SPARQL Query Language for RDF

Appendices

• A SPARQL Grammar
• B Security Considerations
• C Collected Formal Definitions
• D Mime Type
• E References
• D Acknowledgements
• E Change Log

1 Introduction

An RDF graph is a set of triples; each triple consists of a subject, a predicate and an object. This is defined in RDF Concepts and Abstract Syntax[12]. 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. They may be the RDF expression of data stored in other formats, such as XML or relational databases.

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, plain and typed 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 Conventions

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

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 in any of the subject, predicate or object positions. Combining these gives a basic graph pattern, where an exact match to a graph is needed to fulfill a pattern.

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.

In this section, we cover simple triple patterns, basic graph patterns as well as the SPARQL syntax for basic pattern queries.

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.

Data:

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

Query:

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

Query Result:

2.1.1 Query Term Syntax

The terms delimited by "<>" are IRI references [RFC3987]. 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 query terms can be literals which are a string (enclosed in quotes, either double quotes "" or single quotes '' ), with an optional language tag (introduced by @) or an optional datatype IRI or qname (introduced by ^^). As a convenience, integers can be written directly and are interpreted as typed literals of datatype xsd:integer; floating point numbers can also be directly written and are interpreted as xsd:double. Values of type xsd:boolean can also be written as true or false.

Variables in SPARQL queries have global scope; it is the same variable everywhere in the query that the same name is used. Variables are indicated by "?"; the "?" does not form part of the variable. "$" is an alternative to "?". In a query, $abc and ?abc are the same variable.

SPARQL provides a two abbreviation mechanisms for IRIs, namespace prefixes and relative IRIs.

The PREFIX keyword binds a prefix to a namespace IRI [NAMESPACE]. A prefix binding applies to any QNames in the query with that prefix; a prefix may be defined only once. A QName is mapped to an IRI by appending the local name to the namespace IRI corresponding to the prefix.

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) is 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 a 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.

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

2.1.2 Examples of Query Syntax

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 }

Prefixes are syntactic: the prefix name does not affect the query, nor do prefix names in queries need to be the same prefixes as used for data. The following query is equivalent to the previous examples and will give the same results when applied to the same data:

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

2.1.3 Data descriptions used in this document

The data format used in this document is Turtle [15], 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" .

2.1.4 Result Descriptions used in this document

The term "binding" is used as a descriptive term to refer to a pair of (variable, RDF term). In this document, we illustrate results in tabular form. If variable x is bound to "Alice" and variable y is bound to "Bob", we show this as:

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 Variable Binding Results XML Format [16].

2.2 Initial Definitions

This definition of RDF Term collects together several basic notions from the RDF data model.

Note that all IRIs are absolute; they may or may not include a fragment identifier [RFC3987, section 3.1]. Also note that IRIs include URIs [RFC3986] and URLs.

Queries can include blank nodes; the blank nodes in a query are disjoint from all blank nodes in the RDF graphs being matched and members of the set of variables.

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

2.3 Triple Patterns

The building blocks of queries are triple patterns. The following triple pattern has a subject variable (the variable book), a predicate of dc:title and an object variable (the variable title).

 ?book dc:title ?title .

Matching a triple pattern to a graph gives bindings between variables and RDF Terms so that the triple pattern, with the variables replaced by the corresponding RDF terms, is a triple of the graph being matched.

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."

Any SPARQL triple pattern with a literal as subject will fail to match on any RDF graph.

2.4 Pattern Solutions

For example, the query:

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

has a single triple pattern as the query pattern. It matches a graph of a single triple:

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

with solution:

2.5 Basic Graph Patterns

The SPARQL syntax uses the keyword WHERE to introduce the Query Pattern.

For a basic graph pattern to match some dataset, there must be a solution where each of the triple patterns matches the dataset with that solution.

Data:

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

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

There is a blank node [12] in this dataset, identified by _:a. The label is only used within the file for encoding purposes. The label information is not in the RDF graph.

Query:

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

Query Result:

