SPARQL 1.1 Query Language

1.1 Document Outline

Unless otherwise noted in the section heading, all sections and appendices in this document are normative.

This section of the document, section 1, introduces the SPARQL query language specification. It presents the organization of this specification document and the conventions used throughout the specification.

Section 2 of the specification introduces the SPARQL query language itself via a series of example queries and query results. Section 3 continues the introduction of the SPARQL query language with more examples that demonstrate SPARQL's ability to express constraints on the RDF terms that appear in a query's results.

Section 4 presents details of the SPARQL query language's syntax. It is a companion to the full grammar of the language and defines how grammatical constructs represent IRIs, blank nodes, literals, and variables. Section 4 also defines the meaning of several grammatical constructs that serve as syntactic sugar for more verbose expressions.

Section 5 introduces basic graph patterns and group graph patterns, the building blocks from which more complex SPARQL query patterns are constructed. Sections 6, 7, and 8 present constructs that combine SPARQL graph patterns into larger graph patterns. In particular, Section 6 introduces the ability to make portions of a query optional; Section 7 introduces the ability to express the disjunction of alternative graph patterns; and Section 8 introduces patterns to test for the absense of information.

Section 9 adds property paths to graph pattern matching, giving a compact representation of queries and also the ability to match arbitrary length paths in the graph.

Section 10 describes the forms of assignment possible in SPARQL.

Sections 11 introduces the mechanism to group and aggregate results, which can be incorporated as subqueries as described in Section 12.

Section 13 introduces the ability to constrain portions of a query to particular source graphs. Section 13 also presents SPARQL's mechanism for defining the source graphs for a query.

Section 14 refers to the separate document SPARQL 1.1 Federation Extensions

Section 15 defines the constructs that affect the solutions of a query by ordering, slicing, projecting, limiting, and removing duplicates from a sequence of solutions.

Section 16 defines the four types of SPARQL queries that produce results in different forms.

Section 17 defines SPARQL's extensible value testing and expression framework. It presents the functions and operators that can be used to constrain the values that appear in a query's results and also calculate new values to be returned by a query.

Section 18 is a formal definition of the evaluation of SPARQL graph patterns and solution modifiers.

Section 19 contains the normative definition of the syntax for the SPARQL query and SPARQL update languages, as given by a grammar expressed in EBNF notation.

1.2 Document Conventions

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

2.1 Writing a Simple Query

The example below shows a SPARQL query to find the title of a book from the given data graph. The query consists of two parts: the SELECT clause identifies the variables to appear in the query results, and the WHERE clause provides the basic graph pattern to match against the data graph. The basic graph pattern in this example consists of a single triple pattern with a single variable (?title) in the object position.

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

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

2.2 Multiple Matches

The result of a query is a solution sequence, corresponding to the ways in which the query's graph pattern matches the data. There may be zero, one or multiple solutions to a query.

Data:

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

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

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

Each solution gives one way in which the selected variables can be bound to RDF terms so that the query pattern matches the data. The result set gives all the possible solutions. 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; all the variables used in the query pattern must be bound in every solution.

2.3 Matching RDF Literals

The data below contains three 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     "cat"@en .
:y   ns:p     "42"^^xsd:integer .
:z   ns:p     "abc"^^dt:specialDatatype .

This RDF data is the data graph for the query examples in sections 2.3.1–2.3.3.

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

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

SELECT ?v WHERE { ?v ?p 42 }

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

2.4 Blank Node Labels in Query Results

Query results can contain blank nodes. Blank nodes in the example result sets in this document are written in the form "_:" followed by a blank node label.

Blank node labels are scoped to a result set (as defined in "SPARQL Query Results XML Format") or, for the CONSTRUCT query form, the result graph. Use of the same label within a result set indicates the same blank node.

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

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

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

These two results have the same information: the blank nodes used to match the query are different in the two solutions. There need not be any relation between a label _:a in the result set and a blank node in the data graph with the same label.

An application writer should not expect blank node labels in a query to refer to a particular blank node in the data.

2.5 Creating Values with Expressions

SPARQL 1.1 allows to create values from complex expressions. The queries below show how to concatenate first names and last names from foaf data, then assign the value using an expression in the SELECT clause and also assign the value by using the BIND form.

@prefix foaf:  <http://xmlns.com/foaf/0.1/> .
          
_:a  foaf:givenName   "John" .
_:a  foaf:surname  "Doe" .

PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
SELECT ( CONCAT(?G, " ", ?S) AS ?name )
WHERE  { ?P foaf:givenName ?G ; foaf:surname ?S }

PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
SELECT ?name
WHERE  { 
   ?P foaf:givenName ?G ; 
      foaf:surname ?S 
   BIND(CONCAT(?G, " ", ?S) AS ?name)
}

2.6 Building RDF Graphs

SPARQL has several query forms. The SELECT query form returns variable bindings. The CONSTRUCT query form returns an RDF graph. The graph is built based on a template which is used to generate RDF triples based on the results of matching the graph pattern of the query.

@prefix org:    <http://example.com/ns#> .

_:a  org:employeeName   "Alice" .
_:a  org:employeeId     12345 .

_:b  org:employeeName   "Bob" .
_:b  org:employeeId     67890 .

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

CONSTRUCT { ?x foaf:name ?name }
WHERE  { ?x org:employeeName ?name }

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

<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:foaf="http://xmlns.com/foaf/0.1/"
    >
  <rdf:Description>
    <foaf:name>Alice</foaf:name>
  </rdf:Description>
  <rdf:Description>
    <foaf:name>Bob</foaf:name>
  </rdf:Description>
</rdf:RDF>

3.1 Restricting the Value of Strings

SPARQL FILTER functions like regex can test RDF literals. regex matches only plain literals with no language tag. regex can be used to match the lexical forms of other literals by using the str function.

Query:

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

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

Query:

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

The regular expression language is defined by XQuery 1.0 and XPath 2.0 Functions and Operators and is based on XML Schema Regular Expressions.

3.2 Restricting Numeric Values

SPARQL FILTERs can restrict on arithmetic expressions.

Query:

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

3.3 Other Term Constraints

In addition to numeric types, SPARQL supports types xsd:string, xsd:boolean and xsd:dateTime (see 17.1 Operand Data Types). 17.3 Operator Mapping lists a set of test functions, including BOUND, isLITERAL and langMATCHES and accessors, including STR, LANG and DATATYPE. There are also functions to construct new RDF terms and cast terms from one datatype to another, where possible.

4.1 RDF Term Syntax

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

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

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

[ :p "v" ] .

[] :p "v" .

_:b57 :p "v" .

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

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

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

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

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

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

4.2 Syntax for Triple Patterns

Triple Patterns are written as a whitespace-separated list of a subject, predicate and 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 }

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

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

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

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

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

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

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

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

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

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

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

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

5.1 Basic Graph Patterns

Basic graph patterns are sets of triple patterns. SPARQL graph pattern matching is defined in terms of combining the results from matching basic graph patterns.

A sequence of triple patterns interrupted by a filter comprises a single basic graph pattern. Any graph pattern terminates a basic graph pattern.

5.2 Group Graph Patterns

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

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

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

{ }

SELECT ?x
WHERE {}

 {  ?x foaf:name ?name .
    ?x foaf:mbox ?mbox .
    FILTER regex(?name, "Smith")
 }
  

 {  FILTER regex(?name, "Smith")
    ?x foaf:name ?name .
    ?x foaf:mbox ?mbox .
 }

 {  ?x foaf:name ?name .
    FILTER regex(?name, "Smith")
    ?x foaf:mbox ?mbox .
 }

  {
    ?x foaf:name ?name .
    ?x foaf:mbox ?mbox .
  }

  {
    ?x foaf:name ?name . FILTER regex(?name, "Smith")
    ?x foaf:mbox ?mbox .
  }

  {
    ?x foaf:name ?name .
    {}
    ?x foaf:mbox ?mbox .
  }

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

