SPARQL Query Language for RDF

Appendices

• A SPARQL Grammar
• B References
• C Change Log

See also:

• The protocol document
• XML result format
• DAWG Test Cases
• Slide set

Issues

DAWG issues list

@@ToDo@@ Tidy up HTML

@@ToDo@@ Ensure markup around examples enables XSLT extraction.

@@ToDo@@ Make sure there are no @@ToDo@@ in the document.

1 Introduction

An RDF graph is a set of triples, each triple consisting of a subject, a predicate and an object, as defined in RDF Concepts and Abstract syntax. 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. When used across networks, the companion SPARQL Protocol for RDF document [11] describes a remote access protocol.

1.1 Document Conventions

When undeclared, the prefixes below stand in place of the URIs given:

2 Making Simple Queries

The SPARQL query language is based around matching graph patterns. The simplest graph patterns are triple patterns, which are 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 describe how other graph patterns can be built using the graph operators OPTIONAL and UNION, be grouped together and also how queries can extract information from more than one graph. It is also possible to restrict the values allowed in matching a pattern.

In this section, we cover simple triple patterns, basic graph patterns and the SPARQL syntax related to these.

2.1 Writing a Simple Query

The example below shows a SPARQL query to find the title of a book from the information in an RDF graph. The query consists of two parts, the SELECT clause and the WHERE clause. The SELECT clause identifies the variables of interest to the application, 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:

Query Term Syntax

The terms delimited by "<>" are relative URI references [RFC 3986]. After parsing, these are resolved to give URIs. The term URI in this document refers to URIs after resolution.

The query terms delimited by double quotes ("") are literals which, following Turtle [15]syntax are a string, in quotes, an optional language tag, introduced with '@', or an optional datatype URI, introduced by '^^'. Single quotes ('') are also allowed instead of double quotes. As a convenience, integers can be directly written and are interpreted as typed literals of datatype xsd:integer; floating point numbers can also be directly written and are interpreted as xsd:double. Boolean values of type xsd:boolean literals 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 name is used. Variables are indicated by '?'; the '?' does not form part of the variable. '$' is an alternative to '?' to help where systems use '?' as a substitution character. In a query, $abc and ?abc are the same variable.

Because URIs can be long, SPARQL provides an abbreviation mechanism. Prefixes can be defined and a QName-like syntax [14] provides shorter forms. Prefixes may be used anywhere after they are declared; redefining a prefix causes the new definition to be used from that point in the syntax. The base URI for the resolution of relative URIs [RFC 3869] can be explicitly declared with the BASE keyword.

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

Examples of Query Syntax

The following examples are three ways to 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/shelf/>
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 any of the previous ones and will give the same results when applied to the same data.

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

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/shelf/> .
:book1  dc:title  "SPARQL Tutorial" .

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 bindings in results in tabular form so 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 RDF, in XML with the SPARQL Variable Binding Results XML Format [16] and also in forms specific to implementation APIs.

2.2 Basic Graph Patterns

The building blocks of queries are triple patterns. Syntactically, a SPARQL triple pattern is a subject, predicate and object. 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.

Definition: RDF Term

An RDF Term is anything that can occur in the RDF data model.
let RDF-U be the set of all RDF URIs
let RDF-L be the set of all RDF Literals
let RDF-B be the set of all blank nodes

The set of RDF Terms, RDF-T, is RDF-U union RDF-L union RDF-B.

Definition: Query Variable

Let V be the set of all query variables. V and RDF-T are disjoint.

An RDF triple contains three components:

• the subject, which is an RDF URI reference or a blank node
• the predicate, which is an RDF URI reference
• the object, which is an RDF URI reference, a literal or a blank node

Definition: Graph Pattern

A Graph Pattern is one of:

• 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
• Alternate graph pattern, where two or more possible patterns are tried
• Patterns on Named Graphs, where patterns are matched against named graphs

Each of these pattern types is defined in sections of this document.

In SPARQL, a triple pattern is similar to an RDF triple but with the change that any component can be a query variable.

Definition: Triple Pattern

The set of triple patterns is
    (RDF-T union V) x (RDF-U union V) x (RDF-T union V)

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

Definition: Basic Graph Pattern

A Basic Graph Pattern is a set of Triple Patterns.

An RDF graph is a set of RDF triples. In the same way, a SPARQL Basic Graph Pattern is a set of Triple Patterns.

Definition: Query Pattern

A query has one main graph pattern. It is called the Query Pattern.

2.3 Matching of Basic Graph Patterns

Definition: Substitution

Substitution is a function from a subset of the set of variables, V, the domain of the substitution, dom(S), to the set of RDF terms, T.

We write S(v) for the substitution of variable.

Definition: Pattern Instance

If S is a substitution then the result of replacing every v in a basic graph pattern P by S(v) is a pattern instance of P, written S(P).

@@ToDo@@Check used

For example, the query:

@@ToDo@@Change example to "A foaf:knows A"

SELECT ?x ?v WHERE { ?x ?x ?v }

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

rdf:type rdf:type rdf:Property .

with substitution:

It does not match the graph of a single triple:

rdfs:seeAlso rdf:type rdf:Property .

because the variable x would need to be both rdfs:seeAlso and rdf:type.

Definition: Pattern Solution

A Pattern Solution of Graph Pattern GP on graph G is any substitution S such that S(GP) is a subgraph of G.

Where it is clear, a pattern solution is simply called a solution.

2.4 Examples of Basic Graph Patterns

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

For a basic graph pattern to match, there must be a substitution where each of the triple patterns matches with the same substitution.

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. No SPARQL query will be able to identify that blank node by the label used in the serialization.

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

Definition: Query Solution

A Query Solution is a Pattern Solution for the Query Pattern. A substitution in a query solution only contains variables mentioned in the query.

Definition: Query Results

The Query Results, for a given graph pattern GP on graph G, is written R(GP,G), and is the set of all query solutions S such that S is a solution for GP on G.

R(GP, G) may be the empty set.

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 muts be bound in every solution.

2.6 Blank Nodes

Blank Nodes and Queries

A blank node can appear in a query pattern. It behaves as a variable, although it can not be mentioned in the query result form or anyplace else outside a graph pattern.

Blank nodes in queries are distinct from all blank nodes in the data. A blank node in a graph pattern does not match a blank node in the data by blank node label.

Blank Nodes and Query Results

In the results of queries, the presence of blank nodes can be indicated by labels in the serializations of 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.

@@ToDo@@Tie to RDF graph form - or don't mention

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.7 Other Syntactic Forms

SPARQL uses a "Turtle-like" syntax for writing basic graph patterns, with the addition of named variables. 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 common subject can be written so that the subject is written once, and used for more than one triple pattern using 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 used to form triple patterns with a blank node for subject.

The following two forms:

[ :p "v" ] .

[] :p "v" .

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

_: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 short for resource rdf:nil or <http://www.w3.org/1999/02/22-rdf-syntax-ns#nil>.