This query contains a basic graph pattern of two triple patterns, each of which must match for the graph pattern to match.

2.6 Multiple Matches

The results of a query are all the ways a query can match the graph being queried. Each result is one solution to the query and there may be zero, one or multiple results 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> .

Query:

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

Query Result:

The results enumerate the RDF terms to which the selected variables can be bound in the query pattern. 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 simple, conjunctive graph pattern match, and all the variables used in the query pattern must be bound in every solution.

2.7 Blank Nodes

Blank Nodes and Queries

A blank node can appear in a query pattern. A blank node in a query pattern may match any RDF term.

Blank Nodes and Query Results

The presence of blank nodes can be indicated by labels in the serialization of query results. An application or client receiving the results of a query can tell that two solutions or two variable bindings differ in blank nodes but this information is only scoped to the results as defined in "SPARQL Variable Binding Results XML Format" or the CONSTRUCT result form.

Data:

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

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

Query:

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

The results above could equally be given with different blank node labels because the labels in the results only indicate whether RDF terms in the solutions were the same or different.

These two results have the same information: the blank nodes used to match the query are different in the two solutions. There is no relation between using _:a in the results and any blank node label in the data graph.

2.8 Other Syntactic Forms

There are a number of syntactic forms that abbreviate some common sequences of triples. These syntactic forms do not change the meaning of the query.

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 . 

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_" .

Blank Nodes

Blank nodes have labels which are scoped to the query. They are written as "_:a" for a blank node with label "a".

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.

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 predicates and common objects.

  [ foaf:name  ?name ;
    foaf:mbox  <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  <alice@example.org> .

RDF Collections

RDF collections can be written in triple patterns using the syntax "(  )". The form () is an alternative for the IRI rdf:nil which is  http://www.w3.org/1999/02/22-rdf-syntax-ns#nil. When used with collection elements, such as (1 ?x 3) then 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.

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

is a short form for:

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

Other

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

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

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

3 Working with RDF Literals

An RDF Literal is written in SPARQL as a string containing the lexical form of the literal, followed by an optional language tag or an optional datatype. There are convenience forms for numeric-types literals which are of type xsd:integer, xsd:double and also for  xsd:boolean.

Examples of literal syntax in SPARQL include:

• "chat"
• "chat"@fr with language tag "fr"
• "xyz"^^<http://example.org/ns/userDatatype>
• "abc"^^appNS:appDataType
• 1, which is the same as "1"^^xsd:integer
• 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 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 .

Matching Integers

The pattern in the following query has a solution :x because 42 is syntax for "42"^^<http://www.w3.org/2001/XMLSchema#integer>.

SELECT ?v WHERE { ?v ?p 42 }

Matching Arbitrary Datatypes

The following query has a solution with variable v being :y. The query processor does not have to have any understanding of the values in the space of the datatype because, in this case, lexical form and datatype IRI both match exactly.

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

Matching Language Tags

This following query has no solution because "cat" is not the same RDF literal as "cat"@en:

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

but this does find a solution where variable x is substituted by :z:

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

3.2 Value Constraints

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

Data:

@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 .

Query:

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) .
          ?x dc:title ?title . }

Query Result:

By having a constraint on the "price" variable, only book2 matches the query because there is a restriction on the allowable values of "price".

3.3 Value Constraints – Definition

Constraints may be restrictions of the value of 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.

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.

4 Graph Patterns

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

• Basic Graph Patterns
• Group Pattern, where a set of graph patterns must all match
• 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

4.1 Group Graph Patterns

A group graph pattern is syntactically delimited with braces: {}.

For any solution, the same variable is given the same value everywhere in the set of graph patterns making up the group graph pattern. A Basic Graph Pattern is a group of triple patterns. For example, this query has a group 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 ;
              foaf:mbox ?mbox }
       }

Because a solution to a group graph pattern is a solution to each element of the group, and a solution of a basic graph pattern is a solution to each triple pattern, these queries also have the same solutions as:

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

4.2 Unbound variables