{ OPTIONAL { pattern } }

{ { } OPTIONAL { pattern } }

pattern OPTIONAL { pattern } OPTIONAL { pattern }

{ pattern OPTIONAL { pattern } } OPTIONAL { pattern }

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

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

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

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

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

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

6.2 Constraints in Optional Pattern Matching

Constraints can be given in an optional graph pattern. For example:

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

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

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

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

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

8.1 Filtering Using Graph Patterns

Filtering of query solutions is done within a FILTER expression using NOT EXIST and EXISTS. Note that the filter scope rules apply to the whole group in which the filter appears.

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

:alice  rdf:type   foaf:Person .
:alice  foaf:name  "Alice" .
:bob    rdf:type   foaf:Person .     

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

SELECT ?person
WHERE 
{
    ?person rdf:type  foaf:Person .
    FILTER NOT EXISTS { ?person foaf:name ?name }
}     

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

SELECT ?person
WHERE 
{
    ?person rdf:type  foaf:Person .
    FILTER EXISTS { ?person foaf:name ?name }
}

8.2 Removing Possible Solutions

The other style of negation provided in SPARQL is MINUS which evaluates both its arguments, then calculates solutions in the left-hand side that are not compatible with the solutions on the right-hand side.

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

:alice  foaf:givenName "Alice" ;
        foaf:familyName "Smith" .

:bob    foaf:givenName "Bob" ;
        foaf:familyName "Jones" .

:carol  foaf:givenName "Carol" ;
        foaf:familyName "Smith" .

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

SELECT DISTINCT ?s
WHERE {
   ?s ?p ?o .
   MINUS {
      ?s foaf:givenName "Bob" .
   }
}

8.3 Relationship and differences between NOT EXISTS and MINUS

NOT EXISTS and MINUS represent two ways of thinking about negation, one based on testing whether a pattern exists in the data, given the bindings already determined by the query pattern, and one based on removing matches based on the evaluation of two patterns. In some cases they can produce different answers.

@prefix : <http://example/> .
:a :b :c .

SELECT *
{ 
  ?s ?p ?o
  FILTER NOT EXISTS { ?x ?y ?z }
}

SELECT *
{ 
   ?s ?p ?o 
   MINUS 
     { ?x ?y ?z }
}

PREFIX : <http://example/>
SELECT * 
{ 
  ?s ?p ?o 
  FILTER NOT EXISTS { :a :b :c }
}

PREFIX : <http://example/>
SELECT * 
{ 
  ?s ?p ?o 
  MINUS { :a :b :c }
}

@prefix : <http://example.com/> .
:a :p 1 .
:a :q 1 .
:a :q 2 .

:b :p 3.0 .
:b :q 4.0 .
:b :q 5.0 .

PREFIX : <http://example.com/>
SELECT * WHERE {
        ?a :p ?n
        FILTER NOT EXISTS {
                ?a :q ?m .
                FILTER(?n = ?m)
        }
}

PREFIX : <http://example/>
SELECT * WHERE {
        ?x :p ?n
        MINUS {
                ?x :q ?m .
                FILTER(?n = ?m)
        }
}

9.1 Property Path Syntax

In the description below, iri is either an IRI, a prefixed name, or the keyword a, and elt is a path element, which may itself be composed of path syntax constructs.

The order of IRIs, and reverse IRIs, in a negated property set is not significant and they can occur in a mixed order.

The precedence of the syntax forms is, from highest to lowest:

• IRI, prefixed names
• Negated property sets
• Groups
• Unary operators *, ?, + and {} forms
• Unary ^ inverse links
• Binary operator /
• Binary operator |

Precedence is left-to-right within groups.

9.2 Examples

{ :book1 dc:title|rdfs:label ?displayString }

{
  ?x foaf:mbox <mailto:alice@example> .
  ?x foaf:knows/foaf:name ?name .
}

{ 
  ?x foaf:mbox <mailto:alice@example> .
  ?x foaf:knows/foaf:knows/foaf:name ?name .
}

{
  ?x foaf:mbox <mailto:alice@example> .
  ?x foaf:knows{2}/foaf:name ?name .
}

{ ?x  foaf:mbox <mailto:alice@example> .
   ?x  foaf:knows [ foaf:knows [ foaf:name ?name ]]. 
}

{
  ?x  foaf:mbox <mailto:alice@example> .
  ?x  foaf:knows ?a1 .
  ?a1 foaf:knows ?a2 .
  ?a2 foaf:name ?name .
}

{ ?x foaf:mbox <mailto:alice@example> .
  ?x foaf:knows/foaf:knows ?y .
  FILTER ( ?x != ?y )
  ?y foaf:name ?name 
}

{ ?x foaf:mbox <mailto:alice@example> }

{ <mailto:alice@example> ^foaf:mbox ?x }

{
  ?x foaf:knows/^foaf:knows ?y .  
  FILTER(?x != ?y)
}

{
  ?x foaf:mbox <mailto:alice@example> .
  ?x foaf:knows+/foaf:name ?name .
}

?ancestor (ex:motherOf|ex:fatherOf)+ <#me>

