SPARQL Query Language for RDF

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This October 2006 release of the SPARQL Query Language specification represents a return to Working Draft by the RDF Data Access Working Group (part of the Semantic Web Activity) for review by W3C Members and other interested parties. The Working Group specifically seeks guidance from the community on the following issues:

• Should SELECTed variables be separated by commas?
• Should blank nodes be treated differently than variables in the query pattern?

The change log enumerates changes since the Candidate Recommendation of 6 April 2006. See also: SPARQL Test Cases, in progress, and the collected defintions from this document. Plese send comments to public-rdf-dawg-comments@w3.org, a mailing list with a public archive.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Appendices

• A SPARQL Grammar
  • A.1 SPARQL Query String References
  • A.2 Codepoint Escape Sequences
  • A.3 White Space
  • A.4 Comments
  • A.5 IRI References
  • A.6 Escape sequences in strings
  • A.7 Grammar
• B Conformance
• C Security Considerations
• D Collected Formal Definitions
• E Internet Media Type, File Extension and Macintosh File Type
• F References
• G Acknowledgements
• H Change Log

In addition, the collected formal definitions are collected into a single document "SPARQL Query Language for RDF - Formal Definitions".

    @@Scope of blank nodes in BGP and FilteredBasicGraphPatterns. 3.1.4 & 5.4 + clarify the group example of { {} {} }

    @@Consider putting formal definitions first for OPTIONAL, UNION and result forms (10.2, 10.3, 10.4, 10.5)

1 Introduction

An RDF graph is a set of triples; each triple consists of a subject, a predicate and an object. RDF graphs are defined in RDF Concepts and Abstract Syntax [CONCEPTS]. These triples can come from a variety of sources. For instance, they may come directly from an RDF document; they may be inferred from other RDF triples; or they may be the RDF expression of data stored in other formats, such as XML or relational databases. The RDF graph may be virtual, in that it is not fully materialized, only doing the work needed for each query to execute.

SPARQL is a query language for getting information from such RDF graphs. It provides facilities to:

• extract information in the form of URIs, blank nodes and literals.
• extract RDF subgraphs.
• construct new RDF graphs based on information in the queried graphs.

As a data access language, it is suitable for both local and remote use. The companion SPARQL Protocol for RDF document [SPROT] describes the remote access protocol.

1.1 Document Outline

This document defines the SPARQL, an RDF query language.

    @@About grammar extracts

    @@ This text does somewhere:

Later sections of this document describe how other graph patterns can be built using the graph operators OPTIONAL and UNION; how graph patterns can be grouped together; how queries can extract information from more than one graph, and how it is also possible to restrict the values allowed in matching a pattern.

1.2 Document Conventions

1.2.1 Namespaces

In this document, examples assume the following namespace prefix bindings unless otherwise stated:

1.2.2 Data Descriptions

@@ Need a bit more, esp blank nodes.

The data format used in this document is Turtle [TURTLE], used to show each triple explicitly. Turtle allows URIs to be abbreviated with prefixes:

@prefix dc:   <http://purl.org/dc/elements/1.1/> .
@prefix :     <http://example.org/book/> .
:book1  dc:title  "SPARQL Tutorial" .

1.2.3 Result Descriptions

Results in the form of result sets are illustrated results in tabular form.

The term "binding" is used as a descriptive term to refer to a pair of (variable, RDF term). In this result set, there are variables x, y and z (shown as column hearers). Each solution is shown as a row in the body of the table.  Here, there is a single solution, where variable x is bound to "Alice", variable y is bound to <http://example/a>, and variable z is not bound to an RDF term. Not every binding needs to exist in every row of the table. Optional matches and alternative matches may leave some variables unbound.

Results can be returned in XML using the SPARQL Query Results XML Format [RESULTS].

2 Making Simple Queries

The SPARQL query language is based on matching graph patterns. The simplest graph pattern is the triple pattern, which is like an RDF triple, but with the possibility of a variable instead of an RDF term in the subject, predicate or object positions. Combining triple patterns gives a basic graph pattern, where an exact match to a graph is needed to fulfill a pattern.

2.1 Writing a Simple Query

The example below shows a SPARQL query to find the title of a book from the information in the given RDF graph. The query consists of two parts, the SELECT clause and the WHERE clause. The SELECT clause identifies the variables to appear in the query results, and the WHERE clause has one triple pattern.

<http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title> "SPARQL Tutorial" .

SELECT ?title
WHERE
{
  <http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title> ?title .
}    

2.2 Multiple Matches

The results of a query is a sequence of solutions, giving the ways in which the query pattern matches the data. The sequence of solutions is further modified by the solution sequence modifiers. There may be zero, one or multiple solutions to a query.

Data:

@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

_:a  foaf:name   "Johnny Lee Outlaw" .
_:a  foaf:mbox   <mailto:jlow@example.com> .
_:b  foaf:name   "Peter Goodguy" .
_:b  foaf:mbox   <mailto:peter@example.org> .

PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
WHERE
  { ?x foaf:name ?name .
    ?x foaf:mbox ?mbox }

The results enumerate the RDF terms to which the selected variables can be bound in the query pattern in order to match triples in the data. In the above example, the following two subsets of the data provided the two matches.

 _:a foaf:name  "Johnny Lee Outlaw" .
 _:a foaf:box   <mailto:jlow@example.com> .

 _:b foaf:name  "Peter Goodguy" .
 _:b foaf:box   <mailto:peter@example.org> .