Solutions to graph patterns do not necessarily have to have every variable bound in every solution that causes a graph pattern to be matched. In particular, the OPTIONAL and UNION graph patterns can lead to query results where a variable may be bound in some solutions, but not in others.

4.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.

5 Including Optional Values

Basic graph patterns allow applications to make queries where 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. RDF is semi-structured: a regular, complete structure can not be assumed 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, variables can be left unbound.

5.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 }

Data:

@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> .

_: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 }
       }

With the data above, the query result is:

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 add to the query solution.

5.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.

5.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.

Data:

@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> .

Query:

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 }
       }

Query result:

5.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 any solutions without adding any additional bindings.

The syntactic form:

{ optional { pattern } }

is defined to be

{ } optional { pattern }

5.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.

Data:

@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" .

Query:

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 }
              }
  }

Query result:

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 reaches these if there is a vcard:N predicate. Here the expression is a simple triple pattern on vcard:N but it could be a complex graph pattern with value constraints.

6 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.

6.1 Joining Patterns with UNION

The UNION keyword is the syntax for pattern alternatives.

Data:

@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" .

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

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

Query:

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 } }

Query result:

This query finds titles of the books in the data, whether the title is recorded using Dublin Core properties from version 1.0 or version 1.1. If the application wishes to know how exactly the information was recorded, then the query:

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 } }

will return results with the variables x or y bound depending on which way the query processor matches the pattern to the data. Note that, unlike an OPTIONAL pattern, if neither part of the UNION pattern matched, then the graph pattern would not match.

• The working group decided on this design and closed the disjunction issue without reaching consensus. The objection was that adding UNION would complicate implementation and discourage adoption. If you have input to this aspect of the SPARQL that the working group has not yet considered, please send a comment to public-rdf-dawg-comments@w3.org.

The UNION operator combines graph patterns, so more than one triple pattern can be given in each alternative possibility:

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.

6.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.

7 RDF Dataset

The RDF data model expresses information as graphs, comprising 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 such a collection of graphs. Different parts of the query may be matched against different graphs as described in the next section. There is one graph, the default graph, which does not have a name, and zero or more named graphs, each identified by IRI.

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

7.1 Examples of RDF Datasets

The definition of RDF Dataset does not restrict the relationships of named and default graphs. 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.

Example 1:

# 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 RDF merge[RDF-MT] of graphs so that the default graph can be made to include the RDF merge of some or all of the information in the named graphs.

In this next example, the named graphs contain the same information 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> .

8 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 .

8.1 Accessing Graph Names

The query below matches the graph pattern on each of the named graphs in the dataset and forms solutions which have the src variable bound to IRIs of the graph being matched.

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
    }
  }

The query result gives the name of the graphs where the information was found and the value for Bob's nick:

8.2 Restricting by Graph IRI

The query can restrict the matching applied to a specific graph by supplying the graph IRI.  This query looks for Bob's nick as given in the graph http://example.org/foaf/bobFoaf.

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 }
  }

which yields a single solution:

8.3 Restricting by Bound Variables

A variable used in the GRAPH clause may also be used in another GRAPH clause or in a graph pattern matched against the default graph in the dataset.

This can be used to find information in one part of a query, and thus restrict the graphs matched in another part of the query. The query below uses the graph with IRI http://example.org/foaf/aliceFoaf to find the profile document for Bob; it then matches another pattern against that graph. The pattern in the second GRAPH clause finds the blank node (variable w) for the person with the same mail box (given by variable mbox) as found in the first GRAPH clause (variable whom), because the blank node used to match for variable whom from Alice's FOAF file is not the same as the blank node in the profile document (they are in different graphs).

PREFIX  data:  <http://example.org/foaf/>
PREFIX  foaf:  <http://xmlns.com/foaf/0.1/>
PREFIX  rdfs:  <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?mbox ?nick ?ppd
WHERE
{
  GRAPH data:aliceFoaf
  {
    ?alice foaf:mbox <mailto:alice@work.example> ;
           foaf:knows ?whom .
    ?whom  foaf:mbox ?mbox ;
           rdfs:seeAlso ?ppd .
    ?ppd  a foaf:PersonalProfileDocument .
  } .
  GRAPH ?ppd
  {
      ?w foaf:mbox ?mbox ;
         foaf:nick ?nick 
  }
}    