{ <http://example/thing> rdf:type/rdfs:subClassOf* ?type }

{ ?x rdf:type/rdfs:subClassOf* ?type }

{ ?x ?p ?v . ?p rdfs:subPropertyOf* :property }

{ ?x !(rdf:type|^rdf:type) ?y }

{ :list rdf:rest*/rdf:first ?element }

9.3 Cycles and Duplicates

SPARQL property paths treat the RDF triples as a directed, possible cyclic, graph with named edges. Evaluation of a property path expression can lead to duplicates in the results. The property paths are equivalent to their translation into triple patterns and SPARQL UNION graph patterns, with the addition of operators for negated property paths, zero-length paths and arbitrary length paths. Any variables introduced in the equivalent pattern are not part of the results - they are hidden by implicit projection of the results to just the variables given in the query.

For example, on the data:

@prefix :       <http://example/> .

:x  :p :z1 .
:x  :p :z2 .
:z1 :q :y .
:z2 :q :y .

PREFIX :   <http://example/>
SELECT * 
{  ?s :p/:q ?o . }

Results:

whereas if the query were written out to include the intermediate variable (?a), no rows in the results are duplicates:

PREFIX :   <http://example/>
SELECT * 
{  ?s :p ?a .
   ?a :q ?o . }

Results:

Where the query matches on arbitrary length paths, each cycle is considered at most once by stopping if an RDF term in the data would be a matched again in the evaluation of the + or * property path operators.

For example, on the data, which is a graph with a cycle in it,

@prefix :       <http://example/> .

:x  :p  :y .
:y  :p  :x .

and the query:

PREFIX :   <http://example/>
SELECT * 
{ :x :p+ ?o }

the results are:

because :p+ is a property path expression that is "one or more :p properties". The two answers correspond to matching once for :x :p :y then once for the case of :x :p :y . :y :p :x.

Using :p* instead of :p+ leads to a duplicate for :x because it is possible to match in two different ways in finding paths starting at :x; once with :p{0}

PREFIX :   <http://example/>
SELECT * 
{ :x :p* ?o }

which, using the translation of :p* is equivalent to the query:

PREFIX :   <http://example/>
SELECT * 
{  
   { :x :p{0} ?o } UNION { :x :p+ ?o } 
}

giving results of:

The order of results in these examples is not significant.

10.1 BIND: Assigning to Variables

The BIND form allows a value to be assigned to a variable in a group graph pattern. Use of BIND is a separate element of a group graph pattern and it ends any basic graph pattern.

Example:

@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 .
:book1  ns:discount  0.2 .

:book2  dc:title     "The Semantic Web" .
:book2  ns:price     23 .
:book2  ns:discount  0.25 .

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

SELECT  ?title ?price
{  ?x ns:price ?p .
   ?x ns:discount ?discount
   BIND (?p*(1-?discount) AS ?price)
   FILTER(?price < 20)
   ?x dc:title ?title . 
}

10.2 BINDINGS

A BINDINGS clause in a query provides an unordered solution sequence which is combined with the results of query evaluation by a join operation. It can be used by an application to provide specific requirements on query results and also by SPARQL query engine implementations that provide federated query through the SERVICE keyword to send a more constrained query to a remote query service.

@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 :     <http://example.org/book/> 
PREFIX ns:   <http://example.org/ns#> 

SELECT ?book ?title ?price
{
   ?book dc:title ?title ;
         ns:price ?price .
}
BINDINGS ?book {
 (:book1)
}

If a variable has no value for a particular query solution in the BINDINGS clause, the keyword UNDEF is used instead of an RDF term.

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

SELECT ?book ?title ?price
{
   ?book dc:title ?title ;
         ns:price ?price .
}
BINDINGS ?book ?title {
 (UNDEF "SPARQL Tutorial")
 (:book2 UNDEF)
}

11.1 Aggregate Example

@prefix : <http://books.example/> .

:org1 :affiliates :auth1, :auth2 .
:auth1 :writesBook :book1, :book2 .
:book1 :price 9 .
:book2 :price 5 .
:auth2 :writesBook :book3 .
:book3 :price 7 .
:org2 :affiliates :auth3 .
:auth3 :writesBook :book4 .
:book4 :price 7 .

PREFIX : <http://books.example/>
SELECT (SUM(?lprice) AS ?totalPrice)
WHERE {
  ?org :affiliates ?auth .
  ?auth :writesBook ?book .
  ?book :price ?lprice .
}
GROUP BY ?org
HAVING (SUM(?lprice) > 10)

This example demonstrates two features of aggregates: GROUP BY, which groups query solutions according to one or more expressions (in this case ?org), and HAVING, which is analogous to a FILTER expression, but operates over groups, rather than individual solutions.

The example is produced by grouping solutions according to the GROUP BY expression (i.e. all solutions where ?org takes a particular value appear within the same group), and evaluating the Set Function Sum() over that group. The groups are then filtered by the HAVING expression, which removes all groups where SUM(?lprice) is not greater than 10.

In aggregate queries and sub-queries variables that appear in the query pattern, but are not in the GROUP BY clause cannot be projected nor used in project expressions. In order to project arbitrary expressions the SAMPLE aggregate may be used. For details see the section on Projection Restrictions.

It should be noted that as per functions, aggregate expressions are required to be aliased (again, similar to the BIND clause, using the keyword 'AS') in order to project them from queries or subqueries. In the example above this is done using the variable ?totalPrice. It is an error for aggregates to project variables with a name already used in other aggregate projections.

11.2 GROUP BY

In order to calculate aggregate values for a solution, the solution is first divided into one or more groups, and the aggregate value is calculated for each group.

If aggregates are used in the query level, but the GROUP BY term is not used, then this is taken to be a single implicit group, to which all solutions belong.

Within GROUP BY clauses the binding keyword, AS, may be used, such as GROUP BY (?x + ?y AS ?z). This is equivalent to { ... BIND (?x + ?y AS ?z) } GROUP BY ?z.

For example, given a solution sequence S, ( {?x->2, ?y->3}, {?x->2, ?y->5}, {?x->6, ?y->7} ), we might wish to group the solutions according to the value of ?x, and calculate the average of the values of ?y for each group.

This could be written as:

SELECT (AVG(?y) AS ?avg)
WHERE {
  ?a :x ?x ;
     :y ?y .
}
GROUP BY ?x

The GROUP BY function, Group((?x), S) gives G = {
  (2) -> ( {?x->2, ?y->3}, {?x->2, ?y->5} ),
  (6) -> ( {?x->6, ?y->7} )
}

We can then apply the set function Avg() to the group solutions, using the Aggregation() algebra function, as Aggregation((?y), Avg, {}, G), giving:

{
  (2) -> Avg({(3), (5)}, {}),
  (6) -> Avg({(7)}, {})
}

or

{
  (2) -> 4,
  (6) -> 7
}

11.3 HAVING

HAVING operates over grouped solution sets, in the same way that FILTER operates over un-grouped ones.

HAVING expressions have the same evaluation rules as projections from grouped queries, as described in the following section.

An example of the use of HAVING is given below.

PREFIX : <http://data.example/>
SELECT (AVG(?size) AS ?asize)
WHERE {
  ?x :size ?size
}
GROUP BY ?x
HAVING(AVG(?size) > 10)

This will return average sizes, grouped by the subject, but only where the mean size is greater than 10.

11.4 Aggregate Projection Restrictions

In a query level which uses aggregates, only expressions consisting of aggregates and constants may be projected, with one exception. When GROUP BY is given with one more more simple expressions consisting of just a variable, those variables may be projected from the level.

For example, the following query is legal as ?x is given as a GROUP BY term.

PREFIX : <http://example.com/data/#>
SELECT ?x (MIN(?y) * 2 AS ?min)
WHERE {
  ?x :p ?y .
  ?x :q ?z .
} GROUP BY ?x (STR(?z))

Note that it would not be legal to project STR(?z) as this is not a simple variable expression. However, with GROUP BY (STR(?z) AS ?strZ) it would be possible to project ?strZ.

Other expressions, not using GROUP BY variables, or aggregates may have non-deterministic values projected from their groups using the SAMPLE aggregate.

11.5 Set Functions

The set functions which underlie SPARQL aggregates all have a common signature: SetFunc(M), or SetFunc(M, scalarvals) where M is a multiset of lists, and scalarvals is one or more scalar values that are passed to the set function indirectly via the ( ... ; key=value ) syntax for aggregates in the SPARQL grammar. The only use of this that's supported by the builtin aggregates in SPARQL Query 1.1 is GROUP_CONCAT, as in GROUP_CONCAT(?x ; separator=", ").

Note that the name “Set Function” is somewhat historical — the arguments to set functions are infact multisets. The name is retained due to the commonality with SQL Set Functions, which also operate over multisets.

The set functions defined in this document are Count, Sum, Min, Max, Avg, GroupConcat, and Sample — corresponding to the aggregates COUNT, SUM, MIN, MAX, AVG, GROUP_CONCAT, and SAMPLE. Definitions may be found in the SPARQL Algebra section. Systems may choose to expand this set using local extensions, using the same notation as for functions and casts. Note that, unless the ; separator is used this requires the parser to know whether some IRI refers to a function, cast, or aggregate before it can determine if there are any errors in a query where aggregates are used.

11.6 Joining Aggregate Values

In order to project values from (sub-)queries using aggregate values, a solution multiset is constructed where each solution comprises the results of evaluating the Aggregate expressions which share a key.

For example, if we have two aggregations:

A₁ = { (1,3) -> 5, (7,9) -> 11 }
A₂ = { (1,3) -> 6, (7,9) -> 12 }

AggregateJoin(A) = {
   { agg₁ -> 5, agg₂ -> 6 },
   { agg₁ -> 11, agg₂ -> 12 }
}

This is required to transform the aggregates solution multisets into solution multisets as used in the rest of the algebra.

11.7 Aggregate Example (with errors)

Data:

@prefix : <http://example.com/data/#> .

:x :p 1, 2, 3, 4 .
:y :p 1, _:b2, 3, 4 .
:z :p 1.0, 2.0, 3.0, 4 .

Query:

PREFIX : <http://example.com/data/#>
SELECT ?g (AVG(?p) AS ?avg) ((MIN(?p) + MAX(?p)) / 2 AS ?c)
WHERE {
  ?g :p ?p .
}
GROUP BY ?g

Result:

Note that the bindings for the :y group is not included in the results as the evaluation of Avg({1, _:b2, 3, 4}), and (_:b2 + 4) / 2 is an error, removing the bindings from the solution.

13.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 graphs can be exposed. Two useful arrangements are:

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

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

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

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

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

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

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

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

Example 2:

RDF data can be combined by the RDF merge [RDF-MT] of graphs. One possible arrangement of graphs in an RDF Dataset is to have the default graph be 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> .

13.2 Specifying RDF Datasets

A SPARQL query may specify the dataset to be used for matching by 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.

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

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

If there is no FROM clause, but there is one or more FROM NAMED clauses, then the dataset includes an empty graph for the 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 }

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

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

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

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

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

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

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

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

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

