Copyright © 2005 W3C® ( MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, and document use rules apply.
RDF is a flexible and extensible way to represent information about World Wide Web resources. It is used to represent, among other things, personal information, social networks, metadata about digital artifacts, like music and images, as well as provide a means of integration over disparate sources of information. A standardized query language for RDF data with multiple implementations offers developers and end users a way to write and to consume the results of queries across this wide range of information. Used with a common protocol, applications can access and combine information from across the web.
This document describes the query language part of Protocol And RDF Query Language (SPARQL) for easy access to RDF stores. It is designed to meet the requirements and design objectives described in the W3C RDF Data Access Working Group (DAWG) document "RDF Data Access Use Cases and Requirements".
This is the third Public Working Draft of the Data Access SPARQL Query Language by the RDF Data Access Working Group (part of the Semantic Web Activity) for review by W3C Members and other interested parties.
Among the remaining issues for the SPARQL query language are:
A change log shows the differences between this document and the previous version. Editorial notes in "issue" style highlight issues or outstanding dissent. "todo" style indicates an area where the editors will provide more text. See the working group issues document for issues outside of this document. Please send comments to public-rdf-dawg-comments@w3.org, a mailing list with a public archive.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced under the 5 February 2004 W3C Patent Policy. The Working Group maintains a public list of patent disclosures relevant to this document; that page also includes instructions for disclosing [and excluding] a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.
Per section 4 of the W3C Patent Policy, Working Group participants have 150 days from the title page date of this document to exclude essential claims from the W3C RF licensing requirements with respect to this document series. Exclusions are with respect to the exclusion reference document, defined by the W3C Patent Policy to be the latest version of a document in this series that is published no later than 90 days after the title page date of this document.
See also:
@@ToDo@@ Tidy up HTML
@@ToDo@@ Ensure markup around examples enables XSLT extraction.
@@ToDo@@ Make sure there are no @@ToDo@@ in the document.
An RDF graph is a set of triples, each triple consisting of a subject, a predicate and an object, as defined in RDF Concepts and Abstract syntax. These triples can come from a variety of sources. For instance, they may come directly from an RDF document. They may be inferred from other RDF triples. They may be the RDF expression of data stored in other formats, such as XML or relational databases.
SPARQL is a query language for getting information from such RDF graphs. It provides facilities to:
As a data access language, it is suitable for both local and remote use. When used across networks, the companion SPARQL Protocol for RDF document [11] describes a remote access protocol.
When undeclared, the prefixes below stand in place of the URIs given:
Prefix | URI |
---|---|
rdf |
http://www.w3.org/1999/02/22-rdf-syntax-ns# |
rdfs |
http://www.w3.org/2000/01/rdf-schema# |
xsd |
http://www.w3.org/2001/XMLSchema# |
The SPARQL query language is based around matching graph patterns. The simplest graph patterns are triple patterns, which are like an RDF triple but with the possibility of a variable in any of the subject, predicate or object positions. Combining these gives a basic graph pattern, where an exact match to a graph is needed to fulfill a pattern.
Later sections describe how other graph patterns can be built using the graph operators OPTIONAL and UNION, be grouped together and also how queries can extract information from more than one graph. It is also possible to restrict the values allowed in matching a pattern.
In this section, we cover simple triple patterns, basic graph patterns and the SPARQL syntax related to these.
The example below shows a SPARQL query to find the title of a book from the information in an RDF graph. The query consists of two parts, the SELECT clause and the WHERE clause. The SELECT clause identifies the variables of interest to the application, and the WHERE clause has one triple pattern.
Data:
<http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title> "SPARQL Tutorial" .
Query:
SELECT ?title WHERE { <http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title> ?title }
Query Result:
title |
---|
"SPARQL Tutorial" |
The terms delimited by "<>" are relative URI references [RFC 3986]. After parsing, these are resolved to give URIs. The term URI in this document refers to URIs after resolution.
The query terms delimited by double quotes ("") are literals which, following Turtle [15]syntax are a string, in quotes, an optional language tag, introduced with '@', or an optional datatype URI, introduced by '^^'. Single quotes ('') are also allowed instead of double quotes. As a convenience, integers can be directly written and are interpreted as typed literals of datatype xsd:integer; floating point numbers can also be directly written and are interpreted as xsd:double. Boolean values of type xsd:boolean literals can also be written as true or false.
Variables in SPARQL queries have global scope; it is the same variable everywhere in the query that the name is used. Variables are indicated by '?'; the '?' does not form part of the variable. '$' is an alternative to '?' to help where systems use '?' as a substitution character. In a query, $abc and ?abc are the same variable.
Because URIs can be long, SPARQL provides an abbreviation mechanism. Prefixes can be defined and a QName-like syntax [14] provides shorter forms. Prefixes may be used anywhere after they are declared; redefining a prefix causes the new definition to be used from that point in the syntax. The base URI for the resolution of relative URIs [RFC 3869] can be explicitly declared with the BASE keyword.
Triple Patterns are written as a list of subject, predicate, object; there are abbreviated ways of writing some common triple pattern constructs.
The following examples are three ways to express the same query:
PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?title WHERE { <http://example.org/book/book1> dc:title ?title }
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX : <http://example.org/book/> SELECT $title WHERE { :book1 dc:title $title }
BASE <http://example.org/book/shelf/> PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?title WHERE { <book1> dc:title ?title }
Prefixes are syntactic: the prefix name does not affect the query, nor do prefix names in queries need to be the same prefixes as used for data. The following query is equivalent to the any of the previous ones and will give the same results when applied to the same data.
BASE <http://example.org/book/shelf/> PREFIX dcore: <http://purl.org/dc/elements/1.1/> SELECT ?title WHERE { <book1> dcore:title ?title }
The data format used in this document is Turtle [15] used to show each triple explicitly. Turtle allows URIs to be abbreviated with prefixes:
@prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix : <http://example.org/book/shelf/> . :book1 dc:title "SPARQL Tutorial" .
The term "binding" is used as a descriptive term to refer to a pair of (variable, RDF term). In this document, we illustrate bindings in results in tabular form so if variable x is bound to "Alice" and variable y is bound to "Bob", we show this as:
x | y |
---|---|
"Alice" | "Bob" |
Not every binding needs to exist in every row of the table. Optional matches and alternative matches may leave some variables unbound.
Results can be returned in RDF, in XML with the SPARQL Variable Binding Results XML Format [16] and also in forms specific to implementation APIs.
The building blocks of queries are triple patterns. Syntactically, a SPARQL triple pattern is a subject, predicate and object. The following triple pattern has a subject variable (the variable book), a predicate of dc:title and an object variable (the variable title).
?book dc:title ?title .
Matching a triple pattern to a graph, gives bindings between variables and RDF Terms so that the triple pattern, with the variables replaced by the corresponding RDF terms, is a triple of the graph being matched.
Definition: RDF Term
An RDF Term is anything that can
occur in the
RDF data model.
let RDF-U be the set of all
RDF URIs
let RDF-L be the set of all
RDF Literals
let RDF-B be the set of all
blank nodes
The set of RDF Terms, RDF-T, is RDF-U union RDF-L union RDF-B.
Definition:
Query Variable
Let V be the set of all query variables. V and RDF-T are
disjoint.
An RDF triple contains three components:
Definition: Graph Pattern
A Graph Pattern is one of:
Each of these pattern types is defined in sections of this document.
In SPARQL, a triple pattern is similar to an RDF triple but with the change that any component can be a query variable.
Definition: Triple Pattern
The set of triple patterns
is
(RDF-T union V) x (RDF-U union V)
x (RDF-T union V)
This definition of Triple Pattern includes literal subjects. This has been noted by RDF-core.
"[The RDF core Working Group] noted that it is aware of no reason why literals should not be subjects and a future WG with a less restrictive charter may extend the syntaxes to allow literals as the subjects of statements."
Definition:
Basic Graph Pattern
A Basic Graph Pattern is a set of Triple Patterns.
An RDF graph is a set of RDF triples. In the same way, a SPARQL Basic Graph Pattern is a set of Triple Patterns.
Definition: Query Pattern
A query has one main graph pattern. It is called the Query Pattern.
Definition: Substitution
Substitution is a
function from a subset of the set of variables, V, the domain of the substitution, dom(S), to the
set of RDF terms, T.
We write S(v) for the substitution of variable.
Definition:
Pattern Instance
If S is a substitution then the result of replacing every v in a basic graph pattern P
by S(v) is a pattern instance of P, written S(P).
@@ToDo@@Check used
For example, the query:
@@ToDo@@Change example to "A foaf:knows A"
SELECT ?x ?v WHERE { ?x ?x ?v }
has a single triple pattern as the query pattern. It matches a graph of a single triple:
rdf:type rdf:type rdf:Property .
with substitution:
x | v |
---|---|
rdf:type | rdf:Property |
It does not match the graph of a single triple:
rdfs:seeAlso rdf:type rdf:Property .
because the variable x would need to be both rdfs:seeAlso and rdf:type.
Definition:
Pattern Solution
A Pattern Solution of Graph
Pattern GP on graph G is any substitution S such that S(GP) is a subgraph of
G.
Where it is clear, a pattern solution is simply called a solution.
The SPARQL syntax uses the keyword WHERE to introduce the Query Pattern.
For a basic graph pattern to match, there must be a substitution where each of the triple patterns matches with the same substitution.
Data:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Johnny Lee Outlaw" . _:a foaf:mbox <mailto:jlow@example.com> .
There is a blank node [12] in this dataset, identified by _:a. The label is only used within the file for encoding purposes. The label information is not in the RDF graph. No SPARQL query will be able to identify that blank node by the label used in the serialization.
Query:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?mbox WHERE { ?x foaf:name "Johnny Lee Outlaw" . ?x foaf:mbox ?mbox }
Query Result:
mbox |
---|
<mailto:jlow@example.com> |
This query contains a basic graph pattern of two triple patterns, each of which must match for the graph pattern to match.
The results of a query are all the ways a query can match the graph being queried. Each result is one solution to the query and there may be zero, one or multiple results to a query.
Definition:
Query Solution
A Query Solution is a Pattern
Solution for the Query Pattern. A substitution in a query solution only
contains variables mentioned in the query.
Definition: Query Results
The Query Results, for a given
graph pattern GP on graph G, is written R(GP,G), and is the set of all query
solutions S such that S is a solution for GP on G.
R(GP, G) may be the empty set.
Data:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Johnny Lee Outlaw" . _:a foaf:mbox <mailto:jlow@example.com> . _:b foaf:name "Peter Goodguy" . _:b foaf:mbox <mailto:peter@example.org> .
Query:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name . ?x foaf:mbox ?mbox }
Query Result:
name | mbox |
---|---|
"Johnny Lee Outlaw" | <mailto:jlow@example.com> |
"Peter Goodguy" | <mailto:peter@example.org> |
The results enumerate the RDF terms to which the selected variables can be bound in the query pattern. In the above example, the following two subsets of the data provided the two matches.
_:a foaf:name "Johnny Lee Outlaw" . _:a foaf:box <mailto:jlow@example.com> .
_:b foaf:name "Peter Goodguy" . _:b foaf:box <mailto:peter@example.org> .
This is a simple, conjunctive graph pattern match, and all the variables used in the query pattern muts be bound in every solution.
A blank node can appear in a query pattern. It behaves as a variable, although it can not be mentioned in the query result form or anyplace else outside a graph pattern.
Blank nodes in queries are distinct from all blank nodes in the data. A blank node in a graph pattern does not match a blank node in the data by blank node label.
In the results of queries, the presence of blank nodes can be indicated by labels in the serializations of results. An application or client receiving the results of a query can tell that two solutions or two variable bindings differ in blank nodes but this information is only scoped to the results as defined in "SPARQL Variable Binding Results XML Format" or the CONSTRUCT result form.
@@ToDo@@Tie to RDF graph form - or don't mention
Data:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:b foaf:name "Bob" .
Query:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?x ?name WHERE { ?x foaf:name ?name }
x | name |
---|---|
_:c | "Alice" |
_:d | "Bob" |
The results above could equally be given with different blank node labels because the labels in the results only indicate whether RDF terms in the solutions were the same or different.
x | name |
---|---|
_:r | "Alice" |
_:s | "Bob" |
These two results have the same information: the blank nodes used to match the query are different in the two solutions. There is no relation between using _:a in the results and any blank node label in the data graph.
SPARQL uses a "Turtle-like" syntax for writing basic graph patterns, with the addition of named variables. There are a number of syntactic forms that abbreviate some common sequences of triples. These syntactic forms do not change the meaning of the query.
Triple patterns with common subject can be written so that the subject is written once, and used for more than one triple pattern using the ";" notation.
?x foaf:name ?name ; foaf:mbox ?mbox .
This is the same as writing the triple patterns:
?x foaf:name ?name . ?x foaf:mbox ?mbox .
If triple patterns share both subject and predicate, then these can be written using the "," notation.
?x foaf:nick "Alice" , "Alice_" .
is the same as writing the triple patterns:
?x foaf:nick "Alice" . ?x foaf:nick "Alice_" .
Blank nodes have labels which are scoped to the query. They are written as "_:a" for a blank node with label "a".
A blank node that is used in only one place in the query syntax can be abbreviated with "[]". A unique blank node will be created and used to form the triple pattern.
The "[:p :v]" construct can used to form triple patterns with a blank node for subject.
The following two forms:
[ :p "v" ] .
[] :p "v" .
allocate a unique blank node label (here "b57") and equivalent to writing:
_:b57 :p "v" .
Abbreviated blank node syntax can be combined with other abbreviations for common predicates and common objects.
[ foaf:name ?name ; foaf:mbox <alice@example.org> ]
This is the same as writing the following basic graph pattern for some uniquely allocated blank node:
_:b18 foaf:name ?name . _:b18 foaf:mbox <alice@example.org> .
RDF collections can be written in triple patterns using the syntax "( )". The form "()" is short for resource rdf:nil or <http://www.w3.org/1999/02/22-rdf-syntax-ns#nil>.
(1 ?x 3)
is short for:
_:b0 rdf:first 1 . _:b0 rdf:rest _:b1 . _:b1 rdf:first ?x . _:b1 rdf:rest _:b2 . _:b2 rdf:first 3 . _:b2 rdf:rest rdf:nil .
The keyword "a" can be used as a predicate in a triple pattern and is short for rdf:type.
?x a :Class1 . [ a :myClass ] :p "v" .
?x rdf:type :Class1 . _:b0 rdf:type :myClass . _:b0 :p "v" .
An RDF Literal is written in SPARQL as a string containing the lexical form of the literal, delimited by "", followed by an optional language tag (indicted by '@') or optional datatype (indicated by '^^'). There are convenience forms for numeric-types literals which are of type xsd:integer, xsd:double or xsd:boolean.
Examples of literal syntax in SPARQL:
The data below contains a number of RDF literals:
@prefix dt: <http://example.org/datatype#> .
@prefix ns: <http://example.org/ns#> .
@prefix : <http://example.org/ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
:x ns:p "42"^^xsd:integer .
:y ns:p "abc"^^dt:specialDatatype .
:z ns:p "cat"@en .
The pattern in the following query has a solution :x
because 42 is syntax for
"42"^^<http://www.w3.org/2001/XMLSchema#integer>.
SELECT ?v WHERE { ?v ?p 42 }
The following query has a solution :y
. The query processor does not
have to have any understanding of the values in the space of the datatype because, in this case, lexical form and datatype URI both match exactly.
SELECT ?x WHERE { ?x ?p "abc"^^<http://example.org/datatype#specialDatatype> }
This following query has no solution because "cat" is not the same RDF literal as "cat"@en:
SELECT ?x WHERE { ?x ?p "cat" }
but this does find a solution :z
:
SELECT ?x WHERE { ?x ?p "cat"@en }
Graph pattern matching creates bindings of variables. It is possible to further restrict solutions by constraining the allowable bindings of variables to RDF Terms. Value constraints take the form of boolean-valued expressions; the language also allows application-specific constraints on the values in a query solution.
Data:
@prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix : <http://example.org/book/> . @prefix ns: <http://example.org/ns#> . :book1 dc:title "SPARQL Tutorial" . :book1 ns:price 42 . :book2 dc:title "The Semantic Web" . :book2 ns:price 23 .
Query:
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX ns: <http://example.org/ns#> SELECT ?title ?price WHERE { ?x ns:price ?price . FILTER ?price < 30 . ?x dc:title ?title . }
Query Result:
title | price |
---|---|
"The Semantic Web" | 23 |
By having a constraint on the "price" variable, only book2
matches the query because
there is a restriction on the allowable values of "price".
Definition: Value Constraint
A graph pattern may involve a value constraint, which is a boolean-valued
expression of variables and RDF Terms that restricts query solutions.
Constraints may be restrictions of the value of an RDF Term or they may be restrictions on some part of an RDF term, such as its lexical form. SPARQL defines a set of functions & operations (sections 11.1 and 11.2) that all implementations must provide. In addition, there is an extension mechanism (section 11.3) for operations that are specific to an application domain or kind of data.
A constraint may lead to an error condition when testing some RDF term. The exact error will depend on the constraint: for example, in numeric operations, solutions with variables bound to a non-number or a blank node will lead to an error. Any potential solution that causes an error condition in a constraint will not form part of the final results, but does not cause the query to fail.
Open: whether to allow "foo"@?v or ?v@fr or ?v^^xsd:integer
or "foo"^^?v
One way to address this is to allow expressions in SELECT
Complex graph patterns can be made by combining simpler graph patterns. The ways of creating graph patterns are:
Definition:
Group Graph Pattern Matching
A graph pattern GP may be a set of graph patterns,
GPi. A solution of Graph Pattern GP on graph G
is any solution S such that for each element GPi of GP, S is a solution
of GPi.
Syntactically, a group of patterns is delimited with {}s (that is, braces).
For any solution, the same variable is given the same value everywhere in the set of graph patterns. A Basic Graph Pattern is, as described above, a group of triple patterns. For example, this query has a group pattern of one basic graph pattern as the query pattern.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name . ?x foaf:mbox ?mbox }
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { { ?x foaf:name ?name ; foaf:mbox ?mbox } }
Because a solution to a group is a solution to each element of a group, and a solution of a basic graph pattern is a solution to each triple pattern, these queries also have the same solutions as:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name ; foaf:mbox ?mbox }
using the abbreviation for a common subject between triple patterns.
@@ToDo@@Discussion of unbound variables.
Basic graph patterns allow application to queries where the whole of the query pattern must match for there to be a solution. For every solution of the query, every variable is bound to an RDF Term in a pattern solution. RDF is semi-structured so a regular, complete structure can not be assumed and it is useful to be able to have queries that allow information to be added to the solution where the information is available, but not have the solution rejected just because that part of the query pattern does not match. Optional matching provides this facility; if the optional part does not lead to any solutions, variables can be left unbound.
Optional parts of the graph pattern may be specified syntactically with the OPTIONAL keyword:
OPTIONAL { ?s ?p ?o }
Data:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . _:a rdf:type foaf:Person . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> . _:b rdf:type foaf:Person . _:b foaf:name "Bob" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name . OPTIONAL { ?x foaf:mbox ?mbox } }
With the data above, the query result is:
name | mbox |
---|---|
"Alice" | <mailto:alice@example.com> |
"Bob" |
There is no value of mbox in the solution where the name is "Bob". It is left unbound.
This query finds the names of people in the data, and, if there is a triple with predicate mbox and same subject, retrieves the object of that triple as well. In the example, only a single triple pattern is given in the optional match part of the query but, in general, it is any graph pattern. The whole graph pattern of an optional block must match for the optional to add to the query solution.
Constraints can be given in optional blocks as this example shows:
@prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix : <http://example.org/book/> . @prefix ns: <http://example.org/ns#> . :book1 dc:title "SPARQL Tutorial" . :book1 ns:price 42 . :book2 dc:title "The Semantic Web" . :book2 ns:price 23 .
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX ns: <http://example.org/ns#> SELECT ?title ?price WHERE { ?x dc:title ?title . OPTIONAL { ?x ns:price ?price . FILTER ?price < 30 } }
title | price |
---|---|
"SPARQL Tutorial" | |
"The Semantic Web" | 23 |
No price appears for the book with title "SPARQL Tutorial" because the optional block did not lead to a solution involving the variable price.
Graph patterns are defined recursively. A query may have zero or more optional blocks and any part of a query pattern may have an optional part. In this example, there are two optional blocks.
Data:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . _:a foaf:name "Alice" . _:a foaf:homepage <http://work.example.org/alice/> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@work.example> .
Query:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox ?hpage WHERE { ?x foaf:name ?name . OPTIONAL { ?x foaf:mbox ?mbox } . OPTIONAL { ?x foaf:homepage ?hpage } }
Query result:
name | mbox | hpage |
---|---|---|
"Alice" | <http://work.example.org/alice/> | |
"Bob" | <mailto:bob@example.com> |
In an optional match, either an additional graph pattern matches a graph and so defines one or more pattern solutions, or gives an empty pattern solution but does not cause matching to fail overall, leaving existing solutions in the query results.
Definition:
Optional Matching
Given graph pattern GP1, and graph pattern GP2, Opt(GP1, GP2) is the optional match of GP2 of
graph G, given GP1.
Let GP = (GP1 union GP2) then S is a solution of Opt(GP1, GP2) if
S is a solution for a match of GP on G, or else S is a solution for GP1 and S
is not a solution for GP.
S in R(Opt(GP1, GP2), G) if:
S in R(GP, G)
or
S not in R(GP,G) and S in R(GP1, G).
This definition can introduce ordering issues in queries - this is discussed in section "Query Execution Ordering".
Optional patterns can occur inside any pattern, including a group graph pattern which itself is optional, forming a nested pattern. The outer optional block must match for any nested one to be matched.
Data:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> . _:a vcard:N _:x . _:x vcard:Family "Hacker" . _:x vcard:Given "Alice" . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@work.example> . _:b foaf:N _:z . _:z vcard:Family "Hacker" . _:e foaf:name "Ella" . _:e vcard:N _:y . _:y vcard:Given "Eleanor" .
Query:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> SELECT ?foafName ?mbox ?gname ?fname WHERE { ?x foaf:name ?foafName . OPTIONAL { ?x foaf:mbox ?mbox } . OPTIONAL { ?x vcard:N ?vc . ?vc vcard:Given ?gname . OPTIONAL { ?vc vcard:Family ?fname } } }
Query result:
foafName | mbox | gname | fname |
---|---|---|---|
"Alice" | <mailto:alice@work.example> | "Alice" | "Hacker" |
"Bob" | <mailto:bob@work.example> | ||
"Ella" | "Eleanor" |
This query finds the name, optionally the mbox, and also the vCard given name; further, if there is a vCard Family name as well as the Given name, the query gets that as well.
By nesting the optional access to vcard:Family, the query only reaches these if there is a vcard:N predicate. It is possible to expand out optional blocks to remove nesting at the cost of duplication of expressions. Here, the expression is a simple triple pattern on vcard:N but it could be a complex graph match with value constraints.
SPARQL provides a means of combining graph patterns so that one of several alternative graph patterns may match. If more than one of the alternatives matches, all the possible pattern solutions are found.
The UNION keyword is the syntax for pattern alternatives.
Data:
@prefix dc10: <http://purl.org/dc/elements/1.0/> . @prefix dc11: <http://purl.org/dc/elements/1.1/> . _:a dc10:title "SPARQL Query Language Tutorial" . _:b dc11:title "SPARQL Protocol Tutorial" . _:c dc10:title "SPARQL" . _:c dc11:title "SPARQL (updated)" .
Query:
PREFIX dc10: <http://purl.org/dc/elements/1.0/> PREFIX dc11: <http://purl.org/dc/elements/1.1/> SELECT ?title WHERE { { ?book dc10:title ?title } UNION { ?book dc11:title ?title } }
Query result:
title |
---|
"SPARQL Protocol Tutorial" |
"SPARQL" |
"SPARQL (updated)" |
"SPARQL Query Language Tutorial" |
This query finds titles of the books in the data, whether the title is recorded using Dublin Core properties from version 1.0 or version 1.1. If the application wishes to know how exactly the information was recorded, then the query:
PREFIX dc10: <http://purl.org/dc/elements/1.0/> PREFIX dc11: <http://purl.org/dc/elements/1.1/> SELECT ?x ?y WHERE { { ?book dc10:title ?x } UNION { ?book dc11:title ?y } }
x | y |
---|---|
"SPARQL (updated)" | |
"SPARQL Protocol Tutorial" | |
"SPARQL" | |
"SPARQL Query Language Tutorial" |
will return results with the variables x or y bound depending on which way the query processor matches the pattern to the data. Note that, unlike an OPTIONAL pattern, if neither part of the UNION pattern matched, then the query pattern would not match.
The working group decided on this design and closed the disjunction issue without reaching consensus. The objection was that adding UNION would complicate implementation and discourage adoption. If you have input to this aspect of the SPARQL that the working group has not yet considered, please send a comment to public-rdf-dawg-comments@w3.org.
The UNION operator takes group graph patterns so more than one triple pattern can be given in each alternative possibility:
PREFIX dc10: <http://purl.org/dc/elements/1.1/> PREFIX dc11: <http://purl.org/dc/elements/1.0/> SELECT ?title ?author WHERE { { ?book dc10:title ?title . ?book dc10:creator ?author } UNION { ?book dc11:title ?title . ?book dc11:creator ?author } }
author | title |
---|---|
"Alice" | "SPARQL Protocol Tutorial" |
"Bob" | "SPARQL Query Language Tutorial" |
This query will only match a book if it has both a title and creator predicate from the same version of Dublin Core.
Definition:
Union Pattern Matching
Given graph patterns GP1 and GP2, and graph G, then a
union pattern solution of GP1 and GP2 is any
pattern solution S such that either S(GP1) matches G or
S(GP2) matches G with substitution S.
Query results involving a pattern containing GP1 and GP2, will include separate solutions for each match where GP1 and GP2 give rise to different sets of bindings.
The RDF data model expresses information as graphs, comprising of triples with subject, predicate and object. Many RDF data stores hold multiple RDF graphs, and record information about each graph, allowing an application to make queries that involve information from more than one graph.
A SPARQL query is made against an RDF Dataset which represents such a collection of graphs. Different parts of the query are matched against different graphs as described in the next section. There is one graph, the background graph, which does not have a name, and zero or more named graphs, identified by URI reference.
Definition:
RDF Dataset
An RDF dataset is a set = { G, (u1, G1),
(u2, G2), . . . (un, Gn) } where G
and each Gi are graphs, and each ui is a URI. Each ui
is distinct.
G is called the background graph. Gi are named graphs.
In the previous sections, all queries have been shown executed against a single, background graph. A query does not need to involve the background graph; the query can just involve the named graphs. A query processor is not required to support named graphs.
The definition of RDF Dataset does not restrict the relationships of named and background graphs. Two useful arrangements are:
# Background graph @prefix dc: <http://purl.org/dc/elements/1.1/> . <http://example.org/bob> dc:publisher "Bob" . <http://example.org/alice> dc:publisher "Alice" .
# Graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Bob" . _:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example.org> .
In this example, the background graph contains the publisher names of two named graphs. The triples in the named graphs are not visible in the background graph and, thought of as the default knowledge base, the application is not directly trusting the information in the named graphs.
RDF data can be combined by RDF merge of graphs so the background graph can be made to include the RDF merge of some or all of the information in the named graphs. Because this information is now being published without qualification, and a query application accepts as coming from the publisher, not just from a source 9a named graph) that the publisher incorporated.
In this next example, the named graphs contain the same information as before. The RDF dataset includes an RDF merge of the named graphs in the background graph, relabelling blank nodes to keep them distinct. Doing this is trusting the contents of the named graphs. An implementation can efficiently provide datasets of this form without duplicating stored triples.
# Background graph @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:x foaf:name "Bob" . _:x foaf:mbox <mailto:bob@oldcorp.example.org> . _:y foaf:name "Alice" . _:y foaf:mbox <mailto:alice@work.example.org> .
# Graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Bob" . _:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> .
When querying a collection of graphs, the GRAPH keyword allows access to the URIs naming the graphs in the RDF Dataset, or restricts a graph pattern to be applied to a specific named graph.
The following two graphs will be used in examples:
# Graph: http://example.org/foaf/aliceFoaf @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> . _:a foaf:knows _:b . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@work.example> . _:b foaf:age 32 . _:b rdfs:seeAlso <http://example.org/foaf/bobFoaf> . <http://example.org/foaf/bobFoaf> rdf:type foaf:PersonalProfileDocument .
# Graph: http://example.org/foaf/bobFoaf @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . _:1 foaf:mbox <mailto:bob@work.example> . _:1 rdfs:seeAlso <http://example.org/foaf/bobFoaf> . _:1 foaf:age 35 . <http://example.org/foaf/bobFoaf> rdf:type foaf:PersonalProfileDocument .
Access to the graph labels of the collection of graphs being queried is by variable in the GRAPH expression.
The query below matches the pattern on each of the named graphs in the dataset and forms solutions which have the src variable bound to URIs of the graph being matched. The pattern part of the GRAPH only matched triples in a single named graph in the same way that a graph pattern matches the background graph when there is no GRAPH clause being applied.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?src ?bobAge WHERE { GRAPH ?src { ?x foaf:mbox <mailto:bob@work.example> . ?x foaf:age ?bobAge } }
The query result gives the label of the graphs where the information was found and the value for Bob's age:
src | bobAge |
---|---|
<http://example.org/foaf/aliceFoaf> | 32 |
<http://example.org/foaf/bobFoaf> | 35 |
The query can restrict the matching applied to a specific graph by supplying the graph label. This query looks for the age as the graph http://example.org/foaf/bobFoaf asserts it.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX data: <http://example.org/foaf/> SELECT ?age WHERE { GRAPH data:bobFoaf { ?x foaf:mbox <mailto:bob@work.example> . ?x foaf:age ?age } }
which yields a single solution:
age |
---|
35 |
A variable used in the GRAPH clause may also be used elsewhere in the query, whether in another GRAPH clause or in a graph pattern matched against the background graph in the dataset.
This can be used to find information in one part of a query, and using it to restrict the graphs matched in another part of the query. The query below uses the graph with URI http://example.org/foaf/aliceFoaf to find the profile document for Bob; it then matches another pattern against that graph. Note that the pattern in the second GRAPH part finds the blank node for the person with the same mail box (given by variable mbox) as found in the first GRAPH part, because the blank node used to match for variable whom from Alice's FOAF file is not the same as the blank node in the profile document (they are in different graphs).
PREFIX data: <http://example.org/foaf/> PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> SELECT ?mbox ?age ?ppd WHERE { GRAPH data:aliceFoaf { ?alice foaf:mbox <mailto:alice@work.example> ; foaf:knows ?whom . ?whom foaf:mbox ?mbox ; rdfs:seeAlso ?ppd . ?ppd a foaf:PersonalProfileDocument . } . GRAPH ?ppd { ?w foaf:mbox ?mbox ; foaf:age ?age } }
mbox | age | ppd |
---|---|---|
<mailto:bob@work.example> | 35 | <http://example.org/foaf/bobFoaf> |
Any triple in Alice's FOAF file giving Bob's age is not used to provide an age for Bob because the pattern involving variable age is restricted by ppd to a particular Personal Profile Document.
Query patterns can involve both the background graph and the named graphs. In this example, an aggregator has read in a web resource on two different occasions. Each time a graph is read into the aggregator, it is given a URI by the local system. The graphs are nearly the same but the email address for "Bob" has changed.
The background graph is being used to record the provenance information and the RDF data actually read is kept in two separate graphs, each of which is given a different URI by the system. The RDF dataset consists of two, named graphs and the information about them.
RDF Dataset:
# Background graph @prefix dc: <http://purl.org/dc/elements/1.1/> . <urn:x-local:graph1> dc:publisher "Bob" . <urn:x-local:graph1> dc:date "2004-12-06"^^xsd:date . <urn:x-local:graph2> dc:publisher "Bob" . <urn:x-local:graph2> dc:date "2005-01-10"^^xsd:date .
# Graph: locally allocated URI: urn:x-local:graph1 @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@oldcorp.example.org> .
# Graph: locally allocated URI: urn:x-local:graph2 @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@newcorp.example.org> .
This query finds email addresses, detailing the name of the person and the date the information was discovered.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?name ?mbox ?date WHERE { ?g dc:publisher ?name ; dc:date ?date . GRAPH ?g { ?person foaf:name ?name ; foaf:mbox ?mbox } }
name | mbox | date |
---|---|---|
"Bob" | <mailto:bob@oldcorp.example.org> | "2004-12-06"^^xsd:date |
"Bob" | <mailto:bob@newcorp.example.org> | "2005-01-10"^^xsd:date |
The URI for the date datatype has been abbreviated in the results for convenience.
Definition:
DataSet Graph Pattern
If D is a dataset {G, (<u1> G1), ...}, and P is a graph pattern then S
is a pattern solution of GRAPH(g, P) if:
g is a URI where g = <ui> for some i, and S is pattern solution of P on Gi
or g is a variable, S maps the variable g to <ui>
and S is a pattern solution of P on Gi.
This section has been added back into the document because the Working Group is now considering putting some language constructs to specify datasets. As such, this text has been added but not fully integrated and may be inconsistent with the rest of the document. Comments about the design are especially welcome.
The FROM clause gives a URI that the query processor can use to create the background graph and the FROM NAMED clause can be used to specify named graphs.
A query processor may use these URIs in any way to associate an RDF Dataset with a query. For example, it could use URIs to retrieve documents, parse them and use the resulting triples as one of the graphs; alternatively, it might only service queries that specify URIs of graphs that it already has stored.
The FROM clause a single URIs that indicates the graph to use as the background graph. This does not automatically put the graph in as a named graph; a query can do this by also specifying the graph in the FROM NAMED clause.
In this first example, there is a single background graph:
# Background graph @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name FROM <http://example.org/foaf/aliceFoaf> WHERE { ?x foaf:name ?name }
name |
---|
"Alice" |
A query can supply URIs for the named graphs in the RDF Dataset using the FROM NAMED clause. Each URI is used to provide one, named graph in the RDF Dataset.
# Graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Bob" . _:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?src ?name FROM NAMED <http://example.org/alice> FROM NAMED <http://example.org/bob> WHERE { GRAPH ?src { ?x foaf:name ?name } }
src | age |
---|---|
<http://example.org/bob> | 35 |
<http://example.org/alice> | 32 |
The FROM clause and FROM NAMED clauses can be used in the same query.
@@ToDo@@ Example based on example 1 section 7
Outline : help in wording appreciated.
Examples of where is matters: OPTIONALs, and FILTERS
For pattern P, let var(P) be the variables mentioned by P or any of its sub patterns. For pattern P, let var-u(P) be the variables mentioned by P or any of its sub patterns such that x is in var-u(P) and P is a union expression, then x occurs all sub-patterns. For group GP = { P1 or C1, (P2 or C2), ... (CN or PN) } P pattern C constraint
Fixed patterns: basic graph patterns and UNIONS
Recursive definition for nested patterns
Informally, this rule states that optional patterns must be executed as if it came after any basic graph patterns, where there is a common variable.
If variable x in var(Pi), and Pi is an optional and x in var(Pj) and Pj is a triple pattern or union then j < i
Informally, this rule states that there can't be two optionals with a common variable, if that variable does not occur in a basic graph pattern as well.
If variable x in var(Pi), and Pi is an optional and x in var-u(Pj) and Pj an optional, i != j then x must occur in some fixed Pk
By rule opt 1, k < i and j.
Informally, this rule states that constraints are evaluated after variable are assigned values.
If Ci is a constraint expression, variable x in var(Ci) and x in var(Pj) then j < i
SPARQL has a number of result forms for returning results. These result forms use the solutions from pattern matching to form result sets or RDF graphs. The query forms are:
- SELECT
- Returns all, or a subset of, the variables bound in a query pattern match. Formats for the result set can be in XML or RDF/XML (see the result format document)
@@ToDo@@Links to result format documents
- CONSTRUCT
- Returns an RDF graph constructed by substituting variables in a set of triple templates.
- DESCRIBE
- Returns an RDF graph that describes the resources found.
- ASK
- Returns whether a query pattern matches or not.
Query patterns generate a number of solutions and each solution is a set of variables and associated RDF terms. These solutions are passed through a stage to control the solution sequence, then passed to the result form for the query.
The controls on the sequence of solutions are:
The effect of applying these controls is as they are applied in the order given.
The solution sequence can be transformed to one only involving a subset of the variables. For each solution in the sequence, a new solution is formed using a specified selection of the variables.
Definition:
Projection
For a substitution S and a finite set of variables VS,
project(S, VS) = { (v, S[v]) | v in VS }
For a query solution Q project(Q, VS) is { project(S, VS) | S in Q }
For a set QS of query solutions, project(QS, VS) is { project(Q, V) | Q in QS
}
The DISTINCT modifier applies only for the SELECT result form.
@@ToDo@@ could make sense, with LIMIT and OFFSET, in CONSTRUCT and DESCRIBE
The solution sequence can be modified by adding the DISTINCT keyword which ensures that every combination of variable bindings (i.e. each solution) in the sequence is unique. Thought of as a table, each row is different.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@org> . _:z foaf:name "Alice" . _:z foaf:mbox <mailto:smith@work> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT DISTINCT ?name WHERE { ?x foaf:name ?name }
name |
---|
"Alice" |
If DISTINCT and LIMIT/OFFSET are specified, then duplicates are eliminated before the limit or offset is applied.
The ORDER BY clause takes a solution sequence and applies ordering conditions. An ordering condition can be a variable or a function call. The direction of ordering is ascending by default. It can be explicitly set to ascending or descending by enclosing the condition in ASC[] or DESC[] respectively. If multiple conditions are given, then they are applied in turn until one gives the indication of the ordering.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name } ORDER BY ?name
PREFIX : <http://example.org/ns#> PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> SELECT ?name WHERE { ?x foaf:name ?name ; :empId ?emp } ORDER BY DESC[?emp]
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name ; :empId ?emp } ORDER BY ?name DESC[?emp]
Using ORDER BY on a solution sequence for a result form other than SELECT has no direct effect because only SELECT returns a sequence of results, not an RDF graph. However, in combination with LIMIT and OFFSET, it can be used to return partial results.
When ordering a solution sequence involves an expression, it is possible that the ordering conditions do no give a completely determined ordering for the sequence. In this case the ordering of solutions that are not distinguished, is not determined.
If an ordering condition is a variable, SPARQL defines an fixed, arbitrary order between some kinds of RDF terms that would not otherwise be ordered. This arbitrary order is necessary to provide slicing of query solutions by use of LIMIT and OFFSET.
RDF Literals are compared with the "<" operator (see below) where possible.
If the ordering criteria do not specify the order of values, then the ordering in the solution sequence is undefined. However, an implementation must consistently impose the same order so that applying LIMIT/OFFSET will not miss any solutions.
Ordering a sequence of solutions always results in a sequence with the same number of solutions in it, even if the ordering criteria does not differentiate between two solutions.
Check whether xsd:string and plain literals are comparable with "<".
The LIMIT form puts an upper bound on the number of solutions returned. If the number of actual solutions is greater than the limit, then at most the limit number of solutions will be returned.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name } LIMIT 20
A limit of 0 will cause no results to be returned. A limit may not be negative.
OFFSET causes the solutions generated to start after the specified number of solutions. An OFFSET of zero has no effect.
The order in which solutions are returned is undefined so using LIMIT and OFFSET to select different subsets of the query solutions will given not be useful unless the order is made predictable by ensuring ordered results using ORDER BY.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name } ORDER BY ?name LIMIT 5 OFFSET 10
The SELECT form of results returns the variables directly. The syntax SELECT * is shorthand for "select all the named variables".
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:knows _:b . _:a foaf:knows _:c . _:b foaf:name "Bob" . _:c foaf:name "Clare" . _:c foaf:nick "CT" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?nameX ?nameY ?nickY WHERE { ?x foaf:knows ?y ; foaf:name ?nameX . ?y foaf:name ?nameY . OPTIONAL { ?y foaf:nick ?nickY } }
nameX | nameY | nickY |
---|---|---|
"Alice" | "Bob" | |
"Alice" | "Clare" | "CT" |
Result sets can be accessed by the local API but also can be serialized into either XML or an RDF graph. The XML result set form gives:
<?xml version="1.0"?> <sparql xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns="http://www.w3.org/2001/sw/DataAccess/rf1/result" > <head> <variable name="nameX"/> <variable name="nameY"/> <variable name="nickY"/> </head> <results> <result> <nameX>Alice</nameX> <nameY>Clare</nameY> <nickY>CT</nickY> </result> <result> <nameX>Alice</nameX> <nameY>Bob</nameY> <nickY bound="false"/> </result> </results> </sparql>
And in RDF/XML, using the Variable Binding Results XML Format [16] gives:
<rdf:RDF xmlns:rs="http://www.w3.org/2001/sw/DataAccess/tests/result-set#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rs:ResultSet> <rs:resultVariable>nickY</rs:resultVariable> <rs:resultVariable>nameX</rs:resultVariable> <rs:resultVariable>nameY</rs:resultVariable> <rs:solution rdf:parseType="Resource"> <rs:binding rdf:parseType="Resource"> <rs:variable>nameX</rs:variable> <rs:value>Alice</rs:value> </rs:binding> <rs:binding rdf:parseType="Resource"> <rs:value>CT</rs:value> <rs:variable>nickY</rs:variable> </rs:binding> <rs:binding rdf:parseType="Resource"> <rs:value>Clare</rs:value> <rs:variable>nameY</rs:variable> </rs:binding> </rs:solution> <rs:solution rdf:parseType="Resource"> <rs:binding rdf:parseType="Resource"> <rs:variable>nameX</rs:variable> <rs:value>Alice</rs:value> </rs:binding> <rs:binding rdf:parseType="Resource"> <rs:value>Bob</rs:value> <rs:variable>nameY</rs:variable> </rs:binding> </rs:solution> </rs:ResultSet> </rdf:RDF>
Results can be thought of as a table, with one row per query solution. Some cells may be empty because a variable is not bound in that particular solution.
The CONSTRUCT result form returns a single RDF graph specified by a graph template. The result is an RDF graph formed by taking each query solution in the solution sequence, substituting for the variables into the graph template and combining the triples into a single RDF graph by set union.
If any such instantiation produces a triple containing an unbound variable, or an illegal RDF construct (such as a literal in subject or predicate position) then that triple is not included in the RDF graph, and a warning may be generated.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@example.org> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> CONSTRUCT { <http://example.org/person#Alice> vcard:FN ?name } WHERE { ?x foaf:name ?name }
A template can create an RDF graph containing blank nodes. The labels are scoped to the template for each solution. If two such prefixed names share the same label in the template, then there will be one blank node created for each query solution but there will be different blank nodes across triples generated by different query solutions.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:givenname "Alice" . _:a foaf:family_name "Hacker" . _:b foaf:firstname "Bob" . _:b foaf:surname "Hacker" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> CONSTRUCT { ?x vcard:N _:v . _:v vcard:givenName ?gname . _:v vcard:familyName ?fname } WHERE { { ?x foaf:firstname ?gname } UNION { ?x foaf:givenname ?gname } . { ?x foaf:surname ?fname } UNION { ?x foaf:family_name ?fname } . }
The use of variable ?x in the template, which in this example will be bound to blank nodes, causes an equivalent graph to be constructed with a different blank node as shown by the document-scoped label.
Using CONSTRUCT it is possible to extract parts of, or the whole of, graphs from the target RDF dataset. This first example returns the graph (if it is in the dataset) with URI label http://example.org/myGraph otherwise it returns an empty graph.
CONSTRUCT { ?s ?p ?o } WHERE { GRAPH <http://example.org/myGraph> { ?s ?p ?o } . }
The access to the graph can be conditional on other information. Suppose the background graph contains metadata about the named graphs in the dataset then a query like this next one can extract one graph based on information about the named graph:
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX app: <http://example.org/ns#> CONSTRUCT { ?s ?p ?o } WHERE { GRAPH ?g { ?s ?p ?o } . { ?g dc:publisher <http://www.w3.org/> } . { ?g dc:date ?date } . FILTER app:myDate(?date) > "2005-02-28T00:00:00Z"^^xsd:dateTime . }
where app:myDate identified an extension function to turn the data format into an xsd:dateTime RDF Term..
The DESCRIBE form returns a single RDF graph containing RDF data about resources. This data is not prescribed by a SPARQL query, where the query client would need to know the structure of the RDF in the data source, but, instead, is determined by the SPARQL query processor.
The query pattern is used to create a result set. The DESCRIBE form takes each of the resources identified in a solution, together with any resources directly named by URI, and assembles a single RDF graph by taking a "description" from the target knowledge base. The description is determined by the query processor implementation and should provide a useful description of the resource, where "useful" is left to nature of the information in the data source.
If a data source, has no information about a resource, no RDF triples are added to the result graph but the query does not fail.
The working group adopted DESCRIBE without reaching consensus. The objection was that the expectations around DESCRIBE are very different from CONSTRUCT and SELECT, and hence it should be specified in a separate query language. If you have input to this aspect of the SPARQL that the working group has not yet considered, please send a comment to public-rdf-dawg-comments@w3.org.
The DESCRIBE clause itself can take URIs to identify the resources. The simplest query is just a URI in the DESCRIBE clause:
DESCRIBE <http://example.org/>
The resources can also be a query variable from a result set. This enables description of resources whether they are identified by URI or blank node in the dataset being queried.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> DESCRIBE ?x WHERE { ?x foaf:mbox <mailto:alice@org> }
The property foaf:mbox is defined as being an inverse function property in the FOAF vocabulary so, if treated as such, this query will return information about at most one person. If, however, the query pattern has multiple solutions, the RDF data for each is the union of all RDF graph descriptions.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> DESCRIBE ?x WHERE { ?x foaf:name "Alice" }
More than one URI or can be given:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> DESCRIBE ?x ?y <http://example.org/> WHERE {?x foaf:knows ?y}
The RDF returned is the choice of the deployment and may be dependent on the query processor implementation, data source and local configuration. It should be the useful information the server has (within security matters outside of SPARQL) about a resource. It may include information about other resources: the RDF data for a book may also include details of the author.
A simple query such as
PREFIX ent: <http://myorg.example/employees#> DESCRIBE ?x WHERE { ?x ent:employeeId "1234" }
might return a description of the employee and some other potentially useful details:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix vcard: <http://www.w3.org/2001/vcard-rdf/3.0> . @prefix myOrg: <http://myorg.example/employees#> . _:a myOrg:employeeId "1234" ;foaf:mbox_sha1sum "ABCD1234" ;
vcard:N [ vcard:Family "Smith" ; vcard:Given "John" ] .foaf:mbox_sha1sum rdf:type owl:InverseFunctionalProperty .
which includes the blank node closure for the vcard vocabulary vcard:N. For a vocabulary such as FOAF, where the
resources are typically blank nodes, returning sufficient information to
identify a node such as the InverseFunctionalProperty
foaf:mbox_sha1sum
as well information which as name
and other details recorded would be appropriate. In the example,
the match to the WHERE clause was returned but this is not
required.
Applications can use the ASK form to test whether or not a query pattern has a solution. No information is returned about the possible query solutions, just whether the server can find one or not.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . _:a foaf:name "Alice" . _:a foaf:homepage <http://work.example.org/alice/> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@work.example> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> ASK { ?x foaf:name "Alice" }
yes
@@ToDo@@ Align results to XML results format or some result form for ASK
on the same data, the following returns no match because Alice's mbox is not as described.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> ASK { ?x foaf:name "Alice" ; foaf:mbox <mailto:alice@work.example> }
no
SPARQL expressions are constructed according to the grammar and provide access to named functions and syntactically constructed operations. The operands of these functions and operators are the subset of XML Schema DataTypes {xsd:string, xsd:decimal, xsd:double, xsd:dateTime} and types derived from xsd:decimal. The SPARQL operations are listed in table 11.1 and are associated with productions in the grammar. In addition, SPARQL imports a subset of the XPath casting functions, listed in table 11.2, which are invokable by name within a SPARQL query. These functions and operators are taken from the XQuery 1.0 and XPath 2.0 Functions and Operators [17].
As described above, RDF Terms are made of
URIs (URI References), Literals and Blank Nodes. RDF Literals
may have datatypes in the instance data:
@prefix a: <http://www.w3.org/2000/10/annotation-ns#> . @prefix dc: <http://purl.org/dc/elements/1.1/> . _:a a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . _:a dc:created "2004-12-31T19:00:00-05:00" . _:b a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . _:b dc:created "2004-12-31T19:01:00-05:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
The first dc:created
arc has no type information. The second is tagged with the type xsd:dateTime
. SPARQL operators compare the values of types literals:
PREFIX a: <http://www.w3.org/2000/10/annotation-ns#> PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> SELECT ?annot WHERE { ?annot a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . ?annot dc:created ?date . FILTER ?date < xsd:dateTime("2005-01-01T00:00:00Z") }
A significant of RDF data has untyped literals. Literals may be cast to typed literals to use the SPARQL operators.
... FILTER xsd:dateTime(?date) < xsd:dateTime("2005-01-01T00:00:00Z") ...
Namespaces:
The namespace for XPath functions that are directly available by name is http://www.w3.org/2004/07/xpath-functions.
The associated namespace prefix used in this document is fn:
. XPath operators are named with the prefix op:
, XML Schema datatypes with the prefix op:
, and types of RDF terms with the prefix r:
. SPARQL operators are named with the prefix sop:
.
SPARQL defines a subset of the XPath functions and operators with operands of the following XML Schema datatypes:
In addition, SPARQL introduces additional operators which operate on RDF terms. RDF terms are identified by r:term and the constituant subclasses:
XPath defines a set of Numeric Type Promotions. Numeric operators are defined for the following three primitive XML Schema numeric
types:
These invoke XQuery's numeric type promotion to cast function arguments to the appropriate type. In summary: each of the numeric types is promoted to any type higher in the above list when used as an argument to function expecting that higher type. When an argument is promoted, the value is cast to the expected type. For instance, a "7"^^xs:decimal
will be converted to an "7.0E0"^^xs:double
when passed to an argument expecting an xs:double. Promotion does not change the bindings of variables.
The operators defined below that take numeric
arguments expect all arguments to be the same type. This is accomplished by promoting
the argument with the lower type to the same type as the other argument. For example, "7"^^xs:decimal
+
"6.5"^^xs:float
would call op:numeric-add("7"^^xs:float, "6.5"^^xs:float)
. In addition, any r:Literal may be cast to xs:string or xs:numeric when used as an argument to an operator expecting that type.
XML Schema [] defines a set of types derived from decimal
: integer
; nonPositiveInteger
; negativeInteger
; long
; int
; short
; byte
; nonNegativeInteger
; unsignedLong
; unsignedInt
; unsignedShort
; unsignedByte
and positiveInteger
. These are all treated as decimal
s for computing effective boolean values. SPARQL does not specifically require integrity checks on derived subtypes. SPARQL has no numeric type test operators so the distinction between a primitive type and a type derived from that primitive type is unobservable.
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:
||
) that encounters a type error will produce a type error.FILTER
will eliminate any solutions that yield an effective boolean value of false
or produce a type error.SPARQL defines a syntax for invoking functions and operators on a list of arguments. These are invoked as follows:
If any of these steps fails, the invocation generates an error. The effects of type errors are defined in SPARQL Functions and Operators.
When a operand is coerced to xs:boolean through invoking a function that takes a boolean argument, the following rules apply:
The result is TRUE
unless any of the following are true:
FALSE
value.xs:string
.xs:double
or xs:float
with a value of NaN
The SPARQL grammar identifies a set of operators (for instance, &&, *, isUri) used to construct constraints. The following table associates each of these grammatical productions with an operator defined by either the XQuery Operator Mapping or the additional SPARQL operators specified in section 11.2.2.
Some of the operators are associate with nested function expressions, e.g. fn:not(op:numeric-equal(A, B))
. Note that per the xpath definitions, fn:not
and op:numeric-equal
return an error if their argument is an error.
Operator | Type(A) | Type(B) | Function | Result type |
---|---|---|---|---|
XQuery Connectives | ||||
A || B | xs:boolean | xs:boolean | sop:logical-or(A, B) | xs:boolean |
Returns a boolean: TRUE if either A or B is true, else FALSE. | ||||
A && B | xs:boolean | xs:boolean | sop:logical-and(A, B) | xs:boolean |
Returns a boolean: TRUE if both A and B are true, else FALSE. | ||||
XPath Tests | ||||
A = B | xs:string | xs:string | op:numeric-equal(fn:compare(A, B), 0) | xs:boolean |
A != B | xs:string | xs:string | fn:not(op:numeric-equal(fn:compare(A, B), 0)) | xs:boolean |
A = B | numeric | numeric | op:numeric-equal(A, B) | xs:boolean |
A = B | xs:dateTime | xs:dateTime | op:dateTime-equal(A, B) | xs:boolean |
A != B | numeric | numeric | fn:not(op:numeric-equal(A, B)) | xs:boolean |
A != B | xs:dateTime | xs:dateTime | fn:not(op:dateTime-equal(A, B)) | xs:boolean |
A < B | numeric | numeric | op:numeric-less-than(A, B) | xs:boolean |
A < B | xs:dateTime | xs:dateTime | op:dateTime-less-than(A, B) | xs:boolean |
A > B | numeric | numeric | op:numeric-greater-than(A, B) | xs:boolean |
A > B | xs:dateTime | xs:dateTime | op:dateTime-greater-than(A, B) | xs:boolean |
A <= B | numeric | numeric | sop:logical-or(op:numeric-less-than(A, B), op:numeric-equal(A, B)) | xs:boolean |
A <= B | xs:dateTime | xs:dateTime | fn:not(op:dateTime-greater-than(A, B)) | xs:boolean |
A >= B | numeric | numeric | sop:logical-or(op:numeric-greater-than(A, B), op:numeric-equal(A, B)) | xs:boolean |
A >= B | xs:dateTime | xs:dateTime | fn:not(op:dateTime-less-than(A, B)) | xs:boolean |
A * B | numeric | numeric | op:numeric-multiply(A, B) | numeric |
A / B | numeric | numeric | op:numeric-divide(A, B) | numeric; but xs:decimal if both operands are xs:integer |
A + B | numeric | numeric | op:numeric-add(A, B) | numeric |
A - B | numeric | numeric | op:numeric-subtract(A, B) | numeric |
SPARQL Tests: defined in section 11.2.2 | ||||
A = B | r:term | r:term | sop:RDFterm-equal(A, B) | xs:boolean |
A != B | r:term | r:term | fn:not(sop:RDFterm-equal(A, B)) | xs:boolean |
bound(A) | variable | N/A | sop:isBound(A) | xs:boolean |
isURI(A) | variable | N/A | sop:isURI(A) | xs:boolean |
isBlank(A) | variable | N/A | sop:isBlank(A) | xs:boolean |
isLiteral(A) | variable | N/A | sop:isLiteral(A) | xs:boolean |
regex(STRING, PATTERN [, FLAGS]) | xs:string | xs:string [, xs:string] | fn:matches(STRING, PATTERN) fn:matches(STRING, PATTERN, FLAGS) | xs:boolean |
The XPath fn:matches is defined on the basis of Unicode code points; it takes no account of collations †. (Unicode's Character Foldings) | ||||
SPARQL Casts | ||||
str(A) | rdf:uri or rdf:literal | N/A | sop:str(A) | xs:string |
lang(A) | rdf:literal | N/A | sop:lang(A) | xs:string |
datatype(A) | rdf:literal | N/A | sop:datatype(A) | rdf:uri |
† fn:string-match
requires a collation
to define character order and string equivalence. The XQuery 1.0 and XPath 2.0 Functions and Operators [F&O] defines the semantics of fn:string-compare and establishes a default collation. In addition, it identifies a specific collation with a distinguished name, http://www.w3.org/2004/10/xpath-functions/collation/codepoint
which provides the ability to compare strings based on code point values. Every implementation of SPARQL must support the collation based on code point values.
This section defines the operators introduced by the SPARQL Query language. The names of the operators are prefixed with sop:
. The examples show the behavior of the operators as invoked by the appropriate grammatical constructs.
Returns TRUE if the two arguments are the same RDF term or they are literals known to have the same value. The latter is tested with an XQuery function appropriate to the arguments. This function is overloaded because there is no syntactic way to separate xs:string = xs:string
from r:literal = r:literal
(or r:uri or r:bNode). I think I'm happy with that. Are you, dear reader?
The following sop:RDFterm-equal
example passes the test because the mbox
terms are the same RDF term:
?u =
?v
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . _:a foaf:name "Alice". _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Ms A.". _:b foaf:mbox <mailto:alice@work.example> .
This query finds the people who have multiple foaf:name arcs:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name1 ?name2 WHERE { ?x foaf:name ?name1 ; foaf:mbox ?mbox1 . ?y foaf:name ?name2 ; foaf:mbox ?mbox2 . FILTER ?mbox1 = ?mbox2 && ?name1 != ?name2 }
Query result:
name1 | name2 |
---|---|
"Alice" | "Ms A." |
In this query for documents that were annotated on new years day (2004 or 2005), the RDF terms are not the same, but have equivalent values:
@prefix a: <http://www.w3.org/2000/10/annotation-ns#> . @prefix dc: <http://purl.org/dc/elements/1.1/> . _:b a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . _:b dc:created "2004-12-31T19:01:00-05:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
PREFIX a: <http://www.w3.org/2000/10/annotation-ns#> PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> SELECT ?annotates WHERE { ?annot a:annotates ?annotates . ?annot dc:created ?date . FILTER ?date = xsd:dateTime("2004-01-01T00:00:00Z") || ?date = xsd:dateTime("2005-01-01T00:00:00Z") }
annotates |
---|
<http://www.w3.org/TR/rdf-sparql-query/> |
Queries with union
and optional
s may have solutions with some unbound variables. The operator bound
tests that a variable has been bound to a value. NaNs and INFs count as defined.
bound
(?v)
Data:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix xs: <http://www.w3.org/2001/XMLSchema#> . _:a foaf:name "Alice". _:b foaf:givenname "Bob" . _:b dc:created "2005-04-04T04:04:04Z"^^xs:dateTime .
This query matches the people with a name and an mbox:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?name ?givenName WHERE { { ?x foaf:name ?name } UNION { ?x foaf:givenName ?givenName; dc:created ?created } . FILTER bound(?name) || ?created < "2005-01-01T00:00:00Z" }
Query result:
name | givenName |
---|---|
"Alice" |
One may test that a graph pattern is not expressed by specifying an optional
graph pattern that introduces a variable and testing to see that the variable is not
bound
. This is called Negation as Failure in logic programming.
This query matches the people with a name but no expressed created:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?name WHERE { ?x foaf:name ?name . OPTIONAL { ?x dc:created ?created } . FILTER !bound(?created) }
Query result:
name |
---|
"Alice" |
Because Alice's mbox was known, "Alice" was not a solution to the query.
Returns whether a variable is bound to a URI.
isURI
(?v)
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . _:a foaf:name "Alice". _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Bob" . _:b foaf:mbox "bob@work.example" .
This query matches the people with a name and an mbox which is a URI:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name ; foaf:mbox ?mbox . FILTER isUri(?mbox) }
Query result:
name | mbox |
---|---|
"Alice" | <mailto:alice@work.example> |
Returns whether a variable is bound to a blank node.
isBlank
(?v)
@prefix a: <http://www.w3.org/2000/10/annotation-ns#> . @prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . _:a dc:creator "Alice B. Toeclips" . _:b a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . _:b dc:creator _:c . _:c foaf:given "Bob". _:c foaf:family "Smith".
This query matches the people with a name and an mbox which is a URI:
PREFIX a: <http://www.w3.org/2000/10/annotation-ns#> PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?given ?family WHERE { ?annot a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . ?annot dc:creator ?c . OPTIONAL { ?c foaf:given ?given ; foaf:family ?family } . FILTER isBlank(?c) }
Query result:
given | family |
---|---|
"Bob" | "Smith" |
In this example, there were two objects of foaf:knows
predicates, but only one (_:c
) was a blank node.
Returns whether the argument is a literal.
isLiteral
(?v)
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . _:a foaf:name "Alice". _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Bob" . _:b foaf:mbox "bob@work.example" .
This query is similar to the one in 1.2.1.3 except that is matches the people with a name and an mbox which is a Literal. This would be used to look for erroneous data (foaf:mbox
should only have a URI as its object).
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name ; foaf:mbox ?mbox . FILTER isLiteral(?mbox) }
Query result:
name | mbox |
---|---|
"Bob" | "bob@work.example" |
Returns an xs:string representation of an r:URI. This useful for examining parts of a URI, for instance, the host-name.
str
(?v)
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . _:a foaf:name "Alice". _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@home.example> .
This query selects the set of people who use their work.example
address in their foaf profile:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name ; foaf:mbox ?mbox . FILTER regex(str(?mbox), "@work.example") }
Query result:
name | mbox |
---|---|
"Alice" | <alice@work.example> |
Returns a valid RFC 3066 language string representing the XML schema language datatype for a variable.
lang
(?v)
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . _:a foaf:name "Robert"@EN. _:a foaf:name "Roberto"@ES. _:a foaf:mbox <mailto:bob@work.example> .
This query finds the Spanish foaf:name and foaf:mbox:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name ; foaf:mbox ?mbox . FILTER lang(?name) = "ES" }
Query result:
name | mbox |
---|---|
"Roberto"@ES | <mailto:bob@work.example> |
Returns the datatype of its argument if that argument is a typed literal. Otherwise it fails.
datatype
(?v)
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix eg: <http://biometrics.example/ns#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . _:a foaf:name "alice". _:a eg:shoeSize "9.5"^^xsd:float . _:b foaf:name "bob". _:b eg:shoeSize "42"^^xsd:integer .
This query finds everyone's foaf:name and integer foaf:shoeSize:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> PREFIX eg: <http://biometrics.example/ns#> SELECT ?name ?size WHERE { ?x foaf:name ?name ; eg:shoeSize ?size . FILTER datatype(?size) = xsd:int }
Query result:
name | shoeSize |
---|---|
"Bob" | 42 |
Returns a logical OR
of the arguments. As with other functions and operators with boolean arguments, sop:logical-or
operates on the effective boolean value of its arguments.
?u ||
?v
Returns a logical AND
of the arguments. As with other functions and operators with boolean arguments, sop:logical-and
operates on the effective boolean value of its arguments.
?u &&
?v
SPARQL imports casting functions from the XPath. The XQuery Functions & Operators Primitive Type Mapping table [17] specifies a which primitive types are castable to which other primitive types. The table is reproduced below, omitting casting operations that are not in the SPARQL language, and adding the additional datatypes imposed by the RDF data model.
bool = xs:boolean
dbl = xs:double
flt = xs:float
dec = xs:decimal
int = xs:integer
dT = xs:dateTime
str = xs:string
URI = r:URIRef — introduced by the RDF data model
ltrl = r:Literal — introduced by the RDF data model
S\T | str | flt | dbl | dec | int | dT | bool | URI | ltrl |
---|---|---|---|---|---|---|---|---|---|
str | Y | M | M | M | M | M | M | M | M |
flt | Y | Y | Y | M | M | N | Y | N | N |
dbl | Y | Y | Y | M | M | N | Y | N | N |
dec | Y | Y | Y | Y | Y | N | Y | N | N |
int | Y | Y | Y | Y | Y | N | Y | N | N |
dT | Y | N | N | N | N | Y | N | N | N |
bool | Y | Y | Y | Y | Y | N | Y | N | N |
URI | Y | N | N | N | N | N | N | Y | N |
ltrl | Y | M | M | M | M | M | M | M | Y |
Implementations may provide custom extended value testing operations, for example, for specialized datatypes. These are provided by functions in the query that return true or false for their arguments.
qname( expression, expression , ...)
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX my: <http://my.example/functions#> SELECT ?name ?id WHERE { ?x foaf:name ?name ; my:empId ?id . FILTER my:even(?id) }
PREFIX myGeo: <http://my.example.org/geo#> SELECT ?x ?y WHERE { ?x myGeo:placeName "SWEB Town" . ?x myGeo:location ?xLoc . ?y myGeo:location ?yLoc . FILTER myGeo:distance(?x, ?y) < 10 . }
A function returns an RDF term. It might be used to test some application datatype not supported by the core SPARQL specification, it might be a transformation between datatype formats, for example into an XSD dateTime RDF term from another date format.
The function is called during FILTER evaluation for each possible query solution. A function is named by URI in a QName form, and returns an RDF term.
If a query processor encounters a function that it does not provide, the query is not executed and an error is returned.
Functions should have no side-effects. A SPARQL query processor may remove calls to functions if it can optimize them away.
Section status: drafted – terminal syntax not checked against that of the XML 1.1 spec
A SPARQL query is a sequence of characters in the language defined by the following grammar, starting with the Query production. The EBNF format is the same as that used in the XML 1.1 specification. Please see the "Notation" section of that specification for specific information about the notation.
Whitespace
Whitespace is used to separate two terminals which would otherwise be (mis-)recognized as one terminals. Whitespace in terminals is significant. Otherwise whitespace is ignored. Terminals are shown below enclosed in <> or shown in-line.
Keywords
Keywords are shown in uppercase and are matched in a case insensitive manner. The exception is the keyword 'a' which, in line with Turtle and N3, is used in place of the URI rdf:type (in full, http://www.w3.org/1999/02/22-rdf-syntax-ns#type).
Comments
Comments in SPARQL queries take the form of '#', outside a URI or string, and continue to the end of line or end of file if there is no end of line after the comment marker.
We expect to state some formal characteristics of the grammar in later drafts.
@@ToDo@@ Split into acknowledgements and references, noting whether normative or not.
References
@@ToDo@@How many of these are still used?
@@ToDo@@Mention SeRQL or reference emails
[1] "Three Implementations of SquishQL, a Simple RDF Query Language", Libby Miller, Andy Seaborne, Alberto Reggiori; ISWC2002
[2] "RDF Query and Rules: A Framework and Survey", Eric Prud'hommeaux
[3] "RDF Query and Rule languages Use Cases and Example", Alberto Reggiori, Andy Seaborne
[4] RDQL Tutorial for Jena (in the Jena tutorial).
[6] Enabling Inference, R.V. Guha, Ora Lassila, Eric Miller, Dan Brickley
[8] RDF http://www.w3.org/RDF/
[9] "Representing vCard Objects in RDF/XML", Renato Iannella, W3C Note.
[10] "RDF Data Access Working Group"
[11] "RDF Data Access Use Cases and Requirements ? W3C Working Draft 2 June 2004", Kendall Grant Clark.
[12] "Resource Description Framework (RDF): Concepts and Abstract Syntax", Graham Klyne, Jeremy J. Carroll, W3C Recommendation.
[13] RFC 3986, "Uniform Resource Identifier (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter
[14] "Namespaces in XML 1.1", Tim Bray et al., W3C Recommendation.
[15] "Turtle - Terse RDF Triple Language, Dave Beckett.
[16] "SPARQL Variable Binding Results XML Format", Dave Beckett.
[17] "XQuery 1.0 and XPath 2.0 Functions and Operators", Ashok Malhotra et al., W3C Working Draft.
CVS Change Log:
$Log: Overview.html,v $
Revision 1.6 2018/10/09 13:31:29 denis
fix validation of xhtml documents
Revision 1.5 2017/10/02 10:30:43 denis
add fixup.js to old specs
Revision 1.4 2005/04/20 09:48:58 eric
removed extraneous link meant for editor's draft
Revision 1.3 2005/04/19 22:35:52 matthieu
fixed typo
Revision 1.2 2005/04/19 22:26:54 matthieu
fixed previous version
Revision 1.1 2005/04/19 22:22:16 matthieu
new entry
Revision 1.318 2005/04/19 22:16:34 eric
typos
Revision 1.317 2005/04/19 22:09:04 eric
trimmed CVS log for publication
3rd WD ready for publication
Revision 1.316 2005/04/19 22:06:20 eric
pubrules checker
Revision 1.315 2005/04/19 22:03:40 eric
prep for publication
Revision 1.314 2005/04/19 21:49:02 eric
add heading ids
Revision 1.313 2005/04/19 21:38:56 eric
link checking
Revision 1.312 2005/04/19 20:55:16 eric
namespace validating
Revision 1.311 2005/04/19 20:51:31 eric
css validating
Revision 1.310 2005/04/19 20:50:08 eric
css validating
Revision 1.309 2005/04/19 20:40:10 eric
validating markup
Revision 1.308 2005/04/19 19:12:28 eric
incorporated most of andy's comments
Revision 1.307 2005/04/18 08:33:41 aseaborne
Typos
Revision 1.306 2005/04/17 18:50:10 aseaborne
typos
Revision 1.305 2005/04/17 18:42:08 aseaborne
Working through section 7
+ Typos
+ Include text in example 2 that puts RDF merging of
data down to the publisher of the data and not part
of the spec.
Revision 1.304 2005/04/17 18:00:36 aseaborne
Working through sections 5 and 6
+ Fix text in 5 intro. Typos.
+ 5.3 Query pattern => Graph Pattern
+ Link broken in 2
+ Fixed missing link in 4 2
+ Tweak text in 5.5 (nested optionals)
+ Remove section 5.6 (it moved to the wider discussion of ordering).
+ 6 - title now "Matching Alternatives"
+ 6.2 - Tidy text; highlight that UNION takes
groups for parameters (like all graph operators).
+ Add missing defn tags to definitions
throughout the document
+ 6.3 Definition seems to have swallowed the next para - split out.
Revision 1.303 2005/04/16 17:13:51 aseaborne
+ ORDERing: choose case 1: implementations
(should be consistent but exactly what is not defined)
so as to allow for processors that handle datatypes outside
the core set.
+ 10.3 Change "merging" (which is not an RDF merge and wasn't
qualified as such) to "combining ... by set union.".
Revision 1.302 2005/04/16 16:48:50 aseaborne
Working through sections 3 and 4.
+ 3.2 binding -> bindings
+ Defn Value Constraint: "A graph pattern may involve
a value constraint ..."
+ 4 Graph Patterns - list possibilities
4.1 New section specifically for groups
Old 4.1 => 4.2
Revision 1.301 2005/04/16 16:10:40 aseaborne
Working through sections 1 and 2.
+ TOC and section headings:
Section 2 : Sub-section titles : "Basic Graph Pattern"
Section 4 : "Graph Patterns"
+ Added a table for prefixes used for better
layout in narrow windows.
+ Unpdate "Query Term Syntax"
+ s/bNode/blank node/g in text
+ Removed reference? because we
use RFC 3986 terminology.
+ 2.1 Use link to unbound variables section.
+ 2.2 Add defn of Graph Pattern - all forward references to later sections.
+ 4 Add basic graph patterns to elements of a graph pattern
+ Commented out definition of restriction as it appears to be no longer used.
+ Removed overview text in 2.4
+ 2.6 More text to clarify role of blank nodes in queries.
+ 2.7 Removed comment on nesting of syntax a it seems to create more
confusion than light.
Revision 1.300 2005/04/14 11:43:04 eric
pre- Graph Pattern overhaul
incorporated DaveB's comments up to 4
Revision 1.299 2005/04/14 08:04:03 aseaborne
Removed reification syntax
Revision 1.298 2005/04/13 14:34:20 aseaborne
fix HTML ptII
Revision 1.296 2005/04/13 14:26:36 aseaborne
+ Bare text for section on specifying graphs in datasets
Revision 1.295 2005/04/13 10:53:36 aseaborne
+ Noted todo "?x ?x" example.
+ Grammar update
Revision 1.294 2005/04/13 08:19:57 eric
incorporated DaveB's comments up to 2.2
Revision 1.293 2005/04/05 14:26:19 connolly
ispell fixes: predciate, dadatype, expliitly, dataypes, operatates,
specialised
hyphenated subpatterns, hostname, inline per m-w.com
per http://www.w3.org/2001/06/manual/#Spelling
Revision 1.292 2005/04/05 11:25:22 eric
waffled back to decimal derivatives being only used for ebvs
Revision 1.291 2005/04/04 19:21:03 connolly
WF fixes
Revision 1.290 2005/04/01 15:29:04 eric
renumbered chapter 11 subsections
Revision 1.289 2005/04/01 05:42:35 eric
s/primative/primitive/
Revision 1.288 2005/04/01 03:58:12 eric
reworked examples to be friendly to existing schemas
sending to WG now.
Revision 1.287 2005/04/01 03:13:41 eric
aggressive pass through section 11, rewording and clarifying a lot about the execution model
Revision 1.286 2005/03/31 08:26:41 eric
add a function mapping for matches with a flags parameter
Revision 1.285 2005/03/31 07:50:53 eric
comparing a bNode and a URI does NOT produce an error (<foo> != [] is TRUE)
Revision 1.284 2005/03/30 13:10:14 aseaborne
Fix <br>
Revision 1.283 2005/03/30 13:08:55 aseaborne
revised definition for optional
Revision 1.282 2005/03/30 10:27:13 aseaborne
+ Updated grammar
+ Syntax for ascending/.descending is ASC[] / DESC[]
Revision 1.281 2005/03/30 09:02:44 eric
moved matches around
Revision 1.280 2005/03/30 08:56:36 eric
questions from implementation and testing SPARQL0 test
Revision 1.279 2005/03/29 16:35:45 aseaborne
+ Added "distance" example for extension functions.
Revision 1.278 2005/03/29 14:23:47 eric
include derived types in the set of handled types
Revision 1.277 2005/03/29 13:01:09 eric
+ numeric derived types
Revision 1.276 2005/03/28 16:29:24 aseaborne
Typo
Revision 1.275 2005/03/28 16:26:51 aseaborne
+ Section 10: ORDER BY
Sub sections on order by expression and order by variable.
noting that ordering be partial
Revision 1.274 2005/03/28 14:57:35 aseaborne
+ Tidyup sections 7 & 8
Revision 1.273 2005/03/28 14:18:49 aseaborne
+ Typographical corrections to section 5 & 6.
Revision 1.272 2005/03/28 11:27:48 aseaborne
+ Remove special talk about constraints from the definition of group
+ Noted need 4.1 about unbound variables
+ Tidy up 2.6 to 4
+ Some misc 'tidy'ing up
Revision 1.271 2005/03/26 15:55:37 aseaborne
Change refs involving the word "disjunction" to ones using "union"
Revision 1.270 2005/03/24 15:33:19 aseaborne
*** empty log message ***
Revision 1.269 2005/03/24 13:59:43 aseaborne
Missed a change
Revision 1.268 2005/03/24 13:50:33 aseaborne
+ Corrections provided by Kevin
2005JanMar/0435
Revision 1.267 2005/03/22 17:48:32 aseaborne
+ Reworded 11.3 to be inline with general function-rturns-RDF term.
Revision 1.266 2005/03/22 16:12:41 eric
validated better
Revision 1.265 2005/03/22 16:10:41 eric
validated
Revision 1.264 2005/03/22 10:23:24 aseaborne
+ Noted need for references and acknowledgements
+ Ensured "{ }" is a legal graph pattern
Revision 1.263 2005/03/21 17:01:20 aseaborne
Grammar update
Revision 1.262 2005/03/21 16:06:44 aseaborne
+ Move Projection and DISTINCT out of SELECT, into solution sequence processing
Revision 1.261 2005/03/21 14:53:14 aseaborne
Mistake in TOC href
Revision 1.260 2005/03/21 14:49:53 aseaborne
+ Example of two forms of RDF datasets:
1/ Provenance information in background graph
2/ RDF merge into the background graph.
Revision 1.259 2005/03/21 14:19:27 aseaborne
+ Typos and editorial matters from 2005Mar/0031
Revision 1.258 2005/03/21 11:14:35 aseaborne
Corrections from comment list message: dawg comments 2005Mar/0028
Revision 1.257 2005/03/18 16:32:45 aseaborne
More on ordering.
Revision 1.256 2005/03/17 17:39:55 aseaborne
Example mistake: LIMIT and OFFSET were the wrong way round
Revision 1.255 2005/03/17 17:15:46 aseaborne
+ Some refinement of order evaluation rules.
Revision 1.254 2005/03/17 17:00:35 aseaborne
+ Clarify the grammar WRT tokens and whitespace.
+ Example of getting a whole graph from a dataset using CONSTRUCT
+ More on sorting
Revision 1.253 2005/03/17 13:51:56 aseaborne
+ Clarify the grammar WRT tokens and whitespace.
Revision 1.252 2005/03/16 15:44:30 aseaborne
+ More notes on ORDER BY syntax.
Revision 1.251 2005/03/15 18:20:25 aseaborne
+ Make section 10.1 (move rest along) - relationship between
solutions and result forms
+ Notes for ORDER BY, LIMIT, OFFSET
Revision 1.250 2005/03/15 15:35:45 eric
update NAF syntax
Revision 1.249 2005/03/15 15:34:44 eric
update NAF syntax
Revision 1.248 2005/03/15 15:17:53 eric
validated
Revision 1.247 2005/03/15 15:14:48 eric
validated
Revision 1.246 2005/03/15 15:05:46 eric
less contrived BOUND operator example
Revision 1.245 2005/03/14 19:34:59 eric
folks seem to prefer "regex".
clean up styling nits.
Revision 1.244 2005/03/14 18:17:47 aseaborne
+ Removed text for default prefixes for rdf: rdfs: owl: xsd:
Revision 1.243 2005/03/14 14:03:47 aseaborne
+ "CONSTRUCT *" removed
+ CONTRUCT/LIMIT and DESCRIBE/LIMIt mentioned
+ Grammar updated
Revision 1.242 2005/03/14 12:29:54 aseaborne
+ Section 2 intro: brief para to set the scene.
+ Section 2 : description of syntact forms for bNode property lists,
RDF collections and reification
Revision 1.241 2005/03/11 10:39:17 aseaborne
+ Added 'a' as a synonym for rdf:type as a property to the grammar
Revision 1.240 2005/03/10 18:38:56 aseaborne
+ Corrected example using foaf:PersonalProfileDocument
Now uses rdfs:seeAlso and a rdf:type assertion.
Queries change to match
+ Inserted ToDos
Revision 1.239 2005/03/10 12:03:31 aseaborne
+ Replaced == by = ; replaced eq by = ; replaced ne by !=
Revision 1.238 2005/03/10 11:56:58 aseaborne
+ New syntax
Grammar updates
Examples converted
Revision 1.237 2005/03/09 16:43:39 aseaborne
+ Noted that must describe various syntactic forms (2.7)
Revision 1.236 2005/03/08 16:44:54 aseaborne
+ Remove section 9 (WITH/FROM)
+ Note for section 9 - execution order
+ A few typos
Revision 1.235 2005/02/28 17:03:25 eric
added namespace to function invocation example
Revision 1.234 2005/02/25 10:53:49 aseaborne
+ Update grammar:
+ Remove "eq" and "ne", change "==" to "="
reflecting use inline with XQuery/XPath2/F&O
except we choose to use "=" "<" etc, not "eq", "lt"
+ str() and datatype() take expressions
+ Combined *AsExpr/*AsNode states
Revision 1.233 2005/02/23 17:51:15 eric
fixed LANG per danbri's comments, responses
Revision 1.232 2005/02/23 15:48:42 eric
still more words on negation as failure per pat's mail
Revision 1.231 2005/02/23 03:46:19 eric
new words on negation as failure per pat's mail
Revision 1.230 2005/02/22 18:17:06 aseaborne
+ Reference Turtle in the text
+ Discuss BASE; add to example of syntax
Revision 1.229 2005/02/22 14:16:59 eric
removed NOT per pat's comment
Revision 1.228 2005/02/19 11:24:47 eric
added EBV
Revision 1.227 2005/02/18 17:49:18 eric
+ further clarification as an editor's draft
- trimmed change log at 1.200
Revision 1.226 2005/02/18 17:40:55 eric
fixed pointer to published working draft
Revision 1.225 2005/02/17 19:38:13 eric
turned back into an editor's draft