(1 ?x 3)

is short for:

  _: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 short for rdf:type.

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

  ?x    rdf:type  :Class1 .
  _:b0  rdf:type  :myClass .
  _: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, delimited by "", followed by an optional language tag (indicted by '@') or optional datatype (indicated by '^^'). There are convenience forms for numeric-types literals which are of type xsd:integer, xsd:double or  xsd:boolean.

Examples of literal syntax in SPARQL:

• "chat"
• "chat"@fr
• "xyz"^^<http://example.org/ns/userDatatype>
• "abc"^^myNS:myDataType
• 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 :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 URI both match exactly.

SELECT ?x WHERE { ?x ?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 :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".

Definition: Value Constraint

A graph pattern may involve a value constraint, which is a boolean-valued expression of variables and RDF Terms that restricts query solutions.

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. SPARQL defines a set of functions & operations (sections 11.1 and 11.2) that all implementations must provide. In addition, there is an extension mechanism (section 11.3) for operations that are specific to an application domain or kind of data.

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.

• Open: whether to allow "foo"@?v or ?v@fr or ?v^^xsd:integer or "foo"^^?v
  One way to address this is to allow expressions in SELECT

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

Definition: Group Graph Pattern Matching

A graph pattern GP may be a set of graph patterns, GP_i. A solution of Graph Pattern GP on graph G is any solution S such that for each element GP_i of GP, S is a solution of GP_i.

Syntactically, a group of patterns is delimited with {}s (that is, braces).

For any solution, the same variable is given the same value everywhere in the set of graph patterns. A Basic Graph Pattern is, as described above, 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 is a solution to each element of a 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
       }

using the abbreviation for a common subject between triple patterns.

4.2 Unbound variables

@@ToDo@@Discussion of unbound variables.

5 Including Optional Values

Basic graph patterns allow application to queries where the whole of the 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 so 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 have the solution rejected just because that 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:

OPTIONAL { ?s ?p ?o }

Data:

@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  rdf:type        foaf:Person .
_:a  foaf:name       "Alice" .
_: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 }
       }

With the data above, the query result is:

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

This query finds the names of people in the data, and, if there is a triple with predicate mbox and same subject, retrieves 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 block must match for the optional to add to the query solution.

5.2 Constraints in Optional Blocks

Constraints can be given in optional blocks 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 block did not lead to a solution involving the variable price.

5.3 Multiple Optional Blocks

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

Data:

@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: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 and so defines one or more pattern solutions,  or gives an empty pattern solution but does not cause matching to fail overall, leaving existing solutions in the query results.

Definition: Optional Matching

Given graph pattern GP1, and graph pattern GP2, Opt(GP1, GP2) is the optional match of GP2 of graph G, given GP1.

Let GP = (GP1 union GP2) then S is a solution of Opt(GP1, GP2) if

S is a solution for a match of GP on G, or else S is a solution for GP1 and S is not a solution for GP.

S in R(Opt(GP1, GP2), G) if:
   S in R(GP, G)
or
  S not in R(GP,G) and S in R(GP1, G).

This definition can introduce ordering issues in queries - this is discussed in section "Query Execution Ordering".

5.5 Nested Optional Blocks

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

Data:

@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#> .
@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 gets that as well.

By nesting the optional access to vcard:Family, the query only reaches these if there is a vcard:N predicate. It is possible to expand out optional blocks to remove nesting at the cost of duplication of expressions. Here, the expression is a simple triple pattern on vcard:N but it could be a complex graph match 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 query 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.

6.2 Blocks in UNION Patterns

The UNION operator takes group 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.3 Alternative Matching – Formal Definition

Definition: Union Pattern Matching

Given graph patterns GP1 and GP2, and graph G, then a union pattern solution of GP1 and GP2 is any pattern solution S such that either S(GP1) matches G or S(GP2) matches G with substitution S.

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 made against an RDF Dataset which represents such a collection of graphs. Different parts of the query are matched against different graphs as described in the next section. There is one graph, the background graph, which does not have a name, and zero or more named graphs, identified by URI reference.

Definition: RDF Dataset

An RDF dataset is a set = { G, (u₁, G₁), (u₂, G₂), . . . (u_n, G_n) } where G and each G_i are graphs, and each u_i is a URI. Each u_i is distinct.

G is called the background graph. G_i are named graphs.

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

7.1 Examples of RDF Datasets

The definition of RDF Dataset does not restrict the relationships of named and background graphs. Two useful arrangements are:

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

Example 1:

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

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

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

In this example, the background graph contains the publisher names of two named graphs. The triples in the named graphs are not visible in the background graph and, thought of as the default knowledge base, the application is not directly trusting the information in the named graphs.

Example 2:

RDF data can be combined by RDF merge of graphs so the background graph can be made to include the RDF merge of some or all of the information in the named graphs. Because this information is now being published without qualification, and a query application accepts as coming from the publisher, not just from a source 9a named graph) that the publisher incorporated.

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 background graph, relabelling blank nodes to keep them distinct. Doing this is trusting the contents of the named graphs. An implementation can efficiently provide datasets of this form without duplicating stored triples.

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

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

8 Querying the Dataset

When querying a collection of graphs, the GRAPH keyword allows access to the URIs naming the graphs in the RDF Dataset, or restricts a graph pattern to be applied to a specific named graph.

The following two graphs will be used in examples:

# 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:age      32 .
_:b  rdfs:seeAlso  <http://example.org/foaf/bobFoaf> .

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

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

_:1  foaf:mbox     <mailto:bob@work.example> .
_:1  rdfs:seeAlso  <http://example.org/foaf/bobFoaf> .
_:1  foaf:age 35 .
<http://example.org/foaf/bobFoaf>
     rdf:type      foaf:PersonalProfileDocument .

8.1 Accessing Graph Labels

Access to the graph labels of the collection of graphs being queried is by variable in the GRAPH expression.

The query below matches the pattern on each of the named graphs in the dataset and forms solutions which have the src variable bound to URIs of the graph being matched. The pattern part of the GRAPH only matched triples in a single named graph in the same way that a graph pattern matches the background graph when there is no GRAPH clause being applied.

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

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

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

8.2 Restricting by Graph Label

The query can restrict the matching applied to a specific graph by supplying the graph label.  This query looks for the age as the graph http://example.org/foaf/bobFoaf asserts it.

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

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

which yields a single solution:

8.3 Restricting via Query Pattern

A variable used in the GRAPH clause may also be used elsewhere in the query, whether in another GRAPH clause or in a graph pattern matched against the background graph in the dataset.

This can be used to find information in one part of a query, and using it to restrict the graphs matched in another part of the query. The query below uses the graph with URI http://example.org/foaf/aliceFoaf to find the profile document for Bob; it then matches another pattern against that graph. Note that the pattern in the second GRAPH part finds the blank node for the person with the same mail box (given by variable mbox) as found in the first GRAPH part, 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  rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> 
PREFIX  rdfs:  <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?mbox ?age ?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:age ?age 
  }
}    

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