13.3 Querying the Dataset

When querying a collection of graphs, the GRAPH keyword is used to match patterns against named graphs. GRAPH can provide an IRI to select one graph or use a variable which will range over the IRI of all the named graphs in the query's RDF dataset.

The use of GRAPH changes the active graph for matching basic graph patterns within part of the query. Outside the use of GRAPH, the default graph is matched by basic graph patterns.

The following two graphs will be used in examples:

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

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

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

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

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

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

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

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

SELECT ?src ?bobNick
FROM NAMED <http://example.org/foaf/aliceFoaf>
FROM NAMED <http://example.org/foaf/bobFoaf>
WHERE
  {
    GRAPH ?src
    { ?x foaf:mbox <mailto:bob@work.example> .
      ?x foaf:nick ?bobNick
    }
  }

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

SELECT ?nick
FROM NAMED <http://example.org/foaf/aliceFoaf>
FROM NAMED <http://example.org/foaf/bobFoaf>
WHERE
  {
     GRAPH data:bobFoaf {
         ?x foaf:mbox <mailto:bob@work.example> .
         ?x foaf:nick ?nick }
  }

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
FROM NAMED <http://example.org/foaf/aliceFoaf>
FROM NAMED <http://example.org/foaf/bobFoaf>
WHERE
{
  GRAPH data:aliceFoaf
  {
    ?alice foaf:mbox <mailto:alice@work.example> ;
           foaf:knows ?whom .
    ?whom  foaf:mbox ?mbox ;
           rdfs:seeAlso ?ppd .
    ?ppd  a foaf:PersonalProfileDocument .
  } .
  GRAPH ?ppd
  {
      ?w foaf:mbox ?mbox ;
         foaf:nick ?nick
  }
}

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

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

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

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

15.1 ORDER BY

The ORDER BY clause establishes the order of a solution sequence.

Following the ORDER BY clause is a sequence of order comparators, composed of an expression and an optional order modifier (either ASC() or DESC()). Each ordering comparator is either ascending (indicated by the ASC() modifier or by no modifier) or descending (indicated by the DESC() modifier).

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

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

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

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

The "<" operator (see the Operator Mapping and 17.3.1 Operator Extensibility) defines the relative order of pairs of numerics, simple literals, xsd:strings, xsd:booleans and xsd:dateTimes. Pairs of IRIs are ordered by comparing them as simple literals.

SPARQL also fixes an order between some kinds of RDF terms that would not otherwise be ordered:

1. (Lowest) no value assigned to the variable or expression in this solution.
2. Blank nodes
3. IRIs
4. RDF literals

A plain literal is lower than an RDF literal with type xsd:string of the same lexical form.

SPARQL does not define a total ordering of all possible RDF terms. Here are a few examples of pairs of terms for which the relative order is undefined:

• "a" and "a"@en_gb (a simple literal and a literal with a language tag)
• "a"@en_gb and "b"@en_gb (two literals with language tags)
• "a" and "1"^^xsd:integer (a simple literal and a literal with a supported datatype)
• "1"^^my:integer and "2"^^my:integer (two unsupported datatypes)
• "1"^^xsd:integer and "2"^^my:integer (a supported datatype and an unsupported datatype)

This list of variable bindings is in ascending order:

The ascending order of two solutions with respect to an ordering comparator is established by substituting the solution bindings into the expressions and comparing them with the "<" operator. The descending order is the reverse of the ascending order.

The relative order of two solutions is the relative order of the two solutions with respect to the first ordering comparator in the sequence. For solutions where the substitutions of the solution bindings produce the same RDF term, the order is the relative order of the two solutions with respect to the next ordering comparator. The relative order of two solutions is undefined if no order expression evaluated for the two solutions produces distinct RDF terms.

Ordering a sequence of solutions always results in a sequence with the same number of solutions in it.

Using ORDER BY on a solution sequence for a CONSTRUCT or DESCRIBE query has no direct effect because only SELECT returns a sequence of results. Used in combination with LIMIT and OFFSET, ORDER BY can be used to return results generated from a different slice of the solution sequence. An ASK query does not include ORDER BY, LIMIT or OFFSET.

15.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 using the SELECT query form.

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

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

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

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

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

15.3 Duplicate Solutions

A solution sequence with no DISTINCT or REDUCED query modifier will preserve duplicate solutions.

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

_:x    foaf:name   "Alice" .
_:x    foaf:mbox   <mailto:alice@example.com> .

_:y    foaf:name   "Alice" .
_:y    foaf:mbox   <mailto:asmith@example.com> .

_:z    foaf:name   "Alice" .
_:z    foaf:mbox   <mailto:alice.smith@example.com> .

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

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

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

15.4 OFFSET

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

Using LIMIT and OFFSET to select different subsets of the query solutions will not be useful unless the order is made predictable by using ORDER BY.

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

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

15.5 LIMIT

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

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

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

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

16.1 SELECT

The SELECT form of results returns variables and their bindings directly. It combines the operations of projecting the required variables with introducing new variable bindings into a query solution.

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

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

_:b    foaf:name   "Bob" .

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

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

<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
  <head>
    <variable name="nameX"/>
    <variable name="nameY"/>
    <variable name="nickY"/>
  </head>
  <results>
    <result>
      <binding name="nameX">
        <literal>Alice</literal>
      </binding>
      <binding name="nameY">
        <literal>Bob</literal>
      </binding>
   </result>
    <result>
      <binding name="nameX">
        <literal>Alice</literal>
      </binding>
      <binding name="nameY">
        <literal>Clare</literal>
      </binding>
      <binding name="nickY">
        <literal>CT</literal>
      </binding>
    </result>
  </results>
</sparql>
		

@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 .
:book1  ns:discount 0.2 .

:book2  dc:title  "The Semantic Web" .
:book2  ns:price  23 .
:book2  ns:discount 0.25 .

PREFIX  dc:  <http://purl.org/dc/elements/1.1/>
PREFIX  ns:  <http://example.org/ns#>
SELECT  ?title (?p*(1-?discount) AS ?price)
{ ?x ns:price ?p .
  ?x dc:title ?title . 
  ?x ns:discount ?discount 
}

