SPARQL 1.2 Query Language

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 Federated Query.

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 1.1 Update languages, as given by a grammar expressed in EBNF notation.

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

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.

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

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

Blank node identifiers are scoped to a result set (see "SPARQL Query Results XML Format (Second Edition)" and "SPARQL 1.1 Query Results JSON Format") or, for the CONSTRUCT query form, the result graph. Use of the same identifier 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 blank node identifier _:a in the result set and a blank node identifier used in the syntax for the data.

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

SPARQL 1.2 allows values to be created from complex expressions. The queries below show how the CONCAT function can be used 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)
}

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>

SPARQL FILTER functions like regex can test RDF literals. regex matches only string literals. 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 and XPath Functions and Operators and is based on XML Schema Regular Expressions.

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

In addition to numeric types, SPARQL supports types xsd:string, xsd:boolean and xsd:dateTime (see Operand Data Types). Section Operator Mapping describes the operators and section Function Definitions describes the functions that can be applied to RDF terms.

Triple Patterns are written as 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" .

To cope with the language evolution of SPARQL, the VERSION directive can be used. When writing SPARQL queries with new features such as triple terms or functions on triple terms, authors MAY announce the use of the new syntax forms by including this directive followed by a version label indicating the version required to process the included features.

Version labels are defined in the following section. Processors may treat unrecognized labels as an error or as a warning.

VERSION "1.2"
PREFIX : <http://example/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

SELECT ?s ?date {
    ?s ?p ?o .
    BIND( <<( ?s ?p ?o )>> AS ?tt )
    :myreifier rdf:reifies ?tt .
    :myreifier :tripleAdded ?date .
}

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, with optional filters, comprises a single basic graph pattern. Any other graph pattern terminates a basic graph pattern.

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

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.

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

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

Filtering of query solutions is done within a FILTER expression using NOT EXISTS 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 }
}

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

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 {
    ?x :p ?n
    FILTER NOT EXISTS {
        ?x :q ?m .
        FILTER(?n = ?m)
    }
}

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

In the description below, iri is either an IRI written in full or abbreviated by a prefixed name, or the keyword a. elt is a path element, which may itself be composed of path 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 +
• Unary ^ inverse links
• Binary operator /
• Binary operator |

Precedence is left-to-right within groups.

Alternatives: Match one or both possibilities

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

which could have written:

{ 
   :book1 <http://purl.org/dc/elements/1.1/title> | <http://www.w3.org/2000/01/rdf-schema#label> ?displayString
}

Sequence: Find the name of any people that Alice knows.

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

Sequence: Find the names of people 2 "foaf:knows" links away.

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

This is the same as the SPARQL query:

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

or, with explicit variables:

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

Filtering duplicates: Because someone Alice knows may well know Alice, the example above may include Alice herself. This could be avoided with:

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

Inverse Property Paths: These two are the same query: the second is just reversing the property direction which swaps the roles of subject and object.

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

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

Inverse Path Sequence: Find all the people who know someone ?x knows.

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

which is equivalent to (?gen1 is a system generated variable):

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

Arbitrary length match: Find the names of all the people that can be reached from Alice by foaf:knows:

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

Alternatives in an arbitrary length path:

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

Arbitrary length path match: Some forms of limited inference are possible as well. For example, for RDFS, all types and supertypes of a resource:

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

All resources and all their inferred types:

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

Subproperty:

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

Negated Property Paths: Find nodes connected but not by rdf:type (either way round):

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

Elements in an RDF collection:

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

Note: This path expression does not guarantee the order of the results.

SPARQL property paths treat the RDF triples as a directed, possibly cyclic, graph with named edges. Evaluation of a property path expression can lead to duplicates because any variables introduced in the equivalent pattern are not part of the results and are not already used elsewhere. 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/>

:order  :item :z1 .
:order  :item :z2 .

:z1 :name "Small" .
:z1 :price 5 .

:z2 :name "Large" .
:z2 :price 5 .

Query:

PREFIX :   <http://example/>
SELECT * 
{  ?s :item/:price ?x . }

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 :item ?_a .
   ?_a :price ?x .
}

Results:

The equivalence to graphs patterns is particularly significant when query also involves an aggregation operation. The total cost of the order can be found with

PREFIX :   <http://example/>
SELECT (sum(?x) AS ?total) { 
    :order :item/:price ?x
}

Connectivity between the subject and object by a property path of arbitrary length can be found using the "zero or more" property path operator, *, and the "one or more" property path operator, +. There is also a "zero or one" connectivity property path operator, ?.

Each of these operators uses the property path expression to try to find a connection between subject and object, using the path step a number of times, as restricted by the operator.

For example, finding all the the possible types of a resource, including supertypes of resources, can be achieved with:

PREFIX  rdfs:   <http://www.w3.org/2000/01/rdf-schema#> . 
PREFIX  rdf:    <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
SELECT ?x ?type
{ 
    ?x rdf:type/rdfs:subClassOf* ?type
}

Similarly, finding all the people :x connects to via the foaf:knows relationship,

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX :     <http://example/>
SELECT ?person
{ 
    :x foaf:knows+ ?person
}

Such connectivity matching does not introduce duplicates (it does not incorporate any count of the number of ways the connection can be made) even if the repeated path itself would otherwise result in duplicates.

The graph matched may include cycles. Connectivity matching is defined so that matching cycles does not lead to undefined or infinite results.

The BIND form allows a value to be assigned to a variable from a basic graph pattern or property path expression. Use of BIND ends the preceding basic graph pattern. The variable introduced by the BIND clause must not have been used in the group graph pattern up to the point of use in BIND.

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

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)
    }
    {?x dc:title ?title . }
    FILTER(?price < 20)
}

Data can be directly written in a graph pattern or added to a query using VALUES. VALUES provides inline data as a solution sequence which are 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.

VALUES (?x ?y) {
    (:uri1 1)
    (:uri2 UNDEF)
}

VALUES ?z { "abc" "def" }

VALUES (?z) { ("abc") ("def") }

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
{
    VALUES ?book { :book1 :book3 }
    ?book dc:title ?title ;
          ns:price ?price .
}

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 .
    VALUES (?book ?title) {
        (UNDEF "SPARQL Tutorial")
        (:book2 UNDEF)
    }
}

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 .
}
VALUES (?book ?title) {
    (UNDEF "SPARQL Tutorial")
    (:book2 UNDEF)
}

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, can only be projected or used in select expressions if they are aggregated. The SAMPLE aggregate may be used for this purpose. 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, or in the WHERE clause.

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 in SELECT, HAVING or ORDER BY 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

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.

In a query level which uses grouping (either by the explicit use of a GROUP BY clause or through the use of aggregates in projection, HAVING, or ORDER BY clauses), every occurrence of a variable that appears in projection or SELECT expressions of that query level MUST satisfy one of the following conditions:

• the variable, V, appears as a named GROUP BY variable (with the corresponding GROUP BY expression consisting of just the variable V, or having the form (expr AS V))
• the variable appears as part of a sub-expression within the SELECT expression and this sub-expression is used as an argument to an aggregate (e.g., MIN(?v) or AVG(?v+2))
• the variable is introduced by an earlier SELECT expression in the same SELECT clause

If such a variable occurrence does not satisfy one of these conditions, the query is syntactically invalid.

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 expression is neither a simple variable, nor a named GROUP BY expression. However, with GROUP BY ?x (STR(?z) AS ?strZ) it would b[Truncated]