8.4 GRAPH and a background graph

Query patterns can involve both the background 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 a URI by the local system. The graphs are nearly the same but the email address for "Bob" has changed.

The background 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 URI by the system. The RDF dataset consists of two, named graphs and the information about them.

RDF Dataset:

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

<urn:x-local:graph1> dc:publisher "Bob" .
<urn:x-local:graph1> dc:date "2004-12-06"^^xsd:date .

<urn:x-local:graph2> dc:publisher "Bob" .
<urn:x-local:graph2> dc:date "2005-01-10"^^xsd:date .

# Graph: locally allocated URI: urn:x-local: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 URI: urn:x-local: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 URI for the date datatype has been abbreviated in the results for convenience.

8.5 Definition for GRAPH

Definition: DataSet Graph Pattern

If D is a dataset {G, (<u1> G1), ...}, and P is a graph pattern then S is a pattern solution of GRAPH(g, P) if:

g is a URI where g = <u_i> for some i, and S is pattern solution of P on G_i or g is a variable, S maps the variable g to <u_i> and S is a pattern solution of P on G_i.

N Specifying RDF Datasets

This section has been added back into the document because the Working Group is now considering putting some language constructs to specify datasets.  As such, this text has been added but not fully integrated and may be inconsistent with the rest of the document.  Comments about the design are especially welcome.

The FROM clause gives a URI that the query processor can use to create the background graph and the FROM NAMED clause can be used to specify named graphs.

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

N.1 Specifying the Background Graph

The FROM clause a single URIs that indicates the graph to use as the background 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 first example, there is a single background graph:

# Background graph
@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 }

N.2 Specifying Named Graphs

A query can supply URIs for the named graphs in the RDF Dataset using the FROM NAMED clause.  Each URI 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 } }

N.3 Combining FROM and FROM NAMED

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

@@ToDo@@ Example based on example 1 section 7

9 Query Execution and Ordering

Outline : help in wording appreciated.

Examples

Examples of where is matters: OPTIONALs, and FILTERS

Evaluation Rules : Definitions

For pattern P, let var(P) be the variables mentioned
   by P or any of its sub patterns.

For pattern P, let var-u(P) be the variables mentioned
   by P or any of its sub patterns such that x is in var-u(P)
   and P is a union expression, then x occurs all sub-patterns.

For group GP = { P1 or C1, (P2 or C2), ... (CN or PN) }
   P pattern
   C constraint

Fixed patterns: basic graph patterns and UNIONS

Recursive definition for nested patterns

Evaluation rule: Optional-1

Informally, this rule states that optional patterns must be executed as if it came after any basic graph patterns, where there is a common variable.

If variable x in var(Pi), and Pi is an optional
and x in var(Pj) and Pj is a triple pattern or union
then
  j < i

Evaluation rule: Optional-2

Informally, this rule states that there can't be two optionals with a common variable, if that variable does not occur in a basic graph pattern as well.

If variable x in var(Pi), and Pi is an optional
and x in var-u(Pj) and Pj an optional, i != j
then x must occur in some fixed Pk 

By rule opt 1, k < i and j.

Evaluation rule: Constraint

Informally, this rule states that constraints are evaluated after variable are assigned values.

If Ci is a constraint expression, variable x in var(Ci)
and x in var(Pj)
then
  j < i

10 Result Forms

SPARQL has a number of result forms for returning results. 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. Formats for the result set can be in XML or RDF/XML (see the result format document)

@@ToDo@@Links to result format documents

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 whether a query pattern matches or not.

10.1 Solution Sequences and Result Forms

Query patterns generate a number of solutions and each solution is a set of variables and associated RDF terms. These solutions are passed through a stage to control the solution sequence, then passed to the result form for the query.

The controls on the sequence of solutions are:

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

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

Projection

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

Definition: Projection

For a substitution S and a finite set of variables VS,
project(S, VS) = { (v, S[v]) | v in VS }

For a query solution Q project(Q, VS) is { project(S, VS) | S in Q }

For a set QS of query solutions, project(QS, VS) is { project(Q, V) | Q in QS }

DISTINCT

The DISTINCT modifier applies only for the SELECT result form.

@@ToDo@@ could make sense, with LIMIT and OFFSET, in CONSTRUCT and DESCRIBE

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. Thought of as a table, each row is different.

@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/OFFSET are specified, then duplicates are eliminated before the limit or offset is applied.

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, not an RDF graph. However, in combination with LIMIT and OFFSET, it can be used to return partial results.

Ordering by expression

When ordering a solution sequence involves an expression, it is possible that the ordering conditions do no give a completely determined ordering for the sequence. In this case the ordering of solutions that are not distinguished, is not determined.

Ordering by RDF term

If an ordering condition is a variable, SPARQL defines an 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 in this solution.
2. Blank nodes
3. URIs
4. RDF literals
5. A plain literal before an XSD string with the same lexical form.

RDF Literals are compared with the "<" operator (see below) where possible.

If the ordering criteria do not specify the order of values, then the ordering in the solution sequence is undefined. However, an implementation must consistently impose the same order so that applying LIMIT/OFFSET will not miss any solutions.

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.

Check whether xsd:string and plain literals are comparable with "<".

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

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 undefined so using LIMIT and OFFSET to select different subsets of the query solutions will given not be useful unless the order is made predictable by ensuring ordered results 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 which Variables to Return

The SELECT form of results returns the variables directly. The syntax SELECT * is shorthand for "select all 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 } 
  }

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

<?xml version="1.0"?>
<sparql
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
  xmlns="http://www.w3.org/2001/sw/DataAccess/rf1/result" >
  <head>
    <variable name="nameX"/>
    <variable name="nameY"/>
    <variable name="nickY"/>
  </head>
  <results>
    <result>
      <nameX>Alice</nameX>
      <nameY>Clare</nameY>
      <nickY>CT</nickY>
    </result>
    <result>
      <nameX>Alice</nameX>
      <nameY>Bob</nameY>
      <nickY bound="false"/>
    </result>
  </results>
</sparql>

And in RDF/XML, using the Variable Binding Results XML Format [16] gives:

<rdf:RDF
    xmlns:rs="http://www.w3.org/2001/sw/DataAccess/tests/result-set#"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rs:ResultSet>
    <rs:resultVariable>nickY</rs:resultVariable>

    <rs:resultVariable>nameX</rs:resultVariable>
    <rs:resultVariable>nameY</rs:resultVariable>
    <rs:solution rdf:parseType="Resource">
      <rs:binding rdf:parseType="Resource">
        <rs:variable>nameX</rs:variable>
        <rs:value>Alice</rs:value>
      </rs:binding>
      <rs:binding rdf:parseType="Resource">
        <rs:value>CT</rs:value>
        <rs:variable>nickY</rs:variable>
      </rs:binding>
      <rs:binding rdf:parseType="Resource">
        <rs:value>Clare</rs:value>
        <rs:variable>nameY</rs:variable>
      </rs:binding>
    </rs:solution>
   <rs:solution rdf:parseType="Resource">
      <rs:binding rdf:parseType="Resource">
        <rs:variable>nameX</rs:variable>
        <rs:value>Alice</rs:value>
      </rs:binding>
      <rs:binding rdf:parseType="Resource">
        <rs:value>Bob</rs:value>
        <rs:variable>nameY</rs:variable>
      </rs:binding>
    </rs:solution>
 </rs:ResultSet>