PREFIX  dc:  <http://purl.org/dc/elements/1.1/>
PREFIX  ns:  <http://example.org/ns#>
SELECT  ?title (?p AS ?fullPrice) (?fullPrice*(1-?discount) AS ?customerPrice)
{ ?x ns:price ?p .
   ?x dc:title ?title . 
   ?x ns:discount ?discount 
}

16.2 CONSTRUCT

The CONSTRUCT query 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 in 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 triples with no variables (known as ground or explicit triples), 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 }

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

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

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

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

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

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

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

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

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

PREFIX  dc: <http://purl.org/dc/elements/1.1/>
PREFIX app: <http://example.org/ns#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

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

@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 }
WHERE
{ [] foaf:name ?name ;
     site:hits ?hits .
}
ORDER BY desc(?hits)
LIMIT 2

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

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

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

CONSTRUCT { ?x foaf:name ?name } 
WHERE
{ ?x foaf:name ?name }

16.3 ASK

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 or not a solution exists.

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

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

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

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

yes

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

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

no

16.4 DESCRIBE (Informative)

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" which can come from any information available including the target RDF Dataset. The description is determined by the query service. The syntax DESCRIBE * is an abbreviation that describes all of the variables in a query.

DESCRIBE <http://example.org/>

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

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

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

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

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

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

foaf:mbox_sha1sum  rdf:type  owl:InverseFunctionalProperty .

17.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 the same way.

SPARQL has additional operators which operate on specific subsets of RDF terms. When referring to a type, the following terms denote a typed literal with the corresponding XML Schema [XSDT] datatype IRI:

• xsd:integer
• xsd:decimal
• xsd:float
• xsd:double
• xsd:string
• xsd:boolean
• xsd:dateTime

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

• numeric denotes typed literals with datatypes xsd:integer, xsd:decimal, xsd:float, and xsd:double.
• simple literal denotes a plain literal with no language tag.
• RDF term denotes the types IRI, literal, and blank node.
• variable denotes a SPARQL variable.

The following types are derived from numeric types and are valid arguments to functions and operators taking numeric arguments:

• xsd:nonPositiveInteger
• xsd:negativeInteger
• xsd:long
• xsd:int
• xsd:short
• xsd:byte
• xsd:nonNegativeInteger
• xsd:unsignedLong
• xsd:unsignedInt
• xsd:unsignedShort
• xsd:unsignedByte
• xsd:positiveInteger

SPARQL language extensions may treat additional types as being derived from XML schema datatypes.

17.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:

• Unlike XPath/XQuery, SPARQL functions do not process node sequences. When interpreting the semantics of XPath functions, assume that each argument is a sequence of a single node.
• Functions invoked with an argument of the wrong type will produce a type error. Effective boolean value arguments (labeled "xsd:boolean (EBV)" in the operator mapping table below), are coerced to xsd:boolean using the EBV rules in section 11.2.2 .
• Apart from BOUND, NOT EXISTS and EXISTS, all functions and operators operate on RDF Terms and will produce a type error if any arguments are unbound.
• Any expression other than logical-or (||) or logical-and (&&) that encounters an error will produce that error.
• A logical-or that encounters an error on only one branch will return TRUE if the other branch is TRUE and an error if the other branch is FALSE.
• A logical-and that encounters an error on only one branch will return an error if the other branch is TRUE and FALSE if the other branch is FALSE.
• A logical-or or logical-and that encounters errors on both branches will produce either of the errors.

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

17.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 the upper-most viable candidate 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 (xsd:integer, xsd:decimal, xsd:float, xsd:double, and types derived from a numeric type) apply to SPARQL operators as well (see XML Path Language (XPath) 2.0 [XPATH20] for definitions 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 equivalence can be tested with RDF term equivalence.

xsd:boolean function arguments marked with "(EBV)" are coerced to xsd:boolean by evaluating the effective boolean value of that argument.

17.4 Operator and Function Definitions

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

xsd:boolean   bound (variable var)

@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 ?givenName
 WHERE { ?x foaf:givenName  ?givenName .
         OPTIONAL { ?x dc:date ?date } .
         FILTER ( bound(?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)) }

rdfTerm   IF(expression1, expression2, expression3)

rdfTerm   coalesce(expression, ....)

 xsd:boolean   NOT EXISTS {pattern}

 xsd:boolean   EXISTS {pattern}

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

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

 xsd:boolean   RDF term term1 = RDF term term2

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

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

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

 xsd:boolean   sameTerm (RDF term term1, RDF term term2)

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

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

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

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

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

_:c3  :label        "Container 3" .
_:c3  :weight       "85"^^t:kilos .
_:c3  :displacement  "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)) }

boolean   rdfTerm IN (expression, ...)

(lhs = expression1) || (lhs = expression2) || ...

boolean   rdfTerm NOT IN (expression, ...)

(lhs != expression1) && (lhs != expression2) && ...

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

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

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

 xsd:boolean   isBlank (RDF term term)

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

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

 xsd:boolean   isLiteral (RDF term term)

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

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

 xsd:boolean   isNumeric (RDF term term)

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

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

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

 simple literal   lang (literal ltrl)

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

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

 IRI   datatype (typed literal typedLit)
 IRI   datatype (simple literal simpleLit)

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

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

iri   IRI(simple literal)

iri   IRI(iri)

blank node   BNODE()

blank node   BNODE(simple literal)

literal   STRDT(simple literal lexicalForm, IRI datatypeIRI)

literal   STRLANG(simple literal lexicalForm, simple literal langTag)

xsd:integer   STRLEN(literal ltrl)

literal   SUBSTR(literal source, xsd:integer startingLoc)

literal   SUBSTR(literal source, xsd:integer startingLoc, xsd:integer length)

literal   UCASE(literal ltrl)

literal   LCASE(literal ltrl)

xsd:boolean   STRSTARTS(literal arg1, literal arg2)

xsd:boolean   STRENDS(literal arg1, literal arg2)

xsd:boolean   CONTAINS(literal arg1, literal arg2)

simple literal   ENCODE_FOR_URI(literal ltrl)

literal   CONCAT(literal ltrl1 ... literal 
ltrln)

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

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

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

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

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

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

 numeric   abs (numeric term)

 numeric   round (numeric term)

 numeric   ceil (numeric term)

 numeric   floor (numeric term)

 xsd:double   rand ( )

 xsd:dateTime   now ()

 xsd:integer   year (xsd:dateTime arg)

 xsd:integer   month (xsd:dateTime arg)

 xsd:integer   day (xsd:dateTime arg)

 xsd:integer   hours (xsd:dateTime arg)

 xsd:integer   minutes (xsd:dateTime arg)

 xsd:decimal   seconds (xsd:dateTime arg)

 xsd:duration   timezone (xsd:dateTime arg)

 simple literal   tz (xsd:dateTime arg)

 simple literal   MD5 (simple literal arg)

 simple literal   MD5 (xsd:string arg)

 simple literal   SHA1 (simple literal arg)

 simple literal   SHA1 (xsd:string arg)

 simple literal   SHA224 (simple literal arg)

 simple literal   SHA224 (xsd:string arg)

 simple literal   SHA256 (simple literal arg)

 simple literal   SHA256 (xsd:string arg)

 simple literal   SHA384 (simple literal arg)

 simple literal   SHA384 (xsd:string arg)

 simple literal   SHA512 (simple literal arg)

 simple literal   SHA512 (xsd:string arg)

17.5 XPath 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 datatypes 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:

• Casting an IRI to an xsd:string produces a typed literal with a lexical value of the codepoints comprising the IRI, and a datatype of xsd:string.
• Casting a simple literal to any XML Schema datatype is defined as the product of casting an xsd:string with the string value equal to the lexical value of the literal to the target datatype.

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
IRI = IRI
ltrl = simple literal

17.6 Extensible Value Testing

A PrimaryExpression grammar rule 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.

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)

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:double   aGeo:distance (numeric x1, numeric y1, numeric x2, numeric y2)

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.