Any triple in Alice's FOAF file giving Bob's nick is not used to provide a nick for Bob because the pattern involving variable nick is restricted by ppd to a particular Personal Profile Document.

8.4 Named and Default Graphs

Query patterns can involve both the default graph and the named graphs. In this example, an aggregator has read in a Web resource on two different occasions.  Each time a graph is read into the aggregator, it is given an IRI by the local system. The graphs are nearly the same but the email address for "Bob" has changed.

The default graph is being used to record the provenance information and the RDF data actually read is kept in two separate graphs, each of which is given a different IRI by the system. The RDF dataset consists of two, named graphs and the information about them.

RDF Dataset:

# Default graph
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix g:  <tag:example.org,2005-06-06:>

g:graph1 dc:publisher "Bob" .
g:graph1 dc:date "2004-12-06"^^xsd:date .

g:graph2 dc:publisher "Bob" .
g:graph2 dc:date "2005-01-10"^^xsd:date .

# Graph: locally allocated IRI: tag:example.org,2005-06-06:graph1
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

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

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

# Graph: locally allocated IRI: tag:example.org,2005-06-06:graph2
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

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

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

This query finds email addresses, detailing the name of the person and the date the information was discovered.

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

SELECT ?name ?mbox ?date
WHERE
  {  ?g dc:publisher ?name ;
        dc:date ?date .
    GRAPH ?g 
      { ?person foaf:name ?name ; foaf:mbox ?mbox }
  }

The IRI for the date datatype has been abbreviated in the results for clarity.

9 Specifying RDF Datasets

A SPARQL query may specify the dataset to be used for matching.  The FROM clauses give IRIs that the query processor can use to create the default graph and the FROM NAMED clause can be used to specify named graphs. 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 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 already has 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.

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.

9.1 Specifying the Default Graph

The FROM clause contains an IRI that indicates the graph to be used to form the default graph. This does not automatically 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 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.

# 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> .

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

SELECT ?src ?name

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

WHERE
{ GRAPH ?src { ?x foaf:name ?name } }

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 [20].

9.3 Combining FROM and FROM NAMED

The FROM clause and FROM NAMED clauses 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.

10 Query Result Forms

SPARQL has four query result forms. These result forms use the solutions from pattern matching to form result sets or RDF graphs. The query forms are:

SELECT

Returns all, or a subset of, the variables bound in a query pattern match.

CONSTRUCT

Returns an RDF graph constructed by substituting variables in a set of triple templates.

DESCRIBE

Returns an RDF graph that describes the resources found.

ASK

Returns a boolean indicating whether a query pattern matches or not.

The SPARQL Variable Binding Results XML Format can be used to serialize result sets from a SELECT query or the boolean result of an ASK query.

10.1 Solution Sequences and Result Forms

Query patterns generate an unordered collection of solutions, each solution being a function from variables to RDF terms. These solutions are then treated as a sequence, initially in no specific order; any sequence modifiers are then applied to create another sequence. Finally, this latter sequence is used to generate one of the SPARQL result forms.

The elements of a sequence of solutions can be modified by:

1. Projection
2. DISTINCT: ensure solutions in the sequence are unique.
3. ORDER BY: put the solutions in order
4. LIMIT: restrict the number of solutions processed for query results
5. OFFSET: control where the solutions processed start from in the overall sequence of solutions.

The effect of applying these controls is as if they are applied in the order given.

10.1.1 Projection

The solution sequence can be transformed into one involving only a subset of the variables. For each solution in the sequence, a new solution is formed using a specified selection of the variables.

The following example shows a query to extract just the names of people described in an RDF graph using FOAF properties.

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

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

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

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

10.1.2 DISTINCT