</rdf:RDF>

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

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.

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

Templates with Blank Nodes

A template can create an RDF graph containing blank nodes. The labels are scoped to the template for each solution. If two such prefixed names share the same label in the 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, causes an equivalent graph to be constructed with a different blank node as shown by the document-scoped label.

Accessing Graphs in the RDF Dataset

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

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

The access to the graph can be conditional on other information.  Suppose the background graph contains metadata about the named graphs in the dataset then a query like this next 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:myDate(?date) > "2005-02-28T00:00:00Z"^^xsd:dateTime .
 }

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

10.4 Descriptions of Resources

The DESCRIBE form returns a single 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 URI, and assembles a single RDF graph by taking a "description" from the target knowledge base. The description is determined by the query processor implementation and should provide a useful description of the resource, where "useful" is left to nature of the information in the data source.

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.

Explicit URIs

The DESCRIBE clause itself can take URIs to identify the resources. The simplest query is just a URI in the DESCRIBE clause:

DESCRIBE <http://example.org/>

Identifying Resources

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

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 so, 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 URI or can be given:

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

Descriptions of Resources

The RDF returned is the choice of the deployment and may be dependent on the query processor implementation, data source and local configuration.  It should be the useful information the server has (within security matters outside of SPARQL) about a resource. It may include information about other resources: the RDF data for a book may also include details of the author.

A simple query such as

PREFIX ent:  <http://myorg.example/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 myOrg:   <http://myorg.example/employees#> .

_:a     myOrg: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.4 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/> .
@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: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

@@ToDo@@ Align results to XML results format or some result form for ASK

on the same data, the following returns no match because Alice's mbox is not as described.

PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
ASK  { ?x foaf:name  "Alice" ;
          foaf:mbox  <mailto:alice@work.example> }

no

11 Testing Values

SPARQL expressions are constructed according to the grammar and provide access to named functions and syntactically constructed operations. The operands of these functions and operators are the subset of XML Schema DataTypes {xsd:string, xsd:decimal, xsd:double, xsd:dateTime} and types derived from xsd:decimal. The SPARQL operations are listed in table 11.1 and are associated with productions in the grammar. In addition, SPARQL imports a subset of the XPath casting functions, listed in table 11.2, which are invokable by name within a SPARQL query. These functions and operators are taken from the XQuery 1.0 and XPath 2.0 Functions and Operators [17].

As described above, RDF Terms are made of URIs (URI References), Literals and Blank Nodes. RDF Literals may have datatypes in the instance data:

@prefix a:          <http://www.w3.org/2000/10/annotation-ns#> .
@prefix dc:         <http://purl.org/dc/elements/1.1/> .

_:a   a:annotates   <http://www.w3.org/TR/rdf-sparql-query/> .
_:a   dc:created    "2004-12-31T19:00:00-05:00" .

_:b   a:annotates   <http://www.w3.org/TR/rdf-sparql-query/> .
_:b   dc:created    "2004-12-31T19:01:00-05:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> .

The first dc:created arc has no type information. The second is tagged with the type xsd:dateTime. SPARQL operators compare the values of types literals:

PREFIX a:      <http://www.w3.org/2000/10/annotation-ns#>
PREFIX dc:     <http://purl.org/dc/elements/1.1/>
PREFIX xsd:    <http://www.w3.org/2001/XMLSchema#>

SELECT ?annot
WHERE { ?annot  a:annotates  <http://www.w3.org/TR/rdf-sparql-query/> .
        ?annot  dc:created   ?date .
        FILTER ?date < xsd:dateTime("2005-01-01T00:00:00Z") }

A significant of RDF data has untyped literals. Literals may be cast to typed literals to use the SPARQL operators.

...
        FILTER xsd:dateTime(?date) < xsd:dateTime("2005-01-01T00:00:00Z") ...

Namespaces:

The namespace for XPath functions that are directly available by name is http://www.w3.org/2004/07/xpath-functions. The associated namespace prefix used in this document is fn:. XPath operators are named with the prefix op:, XML Schema datatypes with the prefix op:, and types of RDF terms with the prefix r:. SPARQL operators are named with the prefix sop:.

11.1 Operand Data Types

SPARQL defines a subset of the XPath functions and operators with operands of the following XML Schema datatypes:

• xs:string
• xs:double
• xs:float
• xs:decimal
• xs:integer
• xs:dateTime

In addition, SPARQL introduces additional operators which operate on RDF terms. RDF terms are identified by r:term and the constituant subclasses:

• r:URI
• r:Literal
• r:bNode

11.1.1 Type Promotion

XPath defines a set of Numeric Type Promotions. Numeric operators are defined for the following three primitive XML Schema numeric types:

• xs:double
• xs:float
• xs:decimal

These invoke XQuery's numeric type promotion to cast function arguments to the appropriate type. In summary: each of the numeric types is promoted to any type higher in the above list when used as an argument to function expecting that higher type. When an argument is promoted, the value is cast to the expected type. For instance, a "7"^^xs:decimal will be converted to an "7.0E0"^^xs:double when passed to an argument expecting an xs:double. Promotion does not change the bindings of variables.

The operators defined below that take numeric arguments expect all arguments to be the same type. This is accomplished by promoting the argument with the lower type to the same type as the other argument. For example, "7"^^xs:decimal + "6.5"^^xs:float would call op:numeric-add("7"^^xs:float, "6.5"^^xs:float). In addition, any r:Literal may be cast to xs:string or xs:numeric when used as an argument to an operator expecting that type.

XML Schema [] defines a set of types derived from decimal: integer; nonPositiveInteger; negativeInteger; long; int; short; byte; nonNegativeInteger; unsignedLong; unsignedInt; unsignedShort; unsignedByte and positiveInteger. These are all treated as decimals for computing effective boolean values. SPARQL does not specifically require integrity checks on derived subtypes. SPARQL has no numeric type test operators so the distinction between a primitive type and a type derived from that primitive type is unobservable.

11.2 SPARQL Functions and Operators

SPARQL provides a subset of the functions and operators defined by XQuery Operator Mapping. XQuery 1.0 section 2.2.3 Expression Processing describes the invocation of XPath functions. The following rules accommodate the differences in the data and execution models between XQuery and SPARQL:

• Unlike XPath/XQuery, SPARQL functions do not process node sequences. When interpreting the semantics of XPath functions, assume that each argument is a sequences of a single node.
• Functions invoked with an argument of the wrong type will produce a type error.
• Any expression other than value disjunction (||) that encounters a type error will produce a type error.
• A value disjunction that encounters a type error on only one branch will return the result of evaluating the other branch.
• A value disjunction that encounters type errors on both branches will produce a type error.
• A FILTER will eliminate any solutions that yield an effective boolean value of false or produce a type error.

11.2.1 Invocation

SPARQL defines a syntax for invoking functions and operators on a list of arguments. These are invoked as follows:

• Arguments expressions are evaluated, producing argument values. The order of argument evaluation is not defined.
• For functions and operators where the expected type is specified as boolean, the effective boolean value (defined in section 11.2.1.1) is calculated.
• Numeric arguments are promoted as necessary to fit the expected types for that function or operator.
• The function or operator is invoked on the argument values.

If any of these steps fails, the invocation generates an error. The effects of type errors are defined in SPARQL Functions and Operators.

11.2.1.1 Effective Boolean Value

When a operand is coerced to xs:boolean through invoking a function that takes a boolean argument, the following rules apply:

The result is TRUE unless any of the following are true:

• The operand is a boolean with a FALSE value.
• The operand is a 0-length untyped RDF literal or xs:string.
• The operand is any numeric type with a value of 0.
• The operand is an xs:double or xs:float with a value of NaN

Table 11.1 Operator Mapping

The SPARQL grammar identifies a set of operators (for instance, &&, *, isUri) used to construct constraints. The following table associates each of these grammatical productions with an operator defined by either the XQuery Operator Mapping or the additional SPARQL operators specified in section 11.2.2.

Some of the operators are associate with nested function expressions, e.g. fn:not(op:numeric-equal(A, B)). Note that per the xpath definitions, fn:not and op:numeric-equal return an error if their argument is an error.

^† fn:string-match requires a collation to define character order and string equivalence. The XQuery 1.0 and XPath 2.0 Functions and Operators [F&O] defines the semantics of fn:string-compare and establishes a default collation. In addition, it identifies a specific collation with a distinguished name, http://www.w3.org/2004/10/xpath-functions/collation/codepoint which provides the ability to compare strings based on code point values. Every implementation of SPARQL must support the collation based on code point values.

11.2.3 Operators introduced in SPARQL

This section defines the operators introduced by the SPARQL Query language. The names of the operators are prefixed with sop:. The examples show the behavior of the operators as invoked by the appropriate grammatical constructs.

11.2.3.1 sop:RDFterm-equal

Returns TRUE if the two arguments are the same RDF term or they are literals known to have the same value. The latter is tested with an XQuery function appropriate to the arguments. This function is overloaded because there is no syntactic way to separate xs:string = xs:string from r:literal = r:literal (or r:uri or r:bNode). I think I'm happy with that. Are you, dear reader?

The following sop:RDFterm-equal example passes the test because the mbox terms are the same RDF term:

 ?u = ?v

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

_:b  foaf:name       "Ms A.".
_:b  foaf:mbox       <mailto:alice@work.example> .

This query finds the people who have multiple foaf:name arcs:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name1 ?name2
 WHERE { ?x foaf:name  ?name1 ;
            foaf:mbox  ?mbox1 .
         ?y foaf:name  ?name2 ;
            foaf:mbox  ?mbox2 .
         FILTER ?mbox1 = ?mbox2 && ?name1 != ?name2
       }

Query result:

In this query for documents that were annotated on new years day (2004 or 2005), the RDF terms are not the same, but have equivalent values:

@prefix a:          <http://www.w3.org/2000/10/annotation-ns#> .
@prefix dc:         <http://purl.org/dc/elements/1.1/> .

_:b   a:annotates   <http://www.w3.org/TR/rdf-sparql-query/> .
_:b   dc:created    "2004-12-31T19:01:00-05:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> .

PREFIX a:      <http://www.w3.org/2000/10/annotation-ns#>
PREFIX dc:     <http://purl.org/dc/elements/1.1/>
PREFIX xsd:    <http://www.w3.org/2001/XMLSchema#>

SELECT ?annotates
WHERE { ?annot  a:annotates  ?annotates .
        ?annot  dc:created   ?date .
        FILTER ?date = xsd:dateTime("2004-01-01T00:00:00Z") || ?date = xsd:dateTime("2005-01-01T00:00:00Z") }

11.2.3.2 sop:bound

Queries with union and optionals may have solutions with some unbound variables. The operator bound tests that a variable has been bound to a value. NaNs and INFs count as defined.

 bound(?v)

Data:

@prefix foaf:        <http://xmlns.com/foaf/0.1/> .
@prefix dc:          <http://purl.org/dc/elements/1.1/> .
@prefix xs:          <http://www.w3.org/2001/XMLSchema#> .

_:a  foaf:name       "Alice".

_:b  foaf:givenname  "Bob" .
_:b  dc:created      "2005-04-04T04:04:04Z"^^xs:dateTime .

This query matches the people with a name and an mbox:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dc:   <http://purl.org/dc/elements/1.1/>
SELECT ?name ?givenName
 WHERE { { ?x foaf:name  ?name } UNION { ?x foaf:givenName ?givenName; dc:created ?created } .
         FILTER bound(?name) || ?created < "2005-01-01T00:00:00Z" }

Query result:

One may test that a graph pattern is not expressed by specifying an optional graph pattern that introduces a variable and testing to see that the variable is not bound. This is called Negation as Failure in logic programming.

This query matches the people with a name but no expressed created:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dc:   <http://purl.org/dc/elements/1.1/>
SELECT ?name
 WHERE { ?x foaf:name  ?name .
         OPTIONAL { ?x dc:created ?created } .
         FILTER !bound(?created) }

Query result:

Because Alice's mbox was known, "Alice" was not a solution to the query.

11.2.3.3 sop:isURI

Returns whether a variable is bound to a URI.

 isURI(?v)

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

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

This query matches the people with a name and an mbox which is a URI:

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

Query result:

11.2.3.4 sop:isBlank

Returns whether a variable is bound to a blank node.

 isBlank(?v)

@prefix a:          <http://www.w3.org/2000/10/annotation-ns#> .
@prefix dc:         <http://purl.org/dc/elements/1.1/> .
@prefix foaf:       <http://xmlns.com/foaf/0.1/> .

_:a   a:annotates   <http://www.w3.org/TR/rdf-sparql-query/> .
_:a   dc:creator    "Alice B. Toeclips" .

_:b   a:annotates   <http://www.w3.org/TR/rdf-sparql-query/> .
_:b   dc:creator    _:c .
_:c   foaf:given    "Bob".
_:c   foaf:family   "Smith".

This query matches the people with a name and an mbox which is a URI:

PREFIX a:      <http://www.w3.org/2000/10/annotation-ns#>
PREFIX dc:     <http://purl.org/dc/elements/1.1/>
PREFIX foaf:   <http://xmlns.com/foaf/0.1/>

