SPARQL Query Language for RDF

Editors working draft.
$Revision: 1.45 $ of $Date: 2007/02/16 18:06:04 $
Eric Prud'hommeaux, W3C <eric@w3.org>
Andy Seaborne, Hewlett-Packard Laboratories, Bristol <andy.seaborne@hp.com>
published W3C Technical Report Version:
Latest published version; see also public-rdf-dawg-comments@w3.org Mail Archives


RDF is a flexible and extensible way to represent information about World Wide Web resources. It is used to represent, among other things, personal information, social networks, metadata about digital artifacts, as well as provide a means of integration over disparate sources of information. A standardized query language for RDF data with multiple implementations offers developers and end users a way to write and to consume the results of queries across this wide range of information. Used with a common protocol, applications can access and combine information from across the Web.

This document describes the query language part of the SPARQL Protocol And RDF Query Language for easy access to RDF stores. It is designed to meet the requirements and design objectives described in RDF Data Access Use Cases and Requirements [UCNR.  The SPARQL query language consists of the syntax and semantics for asking and answering queries against RDF graphs. SPARQL contains capabilities for querying by triple patterns, conjunctions, disjunctions, and optional patterns. It also supports constraining queries by source RDF graph and extensible value testing. Results of SPARQL queries can be ordered, limited and offset in number, and presented in several different forms.

@@Revise when rest finished.

Status of This document

This is a live document and is subject to change without notice. It reflects the best effort of the editors to reflect implementation experience and incorporate input from various members of the WG, but is not yet endorsed by the WG as a whole.

The change log enumerates changes since the Candidate Recommendation of 6 April 2006. We have been tracking threads in the public-rdf-dawg-comments archive more closely. A status report is updated every week or so.

For the definitions, we have an XSLT transformation, defns.xsl, that extracts them from this document. A live version of the output is available via the W3C XSLT service.

See also: SPARQL Test Cases, in progress.

Table of Contents


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

    @@Scope of blank nodes in BGP 5.4 + clarify the group example of { {} {} }

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

@@ Grammar extracts maybe out of line with the grammar while the grammar is revised for clarity.



1 Introduction

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

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

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

1.1 Document Outline

This document defines the SPARQL, an RDF query language.

    @@About grammar extracts

    @@ This text does somewhere:

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

1.2 Document Conventions

1.2.1 Namespaces

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

Prefix IRI
rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs: http://www.w3.org/2000/01/rdf-schema#
xsd: http://www.w3.org/2001/XMLSchema#
fn: http://www.w3.org/2005/xpath-functions#

1.2.2 Data Descriptions

@@ Need a bit more, esp blank nodes.

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

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

1.2.3 Result Descriptions

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

x y z
"Alice" <http://example/a>

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

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

2 Making Simple Queries

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

This section gives an introduction to the basic matching features of SPARQL.

2.1 Writing a Simple Query

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


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


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

This query, on the data above has one solution:

Query Result:

"SPARQL Tutorial"

2.2 Multiple Matches

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


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

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


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

Query Result:

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

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

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

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

2.3 Matching RDF Literals

The data below contains a number of RDF literals:

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

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

This RDF data is the target for query examples in the following sections.

2.3.1 Matching Integers

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

SELECT ?v WHERE { ?v ?p 42 }

2.3.2 Matching Arbitrary Datatypes

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

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

2.3.3 Matching Language Tags

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

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

but this does find a solution where variable x is bound to :z:

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

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

2.4 Value Constraints

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

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

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

2.4.1 Restricting the values of strings

Variable bindings can be restricted to strings matching a regular expression by using the regex operator. Only plain literals with no language tag and XSD strings are matched by regex. regex can be used to match the lexical forms of other literals by using the str operator.


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

Query Result:

"SPARQL Tutorial"

Regular expression matches may be made case-insensitive with the "i" flag.


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

Query Result:

"The Semantic Web"

2.4.2 Restricting the values of numbers

It is also possible to restrict the values of literals that have number values. Filters apply to the value of the literal, not its lexical form.


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

Query Result:

title price
"The Semantic Web" 23

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

2.5 Term Constraints

    @@ isURI/isLiteral/isBlank.  Discuss these test

2.6 Querying Reification Vocabulary

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

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

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

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

In this example data, there is no RDF triple giving the title of the book; there are triples that describe two such RDF statements but the statements themselves are not asserted in the graph. A query asking for any titles of any book returns nothing.

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

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

Query Result:

book title

There are no triples in the graph with dc:title in the property position (it appears in the object position in the data).

A query can ask about descriptions of statements made by "Bob":

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

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

and there is one such description for a statement made by Bob:

book title
<http://example.org/book/book1> "SPARQL Tutorial"

2.7 Blank Node Labels in Query Results

    @@ Move to section 10

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

Blank nodes labels are local to the result set of a query. An application or client cannot usefully use blank node labels to formulate a query that directly refers to a particular blank node.  In effect, this means that information about co-occurrences of blank nodes may be treated as scoped to the results as defined in "SPARQL Query Results XML Format" or the CONSTRUCT result form.

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

_:a  foaf:name   "Alice" .
_:b  foaf:name   "Bob" .
PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
SELECT ?x ?name
WHERE  { ?x foaf:name ?name }
x name
_:c "Alice"
_:d "Bob"

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.

x name
_:r "Alice"
_:s "Bob"

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

3 SPARQL Term Syntax

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

3.1 RDF Term Syntax

3.1.1 Syntax for IRIs

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

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

Grammar rules:@@
[64] IRIref ::= Q_IRI_REF | QName
[65] QName ::= QNAME | QNAME_NS
[67] Q_IRI_REF ::= '<' ([^<>'{}|^`]-[#x00-#x20])* '>'
Prefixed names

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

Relative IRIs

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

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

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

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

3.1.2 Syntax for Literals

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

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

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

Examples of literal syntax in SPARQL include:

Grammar rules:@@ (maybe a "literal" rule?)
[60] RDFLiteral ::= String ( LANGTAG | ( '^^' IRIref ) )?
[61] NumericLiteral ::= INTEGER | DECIMAL | DOUBLE
[62] BooleanLiteral ::= 'true' | 'false'
[73] LANGTAG ::= '@' [a-zA-Z]+ ('-' [a-zA-Z0-9]+)*
[74] INTEGER ::= [0-9]+
[75] DECIMAL ::= [0-9]+ '.' [0-9]* | '.' [0-9]+
[76] DOUBLE ::= [0-9]+ '.' [0-9]* EXPONENT | '.' ([0-9])+ EXPONENT | ([0-9])+ EXPONENT
[77] EXPONENT ::= [eE] [+-]? [0-9]+
[78] STRING_LITERAL1 ::= "'" ( ([^#x27#x5C#xA#xD]) | ECHAR )* "'"
[79] STRING_LITERAL2 ::= '"' ( ([^#x22#x5C#xA#xD]) | ECHAR )* '"'
[80] STRING_LITERAL_LONG1 ::= "'''" ( ( "'" | "''" )? ( [^'\] | ECHAR ) )* "'''"
[81] STRING_LITERAL_LONG2 ::= '"""' ( ( '"' | '""' )? ( [^"\] | ECHAR ) )* '"""'

3.1.3 Syntax for Query Variables

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

Grammar rules:@@
[44] Var ::= VAR1 | VAR2
[71] VAR1 ::= '?' VARNAME
[72] VAR2 ::= '$' VARNAME
[90] VARNAME ::= ( NCCHAR1 | [0-9] ) ( NCCHAR1 | [0-9] | #x00B7 | [#x0300-#x036F] | [#x203F-#x2040] )*

3.1.4 Syntax for Blank Nodes

@@Talk about identifiers as mere syntax elements

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

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

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

The following two forms

[ :p "v" ] .
[] :p "v" .

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

_:b57 :p "v" .

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

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

is equivalent to the two triples:

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

and as an object:

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

is equivalent to the two triples:

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

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

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

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

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

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

Grammar rules:@@
[66] BlankNode ::= BLANK_NODE_LABEL | ANON
[87] ANON ::= '[' WS* ']'

3.2 Syntax for Triple Patterns

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

The following examples express the same query:

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

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

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

3.2.1 Predicate-Object Lists

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

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

This is the same as writing the triple patterns:

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

3.2.2 Object Lists

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

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

is the same as writing the triple patterns:

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

Object lists can be combined with predicate-object lists:

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


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

3.2.3 RDF Collections

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

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

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

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

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

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

is a short form for:

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

3.2.4 rdf:type

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

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

  is short for:

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

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

4 Initial Definitions

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

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

4.1 RDF Terms

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

Definition: RDF Term

let I be the set of all IRIs.
let RDF-L be the set of all RDF Literals
let RDF-B be the set of all blank nodes in RDF graphs

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

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

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

4.2 Query Variables

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

Definition: Query Variable

A query variable is a member of the set V where V is infinite and disjoint from RDF-T.

4.3 Triple Patterns

The building blocks of queries are triple patterns.

Definition: Triple Pattern

A triple pattern is member of the set:
(RDF-T union V) x (I 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."

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

Grammar rules:@@
[32] TriplesSameSubject ::= VarOrTerm PropertyListNotEmpty | TriplesNode PropertyList
[33] PropertyList ::= PropertyListNotEmpty?
[34] PropertyListNotEmpty ::= Verb ObjectList ( ';' PropertyList )?
[35] ObjectList ::= GraphNode ( ',' ObjectList )?
[36] Verb ::= VarOrIRIref | 'a'

4.4 Graph Pattern

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

Definition: Graph Pattern

A Graph Pattern is one of:

4.5 SPARQL Query

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

Definition: SPARQL Query

A SPARQL query is a tuple (GP, DS, SM, R) where:

The graph pattern of a query is called the query pattern.

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

4.6 Pattern Solutions

Definition: Pattern Solution

A variable substitution is a substitution function from a subset of V, the set of variables, to the set of RDF terms, RDF-T.

A pattern solution, S, is a variable substitution whose domain includes all the variables in V and whose range is a subset of the set of RDF terms.

The result of replacing every member v of V in a graph pattern P by S(v) is written S(P).

If v is not in the domain of S then S(v) is defined to be v.

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

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

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

4.7 Value Constraints

Definition: Value Constraint

A value constraint is a boolean-valued expression of variables and RDF Terms.

For value constraint C, a solution S matches C if S(C) is true, where S(C) is the boolean-valued expression obtained by substitution of the variables mentioned in C.

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

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

@@Filters apply to the whole of the group they are in.  Canonically, all matchingis done, then filters are applied.  Implementations wil optimize this.

Grammar rules:@@
[27] Constraint ::= 'FILTER' ( BrackettedExpression | BuiltInCall | FunctionCall )

5 Basic Graph Patterns

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

Definition: Basic Graph Pattern

A Basic Graph Pattern is a set of Triple Patterns.

Grammar rules:@@


Definition: E-entailment Regime

An E-entailment regime is a binary relation between subsets of RDF graphs.

A graph in the range of an E-entailment is called well-formed for the E-entailment.

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

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

Definition: Basic Graph Pattern equivalence

Two basic graph patterns are equivalent if there is a bijection M between the terms of the triple patterns that maps blank nodes to blank nodes and maps variables, literals and IRIs to themselves, such that a triple ( s, p, o ) is in the first pattern if and only if the triple ( M(s), M(p) M(o) ) is in the second.

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

5.1 General Framework

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

Definition: Scoping Set

A Scoping Set B is some set of RDF terms.

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

Definition: Scoping Graph

The Scoping Graph G' for RDF graph G, is an RDF Graph that is graph-equivalent to G

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

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

Definition: Basic Graph Pattern E-matching

Given an entailment regime E, a basic graph pattern BGP, and RDF graph G, with scoping graph G', then BGP E-matches with pattern solution S on graph G with respect to scoping set B if:

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

5.2 SPARQL Basic Graph Pattern Matching

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

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

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

5.3 Example of Basic Graph Pattern Matching

As an example of a Basic Graph Pattern:


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

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

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

There is a blank node [CONCEPTS] 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.


PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
SELECT ?mbox
  { ?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 with the same solution for the graph pattern to match. The pattern solution matching the basic graph pattern maps the variable 'x' to blank node _:a and variable 'mbox' to the IRI mailto:outlaw@example.com. The query only returns the variable 'mbox'.

5.4 Basic Graph Patterns in the SPARQL Syntax

@@ Is a split BGP still a single BGP?

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

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

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

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

6 Group Graph Patterns

@@ Don't need this summary any more ?

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

6.1 Group Graph Patterns

Definition: Group Graph Pattern

A group graph pattern GGP is a set of graph patterns, GPi.

A solution of Group Graph Pattern GGP on graph G is any solution S such that, for every element GPi of GGP, S is a solution of GPi.

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

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

PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
          ?x foaf:name ?name .
          ?x foaf:mbox ?mbox .
The same solutions would be obtained from a query that grouped the triple patterns in basic graph patterns as below:
PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
WHERE  { { ?x foaf:name ?name . }
         { ?x foaf:mbox ?mbox . }
Grammar rules:@@
[19] GroupGraphPattern ::= '{' GraphPattern '}'

6.2 Empty Group Pattern

The group pattern:

{ }

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


matches with one solution which has no substitutions for variables.

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

6.3 Order of Evaluation

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

7 Including Optional Values

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

7.1 Optional Pattern Matching

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

pattern OPTIONAL { pattern }


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

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

_:b  rdf:type        foaf:Person .
_:b  foaf:name       "Bob" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
WHERE  { ?x foaf:name  ?name .
         OPTIONAL { ?x  foaf:mbox  ?mbox }

With the data above, the query result is:

name mbox
"Alice" <mailto:alice@example.com>
"Alice" <mailto:alice@work.example>

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

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

7.2 Constraints in Optional Pattern Matching

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

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

:book1  dc:title  "SPARQL Tutorial" .
:book1  ns:price  42 .
:book2  dc:title  "The Semantic Web" .
:book2  ns:price  23 .
PREFIX  dc:  <http://purl.org/dc/elements/1.1/>
PREFIX  ns:  <http://example.org/ns#>
SELECT  ?title ?price
WHERE   { ?x dc:title ?title .
          OPTIONAL { ?x ns:price ?price . FILTER (?price < 30) }
title price
"SPARQL Tutorial"
"The Semantic Web" 23

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

7.3 Multiple Optional Graph Patterns

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


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

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

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


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

Query result:

name mbox hpage
"Alice" <http://work.example.org/alice/>
"Bob" <mailto:bob@work.example>

7.4 Optional Matching – Formal Definition

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

Definition: Optional Graph Pattern

An optional graph pattern is a combination of a pair of graph patterns. The second pattern modifies pattern solutions of the first pattern but does not fail matching of the overall optional graph pattern.

If Opt(A, B) is an optional graph pattern, where A and B are graph patterns, then S is a solution of optional graph pattern if S is a pattern solution of A and of B otherwise if S is a solution to A, but not to A and B.

The syntactic form:

{ OPTIONAL { pattern } }

is defined to be

{ { } OPTIONAL { pattern } }
Grammar rules:@@
[24] OptionalGraphPattern ::= 'OPTIONAL' GroupGraphPattern

The OPTIONAL keyword is left-associative :

pattern OPTIONAL { pattern } OPTIONAL { pattern }

matches the same as:

{ pattern OPTIONAL { pattern } } OPTIONAL { pattern }

7.5 Nested Optional Graph Patterns

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


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

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

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

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

_:z  vcard:Family  "Hacker" .

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

_:y  vcard:Given   "Eleanor" .


PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX vcard: <http://www.w3.org/2001/vcard-rdf/3.0#>
SELECT ?foafName ?mbox ?gname ?fname
  {  ?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:

foafName mbox gname fname
"Alice" <mailto:alice@work.example> "Alice" "Hacker"
"Bob" <mailto:bob@work.example>
"Ella" "Eleanor"

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

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

8 Matching Alternatives

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

8.1 Joining Patterns with UNION

The UNION keyword is the syntax for pattern alternatives.


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

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

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

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


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

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

Query result:

"SPARQL Protocol Tutorial"
"SPARQL (updated)"
"SPARQL Query Language Tutorial"

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 } }
x y
"SPARQL (updated)"
"SPARQL Protocol Tutorial"
"SPARQL Query Language Tutorial"

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

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

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

SELECT ?title ?author
WHERE  { { ?book dc10:title ?title .  ?book dc10:creator ?author }
         { ?book dc11:title ?title .  ?book dc11:creator ?author }
author title
"Alice" "SPARQL Protocol Tutorial"
"Bob" "SPARQL Query Language Tutorial"

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

8.2 Union Matching – Formal Definition

Definition: Union Graph Pattern

A union graph pattern is a set of graph patterns GPi.

A union graph pattern matches a graph G with solution S if there is some GPi such that GPi matches G with solution 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.

Grammar rules:@@
[26] GroupOrUnionGraphPattern ::= GroupGraphPattern ( 'UNION' GroupGraphPattern )*

9 RDF Dataset

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

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

Definition: RDF Dataset

An RDF dataset is a set:
{ G, (<u1>, G1), (<u2>, G2), . . . (<un>, Gn) }
where G and each Gi are graphs, and each <ui> is an IRI. Each <ui> is distinct.

G is called the default graph. (<ui>, Gi) are called named graphs.

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

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

9.1 Examples of RDF Datasets

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

Example 1:

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

<http://example.org/bob>    dc:publisher  "Bob" .
<http://example.org/alice>  dc:publisher  "Alice" .
# Named graph: http://example.org/bob
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Bob" .
_:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Named graph: http://example.org/alice
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

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

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

Example 2:

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

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

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

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

_:y foaf:name "Alice" .
_:y foaf:mbox <mailto:alice@work.example.org> .
# Named graph: http://example.org/bob
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Bob" .
_:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Named graph: http://example.org/alice
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

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

In an RDF merge, blank nodes in the merged graph are not shared with blank nodes from the graphs being merged.

9.2 Specifying RDF Datasets

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

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

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

Grammar rules:@@
[9] DatasetClause ::= 'FROM' ( DefaultGraphClause | NamedGraphClause )
[10] DefaultGraphClause ::= SourceSelector
[11] NamedGraphClause ::= 'NAMED' SourceSelector
[12] SourceSelector ::= IRIref
[26] GroupOrUnionGraphPattern ::= GroupGraphPattern ( 'UNION' GroupGraphPattern )*

9.2.1 Specifying the Default Graph

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

In this example, there is a single default graph:

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

_:a  foaf:name     "Alice" .
_:a  foaf:mbox     <mailto:alice@work.example> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT  ?name
FROM    <http://example.org/foaf/aliceFoaf>
WHERE   { ?x foaf:name ?name }

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

9.2.2 Specifying Named Graphs

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

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

_:a foaf:name "Bob" .
_:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Graph: http://example.org/alice
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Alice" .
_:a foaf:mbox <mailto:alice@work.example> .
FROM NAMED <http://example.org/alice>
FROM NAMED <http://example.org/bob>

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

9.2.3 Combining FROM and FROM NAMED

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

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

<http://example.org/bob>    dc:publisher  "Bob Hacker" .
<http://example.org/alice>  dc:publisher  "Alice Hacker" .
# Named graph: http://example.org/bob
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Bob" .
_:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Named graph: http://example.org/alice
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:a foaf:name "Alice" .
_:a foaf:mbox <mailto:alice@work.example.org> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dc: <http://purl.org/dc/elements/1.1/>

SELECT ?who ?g ?mbox
FROM <http://example.org/dft.ttl>
FROM NAMED <http://example.org/alice>
FROM NAMED <http://example.org/bob>
   ?g dc:publisher ?who .
   GRAPH ?g { ?x foaf:mbox ?mbox }
who g mbox
"Bob Hacker" <http://example.org/bob> <mailto:bob@oldcorp.example.org>
"Alice Hacker" <http://example.org/alice> <mailto:alice@work.example.org>

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

9.3 Querying the Dataset

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

Definition: RDF Dataset Graph Pattern

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

  1. g is an IRI where g = <ui> for some i, and S is pattern solution of P on dataset {Gi, (<u1>, G1), ...}
  2. g is a variable, S maps the variable g to <uj>, where <uj> is an IRI from a named graph of D, and S is a pattern solution of P on dataset {Gj, (<u1>, G1), ...}

The following two graphs will be used in examples:

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

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

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

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

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

     rdf:type      foaf:PersonalProfileDocument .
Grammar rules:@@

9.3.1 Accessing Graph Names

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

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

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

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

src bobNick
<http://example.org/foaf/aliceFoaf> "Bobby"
<http://example.org/foaf/bobFoaf> "Robert"

9.3.2 Restricting by Graph IRI

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

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

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

which yields a single solution:


9.3.3 Restricting possible Graph IRIs

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

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

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

SELECT ?mbox ?nick ?ppd
  GRAPH data:aliceFoaf
    ?alice foaf:mbox <mailto:alice@work.example> ;
           foaf:knows ?whom .
    ?whom  foaf:mbox ?mbox ;
           rdfs:seeAlso ?ppd .
    ?ppd  a foaf:PersonalProfileDocument .
  } .
  GRAPH ?ppd
      ?w foaf:mbox ?mbox ;
         foaf:nick ?nick
mbox nick ppd
<mailto:bob@work.example> "Robert" <http://example.org/foaf/bobFoaf>

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

9.3.4 Named and Default Graphs

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

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

RDF Dataset:

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

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

g:graph2 dc:publisher "Bob" .
g:graph2 dc:date "2005-01-10"^^xsd:date .
# Graph: locally allocated IRI: tag:example.org,2005-06-06:graph1
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

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

_:b foaf:name "Bob" .
_:b foaf:mbox <mailto:bob@oldcorp.example.org> .
# Graph: locally allocated IRI: tag:example.org,2005-06-06:graph2
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

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

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

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

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

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

The results show that the email address for "Bob" has changed.

name mbox date
"Bob" <mailto:bob@oldcorp.example.org> "2004-12-06"^^xsd:date
"Bob" <mailto:bob@newcorp.example.org> "2005-01-10"^^xsd:date

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

10 Query Result Forms

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

Returns all, or a subset of, the variables bound in a query pattern match.
Returns an RDF graph constructed by substituting variables in a set of triple templates.
Returns an RDF graph that describes the resources found.
Returns a boolean indicating whether a query pattern matches or not.

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

10.1 Solution Sequences and Result Forms

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

Definition: Solution Sequence

A solution sequence S is a list of solutions.

S = ( S0, S1, . . . , Sn)

The solution sequence from matching the query pattern is a collection formed from the solutions of the query pattern with no defined order.

Definition: Solution Sequence Modifier

A solution sequence modifier is one of:

If SM is the set of modifiers, and QS is the collection of solutions of a query, we write SM(QS) for the sequence formed by applying SM to the solution sequence formed from QS.

Definition: Result Forms

The result form of a query is one of

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

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

applied in the order given by the list.

10.1.1 ORDER BY

The ORDER BY clause takes a solution sequence and applies an ordering condition based on all the expressions and directions specified in the ORDER BY clause. The ordering condition also involves a direction of ordering which is ascending by default. It can be explicitly set to ascending or descending by enclosing the condition in ASC() or DESC() respectively. If multiple expressions 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 }
PREFIX foaf:    <http://xmlns.com/foaf/0.1/>

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

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

Definition: Ordered Solution Sequence

An ordered solution sequence is a solution sequence where the sequence is partially ordered with respect to some ordering condition.

A solution sequence S = ( S0, S1, . . . , Sn) is ordered with respect to an ordering condition C if, for Si, Sj, then i < j if C orders Si before Sj.

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

The "<" operator (see the Operator Mapping) defines the relative order of pairs of numerics, xsd:dateTimes and xsd:strings.

IRIs are ordered by comparing the character strings making up each IRI using the "<" operator.

SPARQL also defines a fixed, arbitrary order between some kinds of RDF terms that would not otherwise be ordered. This arbitrary order is necessary to provide slicing of query solutions by use of LIMIT and OFFSET.

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

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

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

Grammar rules:@@

10.1.2 Projection

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

Definition: Projection

The projection of solution QS over a set of variables VS is the solution
project(QS, VS) = { (v, QS(v)) | v in VS }

For a solution sequence S = ( S0, S1, . . . , Sn) and a finite set of variables VS,
project(S, VS) = ( project(S0, VS), project(S1, VS), . . . , project(Sn, VS) )

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

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

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

_:b  foaf:name       "Bob" .
_:b  foaf:mbox       <mailto:bob@work.example> .
PREFIX foaf:       <http://xmlns.com/foaf/0.1/>
SELECT ?name
 { ?x foaf:name ?name }


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

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

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

_:z    foaf:name   "Alice" .
_:z    foaf:mbox   <mailto:smith@work> .
PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
SELECT DISTINCT ?name WHERE { ?x foaf:name ?name }

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

Definition: Distinct Solution Sequence

A Distinct Solution Sequence is a solution sequence in which no two solutions are the same.

Let Sx and Sy be pattern solutions
then Sx != Sy if there exists variable v such that Sx(v) != Sy(v).

Equivalence of RDF terms is defined in Resource Description Framework (RDF): Concepts and Abstract Syntax [CONCEPTS].

For a solution sequence S = ( S1, S2, . . . , Sn), then write set(S) for the set of solution sequences in S.

    distinct(S) = (Si | Si != Sj for all i != j) and set(distinct(S)) = set(S)

Grammar rules:@@

10.1.4 OFFSET

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

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

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

SELECT  ?name
WHERE   { ?x foaf:name ?name }
ORDER BY ?name
Definition: Offset Solution Sequence

An Offset Solution Sequence with respect to another solution sequence S, is one which starts at a given index of S.

For solution sequence S = (S0, S1, . . . , Sn), the offset solution sequence
offset(S, k), k >= 0 is
(Sk, Sk+1, . . ., Sn) if n >= k
(), the empty sequence, if k > n

Grammar rules:@@

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

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

Definition: Limited Solution Sequence

A Limited Solution Sequence has at most a given, fixed number of members.

The limit of solution sequence S = (S0, S1, . . . , Sn) is

limit(S, m) =
(S0, S1, . . . , Sm-1) if n > m
(S0, S1, . . . , Sn) if n <= m-1

Grammar rules:@@

10.2 Selecting Variables

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

@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
  { ?x foaf:knows ?y ;
       foaf:name ?nameX .
    ?y foaf:name ?nameY .
    OPTIONAL { ?y foaf:nick ?nickY }
nameX nameY nickY
"Alice" "Bob"
"Alice" "Clare" "CT"

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

Result sets can be accessed by a local API but also can be serialized into either XML or an RDF graph. An XML format is described in SPARQL Query Results XML Format, and this gives:

<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
    <variable name="nameX"/>
    <variable name="nameY"/>
    <variable name="nickY"/>
      <binding name="nameX">
      <binding name="nameY">
      <binding name="nameX">
      <binding name="nameY">
      <binding name="nickY">

Definition: SELECT

Given Q = (GP, DS, SM, SELECT VS) where

then, if QS is the set of solutions formed by matching dataset DS with graph pattern GP, the SELECT result is project(SM(QS), VS)

Grammar rules:@@

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 output RDF graph. The graph template can contain ground or explicit triples, that is, triples with no variables, and these also appear in the output RDF graph returned by the CONSTRUCT query form.

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

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

creates vcard properties from the FOAF information:

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

<http://example.org/person#Alice> vcard:FN "Alice" .

10.3.1 Templates with Blank Nodes

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

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

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

_:b    foaf:firstname   "Bob" .
_:b    foaf:surname     "Hacker" .
PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
PREFIX vcard:   <http://www.w3.org/2001/vcard-rdf/3.0#>

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

creates vcard properties corresponding to the FOAF information:

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

_:v1 vcard:N         _:x .
_:x vcard:givenName  "Alice" .
_:x vcard:familyName "Hacker" .

_:v2 vcard:N         _:z .
_:z vcard:givenName  "Bob" .
_:z vcard:familyName "Hacker" .

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

10.3.2 Accessing Graphs in the RDF Dataset

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

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

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

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

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

Definition: Graph Template

A graph template is a set of triple patterns.

If T = { tj | j = 1,2 ... m } is a graph template and S is a pattern solution then SC(S, tj) is a set of one RDF triple S(tj) if all variables in tj are in the domain of S. SC(S, tj) is the empty set otherwise.

Write SC(S, T) for the union of SC(S, tj).

Definition: CONSTRUCT

Let Q = (GP, DS, SM, CONSTRUCT T) where

then, if QS is the set of solutions formed by matching dataset DS with graph pattern GP, then write SM(QS) = { Si | i = 1,2 ... n }.

Let Ti be a sequence of sets of triple patterns, such that each Ti is basic graph pattern equivalent to T and no Ti have a blank node in common and no Ti has a blank node in common with any blank node in SM(QS).

Let Ri be the RDF graph formed from SC(Si, Ti).

The CONSTRUCT result is the RDF graph formed by the union of Ri.

Grammar rules:@@

10.3.3 Solution Modifiers and CONSTRUCT

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

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

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

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

_:c foaf:name "Eve" .
_:c site:hits 181 .
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX site: <http://example.org/stats#>

CONSTRUCT { [] foaf:name ?name }
{ [] foaf:name ?name ;
     site:hits ?hits .
ORDER BY desc(?hits)
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
_:x foaf:name "Alice" .
_:y foaf:name "Eve" .

10.4 Descriptions of Resources (Non-normative)

Current conventions for DESCRIBE return an RDF graph without any specified constraints. Future SPARQL specifications may further constrain the results of DESCRIBE, rendering some currently valid DESCRIBE responses invalid. As with any query, a service may refuse to serve a DESCRIBE query.

The DESCRIBE form returns a single result RDF graph containing RDF data about resources. This data is not prescribed by a SPARQL query, where the query client would need to know the structure of the RDF in the data source, but, instead, is determined by the SPARQL query processor. The query pattern is used to create a result set. The DESCRIBE form takes each of the resources identified in a solution, together with any resources directly named by IRI, and assembles a single RDF graph by taking a "description" from the target knowledge base. The description is determined by the query service. The syntax DESCRIBE * is an abbreviation that identifies all of the variables in a query.

10.4.1 Explicit IRIs

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

DESCRIBE <http://example.org/>

10.4.2 Identifying Resources

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

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

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

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

More than one IRI or variable can be given:

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

10.4.3 Descriptions of Resources

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

A simple query such as

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

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

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

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

foaf:mbox_sha1sum  rdf:type  owl:InverseFunctionalProperty .

which includes the blank node closure for the vcard vocabulary vcard:N. Other possible mechanisms for deciding what information to return include Concise Bounded Descriptions [CBD].

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 like name and other details recorded would be appropriate. In the example, the match to the WHERE clause was returned but this is not required.

Definition: DESCRIBE

Let Q = (GP, DS, SM, DESCRIBE V) where

then, if QS is the set of solutions formed by matching dataset DS with graph pattern GP, the DESCRIBE result is an RDF graph formed by information relating elements of
distinct(U union project(SM(QS), VS)).

This definition intentionally does not prescribe the nature of the relevant information.

Grammar rules:@@

10.5 Asking "yes or no" questions

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

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

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

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

The SPARQL Query Results XML Format form of this result set gives:

<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">

On the same data, the following returns no match because Alice's mbox is not mentioned.

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

Definition: ASK

Let Q = (GP, DS, SM, ASK) where

and QS is the set of solutions formed by matching dataset DS with graph pattern GP then the ASK result is true if SM(QS) is not empty, otherwise it is false.

Grammar rules:@@

11 Testing Values

SPARQL FILTERs restrict the set of solutions according to a given expression. Specifically, FILTERs eliminate any solutions that, when substituted into the expression, either result in an effective boolean value of false or produce an error. Effective boolean values are defined in section 11.2.2 Effective Boolean Value; errors are defined in XQuery 1.0: An XML Query Language [XQUERY] section 2.3.1, Kinds of Errors.

As stated in section 4.1, RDF Terms are made of IRIs, Literals and Blank Nodes. RDF Literals may have a datatype IRI:

@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:date       "2004-12-31T19:00:00-05:00" .

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

The first dc:date arc has no type information. The second has the datatype xsd:dateTime.

SPARQL expressions are constructed according to the grammar and provide access to functions (named by IRI) and operator functions (invoked by keywords and symbols in the SPARQL grammar). SPARQL operators can be used to compare the values of typed 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:date      ?date .
        FILTER ( ?date > "2005-01-01T00:00:00Z"^^xsd:dateTime ) }

The SPARQL operators are listed in section 11.3 and are associated with their productions in the grammar.

In addition, SPARQL provides the ability to invoke arbitrary functions, including a subset of the XPath casting functions, listed in section 11.5. The are invoked by name (an IRI) within a SPARQL query:

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

The following typographical conventions are used in this section:

11.1 Operand Data Types

SPARQL functions and operators operate on RDF terms and SPARQL variables. A subset of these functions and operators are taken from the XQuery 1.0 and XPath 2.0 Functions and Operators [FUNCOP] and have XML Schema typed value arguments and return types. RDF typed literals passed as arguments to these functions and operators are mapped to XML Schema typed values with a string value of the lexical form and an atomic datatype corresponding to the datatype IRI. The returned typed values are mapped back to RDF typed literals @@by reversing this mapping@@.

SPARQL has additional operators which operate on specific subsets of RDF terms. The following terms are imported from Resource Description Framework (RDF): Concepts and Abstract Syntax [CONCEPTS]:

When referring to a type, the following terms denote a typed literal with the corresponding XML Schema [XSDT] datatype IRI:

The following terms identify additional types used in SPARQL value tests:

The following types are dervived from numeric types:

Extended SPARQL implementations may treat additional types as being derived from numeric types.

11.2 Filter Evaluation

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:

The logical-and and logical-or truth table for true (T), false (F), and error (E) is as follows:

ABA || BA && B

11.2.1 Invocation

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

If any of these steps fails, the invocation generates an error. The effects of errors are defined in Filter Evaluation.

11.2.2 Effective Boolean Value (EBV)

The XQuery Effective Boolean Value rules rely on the definition of XPath's fn:boolean. The following rules reflect the rules for fn:boolean applied to the argument types present in SPARQL Queries:

An EBV of true is represented as a typed literal with a datatype of xsd:boolean and a lexical value of "true"; an EBV of false is represented with a lexical value of "false".

[Informative: Effective boolean value is used to calculate the arguments to the logical functions logical-and, logical-or, and fn:not, as well as evaluate the result of a filter.]

11.3 Operator Mapping

The SPARQL grammar identifies a set of operators (for instance, &&, *, isIRI) used to construct constraints. The following table associates each of these grammatical productions with the appropriate operands and an operator function defined by either XQuery 1.0 and XPath 2.0 Functions and Operators [FUNCOP] or the SPARQL operators specified in section 11.4. When selecting the operator definition for a given set of parameters, the definition with the most specific parameters applies. For instance, when evaluating xsd:integer = xsd:signedInt, the definition for = with two numeric parameters applies, rather than the one with two RDF terms. The table is arranged so that upper-most viable candiate is the most specific. Operators invoked without appropriate operands result in a type error.

SPARQL follows XPath's scheme for numeric type promotions and subtype substitution for arguments to numeric operators. The XPath Operator Mapping rules for numeric operands {xs:integer, xs:decimal, xs:float, xs:double, and types derived from a numeric type} apply to SPARQL operators as well (see XML Path Language (XPath) 2.0 [XPATH20] for defintions of numeric type promotions and subtype substitution). Some of the operators are associated 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 produce an error if their argument is an error.

The collation for fn:compare is defined by XPath and identified by http://www.w3.org/2005/xpath-functions/collation/codepoint. This collation allows for string comparison based on code point values. Codepoint string equivilence can be tested with RDF term equivilence.

SPARQL Unary Operators
Operator Type(A)FunctionResult type
XQuery Unary Operators
! A xsd:booleanfn:not(A)xsd:boolean
+ A numericop:numeric-unary-plus(A)numeric
- A numericop:numeric-unary-minus(A)numeric
SPARQL Tests, defined in section 11.4
BOUND(A) variablebound(A)xsd:boolean
RDF termisIRI(A)xsd:boolean
isBLANK(A) RDF termisBlank(A)xsd:boolean
isLITERAL(A) RDF termisLiteral(A)xsd:boolean
SPARQL Accessors
STR(A) literalstr(A)simple literal
STR(A) IRIstr(A)simple literal
LANG(A) literallang(A)simple literal
DATATYPE(A) RDF termdatatype(A)IRI
SPARQL Binary Operators
Operator Type(A)Type(B)FunctionResult type
Logical Connectives, defined in section 11.4
A || B xsd:booleanxsd:booleanlogical-or(A, B)xsd:boolean
A && B xsd:booleanxsd:booleanlogical-and(A, B)xsd:boolean
XPath Tests
A = B numericnumericop:numeric-equal(A, B)xsd:boolean
A = B simple literalsimple literalop:numeric-equal(fn:compare(A, B), 0)xsd:boolean
A = B xsd:stringxsd:stringop:numeric-equal(fn:compare(STR(A), STR(B)), 0)xsd:boolean
A = B xsd:booleanxsd:booleanop:boolean-equal(A, B)xsd:boolean
A = B xsd:dateTimexsd:dateTimeop:dateTime-equal(A, B)xsd:boolean
A != B numericnumericfn:not(op:numeric-equal(A, B))xsd:boolean
A != B simple literalsimple literalfn:not(op:numeric-equal(fn:compare(A, B), 0))xsd:boolean
A != B xsd:stringxsd:stringfn:not(op:numeric-equal(fn:compare(STR(A), STR(B)), 0))xsd:boolean
A != B xsd:booleanxsd:booleanfn:not(op:boolean-equal(A, B))xsd:boolean
A != B xsd:dateTimexsd:dateTimefn:not(op:dateTime-equal(A, B))xsd:boolean
A < B numericnumericop:numeric-less-than(A, B)xsd:boolean
A < B simple literalsimple literalop:numeric-equal(fn:compare(A, B), -1)xsd:boolean
A < B xsd:stringxsd:stringop:numeric-equal(fn:compare(STR(A), STR(B)), -1)xsd:boolean
A < B xsd:booleanxsd:booleanop:boolean-less-than(A, B)xsd:boolean
A < B xsd:dateTimexsd:dateTimeop:dateTime-less-than(A, B)xsd:boolean
A > B numericnumericop:numeric-greater-than(A, B)xsd:boolean
A > B simple literalsimple literalop:numeric-equal(fn:compare(A, B), 1)xsd:boolean
A > B xsd:stringxsd:stringop:numeric-equal(fn:compare(STR(A), STR(B)), 1)xsd:boolean
A > B xsd:booleanxsd:booleanop:boolean-greater-than(A, B)xsd:boolean
A > B xsd:dateTimexsd:dateTimeop:dateTime-greater-than(A, B)xsd:boolean
A <= B numericnumericlogical-or(op:numeric-less-than(A, B), op:numeric-equal(A, B))xsd:boolean
A <= B simple literalsimple literalfn:not(op:numeric-equal(fn:compare(A, B), 1))xsd:boolean
A <= B xsd:stringxsd:stringfn:not(op:numeric-equal(fn:compare(STR(A), STR(B)), 1))xsd:boolean
A <= B xsd:booleanxsd:booleanfn:not(op:boolean-greater-than(A, B))xsd:boolean
A <= B xsd:dateTimexsd:dateTimefn:not(op:dateTime-greater-than(A, B))xsd:boolean
A >= B numericnumericlogical-or(op:numeric-greater-than(A, B), op:numeric-equal(A, B))xsd:boolean
A >= B simple literalsimple literalfn:not(op:numeric-equal(fn:compare(A, B), -1))xsd:boolean
A >= B xsd:stringxsd:stringfn:not(op:numeric-equal(fn:compare(STR(A), STR(B)), -1))xsd:boolean
A >= B xsd:booleanxsd:booleanfn:not(op:boolean-less-than(A, B))xsd:boolean
A >= B xsd:dateTimexsd:dateTimefn:not(op:dateTime-less-than(A, B))xsd:boolean
XPath Arithmetic
A * B numericnumericop:numeric-multiply(A, B)numeric
A / B numericnumericop:numeric-divide(A, B)numeric; but xsd:decimal if both operands are xsd:integer
A + B numericnumericop:numeric-add(A, B)numeric
A - B numericnumericop:numeric-subtract(A, B)numeric
SPARQL Tests, defined in section 11.4
A = B RDF termRDF termRDFterm-equal(A, B)xsd:boolean
A != B RDF termRDF termfn:not(RDFterm-equal(A, B))xsd:boolean
sameTERM(A) RDF termRDF termsameTerm(A, B)xsd:boolean
langMATCHES(A, B) simple literalsimple literallangMatches(A, B)xsd:boolean
REGEX(STRING, PATTERN) simple literalsimple literalfn:matches(STRING, PATTERN)xsd:boolean
SPARQL Trinary Operators
Operator Type(A)Type(B)Type(C)FunctionResult type
SPARQL Tests, defined in section 11.4
REGEX(STRING, PATTERN, FLAGS) simple literalsimple literalsimple literalfn:matches(STRING, PATTERN, FLAGS)xsd:boolean

11.3.1 Operator Extensibility

Extended SPARQL implementations may support additional associations between operators and operator functions; this amounts to adding rows to the table above. No additional operator support may yield a result that replaces any result other than a type error in an unextended implementation. The consequence of this rule is that extended SPARQL implementations will produce at least the same solutions as an unextended implementation, and may, for some queries, produce more solutions.

11.4 Operators Definitions

This section defines the operators introduced by the SPARQL Query language. The examples show the behavior of the operators as invoked by the appropriate grammatical constructs.

11.4.1 bound

 xsd:boolean   bound (variable var)

Returns true if a var is bound to a value. Returns false otherwise. Variables with the value NaN or INF are considered bound. See 6.3 Unbound Variables for a discussion of why variables may be unbound.

@@ 6.3 may be removed.


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

_:a  foaf:givenName  "Alice".

_:b  foaf:givenName  "Bob" .
_:b  dc:date         "2005-04-04T04:04:04Z"^^xsd:dateTime .
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dc:   <http://purl.org/dc/elements/1.1/>
PREFIX xsd:   <http://www.w3.org/2001/XMLSchema#>
SELECT ?name
 WHERE { ?x foaf:givenName  ?givenName .
         OPTIONAL { ?x dc:date ?date } .
         FILTER ( bound(?date) ) }

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 date:

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

Query result:


Because Bob's dc:date was known, "Bob" was not a solution to the query.

11.4.2 isIRI

 xsd:boolean   isIRI (RDF term term)
 xsd:boolean   isURI (RDF term term)

Returns true if term is an IRI. Returns false otherwise. isURI is an alternate spelling for the isIRI operator.

@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       "bob@work.example" .

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

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

Query result:

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

11.4.3 isBlank

 xsd:boolean   isBlank (RDF term term)

Returns true if term is a blank node. Returns false otherwise.

@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 dc:creator which uses predicates from the FOAF vocabulary to express the name.

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:

given family
"Bob" "Smith"

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

11.4.4 isLiteral

 xsd:boolean   isLiteral (RDF term term)

Returns true if term is a literal. Returns false otherwise.

@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       "bob@work.example" .

This query is similar to the one in 11.4.2 except that is matches the people with a name and an mbox which is a literal. This could be used to look for erroneous data (foaf:mbox should only have an IRI 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:

name mbox
"Bob" "bob@work.example"

11.4.5 str

 simple literal   str (literal ltrl)
 simple literal   str (IRI rsrc)

Returns the lexical form of ltrl, a literal; returns the codepoint representation of rsrc (an IRI). This is useful for examining parts of an IRI, for instance, the host-name.

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

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

11.4.6 lang

 simple literal   lang (literal ltrl)

Returns the language tag of ltrl, if it has one. It returns "" if ltrl has no language tag.

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

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

name mbox
"Roberto"@ES <mailto:bob@work.example>

11.4.7 datatype

 IRI   datatype (RDF term ltrl)

Returns the datatype IRI of ltrl if ltrl is a typed literal; returns xsd:string if ltrl is a simple literal; produces an error otherwise.

@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 the foaf:name and foaf:shoeSize of everyone with a shoeSize that is an integer:

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

Query result:

name shoeSize
"Bob" 42

11.4.8 logical-or

 xsd:boolean   xsd:boolean left || xsd:boolean right

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

Note: see section 11.2, Filter Evaluation, for the || operator's treatment of errors.

11.4.9 logical-and

 xsd:boolean   xsd:boolean left && xsd:boolean right

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

Note: see section 11.2, Filter Evaluation, for the && operator's treatment of errors.

11.4.10 RDFterm-equal

 xsd:boolean   RDF term term1 = RDF term term2

Returns TRUE if term1 and term2 are the same RDF term as defined in Resource Description Framework (RDF): Concepts and Abstract Syntax [CONCEPTS]; produces a type error if the arguments are both literal but are not the same RDF term *; returns FALSE otherwise. term1 and term2 are the same if any of the following is true:

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

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

name1 name2
"Alice" "Ms A."
"Ms A." "Alice"

In this query for documents that were annotated on New Year's 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:date       "2004-12-31T19:00: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:date      ?date .
        FILTER ( ?date = xsd:dateTime("2005-01-01T00:00:00Z") ) }

* Invoking RDFterm-equal on two types literals tests for equivilent values. An extended implementation may have support for additional datatypes. An implementation processing a query that tests for equivalence on unsupported datatypes (and non-identical lexical form and datatype URI) returns an error, indicating that it was unable to determine whether or not the values are equivalent. For example, an unextended implementation will produce an error when testing either "iiii"^^my:romanNumeral = "iv"^^my:romanNumeral or "iiii"^^my:romanNumeral != "iv"^^my:romanNumeral.

11.4.10bis sameTerm

 xsd:boolean   sameTerm (RDF term language-tag, RDF term language-range)

Returns TRUE if term1 and term2 are the same RDF term as defined in Resource Description Framework (RDF): Concepts and Abstract Syntax [CONCEPTS]; returns FALSE otherwise.

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

_: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 (sameTerm(?mbox1, ?mbox2) && !sameTerm(?name1, ?name2))

Query result:

name1 name2
"Alice" "Ms A."
"Ms A." "Alice"

Unlike RDFterm-equal, sameTerm can be used to test for non-equivilent typed literals with unsupported data types:

@prefix :          <http://example.org/WMterms#> .
@prefix t:         <http://example.org/types#> .

_:c1  :label        "Container 1" .
_:c1  :weight       "100"^^t:kilos .
_:c1  :displacment  "100"^^t:liters .

_:c2  :label        "Container 2" .
_:c2  :weight       "100"^^t:kilos .
_:c2  :displacment  "85"^^t:liters .

_:c3  :label        "Container 3" .
_:c3  :weight       "85"^^t:kilos .
_:c3  :displacment  "85"^^t:liters .
PREFIX  :      <http://example.org/WMterms#>
PREFIX  t:     <http://example.org/types#>

SELECT ?aLabel1 ?bLabel
WHERE { ?a  :label        ?aLabel .
        ?a  :weight       ?aWeight .
        ?a  :displacement ?aDisp .

        ?b  :label        ?bLabel .
        ?b  :weight       ?bWeight .
        ?b  :displacement ?bDisp .

        FILTER ( sameTerm(?aWeight, ?bWeight) && !sameTerm(?aDisp, ?bDisp) }
aLabel bLabel
"Container 1" "Container 2"
"Container 2" "Container 1"

The test for boxes with the same weight may also be done with the '=' operator (RDFterm-equal) as the test for "100"^^t:kilos = "85"^^t:kilos will result in an error, eliminating that potential solution. In the same way that pointer comparisons are usually more efficient than value comparisons, sameTerm is likely to be more efficient than RDFterm-equal. @@is that worth mentioning?@@

11.4.11 langMatches

 xsd:boolean   langMatches (simple literal language-tag, simple literal language-range)

Returns true if language-range (second argument) matches language-tag (first argument) per Tags for the Identification of Languages [RFC3066] section 2.5. RFC3066 @@reference rfc4647 (3066bis) term "well-formed" if the RFC is ready in time@@ defines a case-insensitive, hierarchical matching algorithm which operates on ISO-defined subtags for language and country codes, and user defined subtags. In SPARQL, a language-range of "*" matches any non-empty language-tag string.

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

_:a  dc:title         "That Seventies Show"@en .
_:a  dc:title         "Cette Série des Années Soixante-dix"@fr .
_:a  dc:title         "Cette Série des Années Septante"@fr-BE .
_:b  dc:title         "Il Buono, il Bruto, il Cattivo" .

This query uses langMatches and lang (described in section to find the French titles for the show known in English as "That Seventies Show":

PREFIX dc: <http://purl.org/dc/elements/1.1/>
SELECT ?title
 WHERE { ?x dc:title  "That Seventies Show"@en ;
            dc:title  ?title .
         FILTER langMatches( lang(?title), "FR" ) }

Query result:

"Cette Série des Années Soixante-dix"@fr
"Cette Série des Années Septante"@fr-BE

The idiom langMatches( lang( ?v ), "*" ) will not match literals without a language tag as lang( ?v ) will return an empty string, so

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

will report all of the titles with a language tag:

"That Seventies Show"@en
"Cette Série des Années Soixante-dix"@fr
"Cette Série des Années Septante"@fr-BE

11.4.12 regex

 xsd:boolean   regex (simple literal text, simple literal pattern)
 xsd:boolean   regex (simple literal text, simple literal pattern, simple literal flags)

Invokes the XPath fn:matches function to match text against a regular expression pattern. The regular expression language is defined in XQuery 1.0 and XPath 2.0 Functions and Operators section 7.6.1 Regular Expression Syntax [FUNCOP].

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

_:a  foaf:name       "Alice".
_:b  foaf:name       "Bob" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name
 WHERE { ?x foaf:name  ?name
         FILTER regex(?name, "^ali", "i") }

Query result:


11.5 Constructor Functions

SPARQL imports a subset of the XPath constructor functions defined in XQuery 1.0 and XPath 2.0 Functions and Operators [FUNCOP] in section 17.1 Casting from primitive types to primitive types. SPARQL constructors include all of the XPath constructors for the SPARQL operand data types plus the additional datatypes imposed by the RDF data model. Casting in SPARQL is performed by calling a constructor function for the target type on an operand of the source type.

XPath defines only the casts from one XML Schema datatype to another. The remaining casts are defined as follows:

The table below summarizes the casting operations that are always allowed (Y), never allowed (N) and dependent on the lexical value (M). For example, a casting operation from an xsd:string (the first row) to an xsd:float (the second column) is dependent on the lexical value (M).

bool = xsd:boolean
dbl = xsd:double
flt = xsd:float
dec = xsd:decimal
int = xsd:integer
dT = xsd:dateTime
str = xsd:string
ltrl = simple literal

From \ To str flt dbl dec int dT bool
str Y M M M M M M
flt Y Y Y M M N Y
dbl Y Y Y M M N Y
dec Y Y Y Y Y N Y
int Y Y Y Y Y N Y
dT Y N N N N Y N
bool Y Y Y Y Y N Y
ltrl Y M M M M M M

11.6 Extensible Value Testing

A PrimaryExpression (see the grammar, production [55]) can be a call to an extension function named by an IRI. An extension function takes some number of RDF terms as arguments and returns an RDF term. The semantics of these functions are identified by the IRI that identifies the function.

@@ Check the reference into the grammar

SPARQL queries using extension functions are likely to have limited interoperability.

As an example, consider a function called func:even:

 xsd:boolean   func:even (numeric value)

This function would be invoked in a FILTER as such:

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

For a second example, consider a function aGeo:distance that calculates the distance between two points, which is used here to find the places near Grenoble:

 xsd:boolean   aGeo:distance (numeric x, numeric y)
PREFIX aGeo: <http://example.org/geo#>

SELECT ?neighbor
WHERE { ?a aGeo:placeName "Grenoble" .
        ?a aGeo:location ?axLoc .
        ?a aGeo:location ?ayLoc .

        ?b aGeo:placeName ?neighbor .
        ?b aGeo:location ?bxLoc .
        ?b aGeo:location ?byLoc .

        FILTER ( aGeo:distance(?axLoc, ?ayLoc, ?bxLoc, ?byLoc) < 10 ) .

An extension function 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.

A. SPARQL Grammar

@@This section . . .

A.1 SPARQL Query String

A SPARQL query string is a Unicode character string (c.f. section 6.1 String concepts of [CHARMOD]) in the language defined by the following grammar, starting with the Query production. For compatibility with future versions of Unicode, the characters in this string may include Unicode codepoints that are unassigned as of the date of this publication (see Identifier and Pattern Syntax [UNIID] section 4 Pattern Syntax). For productions with excluded character classes (for example [^<>'{}|^`]), the characters are excluded from the range #x0 - #x10FFFF.

A.2 Codepoint Escape Sequences

A SPARQL Query String is processed for codepoint escape sequences before parsing by the grammar defined in EBNF below. The codepoint escape sequences for a SPARQL query string are:

Escape Unicode code point
'\u' HEX HEX HEX HEX A Unicode code point in the range U+0 to U+FFFF inclusive corresponding to the encoded hexadecimal value.
'\U' HEX HEX HEX HEX HEX HEX HEX HEX A Unicode code point in the range U+0 to U+10FFFF inclusive corresponding to the encoded hexadecimal value.


<ab\u00E9xy>        # Codepoint 00E9 is Latin small e with acute - é
\u03B1:a            # Codepoint x03B1 is Greek small alpha - α
a\u003Ab            # a:b -- codepoint x3A is colon

Codepoint escape sequences can appear anywhere in the query string. They are processed before parsing based on the grammar rules and so may be replaced by codepoints with significance in the grammar, such as ":" marking a prefixed name.

These escape sequences are not included in the grammar below. Only escape sequences for characters that would be legal at that point in the grammar may be given. For example, the variable "?x\u0020y" is not legal (\u0020 is a space and is not permitted in a variable name).

A.3 White Space

White space (production WS) is used to separate two terminals which would otherwise be (mis-)recognized as one terminal. Rule names below in capitals indicate where whitespace is significant; these form a possible choice of terminals for constructing a SPARQL parser. White space is significant in strings.

@@ Example ?a<?b&&?c>&d

A.4 Comments

Comments in SPARQL queries take the form of '#', outside an IRI or string, and continue to the end of line (marked by characters 0x0D or 0x0A) or end of file if there is no end of line after the comment marker. Comments are treated as white space.

A.5 IRI References

Text matched by the Q_IRI_REF production and QName (after prefix expansion) production, after escape processing, must be conform to the generic syntax of IRI references in section 2.2 of RFC 3987 "ABNF for IRI References and IRIs" [RFC3987]. For example, the Q_IRI_REF <abc#def> may occur in a SPARQL query string, but the Q_IRI_REF <abc##def> must not.

Base IRIs declared with the BASE keyword must be absolute IRIs. A prefix declared with the PREFIX keyword may not be re-declared in the same query. See see section 2.1.1, Syntax of IRI Terms, for a description of BASE and PREFIX.

A.6 Escape sequences in strings

In addition to the codepoint escape sequences, the following escape sequences any string production (e.g. STRING_LITERAL1, STRING_LITERAL2, STRING_LITERAL_LONG1, STRING_LITERAL_LONG2):

Escape Unicode code point
'\t' U+0009 (tab)
'\n' U+000A (line feed)
'\r' U+000D (carriage return)
'\b' U+0008 (backspace)
'\f' U+000C (form feed)
'\"' U+0022 (quotation mark, double quote mark)
"\'" U+0027 (apostrophe-quote, single quote mark)
'\\' U+005C (backslash)

where HEX is a hexadecimal character

HEX ::= [0-9] | [A-F] | [a-f]

Any escaped character in the range #x0 - #x10FFFF may appear in any string production. For instance, "\n" may appear in a STRING_LITERAL1 even though the unescaped form is not valid in that production.



A.7 Grammar

The EBNF notation used in the grammar is defined in Extensible Markup Language (XML) 1.1 [XML11] section 6 Notation.

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

@@keywords are ...

Escape sequences are case sensitive.

When choosing a rule to match, the longest match is chosen.

[1]   Query   ::=   Prolog
( SelectQuery | ConstructQuery | DescribeQuery | AskQuery )
[2]   Prolog   ::=   BaseDecl? PrefixDecl*
[3]   BaseDecl   ::=   'BASE' Q_IRI_REF
[4]   PrefixDecl   ::=   'PREFIX' QNAME_NS Q_IRI_REF
[5]   SelectQuery   ::=   'SELECT' 'DISTINCT'? ( Var+ | '*' ) DatasetClause* WhereClause SolutionModifier
[6]   ConstructQuery   ::=   'CONSTRUCT' ConstructTemplate DatasetClause* WhereClause SolutionModifier
[7]   DescribeQuery   ::=   'DESCRIBE' ( VarOrIRIref+ | '*' ) DatasetClause* WhereClause? SolutionModifier
[8]   AskQuery   ::=   'ASK' DatasetClause* WhereClause
[9]   DatasetClause   ::=   'FROM' ( DefaultGraphClause | NamedGraphClause )
[10]   DefaultGraphClause   ::=   SourceSelector
[11]   NamedGraphClause   ::=   'NAMED' SourceSelector
[12]   SourceSelector   ::=   IRIref
[13]   WhereClause   ::=   'WHERE'? GroupGraphPattern
[14]   SolutionModifier   ::=   OrderClause? LimitOffsetClauses?
[15]   LimitOffsetClauses   ::=   ( LimitClause OffsetClause? | OffsetClause LimitClause? )
[16]   OrderClause   ::=   'ORDER' 'BY' OrderCondition+
[17]   OrderCondition   ::=   ( ( 'ASC' | 'DESC' ) BrackettedExpression )
| ( FunctionCall | BuiltInCall | Var | BrackettedExpression )
[18]   LimitClause   ::=   'LIMIT' INTEGER
[19]   OffsetClause   ::=   'OFFSET' INTEGER
[20]   GroupGraphPattern   ::=   '{' GroupElement '}'
[21]   GroupElement   ::=   GraphPattern ( OptionalGraphPattern '.'? GroupElement )?
[22]   GraphPattern   ::=   BasicGraphPattern? ( GraphPatternNotTriples '.'? GraphPattern )?
[23]   BasicGraphPattern   ::=   BlockOfTriples
[24]   BlockOfTriples   ::=   TriplesSameSubject ( '.' TriplesSameSubject? )*
[25]   GraphPatternNotTriples   ::=   GroupOrUnionGraphPattern | GraphGraphPattern | Constraint
[26]   OptionalGraphPattern   ::=   'OPTIONAL' GroupGraphPattern
[27]   GraphGraphPattern   ::=   'GRAPH' VarOrIRIref GroupGraphPattern
[28]   GroupOrUnionGraphPattern   ::=   GroupGraphPattern ( 'UNION' GroupGraphPattern )*
[29]   Constraint   ::=   'FILTER' ( BrackettedExpression | BuiltInCall | FunctionCall )
[30]   FunctionCall   ::=   IRIref ArgList
[31]   ArgList   ::=   ( NIL | '(' Expression ( ',' Expression )* ')' )
[32]   ConstructTemplate   ::=   '{' ConstructTriples '}'
[33]   ConstructTriples   ::=   ( TriplesSameSubject ( '.' ConstructTriples )? )?
[34]   TriplesSameSubject   ::=   VarOrTerm PropertyListNotEmpty | TriplesNode PropertyList
[35]   PropertyList   ::=   PropertyListNotEmpty?
[36]   PropertyListNotEmpty   ::=   Verb ObjectList ( ';' PropertyList )?
[37]   ObjectList   ::=   GraphNode ( ',' ObjectList )?
[38]   Verb   ::=   VarOrIRIref | 'a'
[39]   TriplesNode   ::=   Collection | BlankNodePropertyList
[40]   BlankNodePropertyList   ::=   '[' PropertyListNotEmpty ']'
[41]   Collection   ::=   '(' GraphNode+ ')'
[42]   GraphNode   ::=   VarOrTerm | TriplesNode
[43]   VarOrTerm   ::=   Var | GraphTerm
[44]   VarOrIRIref   ::=   Var | IRIref
[45]   Var   ::=   VAR1 | VAR2
[46]   GraphTerm   ::=   IRIref | RDFLiteral | ( '-' | '+' )? NumericLiteral | BooleanLiteral | BlankNode | NIL
[47]   Expression   ::=   ConditionalOrExpression
[48]   ConditionalOrExpression   ::=   ConditionalAndExpression ( '||' ConditionalAndExpression )*
[49]   ConditionalAndExpression   ::=   ValueLogical ( '&&' ValueLogical )*
[50]   ValueLogical   ::=   RelationalExpression
[51]   RelationalExpression   ::=   NumericExpression ( '=' NumericExpression | '!=' NumericExpression | '<' NumericExpression | '>' NumericExpression | '<=' NumericExpression | '>=' NumericExpression )?
[52]   NumericExpression   ::=   AdditiveExpression
[53]   AdditiveExpression   ::=   MultiplicativeExpression ( '+' MultiplicativeExpression | '-' MultiplicativeExpression )*
[54]   MultiplicativeExpression   ::=   UnaryExpression ( '*' UnaryExpression | '/' UnaryExpression )*
[55]   UnaryExpression   ::=     '!' PrimaryExpression
| '+' PrimaryExpression
| '-' PrimaryExpression
| PrimaryExpression
[56]   PrimaryExpression   ::=   BrackettedExpression | BuiltInCall | IRIrefOrFunction | RDFLiteral | NumericLiteral | BooleanLiteral | Var
[57]   BrackettedExpression   ::=   '(' Expression ')'
[58]   BuiltInCall   ::=     'STR' '(' Expression ')'
| 'LANG' '(' Expression ')'
| 'LANGMATCHES' '(' Expression ',' Expression ')'
| 'DATATYPE' '(' Expression ')'
| 'BOUND' '(' Var ')'
| 'sameTerm' '(' Expression ',' Expression ')'
| 'isIRI' '(' Expression ')'
| 'isURI' '(' Expression ')'
| 'isBLANK' '(' Expression ')'
| 'isLITERAL' '(' Expression ')'
| RegexExpression
[59]   RegexExpression   ::=   'REGEX' '(' Expression ',' Expression ( ',' Expression )? ')'
[60]   IRIrefOrFunction   ::=   IRIref ArgList?
[61]   RDFLiteral   ::=   String ( LANGTAG | ( '^^' IRIref ) )?
[62]   NumericLiteral   ::=   INTEGER | DECIMAL | DOUBLE
[63]   BooleanLiteral   ::=   'true' | 'false'
[65]   IRIref   ::=   Q_IRI_REF | QName
[66]   QName   ::=   QNAME | QNAME_NS
[67]   BlankNode   ::=   BLANK_NODE_LABEL | ANON
[68]   Q_IRI_REF   ::=   '<' ([^<>'{}|^`]-[#x00-#x20])* '>'
[69]   QNAME_NS   ::=   NCNAME_PREFIX? ':'
[70]   QNAME   ::=   NCNAME_PREFIX? ':' NCNAME?
[71]   BLANK_NODE_LABEL   ::=   '_:' NCNAME
[72]   VAR1   ::=   '?' VARNAME
[73]   VAR2   ::=   '$' VARNAME
[74]   LANGTAG   ::=   '@' [a-zA-Z]+ ('-' [a-zA-Z0-9]+)*
[75]   INTEGER   ::=   [0-9]+
[76]   DECIMAL   ::=   [0-9]+ '.' [0-9]* | '.' [0-9]+
[77]   DOUBLE   ::=   [0-9]+ '.' [0-9]* EXPONENT | '.' ([0-9])+ EXPONENT | ([0-9])+ EXPONENT
[78]   EXPONENT   ::=   [eE] [+-]? [0-9]+
[79]   STRING_LITERAL1   ::=   "'" ( ([^#x27#x5C#xA#xD]) | ECHAR )* "'"
[80]   STRING_LITERAL2   ::=   '"' ( ([^#x22#x5C#xA#xD]) | ECHAR )* '"'
[81]   STRING_LITERAL_LONG1   ::=   "'''" ( ( "'" | "''" )? ( [^'\] | ECHAR ) )* "'''"
[82]   STRING_LITERAL_LONG2   ::=   '"""' ( ( '"' | '""' )? ( [^"\] | ECHAR ) )* '"""'
[83]   ECHAR   ::=   '\' [tbnrf\"']
[84]   HEX   ::=   [0-9] | [A-F] | [a-f]
[85]   NIL   ::=   '(' WS* ')'
[86]   WS   ::=   #x20 | #x9 | #xD | #xA
[87]   ANON   ::=   '[' WS* ']'
[88]   NCCHAR1P   ::=   [A-Z] | [a-z] | [#x00C0-#x00D6] | [#x00D8-#x00F6] | [#x00F8-#x02FF] | [#x0370-#x037D] | [#x037F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]
[89]   NCCHAR1   ::=   NCCHAR1P | '_'
[90]   VARNAME   ::=   ( NCCHAR1 | [0-9] ) ( NCCHAR1 | [0-9] | #x00B7 | [#x0300-#x036F] | [#x203F-#x2040] )*
[91]   NCCHAR   ::=   NCCHAR1 | '-' | [0-9] | #x00B7 | [#x0300-#x036F] | [#x203F-#x2040]
[93]   NCNAME   ::=   NCCHAR1 ((NCCHAR|'.')* NCCHAR)?

The SPARQL grammar is LL(1) when the rules with uppercased names are used as terminals.

Some grammar files for some commonly used tools are avaiable here (parsers/).

B. Conformance

See appendix A SPARQL Grammar regarding conformance of SPARQL Query strings, and section 10 Query Result Forms for conformance of query results. See appendix E. Internet Media Type for conformance to the application/sparql-query media type.

This specification is intended for use in conjunction with the SPARQL Protocol [SPROT] and the SPARQL Query Results XML Format [RESULTS]. See those specifications for their conformance criteria.

Note that the SPARQL protocol describes an abstract interface as well as a network protocol, and the abstract interface may apply to APIs as well as network interfaces.

C. Security Considerations

SPARQL queries using FROM, FROM NAMED, or GRAPH may cause the specified URI to be dereferenced. This may cause additional use of network, disk or CPU resources along with associated secondary issues such as denial of service. The security issues of Uniform Resource Identifier (URI): Generic Syntax [RFC3986] Section 7 should be considered. In addition, the contents of file: URIs can in some cases be accessed, processed and returned as results, providing unintended access to local resources.

The SPARQL language permits extensions, which will have their own security implications.

Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "о" may appear similar to a Latin "o"). A character followed by combining characters may have the same visual representation as another character (LATIN SMALL LETTER E followed by COMBINING ACUTE ACCENT has the same visual representation as LATIN SMALL LETTER E WITH ACUTE). Users of SPARQL must take care to construct queries with IRIs that match the IRIs in the data. Further information about matching of similar characters can be found in Unicode Security Considerations [UNISEC] and Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8.

D. Collected Formal Definitions

The collected formal definitions are collected into a single document "SPARQL Query Language for RDF - Formal Definitions".

E. Internet Media Type, File Extension and Macintosh File Type (Normative)

Eric Prud'hommeaux
See also:
How to Register a Media Type for a W3C Specification
Internet Media Type registration, consistency of use
TAG Finding 3 June 2002 (Revised 4 September 2002)

The Internet Media Type / MIME Type for the SPARQL Query Language is "application/sparql-query".

It is recommended that sparql query files have the extension ".rq" (all lowercase) on all platforms.

It is recommended that sparql query files stored on Macintosh HFS file systems be given a file type of "TEXT".

This information that follows is intended to be submitted to the IESG for review, approval, and registration with IANA.

Type name:
Subtype name:
Required parameters:
Optional parameters:
Encoding considerations:
The syntax of the SPARQL Query Language is expressed over code points in Unicode [UNICODE]. The encoding is always UTF-8 [RFC3629].
Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F]
Security considerations:
See SPARQL Query appendix C, Security Considerations as well as RFC 3629 [RFC3629] section 7, Security Considerations.
Interoperability considerations:
There are no known interoperability issues.
Published specification:
This specification.
Applications which use this media type:
No known applications currently use this media type.
Additional information:
Magic number(s):
A SPARQL query may have the string 'PREFIX' (case independent) near the beginning of the document.
File extension(s):
Base URI:
The SPARQL 'BASE <IRIref>' term can change the current base URI for relative IRIrefs in the query language that are used sequentially later in the document.
Macintosh file type code(s):
Person & email address to contact for further information:
Intended usage:
Restrictions on usage:
Author/Change controller:
The SPARQL specification is a work product of the World Wide Web Consortium's RDF Data Access Working Group. The W3C has change control over these specifications.

F. References

Normative References

Character Model for the World Wide Web 1.0: Fundamentals , R. Ishida, F. Yergeau, M. J. Düst, M. Wolf, T. Texin, Editors, W3C Recommendation, 15 February 2005, http://www.w3.org/TR/2005/REC-charmod-20050215/ . Latest version available at http://www.w3.org/TR/charmod/ .
Resource Description Framework (RDF): Concepts and Abstract Syntax , G. Klyne, J. J. Carroll, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ . Latest version available at http://www.w3.org/TR/rdf-concepts/ .
XQuery 1.0 and XPath 2.0 Functions and Operators , J. Melton, A. Malhotra, N. Walsh, Editors, W3C Working Draft (work in progress), 4 April 2005, http://www.w3.org/TR/2005/WD-xpath-functions-20050404/ . Latest version available at http://www.w3.org/TR/xpath-functions/ .
RDF Semantics , P. Hayes, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ . Latest version available at http://www.w3.org/TR/rdf-mt/ .
RFC 3629 UTF-8, a transformation format of ISO 10646, F. Yergeau November 2003
RFC 3066 Tags for the Identification of Languages, H. Alvestrand January 2001
RFC 3986 Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter January 2005
RFC 3987, "Internationalized Resource Identifiers (IRIs)", M. Dürst , M. Suignard
The Unicode Standard, Version 4. ISBN 0-321-18578-1, as updated from time to time by the publication of new versions. The latest version of Unicode and additional information on versions of the standard and of the Unicode Character Database is available at http://www.unicode.org/unicode/standard/versions/.
Extensible Markup Language (XML) 1.1 , J. Cowan, J. Paoli, E. Maler, C. M. Sperberg-McQueen, F. Yergeau, T. Bray, Editors, W3C Recommendation, 4 February 2004, http://www.w3.org/TR/2004/REC-xml11-20040204/ . Latest version available at http://www.w3.org/TR/xml11/ .
XML Path Language (XPath) 2.0 , M. F. Fern?dez, D. Chamberlin, M. Kay, S. Boag, J. Robie, J. Sim?n, A. Berglund, Editors, W3C Working Draft (work in progress), 4 April 2005, http://www.w3.org/TR/2005/WD-xpath20-20050404/ . Latest version available at http://www.w3.org/TR/xpath20/ .
XQuery 1.0: An XML Query Language , S. Boag, M. F. Fernández, D. Chamberlin, D. Florescu, J. Robie, J. Siméon, Editors, W3C Candidate Recommendation 3 November 2005, http://www.w3.org/TR/2005/CR-xquery-20051103/. Latest version available at http://www.w3.org/TR/xquery/ .
XML Schema Part 2: Datatypes Second Edition, P. V. Biron, A. Malhotra, Editors, W3C Recommendation, 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ . Latest version available at http://www.w3.org/TR/xmlschema-2/ .

Informative References

CBD - Concise Bounded Description, Patrick Stickler, Nokia, W3C Member Submission, 3 June 2005.
Expressing Simple Dublin Core in RDF/XML Dublin Core Dublin Core Metadata Initiative Recommendation 2002-07-31.
OWL Web Ontology Language Semantics and Abstract Syntax, Peter F. Patel-Schneider, Patrick Hayes, Ian Horrocks, Editors, W3C Recommendation http://www.w3.org/TR/2004/REC-owl-semantics-20040210/. Latest version at http://www.w3.org/TR/owl-semantics/.
RDF Vocabulary Description Language 1.0: RDF Schema, Dan Brickley, R.V. Guha, Editors. W3C Recommendation http://www.w3.org/TR/2004/REC-rdf-schema-20040210/. Latest version at http://www.w3.org/TR/rdf-schema/.
SPARQL Query Results XML Format , D. Beckett, Editor, W3C Working Draft (work in progress), 27 May 2005, http://www.w3.org/TR/2005/WD-rdf-sparql-XMLres-20050527/ . Latest version available at http://www.w3.org/TR/rdf-sparql-XMLres/ .
SPARQL Protocol for RDF, K. Clark, Editor, W3C Working Draft (work in progress), 27 May 2005, http://www.w3.org/TR/2005/WD-rdf-sparql-protocol-20050527/ . Latest version available at http://www.w3.org/TR/rdf-sparql-protocol/ .
Turtle - Terse RDF Triple Language, Dave Beckett.
RDF Data Access Use Cases and Requirements , K. Clark, Editor, W3C Working Draft (work in progress), 25 March 2005, http://www.w3.org/TR/2005/WD-rdf-dawg-uc-20050325/ . Latest version available at http://www.w3.org/TR/rdf-dawg-uc/ .
Unicode Security Considerations, Mark Davis, Michel Suignard
Representing vCard Objects in RDF/XML W3C Note 22 February 2001 Renato Iannella. latest version is available at http://www.w3.org/TR/vcard-rdf
Architecture of the World Wide Web, Volume One, Editors: Ian Jacobs, Norman Walsh
Identifier and Pattern Syntax 4.1.0, Mark Davis, Unicode Standard Annex #31, 25 March 2005, http://www.unicode.org/reports/tr31/tr31-5.html . Latest version available at http://www.unicode.org/reports/tr31/ .

G. Acknowledgements

The SPARQL RDF Query Language is a product of the whole of the W3C RDF Data Access Working Group, and our thanks for discussions, comments and reviews go to all present and past members.

In addition, we have had comments and discussions with many people through the working group comments list. All comments go to making a better document. Andy would also like to particularly thank Geoff Chappell, Bob MacGregor, Yosi Scharf and Richard Newman for exploring specific issues related to SPARQL. Eric would like to acknowledge the invaluable help of Björn Höhrmann.

H. Change Log

Changes since the 21 July 2005 Working Draft include design changes, for which the WG has or intends to have corresponding test cases:

and significant editorial changes:

Raw CVS log:


$Log: rq24.html,v $
Revision 1.45  2007/02/16 18:06:04  aseaborne

Revision 1.44  2007/01/02 14:46:03  eric
+ = and != for simple literal and xsd:string

Revision 1.43  2006/10/13 15:01:12  aseaborne
Finish removing token UCHAR

Revision 1.42  2006/10/12 12:58:09  aseaborne
Editorial changes from
2006OctDec/0025 as described in

Grammar changed as detailed in

Revision 1.41  2006/10/10 11:31:54  aseaborne
Fix HTML for validation ; truncate CVS log to rq24 start

Revision 1.38  2006/10/02 14:06:14  aseaborne
Remove red text about UNION objection that has been withdrawn

Revision 1.37  2006/09/20 14:33:44  aseaborne
Removed out-of-date editor notes.

Changes to reflect the WG decisions on:
+ """
  to support term distinctness w/r/t URIs and bnodes,
  with literals to be decided
+ """
  Logical entailment may result in inconsistent RDF graphs.
  The result of queries on an inconsistent graph is outside this

Revision 1.36  2006/09/20 10:50:27  eric
- Pending issues summary per Bijan's and Kendall's requests

Revision 1.35  2006/09/19 16:07:21  eric
- DISTINCT issue per WG decision

Revision 1.34  2006/09/19 15:31:16  eric
- inconsistent graph issue per WG decision

Revision 1.33  2006/09/19 10:43:08  eric
~ updated Pending issues per discussion with Ralph, Ivan, Sandro, DanC 2006-09-18T14:18:55Z

Revision 1.32  2006/09/15 08:22:57  aseaborne
Added an @@ for filters in 4.7

Revision 1.31  2006/09/14 13:04:46  eric

Revision 1.30  2006/09/14 11:48:02  eric
+ [NON-EDITORIAL] 11.4.10bis sameTerm
+ [EDITORIAL] explanation of RDFterm-equal type errors

Revision 1.29  2006/09/13 19:52:52  aseaborne
Editorial changes in response to
as noted in

Revision 1.28  2006/09/13 14:33:07  aseaborne
Editorial changes based on comments by SimonR:

2006Sep/0000as noted in

Revision 1.27  2006/09/13 13:03:42  aseaborne
Editorial changes based on telecon of 2006/09/12:

- Remove section discussion D-entailment (4.8)
+ Add text in 4.7 that restrictions by value only apply to RDF literals.

Revision 1.25  2006/09/12 12:33:01  aseaborne
Fix validation errors

Revision 1.23  2006/09/11 17:16:39  aseaborne
Editorial changes based on comments by LeeF:
(partial commit)

Revision 1.22  2006/09/11 12:42:05  aseaborne
Editorial changes based on comments by LeeF:
as noted in

Revision 1.21  2006/09/09 10:38:57  eric
+ Pending issues list
+ issue descriptions, place in context in the document

Revision 1.20  2006/09/08 12:34:12  eric
+ handle unbound arguments [addressed comment, proposed changes]
~ [EDITORIAL] changed the operator name "isBound" to "bound" because the distinct func name was unhelpful
+ [EDITORIAL] note 3066bis

Revision 1.19  2006/09/08 11:19:29  eric
+ controversial extensibility text [announced]

Revision 1.18  2006/09/06 08:04:12  aseaborne
Type ; added an @@

Revision 1.17  2006/08/16 09:02:14  aseaborne
Noted ToDo items for DISTINCT

Revision 1.16  2006/08/15 17:20:26  aseaborne
Add CVS date to head

Revision 1.15  2006/08/15 11:39:11  eric
+ make RDFterm-equal produce a type error for != literals

Revision 1.14  2006/08/15 11:37:18  eric
~ [EDITORIAL] rework Testing Values to facilitate adding extensibility

Revision 1.13  2006/08/14 17:36:19  aseaborne
Put back text for DISTINCT definition which gives the
condition for DISTINCTness.

Revision 1.12  2006/08/14 17:14:01  eric
~ [EDITORIAL] restructured 11.3 intro paragraphs

Revision 1.11  2006/08/14 13:57:07  eric
~ [EDITORIAL] minor clarifications on filter functions

Revision 1.10  2006/08/09 14:50:33  eric
~ copied 11 Testing Values markup from rq23

Revision 1.9  2006/07/26 12:31:08  aseaborne
Added ties to the grammar from main body of doc - some still placeholders

Revision 1.8  2006/07/24 10:35:43  aseaborne
Reorganize appendix A.

Move codepoint escape processing outside the grammar proper as per
The grammar rules itself not updated for this chnage.

Revision 1.7  2006/07/17 12:53:34  aseaborne
Finish renumbering

Revision 1.6  2006/07/13 17:05:01  aseaborne
Editorial changes to wording in descriptive sections

Revision 1.5  2006/07/06 10:44:28  aseaborne
Validation fix

Revision 1.4  2006/07/06 10:39:46  aseaborne
Reorg old sections 7/8/9 (datasets) into one section (new 9)

Revision 1.3  2006/07/04 13:35:51  aseaborne
Missing space in section 4.1 title

Revision 1.2  2006/07/04 13:33:02  aseaborne
Ran tidy -i -asxhtml

Revision 1.1  2006/07/04 13:31:16  aseaborne
Draft reorganisation of sections