18.1 Initial Definitions

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

18.2 Translation to the SPARQL Algebra

This section defines the process of converting graph patterns and solution modifiers in a SPARQL query string into a SPARQL algebra expression. The process described converts one level of query nesting, as formed by subqueries using the nested SELECT syntax and is applied recursively on subqueries. Each level consists of graph pattern matching and filtering, followed by the application of solution modifiers.

The SPARQL query string is parsed and the abbreviations for IRIs and triple patterns given in section 4 are applied. At this point the abstract syntax tree is composed of:

Property path expressions are written to produce triple patterns and introduce four forms, ZeroLengthPath, ZeroOrMorePath, OneOrMorePath, and NegatedPropertySet.

The result of converting such an abstract syntax tree is a SPARQL query that uses the following symbols in the SPARQL algebra:

Slice is the combination of OFFSET and LIMIT.

ToList is used where conversion from the results of graph pattern matching to sequences occurs.

ToMultiSet is used where conversion from a solution sequence to a multiset occurs.

ZeroLengthPath, ZeroOrMorePath, OneOrMorePath and NegatedPropertySet are used in property path expressions.

OPTIONAL { { ... FILTER ( ... ?x ... ) } }..

Let P := graph pattern of EXISTS
Let A := Transform(P)

Replace EXISTS{P} by exists(A)
Replace NOT EXISTS{P} by fn:not(exists(A))

Let A := undefined
          
For each element G in the GroupOrUnionGraphPattern
    If A is undefined
        A := Transform(G)
    Else
        A := Union(A, Transform(G))
    End

The result is A
            

If the form is GRAPH IRI GroupGraphPattern
    The result is Graph(IRI, Transform(GroupGraphPattern))

If the form is GRAPH Var GroupGraphPattern
    The result is Graph(Var, Transform(GroupGraphPattern))

Let FS := the empty set
Let G := the empty pattern, Z, a basic graph pattern which is the empty set.

For each element E in the GroupGraphPattern
    If E is of the form FILTER(expr)
        FS := FS ∪ {expr}
        End

    If E is of the form OPTIONAL{P} 
        Let A := Transform(P)
        If A is of the form Filter(F, A2)
            G := LeftJoin(G, A2, F)
        Else 
            G := LeftJoin(G, A, true)
            End
        End

    If E is of the form MINUS{P}
        G := Minus(G, Transform(P))
        End

    If E is of the form BIND(expr AS var)
        G := Extend(G, var, expr)
        End

    If E is any other form 
        Let A := Transform(E)
        G := Join(G, A)
        End

   End
   
If FS is not empty
    Let X := Conjunction of expressions in FS
    G := Filter(X, G)
    End

The result is G.
            

The result is ToMultiset(Transform(SubSelect))

Replace join(Z, A) by A
Replace join(A, Z) by A

Let A := the empty sequence
Let Q := the query level being evaluated
Let P := the algebra translation of the GroupGraphPattern of the query level

If Q contains GROUP BY exprlist
    Let G := Group(exprlist, P)
Else
    Let G := Group((1), P)
    End

Let i := 1
For each expression E in SELECT and each HAVING(E) in Q

    If E does not contain an aggregate
        Replace E with Sample(E) in Q
        End

    For each variable V appearing outside of an aggregate
        Replace V with Sample(V) in Q
        End

    For each aggregate X(args ; scalarvals) now in E
        # note scalarvals may be omitted, then it's equivalent to the empty set
        Ai := Aggregation(args, X, scalarvals, G)
        Replace X(...) with aggi in Q
        i := i + 1
        End

A := Ai, ..., Ai-1
P := AggregateJoin(A)

For each HAVING(E) in Q
    P := Filter(E, P)
    End

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
SELECT (SUM(?val) AS ?sum) (COUNT(?a) AS ?count)
WHERE {
  ?a rdf:value ?val .
} GROUP BY ?a

Let G := Group((?a), BGP(?a rdf:value ?val))
A1 = Aggregation((?val), Sum, {}, G)
A2 = Aggregation((?a), Count, {}, G)
A := (A1, A2)
Let P := AggregateJoin(A)

SELECT selItem ... { pattern }
SELECT * { pattern }

Let X := algebra from earlier steps
Let VS := list of all variables visible in the pattern,
           so restricted by sub-SELECT projected variables and GROUP BY variables.
           Not visible: only in filter, exists/not exists, masked by a subselect, 
                        non-projected GROUP variables, only in the righ hadn side of MINUS

Let P := {}, a set of variable names
Let E := [], a list of pairs of the form (variable, expression)
  
If "SELECT *"
    P := VS

If  "SELECT selItem ...:"  
    For each selItem:
        If selItem is a variable
            P := P union { variable }
        End
        If selItem is (expr AS variable)
            variable must not appear in VS; if it does then generate a syntax error and stop
            P := P  union { variable }
            E := E append (variable, expr) 
        End
    End

For each pair (var, expr) in E
    X := Extend(X, var, expr)
    End
  
Result is X  
The set P is used later for projection.
            

18.3 Basic Graph Patterns

When matching graph patterns, the possible solutions form a multiset [multiset], also known as a bag. A multiset is an unordered collection of elements in which each element may appear more than once. It is described by a set of elements and a cardinality function giving the number of occurrences of each element from the set in the multiset.

Write μ for solution mappings.

Write μ₀ for the mapping such that dom(μ₀) is the empty set.

Write Ω₀ for the multiset consisting of exactly the empty mapping μ_0, with cardinality 1. This is the join identity.

Write μ(?x->t) for the solution mapping variable x to RDF term t : { (x, t) }

Write Ω(?x->t) for the multiset consisting of exactly μ(?x->t), that is, { { (x, t) } } with cardinality 1.

If μ₁ and μ₂ are compatible then μ₁ ∪ μ₂ is also a mapping. Write merge(μ₁, μ₂) for μ₁ ∪ μ₂

Write card[Ω](μ) for the cardinality of solution mapping μ in a multiset of mappings Ω.

18.4 SPARQL Algebra

For each symbol in a SPARQL abstract query, we define an operator for evaluation. The SPARQL algebra operators of the same name are used to evaluate SPARQL abstract query nodes as described in the section "Evaluation Semantics".

It is possible that a solution mapping μ in a Join can arise in different solution mappings, μ₁and μ₂ in the multisets being joined. The cardinality of  μ is the sum of the cardinalities from all possibilities.

Diff is used internally for the definition of LeftJoin.

Written in full that is:

LeftJoin(Ω₁, Ω₂, expr) =
    { merge(μ_1, μ₂) | μ₁ in Ω₁and μ₂ in Ω₂, and μ₁ and μ₂ are compatible and expr(merge(μ₁, μ₂)) is true }
∪
    { μ₁ | μ₁ in Ω₁and μ₂ in Ω₂, and μ₁ and μ₂ are not compatible, or Ω₂ is empty }
∪
    { μ₁ | μ₁ in Ω₁and μ₂ in Ω₂, and μ₁ and μ₂ are compatible and expr(merge(μ₁, μ₂)) is false, or Ω₂ is empty }

As these are distinct, the cardinality of LeftJoin is cardinality of these individual components of the definition.