SELECT ?given ?family
 WHERE { ?annot  a:annotates  <http://www.w3.org/TR/rdf-sparql-query/> .
         ?annot  dc:creator   ?c .
         OPTIONAL { ?c  foaf:given   ?given ; foaf:family  ?family } .
         FILTER isBlank(?c)
       }

Query result:

In this example, there were two objects of foaf:knows predicates, but only one (_:c) was a blank node.

11.2.3.5 sop:isLiteral

Returns whether the argument is a literal.

 isLiteral(?v)

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

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

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

This query is similar to the one in 1.2.1.3 except that is matches the people with a name and an mbox which is a Literal. This would be used to look for erroneous data (foaf:mbox should only have a URI as its object).

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

Query result:

11.2.3.6 sop:str

Returns an xs:string representation of an r:URI. This useful for examining parts of a URI, for instance, the host-name.

 str(?v)

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

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

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

This query selects the set of people who use their work.example address in their foaf profile:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
 WHERE { ?x foaf:name  ?name ;
            foaf:mbox  ?mbox .
         FILTER regex(str(?mbox), "@work.example") }

Query result:

11.2.3.7 sop:lang

Returns a valid RFC 3066 language string representing the XML schema language datatype for a variable.

 lang(?v)

@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       "Robert"@EN.
_:a  foaf:name       "Roberto"@ES.
_:a  foaf:mbox       <mailto:bob@work.example> .

This query finds the Spanish foaf:name and foaf:mbox:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
 WHERE { ?x foaf:name  ?name ;
            foaf:mbox  ?mbox .
         FILTER lang(?name) = "ES" }

Query result:

11.2.3.8 sop:datatype

Returns the datatype of its argument if that argument is a typed literal. Otherwise it fails.

 datatype(?v)

@prefix foaf:       <http://xmlns.com/foaf/0.1/> .
@prefix eg:         <http://biometrics.example/ns#> .
@prefix xsd:        <http://www.w3.org/2001/XMLSchema#> .

_:a  foaf:name       "alice".
_:a  eg:shoeSize     "9.5"^^xsd:float .

_:b  foaf:name       "bob".
_:b  eg:shoeSize     "42"^^xsd:integer .

This query finds everyone's foaf:name and integer foaf:shoeSize:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX xsd:  <http://www.w3.org/2001/XMLSchema#>
PREFIX eg:   <http://biometrics.example/ns#>
SELECT ?name ?size
 WHERE { ?x foaf:name  ?name ; eg:shoeSize  ?size .
         FILTER datatype(?size) = xsd:int }

Query result:

11.2.3.9 sop:logical-or

Returns a logical OR of the arguments. As with other functions and operators with boolean arguments, sop:logical-or operates on the effective boolean value of its arguments.

 ?u || ?v

11.2.3.10 sop:logical-and

Returns a logical AND of the arguments. As with other functions and operators with boolean arguments, sop:logical-and operates on the effective boolean value of its arguments.

 ?u && ?v

Table 11.2 SPARQL Casting Functions

SPARQL imports casting functions from the XPath. The XQuery Functions & Operators Primitive Type Mapping table [17] specifies a which primitive types are castable to which other primitive types. The table is reproduced below, omitting casting operations that are not in the SPARQL language, and adding the additional datatypes imposed by the RDF data model.

bool = xs:boolean
dbl = xs:double
flt = xs:float
dec = xs:decimal
int = xs:integer
dT = xs:dateTime
str = xs:string
URI = r:URIRef — introduced by the RDF data model
ltrl = r:Literal — introduced by the RDF data model

11.3 Extensible Value Testing

Implementations may provide custom extended value testing operations, for example, for specialized datatypes. These are provided by functions in the query that return true or false for their arguments.

qname( expression, expression , ...)

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX my: <http://my.example/functions#>
SELECT ?name ?id
WHERE { ?x foaf:name  ?name ;
           my:empId   ?id .
        FILTER my:even(?id) }

PREFIX myGeo: <http://my.example.org/geo#>

SELECT ?x ?y
WHERE { ?x myGeo:placeName "SWEB Town" .
        ?x myGeo:location ?xLoc .
        ?y myGeo:location ?yLoc .
        FILTER myGeo:distance(?x, ?y) < 10 . 
      }

A function returns an RDF term.  It might be used to test some application datatype not supported by the core SPARQL specification, it might be a transformation between datatype formats, for example into an XSD dateTime RDF term from another date format.

The function is called during FILTER evaluation for each possible query solution. A function is named by URI in a QName form, and returns an RDF term.

If a query processor encounters a function that it does not provide, the query is not executed and an error is returned.

Functions should have no side-effects.  A SPARQL query processor may remove calls to functions if it can optimize them away.

A. SPARQL Grammar

Section status: drafted – terminal syntax not checked against that of the XML 1.1 spec

A SPARQL query is a sequence of characters in the language defined by the following grammar, starting with the Query production. The EBNF format is the same as that used in the XML 1.1 specification. Please see the "Notation" section of that specification for specific information about the notation.

Whitespace

Whitespace is used to separate two terminals which would otherwise be (mis-)recognized as one terminals.  Whitespace in terminals is significant. Otherwise whitespace is ignored. Terminals are shown below enclosed in <> or shown in-line.

Keywords