The solution sequence can be modified by adding the DISTINCT keyword which ensures that every combination of variable bindings (i.e. each solution) in the sequence is unique.

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

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

_:z    foaf:name   "Alice" .
_:z    foaf:mbox   <mailto:smith@work> .

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

If DISTINCT and LIMIT or OFFSET are specified, then duplicates are eliminated before the limit or offset is applied.

10.1.3 ORDER BY

The ORDER BY clause takes a solution sequence and applies ordering conditions. An ordering condition can be a variable or a function call. The direction of ordering is ascending by default. It can be explicitly set to ascending or descending by enclosing the condition in ASC() or DESC() respectively. If multiple conditions are given, then they are applied in turn until one gives the indication of the ordering.

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

SELECT ?name
WHERE { ?x foaf:name ?name }
ORDER BY ?name

PREFIX     :    <http://example.org/ns#>
PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
PREFIX xsd:     <http://www.w3.org/2001/XMLSchema#>     

SELECT ?name
WHERE { ?x foaf:name ?name ; :empId ?emp }
ORDER BY DESC(?emp)

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

SELECT ?name
WHERE { ?x foaf:name ?name ; :empId ?emp }
ORDER BY ?name DESC(?emp)

Using ORDER BY on a solution sequence for a result form other than SELECT has no direct effect because only SELECT returns a sequence of results. In combination with LIMIT and OFFSET, it can be used to return partial results.

An ordering condition need not give a total ordering of a solution sequence.

The "<" operator (see the Operator Mapping Table) defines the relative order of pairs of numerics, xsd:dateTimes and xsd:strings. SPARQL defines a fixed, arbitrary order between some kinds of RDF terms that would not otherwise be ordered. This arbitrary order is necessary to provide slicing of query solutions by use of LIMIT and OFFSET.

1. (Lowest) no value assigned to the variable or expression in this solution.
2. Blank nodes
3. IRIs
4. RDF literals
5. A plain literal before an RDF literal with type xsd:string of  the same lexical form.

IRIs are ordered by comparing the character strings making up each IRI.

If the ordering criteria do not specify the order of values, then the ordering in the solution sequence is undefined.

Ordering a sequence of solutions always results in a sequence with the same number of solutions in it, even if the ordering criteria does not differentiate between two solutions.

10.1.4 LIMIT

The LIMIT form puts an upper bound on the number of solutions returned. If the number of actual solutions is greater than the limit, then at most the limit number of solutions will be returned.

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

SELECT ?name
WHERE { ?x foaf:name ?name }
LIMIT 20

A limit of 0 would cause no results to be returned. A limit may not be negative.

10.1.5 OFFSET

OFFSET causes the solutions generated to start after the specified number of solutions. An OFFSET of zero has no effect.

The order in which solutions are returned is initially undefined. Using LIMIT and OFFSET to select different subsets of the query solutions will not be useful unless the order is made predictable by using ORDER BY.

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

SELECT  ?name
WHERE   { ?x foaf:name ?name }
ORDER BY ?name
LIMIT   5
OFFSET  10

10.2 Selecting Variables

The SELECT form of results returns the variables directly. The syntax SELECT * is an abbreviation that selects all of the named variables.

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

_:a    foaf:name   "Alice" .
_:a    foaf:knows  _:b .
_:a    foaf:knows  _:c .

_:b    foaf:name   "Bob" .

_:c    foaf:name   "Clare" .
_:c    foaf:nick   "CT" .

PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
SELECT ?nameX ?nameY ?nickY
WHERE
  { ?x foaf:knows ?y ;
       foaf:name ?nameX .
    ?y foaf:name ?nameY .
    OPTIONAL { ?y foaf:nick ?nickY } 
  }

Results can be thought of as a table or result set, with one row per query solution. Some cells may be empty because a variable is not bound in that particular solution.

Result sets can be accessed by the local API but also can be serialized into either XML or an RDF graph. The SPARQL Query Results XML Format form of this result set gives:

<?xml version="1.0"?>
<sparql
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:xs="http://www.w3.org/2001/XMLSchema#"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://www.w3.org/2005/sparql-results#" >
  <head>
    <variable name="nameX"/>
    <variable name="nameY"/>
    <variable name="nickY"/>
  </head>
  <results>
    <result>
      <binding name="nameX">
        <literal>Alice</literal>
      </binding>
      <binding name="nameY">
        <literal>Bob</literal>
      </binding>
      <binding name="nickY">
        <unbound/>
      </binding>
    </result>
    <result>
      <binding name="nameX">
        <literal>Alice</literal>
      </binding>
      <binding name="nameY">
        <literal>Clare</literal>
      </binding>
      <binding name="nickY">
        <literal>CT</literal>
      </binding>
    </result>
  </results>
</sparql>

10.3 Constructing an Output Graph

The CONSTRUCT result form returns a single RDF graph specified by a graph template. The result is an RDF graph formed by taking each query solution in the solution sequence, substituting for the variables into the graph template and combining the triples into a single RDF graph by set union.

If any such instantiation produces a triple containing an unbound variable, or an illegal RDF construct (such as a literal in subject or predicate position), then that triple is not included in the RDF graph, and a warning may be generated. The graph template may contain ground or explicit triples, that is, triples with no variables, and these also appear in the RDF graph returned by the CONSTRUCT query form.

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

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

PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
PREFIX vcard:   <http://www.w3.org/2001/vcard-rdf/3.0#>
CONSTRUCT   { <http://example.org/person#Alice> vcard:FN ?name }
WHERE       { ?x foaf:name ?name }

10.3.1 Templates with Blank Nodes

A template can create an RDF graph containing blank nodes. The blank node labels are scoped to the template for each solution. If the same label occurs twice in a template, then there will be one blank node created for each query solution but there will be different blank nodes across triples generated by different query solutions.

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

_:a    foaf:givenname   "Alice" .
_:a    foaf:family_name "Hacker" .

_:b    foaf:firstname   "Bob" .
_:b    foaf:surname     "Hacker" .

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

CONSTRUCT { ?x  vcard:N _:v .
            _:v vcard:givenName ?gname .
            _:v vcard:familyName ?fname }
WHERE
 {
    { ?x foaf:firstname ?gname } UNION  { ?x foaf:givenname   ?gname } .
    { ?x foaf:surname   ?fname } UNION  { ?x foaf:family_name ?fname } .
 }  

The use of variable ?x in the template, which in this example will be bound to blank nodes (which have labels _:a and _:b in the data) causes different blank node labels (_:v1 and _:v2) as shown by the results.

10.3.2 Accessing Graphs in the RDF Dataset

Using CONSTRUCT it is possible to extract parts or the whole of graphs from the target RDF dataset. This first example returns the graph (if it is in the dataset) with IRI label http://example.org/aGraph; otherwise, it returns an empty graph.

CONSTRUCT { ?s ?p ?o } WHERE { GRAPH <http://example.org/aGraph> { ?s ?p ?o } . }

The access to the graph can be conditional on other information.  Suppose the default graph contains metadata about the named graphs in the dataset, then a query like the following one can extract one graph based on information about the named graph:

PREFIX  dc: <http://purl.org/dc/elements/1.1/>
PREFIX app: <http://example.org/ns#>
CONSTRUCT { ?s ?p ?o } WHERE
 {
   GRAPH ?g { ?s ?p ?o } .
   { ?g dc:publisher <http://www.w3.org/> } .
   { ?g dc:date ?date } .
   FILTER ( app:customDate(?date) > "2005-02-28T00:00:00Z"^^xsd:dateTime ) .
 }

where app:customDate identified an extension function to turn the data format into an xsd:dateTime RDF Term.

10.3.3 Solution Modifiers and CONSTRUCT

The solution modifiers of a query affect the results of a CONSTRUCT query. In this example, the output graph from the CONSTRUCT template is formed from just 2 of the solutions from graph pattern matching. The query outputs a graph with the names of the people with the top 2 sites, rated by hits.  The triples in the RDF graph are not ordered.

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix site: <http://example.org/stats#> .

_:a foaf:name "Alice" .
_:a site:hits 2349 .

_:a foaf:name "Bob" .
_:a site:hits 105 .

_:a foaf:name "Eve" .
_:a site:hits 181 .

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX site: <http://example.org/stats#>

CONSTRUCT { [] foaf:name ?name }
WHERE
{ [] foaf:name ?name ;
     site:hits ?hits .
}
ORDER BY ?hits
LIMIT 2

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:x foaf:name "Bob" .
_:y foaf:name "Alice" .

10.4 Descriptions of Resources

The DESCRIBE form returns a single result RDF graph containing RDF data about resources. This data is not prescribed by a SPARQL query, where the query client would need to know the structure of the RDF in the data source, but, instead, is determined by the SPARQL query processor.

The query pattern is used to create a result set. The DESCRIBE form takes each of the resources identified in a solution, together with any resources directly named by IRI, and assembles a single RDF graph by taking a "description" from the target knowledge base. The description is determined by the query service.

If a data source has no information about a resource, no RDF triples are added to the result graph but the query does not fail.

• The working group adopted DESCRIBE without reaching consensus. The objection was that the expectations around DESCRIBE are very different from CONSTRUCT and SELECT, and hence it should be specified in a separate query language. If you have input to this aspect of the SPARQL that the working group has not yet considered, please send a comment to public-rdf-dawg-comments@w3.org.

10.4.1 Explicit IRIs

The DESCRIBE clause itself can take IRIs to identify the resources. The simplest DESCRIBE query is just an IRI in the DESCRIBE clause:

DESCRIBE <http://example.org/>

10.4.2 Identifying Resources

The resources can also be a query variable from a result set. This enables description of resources whether they are identified by IRI or by blank node in the dataset:

PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
DESCRIBE ?x
WHERE    { ?x foaf:mbox <mailto:alice@org> }

The property foaf:mbox is defined as being an inverse function property in the FOAF vocabulary. If treated as such, this query will return information about at most one person. If, however, the query pattern has multiple solutions, the RDF data for each is the union of all RDF graph descriptions.

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

More than one IRI or variable can be given:

PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
DESCRIBE ?x ?y <http://example.org/>
WHERE    {?x foaf:knows ?y}

10.4.3 Descriptions of Resources

The RDF returned is the determined by the information publisher. It is the useful information the service has about a resource. It may include information about other resources: the RDF data for a book may also include details about the author.

A simple query such as

PREFIX ent:  <http://org.example.com/employees#> 
DESCRIBE ?x WHERE { ?x ent:employeeId "1234" }

might return a description of the employee and some other potentially useful details:

@prefix foaf:   <http://xmlns.com/foaf/0.1/> .
@prefix vcard:  <http://www.w3.org/2001/vcard-rdf/3.0> .
@prefix exOrg:  <http://org.example.com/employees#> .
@prefix rdf:    <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix owl:    <http://www.w3.org/2002/07/owl#>

_:a     exOrg:employeeId    "1234" ;
        foaf:mbox_sha1sum   "ABCD1234" ;
        vcard:N
         [ vcard:Family       "Smith" ;
           vcard:Given        "John"  ] .

foaf:mbox_sha1sum  rdf:type  owl:InverseFunctionalProperty .

which includes the blank node closure for the vcard vocabulary vcard:N. For a vocabulary such as FOAF, where the resources are typically blank nodes, returning sufficient information to identify a node such as the InverseFunctionalProperty foaf:mbox_sha1sum as well information which as name and other details recorded would be appropriate. In the example, the match to the WHERE clause was returned but this is not required.

10.5 Asking "yes or no" questions

Applications can use the ASK form to test whether or not a query pattern has a solution. No information is returned about the possible query solutions, just whether the server can find one or not.

@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/>
ASK  { ?x foaf:name  "Alice" }

yes

The SPARQL Query Results XML Format f