The additional restriction on dom(μ) and dom(μ') is added because otherwise if there is a solution mapping in Ω₂ that has no variables in common with the solution mappings of Ω₁, then Minus(Ω₁, Ω₂) would be empty, regardless of the rest of Ω₂. The empty solution mapping is compatible with every other solution mapping so P MINUS {} would otherwise be empty for any pattern P.

There are 4 property path operators in the SPARQL algebra

Write [x | C] for a sequence of elements where C(x) is true.

Write card[L](x) to be the cardinality of x in L.

The Reduced solution sequence modifier does not guarantee a defined cardinality.

ListEval is a function which is used to evaluate a list of expressions against a solution and return a list of the resulting values.

Note that, although the result of a ListEval can be an error, and errors may be used to group, solutions containing error values are removed at projection time.

ListEval((unbound), μ) = (error), as the evaluation of an unbound expression is an error.

Group, a function which groups a solution sequence into multiple solutions, based on some attribute of the solutions.

Aggregation, a function which calculates a scalar value as an output of the aggregate expression in the SELECT clause, and in the HAVING evaluation process.

Example

Given a solution multiset (Ω) with the following values:

And the query expression SELECT (ex:agg(?y, ?z) AS ?agg) WHERE { ?x ?y ?z } GROUP BY ?x.

We produce G = Group((?x), Ω) = { ( (1), { μ₁, μ₂ } ), ( (2), { μ₃} ) }

And so Aggregation((?y, ?z), ex:agg, {}, G) =
{ ((1), eg:agg({(2, 3), (3, 4)}, {})), ((2), eg:agg({(5, 6)}, {})) }.

Flatten is a function which is used to collapse multisets of lists into a multiset, so for example { (1, 2), (3, 4) } becomes { 1, 2, 3, 4 }.

Count is a SPARQL set function which counts the number of times a given expression has a bound, and non-error value within the aggregate group.

Sum is a SPARQL set function that will return the numeric value obtained by summing the values within the aggregate group. Type promotion happens as per the op:numeric-add function, applied transitively, (see definition below) so the value of SUM(?x), in an aggregate group where ?x has values 1 (integer), 2.0e0 (float), and 3.0 (decimal) will be 6.0 (float).

The Avg set function calculates the average value for an expression over a group. It is defined in terms of Sum and Count.

For example, Avg({1, 2, 3}) = Sum({1, 2, 3})/Count({1, 2, 3}) = 6/3 = 2.

Min and Max are SPARQL set functions that return the minimum and maximum value from a group respectively.

This makes use of the SPARQL ORDER BY ordering definition, to allow ordering over arbitrarily typed expressions.

GroupConcat is a set function which performs a string concatenation across the values of an expression with a group. The order of the strings is not specified. The separator character used in the concatenation may be given with the scalar argument SEPARATOR.

For example, GroupConcat({"a", "b", "c"}, {"separator" -> "."}) = "a.b.c".

Sample is a set function which returns an arbitrary value from the multiset passed to it.

For example, given Sample({"a", "b", "c"}), "a", "b", and "c" are all valid return values. Note that Sample() is not required to be deterministic for a given input, the only restriction is that the output value must be present in the input multiset.

We define the expression function "exists" using "substitute":

18.5 Evaluation Semantics

We define eval(D(G), algebra expression) as the evaluation of an algebra expression with respect to a dataset D having active graph G. The active graph is initially the default graph.

D : a dataset
D(G) : D a dataset with active graph G (the one patterns match against)
D[i] : The graph with IRI i in dataset D
P, P1, P2 : graph patterns
L : a solution sequence

eval(D(G), BGP) = multiset of solution mappings

eval(D(G), Filter(F, P)) = Filter(F, eval(D(G),P), D(G))

Two filter functions in support of the evaluation of EXISTS and NOT EXISTS forms which were translated to exists are defined:

We define the expression function "exists" using "substitute":

eval(D(G), Join(P1, P2)) = Join(eval(D(G), P1), eval(D(G), P2))

eval(D(G), LeftJoin(P1, P2, F)) = LeftJoin(eval(D(G), P1), eval(D(G), P2), F)
          

eval(D(G), Union(P1,P2)) = Union(eval(D(G), P1), eval(D(G), P2))
          

if IRI is a graph name in D
eval(D(G), Graph(IRI,P)) = eval(D(D[IRI]), P)

if IRI is not a graph name in D
eval(D(G), Graph(IRI,P)) = the empty multiset

eval(D(G), Graph(var,P)) =
     Let R be the empty multiset
     foreach IRI i in D
        R := Union(R, Join( eval(D(D[i]), P) , Ω(?var->i) )
     the result is R
          

The evaluation of graph uses the SPARQL algebra union operator. The cardinality of a solution mapping is the sum of the cardinalities of that solution mapping in each join operation.

eval(D(G), Group(exprlist, P)) = Group(exprlist, eval(D(G), P))

eval(D(G), Aggregation(exprlist, func, scalarvals, P)) = { (dom(g), F) | g in eval(D(G), P) }

Where
   exprlist is a list of expressions, or *
   M = { ListEval(exprlist, μ) | μ in range(g) }
   F = func(M, scalarvals), for non-DISTINCT
   F = func(Distinct(M), scalarvals), for DISTINCT

Write A = (A1, A2, ...) where Ai = Aggregation(exprListi, funci, scalarvarsi, P)

eval(D(G), AggregateJoin(A)) = { (agg1, v1), ..., (aggn, vn) | vi such that ( k, vi ) in eval(D(G), Ai)
for some k and each 1 <= i <= n }

eval(D(G), extend(var, expr, P)) = extend(var, expr , eval(D(G), P))

For matching propery paths expressions, we write x:t for term or variables, x which is of type t or variable used for that type. For example, var:term means a variable used for RDF terms; x:term means x is some RDF term.

We define an auxillary function ALP used in the definitions of ZeroOrMorePath and OneOrMorePath. Note that the algorithm given here serves to specify the feature. An implementation is free to implement evaluation by any method that produces the same results for the query overall.

The matching algorithm is based on following all paths, and detecting when a graph node (subject or object), has been already visited on the path.

Informally, this algorithm attempts to extend the multiset of results by one application of path at each step, noting which nodes it has visited for this particular path in Visited. If a node has been visited for the path under consideration, it is not a candidate for another step. A node can still be visited multiple times if there are two different paths that visit it.

Let eval(x:term, path) be the evaluation of 'path', returning a multiset of RDF terms reached by path.

ALP(x:term, path) = 
    Let R = empty multiset
    ALP(x:term, path, R, {})
    return is R

# V is the set of nodes on this one path possibility.
# R is the overall result.

ALP(x:term, path, R:multiset of RDF terms , V:set of RDF terms) =
    if ( x in V ) return 
    add x to V
    add x to R
    X = eval(x,path) 
    For n:term in X
        ALP(n, path, R, V)
        End
    remove x from V

We now define the evalution of the path expression operations ZeroLengthPath, ZeroOrMorePath, OneOrMorePath and NegatedPropertySet.

eval(D(G), ZeroLengthPath(vx:var, path, vy:var))) = 
  { {(vx, term), (vy, term)} | term in nodes(G) }
  card[{(vx, term), (vy, term)}] = 1

eval(D(G), ZeroLengthPath(vx:var, path, y:term)) =
 { { (vx, y) } }
  card[{ (vx, y) }] = 1

eval(D(G), ZeroLengthPath(x:term, path, vy:var)) = 
  { { (vy, x) } }
  card[{ (vy, x) }] = 1

eval(D(G), ZeroLengthPath(x:term, path, y:term)) = 
  if x is the same term as y
    { {} }
    card[{}] = 1 
  else
    { }
    card[] = 0
          

eval(D(G), ZeroOrMore(x:term, path, vy:var)) =
    { { (vy, n) } | n in ALP(x, path) }
    card[{(vy, n)}] = card[n] in ALP(x, path)

eval(D(G), ZeroOrMore(vx:var, path, vy:var)) =
    { { (vx, t), (vy, n) } |  t in nodes(G), (vy, n) in eval(D(G), ZeroOrMore(t, path, vy:var)) }
    card[{(vx, t), (vy, n)}] = card[n] in eval(D(G), ZeroOrMore(t, path, vy:var))

eval(D(G), ZeroOrMore(vx:var, path, y:term)) = 
    eval(D(G), ZeroOrMore(y:term, ^path, vx:var))

eval(D(G), ZeroOrMore(x:term, path, y:term)) = 
    { { } } if (x,vy:var) in eval(D(G), ZeroOrMore(x, path, vy); card[{ }] = 1 
    { } if y not in ALP(x, path), card[] = 0

# For OneOrMorePath, we take one step of the path then start
# recording nodes for results.

eval(D(G), OneOrMore(x:term, path, vy:var)) =
    Let X = eval(x, path)
    Let V = {}
    For n in X
        ALP(n, path, R, V)
        End

eval(D(G), OneOrMore(vx:var, path, vy:var)) =
   { { (vx, t), (vy, n) } |  t in nodes(G), (vy, n) in eval(D(G), OneOrMore(t, path, vy:var)) }
    card[(vx, t), (vy, n)] = card[n] in eval(D(G), OneOrMore(t, path, vy:var))

eval(D(G), OneOrMore(vx:var, path, y:term)) =
  eval(D(G), OneOrMore(y:term, ^path, vx:var))

eval(D(G), OneOrMore(x:term, path, y:term)) =
    { { } } if (x,vy:var) in eval(D(G), OneOrMore(x, path, vy); card[{ }] = 1 
    { } if y not in ALP(x, path), card[] = 0

eval(D(G), ToList(P)) = ToList(eval(D(G), P))

eval(D(G), Distinct(L)) = Distinct(eval(D(G), L))
          

eval(D(G), Reduced(L)) = Reduced(eval(D(G), L))
          

eval(D(G), Project(L, vars)) = Project(eval(D(G), L), vars)
          

eval(D(G), OrderBy(L, condition)) = OrderBy(eval(D(G), L), condition)
          

eval(D(G), ToMultiSet(L)) = ToMultiSet(eval(D), M))

eval(D(G), Slice(L, start, length)) = Slice(eval(D(G), L), start, length)

18.6 Extending SPARQL Basic Graph Matching

The overall SPARQL design can be used for queries which assume a more elaborate form of entailment than simple entailment, by re-writing the matching conditions for basic graph patterns. Since it is an open research problem to state such conditions in a single general form which applies to all forms of entailment and optimally eliminates needless or inappropriate redundancy, this document only gives necessary conditions which any such solution should satisfy. These will need to be extended to full definitions for each particular case.

Basic graph patterns stand in the same relation to triple patterns that RDF graphs do to RDF triples, and much of the same terminology can be applied to them. In particular, two basic graph patterns are said to be 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 patterns.

An entailment regime specifies

1. a subset of RDF graphs called well-formed for the regime
2. an entailment relation between subsets of well-formed graphs and well-formed graphs.

Examples of entailment regimes include simple entailment [RDF-MT], RDF entailment [RDF-MT], RDFS entailment [RDF-MT], D-entailment [RDF-MT] and OWL Direct and RDF-Based Semantics entailment [OWL semantics]. Of these, only OWL Direct Semantics (OWL-DL) entailment restricts the set of well-formed graphs. If E is an entailment regime then we will refer to E-entailment, E-consistency, etc, following this naming convention.

Some entailment regimes can categorize some RDF graphs as inconsistent. For example, the RDF graph:

_:x rdf:type xsd:string .
_:x rdf:type xsd:decimal .

is D-inconsistent when D contains the XSD datatypes. The effect of a query on an inconsistent graph is not covered by this specification, but must be specified by the particular SPARQL extension.

An entailment regime E must provide conditions on basic graph pattern evaluation such that for any basic graph pattern BGP, any RDF graph G, and any evaluation that satisfies the conditions, the resulting multiset of solutions is uniquely determined up to RDF graph equivalence. We denote the multiset of solutions from evaluating BGP over G using E with Eval-E(G, BGP).
An entailment regime must further satisfy the following conditions:

1. For any consistent active graph AG, the entailment regime E uniquely specifies a scoping graph SG that is E-equivalent to AG.
2. A set of well-formed graphs for E is specified such that, for any basic graph pattern BGP, scoping graph SG, and solution mapping μ in Eval-E(SG, BGP), the graph μ(BGP) is well-formed for E.
3. For any basic graph pattern BGP and scoping graph SG, if μ₁, ..., μ_n in Eval-E(SG, BGP) and BGP₁, ..., BGP_n are basic graph patterns all equivalent to BGP but not sharing any blank nodes with each other or with SG, then

   SG E-entails (SG union μ₁(BGP₁) union ... union μ_n(BGP_n))

   These conditions do not fully determine the set of possible answers, since RDF allows unlimited amounts of redundancy. In addition, therefore, the following must hold.

4. Entailment regimes should provide conditions to prevent trivial infinite solution multisets as appropriate to the regime.

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

19.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:

where HEX is a hexadecimal character

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

Examples:

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

19.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 white space is significant; these form a possible choice of terminals for constructing a SPARQL parser. White space is significant in strings.

For example:

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

is the token sequence variable '?a', an IRI '<?b&&?c>', and variable '?d', not a expression involving the operator '&&' connecting two expression using '<' (less than) and '>' (greater than).

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

19.5 IRI References

Text matched by the IRI_REF production and PrefixedName (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 IRI_REF <abc#def> may occur in a SPARQL query string, but the 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 section 4.1.1, Syntax of IRI Terms, for a description of BASE and PREFIX.

19.6 Blank Node Labels

The same blank node label may not be used in two separate basic graph patterns with a single query.

19.7 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):

Examples:

"abc\n"
"xy\rz"
'xy\tz'

19.8 Grammar

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

Notes:

1. 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).
2. Escape sequences are case sensitive.
3. When tokenizing the input and choosing grammar rules, the longest match is chosen.
4. The SPARQL grammar is LL(1) when the rules with uppercased names are used as terminals.
5. There are two entry points into the grammar: QueryUnit for SPARQL queries, and UpdateUnit for SPARQL Update requests.
6. In signed numbers, no white space is allowed between the sign and the number. The AdditiveExpression grammar rule allows for this by covering the the two cases of an expression followed by a signed number. These produce an addition or substraction of the unsigned number as appropriate.
7. The tokens INSERT DATA, DELETE DATA, DELETE WHERE allow any amount of whitespace between the words. The single space version is used in the grammar for clarity.
8. The QuadData and QuadPattern rules both use rule Quads. The rule QuadData, used in INSERT DATA and DELETE DATA, must not allow variables in the quad patterns.
9. Blank nodes syntax is not allowed in DELETE WHERE, DELETE, nor in DELETE DATA.
10. The number of variables in the variable list of BINDING must be the same as the number of each list of associated BindingValues.
11. Expressions used in SELECT clauses must only use in-scope variables. This only applies to expressions used on the left-hand side of AS.
12. The variable assigned in a BIND clause must not be already in-scope.