Keywords are shown in uppercase and are matched in a case insensitive manner.  The exception is the keyword 'a' which, in line with Turtle and N3, is used in place of the URI rdf:type (in full,  http://www.w3.org/1999/02/22-rdf-syntax-ns#type).

Comments

Comments in SPARQL queries take the form of '#', outside a URI or string, and continue to the end of line or end of file if there is no end of line after the comment marker.

• We expect to state some formal characteristics of the grammar in later drafts.

B. References

@@ToDo@@ Split into acknowledgements and references, noting whether normative or not.

References

@@ToDo@@How many of these are still used?

@@ToDo@@Mention SeRQL or reference emails

[1] "Three Implementations of SquishQL, a Simple RDF Query Language", Libby Miller, Andy Seaborne, Alberto Reggiori; ISWC2002

[2] "RDF Query and Rules: A Framework and Survey", Eric Prud'hommeaux

[3] "RDF Query and Rule languages Use Cases and Example", Alberto Reggiori, Andy Seaborne

[4] RDQL Tutorial for Jena (in the Jena tutorial).

[5] RDQL BNF from Jena

[6] Enabling Inference, R.V. Guha, Ora Lassila, Eric Miller, Dan Brickley

[7] N-Triples

[8] RDF http://www.w3.org/RDF/

[9] "Representing vCard Objects in RDF/XML", Renato Iannella, W3C Note.

[10] "RDF Data Access Working Group"

[11] "RDF Data Access Use Cases and Requirements ? W3C Working Draft 2 June 2004", Kendall Grant Clark.

[12] "Resource Description Framework (RDF): Concepts and Abstract Syntax", Graham Klyne, Jeremy J. Carroll, W3C Recommendation.

[13] RFC 3986, "Uniform Resource Identifier (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter

[14] "Namespaces in XML 1.1", Tim Bray et al., W3C Recommendation.

[15] "Turtle - Terse RDF Triple Language, Dave Beckett.

[16] "SPARQL Variable Binding Results XML Format", Dave Beckett.

[17] "XQuery 1.0 and XPath 2.0 Functions and Operators", Ashok Malhotra et al., W3C Working Draft.

C. Change Log

CVS Change Log:

 
$Log: Overview.html,v $
Revision 1.6  2018/10/09 13:31:29  denis
fix validation of xhtml documents

Revision 1.5  2017/10/02 10:30:43  denis
add fixup.js to old specs

Revision 1.4  2005/04/20 09:48:58  eric
removed extraneous link meant for editor's draft

Revision 1.3  2005/04/19 22:35:52  matthieu
fixed typo

Revision 1.2  2005/04/19 22:26:54  matthieu
fixed previous version

Revision 1.1  2005/04/19 22:22:16  matthieu
new entry

Revision 1.318  2005/04/19 22:16:34  eric
typos

Revision 1.317  2005/04/19 22:09:04  eric
trimmed CVS log for publication


3rd WD ready for publication

Revision 1.316  2005/04/19 22:06:20  eric
pubrules checker

Revision 1.315  2005/04/19 22:03:40  eric
prep for publication

Revision 1.314  2005/04/19 21:49:02  eric
add heading ids

Revision 1.313  2005/04/19 21:38:56  eric
link checking

Revision 1.312  2005/04/19 20:55:16  eric
namespace validating

Revision 1.311  2005/04/19 20:51:31  eric
css validating

Revision 1.310  2005/04/19 20:50:08  eric
css validating

Revision 1.309  2005/04/19 20:40:10  eric
validating markup

Revision 1.308  2005/04/19 19:12:28  eric
incorporated most of andy's comments

Revision 1.307  2005/04/18 08:33:41  aseaborne
Typos

Revision 1.306  2005/04/17 18:50:10  aseaborne
typos

Revision 1.305  2005/04/17 18:42:08  aseaborne
Working through section 7

+ Typos

+ Include text in example 2 that puts RDF merging of
  data down to the publisher of the data and not part
  of the spec.

Revision 1.304  2005/04/17 18:00:36  aseaborne
Working through sections 5 and 6

+ Fix text in 5 intro.  Typos.

+ 5.3 Query pattern => Graph Pattern

+ Link broken in 2
+ Fixed missing link in 4 2

+ Tweak text in 5.5 (nested optionals)

+ Remove section 5.6 (it moved to the wider discussion of ordering).

+ 6 - title now "Matching Alternatives"

+ 6.2 - Tidy text; highlight that UNION takes
  groups for parameters (like all graph operators).

+ Add missing defn tags to definitions
  throughout the document

+ 6.3 Definition seems to have swallowed the next para - split out.

Revision 1.303  2005/04/16 17:13:51  aseaborne
+ ORDERing: choose case 1: implementations
  (should be consistent but exactly what is not defined)
  so as to allow for processors that handle datatypes outside
  the core set.

+ 10.3 Change "merging" (which is not an RDF merge and wasn't
  qualified as such) to "combining ... by set union.".

Revision 1.302  2005/04/16 16:48:50  aseaborne
Working through sections 3 and 4.

+ 3.2 binding -> bindings

+ Defn Value Constraint: "A graph pattern may involve
  a value constraint ..."

+ 4 Graph Patterns - list possibilities
  4.1 New section specifically for groups
  Old 4.1 => 4.2

Revision 1.301  2005/04/16 16:10:40  aseaborne
Working through sections 1 and 2.

+ TOC and section headings:
  Section 2 : Sub-section titles : "Basic Graph Pattern"
  Section 4 : "Graph Patterns"

+ Added a table for prefixes used for better
  layout in narrow windows.

+ Unpdate "Query Term Syntax"

+ s/bNode/blank node/g in text

+ Removed reference? because we
  use RFC 3986 terminology.

+ 2.1 Use link to unbound variables section.

+ 2.2 Add defn of Graph Pattern - all forward references to later sections.

+ 4 Add basic graph patterns to elements of a graph pattern

+ Commented out definition of restriction as it appears to be no longer used.

+ Removed overview text in 2.4

+ 2.6 More text to clarify role of blank nodes in queries.

+ 2.7 Removed comment on nesting of syntax a it seems to create more
  confusion than light.

Revision 1.300  2005/04/14 11:43:04  eric
pre- Graph Pattern overhaul
  incorporated DaveB's comments up to 4

Revision 1.299  2005/04/14 08:04:03  aseaborne
Removed reification syntax

Revision 1.298  2005/04/13 14:34:20  aseaborne
fix HTML ptII

Revision 1.296  2005/04/13 14:26:36  aseaborne
+ Bare text for section on specifying graphs in datasets

Revision 1.295  2005/04/13 10:53:36  aseaborne
+ Noted todo "?x ?x" example.
+ Grammar update

Revision 1.294  2005/04/13 08:19:57  eric
incorporated DaveB's comments up to 2.2

Revision 1.293  2005/04/05 14:26:19  connolly
ispell fixes: predciate, dadatype, expliitly, dataypes, operatates,
  specialised
 hyphenated subpatterns, hostname, inline per m-w.com
  per  http://www.w3.org/2001/06/manual/#Spelling

Revision 1.292  2005/04/05 11:25:22  eric
waffled back to decimal derivatives being only used for ebvs

Revision 1.291  2005/04/04 19:21:03  connolly
WF fixes

Revision 1.290  2005/04/01 15:29:04  eric
renumbered chapter 11 subsections

Revision 1.289  2005/04/01 05:42:35  eric
s/primative/primitive/

Revision 1.288  2005/04/01 03:58:12  eric
reworked examples to be friendly to existing schemas
sending to WG now.

Revision 1.287  2005/04/01 03:13:41  eric
aggressive pass through section 11, rewording and clarifying a lot about the execution model

Revision 1.286  2005/03/31 08:26:41  eric
add a function mapping for matches with a flags parameter

Revision 1.285  2005/03/31 07:50:53  eric
comparing a bNode and a URI does NOT produce an error (<foo> != [] is TRUE)

Revision 1.284  2005/03/30 13:10:14  aseaborne
Fix <br>

Revision 1.283  2005/03/30 13:08:55  aseaborne
revised definition for optional

Revision 1.282  2005/03/30 10:27:13  aseaborne
+ Updated grammar
+ Syntax for ascending/.descending is ASC[] / DESC[]

Revision 1.281  2005/03/30 09:02:44  eric
moved matches around

Revision 1.280  2005/03/30 08:56:36  eric
questions from implementation and testing SPARQL0 test

Revision 1.279  2005/03/29 16:35:45  aseaborne
+ Added "distance" example for extension functions.

Revision 1.278  2005/03/29 14:23:47  eric
include derived types in the set of handled types

Revision 1.277  2005/03/29 13:01:09  eric
+ numeric derived types

Revision 1.276  2005/03/28 16:29:24  aseaborne
Typo

Revision 1.275  2005/03/28 16:26:51  aseaborne
+ Section 10: ORDER BY
  Sub sections on order by expression and order by variable.
  noting that ordering be partial

Revision 1.274  2005/03/28 14:57:35  aseaborne
+ Tidyup sections 7 & 8

Revision 1.273  2005/03/28 14:18:49  aseaborne
+ Typographical corrections to section 5 & 6.

Revision 1.272  2005/03/28 11:27:48  aseaborne
+ Remove special talk about constraints from the definition of group
+ Noted need 4.1 about unbound variables
+ Tidy up 2.6 to 4
+ Some misc 'tidy'ing up

Revision 1.271  2005/03/26 15:55:37  aseaborne
Change refs involving the word "disjunction" to ones using "union"

Revision 1.270  2005/03/24 15:33:19  aseaborne
*** empty log message ***

Revision 1.269  2005/03/24 13:59:43  aseaborne
Missed a change

Revision 1.268  2005/03/24 13:50:33  aseaborne
+ Corrections provided by Kevin
  2005JanMar/0435

Revision 1.267  2005/03/22 17:48:32  aseaborne
+ Reworded 11.3 to be inline with general function-rturns-RDF term.

Revision 1.266  2005/03/22 16:12:41  eric
validated better

Revision 1.265  2005/03/22 16:10:41  eric
validated

Revision 1.264  2005/03/22 10:23:24  aseaborne
+ Noted need for references and acknowledgements
+ Ensured "{ }" is a legal graph pattern

Revision 1.263  2005/03/21 17:01:20  aseaborne
Grammar update

Revision 1.262  2005/03/21 16:06:44  aseaborne
+ Move Projection and DISTINCT out of SELECT, into solution sequence processing

Revision 1.261  2005/03/21 14:53:14  aseaborne
Mistake in TOC href

Revision 1.260  2005/03/21 14:49:53  aseaborne
+ Example of two forms of RDF datasets:
  1/ Provenance information in background graph
  2/ RDF merge into the background graph.

Revision 1.259  2005/03/21 14:19:27  aseaborne
+ Typos and editorial matters from 2005Mar/0031

Revision 1.258  2005/03/21 11:14:35  aseaborne
Corrections from comment list message: dawg comments 2005Mar/0028

Revision 1.257  2005/03/18 16:32:45  aseaborne
More on ordering.

Revision 1.256  2005/03/17 17:39:55  aseaborne
Example mistake: LIMIT and OFFSET were the wrong way round

Revision 1.255  2005/03/17 17:15:46  aseaborne
+ Some refinement of order evaluation rules.

Revision 1.254  2005/03/17 17:00:35  aseaborne
+ Clarify the grammar WRT tokens and whitespace.
+ Example of getting a whole graph from a dataset using CONSTRUCT
+ More on sorting

Revision 1.253  2005/03/17 13:51:56  aseaborne
+ Clarify the grammar WRT tokens and whitespace.

Revision 1.252  2005/03/16 15:44:30  aseaborne
+ More notes on ORDER BY syntax.

Revision 1.251  2005/03/15 18:20:25  aseaborne
+ Make section 10.1 (move rest along) - relationship between
  solutions and result forms
+ Notes for ORDER BY, LIMIT, OFFSET

Revision 1.250  2005/03/15 15:35:45  eric
update NAF syntax

Revision 1.249  2005/03/15 15:34:44  eric
update NAF syntax

Revision 1.248  2005/03/15 15:17:53  eric
validated

Revision 1.247  2005/03/15 15:14:48  eric
validated

Revision 1.246  2005/03/15 15:05:46  eric
less contrived BOUND operator example

Revision 1.245  2005/03/14 19:34:59  eric
folks seem to prefer "regex".
clean up styling nits.

Revision 1.244  2005/03/14 18:17:47  aseaborne
+ Removed text for default prefixes for rdf: rdfs: owl: xsd:

Revision 1.243  2005/03/14 14:03:47  aseaborne
+ "CONSTRUCT *" removed
+ CONTRUCT/LIMIT and DESCRIBE/LIMIt mentioned
+ Grammar updated

Revision 1.242  2005/03/14 12:29:54  aseaborne
+ Section 2 intro: brief para to set the scene.
+ Section 2 : description of syntact forms for bNode property lists,
    RDF collections and reification

Revision 1.241  2005/03/11 10:39:17  aseaborne
+ Added 'a' as a synonym for rdf:type as a property to the grammar

Revision 1.240  2005/03/10 18:38:56  aseaborne
+ Corrected example using foaf:PersonalProfileDocument
  Now uses rdfs:seeAlso and a rdf:type assertion.
  Queries change to match
+ Inserted ToDos

Revision 1.239  2005/03/10 12:03:31  aseaborne
+ Replaced == by = ; replaced eq by = ; replaced ne by !=

Revision 1.238  2005/03/10 11:56:58  aseaborne
+ New syntax
  Grammar updates
  Examples converted

Revision 1.237  2005/03/09 16:43:39  aseaborne
+ Noted that must describe various syntactic forms (2.7)

Revision 1.236  2005/03/08 16:44:54  aseaborne
+ Remove section 9 (WITH/FROM)
+ Note for section 9 - execution order
+ A few typos

Revision 1.235  2005/02/28 17:03:25  eric
added namespace to function invocation example

Revision 1.234  2005/02/25 10:53:49  aseaborne
+ Update grammar:
  + Remove "eq" and "ne", change "==" to "="
    reflecting use inline with XQuery/XPath2/F&O
    except we choose to use "=" "<" etc, not "eq", "lt"
  + str() and datatype() take expressions
  + Combined *AsExpr/*AsNode states

Revision 1.233  2005/02/23 17:51:15  eric
fixed LANG per danbri's comments, responses

Revision 1.232  2005/02/23 15:48:42  eric
still more words on negation as failure per pat's mail

Revision 1.231  2005/02/23 03:46:19  eric
new words on negation as failure per pat's mail

Revision 1.230  2005/02/22 18:17:06  aseaborne
+ Reference Turtle in the text
+ Discuss BASE; add to example of syntax

Revision 1.229  2005/02/22 14:16:59  eric
removed NOT per pat's comment

Revision 1.228  2005/02/19 11:24:47  eric
added EBV

Revision 1.227  2005/02/18 17:49:18  eric
+ further clarification as an editor's draft
- trimmed change log at 1.200

Revision 1.226  2005/02/18 17:40:55  eric
fixed pointer to published working draft

Revision 1.225  2005/02/17 19:38:13  eric
turned back into an editor's draft