Basic Graph Pattern

The atomic building block of a BGP. It mirrors the structure of an RDF triple (subject-predicate-object) but allows variables (prefixed with ? or $) in any position to act as placeholders for unknown values.

• Example: ?person foaf:name "Alice" .
• This pattern matches any triple where the predicate is foaf:name, the object is the literal "Alice", and binds the subject of that triple to the variable ?person.
• A BGP is a conjunction of triple patterns; all patterns must match simultaneously within the same graph.

Variables are the query's unknowns, represented by a ? or $ followed by a name (e.g., ?city, ?date). They are bound to RDF terms (URIs, literals, or blank nodes) during query execution.

• Variables create the join conditions across triple patterns in a BGP. If the same variable appears in multiple patterns, it must be bound to the same value in all matches.
• Example BGP: ?article dc:creator ?author . ?author foaf:based_near ?city .
• Here, ?author is the join variable, ensuring the matched creator is also the entity with a location.

IRIs (Internationalized Resource Identifiers) identify resources and predicates. To keep patterns concise, SPARQL uses prefix declarations (e.g., PREFIX foaf: <http://xmlns.com/foaf/0.1/>) to abbreviate long IRIs.

• Abbreviated IRI: foaf:name expands to the full IRI.
• Full IRI: Enclosed in angle brackets: <http://example.org/person>.
• Using correct IRIs is critical for precise matching against the dataset's ontology.

Literals are constant values (strings, numbers, dates) used in the object position of a triple pattern. They can be:

• Simple Literals: Plain strings: "London".
• Typed Literals: Include a datatype IRI: "42"^^xsd:integer.
• Language-tagged Literals: Include a language tag: "chat"@fr.

Pattern matching is sensitive to literal type and language tag. The pattern ?s ex:value "42" will not match a triple with object "42"^^xsd:integer unless the query explicitly uses the typed literal.

Blank nodes (written as _:a or []) in a BGP act as existential variables—they match any resource but do not bind to a variable name for output. They are useful for matching anonymous resources or specific graph structures without needing to identify the node.

• Example: ?person foaf:knows [ foaf:name "Bob" ] .
• This pattern matches a person who knows some resource (the blank node) that has the name "Bob". The identity of that resource is not captured in the query results.

A BGP is matched against a specific RDF Dataset, which is a collection of graphs. The default graph and any named graphs to be queried are specified using the FROM and FROM NAMED clauses in the SPARQL query.

• Patterns are matched against the default graph unless enclosed in a GRAPH clause.
• GRAPH ?g { ...BGP... }: Matches the BGP only within the named graph bound to variable ?g.
• GRAPH <http://ex.org/graph1> { ... }: Matches the BGP specifically within the named graph identified by that IRI.

A SPARQL Query is a request to retrieve or manipulate data from an RDF graph database. It is composed of several key clauses, with the Basic Graph Pattern forming the core matching logic within the WHERE clause. The query's overall structure determines the form of the results, such as a set of variable bindings (SELECT), a new RDF graph (CONSTRUCT), or a boolean answer (ASK).

A Triple Pattern is the atomic matching unit within a SPARQL query, analogous to an RDF triple but with variables. It consists of a subject, predicate, and object, where any component can be a variable (prefixed with ? or $). A Basic Graph Pattern is a set of these triple patterns that must all find matches in the dataset for a solution to be generated. For example, ?person foaf:name ?name is a single triple pattern.

Solution Modifiers are SPARQL clauses that process the results after the Basic Graph Pattern has been matched. They do not affect which data is matched but control the presentation of the results. Key modifiers include:

• ORDER BY: Sorts the solution sequence.
• LIMIT / OFFSET: Restricts the number of solutions returned, enabling pagination.
• DISTINCT / REDUCED: Eliminates duplicate solutions from the results. These operate on the solution set produced by evaluating the BGP.

A SPARQL Property Path provides a concise syntax for matching arbitrary-length paths in the graph, extending the capability of a simple triple pattern. While a BGP matches fixed, adjacent triples, a property path can match chains of relationships using operators like sequence (/), alternation (|), and Kleene star (*). For example, :Alice :knows+ ?friend finds all people reachable via one or more :knows relationships. Property paths are integrated into graph patterns.

A SPARQL FILTER is a constraint that removes solutions from the result set based on a boolean expression. It is applied to the solutions generated by a Basic Graph Pattern. FILTERs can test values of variables using functions for comparison, regex matching, data type checking, and more. For example, FILTER (?age > 18) would eliminate all solutions where the bound value for ?age is not greater than 18. It refines the results of pattern matching.

An OPTIONAL Graph Pattern allows parts of a query to be matched without causing the entire solution to be rejected if the optional part fails. It is a key feature for dealing with incomplete data. In a query, a BGP inside an OPTIONAL { } block will extend a solution if the pattern matches, but will leave the variables from that pattern unbound if it does not, without invalidating the core solution from the mandatory BGP. This enables left-outer-join semantics.