This is a basic graph pattern match, and all the named variables used in the query pattern must be bound in every solution.

2.3 Matching RDF Literals

The data below contains a number of RDF literals:

@prefix dt:   <http://example.org/datatype#> .
@prefix ns:   <http://example.org/ns#> .
@prefix :     <http://example.org/ns#> .
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .

:x   ns:p     "42"^^xsd:integer .
:y   ns:p     "abc"^^dt:specialDatatype .
:z   ns:p     "cat"@en .

SELECT ?v WHERE { ?v ?p 42 }

SELECT ?v WHERE { ?v ?p "abc"^^<http://example.org/datatype#specialDatatype> }

SELECT ?x WHERE { ?x ?p "cat" }

SELECT ?x WHERE { ?x ?p "cat"@en }

because "cat"@en is a term in the graph whereas "cat" is not.

2.4 Value Constraints

Graph pattern matching creates bindings of variables. It is possible to further restrict solutions by constraining the RDF terms that can be used as bindings of variables. Value constraints take the form of boolean-valued expressions; the language also allows application-specific constraints on the values in a solution.

@prefix dc:   <http://purl.org/dc/elements/1.1/> .
@prefix :     <http://example.org/book/> .
@prefix ns:   <http://example.org/ns#> .

:book1  dc:title  "SPARQL Tutorial" .
:book1  ns:price  42 .
:book2  dc:title  "The Semantic Web" .
:book2  ns:price  23 .

PREFIX  dc:  <http://purl.org/dc/elements/1.1/>
SELECT  ?title
WHERE   { ?x dc:title ?title
          FILTER regex(?title, "SPARQL") 
        }

PREFIX  dc:  <http://purl.org/dc/elements/1.1/>
SELECT  ?title
WHERE   { ?x dc:title ?title
          FILTER regex(?title, "web", "i" ) 
        }

PREFIX  dc:  <http://purl.org/dc/elements/1.1/>
PREFIX  ns:  <http://example.org/ns#>
SELECT  ?title ?price
WHERE   { ?x ns:price ?price .
          FILTER (?price < 30.5) .
          ?x dc:title ?title . }

By constraining the price variable, only book2 matches the query because only book2 has a price less than 30.5, as the filter condition requires.

2.5 Term Constraints

    @@ isURI/isLiteral/isBlank.  Discuss these test

2.6 Querying Reification Vocabulary

RDF defines a reification vocabulary which provides for describing RDF statements without stating them. These descriptions of statements can be queried by using the defined vocabulary. SPARQL does not treat querying reified data differently from any other RDF data. SPARQL can be used to query graph-pattern matches using the reification vocabulary.

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix dc:  <http://purl.org/dc/elements/1.1/> .
@prefix :    <http://example/ns#> .

_:a   rdf:subject   <http://example.org/book/book1> .
_:a   rdf:predicate dc:title .
_:a   rdf:object    "SPARQL" .
_:a   :saidBy       "Alice" .

_:b   rdf:subject   <http://example.org/book/book1> .
_:b   rdf:predicate dc:title .
_:b   rdf:object    "SPARQL Tutorial" .
_:b   :saidBy       "Bob" .

PREFIX dc: <http://purl.org/dc/elements/1.1/>

SELECT ?book ?title
WHERE
{ ?book dc:title ?title }

PREFIX rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX dc:   <http://purl.org/dc/elements/1.1/>
PREFIX :     <http://example/ns#>

SELECT ?book ?title
WHERE
{ ?t rdf:subject    ?book  .
  ?t rdf:predicate  dc:title .
  ?t rdf:object     ?title .
  ?t :saidBy        "Bob" .
}

2.7 Blank Nodes in Query Results

    @@ Move to section 10

The presence of blank nodes in query results can be indicated by labels in the serialization of query results.

Blank nodes in the results of a query are from the scoping set, but this information cannot be used by an application or client which receives these results, since all blank nodes in subsequent queries are treated as being local to that query. In effect, this means that information about co-occurrences of blank nodes may be treated as scoped to the results as defined in "SPARQL Query Results XML Format" or the CONSTRUCT result form.

@prefix foaf:  <http://xmlns.com/foaf/0.1/> .

_:a  foaf:name   "Alice" .
_:b  foaf:name   "Bob" .

PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
SELECT ?x ?name
WHERE  { ?x foaf:name ?name }

These two results have the same information: the blank nodes used to match the query are different in the two solutions. There would be no relation if the label _:a were used in the results and the blank node label in the data graph.

3 SPARQL Term Syntax

This section covers the syntax used by SPARQL for RDF terms and triple patterns. The full grammar is given in appendix A.

3.1 RDF Term Syntax

3.1.1 Syntax for IRIs

The terms delimited by "<>" are IRI references [RFC3987]; the delimiters do not form part of the reference. They stand for IRIs, either directly, or relative to a base IRI. IRIs are a generalization of URIs [RFC3986] and are fully compatible with URIs and URLs.

The SPARQL syntax provides two abbreviation mechanisms for IRIs, prefixed names and relative IRIs.

Prefixed names

The PREFIX keyword associates a prefix label with an IRI. A prefixed name is a prefix label and a local part, separated by a colon ":". It is mapped to an IRI by concatenating the local part to the IRI corresponding to the prefix. The prefix label may be the empty string.

Relative IRIs

Relative IRIs are combined with base IRIs as per Uniform Resource Identifier (URI): Generic Syntax [RFC3986] using only the basic algorithm in Section 5.2 . Neither Syntax-Based Normalization nor Scheme-Based Normalization (described in sections 6.2.2 and 6.2.3 of RFC3986) are performed. Characters additionally allowed in IRI references are treated in the same way that unreserved characters are treated in URI references, per section 6.5 of Internationalized Resource Identifiers (IRIs) [RFC3987].

The BASE keyword defines the Base IRI used to resolve relative IRIs per RFC3986 section 5.1.1, "Base URI Embedded in Content". Section 5.1.2, "Base URI from the Encapsulating Entity" defines how the Base IRI may come from an encapsulating document, such as a SOAP envelope with an xml:base directive, or a mime multipart document with a Content-Location header. The "Retrieval URI" identified in 5.1.3, Base "URI from the Retrieval URI", is the URL from which a particular SPARQL query was retrieved. If none of the above specifies the Base URI, the default Base URI (section 5.1.4, "Default Base URI") is used.

The following fragments are some of the different ways to write the same IRI:

<http://example.org/book/book1>

BASE <http://example.org/book/>
<book1>

PREFIX book: <http://example.org/book/>
book:book1

3.1.2 Syntax for Literals

The general syntax for literals is a string (enclosed in quotes, either double quotes "" or single quotes '' ), with either an optional language tag (introduced by @) or an optional datatype IRI or prefixed name (introduced by ^^).

As a convenience, integers can be written directly and are interpreted as typed literals of datatype xsd:integer; decimal numbers, where there is '.' in the number but no exponent, are interpreted as xsd:decimal and a number with an exponent is interpreted as an xsd:double. Values of type xsd:boolean can also be written as true or false.

To facilitate writing literal values which themselves contain quotation marks or which are long and contain newline characters, SPARQL provides an additional quoting construct in which literals are enclosed in three single- or double-quotation marks.

Examples of literal syntax in SPARQL include:

• "chat"
• 'chat'@fr with language tag "fr"
• "xyz"^^<http://example.org/ns/userDatatype>
• "abc"^^appNS:appDataType
• """The librarian said, "Perhaps you would enjoy 'War and Peace'.""""
• 1, which is the same as "1"^^xsd:integer
• 1.3, which is the same as "1.3"^^xsd:decimal
• 1.0e6, which is the same as "1.0e6"^^xsd:double
• true, which is the same as "true"^^xsd:boolean
• false, which is the same as "false"^^xsd:boolean

3.1.3 Syntax for Query Variables

Query variables in SPARQL queries have global scope; use of a given variable name anywhere in a query identifies the same variable. Variables are indicated by "?"; the "?" does not form part of the variable name. "$" is an alternative to "?". In a query, $abc and ?abc are the same variable. The possible names for variables are given in the SPARQL grammar.

3.1.4 Syntax for Blank Nodes

@@Talk about identifiers as mere syntax elements

@@revise/rework when section 5 (BGP matching) updated

A blank node can appear in a query pattern and will take part in the pattern matching. Blank nodes are indicated by either the label form "_:a" or by use of "[ ]". A blank node that is used in only one place in the query syntax can be abbreviated with []. A unique blank node will be created and used to form the triple pattern. Blank node labels are written as "_:a" for a blank node with label "a" and the label is scoped to the basic graph pattern.

The [:p :v] construct can be used in triple patterns. It creates a blank node label which is used as the subject of all contained predicate-object pairs. The created blank node can also be used in further triple patterns in the subject and object positions.

The following two forms

[ :p "v" ] .

[] :p "v" .

allocate a unique blank node label (here "b57") and are equivalent to writing:

_:b57 :p "v" .

This allocated blank node label can be used as the subject or object of further triple patterns. For example, as a subject:

[ :p "v" ] :q "w" .

is equivalent to the two triples:

_:b57 :p "v" .
_:b57 :q "w" .

and as an object:

:x :q [ :p "v" ] .

is equivalent to the two triples:

:x  :q _:b57 .
_:b57 :p "v" .

Abbreviated blank node syntax can be combined with other abbreviations for common subjects and predicates.

  [ foaf:name  ?name ;
    foaf:mbox  <mailto:alice@example.org> ]

This is the same as writing the following basic graph pattern for some uniquely allocated blank node:

  _:b18  foaf:name  ?name .
  _:b18  foaf:mbox  <mailto:alice@example.org> .

    @@ Add rules for [:p "object] when grammar stable again.

3.2 Syntax for Triple Patterns

Triple Patterns are written as a list of subject, predicate, object; there are abbreviated ways of writing some common triple pattern constructs.

The following examples express the same query:

PREFIX  dc: <http://purl.org/dc/elements/1.1/>
SELECT  ?title
WHERE   { <http://example.org/book/book1> dc:title ?title }  

PREFIX  dc: <http://purl.org/dc/elements/1.1/>
PREFIX  : <http://example.org/book/>

SELECT  $title
WHERE   { :book1  dc:title  $title }

BASE    <http://example.org/book/>
PREFIX  dc: <http://purl.org/dc/elements/1.1/>

SELECT  $title
WHERE   { <book1>  dc:title  ?title }

3.2.1 Predicate-Object Lists

Triple patterns with a common subject can be written so that the subject is only written once, and used for more than one triple pattern by employing the ";" notation.

    ?x  foaf:name  ?name ;
        foaf:mbox  ?mbox .

This is the same as writing the triple patterns:

    ?x  foaf:name  ?name .
    ?x  foaf:mbox  ?mbox .

3.2.2 Object Lists

If triple patterns share both subject and predicate, then these can be written using the "," notation.

    ?x foaf:nick  "Alice" , "Alice_" .

is the same as writing the triple patterns:

   ?x  foaf:nick  "Alice" .
   ?x  foaf:nick  "Alice_" .

Object lists can be combined with predicate-object lists:

   ?x  foaf:name ?name ; foaf:nick  "Alice" , "Alice_" .

giving:

   ?x  foaf:name  ?name .
   ?x  foaf:nick  "Alice" .
   ?x  foaf:nick  "Alice_" .

3.2.3 RDF Collections

RDF collections can be written in triple patterns using the syntax "( )". The form () is an alternative for the IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#nil. When used with collection elements, such as (1 ?x 3 4), triple patterns and blank nodes are allocated for the collection and the blank node at the head of the collection can be used as a subject or object in other triple patterns. Blank nodes allocated do not occur else in the query.

(1 ?x 3 4) :p "w" .

is a short form for (the blank node labels do not occur anywhere else in the query):

    _:b0  rdf:first  1 ;
          rdf:rest   _:b1 .
    _:b1  rdf:first  ?x ;
          rdf:rest   _:b2 .
    _:b2  rdf:first  3 ;
          rdf:rest   _:b3 .
    _:b3  rdf:first  4 ;
          rdf:rest   rdf:nil .
    _:b0  :p         "w" . 

RDF collections can be nested and can involve other syntactic forms:

(1 [:p :q] ( 2 ) ) .

is a short form for:

    _:b0  rdf:first  1 ;
          rdf:rest   _:b1 .
    _:b1  rdf:first  _:b2 .
    _:b2  :p         :q .
    _:b1  rdf:rest   _:b3 .
    _:b3  rdf:first  _:b4 .
    _:b4  rdf:first  2 ;
          rdf:rest   rdf:nil .
    _:b3  rdf:rest   rdf:nil .

3.2.4 rdf:type

The keyword "a" can be used as a predicate in a triple pattern and is an alternative for the IRI  http://www.w3.org/1999/02/22-rdf-syntax-ns#type. This keyword is case-sensitive.

  ?x  a  :Class1 .
  [ a :appClass ] :p "v" .

  is short for:

  ?x    rdf:type  :Class1 .
  _:b0  rdf:type  :appClass .
  _:b0  :p        "v" .

where rdf: is the prefix for http://www.w3.org/1999/02/22-rdf-syntax-ns#

4 Initial Definitions

The following terms are used from RDF Concepts and Abstract Syntax [CONCEPTS]

• IRI
• literal
• lexical form
• plain literal
• language tag
• typed literal
• datatype IRI
• blank node

SPARQL is defined in terms of IRIs. RDF Concepts and Abstract Syntax "anticipates an RFC on Internationalized Resource Identifiers. Implementations may issue warnings concerning the use of RDF URI References that do not conform with [IRI draft] or its successors."

4.1 RDF Terms

SPARQL is defined in terms of IRIs, a subset of RDF URI References that omits spaces.

This definition of RDF Term collects together several basic notions from the RDF data model, but updated to refer to IRIs rather than RDF URI references.

Note that all IRIs are absolute; they may or may not include a fragment identifier [RFC3987, section 3.1]. IRIs include URIs [RFC3986] and URLs. The abbreviated forms (relative IRIs and prefixed names) in the SPARQL syntax are resolved to produce absolute IRIs.

4.2 Query Variables

SPARQL query results are a binding of query variables to RDF Terms.

4.3 Triple Patterns

The building blocks of queries are triple patterns.

This definition of Triple Pattern includes literal subjects. This has been noted by RDF-core.

"[The RDF core Working Group] noted that it is aware of no reason why literals should not
  be subjects and a future WG with a less restrictive charter may
  extend the syntaxes to allow literals as the subjects of statements."

Because RDF graphs may not contain literal subjects, any SPARQL triple pattern with a literal as subject will fail to match on any RDF graph.

4.4 Graph Pattern

SPARQL queries are made of one or more graph patterns. Graph patterns can be combined into larger patterns.

4.5 SPARQL Query

Formally, a SPARQL query contains four components: the pattern, the dataset being queried, solution modifiers, and the result form.

The graph pattern may be the empty pattern. The set of solution modifiers may be the empty set.

4.6 Pattern Solutions

The term "solution" is used for "pattern solution" where it is unambiguous.

@@ Consider whether to have a "RDF dataset" section in "Initial Definitions"

Graph patterns match against the default graph of an RDF dataset, except for the RDF Dataset Graph Pattern. In this section, all matching is described for a single graph, being the default graph of the RDF dataset being queried.

4.7 Value Constraints

Constraints may be restrictions on the value associated with an RDF Term or they may be restrictions on some part of an RDF term, such as its lexical form. There is a set of functions & operators in SPARQL for constraints. In addition, there is an extension mechanism to provide access to functions that are not defined in the SPARQL language. Restrictions on the value of a RDF term are based on its value, as given by any datatype; value tests only apply to RDF literals.

A constraint may lead to an error condition when testing some RDF term. The exact error will depend on the constraint: for example, in numeric operations, solutions with variables bound to a non-number or a blank node will lead to an error. Any potential solution that causes an error condition in a constraint will not form part of the final results, but does not cause the query to fail.

@@Say more about what gets filtered when filters are in groups, or elements inside groups.  Extend extract to show this.

5 Basic Graph Patterns

A basic graph pattern is a set of triple patterns and forms the basis of SPARQL query matching. Matching a basic graph pattern is defined in terms of generic entailment to allow for future extension of the language.

This specification covers only simple entailment [RDF-MT] as E-entailment. Examples of other E-entailment regimes are RDF entailment [RDF-MT], RDFS entailment [RDF-MT], OWL entailment [OWL-Semantics].

Logical entailment may result in inconsistent RDF graphs. For example, "-1"^^xsd:positiveInteger is inconsistent with respect to D-entailment [RDF-MT]. The effect of any query on an inconsistent graph is not covered by this specification.

This definition extends that for RDF graph-equivalence to basic graph patterns by preserving variable names across equivalent graphs.

5.1 General Framework

@@ Better name: "General Basic Graph Pattern Matching" ??

The scoping set restricts the values of variable assignments in a solution. The scoping set may be characterized differently by different entailment regimes.

The scoping graph makes the graph to be matched independent of the chosen blank node names.

The same scoping set and scoping graph is used for all basic graph pattern matching in a single SPARQL query request.

The introduction of the basic graph pattern BGP' in the above definition makes the query basic graph pattern independent of the choice of blank node names in the basic graph pattern.

Open Issue: Should blank nodes be treated differently than variables in the query pattern?.
Current specification: yes: blank nodes in the query pattern are scoped to a basic graph pattern. Their use in FILTERs is unclear.
Alternative Proposal: the previous last call working draft treated blank nodes in the query pattern as variables.
Costs: Tableau-based reasoners (at least, the Pellet Demo example 7) rely on the current, more expressive semantics to match implications that are not in a materializable RDF graph.
Benefit: would simplify the current semantics, which are difficult to specify and allow the expression of counter-intuitive queries.

5.2 SPARQL Basic Graph Pattern Matching

These definitions allow for future extensions to SPARQL. This document defines SPARQL for simple entailment and the scoping set B is the set of all RDF terms in G'.

When using simple entailment, the operation of querying an RDF graph provides access to the graph structure, up to blank node renaming; nothing that is not already in the graph G needs to be inferred or constructed, even implicitly.

A pattern solution can then be defined as follows: to match a basic graph pattern under simple entailment, it is possible to proceed by finding a mapping from blank nodes and variables in the basic graph pattern to terms in the graph being matched; a pattern solution is then a mapping restricted to just the variables, possibly with blank nodes renamed. Moreover, a uniqueness property guarantees the interoperability between SPARQL systems: given a graph and a basic graph pattern, the set of all the pattern solutions is unique up to blank node renaming.

5.3 Example of Basic Graph Pattern Matching

As an example of a Basic Graph Pattern:

Data:

@prefix foaf:    <http://xmlns.com/foaf/0.1/> .

_:a  foaf:name   "Johnny Lee Outlaw" .
_:a  foaf:mbox   <mailto:outlaw@example.com> .

_:b  foaf:name   "A. N. Other" .
_:b  foaf:mbox   <mailto:other@example.com> .

PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
SELECT ?mbox
WHERE
  { ?x foaf:name "Johnny Lee Outlaw" .
    ?x foaf:mbox ?mbox }

This query contains a basic graph pattern of two triple patterns, each of which must match with the same solution for the graph pattern to match. The pattern solution matching the basic graph pattern maps the variable 'x' to blank node _:a and variable 'mbox' to the IRI mailto:outlaw@example.com. The query only returns the variable 'mbox'.

5.4 Basic Graph Patterns in the SPARQL Syntax

In the SPARQL syntax, Basic Graph Patterns are sequences of triple patterns mixed with value constraints. Other graph patterns separate basic patterns. The two query fragments below each contain the same basic graph pattern of

{ _:x :p ?v . _:x :q ?w . }

with the scope of the blank node label being the basic graph pattern.

{ _:x :p ?v .
  FILTER (?v < 3) .
  _:x :q ?w .
}

{ _:x :p ?v .
  _:x :q ?w .
  FILTER (?v < 3) .
}

6 Group Graph Patterns

@@ Don't need this summary any more ?

Complex graph patterns can be made by combining simpler graph patterns. The ways of creating graph patterns are:

• Basic Graph Patterns, where a set of triple patterns must match
• Group Graph Pattern, where a set of graph patterns must all match using the same variable substitution
• Value constraints, which restrict RDF terms in a solution
• Optional Graph patterns, where additional patterns may extend the solution
• Alternative Graph Pattern, where two or more possible patterns are tried
• Patterns on Named Graphs, where patterns are matched against named graphs

6.1 Group Graph Patterns

For any solution, the same variable is given the same value everywhere in the set of graph patterns making up the group graph pattern.

In a SPARQL query string, a group graph pattern is delimited with braces: {}. For example, this query has a group graph pattern of one basic graph pattern as the query pattern.

PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
WHERE  {
          ?x foaf:name ?name .
          ?x foaf:mbox ?mbox .
       }

PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
WHERE  { { ?x foaf:name ?name . }
         { ?x foaf:mbox ?mbox . }
       }

6.2 Empty Group Pattern

The group pattern:

{ }

matches any graph (including the empty graph) requiring no substitutions for variables.

SELECT ?x
WHERE {}

matches with one solution which has no substitutions for variables.

@@ More? Need to couple to a pattern solution involves the "required" terms.

6.3 Order of Evaluation

There is no implied order of graph patterns within a Group Graph Pattern. Any solution for the group graph pattern that can satisfy all the graph patterns in the group is valid, independently of the order that may be implied by the lexical order of the graph patterns in the group.

7 Including Optional Values

Basic graph patterns allow applications to make queries where the entire query pattern must match for there to be a solution. For every solution of the query, every variable is bound to an RDF Term in a pattern solution. However, regular, complete structures cannot be assumed in all RDF graphs and it is useful to be able to have queries that allow information to be added to the solution where the information is available, but not to have the solution rejected because some part of the query pattern does not match. Optional matching provides this facility; if the optional part does not lead to any solutions, it creates no bindings.

7.1 Optional Pattern Matching

Optional parts of the graph pattern may be specified syntactically with the OPTIONAL keyword applied to a graph pattern:

pattern OPTIONAL { pattern }

@prefix foaf:       <http://xmlns.com/foaf/0.1/> .
@prefix rdf:        <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

_:a  rdf:type        foaf:Person .
_:a  foaf:name       "Alice" .
_:a  foaf:mbox       <mailto:alice@example.com> .
_:a  foaf:mbox       <mailto:alice@work.example> .

_:b  rdf:type        foaf:Person .
_:b  foaf:name       "Bob" .

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
WHERE  { ?x foaf:name  ?name .
         OPTIONAL { ?x  foaf:mbox  ?mbox }
       }

There is no value of mbox in the solution where the name is "Bob". It is unbound.

This query finds the names of people in the data. If there is a triple with predicate mbox and same subject, a solution will contain the object of that triple as well. In the example, only a single triple pattern is given in the optional match part of the query but, in general, it is any graph pattern. The whole graph pattern of an optional graph pattern must match for the optional graph pattern to affect the query solution.

7.2 Constraints in Optional Pattern Matching

Constraints can be given in an optional graph pattern as this example shows:

@prefix dc:   <http://purl.org/dc/elements/1.1/> .
@prefix :     <http://example.org/book/> .
@prefix ns:   <http://example.org/ns#> .

:book1  dc:title  "SPARQL Tutorial" .
:book1  ns:price  42 .
:book2  dc:title  "The Semantic Web" .
:book2  ns:price  23 .

PREFIX  dc:  <http://purl.org/dc/elements/1.1/>
PREFIX  ns:  <http://example.org/ns#>
SELECT  ?title ?price
WHERE   { ?x dc:title ?title .
          OPTIONAL { ?x ns:price ?price . FILTER (?price < 30) }
        }

No price appears for the book with title "SPARQL Tutorial" because the optional graph pattern did not lead to a solution involving the variable "price".

7.3 Multiple Optional Graph Patterns

Graph patterns are defined recursively. A graph pattern may have zero or more optional graph patterns, and any part of a query pattern may have an optional part. In this example, there are two optional graph patterns.

@prefix foaf:       <http://xmlns.com/foaf/0.1/> .

_:a  foaf:name       "Alice" .
_:a  foaf:homepage   <http://work.example.org/alice/> .

_:b  foaf:name       "Bob" .
_:b  foaf:mbox       <mailto:bob@work.example> .

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox ?hpage
WHERE  { ?x foaf:name  ?name .
         OPTIONAL { ?x foaf:mbox ?mbox } .
         OPTIONAL { ?x foaf:homepage ?hpage }
       }

7.4 Optional Matching – Formal Definition

In an optional match, either an additional graph pattern matches a graph, thereby defining one or more pattern solutions; or it passes the solution without adding any additional bindings.

The syntactic form:

{ OPTIONAL { pattern } }

is defined to be

{ { } OPTIONAL { pattern } }

The OPTIONAL keyword is left-associative :

pattern OPTIONAL { pattern } OPTIONAL { pattern }

matches the same as:

{ pattern OPTIONAL { pattern } } OPTIONAL { pattern }

7.5 Nested Optional Graph Patterns

Optional patterns can occur inside any group graph pattern, including a group graph pattern which itself is optional, forming a nested pattern. The outer optional graph pattern must match for any nested optional pattern to be matched.

@prefix foaf:       <http://xmlns.com/foaf/0.1/> .
@prefix vcard:      <http://www.w3.org/2001/vcard-rdf/3.0#> .

_:a  foaf:name     "Alice" .
_:a  foaf:mbox     <mailto:alice@work.example> .
_:a  vcard:N       _:x .

_:x  vcard:Family  "Hacker" .
_:x  vcard:Given   "Alice" .

_:b  foaf:name     "Bob" .
_:b  foaf:mbox     <mailto:bob@work.example> .
_:b  foaf:N        _:z .

_:z  vcard:Family  "Hacker" .

_:e  foaf:name     "Ella" .
_:e  vcard:N       _:y .

_:y  vcard:Given   "Eleanor" .

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX vcard: <http://www.w3.org/2001/vcard-rdf/3.0#>
SELECT ?foafName ?mbox ?gname ?fname
WHERE
  {  ?x foaf:name ?foafName .
     OPTIONAL { ?x foaf:mbox ?mbox } .
     OPTIONAL {  ?x vcard:N ?vc .
                 ?vc vcard:Given ?gname .
                 OPTIONAL { ?vc vcard:Family ?fname }
              }
  }

This query finds the name, optionally the mbox, and also the vCard given name; further, if there is a vCard Family name as well as the Given name, the query finds that as well.

By nesting the optional pattern involving vcard:Family, the query only matches these if there are appropriate vcard:N and vcard:Given triples in the data. Here the expression is a simple triple pattern on vcard:N but it could be a complex graph pattern with value constraints.

8 Matching Alternatives

SPARQL provides a means of combining graph patterns so that one of several alternative graph patterns may match. If more than one of the alternatives matches, all the possible pattern solutions are found.

8.1 Joining Patterns with UNION

The UNION keyword is the syntax for pattern alternatives.

@prefix dc10:  <http://purl.org/dc/elements/1.0/> .
@prefix dc11:  <http://purl.org/dc/elements/1.1/> .

_:a  dc10:title     "SPARQL Query Language Tutorial" .
_:a  dc10:creator   "Alice" .

_:b  dc11:title     "SPARQL Protocol Tutorial" .
_:b  dc11:creator   "Bob" .

_:c  dc10:title     "SPARQL" .
_:c  dc11:title     "SPARQL (updated)" .

PREFIX dc10:  <http://purl.org/dc/elements/1.0/>
PREFIX dc11:  <http://purl.org/dc/elements/1.1/>

SELECT ?title
WHERE  { { ?book dc10:title  ?title } UNION { ?book dc11:title  ?title } }

PREFIX dc10:  <http://purl.org/dc/elements/1.0/>
PREFIX dc11:  <http://purl.org/dc/elements/1.1/>

SELECT ?x ?y
WHERE  { { ?book dc10:title ?x } UNION { ?book dc11:title  ?y } }

PREFIX dc10:  <http://purl.org/dc/elements/1.1/>
PREFIX dc11:  <http://purl.org/dc/elements/1.0/>

SELECT ?title ?author
WHERE  { { ?book dc10:title ?title .  ?book dc10:creator ?author }
         UNION
         { ?book dc11:title ?title .  ?book dc11:creator ?author }
       }

This query will only match a book if it has both a title and creator predicate from the same version of Dublin Core.

8.2 Union Matching – Formal Definition

Query results involving a pattern containing GP1 and GP2 will include separate solutions for each match where GP1 and GP2 give rise to different sets of bindings.

9 RDF Dataset

The RDF data model expresses information as graphs, consisting of triples with subject, predicate and object. Many RDF data stores hold multiple RDF graphs, and record information about each graph, allowing an application to make queries that involve information from more than one graph.

A SPARQL query is executed against an RDF Dataset which represents a collection of graphs. An RDF Dataset comprises one graph, the default graph, which does not have a name, and zero or more named graphs, each identified by IRI. A SPARQL query can match different parts of the query pattern against different graphs as described in the query section.

There may be no named graphs; there is always a default graph.

In the previous sections, all queries have been shown executed against a single graph, being the default graph of an RDF dataset. A query does not need to involve the default graph; the query can just involve matching named graphs.

9.1 Examples of RDF Datasets

The definition of RDF Dataset does not restrict the relationships of named and default graphs. Information can be repeated in different graphs; relationships between graph can exposed. Two useful arrangements are:

• to have information in the default graph that includes provenance information about the named graphs
• to include the information in the named graphs in the default graph as well.

# Default graph
@prefix dc: <http://purl.org/dc/elements/1.1/> .

<http://example.org/bob>    dc:publisher  "Bob" .
<http://example.org/alice>  dc:publisher  "Alice" .

# Named graph: http://example.org/bob
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Bob" .
_:a foaf:mbox <mailto:bob@oldcorp.example.org> .

# Named graph: http://example.org/alice
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Alice" .
_:a foaf:mbox <mailto:alice@work.example.org> .

In this example, the default graph contains the names of the publishers of two named graphs. The triples in the named graphs are not visible in the default graph in this example.

Example 2:

RDF data can be combined by the RDF merge [RDF-MT] of graphs. One possible arranegment of graphs in an RDF Dataset is to have the default graph being the RDF merge of some or all of the information in the named graphs.

In this next example, the named graphs contain the same triples as before. The RDF dataset includes an RDF merge of the named graphs in the default graph, re-labeling blank nodes to keep them distinct.

# Default graph
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:x foaf:name "Bob" .
_:x foaf:mbox <mailto:bob@oldcorp.example.org> .

_:y foaf:name "Alice" .
_:y foaf:mbox <mailto:alice@work.example.org> .

# Named graph: http://example.org/bob
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Bob" .
_:a foaf:mbox <mailto:bob@oldcorp.example.org> .

# Named graph: http://example.org/alice
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Alice" .
_:a foaf:mbox <mailto:alice@work.example> .

9.2 Specifying RDF Datasets

A SPARQL query may specify the dataset to be used for matching using the FROM clause and the FROM NAMED clause to describe the RDF dataset. If a query provides such a dataset description, then it is used in place of any dataset that the query service would use if no dataset description is provided in a query. The RDF dataset may also be specified in a SPARQL protocol request, in which case the protocol description overrides any description in the query itself. A query service may refuse a query request if the dataset description is not acceptable to the service.

A query processor may use these IRIs in any way to associate an RDF Dataset with a query. For example, it could use IRIs to retrieve documents, parse them and use the resulting triples as one of the graphs; alternatively, it might only service queries that specify IRIs of graphs that it has already stored.

The FROM and FROM NAMED keywords allow a query to specify an RDF dataset by reference; they indicate that the dataset should include graphs that are obtained from representations of the resources identified by the given IRIs (i.e. the absolute form of the given IRI references). The dataset resulting from a number of FROM and FROM NAMED clauses is:

• a default graph consisting of the merge of the graphs referred to in the FROM clauses
• a set of (IRI, graph) pairs, one from each FROM NAMED clause.

9.2.1 Specifying the Default Graph

Each FROM clause contains an IRI that indicates the graph to be used to form the default graph. This does not put the graph in as a named graph; a query can do this by also specifying the graph in the FROM NAMED clause.

In this example, there is a single default graph:

# Default graph (stored at http://example.org/foaf/aliceFoaf)
@prefix  foaf:  <http://xmlns.com/foaf/0.1/> .

_:a  foaf:name     "Alice" .
_:a  foaf:mbox     <mailto:alice@work.example> .

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT  ?name
FROM    <http://example.org/foaf/aliceFoaf>
WHERE   { ?x foaf:name ?name }

If a query provides more than one FROM clause, providing more than one IRI to indicate the default graph, then the default graph is based on the RDF merge of the graphs obtained from representations of the resources identified by the given IRIs.

9.2.2 Specifying Named Graphs

A query can supply IRIs for the named graphs in the RDF Dataset using the FROM NAMED clause. Each IRI is used to provide one named graph in the RDF Dataset. Using the same IRI in two or more FROM NAMED clauses results in one named graph with that IRI appearing in the dataset.

# Graph: http://example.org/bob
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Bob" .
_:a foaf:mbox <mailto:bob@oldcorp.example.org> .

# Graph: http://example.org/alice
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Alice" .
_:a foaf:mbox <mailto:alice@work.example> .

...
FROM NAMED <http://example.org/alice>
FROM NAMED <http://example.org/bob>
...

The FROM NAMED syntax suggests that the IRI identifies the corresponding graph, but actually the relationship between a URI and a graph in an RDF dataset is indirect. The IRI identifies a resource, and the resource is represented by a graph (or, more precisely: by a document that serializes a graph). For further details see [WEBARCH].

9.2.3 Combining FROM and FROM NAMED

The FROM clause and FROM NAMED clause can be used in the same query.

# Default graph (stored at http://example.org/dft.ttl)
@prefix dc: <http://purl.org/dc/elements/1.1/> .

<http://example.org/bob>    dc:publisher  "Bob Hacker" .
<http://example.org/alice>  dc:publisher  "Alice Hacker" .

# Named graph: http://example.org/bob
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Bob" .
_:a foaf:mbox <mailto:bob@oldcorp.example.org> .

# Named graph: http://example.org/alice
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Alice" .
_:a foaf:mbox <mailto:alice@work.example.org> .

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dc: <http://purl.org/dc/elements/1.1/>

SELECT ?who ?g ?mbox
FROM <http://example.org/dft.ttl>
FROM NAMED <http://example.org/alice>
FROM NAMED <http://example.org/bob>
WHERE
{
   ?g dc:publisher ?who .
   GRAPH ?g { ?x foaf:mbox ?mbox }
}

This query finds the mbox together with the information in the default graph about the publisher. <http://example.org/dft.ttl> is just the IRI used to form the default graph, not it's name.

9.3 Querying the Dataset

When querying a collection of graphs, the GRAPH keyword is used to match patterns against named graphs. This is by either using an IRI to select a graph or using a variable to range over the IRIs naming graphs.

The following two graphs will be used in examples:

# Named graph: http://example.org/foaf/aliceFoaf
@prefix  foaf:     <http://xmlns.com/foaf/0.1/> .
@prefix  rdf:      <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix  rdfs:     <http://www.w3.org/2000/01/rdf-schema#> .

_:a  foaf:name     "Alice" .
_:a  foaf:mbox     <mailto:alice@work.example> .
_:a  foaf:knows    _:b .

_:b  foaf:name     "Bob" .
_:b  foaf:mbox     <mailto:bob@work.example> .
_:b  foaf:nick     "Bobby" .
_:b  rdfs:seeAlso  <http://example.org/foaf/bobFoaf> .

<http://example.org/foaf/bobFoaf>
     rdf:type      foaf:PersonalProfileDocument .

# Named graph: http://example.org/foaf/bobFoaf
@prefix  foaf:     <http://xmlns.com/foaf/0.1/> .
@prefix  rdf:      <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix  rdfs:     <http://www.w3.org/2000/01/rdf-schema#> .

_:z  foaf:mbox     <mailto:bob@work.example> .
_:z  rdfs:seeAlso  <http://example.org/foaf/bobFoaf> .
_:z  foaf:nick     "Robert" .

<http://example.org/foaf/bobFoaf>
     rdf:type      foaf:PersonalProfileDocument .

PREFIX foaf: <http://xmlns.com/foaf/0.1/>

SELECT ?src ?bobNick
WHERE
  {
    GRAPH ?src
    { ?x foaf:mbox <mailto:bob@work.example> .
      ?x foaf:nick ?bobNick
    }
  }

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX data: <http://example.org/foaf/>

SELECT ?nick
WHERE
  {
     GRAPH data:bobFoaf {
         ?x foaf:mbox <mailto:bob@work.example> .
         ?x foaf:nick ?nick }
  }