Please refer to the errata for this document, which may include some normative corrections.
The previous errata for this document, are also available.
See also translations.
Copyright © 2010 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
RDF is a directed, labeled graph data format for representing information in the Web. This specification defines the syntax and semantics of the SPARQL query language for RDF. SPARQL can be used to express queries across diverse data sources, whether the data is stored natively as RDF or viewed as RDF via middleware. SPARQL contains capabilities for querying required and optional graph patterns along with their conjunctions and disjunctions. SPARQL also supports aggregation, subqueries, creating values by complex expressions, extensible value testing, and constraining queries by source RDF graph. The results of SPARQL queries can be results sets or RDF graphs.
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.
The documents produced by this Working Group are:
This publication includes the new features of SPARQL 1.1 into the main SPARQL Query specification. The structure of this document will change to fully integrate the new features. In this publication, new content is gathered together for ease of review of these new features.
The new features are:
No incompatibilities with existing valid SPARQL queries, in either syntax or results, will be introduced by these extensions to the language.
The design of the features presented here is work-in-progress and does not represent the final decisions of the working group. Implementers and application writers should not assume that the designs in this document will not change.
This is a Working Draft.
Comments on this document should be sent to public-rdf-dawg-comments@w3.org, a mailing list with a public archive. Questions and comments about SPARQL that are not related to this specification, including extensions and features, can be discussed on the mailing list public-sparql-dev@w3.org, (public archive).
This document was produced by the SPARQL Working Group, which is part of the W3C Semantic Web Activity.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Introduction
1.1 Document Outline
1.2 Document Conventions
1.2.1 Namespaces
1.2.2 Data Descriptions
1.2.3 Result Descriptions
1.2.4 Terminology
2 Making Simple Queries (Informative)
2.1 Writing a Simple Query
2.2 Multiple Matches
2.3 Matching RDF Literals
2.3.1 Matching Literals with Numeric Types
2.3.2 Matching Literals with Arbitrary Datatypes
2.4 Blank Node Labels in Query Results
2.5 Creating Values with Expressions
2.6 Building RDF Graphs
3 RDF Term Constraints (Informative)
3.1 Restricting the Value of Strings
3.2 Restricting Numeric Values
3.3 Other Term Constraints
4 SPARQL Syntax
4.1 RDF Term Syntax
4.1.1 Syntax for IRIs
4.1.1.1 Prefixed names
4.1.1.2 Relative IRIs
4.1.2 Syntax for Literals
4.1.3 Syntax for Query Variables
4.1.4 Syntax for Blank Nodes
4.2 Syntax for Triple Patterns
4.2.1 Predicate-Object Lists
4.2.2 Object Lists
4.2.3 RDF Collections
4.2.4 rdf:type
5 Graph Patterns
5.1 Basic Graph Patterns
5.1.1 Blank Node Labels
5.1.2 Extending Basic Graph Pattern Matching
5.2 Group Graph Patterns
5.2.1 Empty Group Pattern
5.2.2 Scope of Filters
5.2.3 Group Graph Pattern Examples
6 Including Optional Values
6.1 Optional Pattern Matching
6.2 Constraints
in Optional Pattern Matching
6.3 Multiple Optional Graph
Patterns
7 Matching Alternatives
8 Negation
8.1 Filtering Using Graph Patterns
8.1.1 Testing For the Absence of a Pattern
8.1.2 Testing For the Presence of a Pattern
8.2 Removing Possible Solutions
8.3 Relationship and difference between NOT EXISTS and MINUS
9 Property Paths
9.1 Property Path Expressions
9.2 Examples
9.3 Algebra for Property Paths
9.3.1 Translation of Property Paths
9.3.2 Material for the "Initial Definitions" section
9.3.2.1 Property Paths Patterns
9.3.3 Property Path Expression Matching
9.3.3.1 SPARQL Property Path Pattern Matching
9.3.4 Material for the SPARQL syntax to SPARQL algebra section
9.3.5 Material for the SPARQL algebra section
9.3.6 Material for the SPARQL Evaluation Semantics section
9.3.6.1 Zero-length paths
9.3.6.2 Arbitrary length paths
10 Aggregates
10.1 Aggregate Example
10.2 Algebra Operators
10.2.1 HAVING
10.2.2 Set Functions
10.2.3 Mapping from Abstract Syntax to Algebra
11 Subqueries
12 RDF Dataset
12.1 Examples of RDF Datasets
12.2 Specifying RDF Datasets
12.2.1 Specifying the Default Graph
12.2.2 Specifying Named Graphs
12.2.3 Combining FROM and FROM NAMED
12.3 Querying the Dataset
12.3.1 Named and Default
Graphs
13 Basic Federated Query
14 Solution Sequences and Modifiers
14.1 ORDER BY
14.2 Projection
14.3 Duplicate Solutions
14.4 OFFSET
14.5 LIMIT
15 Query Forms
15.1 SELECT
15.1.1 Projection
15.1.2 SELECT expressions
15.2 CONSTRUCT
15.2.1 Templates with Blank Nodes
15.2.2 Accessing Graphs in the RDF Dataset
15.2.3 Solution Modifiers and CONSTRUCT
15.3 ASK
15.4 DESCRIBE (Informative)
15.4.1 Explicit IRIs
15.4.2 Identifying Resources
15.4.3 Descriptions of Resources
16 Testing Values
16.1 Operand Data Types
16.2 Filter Evaluation
16.2.1 Invocation
16.2.2 Effective Boolean Value (EBV)
16.3 Operator Mapping
16.3.1 Operator Extensibility
16.4 Operators Definitions
16.4.1 bound
16.4.2 isIRI
16.4.3 isBlank
16.4.4 isLiteral
16.4.5 isNumeric
16.4.6 str
16.4.7 lang
16.4.8 datatype
16.4.9 logical-or
16.4.10 logical-and
16.4.11 RDFterm-equal
16.4.12 sameTerm
16.4.13 langMatches
16.4.14 regex
16.4.15 COALESCE
16.4.16 IF
16.4.17 IN
16.4.18 NOT IN
16.4.19 IRI
16.4.20 URI
16.4.21 BNODE
16.4.22 STRDT
16.4.23 STRLANG
16.4.24 NOT EXISTS and EXISTS
16.5 Constructor Functions
16.6 Extensible Value Testing
17 Definition of SPARQL
17.1 Initial Definitions
17.1.1 RDF Terms
17.1.2 RDF Dataset
17.1.3 Query Variables
17.1.4 Triple Patterns
17.1.5 Basic Graph Patterns
17.1.6 Solution Mapping
17.1.7 Solution Sequence Modifiers
17.2 SPARQL Query
17.2.1 Converting Graph Patterns
17.2.2 Examples of Mapped Graph Patterns
17.2.3 Converting Solution Modifiers
17.3 Basic Graph Patterns
17.3.1 SPARQL Basic Graph Pattern Matching
17.3.2 Treatment of Blank Nodes
17.4 SPARQL Algebra
17.5 Evaluation Semantics
17.6 Extending SPARQL Basic Graph Matching
17.6.1 Notes
18 SPARQL Grammar
19 Conformance
20 Security Considerations (Informative)
21 Internet Media Type, File Extension and Macintosh File Type
A References
A.1 Normative References
A.2 Other References
B CVS History
RDF is a directed, labeled graph data format for representing information in the Web. RDF is often used to represent, among other things, personal information, social networks, metadata about digital artifacts, as well as to provide a means of integration over disparate sources of information. This specification defines the syntax and semantics of the SPARQL query language for RDF.
The SPARQL query language for RDF is designed to meet the use cases and requirements identified by the RDF Data Access Working Group in RDF Data Access Use Cases and Requirements [UCNR].
The SPARQL query language is closely related to the following specifications:
Unless otherwise noted in the section heading, all sections and appendices in this document are normative.
@@Revise when structure stable
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 the ability to constrain portions of a query to particular source graphs. Section 8 also presents SPARQL's mechanism for defining the source graphs for a query.
Section 9 defines the constructs that affect the solutions of a query by ordering, slicing, projecting, limiting, and removing duplicates from a sequence of solutions.
Section 10 defines the four types of SPARQL queries that produce results in different forms.
Section 11 defines SPARQL's extensible value testing framework. It also presents the functions and operators that can be used to constrain the values that appear in a query's results.
Section 12 is a formal definition of the evaluation of SPARQL graph patterns and solution modifiers.
Appendix A contains the normative definition of the SPARQL query language's syntax, as given by a grammar expressed in EBNF notation.
In this document, examples assume the following namespace prefix bindings unless otherwise stated:
Prefix | IRI |
---|---|
rdf: | http://www.w3.org/1999/02/22-rdf-syntax-ns# |
rdfs: | http://www.w3.org/2000/01/rdf-schema# |
xsd: | http://www.w3.org/2001/XMLSchema# |
fn: | http://www.w3.org/2005/xpath-functions# |
This document uses the Turtle [TURTLE] data format to show each triple explicitly. Turtle allows IRIs to be abbreviated with prefixes:
@prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix : <http://example.org/book/> . :book1 dc:title "SPARQL Tutorial" .
Result sets are illustrated in tabular form.
A 'binding' is a pair (variable,
RDF term). In this result set, there are three
variables:
x
, y
and z
(shown as column headers). Each
solution is shown as one row in the body of the table. Here, there is a single
solution, in which variable x
is bound to "Alice"
, variable
y
is bound to <http://example/a>
, and variable z
is not bound to an RDF term. Variables are not required to be bound in a
solution.
The SPARQL language includes IRIs, a subset of RDF URI References that omits spaces. Note that all IRIs in SPARQL queries are absolute; they may or may not include a fragment identifier [RFC3987, section 3.1]. IRIs include URIs [RFC3986] and URLs. The abbreviated forms (relative IRIs and prefixed names) in the SPARQL syntax are resolved to produce absolute IRIs.
The following terms are defined in RDF Concepts and Abstract Syntax [CONCEPTS] and used in SPARQL:
RDF URI reference
")datatype URI
")Most forms of SPARQL query contain a set of triple patterns called a basic graph pattern. Triple patterns are like RDF triples except that each of the subject, predicate and object may be a variable. A basic graph pattern matches a subgraph of the RDF data when RDF terms from that subgraph may be substituted for the variables and the result is RDF graph equivalent to the subgraph.
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.
Data:
<http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title> "SPARQL Tutorial" .
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> .
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> |
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 .
Note that, in Turtle, "cat"@en
is an RDF literal with a lexical form "cat" and a language tag en
; "42"^^xsd:integer
is a typed literal with the datatype http://www.w3.org/2001/XMLSchema#integer
; and "abc"^^dt:specialDatatype
is a typed literal with the datatype http://example.org/datatype#specialDatatype
.
This RDF data is the data graph for the query examples in sections 2.3.1–2.3.3.
Language tags in SPARQL are expressed using @
and the
language tag, as defined in Best Common Practice 47 [BCP47].
This following query has no solution because "cat"
is not the
same RDF literal as "cat"@en
:
SELECT ?v WHERE { ?v ?p "cat" }
v |
---|
but the query below will find a solution where variable v
is bound to
:x
because the language tag is specified and matches the given data:
SELECT ?v WHERE { ?v ?p "cat"@en }
v |
---|
<http://example.org/ns#x> |
Integers in a SPARQL query indicate an RDF typed literal with the datatype
xsd:integer
. For example: 42
is a shortened form
of "42"^^<http://www.w3.org/2001/XMLSchema#integer>
.
The pattern in the following query has a solution with variable v
bound to :y
.
Section 4.1.2 defines SPARQL shortened forms for xsd:float
and xsd:double
.
Query results can contain blank nodes. Blank nodes in the example result sets in this document are written in the form "_:" followed by a blank node label.
Blank node labels are scoped to a result set (as defined in "SPARQL
Query Results XML Format") or, for the CONSTRUCT
query
form, the result graph.
Use of the same label within a
result set indicates the same blank node.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:b foaf:name "Bob" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?x ?name WHERE { ?x foaf:name ?name }
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 are the same or different.
These two results have the same information: the blank nodes used to match the
query are different in the two solutions. There need not be any relation between a
label
_:a
in the result set and a blank node in the data graph
with the same label.
An application writer should not expect blank node labels in a query to refer to a particular blank node in the data.
SPARQL 1.1 allows to create values from complex expressions.
The query below shows how to concatenate first names and last names from foaf data.
This can be achieved by using expressions in the SELECT
clause.
@@Example of expression in SELECT clause
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:givenName "John" . _:a foaf:surname "Doe" .
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.
Data:
@prefix org: <http://example.com/ns#> . _:a org:employeeName "Alice" . _:a org:employeeId 12345 . _:b org:employeeName "Bob" . _:b org:employeeId 67890 .
Query:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX org: <http://example.com/ns#> CONSTRUCT { ?x foaf:name ?name } WHERE { ?x org:employeeName ?name }
Results:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:x foaf:name "Alice" . _:y foaf:name "Bob" .
which can be serialized in RDF/XML as:
<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>
Graph pattern matching produces a solution sequence, where each solution has a set of bindings of variables to RDF terms. SPARQL FILTER
s
restrict solutions to those for which the filter expression evaluates to TRUE
.
This section provides an informal introduction to SPARQL FILTER
s; their semantics are defined in @@ Section 11. Testing Values. The examples in this section share one input graph:
@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 .
SPARQL FILTER
functions like regex
can test RDF literals. regex
matches only plain
literals with no language tag.
regex
can be used to match the lexical forms of other literals by
using the str
function.
Query:
PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?title WHERE { ?x dc:title ?title FILTER regex(?title, "^SPARQL") }
Query Result:
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" ) }
Query Result:
The regular expression language is defined by XQuery 1.0 and XPath 2.0 Functions and Operators and is based on XML Schema Regular Expressions.
By constraining the price
variable, only :book2
matches
the query because only :book2
has a price less than 30.5
,
as the filter condition requires.
@@ Fix section refs
In addition to numeric types, SPARQL supports
types xsd:string
, xsd:boolean
and xsd:dateTime
(see 11.1 Operand Data Types). 11.3 Operator Mapping lists a set of test functions, including BOUND
, isLITERAL
and langMATCHES
and accessors, including STR
, LANG
and DATATYPE
. 11.5 Constructor Functions (@@ renumber) lists a set of XML Schema constructor functions that are in the SPARQL language to cast values from one type to another.
This section covers the syntax used by SPARQL for RDF terms and triple patterns. The full grammar is given in appendix A.
The IRIref production designates the set of IRIs [RFC3987]; IRIs are a generalization of URIs [RFC3986] and are fully compatible with URIs and URLs. The PrefixedName production designates a prefixed name. The mapping from a prefixed name to an IRI is described below. IRI references (relative or absolute IRIs) are designated by the IRI_REF production, where the '<' and '>' delimiters do not form part of the IRI reference. Relative IRIs match the irelative-ref reference in section 2.2 ABNF for IRI References and IRIs in [RFC3987] and are resolved to IRIs as described below.
[67] | IRIref | ::= | IRI_REF | PrefixedName |
[68] | PrefixedName | ::= | PNAME_LN | PNAME_NS |
[69] | BlankNode | ::= | BLANK_NODE_LABEL | ANON |
[70] | IRI_REF | ::= | '<' ([^<>"{}|^`\]-[#x00-#x20])* '>' |
[71] | PNAME_NS | ::= | PN_PREFIX? ':' |
[72] | PNAME_LN | ::= | PNAME_NS PN_LOCAL |
The set of RDF terms defined in RDF Concepts and Abstract Syntax
includes RDF URI references while SPARQL terms include IRIs. RDF URI
references containing "<
", ">
", '"
' (double
quote), space, "{
", "}
", "|
",
"\
", "^
", and
"`
" are not IRIs. The behavior of a SPARQL query against RDF
statements composed of such RDF URI references is not defined.
The PREFIX
keyword associates a prefix label with an IRI. A prefixed
name is a prefix label and a local part, separated by a colon ":
".
A prefixed name is mapped to an IRI by concatenating the IRI associated with the prefix and the local part.
The prefix label or the local part may be empty. Note that SPARQL local names allow leading digits while XML local names do not.
Relative IRIs are combined with base IRIs as per Uniform Resource Identifier (URI): Generic Syntax [RFC3986] using only the basic algorithm in Section 5.2 . Neither Syntax-Based Normalization nor Scheme-Based Normalization (described in sections 6.2.2 and 6.2.3 of RFC3986) are performed. Characters additionally allowed in IRI references are treated in the same way that unreserved characters are treated in URI references, per section 6.5 of Internationalized Resource Identifiers (IRIs) [RFC3987].
The BASE
keyword defines the Base IRI used to resolve relative IRIs
per RFC3986 section 5.1.1, "Base URI Embedded in Content". Section 5.1.2, "Base
URI from the Encapsulating Entity" defines how the Base IRI may come from an encapsulating
document, such as a SOAP envelope with an xml:base directive or a mime multipart
document with a Content-Location header. The "Retrieval URI" identified in 5.1.3,
Base "URI from the Retrieval URI", is the URL from which a particular SPARQL query
was retrieved. If none of the above specifies the Base URI, the default Base URI
(section 5.1.4, "Default Base URI") is used.
The following fragments are some of the different ways to write the same IRI:
<http://example.org/book/book1>
BASE <http://example.org/book/> <book1>
PREFIX book: <http://example.org/book/> book:book1
The general syntax for literals is a string (enclosed in either double
quotes, "..."
, or single quotes, '...'
), with either an optional
language tag (introduced by @
) or an optional datatype IRI or prefixed
name (introduced by ^^
).
As a convenience, integers can be written directly (without quotation marks and an explicit datatype IRI) and are interpreted as typed
literals of datatype xsd:integer
; decimal numbers for which there is '.'
in the number but no exponent are interpreted as xsd:decimal
; and
numbers with exponents are interpreted as xsd:double
. Values of
type xsd:boolean
can also be written as true
or
false
.
To facilitate writing literal values which themselves contain quotation marks or which are long and contain newline characters, SPARQL provides an additional quoting construct in which literals are enclosed in three single- or double-quotation marks.
Examples of literal syntax in SPARQL include:
"chat"
'chat'@fr
with language tag "fr""xyz"^^<http://example.org/ns/userDatatype>
"abc"^^appNS:appDataType
'''The librarian said, "Perhaps you would enjoy 'War and Peace'."'''
1
, which is the same as "1"^^xsd:integer
1.3
, which is the same as "1.3"^^xsd:decimal
1.300
, which is the same as "1.300"^^xsd:decimal
1.0e6
, which is the same as "1.0e6"^^xsd:double
true
, which is the same as "true"^^xsd:boolean
false
, which is the same as "false"^^xsd:boolean
Tokens matching the productions INTEGER, DECIMAL, DOUBLE and
BooleanLiteral are equivalent to a typed
literal with the lexical value of the token and the corresponding
datatype (xsd:integer
, xsd:decimal
, xsd:double
, xsd:boolean
).
@@SPARQL 1.1 : need to modify the variable scope description to reflect subqueries.
Query variables in SPARQL queries have global scope; use of a given variable
name anywhere in a query identifies the same variable. Variables are prefixed by
either "?" or "$"; the "?" or "$" is not part of the variable name.
In a query, $abc
and ?abc
identify the same variable. The
possible names for variables are given in the
SPARQL grammar.
[44] | Var | ::= | VAR1 | VAR2 |
[74] | VAR1 | ::= | '?' VARNAME |
[75] | VAR2 | ::= | '$' VARNAME |
[97] | VARNAME | ::= | ( PN_CHARS_U | [0-9] ) ( PN_CHARS_U | [0-9] | #x00B7 | [#x0300-#x036F] | [#x203F-#x2040] )* |
Blank nodes in graph patterns act as non-distinguished variables, not as references to specific blank nodes in the data being queried.
Blank nodes are indicated by either the label form, such as "_:abc
", or the abbreviated form "[]
". A blank
node that is used in only one place in the query syntax can be indicated with
[]
. A unique blank node will be used to form the triple
pattern. Blank node labels are written as "_:abc
" for a blank node with
label "abc
". The same blank node label cannot be used
in two different basic graph patterns in the same query.
The [:p :v]
construct can be used in triple patterns. It creates
a blank node label which is used as the subject of all contained predicate-object
pairs. The created blank node can also be used in further triple patterns in the
subject and object positions.
The following two forms
[ :p "v" ] .
[] :p "v" .
allocate a unique blank node label (here "b57
") and are equivalent
to writing:
_:b57 :p "v" .
This allocated blank node label can be used as the subject or object of further triple patterns. For example, as a subject:
[ :p "v" ] :q "w" .
which is equivalent to the two triples:
_:b57 :p "v" . _:b57 :q "w" .
and as an object:
:x :q [ :p "v" ] .
which is equivalent to the two triples:
:x :q _:b57 . _:b57 :p "v" .
Abbreviated blank node syntax can be combined with other abbreviations for common subjects and common predicates.
[ foaf:name ?name ; foaf:mbox <mailto:alice@example.org> ]
This is the same as writing the following basic graph pattern for some uniquely
allocated blank node label, "b18
":
_:b18 foaf:name ?name . _:b18 foaf:mbox <mailto:alice@example.org> .
[39] | BlankNodePropertyList | ::= | '['PropertyListNotEmpty']' |
[69] | BlankNode | ::= | BLANK_NODE_LABEL | ANON |
[73] | BLANK_NODE_LABEL | ::= | '_:' PN_LOCAL |
[94] | ANON | ::= | '[' WS* ']' |
Triple Patterns are written as a whitespace-separated list of a subject, predicate and object; there are abbreviated ways of writing some common triple pattern constructs.
The following examples express the same query:
PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?title WHERE { <http://example.org/book/book1> dc:title ?title }
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX : <http://example.org/book/> SELECT $title WHERE { :book1 dc:title $title }
BASE <http://example.org/book/> PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT $title WHERE { <book1> dc:title ?title }
[32] | TriplesSameSubject | ::= | VarOrTerm PropertyListNotEmpty | |
[33] | PropertyListNotEmpty | ::= | Verb ObjectList ( ';' ( Verb ObjectList )? )* |
[34] | PropertyList | ::= | PropertyListNotEmpty? |
[35] | ObjectList | ::= | Object ( ',' Object )* |
[37] | Verb | ::= | VarOrIRIref | 'a' |
Triple patterns with a common subject can be written so that the subject is only
written once and is used for more than one triple pattern by employing the ";
"
notation.
?x foaf:name ?name ; foaf:mbox ?mbox .
This is the same as writing the triple patterns:
?x foaf:name ?name . ?x foaf:mbox ?mbox .
If triple patterns share both subject and predicate, the objects may be separated
by ",
".
?x foaf:nick "Alice" , "Alice_" .
is the same as writing the triple patterns:
?x foaf:nick "Alice" . ?x foaf:nick "Alice_" .
Object lists can be combined with predicate-object lists:
?x foaf:name ?name ; foaf:nick "Alice" , "Alice_" .
is equivalent to:
?x foaf:name ?name . ?x foaf:nick "Alice" . ?x foaf:nick "Alice_" .
RDF collections can be written in triple patterns using the syntax "(element1 element2 ...)". The
form "()
" is an alternative for the IRI
http://www.w3.org/1999/02/22-rdf-syntax-ns#nil
.
When used with collection elements, such as (1 ?x 3 4)
, triple patterns
with blank nodes are allocated for the collection. The blank node at the head
of the collection can be used as a subject or object in other triple patterns. The blank nodes allocated by the collection syntax do not occur elsewhere in the query.
(1 ?x 3 4) :p "w" .
is syntactic sugar for (noting that b0
, b1
, b2
and b3
do not occur anywhere else in the
query):
_:b0 rdf:first 1 ; rdf:rest _:b1 . _:b1 rdf:first ?x ; rdf:rest _:b2 . _:b2 rdf:first 3 ; rdf:rest _:b3 . _:b3 rdf:first 4 ; rdf:rest rdf:nil . _:b0 :p "w" .
RDF collections can be nested and can involve other syntactic forms:
(1 [:p :q] ( 2 ) ) .
is syntactic sugar for:
_:b0 rdf:first 1 ; rdf:rest _:b1 . _:b1 rdf:first _:b2 . _:b2 :p :q . _:b1 rdf:rest _:b3 . _:b3 rdf:first _:b4 . _:b4 rdf:first 2 ; rdf:rest rdf:nil . _:b3 rdf:rest rdf:nil .
[40] | Collection | ::= | '(' GraphNode+ ')' |
[92] | NIL | ::= | '(' WS* ')' |
The keyword "a
" can be used as a predicate in a triple pattern and
is an alternative for the IRI
http://www.w3.org/1999/02/22-rdf-syntax-ns#type
.
This keyword is case-sensitive.
?x a :Class1 . [ a :appClass ] :p "v" .
is syntactic sugar for:
?x rdf:type :Class1 . _:b0 rdf:type :appClass . _:b0 :p "v" .
SPARQL is based around graph pattern matching. More complex graph patterns can be formed by combining smaller patterns in various ways:
In this section we describe the two forms that combine patterns by conjunction: basic graph patterns, which combine triples patterns, and group graph patterns, which combine all other graph patterns.
The outer-most graph pattern in a query is called the query pattern. It is grammatically identified by GroupGraphPattern
in
[13] | WhereClause | ::= | 'WHERE'? GroupGraphPattern |
Basic graph patterns are sets of triple patterns. SPARQL graph pattern matching is defined in terms of combining the results from matching basic graph patterns.
A sequence of triple patterns interrupted by a filter comprises a single basic graph pattern. Any graph pattern terminates a basic graph pattern.
When using blank nodes of the form _:abc
, labels for blank
nodes are scoped to the basic graph pattern. A label can be used in only a
single basic graph pattern in any query.
SPARQL is defined for matching RDF graphs with simple entailment. SPARQL can be extended to other forms of entailment given certain conditions as described below.
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 . } }
[20]
|
GroupGraphPattern
| ::= |
'{' TriplesBlock? ( ( GraphPatternNotTriples | Filter ) '.'? TriplesBlock? )* '}'
|
[21]
|
TriplesBlock
| ::= | TriplesSameSubject ( '.' TriplesBlock? )?
|
[22] | GraphPatternNotTriples | ::= |
OptionalGraphPattern | GroupOrUnionGraphPattern | GraphGraphPattern
|
The group pattern:
{ }
matches any graph (including the empty graph) with one solution that does not bind any variables. For example:
SELECT ?x WHERE {}
matches with one solution in which variable x
is not bound.
A constraint, expressed by the keyword FILTER
, is a
restriction on solutions over the whole group in which the filter appears. The
following patterns all have the same solutions:
{ ?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 . }
is a group of one basic graph pattern and that basic graph pattern consists of two triple patterns.
{ ?x foaf:name ?name . FILTER regex(?name, "Smith") ?x foaf:mbox ?mbox . }
is a group of one basic graph pattern and a filter, and that basic graph pattern consists of two triple patterns; the filter does not break the basic graph pattern into two basic graph patterns.
{ ?x foaf:name ?name . {} ?x foaf:mbox ?mbox . }
is a group of three elements, a basic graph pattern of one triple pattern, an empty group, and another basic graph pattern of one triple pattern.
Basic graph patterns allow applications to make queries where the entire query pattern must match for there to be a solution. For every solution of a query containing only group graph patterns with at least one basic graph pattern, every variable is bound to an RDF Term in a solution. However, regular, complete structures cannot be assumed in all RDF graphs. It is useful to be able to have queries that allow information to be added to the solution where the information is available, but do not reject the solution because some part of the query pattern does not match. Optional matching provides this facility: if the optional part does not match, it creates no bindings but does not eliminate the solution.
Optional parts of the graph pattern may be specified syntactically with the OPTIONAL keyword applied to a graph pattern:
pattern OPTIONAL { pattern }
The syntactic form:
{ OPTIONAL { pattern } }
is equivalent to:
{ { } OPTIONAL { pattern } }
[23] | OptionalGraphPattern | ::= | 'OPTIONAL' GroupGraphPattern |
The OPTIONAL
keyword is left-associative :
pattern OPTIONAL { pattern } OPTIONAL { pattern }
is the same as:
{ pattern OPTIONAL { pattern } } OPTIONAL { pattern }
In an optional match, either the optional graph pattern matches a graph, thereby defining and adding bindings to one or more solutions, or it leaves a solution unchanged without adding any additional bindings.
Data:
@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" .
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 .
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 } }
Query result:
@@Additional SPARQL 1.1. syntax - can omit the {} for the LHS to bring into line with OPTIONAL and MINUS.
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.
Pattern alternatives are syntactically specified with the UNION
keyword.
@prefix dc10: <http://purl.org/dc/elements/1.0/> . @prefix dc11: <http://purl.org/dc/elements/1.1/> . _:a dc10:title "SPARQL Query Language Tutorial" . _:a dc10:creator "Alice" . _:b dc11:title "SPARQL Protocol Tutorial" . _:b dc11:creator "Bob" . _:c dc10:title "SPARQL" . _:c dc11:title "SPARQL (updated)" .
PREFIX dc10: <http://purl.org/dc/elements/1.0/> PREFIX dc11: <http://purl.org/dc/elements/1.1/> SELECT ?title WHERE { { ?book dc10:title ?title } UNION { ?book dc11:title ?title } }
Query result:
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. To determine exactly how the information was recorded, a query could use different variables for the two alternatives:
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 } }
This will return results with the variable x
bound for solutions from the left branch of the UNION
, and y
bound
for the solutions from the right branch. If neither part of the UNION
pattern matched, then the graph pattern would not match.
The UNION
pattern combines graph patterns; each alternative possibility can contain more
than one triple
pattern:
PREFIX dc10: <http://purl.org/dc/elements/1.0/> PREFIX dc11: <http://purl.org/dc/elements/1.1/> SELECT ?title ?author WHERE { { ?book dc10:title ?title . ?book dc10:creator ?author } UNION { ?book dc11:title ?title . ?book dc11:creator ?author } }
This query will only match a book if it has both a title and creator predicate from the same version of Dublin Core.
[25] | GroupOrUnionGraphPattern | ::= | GroupGraphPattern
|
The SPARQL query language incorporates two styles of negation, one based on filtering results depending on whether a graph pattern does or does not match in the context of the query solution being filtered, and one based on removing solutions related to another pattern.
Filtering of query solutions is done within a FILTER
expression using NOT EXIST
and EXISTS
.
Note that the filter scope rules
apply to the
whole group in which the filter appears.
The NOT EXISTS
filter expression tests whether a graph pattern does
not match the dataset, given the values of variables in-scope. It does
not generate any additional bindings.
Data:
@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 .
Query:
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 } }
Query Result:
person |
---|
<http://example/bob> |
The filter expression EXISTS
is also provided.
It tests whether the pattern can be found in the data;
it does not generate any additional bindings.
Query:
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 } }
Query Result:
person |
---|
<http://example/alice> |
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" . } }
Results:
s |
---|
<http://example/carol> |
<http://example/alice> |
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 } }
evaluates to a result set with no solutions because { ?x ?y ?z }
matches given any ?s ?p ?o
, so NOT EXISTS { ?x ?y ?z }
eliminates any solutions.
s | p | o |
---|
whereas with MINUS
, there is no shared variable between the
first part (?s ?p ?o
) and the second (?x ?y ?z
)
so no bindings are eliminated.
SELECT * { ?s ?p ?o MINUS { ?x ?y ?z } }Results:
s | p | o |
---|---|---|
<http://example/a> | <http://example/b> | <http://example/c> |
Another case is where there is a concrete pattern (no variables) in the example:
PREFIX : <http://example/> SELECT * { ?s ?p ?o FILTER NOT EXISTS { :a :b :c } }
evaluates to a result set with no query solutions:
Results:s | p | o |
---|
whereas
PREFIX : <http://example/> SELECT * { ?s ?p ?o MINUS { :a :b :c } }
evaluates to result set with one query solution:
Results:s | p | o |
---|---|---|
<http://example/a> | <http://example/b> | <http://example/c> |
because there is no match of bindings and so no solutions are eliminated.
A property path is a possible route through a graph between two graph nodes. A trivial case is a property path of length exactly 1, which is a triple pattern. Property paths allow for more concise expression of some SPARQL basic graph patterns and also add the ability to match arbitrary length paths. The ends of the path may be RDF terms or variables. Variables can not be used as part of the path itself, only the ends. Query evaluation determines all matches of a path expression and binds subject or object as appropriate.
Matching cycles in the graph is possible. A path of length zero connects a graph node to itself.
In the description below, uri is either a URI, a prefixed name, or the keyword a, and elt is a path element, which may itself be composed of path syntax constructs.
Syntax Form | Matches |
---|---|
uri | A URI or a prefixed name. A path of length one. |
^elt | Inverse path (object to subject). |
!uri or !(uri1| ...|urin) | Negated property set. A URI which is not one of urii |
!^uri and !(uri1| ...|urij|^urij+1| ...|^urin) | Negated property set. A URI which is not one of urii, nor one of urij+1...urin as reverse paths |
(elt) | A group path elt, brackets control precedence. |
elt1 / elt2 | A sequence path of elt1, followed by elt2 |
elt1 | elt2 | A alternative path of elt1, or elt2 (all possibilities are tried). |
elt* | A path of zero or more occurrences of elt. |
elt+ | A path of one or more occurrences of elt. |
elt? | A path of zero or one elt. |
elt{n,m} | A path between n and m occurrences of elt. |
elt{n} | Exactly n occurrences of elt. |
elt{n,} | n or more occurrences of elt. |
elt{,n} | Between 0 and n occurrences of elt. |
The order of URIs, and reverse URIs, in a negated property sets is not significant and they can occur in a mixed order.
The precedence of the syntax forms is, from highest to lowest:
Precedence is left-to-right within groups.
@@reformat/restyle
Find the name of any people that Alice knows.
{ ?x foaf:mbox <mailto:alice@example> . ?x foaf:knows/foaf:name ?name . }
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 can be written as:
{ ?x foaf:mbox <mailto:alice@example> . ?x foaf:knows{2}/foaf:name ?name . }
This is the same as the strict SPARQL query:
{ ?x foaf:mbox <mailto:alice@example> . ?x foaf:knows [ foaf:knows [ foaf:name ?name ]]. }
or, with explicit variables:
{ ?x foaf:mbox <mailto:alice@example> . ?x foaf:knows ?a1 . ?a1 foaf:knows ?a2 . ?a2 foaf:name ?name . }
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 }
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 }
Find all the people who know someone ?x knows.
{ ?x foaf:knows^foaf:knows ?y . FILTER(?x != ?y) }
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 . }
Some forms of limited inference are possible as well. For example: 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 }
The material in this section will be moved into the defintions sections of this document
This section describes the translation of the path syntax forms into other SPARQL expressions and hence to the SPARQL algebra. Three new algebra operators are introduced: ZeroLengthPath which defines the evaluation of zero-length path (e.g. ?x :p{0} ?y), ArbitraryLengthPath which defines the evaluation of path of one or more steps (e.g. ?x :p+ ?y) and NegatedPropertySet which defines the evaluation of a path element not matching a set of properties.
Two steps: this set of rewrites, followed by recombining into BGPs
Notes:
Syntax Form (path) | translate(path) |
---|---|
X uri Y | Triple pattern: X uri Y |
X !(:uri1|...|:urin) Y | NegatedPropertySet(X,{:uri1 ... :urin} ,Y) |
X !(^:uri1|...|^:urin)Y | ^(X !(:uri1|...|:urin) Y) |
X !(:uri1|...|:urii|^:urii+1|...|^:urim) Y | { X !(:uri1|...|:urii|)Y } UNION { X !(^:urii+1|...|^:urim) Y } |
X ^path Y | Y path X |
X path1 / path2 Y | X path1 ?V . ?V path2 Y |
X path1 | path2 Y | { X path1 Y } UNION { X path2 Y} |
X path* Y | { X path{0} Y } UNION { X path+ Y} |
X path+ Y | ArbitraryPath(X, path, Y) |
X path? Y | { X path{0} Y } UNION { X path Y} |
X path{0} Y | ZeroLengthPath(X, path, Y) |
X path{n} Y where n > 0 | X path ?V1 . ?V1 path ?V2 ... ?Vn-1 path Y |
X path{n,m} Y | { X path{n} Y } UNION { X path{n+1} Y } ... UNION { X path{m} Y} |
X path{n,} Y | X path{n} ?V . ?V path* Y |
X path{,n} Y | X path{0,n} Y |
A Property Path is a sequence of triples, ti in ST, such that, for i=0 to length(ST)-1, the object of ti is the same term as the subject of ti+1.
We call the subject of t0 the start of the path.
We call the object of tn the end of the path.
Property Path PP is a path in graph G if each ti is a triple of G.
A property path expression is an expression form after translation of the path syntax as defined above.
More commonly called a property path or path, when clear.
Let PP be the set of all property path expressions.
A property path pattern is a member of the set:
(RDF-T union V) x PP x (RDF-T union V)
A Property Path Pattern is a generalization of a Triple Pattern to include a property path in the property position.
To go after Basic Graph Patterns
Alt: in evaluation section
Rename "Basic Graph Patterns" as "Basic Graph Pattern Matching"
@@The material of "translate"
If the form is
TriplesBlock
@@Extend for Property Paths
The result is BGP(list of triple patterns)
@@Translate can go straight to algebra form + combine any adjacent triples patterns into one BGP (but not across {} boundaries)
Definition: ZeroLengthPath
A zero length path matches all subjects and all objects in the graph, and also any IRIs explitictly given as endpoints of the path pattern.
Definition: ArbitraryLengthPath
An arbitrary length path P = (X (path)+ Y) is all solutions from X to Y such that any intermediate nodes in the graph are traversed once only. An intermediate node is one which does not form an endpoint of the path match.
Definition: Negated Property Set
A Negated Property Set, NPS, is a pair (F,B) where F and B are sets of IRIs. F is the set of forward links and B is the set of the backward links.
Maybe better in with the path evaluation after BGP
@@ Add X:T syntax to the intro to "Evaluation Semantics in rq25
eval(D(G), pathPattern) = eval(D(G), translate(x, path, y)) = * translate(PathpathExpression) only depends on BGP, UNION, ArbitraryPath and ZeroLengthPath. Definition: nodes(G) nodes(G) = { n | n is an RDF term and either n is a subject or an object of some triple T in G } * nodes(G) is the node set of the graph.
Definition: Evaluation of ZeroLengthPath
eval(D(G), ZeroLengthPath(vx:var, path, vy:var))) = { {(vx, term), (vy, term)} | term in nodes(G) } card[] = 1 eval(D(G), ZeroLengthPath(vx:var, path, y:term)) = { { (vx, y) } } card[] = 1 eval(D(G), ZeroLengthPath(x:term, path, vy:var)) = { { (vy, x) } } card[] = 1 * does not matter if x or y is in nodes(G) or not. eval(D(G), ZeroLengthPath(x:term, path, y:term)) = if x is the same term as y { {} } card[] = 1 else { } card[] = 1 * Multiset of one solution mapping, which is the solution mapping of no variables
Definition: Evaluation of ArbitraryLengthPath
An arbitrary length path @@
ArbitraryLengthPath(?x (path)+ ?y) = @@
The matching algorithm is based on following all paths, and detecting when a graph node (subject or object), has been already visited by the path.
Definition: Evaluation of ArbitraryLengthPath eval(D(G), ArbitraryLengthPath(x, path, y)) = i.e. the SPARQl pattern x path+ y . Define: ALP ALP(x:term, path) = ALP(x:term, path, {}) ALP(x:term, path, Visited) = if ( x in Visited ) return empty set. Visited = Visited union {x} T = Path(x, path, y) R = empty list for t in T R = R union {t} union ALP(t, Path, Visited) Visited = Visited \ {x} result is R then eval(D(G), ArbitraryLengthPath(x:term, path, vy:var)) = { {(vy, n) | n in ALP(x, path) } eval(D(G), ArbitraryLengthPath(vx:var, path, vy:var)) = multiset-union(ArbitraryLengthPath(t, path, vy) | t in nodes(G)) eval(D(G), ArbitraryLengthPath(vx:var, path, y:term)) = multiset-union({(vx,t)} | t in nodes(G) and y in ArbitraryLengthPath(t, path, y) }) card[] Note that ArbitraryLengthPath(vx:var, path, vy:term) = ArbitraryLengthPath(y:term, ^path, vx:var) eval(D(G), ArbitraryLengthPath(x:term, path, y:term)) = { { } } if y in ALP(x, path) { } if y not in ALP(x, path)
Informally, this algorithm attempts to extend the multiset of results by one application of path at each step, noting which nodes it has visited for this particular path in Visited. If a node has been visited for the path under consideration, it is not a candidate for another step. A node can still be visited multiple times if there are two different paths that visit it.
Aggregates apply expressions over groups of solutions. By default a solution set consists of a single group, containing all solutions.
Grouping may be specified using the GROUP BY
syntax.
Aggregates defined in version 1.1 of SPARQL/Query are
COUNT
, SUM
, MIN
, MAX
, AVG
, GROUP_CONCAT
, and SAMPLE
.
Data:
@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 .
Query:
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)
Results:
?totalPrice |
---|
21 |
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.
In aggregate queries and sub-queries variables that appear in the query
pattern, but are not grouped by cannot be projected nor used in project
expressions. In order to project arbitrary expressions the SAMPLE
aggregate may be used.
ListEval is a function which is used to evaluate a list of expressions against a solution and return a list of the resulting values.
Definition: ListEval
ListEval(ExprList, μ) returns a list E, where Ei = μ(ExprListi).
A variant, ListEvalE, is the same except that all elements of E which are errors are removed.
Group, a function which groups a solution sequence into multiple solutions, based on some attribute of the solutions.
Group evaluates a list of expressions against a solution sequence, producing a set of partial functions from keys to solution sequences.
The behaviour of Group is different when ExprList is empty. Note that the use of the number 1 here, is simply to distinguish from groups where the ExprList is non-empty.
Group((), Ω) = { 1 -> Ω }
Group(ExprList, Ω) = { ListEval(ExprList, μ) -> { μ' | μ' in Ω, ListEval(ExprList, μ) = ListEval(ExprList, μ') } | μ in Ω }
For example, given a solution sequence S, ( {?x→2, ?y→3}, {?x→2, ?y→5}, {?x→6, ?y→7} ),
Group((?x), S) = {
(2) → ( {?x→2, ?y→3}, {?x→2, ?y→5} ),
(6) → ( {?x→6, ?y→7} )
}
Aggregation, a function which calculates a scalar value as an output of the aggregate expression in the SELECT clause.
Aggregation applies a set function “func” to a multiset of lists of expressions and a grouped solution sequence, G as produced by the Group function. It produces a single value for each key and partition for that key (key, X).
Aggregation(ExprList, func, scalar, G) = { dom(g) → F | g in G }
Where
M = ListEvalE(ExprList, range(g))
F = func(M, card[range(g)] - card[M], scalar), for non-DISTINCT
F = func(Distinct(M), card[range(g)] - card[M], scalar), for DISTINCT
Special Case: when COUNT
is used with the expression
*
the value of F will be cardinality of the group solution
sequence, card[range(g)], or card[Distinct(range(g))] if the
DISTINCT
keyword is present.
"scalar" is a set of partial functions passed from the aggregate in the query. These are used to pass values to the underlying set function, bypassing the mechanics of the grouping. For example the aggregate expression GROUP_BY(?x ; separator="|") has a scalar argument of { "separator" → "|" }.
All aggregates may have the DISTINCT
keyword as
the first token in their argument list. If this keyword is present then first
argument to func is Distinct(M).
Example
Given a solution multiset (Ω) with the following values:
?x | ?y | ?z |
1 | 2 | 3 |
1 | 3 | 4 |
2 | 5 | 6 |
And the query expression SELECT (ex:agg(?y, ?z) AS ?agg) WHERE { ?x ?y ?z } GROUP BY ?x.
We produce G = Group((?x), Ω) = { (1) → {?y=2, ?z=3}, {?y=3, ?z=4}), (2) → {?y=5, ?z=6} }
And so Aggregation((?y, ?z), ex:agg, {}, G) =
{ (1) → eg:agg({(2, 3), (3, 4)}, {})), (2) → eg:agg({(5, 6)}, {}) }.
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, see the section on aggregate projection.
Definition: Having
Let X be the algebra expression from the select expression, and expr to be an expression. We define:
Having(expr, X) = Filter(expr, X)
@@ possibly unintended consequence of the ordering in 17.1.7 is that HAVING can only operate on projected variables.
The set functions which underlie SPARQL aggregates all have a common signature: SetFunc(M, err), or SetFunc(M, err, scalar, ...) where M is a multiset of lists, err is a value indicating whether the evaluation of any of the expressions evaluated with respect to Ω returned an error, and scalar is one or more scalar values that are passed to the set function indirectly via the ( ... ; key=value ) syntax for aggregates in the SPARQL grammar.
Flatten is a function which is used to collapse multisets of lists into a multiset, so for example { (1, 2), (3, 4) } becomes { 1, 2, 3, 4 }.
Definition: Flatten
The Flatten(M) function takes a multiset of lists, M {(L1, L2, ...), ...}, and returns the multiset given by the multiset union of { Li | L in M } for all i in L.
Count is a SPARQL set function which counts the number of times a given expression has a bound, and non-error value with the aggregate group.
Definition: Count
Count(M, err) = card[Flatten(M)]
Sum is a SPARQL set function that will return the numeric value obtained by summing the values within the aggregate group. Type promotion happens as per the op:numeric-add function, applied transitively,(see definition below) so the value of SUM(?x), in an aggregate group where ?x has values 1 (integer), 2.0e0 (float), and 3.0 (decimal) will be 6.0 (float).
Definition: Sum
The Sum set function is used by the SUM
aggregate in the syntax.
Sum(M, err) = Sum(ToList(Flatten(M))).
Sum(S) = op:numeric-add(S0, Sum(S1..n)) when |S| > 1
Sum(S) = op:numeric-add(S0, 0) when |S| = 1
Sum(S) = 0 when |S| = 0
In this way, Sum({1, 2, 3}) = op:numeric-add(op:numeric-add(1, 0), op:numeric-add(2, 3)).
The Avg set function calculates the average value for an expression over a group. It is defined in terms of Sum and Count.
Definition: Avg
Avg(M, err) = 0, where Count(M, err) = 0
Avg(M, err) = Sum(M, err) / Count(M, err), where Count(M, err) > 0
For example, Avg({1, 2, 3}) = Sum({1, 2, 3})/Count({1, 2, 3}) = 6/3 = 2.
Min and Max are SPARQL set functions that return the minimum and maximum value from a group respectively.
This makes use of the SPARQL ORDER BY ordering definition, to allow ordering over arbitrarily typed expressions.
Definition: Min
Min(M, err) = Min(ToList(Flatten(M))).
The flattened multiset of values passed as an argument is converted to a sequence S, this sequence is ordered as per the ORDER BY ASC
clause.
Min(S) = S0
Definition: Max
Max(M, err) = Max(ToList(Flatten(M))).
The multiset of values passed as an argument is converted to a sequence S, this sequence is ordered as per the ORDER BY DESC
clause.
Max(S) = S0
GroupConcat is a set function which performs a string concatenation across the values of an expression with a group. The order of the strings is not specified. The separator character used in the concatenation may be given with the scalar argument SEPARATOR.
Definition: GroupConcat
If the "separator" scalar argument is absent from GROUP_CONCAT then it is taken to be the “space” character, unicode codepoint U+0020.
The multiset of values passed as an argument is converted to a sequence S.
GroupConcat(M, err, scalar) = GroupConcat(ToList(Flatten(M), scalar)
GroupConcat(S, scalar) = fn:string-join(S, scalar("separator"))
Note that fn:string-join denotes the XPath function string-join
For example, GroupConcat({"a", "b", "c"}, {"separator" → "."}) = "a.b.c".
Sample is a set function which returns an arbitrary value from the multiset passed to it.
Definition: Sample
Sample(M, err) = Sample(Flatten(M))
Sample(M) = v, where v in M
For example, given Sample({"a", "b", "c"}), "a", "b", and "c" are all valid return values. Note that Sample() is not required to be deterministic for a given input, the only restriction is that the output value must be present in the input multiset.
Example:
SELECT (SUM(?val) AS ?sum) PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> WHERE { ?a rdf:value ?val . } GROUP BY ?a
The SUM expression becomes Aggregation((?val), Sum, (), BGP(?a rdf:value ?val)).
In general the aggregate expression
AGG(exprlist ; scalarvals) ... GROUP BY grouplist
becomes Aggregation(exprlist, Agg, scalarvals, BGP).
In order to project values from (sub-)queries using aggregate values, a Solution Multiset is constructed where each solution comprises the result of the Aggregate functions which share a key.
Given a list of aggregations, A = (A1, A2, ...) we produce a solution sequence using the AggregateJoin function:
AggregateJoin(A) = { { aggi → range(Ai) } | dom(Ai) = k, k in set-union(dom(A)) }
For example, if we have two aggregations:
A1 = { (1,3) → 5, (7,9) → 11 }
A2 = { (1,3) → 6, (7,9) → 12 }
AggregateJoin(A) = {
{ agg1 → 5, agg2 → 6 },
{ agg1 → 11, agg2 → 12 }
}
Data:
@prefix : <http://people.example/> . :alice :name "Alice", "Alice Foo", "A. Foo" . :alice :knows :bob, :carol . :bob :name "Bob", "Bob Bar", "B. Bar" . :carol :name "Carol", "Carol Baz", "C. Baz" .
Return a name (the one with the lowest sort order) from all the people that know Alice and have a name.
Query:
PREFIX : <http://people.example/> PREFIX : <http://people.example/> SELECT ?y ?minName WHERE { :alice :knows ?y . { SELECT ?y (MIN(?name) AS ?minName) WHERE { ?y :name ?name . } GROUP BY ?y } }
Results:
y | name |
---|---|
:bob | "B. Bar" |
:carol | "C. Baz" |
Subqueries require one additional algebra operator, toMultiset
, which takes Lists and returns Multisets.
Definition: ToMultiset
ToMultiset turns a sequence into a multiset with the same elements and cardinality as the sequence. The order and any duplicates in the sequence have no effect on the resulting multiset.
In general, GroupGraphPatternSub
is evaluated and then the
resulting multiset is projected with the Project
function, and
handled as per the Converting
Solution Modifiers section. The resulting sequence is converted back to a
multiset with ToMultiset
.
As a consequence the ordering from any ORDER BY expressions is not propagated outside the subquery.
@@ this section might be clearer if Converting Solution Modifiers was encapsulated as a function.
{ SELECT ?z WHERE { ?x ?y ?z . } }
Becomes ToMultiset(Project(BGP(?x ?y ?z), {?z}))
.
Only variables projected by the Project function are visible to operations outside the ToMultiset call.
The RDF data model expresses information as graphs consisting of triples with subject, predicate and object. Many RDF data stores hold multiple RDF graphs and record information about each graph, allowing an application to make queries that involve information from more than one graph.
A SPARQL query is executed against an RDF Dataset which represents a collection of graphs. An RDF Dataset comprises one graph, the default graph, which does not have a name, and zero or more named graphs, where each named graph is identified by an IRI. A SPARQL query can match different parts of the query pattern against different graphs as described in section 8.3 Querying the Dataset.
An RDF Dataset may contain zero named graphs; an RDF Dataset always contains one default graph. A query does not need to involve matching the default graph; the query can just involve matching named graphs.
The graph that is used for matching a basic graph pattern is the active
graph. In the previous sections, all queries have been shown executed
against a single graph, the default graph of an RDF dataset as the active graph.
The GRAPH
keyword is used to make the active graph one of all of
the named graphs in the dataset for part of the query.
The definition of RDF Dataset does not restrict the relationships of named and default graphs. Information can be repeated in different graphs; relationships between graphs can be exposed. Two useful arrangements are:
# Default graph @prefix dc: <http://purl.org/dc/elements/1.1/> . <http://example.org/bob> dc:publisher "Bob" . <http://example.org/alice> dc:publisher "Alice" .
# Named graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Bob" . _:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Named graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example.org> .
In this example, the default graph contains the names of the publishers of two named graphs. The triples in the named graphs are not visible in the default graph in this example.
Example 2:
RDF data can be combined by the RDF merge [RDF-MT] of graphs. One possible arrangement of graphs in an RDF Dataset is to have the default graph be the RDF merge of some or all of the information in the named graphs.
In this next example, the named graphs contain the same triples as before. The RDF dataset includes an RDF merge of the named graphs in the default graph, re-labeling blank nodes to keep them distinct.
# Default graph @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:x foaf:name "Bob" . _:x foaf:mbox <mailto:bob@oldcorp.example.org> . _:y foaf:name "Alice" . _:y foaf:mbox <mailto:alice@work.example.org> .
# Named graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Bob" . _:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Named graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> .
In an RDF merge, blank nodes in the merged graph are not shared with blank nodes from the graphs being merged.
A SPARQL query may specify the dataset to be used for matching by using the
FROM
clause and the FROM NAMED
clause to describe the
RDF dataset. If a query provides such a dataset description, then it is used in
place of any dataset that the query service would use if no dataset description
is provided in a query. The RDF dataset may also be
specified in a SPARQL protocol request, in which case the protocol description
overrides any description in the query itself. A query service may refuse a query
request if the dataset description is not acceptable to the service.
The FROM
and FROM NAMED
keywords allow a query to specify
an RDF dataset by reference; they indicate that the dataset should include graphs
that are obtained from representations of the resources identified by the given
IRIs (i.e. the absolute form of the given IRI references). The dataset resulting
from a number of FROM
and FROM NAMED
clauses is:
FROM
clauses, andFROM NAMED
clause.If there is no FROM
clause, but there is one or more FROM NAMED
clauses, then the dataset includes an empty graph for the default graph.
[9] | DatasetClause | ::= | 'FROM' ( DefaultGraphClause | NamedGraphClause ) |
[10] | DefaultGraphClause | ::= | SourceSelector |
[11] | NamedGraphClause | ::= | 'NAMED' SourceSelector |
[12] | SourceSelector | ::= | IRIref |
Each FROM
clause contains an IRI that indicates a graph to be
used to form the default graph. This does not put the graph in as a named graph.
In this example, the RDF Dataset contains a single default graph and no named graphs:
# Default graph (stored at http://example.org/foaf/aliceFoaf) @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> .
If a query provides more than one FROM
clause, providing more than
one IRI to indicate the default graph, then the default graph is based on the
RDF merge of the
graphs obtained from representations of the resources identified by the given IRIs.
A query can supply IRIs for the named graphs in the RDF Dataset using the
FROM NAMED
clause. Each IRI is used to provide one named graph in the
RDF Dataset. Using the same IRI in two or more FROM NAMED
clauses results
in one named graph with that IRI appearing in the dataset.
# Graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Bob" . _:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> .
... FROM NAMED <http://example.org/alice> FROM NAMED <http://example.org/bob> ...
The FROM NAMED
syntax suggests that the IRI identifies the corresponding
graph, but the relationship between an IRI and a graph in an RDF dataset
is indirect. The IRI identifies a resource, and the resource is represented by a
graph (or, more precisely: by a document that serializes a graph). For
further details
see [WEBARCH].
The FROM
clause and FROM NAMED
clause can be used in
the same query.
# Default graph (stored at http://example.org/dft.ttl) @prefix dc: <http://purl.org/dc/elements/1.1/> . <http://example.org/bob> dc:publisher "Bob Hacker" . <http://example.org/alice> dc:publisher "Alice Hacker" .
# Named graph: http://example.org/bob @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Bob" . _:a foaf:mbox <mailto:bob@oldcorp.example.org> .
# Named graph: http://example.org/alice @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example.org> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?who ?g ?mbox FROM <http://example.org/dft.ttl> FROM NAMED <http://example.org/alice> FROM NAMED <http://example.org/bob> WHERE { ?g dc:publisher ?who . GRAPH ?g { ?x foaf:mbox ?mbox } }
The RDF Dataset for this query contains a default graph and two named graphs.
The GRAPH
keyword is described below.
The actions required to construct the dataset are not determined by the
dataset description alone. If an IRI is given twice in a dataset
description, either by using two FROM
clauses, or a FROM
clause and a
FROM NAMED
clause, then it does not assume that exactly one or exactly
two attempts are made to obtain an RDF graph associated with the IRI.
Therefore, no assumptions can be made about blank node identity in
triples obtained from the two occurrences in the dataset description.
In general, no assumptions can be made about the equivalence of the graphs.
When querying a collection of graphs, the GRAPH
keyword is used
to match patterns against named graphs. GRAPH
can provide an IRI to select
one graph or use a variable which will range over the IRI of all the named graphs in the query's RDF dataset.
The use of GRAPH
changes the active graph for matching basic
graph patterns within part of the query. Outside the use of GRAPH
,
the default graph is matched by basic graph patterns.
The following two graphs will be used in examples:
# Named graph: http://example.org/foaf/aliceFoaf @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> . _:a foaf:knows _:b . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@work.example> . _:b foaf:nick "Bobby" . _:b rdfs:seeAlso <http://example.org/foaf/bobFoaf> . <http://example.org/foaf/bobFoaf> rdf:type foaf:PersonalProfileDocument .
# Named graph: http://example.org/foaf/bobFoaf @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . _:z foaf:mbox <mailto:bob@work.example> . _:z rdfs:seeAlso <http://example.org/foaf/bobFoaf> . _:z foaf:nick "Robert" . <http://example.org/foaf/bobFoaf> rdf:type foaf:PersonalProfileDocument .
[24] | GraphGraphPattern | ::= | 'GRAPH' VarOrIRIref GroupGraphPattern |
The query below matches the graph pattern against each of the named graphs in the
dataset and forms solutions which have the src
variable bound to
IRIs of the graph being matched. The graph pattern is matched with the active
graph being each of the named graphs in the dataset.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?src ?bobNick FROM NAMED <http://example.org/foaf/aliceFoaf> FROM NAMED <http://example.org/foaf/bobFoaf> WHERE { GRAPH ?src { ?x foaf:mbox <mailto:bob@work.example> . ?x foaf:nick ?bobNick } }
The query result gives the name of the graphs where the information was found and the value for Bob's nick:
The query can restrict the matching applied to a specific graph by supplying
the graph IRI. This sets the active graph to the graph named by the IRI. This query looks for Bob's nick as given in the graph http://example.org/foaf/bobFoaf
.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX data: <http://example.org/foaf/> SELECT ?nick FROM NAMED <http://example.org/foaf/aliceFoaf> FROM NAMED <http://example.org/foaf/bobFoaf> WHERE { GRAPH data:bobFoaf { ?x foaf:mbox <mailto:bob@work.example> . ?x foaf:nick ?nick } }
which yields a single solution:
A variable used in the GRAPH
clause may also be used in another
GRAPH
clause or in a graph pattern matched against the default graph
in the dataset.
The query below uses the graph
with IRI http://example.org/foaf/aliceFoaf
to find the profile document
for Bob; it then matches another pattern against that graph. The pattern in the
second GRAPH
clause finds the blank node (variable w
)
for the person with the same mail box (given by variable mbox
) as
found in the first GRAPH
clause (variable whom
), because
the blank node used to match for variable whom
from Alice's FOAF
file is not the same as the blank node in the profile document (they are in different
graphs).
PREFIX data: <http://example.org/foaf/> PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> SELECT ?mbox ?nick ?ppd FROM NAMED <http://example.org/foaf/aliceFoaf> FROM NAMED <http://example.org/foaf/bobFoaf> WHERE { GRAPH data:aliceFoaf { ?alice foaf:mbox <mailto:alice@work.example> ; foaf:knows ?whom . ?whom foaf:mbox ?mbox ; rdfs:seeAlso ?ppd . ?ppd a foaf:PersonalProfileDocument . } . GRAPH ?ppd { ?w foaf:mbox ?mbox ; foaf:nick ?nick } }
Any triple in Alice's FOAF file giving Bob's nick
is not used to
provide a nick for Bob because the pattern involving variable nick
is restricted by ppd
to a particular Personal Profile Document.
Query patterns can involve both the default graph and the named graphs. In this example, an aggregator has read in a Web resource on two different occasions. Each time a graph is read into the aggregator, it is given an IRI by the local system. The graphs are nearly the same but the email address for "Bob" has changed.
In this example, the default graph is being used to record the provenance information and the RDF data actually read is kept in two separate graphs, each of which is given a different IRI by the system. The RDF dataset consists of two named graphs and the information about them.
RDF Dataset:
# Default graph @prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix g: <tag:example.org,2005-06-06:> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . g:graph1 dc:publisher "Bob" . g:graph1 dc:date "2004-12-06"^^xsd:date . g:graph2 dc:publisher "Bob" . g:graph2 dc:date "2005-01-10"^^xsd:date .
# Graph: locally allocated IRI: tag:example.org,2005-06-06:graph1 @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@oldcorp.example.org> .
# Graph: locally allocated IRI: tag:example.org,2005-06-06:graph2 @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@newcorp.example.org> .
This query finds email addresses, detailing the name of the person and the date the information was discovered.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?name ?mbox ?date WHERE { ?g dc:publisher ?name ; dc:date ?date . GRAPH ?g { ?person foaf:name ?name ; foaf:mbox ?mbox } }
The results show that the email address for "Bob" has changed.
The IRI for the date datatype has been abbreviated in the results for clarity.
@@ Incorporate the text from SPARQL 1.1 Federation Extensions.
Query patterns generate an unordered collection of solutions, each solution being a partial function from variables to RDF terms. These solutions are then treated as a sequence (a solution sequence), initially in no specific order; any sequence modifiers are then applied to create another sequence. Finally, this latter sequence is used to generate one of the results of a SPARQL query form.
A solution sequence modifier is one of:
Modifiers are applied in the order given by the list above.
[5] | SelectQuery | ::= | 'SELECT' (
'DISTINCT' | 'REDUCED' )? ( Var+ | '*'
) DatasetClause*
WhereClause SolutionModifier |
[14] | SolutionModifier | ::= | OrderClause?
LimitOffsetClauses? |
[15] | LimitOffsetClauses | ::= | ( LimitClause
OffsetClause? | OffsetClause
LimitClause? ) |
[16] | OrderClause | ::= | 'ORDER'
'BY' OrderCondition+ |
The ORDER BY
clause establishes the order of a solution sequence.
Following the ORDER BY
clause is a sequence of order comparators, composed of an expression and an optional order modifier (either ASC()
or DESC()
). Each ordering comparator is either ascending (indicated by the ASC()
modifier or by no modifier) or descending (indicated by the DESC()
modifier).
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name } ORDER BY ?name
PREFIX : <http://example.org/ns#> PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name ; :empId ?emp } ORDER BY DESC(?emp)
PREFIX : <http://example.org/ns#> PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name ; :empId ?emp } ORDER BY ?name DESC(?emp)
The "<" operator (see the Operator Mapping and 11.3.1 Operator Extensibility) defines
the relative order of pairs of numerics
, simple literals
, xsd:strings
, xsd:booleans
and xsd:dateTimes
. Pairs of IRIs are ordered by comparing them as simple literals
.
SPARQL also fixes an order between some kinds of RDF terms that would not otherwise be ordered:
A plain literal is lower than an RDF literal with type xsd:string
of the same lexical form.
SPARQL does not define a total ordering of all possible RDF terms. Here are a few examples of pairs of terms for which the relative order is undefined:
This list of variable bindings is in ascending order:
RDF Term | Reason |
---|---|
Unbound results sort earliest. | |
_:z | Blank nodes follow unbound. |
_:a | There is no relative ordering of blank nodes. |
<http://script.example/Latin> | IRIs follow blank nodes. |
<http://script.example/Кириллица> | The character in the 23rd position, "К", has a unicode codepoint 0x41A, which is higher than 0x4C ("L"). |
<http://script.example/漢字> | The character in the 23rd position, "漢", has a unicode codepoint 0x6F22, which is higher than 0x41A ("К"). |
"http://script.example/Latin" | Simple literals follow IRIs. |
"http://script.example/Latin"^^xsd:string | xsd:strings follow simple literals. |
The ascending order of two solutions with respect to an ordering comparator is established by substituting the solution bindings into the expressions and comparing them with the "<" operator. The descending order is the reverse of the ascending order.
The relative order of two solutions is the relative order of the two solutions with respect to the first ordering comparator in the sequence. For solutions where the substitutions of the solution bindings produce the same RDF term, the order is the relative order of the two solutions with respect to the next ordering comparator. The relative order of two solutions is undefined if no order expression evaluated for the two solutions produces distinct RDF terms.
Ordering a sequence of solutions always results in a sequence with the same number of solutions in it.
Using ORDER BY
on a solution sequence for a CONSTRUCT
or
DESCRIBE
query has no direct effect because only SELECT
returns
a sequence of results. Used in combination with LIMIT
and OFFSET
,
ORDER BY
can be used to return results generated from a different slice of the solution sequence.
An ASK
query does not include ORDER BY
, LIMIT
or OFFSET
.
[16] | OrderClause | ::= | 'ORDER' 'BY' OrderCondition+ |
[17] | OrderCondition | ::= | ( ( 'ASC' | 'DESC' ) BrackettedExpression ) |
[18] | LimitClause | ::= | 'LIMIT' INTEGER |
[19] | OffsetClause | ::= | 'OFFSET' INTEGER |
The solution sequence can be transformed into one involving only a subset of the variables. For each solution in the sequence, a new solution is formed using a specified selection of the variables using the SELECT query form.
The following example shows a query to extract just the names of people described in an RDF graph using FOAF properties.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@work.example> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name }
name |
---|
"Bob" |
"Alice" |
A solution sequence with no DISTINCT
or REDUCED
query modifier
will preserve duplicate solutions.
Data:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:x foaf:name "Alice" . _:x foaf:mbox <mailto:alice@example.com> . _:y foaf:name "Alice" . _:y foaf:mbox <mailto:asmith@example.com> . _:z foaf:name "Alice" . _:z foaf:mbox <mailto:alice.smith@example.com> .
Query:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name }
Results:
name |
---|
"Alice" |
"Alice" |
"Alice" |
The modifiers DISTINCT
and REDUCED
affect whether duplicates are included in the query results.
The DISTINCT
solution modifier eliminates duplicate solutions. Specifically, each solution that binds the same variables to the same RDF terms as another solution is eliminated from the solution sequence.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT DISTINCT ?name WHERE { ?x foaf:name ?name }
name |
---|
"Alice" |
Note that, per the order of solution sequence modifiers, duplicates are eliminated before either limit or offset is applied.
While the DISTINCT
modifier ensures that duplicate solutions are eliminated from the solution set, REDUCED
simply permits them to be eliminated. The cardinality of any set of variable bindings in a REDUCED
solution set is at least one and not more than the cardinality of the solution set with no DISTINCT
or REDUCED
modifier. For example, using the data above, the query
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT REDUCED ?name WHERE { ?x foaf:name ?name }
may have one, two (shown here) or three solutions:
name |
---|
"Alice" |
"Alice" |
OFFSET
causes the solutions generated to start after the specified
number of solutions. An OFFSET
of zero has no effect.
Using
LIMIT
and OFFSET
to select different subsets of the query solutions
will not be useful unless the order is made predictable by using ORDER BY
.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name } ORDER BY ?name LIMIT 5 OFFSET 10
The LIMIT
clause puts an upper bound on the number of solutions returned. If the
number of actual solutions is greater than the limit, then at most the limit number
of solutions will be returned.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name } LIMIT 20
A LIMIT
of 0 would cause no results to be returned. A limit may not be negative.
SPARQL has four query forms. These query 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.
- CONSTRUCT
- Returns an RDF graph constructed by substituting variables in a set of triple templates.
- ASK
- Returns a boolean indicating whether a query pattern matches or not.
- DESCRIBE
- Returns an RDF graph that describes the resources found.
The SPARQL Variable
Binding Results XML Format can be used to serialize the result set from a
SELECT
query or the boolean result of an ASK
query.
The SELECT form of results returns variables and their bindings directly. It combines the operations of projecting the required variables with introducing new variable bindings into a query solution.
@@Grammar refers to SPARQL 1.0 only
[5] | SelectQuery | ::= | 'SELECT' ( 'DISTINCT' | 'REDUCED' )? ( Var+ | '*' ) |
Specific variables and their bindings are
returned when a list of variable names is given in the SELECT clause. The syntax
SELECT *
is an abbreviation that
selects all of the variables that could be bound in a query.
@@ excludes variables only in FILTERs and (NOT) EXISTS clauses
@@Use in BGPs, GRAPH and nested AS ; sub-SELECT projection
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:knows _:b . _:a foaf:knows _:c . _:b foaf:name "Bob" . _:c foaf:name "Clare" . _:c foaf:nick "CT" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?nameX ?nameY ?nickY WHERE { ?x foaf:knows ?y ; foaf:name ?nameX . ?y foaf:name ?nameY . OPTIONAL { ?y foaf:nick ?nickY } }
Result sets can be accessed by a local API but also can be serialized into either XML or an RDF graph. An XML format is described in SPARQL Query Results XML Format, and gives for this example:
<?xml version="1.0"?> <sparql xmlns="http://www.w3.org/2005/sparql-results#"> <head> <variable name="nameX"/> <variable name="nameY"/> <variable name="nickY"/> </head> <results> <result> <binding name="nameX"> <literal>Alice</literal> </binding> <binding name="nameY"> <literal>Bob</literal> </binding> </result> <result> <binding name="nameX"> <literal>Alice</literal> </binding> <binding name="nameY"> <literal>Clare</literal> </binding> <binding name="nickY"> <literal>CT</literal> </binding> </result> </results> </sparql>
As well as choosing which variables from the pattern matching are included in
the results, the SELECT clause can also introduce new variables, together with an
expression that gives the value of the binding for that variable. The expression
combines variable bindings already in the query solution, or defined earlier in the SELECT clause, to produce a new value.
The new variable is introduced using the keyword AS
; it must not already be potentially
bound.
Example:
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 . :book1 ns:discount 0.1 . :book2 dc:title "The Semantic Web" . :book2 ns:price 23 . :book2 ns:discount 0 .
Query:
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX ns: <http://example.org/ns#> SELECT ?title (?p*(1-?discount) AS ?price) { ?x ns:price ?p . ?x dc:title ?title . ?x ns:discount ?discount }
Results:
title | price |
---|---|
"The Semantic Web" | 23 |
"SPARQL Tutorial" | 37.8 |
New variables can be also be used in expressions if they are introduced earlier, syntactically, in the same SELECT clause:
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX ns: <http://example.org/ns#> SELECT ?title (?p AS ?fullPrice) (?fullPrice*(1-?discount) AS ?customerPrice) { ?x ns:price ?p . ?x dc:title ?title . ?x ns:discount ?discount }
Results:
title | fullPrice | customerPrice |
---|---|---|
"The Semantic Web" | 23 | 23 |
"SPARQL Tutorial" | 42 | 37.8 |
The CONSTRUCT
query form returns a single RDF graph specified by
a graph template. The result is an RDF graph formed by taking each query solution
in the solution sequence, substituting for the variables in the graph template,
and combining the triples into a single RDF graph by set union.
If any such instantiation produces a triple containing an unbound variable or an illegal RDF construct, such as a literal in subject or predicate position, then that triple is not included in the output RDF graph. The graph template can contain triples with no variables (known as ground or explicit triples), and these also appear in the output RDF graph returned by the CONSTRUCT query form.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:mbox <mailto:alice@example.org> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> CONSTRUCT { <http://example.org/person#Alice> vcard:FN ?name } WHERE { ?x foaf:name ?name }
creates vcard properties from the FOAF information:
@prefix vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> . <http://example.org/person#Alice> vcard:FN "Alice" .
A template can create an RDF graph containing blank nodes. The blank node labels are scoped to the template for each solution. If the same label occurs twice in a template, then there will be one blank node created for each query solution, but there will be different blank nodes for 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 } . }
creates vcard properties corresponding to the FOAF information:
@prefix vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> . _:v1 vcard:N _:x . _:x vcard:givenName "Alice" . _:x vcard:familyName "Hacker" . _:v2 vcard:N _:z . _:z vcard:givenName "Bob" . _:z vcard:familyName "Hacker" .
The use of variable x
in the template, which in this example will be bound to
blank nodes with labels _:a
and _:b
in the data,
causes different blank node labels (_:v1
and _:v2
) in the resulting RDF graph.
Using CONSTRUCT
, it is possible to extract parts or the whole of
graphs from the target RDF dataset. This first example returns the graph (if it
is in the dataset) with IRI label http://example.org/aGraph
; otherwise,
it returns an empty graph.
CONSTRUCT { ?s ?p ?o } WHERE { GRAPH <http://example.org/aGraph> { ?s ?p ?o } . }
The access to the graph can be conditional on other information. For example, if the default graph contains metadata about the named graphs in the dataset, then a query like the following one can extract one graph based on information about the named graph:
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX app: <http://example.org/ns#> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> CONSTRUCT { ?s ?p ?o } WHERE { GRAPH ?g { ?s ?p ?o } . { ?g dc:publisher <http://www.w3.org/> } . { ?g dc:date ?date } . FILTER ( app:customDate(?date) > "2005-02-28T00:00:00Z"^^xsd:dateTime ) . }
where app:customDate
identified an
extension function to turn the data format into an xsd:dateTime
RDF term.
[6] | ConstructQuery | ::= | 'CONSTRUCT' ConstructTemplate |
The solution modifiers of a query affect the results of a CONSTRUCT
query. In this example, the output graph from the CONSTRUCT
template
is formed from just two of the solutions from graph pattern matching. The query outputs
a graph with the names of the people with the top two sites, rated by hits. The triples
in the RDF graph are not ordered.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix site: <http://example.org/stats#> . _:a foaf:name "Alice" . _:a site:hits 2349 . _:b foaf:name "Bob" . _:b site:hits 105 . _:c foaf:name "Eve" . _:c site:hits 181 .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX site: <http://example.org/stats#> CONSTRUCT { [] foaf:name ?name } WHERE { [] foaf:name ?name ; site:hits ?hits . } ORDER BY desc(?hits) LIMIT 2
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:x foaf:name "Alice" . _:y foaf:name "Eve" .
Applications can use the ASK
form to test whether or not a query
pattern has a solution. No information is returned about the possible query solutions,
just whether or not a solution exists.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice" . _:a foaf:homepage <http://work.example.org/alice/> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@work.example> .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> ASK { ?x foaf:name "Alice" }
yes
The SPARQL Query Results XML Format form of this result set gives:
<?xml version="1.0"?> <sparql xmlns="http://www.w3.org/2005/sparql-results#"> <head></head> <boolean>true</boolean> </sparql>
On the same data, the following returns no match because Alice's mbox
is not mentioned.
PREFIX foaf: <http://xmlns.com/foaf/0.1/> ASK { ?x foaf:name "Alice" ; foaf:mbox <mailto:alice@work.example> }
no
[8] | AskQuery | ::= | 'ASK' DatasetClause* WhereClause |
The DESCRIBE
form returns a single result RDF graph containing RDF
data about resources. This data is not prescribed by a SPARQL query, where the query
client would need to know the structure of the RDF in the data source, but, instead,
is determined by the SPARQL query processor. The query pattern is used to create
a result set. The DESCRIBE
form takes each of the resources identified
in a solution, together with any resources directly named by IRI, and assembles
a single RDF graph by taking a "description" which can come from any
information available including the target RDF Dataset. The
description is determined by the query service. The syntax DESCRIBE *
is an abbreviation that describes all of the variables in a query.
The DESCRIBE
clause itself can take IRIs to identify the resources.
The simplest DESCRIBE
query is just an IRI in the DESCRIBE
clause:
DESCRIBE <http://example.org/>
The resources to be described can also be taken from the bindings to a query variable in a result set. This enables description of resources whether they are identified by IRI or by blank node in the dataset:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> 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. 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 IRI or variable can be given:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> DESCRIBE ?x ?y <http://example.org/> WHERE {?x foaf:knows ?y}
The RDF returned is determined by the information publisher. It is the useful information the service has about a resource. It may include information about other resources: for example, the RDF data for a book may also include details about the author.
A simple query such as
PREFIX ent: <http://org.example.com/employees#> DESCRIBE ?x WHERE { ?x ent:employeeId "1234" }
might return a description of the employee and some other potentially useful details:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix vcard: <http://www.w3.org/2001/vcard-rdf/3.0> . @prefix exOrg: <http://org.example.com/employees#> . @prefixrdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix owl: <http://www.w3.org/2002/07/owl#>
_:a exOrg:employeeId "1234" ;foaf:mbox_sha1sum "ABCD1234" ;
vcard:N [ vcard:Family "Smith" ; vcard:Given "John" ] .foaf:mbox_sha1sum rdf:type owl:InverseFunctionalProperty .
which includes the blank node closure for the vcard vocabulary vcard:N. Other possible mechanisms for deciding what information to return include Concise Bounded Descriptions [CBD].
For a vocabulary such as FOAF, where the resources are typically blank nodes,
returning sufficient information to identify a node such as the InverseFunctionalProperty
foaf:mbox_sha1sum
as well as information like name and other details recorded
would be appropriate. In the example, the match to the WHERE clause was returned,
but this is not required.
[7] | DescribeQuery | ::= | 'DESCRIBE' ( VarOrIRIref+ | '*' ) |
@@ To add to function/operator table: IRI, BNODE, STRDT, STRLANG, IF, COALESCE, IN, NOT IN, EXISTS, NOT EXISTS
SPARQL FILTERs
restrict the solutions of a graph pattern match according to a given expression. Specifically,
FILTERs
eliminate any solutions that, when substituted into the expression, either result in an effective boolean value of false
or produce an error. Effective boolean values are defined in section 11.2.2 Effective Boolean Value and errors are defined in XQuery 1.0: An XML Query Language [XQUERY] section 2.3.1, Kinds of Errors. These errors have no affect outside of FILTER
evaluation.
RDF literals may have a datatype IRI:
@prefix a: <http://www.w3.org/2000/10/annotation-ns#> . @prefix dc: <http://purl.org/dc/elements/1.1/> . _:a a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . _:a dc:date "2004-12-31T19:00:00-05:00" . _:b a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . _:b dc:date "2004-12-31T19:01:00-05:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
The object of the first dc:date
triple has no type information. The second has the datatype xsd:dateTime
.
SPARQL expressions are constructed according to the grammar and provide access to functions (named by IRI) and operator functions (invoked by keywords and symbols in the SPARQL grammar). SPARQL operators can be used to compare the values of typed literals:
PREFIX a: <http://www.w3.org/2000/10/annotation-ns#> PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> SELECT ?annot WHERE { ?annot a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . ?annot dc:date ?date . FILTER ( ?date > "2005-01-01T00:00:00Z"^^xsd:dateTime ) }
The SPARQL operators are listed in section 11.3 and are associated with their productions in the grammar.
In addition, SPARQL provides the ability to invoke arbitrary functions, including a subset of the XPath casting functions, listed in section 11.5. These functions are invoked by name (an IRI) within a SPARQL query. For example:
... FILTER ( xsd:dateTime(?date) < xsd:dateTime("2005-01-01T00:00:00Z") ) ...
The following typographical conventions are used in this section:
op:
. XPath operators have no namespace; op:
is a labeling convention.SPARQL functions and operators operate on RDF terms and SPARQL variables. A subset of these functions and operators are taken from the XQuery 1.0 and XPath 2.0 Functions and Operators [FUNCOP] and have XML Schema typed value arguments and return types.
RDF typed literals
passed as arguments to these functions and operators are mapped to XML Schema typed values with a string value of the lexical form
and an atomic datatype corresponding to the datatype IRI. The returned typed values are mapped back to RDF typed literals
the same way.
SPARQL has additional operators which operate on specific subsets of RDF terms. When referring to a type, the following terms denote a typed literal
with the corresponding XML Schema [XSDT] datatype IRI:
The following terms identify additional types used in SPARQL value tests:
typed literals
with datatypes xsd:integer
, xsd:decimal
, xsd:float
, and xsd:double
.plain literal
with no language tag
.IRI
, literal
, and blank node
.The following types are derived from numeric types and are valid arguments to functions and operators taking numeric arguments:
xsd:nonPositiveInteger
xsd:negativeInteger
xsd:long
xsd:int
xsd:short
xsd:byte
xsd:nonNegativeInteger
xsd:unsignedLong
xsd:unsignedInt
xsd:unsignedShort
xsd:unsignedByte
xsd:positiveInteger
SPARQL language extensions may treat additional types as being derived from XML schema data types.
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:
xsd:boolean
using the EBV rules in section 11.2.2 .||
) or logical-and (&&
) that encounters an error will produce that error.The logical-and and logical-or truth table for true (T), false (F), and error (E) is as follows:
A | B | A || B | A && B |
---|---|---|---|
T | T | T | T |
T | F | T | F |
F | T | T | F |
F | F | F | F |
T | E | T | E |
E | T | T | E |
F | E | E | F |
E | F | E | F |
E | E | E | E |
SPARQL defines a syntax for invoking functions and operators on a list of arguments. These are invoked as follows:
If any of these steps fails, the invocation generates an error. The effects of errors are defined in Filter Evaluation.
Effective boolean value is used to calculate the arguments to the logical functions logical-and, logical-or, and fn:not, as well as evaluate the result of a FILTER
expression.
The XQuery Effective Boolean Value rules rely on the definition of XPath's fn:boolean. The following rules reflect the rules for fn:boolean
applied to the argument types present in SPARQL Queries:
xsd:boolean
or numeric is false if the lexical form is not valid for that datatype (e.g. "abc"^^xsd:integer).xsd:boolean
, the EBV is the value of that argument.xsd:string
, the EBV is false if the operand value has zero length; otherwise the EBV is true.An EBV of true
is represented as a typed literal with a datatype of xsd:boolean
and a lexical value of "true"; an EBV of false is represented as a typed literal with a datatype of xsd:boolean
and a lexical value of "false".
@@Add IRI() etc to dispatch table
The SPARQL grammar identifies a set of operators (for instance, &&, *, isIRI) used to construct constraints. The following table associates each of these grammatical productions with the appropriate operands and an operator function defined by either XQuery 1.0 and XPath 2.0 Functions and Operators [FUNCOP] or the SPARQL operators specified in section 11.4. When selecting the operator definition for a given set of parameters, the definition with the most specific parameters applies. For instance, when evaluating xsd:integer = xsd:signedInt
, the definition for =
with two numeric
parameters applies, rather than the one with two RDF terms. The table is arranged so that the upper-most viable candidate is the most specific. Operators invoked without appropriate operands result in a type error.
SPARQL follows XPath's scheme for numeric type promotions and subtype substitution for arguments to numeric operators. The XPath Operator Mapping rules for numeric operands (xsd:integer
, xsd:decimal
, xsd:float
, xsd:double
, and types derived from a numeric type) apply to SPARQL operators as well (see XML Path Language (XPath) 2.0 [XPATH20] for definitions of numeric type promotions and subtype substitution). Some of the operators are associated with nested function expressions, e.g. fn:not(op:numeric-equal(A, B))
. Note that per the XPath definitions, fn:not
and op:numeric-equal
produce an error if their argument is an error.
The collation for fn:compare
is defined by XPath and identified by http://www.w3.org/2005/xpath-functions/collation/codepoint
. This collation allows for string comparison based on code point values. Codepoint string equivalence can be tested with RDF term equivalence.
This table is not up to date. IN, NOT IN, BNODE, IF, COLAESCE, IRI, URI, STRDT, STRLANG, NOT EXISTS, EXISTS
Operator | Type(A) | Function | Result type | |
---|---|---|---|---|
XQuery Unary Operators | ||||
! A | xsd:boolean (EBV) | fn:not(A) | xsd:boolean | |
+ A | numeric | op:numeric-unary-plus(A) | numeric | |
- A | numeric | op:numeric-unary-minus(A) | numeric | |
SPARQL Tests, defined in section 11.4 | ||||
BOUND(A) | variable | bound(A) | xsd:boolean | |
isIRI(A) isURI(A) | RDF term | isIRI(A) | xsd:boolean | |
isBLANK(A) | RDF term | isBlank(A) | xsd:boolean | |
isLITERAL(A) | RDF term | isLiteral(A) | xsd:boolean | |
isNUMERIC(A) | RDF term | isNumeric(A) | xsd:boolean | |
SPARQL Accessors, defined in section 11.4 | ||||
STR(A) | literal | str(A) | simple literal | |
STR(A) | IRI | str(A) | simple literal | |
LANG(A) | literal | lang(A) | simple literal | |
DATATYPE(A) | typed literal | datatype(A) | IRI | |
DATATYPE(A) | simple literal | datatype(A) | IRI |
Operator | Type(A) | Type(B) | Function | Result type |
---|---|---|---|---|
Logical Connectives, defined in section 11.4 | ||||
A || B | xsd:boolean (EBV) | xsd:boolean (EBV) | logical-or(A, B) | xsd:boolean |
A && B | xsd:boolean (EBV) | xsd:boolean (EBV) | logical-and(A, B) | xsd:boolean |
XPath Tests | ||||
A = B | numeric | numeric | op:numeric-equal(A, B) | xsd:boolean |
A = B | simple literal | simple literal | op:numeric-equal(fn:compare(A, B), 0) | xsd:boolean |
A = B | xsd:string | xsd:string | op:numeric-equal(fn:compare(STR(A), STR(B)), 0) | xsd:boolean |
A = B | xsd:boolean | xsd:boolean | op:boolean-equal(A, B) | xsd:boolean |
A = B | xsd:dateTime | xsd:dateTime | op:dateTime-equal(A, B) | xsd:boolean |
A != B | numeric | numeric | fn:not(op:numeric-equal(A, B)) | xsd:boolean |
A != B | simple literal | simple literal | fn:not(op:numeric-equal(fn:compare(A, B), 0)) | xsd:boolean |
A != B | xsd:string | xsd:string | fn:not(op:numeric-equal(fn:compare(STR(A), STR(B)), 0)) | xsd:boolean |
A != B | xsd:boolean | xsd:boolean | fn:not(op:boolean-equal(A, B)) | xsd:boolean |
A != B | xsd:dateTime | xsd:dateTime | fn:not(op:dateTime-equal(A, B)) | xsd:boolean |
A < B | numeric | numeric | op:numeric-less-than(A, B) | xsd:boolean |
A < B | simple literal | simple literal | op:numeric-equal(fn:compare(A, B), -1) | xsd:boolean |
A < B | xsd:string | xsd:string | op:numeric-equal(fn:compare(STR(A), STR(B)), -1) | xsd:boolean |
A < B | xsd:boolean | xsd:boolean | op:boolean-less-than(A, B) | xsd:boolean |
A < B | xsd:dateTime | xsd:dateTime | op:dateTime-less-than(A, B) | xsd:boolean |
A > B | numeric | numeric | op:numeric-greater-than(A, B) | xsd:boolean |
A > B | simple literal | simple literal | op:numeric-equal(fn:compare(A, B), 1) | xsd:boolean |
A > B | xsd:string | xsd:string | op:numeric-equal(fn:compare(STR(A), STR(B)), 1) | xsd:boolean |
A > B | xsd:boolean | xsd:boolean | op:boolean-greater-than(A, B) | xsd:boolean |
A > B | xsd:dateTime | xsd:dateTime | op:dateTime-greater-than(A, B) | xsd:boolean |
A <= B | numeric | numeric | logical-or(op:numeric-less-than(A, B), op:numeric-equal(A, B)) | xsd:boolean |
A <= B | simple literal | simple literal | fn:not(op:numeric-equal(fn:compare(A, B), 1)) | xsd:boolean |
A <= B | xsd:string | xsd:string | fn:not(op:numeric-equal(fn:compare(STR(A), STR(B)), 1)) | xsd:boolean |
A <= B | xsd:boolean | xsd:boolean | fn:not(op:boolean-greater-than(A, B)) | xsd:boolean |
A <= B | xsd:dateTime | xsd:dateTime | fn:not(op:dateTime-greater-than(A, B)) | xsd:boolean |
A >= B | numeric | numeric | logical-or(op:numeric-greater-than(A, B), op:numeric-equal(A, B)) | xsd:boolean |
A >= B | simple literal | simple literal | fn:not(op:numeric-equal(fn:compare(A, B), -1)) | xsd:boolean |
A >= B | xsd:string | xsd:string | fn:not(op:numeric-equal(fn:compare(STR(A), STR(B)), -1)) | xsd:boolean |
A >= B | xsd:boolean | xsd:boolean | fn:not(op:boolean-less-than(A, B)) | xsd:boolean |
A >= B | xsd:dateTime | xsd:dateTime | fn:not(op:dateTime-less-than(A, B)) | xsd:boolean |
XPath Arithmetic | ||||
A * B | numeric | numeric | op:numeric-multiply(A, B) | numeric |
A / B | numeric | numeric | op:numeric-divide(A, B) | numeric; but xsd:decimal if both operands are xsd: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.4 | ||||
A = B | RDF term | RDF term | RDFterm-equal(A, B) | xsd:boolean |
A != B | RDF term | RDF term | fn:not(RDFterm-equal(A, B)) | xsd:boolean |
sameTERM(A, B) | RDF term | RDF term | sameTerm(A, B) | xsd:boolean |
langMATCHES(A, B) | simple literal | simple literal | langMatches(A, B) | xsd:boolean |
REGEX(STRING, PATTERN) | simple literal | simple literal | fn:matches(STRING, PATTERN) | xsd:boolean |
Operator | Type(A) | Type(B) | Type(C) | Function | Result type |
---|---|---|---|---|---|
SPARQL Tests, defined in section 11.4 | |||||
REGEX(STRING, PATTERN, FLAGS) | simple literal | simple literal | simple literal | fn:matches(STRING, PATTERN, FLAGS) | xsd:boolean |
xsd:boolean function arguments marked with "(EBV)" are coerced to xsd:boolean by evaluating the effective boolean value of that argument.
SPARQL language extensions may provide additional associations between operators and operator functions; this amounts to adding rows to the table above. No additional operator may yield a result that replaces any result other than a type error in the semantics defined above. The consequence of this rule is that SPARQL extensions will produce at least the same solutions as an unextended implementation, and may, for some queries, produce more solutions.
Additional mappings of the '<' operator are expected to control the relative ordering of the operands, specifically, when used in an ORDER BY
clause.
This section defines the operators introduced by the SPARQL Query language. The examples show the behavior of the operators as invoked by the appropriate grammatical constructs.
@@ URI: http://www.w3.org/ns/sparql#bound XXXX
xsd:boolean
bound
(variable
var
)
Returns true
if var
is bound to a value. Returns false otherwise. Variables with the value NaN or INF are considered bound.
Data:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . _:a foaf:givenName "Alice". _:b foaf:givenName "Bob" . _:b dc:date "2005-04-04T04:04:04Z"^^xsd:dateTime .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> SELECT ?givenName WHERE { ?x foaf:givenName ?givenName . OPTIONAL { ?x dc:date ?date } . FILTER ( bound(?date) ) }
Query result:
givenName |
---|
"Bob" |
One may test that a graph pattern is not expressed by specifying an OPTIONAL
graph pattern that introduces a variable and testing to see that the variable is not
bound
. This is called Negation as Failure in logic programming.
This query matches the people with a name
but no expressed date
:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?name WHERE { ?x foaf:givenName ?name . OPTIONAL { ?x dc:date ?date } . FILTER (!bound(?date)) }
Query result:
name |
---|
"Alice" |
Because Bob's dc:date
was known, "Bob"
was not a solution to the query.
xsd:boolean
isIRI
(RDF term
term
)xsd:boolean
isURI
(RDF term
term
)
Returns true
if term
is an IRI. Returns false
otherwise. isURI
is an alternate spelling for the isIRI
operator.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice". _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Bob" . _:b foaf:mbox "bob@work.example" .
This query matches the people with a name
and an mbox
which is an IRI:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name ; foaf:mbox ?mbox . FILTER isIRI(?mbox) }
Query result:
name | mbox |
---|---|
"Alice" | <mailto:alice@work.example> |
xsd:boolean
isBlank
(RDF term
term
)
Returns true
if term
is a blank node. Returns false
otherwise.
@prefix a: <http://www.w3.org/2000/10/annotation-ns#> . @prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . _:a dc:creator "Alice B. Toeclips" . _:b a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . _:b dc:creator _:c . _:c foaf:given "Bob". _:c foaf:family "Smith".
This query matches the people with a dc:creator
which uses
predicates from the FOAF vocabulary to express the name.
PREFIX a: <http://www.w3.org/2000/10/annotation-ns#> PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?given ?family WHERE { ?annot a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . ?annot dc:creator ?c . OPTIONAL { ?c foaf:given ?given ; foaf:family ?family } . FILTER isBlank(?c) }
Query result:
given | family |
---|---|
"Bob" | "Smith" |
In this example, there were two objects of foaf:knows
predicates, but only one (_:c
) was a blank node.
xsd:boolean
isLiteral
(RDF term
term
)
Returns true
if term
is a literal. Returns false
otherwise.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice". _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Bob" . _:b foaf:mbox "bob@work.example" .
This query is similar to the one in 11.4.2 except that is matches the people with a name
and an mbox
which is a literal. This could be used to look for erroneous data (foaf:mbox
should only have an
IRI as its object).
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name ; foaf:mbox ?mbox . FILTER isLiteral(?mbox) }
Query result:
name | mbox |
---|---|
"Bob" | "bob@work.example" |
xsd:boolean
isNumeric
(RDF term
term
)
Returns true
if term
is a numeric value. Returns false
otherwise.
term
is numeric if it has an appropriate datatype (see the section Operand Data Types) and has a valid lexical form, making it
a valid argument to functions and operators
taking numeric arguments.
Examples:
isNumeric(12) | true |
isNumeric("12") | false |
isNumeric("12"^^xsd:nonNegativeInteger) | true |
isNumeric("1200"^^xsd:byte) | false |
isNumeric(<http://example/>) | false |
simple literal
str
(literal
ltrl
)simple literal
str
(IRI
rsrc
)
Returns the lexical form
of ltrl
(a literal); returns the codepoint representation of rsrc
(an IRI). This is useful for examining parts of an IRI, for instance, the host-name.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice". _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Bob" . _:b foaf:mbox <mailto:bob@home.example> .
This query selects the set of people who use their work.example
address in their foaf profile:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name ; foaf:mbox ?mbox . FILTER regex(str(?mbox), "@work.example") }
Query result:
name | mbox |
---|---|
"Alice" | <mailto:alice@work.example> |
simple literal
lang
(literal
ltrl
)
Returns the language tag
of ltrl
, if it has one. It returns ""
if ltrl
has no language tag
. Note that the RDF data model does not include literals with an empty language tag
.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Robert"@EN. _:a foaf:name "Roberto"@ES. _:a foaf:mbox <mailto:bob@work.example> .
This query finds the Spanish foaf:name
and foaf:mbox
:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name ?mbox WHERE { ?x foaf:name ?name ; foaf:mbox ?mbox . FILTER ( lang(?name) = "ES" ) }
Query result:
name | mbox |
---|---|
"Roberto"@ES | <mailto:bob@work.example> |
IRI
datatype
(typed literal
typedLit
)IRI
datatype
(simple literal
simpleLit
)
Returns the datatype IRI
of typedLit
; returns xsd:string
if the parameter is a simple literal.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix eg: <http://biometrics.example/ns#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . _:a foaf:name "Alice". _:a eg:shoeSize "9.5"^^xsd:float . _:b foaf:name "Bob". _:b eg:shoeSize "42"^^xsd:integer .
This query finds the foaf:name
and foaf:shoeSize
of everyone with a shoeSize that is an integer:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> PREFIX eg: <http://biometrics.example/ns#> SELECT ?name ?shoeSize WHERE { ?x foaf:name ?name ; eg:shoeSize ?shoeSize . FILTER ( datatype(?shoeSize) = xsd:integer ) }
Query result:
name | shoeSize |
---|---|
"Bob" | 42 |
xsd:boolean
xsd:boolean
left
||
xsd:boolean
right
Returns a logical OR
of left
and right
. Note that logical-or
operates on the effective boolean value of its arguments.
Note: see section 11.2, Filter Evaluation, for
the ||
operator's treatment of errors.
xsd:boolean
xsd:boolean
left
&&
xsd:boolean
right
Returns a logical AND
of left
and right
. Note that logical-and
operates on the effective boolean value of its arguments.
Note: see section 11.2, Filter Evaluation, for
the &&
operator's treatment of errors.
xsd:boolean
RDF term
term1
=
RDF term
term2
Returns TRUE if term1
and term2
are the same RDF term as defined in Resource Description Framework (RDF): Concepts and Abstract Syntax [CONCEPTS]; produces a type error if the arguments are both literal but are not the same RDF term *; returns FALSE otherwise. term1
and term2
are the same if any of the following is true:
term1
and term2
are equivalent IRIs as defined in 6.4 RDF URI References
of [CONCEPTS].term1
and term2
are equivalent literals as defined in 6.5.1 Literal Equality
of [CONCEPTS].term1
and term2
are the same blank node as described in 6.6 Blank Nodes
of [CONCEPTS].@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice". _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Ms A.". _:b foaf:mbox <mailto:alice@work.example> .
This query finds the people who have multiple foaf:name
triples:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name1 ?name2 WHERE { ?x foaf:name ?name1 ; foaf:mbox ?mbox1 . ?y foaf:name ?name2 ; foaf:mbox ?mbox2 . FILTER (?mbox1 = ?mbox2 && ?name1 != ?name2) }
Query result:
name1 | name2 |
---|---|
"Alice" | "Ms A." |
"Ms A." | "Alice" |
In this query for documents that were annotated on New Year's Day (2004 or 2005), the RDF terms are not the same, but have equivalent values:
@prefix a: <http://www.w3.org/2000/10/annotation-ns#> . @prefix dc: <http://purl.org/dc/elements/1.1/> . _:b a:annotates <http://www.w3.org/TR/rdf-sparql-query/> . _:b dc:date "2004-12-31T19:00:00-05:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
PREFIX a: <http://www.w3.org/2000/10/annotation-ns#> PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> SELECT ?annotates WHERE { ?annot a:annotates ?annotates . ?annot dc:date ?date . FILTER ( ?date = xsd:dateTime("2005-01-01T00:00:00Z") ) }
annotates |
---|
<http://www.w3.org/TR/rdf-sparql-query/> |
* Invoking RDFterm-equal on two typed literals tests for
equivalent values. An extended implementation may have support for additional datatypes. An implementation processing a query that tests for equivalence on unsupported datatypes (and non-identical lexical form and datatype IRI) returns an error, indicating that it was unable to determine whether or not the values are equivalent. For example, an unextended implementation will produce an error when testing either
"iiii"^^my:romanNumeral = "iv"^^my:romanNumeral
or
"iiii"^^my:romanNumeral != "iv"^^my:romanNumeral
.
xsd:boolean
sameTerm
(RDF term
term1
,RDF term
term2
)
Returns TRUE if term1
and term2
are the same RDF term as defined in Resource Description Framework (RDF): Concepts and Abstract Syntax [CONCEPTS]; returns FALSE otherwise.
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice". _:a foaf:mbox <mailto:alice@work.example> . _:b foaf:name "Ms A.". _:b foaf:mbox <mailto:alice@work.example> .
This query finds the people who have multiple foaf:name
triples:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name1 ?name2 WHERE { ?x foaf:name ?name1 ; foaf:mbox ?mbox1 . ?y foaf:name ?name2 ; foaf:mbox ?mbox2 . FILTER (sameTerm(?mbox1, ?mbox2) && !sameTerm(?name1, ?name2)) }
Query result:
name1 | name2 |
---|---|
"Alice" | "Ms A." |
"Ms A." | "Alice" |
Unlike RDFterm-equal
, sameTerm
can be used to test for non-equivalent typed literals with unsupported data types:
@prefix : <http://example.org/WMterms#> . @prefix t: <http://example.org/types#> . _:c1 :label "Container 1" . _:c1 :weight "100"^^t:kilos . _:c1 :displacement "100"^^t:liters . _:c2 :label "Container 2" . _:c2 :weight "100"^^t:kilos . _:c2 :displacement "85"^^t:liters . _:c3 :label "Container 3" . _:c3 :weight "85"^^t:kilos . _:c3 :displacement "85"^^t:liters .
PREFIX : <http://example.org/WMterms#> PREFIX t: <http://example.org/types#> SELECT ?aLabel1 ?bLabel WHERE { ?a :label ?aLabel . ?a :weight ?aWeight . ?a :displacement ?aDisp . ?b :label ?bLabel . ?b :weight ?bWeight . ?b :displacement ?bDisp . FILTER ( sameTerm(?aWeight, ?bWeight) && !sameTerm(?aDisp, ?bDisp)) }
aLabel | bLabel |
---|---|
"Container 1" | "Container 2" |
"Container 2" | "Container 1" |
The test for boxes with the same weight may also be done with the '=' operator (RDFterm-equal) as the test for "100"^^t:kilos = "85"^^t:kilos
will result in an error, eliminating that potential solution.
xsd:boolean
langMatches
(simple literal
language-tag
,simple literal
language-range
)
Returns true
if language-tag
(first argument) matches language-range
(second argument) per the basic filtering scheme defined in [RFC4647] section 3.3.1. language-range
is a basic language range per Matching of Language Tags [RFC4647] section 2.1. A language-range
of "*" matches any non-empty language-tag
string.
@prefix dc: <http://purl.org/dc/elements/1.1/> . _:a dc:title "That Seventies Show"@en . _:a dc:title "Cette Série des Années Soixante-dix"@fr . _:a dc:title "Cette Série des Années Septante"@fr-BE . _:b dc:title "Il Buono, il Bruto, il Cattivo" .
This query uses langMatches
and lang
(described in section 11.2.3.8) to find the French titles for the show known in English as "That Seventies Show":
PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?title WHERE { ?x dc:title "That Seventies Show"@en ; dc:title ?title . FILTER langMatches( lang(?title), "FR" ) }
Query result:
title |
---|
"Cette Série des Années Soixante-dix"@fr |
"Cette Série des Années Septante"@fr-BE |
The idiom langMatches( lang( ?v ), "*" )
will not match literals without a language tag as lang( ?v )
will return an empty string, so
PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?title WHERE { ?x dc:title ?title . FILTER langMatches( lang(?title), "*" ) }
will report all of the titles with a language tag:
title |
---|
"That Seventies Show"@en |
"Cette Série des Années Soixante-dix"@fr |
"Cette Série des Années Septante"@fr-BE |
xsd:boolean
regex
(simple literal
text
,simple literal
pattern
)xsd:boolean
regex
(simple literal
text
,simple literal
pattern
,simple literal
flags
)
Invokes the XPath fn:matches function to match text
against a regular expression pattern
. The regular expression language is defined in XQuery 1.0 and XPath 2.0 Functions and Operators section 7.6.1 Regular Expression Syntax [FUNCOP].
@prefix foaf: <http://xmlns.com/foaf/0.1/> . _:a foaf:name "Alice". _:b foaf:name "Bob" .
PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?x foaf:name ?name FILTER regex(?name, "^ali", "i") }
Query result:
name |
---|
"Alice" |
rdfTerm
coalesce
(expression, ....
)
The COALESCE
function form returns the RDF term value
of the first expression that evaluates without error. In SPARQL,
evaluating an unbound variable is an error.
If none of the arguments evaluates to an RDF term, an error is raised. If no expressions are evaluate without error, an error is raised.
Examples: Suppose ?x = 2, ?z = 0 and ?y is not bound in some query solution:
COALESCE(?x, 1/0) | returns 2, the value of x |
COALESCE(1/0, ?x) | returns 2 |
COALESCE(5, ?x) | returns 5 |
COALESCE(?y, 3) | returns 3 |
COALESCE(?y) | raises an error because y is not bound. |
rdfTerm
IF
(expression1
,expression2
,expression3
)
The IF
function form evaluates the first argument, interprets it as a effective boolean value, then returns the value of expr2
if the EBV is true, otherwise it returns the value of expr3
. Only one of expr2
and expr3
is evaluated.
Examples: Suppose ?x = 2, ?z = 0 and ?y is not bound in some query solution:
IF(?x = 2, "yes", "no") | returns "yes" |
IF(bound(?y), "yes", "no") | returns "no" |
IF(?x=2, "yes", 1/?z) | returns "yes", the expression 1/?z is not evaluated |
IF(?x=1, "yes", 1/?z) | raises an error |
boolean
rdfTerm
IN
(expression
,...
)
The IN
operator tests whether the RDF term on the
left-hand side is found in the values of list of expressions
on the right-hand side.
The test is done with "=" operator, which tests for the same value, as
determined by the operator mapping.
A list of zero terms on the right-hand side is legal.
Errors in comparisons cause the IN
expression
to raise an error if the RDF term being tested is not found
elsewhere in the list of terms.
The IN
operator is equivalent to the SPARQL expression: @@
(lhs = expression1) || (lhs = expression2) || ...
Examples:
2 IN (1, 2, 3) | true |
2 IN () | false |
2 IN (<http://example/uri>, "str", 2.0) | true |
2 IN (1/0, 2) | true |
2 IN (2, 1/0) | true |
2 IN (3, 1/0) | raises an error |
boolean
rdfTerm
NOT IN
(expression
,...
)
The NOT IN
operator tests whether the RDF term on the
left-hand side is not found in the values of list of expressions
on the right-hand side.
The test is done with "!=" operator, which tests for not the same value, as
determined by the operator mapping.
A list of zero terms on the right-hand side is legal.
Errors in comparsions cause the NOT IN
expression
to raise an error if the RDF term being tested is not found
to be in the list elsewhere in the list of terms.
The NOT IN
operator is equivalent to the SPARQL expression: @@
(lhs != expression1) && (lhs != expression2) && ...
@@ NOT is equivalent to !(IN)
Examples:
2 NOT IN (1, 2, 3) | false |
2 NOT IN () | true |
2 NOT IN (<http://example/uri>, "str", 2.0) | false |
2 NOT IN (1/0, 2) | false |
2 NOT IN (2, 1/0) | false |
2 NOT IN (3, 1/0) | raises an error |
iri
IRI
(simple literal
)
iri
IRI
(iri
)
@@ protoype needs cleaning
@@ xsd:string
@@ Do we need IRI(relStr, baseStrOrIRI)?
The IRI
function constructs an IRI by resolving the string argument
(see RFC 3986
or any later RFC that superceeds RFC 3986.
). The IRI is resolved against the base IRI of the query and must result
in an absolute IRI.
If the function is passed an IRI, it returns the IRI unchanged.
Passing any RDF term other than a simple literal or an IRI is an error.
Implementation MAY normalize the IRI.
Examples:
IRI("http://example/") | <http://example/> |
IRI(<http://example/>) | <http://example/> |
The URI
function is a synonym for IRI
.
blank node
BNODE
()
blank node
BNODE
(simple literal
)
The BNODE
function constructs a blank node that is distinct
from all blank nodes in the datset being queried and distinct
from all blank nodes created by calls to this constructor
for other query solutions. If the no argument form is used
every call results in a distinct blank node. If the form with
a simple literal is used, every call results in distinct blank nodes
for different simple literals, and the same blank node
for calls with the same simple literal within a FILTER for
one solution mapping.
This functionality is compatible with the treatment of blank nodes in SPARQL CONSTRUCT templates.
literal
STRDT
(simple literal
lexicalForm,IRI
datatypeIRI)
The STRDT
function constructs a literal with lexical
form and RDF datatype as specified by the arguments.
STRDT("123", xsd:integer) | "123"^^<http://www.w3.org/2001/XMLSchema#integer> |
STRDT("iiii", <http://example/romanNumeral>) | "iiii"^^<http://example/romanNumeral> |
literal
STRLANG
(simple literal
lexicalForm,simple literal
langTag)
The STRLANG
function constructs a literal with
lexical form and language tag as specificed by the arguments.
STRLANG("chat", "en") | "chat"@en |
There is a filter operator "exists
" that takes a graph pattern.
exists
returns true/false depending on whether the pattern matches the dataset
given the bindings in the current query solution.
No additional binding of variables occurs. The NOT EXISTS
form
translates into fn:not(EXISTS{...})
.
xsd:boolean
NOT EXISTS
{pattern
}
Returns false
if pattern
matches the dataset. Returns true otherwise.
NOT EXISTS { pattern}
is equivalent to fn:not(EXISTS { pattern})
.
xsd:boolean
EXISTS
{pattern
}
Returns true
if pattern
matches the dataset.
Returns false otherwise.
Variables in the pattern
that are bound in the current
solution mapping take the value they have from the solution mapping.
Variables in the pattern pat
that are not bound in the current
solution mapping take part in pattern matching.
To facilitate this, we introduce an algebra operation for the evaluation of the pattern in an algebra EXISTS operation:
Definition: Substitute
Let μ be a solution mapping.
substitute(pattern, μ) = the pattern formed by replacing every occurrence of a variable in pattern by its value in μ.
We define the expression function "exists" using "substitute":
Definition: Exists
Let μ a solution mapping:
exists(pattern, μ) = true if and only if eval(substitute(pattern, μ), D[g]) has any solutions.
@@Rename as "XPath constructor functions"??
SPARQL imports a subset of the XPath constructor functions defined in XQuery 1.0 and XPath 2.0 Functions and Operators [FUNCOP] in section 17.1 Casting from primitive types to primitive types. SPARQL constructors include all of the XPath constructors for the SPARQL operand data types plus the additional datatypes imposed by the RDF data model. Casting in SPARQL is performed by calling a constructor function for the target type on an operand of the source type.
XPath defines only the casts from one XML Schema datatype to another. The remaining casts are defined as follows:
xsd:string
produces a typed literal with a lexical value of the codepoints comprising the IRI, and a datatype of xsd:string
.xsd:string
with the string value equal to the lexical value of the literal to the target datatype.The table below summarizes the casting operations that are always allowed (Y), never allowed (N) and dependent on the lexical value (M). For example, a casting operation from an xsd:string
(the first row) to an xsd:float
(the second column) is dependent on the lexical value (M).
bool = xsd:boolean
dbl = xsd:double
flt = xsd:float
dec = xsd:decimal
int = xsd:integer
dT = xsd:dateTime
str = xsd:string
IRI = IRI
ltrl =simple literal
From \ To | str | flt | dbl | dec | int | dT | bool |
---|---|---|---|---|---|---|---|
str | Y | M | M | M | M | M | M |
flt | Y | Y | Y | M | M | N | Y |
dbl | Y | Y | Y | M | M | N | Y |
dec | Y | Y | Y | Y | Y | N | Y |
int | Y | Y | Y | Y | Y | N | Y |
dT | Y | N | N | N | N | Y | N |
bool | Y | Y | Y | Y | Y | N | Y |
IRI | Y | N | N | N | N | N | N |
ltrl | Y | M | M | M | M | M | M |
A PrimaryExpression grammar rule can be a call to an extension function named by an IRI. An extension function takes some number of RDF terms as arguments and returns an RDF term. The semantics of these functions are identified by the IRI that identifies the function.
SPARQL queries using extension functions are likely to have limited interoperability.
As an example, consider a function called func:even
:
xsd:boolean
func:even
(numeric
value
)
This function would be invoked in a FILTER as such:
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX func: <http://example.org/functions#> SELECT ?name ?id WHERE { ?x foaf:name ?name ; func:empId ?id . FILTER (func:even(?id)) }
For a second example, consider a function aGeo:distance
that calculates the distance between two points, which is used here to find the places near Grenoble:
xsd:double
aGeo:distance
(numeric
x1
,numeric
y1
,numeric
x2
,numeric
y2
)
PREFIX aGeo: <http://example.org/geo#> SELECT ?neighbor WHERE { ?a aGeo:placeName "Grenoble" . ?a aGeo:location ?axLoc . ?a aGeo:location ?ayLoc . ?b aGeo:placeName ?neighbor . ?b aGeo:location ?bxLoc . ?b aGeo:location ?byLoc . FILTER ( aGeo:distance(?axLoc, ?ayLoc, ?bxLoc, ?byLoc) < 10 ) . }
An extension function might be used to test some application datatype not supported by the core SPARQL specification, it might be a transformation between datatype formats, for example into an XSD dateTime RDF term from another date format.
This section defines the correct behavior for evaluation of graph patterns and solution modifiers, given a query string and an RDF dataset. It does not imply a SPARQL implementation must use the process defined here.
The outcome of executing a SPARQL query is defined by a series of steps, starting from the SPARQL query as a string, turning that string into an abstract syntax form, then turning the abstract syntax into a SPARQL abstract query comprising operators from the SPARQL algebra. This abstract query is then evaluated on an RDF dataset.
SPARQL is defined in terms of IRIs [RFC3987]. IRIs are a subset of RDF URI References that omits spaces.
Let I be the set of all IRIs.
Let RDF-L be the set of all RDF Literals
Let RDF-B be the set of all blank nodes in RDF graphs
The set of RDF Terms, RDF-T, is I union RDF-L union RDF-B.
This definition of RDF Term collects together several basic notions from the RDF data model, but updated to refer to IRIs rather than RDF URI references.
An RDF dataset is a set:
{ G, (<u1>, G1), (<u2>, G2), . . .
(<un>, Gn) }
where G and each Gi are graphs, and each <ui> is
an IRI.
Each <ui> is distinct.
G is called the default graph. (<ui>, Gi) are called named graphs.
The active graph is the graph from the dataset used for basic graph pattern matching.
A query variable is a member of the set V where V is infinite and disjoint from RDF-T.
A triple pattern is member of the set:
(RDF-T union V) x (I union V) x (RDF-T union V)
This definition of Triple Pattern includes literal subjects. This has been noted by RDF-core.
"[The RDF core Working Group] noted that it is aware of no reason why literals should not be subjects and a future WG with a less restrictive charter may extend the syntaxes to allow literals as the subjects of statements."
Because RDF graphs may not contain literal subjects, any SPARQL triple pattern with a literal as subject will fail to match on any RDF graph.
A Basic Graph Pattern is a set of Triple Patterns.
The empty graph pattern is a basic graph pattern which is the empty set.
A solution mapping is a mapping from a set of variables to a set of RDF terms. We use the term 'solution' where it is clear.
A solution mapping, μ, is a partial function μ : V -> RDF-T.
The domain of μ, dom(μ), is the subset of V where μ is defined.
A solution sequence is a list of solutions, possibly unordered.
A solution sequence modifier is one of:
This section defines the process of converting graph patterns and solution modifiers in a SPARQL query string into a SPARQL algebra expression. The process describes converts one level of query nesting, as formed by subqueries using the nested SELECT syntax and is applied recursively on subqueries. Each level consists of graph pattern matching and filtering, followed by the application of solution modifiers.
@@Better description of level? Suggestions?
After parsing a SPARQL query string, and applying the abbreviations for IRIs and triple patterns given in section 4, there is an abstract syntax tree composed of:
Patterns | Modifiers | Query Forms |
---|---|---|
RDF terms | DISTINCT | SELECT |
triple patterns | REDUCED | CONSTRUCT |
Basic graph patterns | PROJECT | DESCRIBE |
Groups | ORDER BY | ASK |
OPTIONAL | LIMIT | |
UNION | OFFSET | |
GRAPH | GROUP BY | |
NOT EXISTS | HAVING | |
EXISTS | Select expressions | |
MINUS | ||
FILTER |
The result of converting such an abstract syntax tree is a SPARQL query that uses the following symbols in the SPARQL algebra:
Graph Pattern | Solution Modifiers |
---|---|
BGP | ToList |
Join | OrderBy |
LeftJoin | Project |
Filter | Distinct |
Union | Reduced |
Graph | Slice |
Extends | GroupAggregate@@ |
Minus |
@@Check
Slice is the combination of OFFSET and LIMIT.
ToList is used where conversion from the results of graph pattern matching to sequences occurs.
A SPARQL Abstract Query is a tuple (E, DS, R) where:
This section describes the process for translating a SPARQL graph pattern into a SPARQL algebra expression. After translating syntactic abbreviations for IRIs and triple patterns, it recursively processes syntactic forms into algebra expressions:
OPTIONAL { { ... FILTER ( ... ?x ... ) } }.
.
This is illustrated by two non-normative test cases:
First, expand abbreviations for IRIs and triple patterns given in section 4.
The WhereClause
consists of a
GroupGraphPattern
which is comprised of the following forms:
TriplesBlock
Filter
OptionalGraphPattern
GroupOrUnionGraphPattern
GraphGraphPattern
@@Select
@@NOT EXISTS
@@MINUS
@@Group/aggregate
Each is translated by the following procedure:
Transform(syntax form)
If the form is
TriplesBlock
@@Extend for Property Paths
The result is BGP(list of triple patterns)
If the form is
GroupOrUnionGraphPattern
Let A := undefined For each element G in the GroupOrUnionGraphPattern If A is undefined A := Transform(G) Else A := Union(A, Transform(G)) The result is A
If the form is
GraphGraphPattern
If the form is GRAPH IRI GroupGraphPattern The result is Graph(IRI, Transform(GroupGraphPattern)) If the form is GRAPH Var GroupGraphPattern The result is Graph(Var, Transform(GroupGraphPattern))
If the form is
GroupGraphPattern
We introduce the following symbols:
- Join(Pattern, Pattern)
- LeftJoin(Pattern, Pattern, expression)
- Filter(expression, Pattern)
Let FS := the empty set Let G := the empty pattern, Z, a basic graph pattern which is the empty set. For each element E in the GroupGraphPattern If E is of the form FILTER(expr) FS := FS set-union {expr} If E is of the form OPTIONAL{P} Then Let A := Transform(P) If A is of the form Filter(F, A2) G := LeftJoin(G, A2, F) else G := LeftJoin(G, A, true) @@All binary operators that have open LHS: new UNION, MINUS, (NOT)EXISTS @@SubSELECT?? If E is any other form: Let A := Transform(E) G := Join(G, A) If FS is not empty: Let X := Conjunction of expressions in FS G := Filter(X, G) The result is G.
If the form is MinusGraphPattern[@@link]
@@ Minus(,)
If the form is ServiceGraphPattern[@@link]
@@ Service
If the form is SubSelect [@@link]
@@ Service
Simplification step:
Groups of one graph pattern (not a filter) become join(Z, A) and can be replaced by A. The empty graph pattern Z is the identity for join:
Replace join(Z, A) by A Replace join(A, Z) by A
The second form of a rewrite example is the first with empty group joins removed by the simplification step.
Example: group with a basic graph pattern consisting of a single triple pattern:
Example: group with a basic graph pattern consisting of two triple patterns:
Example: group consisting of a union of two basic graph patterns:
Example: group consisting a union of a union and a basic graph pattern:
Example: group consisting of a basic graph pattern and an optional graph pattern:
Example: group consisting of a basic graph pattern and two optional graph patterns:
Example: group consisting of a basic graph pattern and an optional graph pattern with a filter:
Example: group consisting of a union graph pattern and an optional graph pattern:
Example: group consisting of a basic graph pattern, a filter and an optional graph pattern:
Solutions modifiers apply to the processing of a SPARQL query after pattern matching. The solution modifiers are applied to a query in the following order:
@@First sort out SELECT into extend and project and collect all uses of aggregates at this level.
Step 1 : ToList
ToList turns a multiset into a sequence with the same elements and cardinality. There is no implied ordering to the sequence; duplicates need not be adjacent.
Let M := ToList(Pattern)
Step 2: GROUP BY
If the GROUP BY keyword is used, or there is implicit grouping due to the use of aggregates in the projection, then grouping is performed by the Group function. It divides the solution into one or more solutions, with the same overall cardinality.
If there is no grouping required by the query, then steps 2 and 3 are omitted.
Let G := Group(M)
Step 3: Aggregates
The Aggregation function applies the aggregates to the group, and the results are joined to produce the new solution using the AggregateJoin function.
Let A1 := Aggregation(G)
...Let M := AggregateJoin(A)
Step 4: Select expressions
@@This draft text sorts out extends/project and will also modify the translation step for projection below as well
@@Define "visible variable" and pull out of text here.
We have two forms of the abstract syntax to consider:
SELECT selItem ... { pattern } SELECT * { pattern }
Let X := algebra from earlier steps
Let VS := list of all variables visible in the pattern,
so restricted by sub-SELECT projected variables and GROUP BY variables.
Not visible: only in filter, exists/not exists, masked by a subselect, non-projected GROUP variables.
Let P := [], a list of variable names
Let E := [], a list of pairs of the form (expression, variable)
IF "SELECT *" THEN P := VS
IF "SELECT selItem ...
:" then
for each selItem:
IF selItem is a variable THEN
P := P append variable
FI
IF selItem is (expr AS variable) THEN
variable must not appear in VS; if it does then generate a syntax error and stop
P := P append variable
E := E append (expr, variable)
FI
for each pair (var, expr) in E:
X := extend(X, var, expr)
X := project(X, P)
Result is X
The syntax error arises for use of a variable as the named target of AS (e.g. ... AS ?x) when the variable is used inside the WHERE clause of the SELECT.
Step 5: HAVING
@@
Step 6 : ORDER BY
If the query string has an ORDER BY clause
M := OrderBy(M, list of order comparators)
Step 7 : Projection
M := Project(M, vars)
where vars is the set of variables mentioned in the SELECT clause or all named variables in the query if SELECT * used.
Step 8 : DISTINCT
If the query contains DISTINCT,
M := Distinct(M)
Step 9 : REDUCED
If the query contains REDUCED,
M := Reduced(M)
Step 10 : OFFSET and LIMIT
If the query contains "OFFSET start" or "LIMIT length"
M := Slice(M, start, length)
start defaults to 0
length defaults to (size(M)-start).
The overall abstract query is M.
When matching graph patterns, the possible solutions form a multiset [multiset], also known as a bag. A multiset is an unordered collection of elements in which each element may appear more than once. It is described by a set of elements and a cardinality function giving the number of occurrences of each element from the set in the multiset.
Write μ for solution mappings and
Write μ0 for the mapping such that dom(μ0) is the empty set.
Write Ω0 for the multiset consisting of exactly the empty mapping μ0, with cardinality 1. This is the join identity.
Write μ(?x->t) for the solution mapping variable x to RDF term t : { (x, t) }
Write Ω(?x->t) for the multiset consisting of exactly μ(?x->t), that is, { { (x, t) } } with cardinality 1.
Two solution mappings μ1 and μ2 are compatible if, for every variable v in dom(μ1) and in dom(μ2), μ1(v) = μ2(v).
If μ1 and μ2 are compatible then μ1 set-union μ2 is also a mapping. Write merge(μ1, μ2) for μ1 set-union μ2
Write card[Ω](μ) for the cardinality of solution mapping μ in a multiset of mappings Ω.
Basic graph patterns form the basis of SPARQL pattern matching. A basic graph pattern is matched against the active graph for that part of the query. Basic graph patterns can be instantiated by replacing both variables and blank nodes by terms, giving two notions of instance. Blank nodes are replaced using an RDF instance mapping, σ, from blank nodes to RDF terms; variables are replaced by a solution mapping from query variables to RDF terms.
A Pattern Instance Mapping, P, is the combination of an RDF instance mapping, σ, and solution mapping, μ. P(x) = μ(σ(x))
For a BGP 'x', P(x) denotes the result of replacing blank nodes b in x for which σ is defined with σ(b) and all variables v in x for which μ is defined with μ(v).
Any pattern instance mapping defines a unique solution mapping and a unique RDF instance mapping obtained by restricting it to query variables and blank nodes respectively.
Let BGP be a basic graph pattern and let G be an RDF graph.
μ is a solution for BGP from G when there is a pattern instance mapping P such that P(BGP) is a subgraph of G and μ is the restriction of P to the query variables in BGP.
card[Ω](μ) = card[Ω](number of distinct RDF instance mappings, σ, such that P = μ(σ) is a pattern instance mapping and P(BGP) is a subgraph of G).
If a basic graph pattern is the empty set, then the solution is Ω0.
This definition allows the solution mapping to bind a variable in a basic graph pattern, BGP, to a blank node in G. Since SPARQL treats blank node identifiers in a SPARQL Query Results XML Format document as scoped to the document, they cannot be understood as identifying nodes in the active graph of the dataset. If DS is the dataset of a query, pattern solutions are therefore understood to be not from the active graph of DS itself, but from an RDF graph, called the scoping graph, which is graph-equivalent to the active graph of DS but shares no blank nodes with DS or with BGP. The same scoping graph is used for all solutions to a single query. The scoping graph is purely a theoretical construct; in practice, the effect is obtained simply by the document scope conventions for blank node identifiers.
Since RDF blank nodes allow infinitely many redundant solutions for many patterns, there can be infinitely many pattern solutions (obtained by replacing blank nodes by different blank nodes). It is necessary, therefore, to somehow delimit the solutions for a basic graph pattern. SPARQL uses the subgraph match criterion to determine the solutions of a basic graph pattern. There is one solution for each distinct pattern instance mapping from the basic graph pattern to a subset of the active graph.
This is optimized for ease of computation rather than redundancy elimination. It allows query results to contain redundancies even when the active graph of the dataset is lean, and it allows logically equivalent datasets to yield different query results.
For each symbol in a SPARQL abstract query, we define an operator for evaluation. The SPARQL algebra operators of the same name are used to evaluate SPARQL abstract query nodes as described in the section "Evaluation Semantics".
Definition: Filter
Let Ω be a multiset of solution mappings and expr be an expression. We define:
Filter(expr, Ω) = { μ | μ in Ω and expr(μ) is an expression that has an effective boolean value of true }
card[Filter(expr, Ω)](μ) = card[Ω](μ)
Definition: Join
Let Ω1 and Ω2 be multisets of solution mappings. We define:
Join(Ω1, Ω2) = { merge(μ1, μ2) | μ1 in Ω1and μ2 in Ω2, and μ1 and μ2 are compatible }
card[Join(Ω1, Ω2)](μ) =
for each merge(μ1, μ2), μ1
in Ω1and μ2 in Ω2 such that μ = merge(μ1, μ2),
sum over (μ1, μ2), card[Ω1](μ1)*card[Ω2](μ2)
It is possible that a solution mapping μ in a Join can arise in different solution mappings, μ1and μ2 in the multisets being joined. The cardinality of μ is the sum of the cardinalities from all possibilities.
Definition: Diff
Let Ω1 and Ω2 be multisets of solution mappings. We define:
Diff(Ω1, Ω2, expr) = { μ | μ in Ω1 such that for all μ′ in Ω2, either μ and μ′ are not compatible or μ and μ' are compatible and expr(merge(μ, μ')) has an effective boolean value of false }
card[Diff(Ω1, Ω2, expr)](μ) = card[Ω1](μ)
Diff is used internally for the definition of LeftJoin.
Definition: LeftJoin
Let Ω1 and Ω2 be multisets of solution mappings and expr be an expression. We define:
LeftJoin(Ω1, Ω2, expr) = Filter(expr, Join(Ω1, Ω2)) set-union Diff(Ω1, Ω2, expr)
card[LeftJoin(Ω1, Ω2, expr)](μ) = card[Filter(expr, Join(Ω1, Ω2))](μ) + card[Diff(Ω1, Ω2, expr)](μ)
Written in full that is:
LeftJoin(Ω1, Ω2, expr) =
{ merge(μ1, μ2) | μ1 in Ω1and μ2 in
Ω2, and μ1 and μ2 are compatible and expr(merge(μ1,
μ2)) is true }
set-union
{ μ1 | μ1 in Ω1and μ2 in Ω2, and
μ1 and μ2 are not compatible, or Ω2 is empty }
set-union
{ μ1 | μ1 in Ω1and μ2 in Ω2, and
μ1 and μ2 are compatible and expr(merge(μ1, μ2)) is false,
or Ω2 is empty }
As these are distinct, the cardinality of LeftJoin is cardinality of these individual components of the definition.
Definition: Union
Let Ω1 and Ω2 be multisets of solution mappings. We define:
Union(Ω1, Ω2) = { μ | μ in Ω1 or μ in Ω2 }
card[Union(Ω1, Ω2)](μ) = card[Ω1](μ) + card[Ω2](μ)
Definition: Minus
Let Ω1 and Ω2 be multisets of solution mappings. We define:
Minus(Ω1, Ω2) = { μ | μ in Ω1 such that for all μ' in Ω2, either μ and μ' are not compatible or dom(μ) and dom(μ') are disjoint }
card[Minus(Ω1, Ω2)](μ) = card[Ω1](μ)
The additional restriction on dom(μ) and dom(μ') is added because otherwise
if there is a solution mapping in Ω2 that has no variables in
common with the solution mappings of Ω1, then
Minus(Ω1, Ω2) would be empty, regardless of
the rest of Ω2. The empty solution mapping is compatible
with every other solution mapping so P MINUS {}
would otherwise
be empty for any pattern P
.
Let μ be a solution mapping, Ω a multiset of solution mappings, var a variable and expr be an expression [@@link], then we define:
extend is undefined when var in dom(μ).extend(μ, var, expr) = μ set-union { (var,value) | var not in dom(μ) and value = eval(expr) }
extend(μ, var, expr) = μ if var not in dom(μ) and eval(expr) is an error
extend(Ω , var, term) = { extend(μ, var, term) | μ in Ω }
@@ Define the case for var in dom(μ) (does not arise in SELECT expressions)
Write [x | C] for a sequence of elements where C(x) is true.
Write card[L](x) to be the cardinality of x in L.
Let Ω be a multiset of solution mappings. We define:
ToList(Ω) = a sequence of mappings μ in Ω in any order, with card[Ω](μ) occurrences of μ
card[ToList(Ω)](μ) = card[Ω](μ)
Let Ψ be a sequence of solution mappings. We define:
OrderBy(Ψ, condition) = [ μ | μ in Ψ and the sequence satisfies the ordering condition]
card[OrderBy(Ψ, condition)](μ) = card[Ψ](μ)
Let Ψ be a sequence of solution mappings and PV a set of variables.
For mapping μ, write Proj(μ, PV) to be the restriction of μ to variables in PV.
Project(Ψ, PV) = [ Proj(Ψ[μ], PV) | μ in Ψ ]
card[Project(Ψ, PV)](μ) = card[Ψ](μ)
The order of Project(Ψ, PV) must preserve any ordering given by OrderBy.
Let Ψ be a sequence of solution mappings. We define:
Distinct(Ψ) = [ μ | μ in Ψ ]
card[Distinct(Ψ)](μ) = 1
The order of Distinct(Ψ) must preserve any ordering given by OrderBy.
Let Ψ be a sequence of solution mappings. We define:
Reduced(Ψ) = [ μ | μ in Ψ ]
card[Reduced(Ψ)](μ) is between 1 and card[Ψ](μ)
The order of Reduced(Ψ) must preserve any ordering given by OrderBy.
The Reduced solution sequence modifier does not guarantee a defined cardinality.
We define eval(D(G), graph pattern) as the evaluation of a graph pattern with respect to a dataset D having active graph G. The active graph is initially the default graph.
D : a dataset D(G) : D a dataset with active graph G (the one patterns match against) D[i] : The graph with IRI i in dataset D D[DFT] : the default graph of D P, P1, P2 : graph patterns L : a solution sequence
eval(D(G), Filter(F, P)) = Filter(F, eval(D(G),P))
eval(D(G), Join(P1, P2)) = Join(eval(D(G), P1), eval(D(G), P2))
eval(D(G), LeftJoin(P1, P2, F)) = LeftJoin(eval(D(G), P1), eval(D(G), P2), F)
eval(D(G), BGP) = multiset of solution mappings
See section 12.3 Basic Graph Patterns
eval(D(G), Union(P1,P2)) = Union(eval(D(G), P1), eval(D(G), P2))
if IRI is a graph name in D eval(D(G), Graph(IRI,P)) = eval(D(D[IRI]), P)
if IRI is not a graph name in D eval(D(G), Graph(IRI,P)) = the empty multiset
eval(D(G), Graph(var,P)) = Let R be the empty multiset foreach IRI i in D R := Union(R, Join( eval(D(D[i]), P) , Ω(?var->i) ) the result is R
The evaluation of graph uses the SPARQL algebra union operator. The cardinality of a solution mapping is the sum of the cardinalities of that solution mapping in each join operation.
eval(D(G), extend(var, expr, P)) = extend(var, expr , eval(D(G), P))
@@Only defined where var no already bound
eval(D, ToList(P)) = ToList(eval(D(D[DFT]), P))
eval(D, Distinct(L)) = Distinct(eval(D, L))
eval(D, Reduced(L)) = Reduced(eval(D, L))
eval(D, Project(L, vars)) = Project(eval(D, L), vars)
eval(D, OrderBy(L, condition)) = OrderBy(eval(D, L), condition)
eval(D, Slice(L, start, length)) = Slice(eval(D, L), start, length)
The overall SPARQL design can be used for queries which assume a more elaborate form of entailment than simple entailment, by re-writing the matching conditions for basic graph patterns. Since it is an open research problem to state such conditions in a single general form which applies to all forms of entailment and optimally eliminates needless or inappropriate redundancy, this document only gives necessary conditions which any such solution should satisfy. These will need to be extended to full definitions for each particular case.
Basic graph patterns stand in the same relation to triple patterns that RDF graphs do to RDF triples, and much of the same terminology can be applied to them. In particular, two basic graph patterns are said to be equivalent if there is a bijection M between the terms of the triple patterns that maps blank nodes to blank nodes and maps variables, literals and IRIs to themselves, such that a triple ( s, p, o ) is in the first pattern if and only if the triple ( M(s), M(p), M(o) ) is in the second. This definition extends that for RDF graph equivalence to basic graph patterns by preserving variable names across equivalent patterns.
An entailment regime specifies
Examples of entailment regimes include simple entailment [RDF-MT], RDF entailment [RDF-MT], RDFS entailment [RDF-MT], D-entailment [RDF-MT] and OWL Direct and RDF-Based Semantics entailment [Ref: OWL2 semantics]. Of these, only OWL Direct Semantics (OWL-DL) entailment restricts the set of well-formed graphs. If E is an entailment regime then we will refer to E-entailment, E-consistency, etc, following this naming convention.
Some entailment regimes can categorize some RDF graphs as inconsistent. For example, the RDF graph:
_:x rdf:type xsd:string . _:x rdf:type xsd:decimal .
is D-inconsistent when D contains the XSD datatypes. The effect of a query on an inconsistent graph is not covered by this specification, but must be specified by the particular SPARQL extension.
A SPARQL extension to E-entailment must satisfy the following conditions.
1 -- The scoping graph, SG, corresponding to any consistent active graph AG is uniquely specified up to RDF graph equivalence and is E-equivalent to AG.
2 -- For any basic graph pattern BGP and pattern instance mapping P, P(BGP) is well-formed for E
3 -- For any scoping graph SG and answer set {P1 ... Pn} for a basic graph pattern BGP, and where {BGP1 .... BGPn} is a set of basic graph patterns all equivalent to BGP, none of which share any blank nodes with any other or with SG
SG E-entails (SG union P1(BGP1) union ... union Pn(BGPn))
These conditions do not fully determine the set of possible answers, since RDF allows unlimited amounts of redundancy. In addition, therefore, the following must hold.
4 -- Each SPARQL extension MUST provide conditions on answer sets which guarantee that the set of triples obtained by instantiating BGP with each solution μ is uniquely specified up to RDF graph equivalence, and SHOULD provide further conditions to prevent trivial infinite answers as appropriate to the regime.
(a) SG will often be graph equivalent to AG, but restricting this to E-equivalence allows some forms of normalization, for example elimination of semantic redundancies, to be applied to the source documents before querying.
(b) The construction in condition 3 ensures that any blank nodes introduced by the solution mapping are used in a way which is internally consistent with the way that blank nodes occur in SG. This ensures that blank node identifiers occur in more than one answer in an answer set only when the blank nodes so identified are indeed identical in SG. If the extension does not allow answer bindings to blank nodes, then this condition can be simplified to the condition:
SG E-entails P(BGP) for each pattern solution P.
(c) These conditions do not impose the SPARQL requirement that SG shares no blank nodes with AG or BGP. In particular, it allows SG to actually be AG. This allows query protocols in which blank node identifiers retain their meaning between the query and the source document, or across multiple queries. Such protocols are not supported by the current SPARQL protocol specification, however.
(d) Since conditions 1 to 3 are only necessary conditions on answers, condition 4 allows cases where the set of legal answers can be restricted in various ways. For example, the current state of the art in OWL-DL querying focusses on the case where answer bindings to blank nodes are prohibited. We note that these conditions even allow the pathological 'mute' case where every query has an empty answer set.
(e) None of these conditions refer explicitly to instance mappings on blank nodes in BGP. For some entailment regimes, the existential interpretation of blank nodes cannot be fully captured by the existence of a single instance mapping. These conditions allow such regimes to give blank nodes in query patterns a 'fully existential' reading.
It is straightforward to show that SPARQL satisfies these conditions for the case where E is simple entailment, given that the SPARQL condition on SG is that it is graph-equivalent to AG but shares no blank nodes with AG or BGP (which satisfies the first condition). The only condition which is nontrivial is (3).
Every answer Pi is the solution mapping restriction of a SPARQL instance Mi such that Mi(BGPi) is a subgraph of SG. Since BGPi and SG have no blank nodes in common, the range of Mi contains no blank nodes from BGPi; therefore, the solution mapping Pi and RDF instance mapping Ii components of Mi commute, so Mi(BGPi) = Ii(Pi(BGPi)). So
M1(BGP1) union ... union Mn(BGPn)
= I1(P1(BGP1)) union ... union In(Pn(BGPn))
= [ I1 + ... + In]( P1(BGP1) union
... union Pn(BGPn) )
since the domains of the Ii instance mappings are all mutually exclusive. Since they are also exclusive from SG,
SG union [ I1 + ... + In]( P1(BGP1)
union ... union Pn(BGPn) )
= [ I1 + ... + In](SG union P1(BGP1)
union ... union Pn(BGPn) )
i.e.
SG union P1(BGP1) union ... union Pn(BGPn)
has an instance which is a subgraph of SG, so is simply entailed by SG by the RDF interpolation lemma [RDF-MT].
A SPARQL query string
is a Unicode character string (c.f. section 6.1 String concepts of [CHARMOD])
in the language defined by the following grammar, starting with the
Query production. For compatibility with future versions of
Unicode, the characters in this string may include Unicode codepoints that are unassigned
as of the date of this publication (see
Identifier
and Pattern Syntax [UNIID] section 4 Pattern Syntax). For
productions with excluded character classes (for example [^<>'{}|^`]
),
the characters are excluded from the range #x0 - #x10FFFF
.
A SPARQL Query String is processed for codepoint escape sequences before parsing by the grammar defined in EBNF below. The codepoint escape sequences for a SPARQL query string are:
Escape | Unicode code point |
---|---|
'\u' HEX HEX HEX HEX | A Unicode code point in the range U+0 to U+FFFF inclusive corresponding to the encoded hexadecimal value. |
'\U' HEX HEX HEX HEX HEX HEX HEX HEX | A Unicode code point in the range U+0 to U+10FFFF inclusive corresponding to the encoded hexadecimal value. |
where HEX is a hexadecimal character
HEX ::= [0-9] | [A-F] | [a-f]
Examples:
<ab\u00E9xy> # Codepoint 00E9 is Latin small e with acute - é \u03B1:a # Codepoint x03B1 is Greek small alpha - α a\u003Ab # a:b -- codepoint x3A is colon
Codepoint escape sequences can appear anywhere in the query string. They are
processed before parsing based on the grammar rules and so may be replaced by codepoints
with significance in the grammar, such as ":
" marking a prefixed name.
These escape sequences are not included in the grammar below. Only escape sequences
for characters that would be legal at that point in the grammar may be given. For
example, the variable "?x\u0020y
" is not legal (\u0020
is a space and is not permitted in a variable name).
White space (production WS
)
is used to separate two terminals which would otherwise be (mis-)recognized as one
terminal. Rule names below in capitals indicate where white space is significant;
these form a possible choice of terminals for constructing a SPARQL parser. White
space is significant in strings.
For example:
?a<?b&&?c>?d
is the token sequence variable '?a
', an IRI '<?b&&?c>
',
and variable '?d
', not a expression involving the operator '&&
'
connecting two expression using '<
' (less than) and '>
' (greater than).
Comments in SPARQL queries take the form of '#
', outside an IRI
or string, and continue to the end of line (marked by characters 0x0D
or 0x0A
) or end of file if there is no end of line after the comment
marker. Comments are treated as white space.
Text matched by the IRI_REF
production and PrefixedName
(after
prefix expansion) production, after escape processing, must be conform to the generic
syntax of IRI references in section 2.2 of RFC 3987 "ABNF for IRI References and
IRIs" [RFC3987]. For example, the
IRI_REF
<abc#def>
may occur in a
SPARQL query string, but the IRI_REF
<abc##def>
must not.
Base IRIs declared with the BASE keyword must be absolute IRIs. A prefix declared with the PREFIX keyword may not be re-declared in the same query. See section 2.1.1, Syntax of IRI Terms, for a description of BASE and PREFIX.
The same blank node label may not be used in two separate basic graph patterns with a single query.
In addition to the codepoint escape sequences, the following escape sequences
any string
production (e.g.
STRING_LITERAL1
,
STRING_LITERAL2
,
STRING_LITERAL_LONG1
,
STRING_LITERAL_LONG2
):
Escape | Unicode code point |
---|---|
'\t' | U+0009 (tab) |
'\n' | U+000A (line feed) |
'\r' | U+000D (carriage return) |
'\b' | U+0008 (backspace) |
'\f' | U+000C (form feed) |
'\"' | U+0022 (quotation mark, double quote mark) |
"\'" | U+0027 (apostrophe-quote, single quote mark) |
'\\' | U+005C (backslash) |
Examples:
"abc\n" "xy\rz" 'xy\tz'
The EBNF notation used in the grammar is defined in Extensible Markup Language (XML) 1.1 [XML11] section 6 Notation.
Keywords are matched in a case-insensitive manner with the exception of the keyword
'a
' which, in line with Turtle and N3, is used in place of the IRI
rdf:type
(in full,
http://www.w3.org/1999/02/22-rdf-syntax-ns#type
).
Keywords: @@Update for SPARQL 1.1
BASE | SELECT | ORDER BY | FROM | GRAPH | STR | isURI |
PREFIX | CONSTRUCT | LIMIT | FROM NAMED | OPTIONAL | LANG | isIRI |
DESCRIBE | OFFSET | WHERE | UNION | LANGMATCHES | isLITERAL | |
ASK | DISTINCT | FILTER | DATATYPE | REGEX | ||
REDUCED | a | BOUND | true | |||
sameTERM | false | |||||
isBLANK |
Escape sequences are case sensitive.
When choosing a rule to match, the longest match is chosen.
Notes:
AdditiveExpression
grammar rule
allows for this by covering the the two cases of an expression followed by a
signed number. These produce an addition or substraction of the unsigned
number as appropriate.Some grammar files for some commonly used tools are available here.
See appendix A SPARQL Grammar regarding conformance of SPARQL Query strings, and section 10 Query Forms for conformance of query results. See appendix E. Internet Media Type for conformance to the application/sparql-query media type.
This specification is intended for use in conjunction with the SPARQL Protocol [SPROT] and the SPARQL Query Results XML Format [RESULTS]. See those specifications for their conformance criteria.
Note that the SPARQL protocol describes an abstract interface as well as a network protocol, and the abstract interface may apply to APIs as well as network interfaces.
SPARQL queries using FROM, FROM NAMED, or GRAPH may cause the specified URI to
be dereferenced. This may cause additional use of network, disk or CPU resources
along with associated secondary issues such as denial of service. The security issues
of Uniform Resource Identifier
(URI): Generic Syntax [RFC3986] Section 7 should be considered.
In addition, the contents of file:
URIs can in some cases be accessed,
processed and returned as results, providing unintended access to local resources.
SPARQL requests may cause additional requests to be issued from the SPARQL endpoint, such as FROM NAMED. The endpoint is potentially within an organisations firewall or DMZ, and so such queries may be a source of indirection attacks.
The SPARQL language permits extensions, which will have their own security implications.
Multiple IRIs may have the same appearance. Characters in different scripts may look similar (a Cyrillic "о" may appear similar to a Latin "o"). A character followed by combining characters may have the same visual representation as another character (LATIN SMALL LETTER E followed by COMBINING ACUTE ACCENT has the same visual representation as LATIN SMALL LETTER E WITH ACUTE). Users of SPARQL must take care to construct queries with IRIs that match the IRIs in the data. Further information about matching of similar characters can be found in Unicode Security Considerations [UNISEC] and Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8.
The Internet Media Type / MIME Type for the SPARQL Query Language is "application/sparql-query".
It is recommended that sparql query files have the extension ".rq" (all lowercase) on all platforms.
It is recommended that sparql query files stored on Macintosh HFS file systems be given a file type of "TEXT".
$Log: Overview.html,v $ Revision 1.4 2018/10/09 13:23:09 denis fix validation of xhtml documents Revision 1.3 2017/10/02 10:42:18 denis add fixup.js to old specs Revision 1.2 2010/10/14 00:29:13 bertails ~ http://lists.w3.org/Archives/Team/webreq/2010Oct/0064.html Revision 1.8 2010/10/13 17:18:51 apollere2 AddedThis is a Working Draft.
Revision 1.7 2010/10/12 15:34:48 aseaborne Tweak for publication Revision 1.6 2010/10/12 15:29:45 aseaborne Tweak for publication Revision 1.5 2010/10/12 15:24:33 aseaborne Tweak for publication Revision 1.4 2010/10/08 05:29:14 apollere2 Changed "This version" to final URI. Revision 1.3 2010/10/08 05:24:24 apollere2 Changed previous version. Revision 1.2 2010/10/07 08:15:34 aseaborne Publication 2010-10-14 Revision 1.99 2010/10/06 12:46:06 aseaborne Edits for publication/validation Revision 1.98 2010/10/06 12:42:18 aseaborne Edits for publication/validation Revision 1.97 2010/10/01 13:02:43 sharris2 Fix typo and clarify meaning of sentence in Aggregates: from explitic groups -> from groups where the ExprList is non-empty as per http://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0002.html Revision 1.96 2010/09/29 09:29:46 sharris2 Fix Aggregation() example in section 10.2.3 Revision 1.95 2010/09/29 09:23:42 sharris2 Add note explainint the use of the value 1 as a key in groups Use the empty set instead of the digit 0 in Aggreagation example Fix example of Sum() evaluation (was decimal, should have been float) Fix defintion of Sum() so that Sum("a") is a type error Use "codepoint U+0020" instead of "codepoint 32" Remove outdated note about variable scope errors in Subselect section Revision 1.94 2010/09/28 18:07:49 aseaborne Typo/editorial Revision 1.93 2010/09/28 18:07:07 aseaborne Typo/editorial Revision 1.92 2010/09/28 18:04:57 aseaborne Typo/editorial Revision 1.91 2010/09/28 17:52:05 aseaborne Add isNumeric Revision 1.90 2010/09/24 16:33:07 aseaborne Changes in response to comments in 2010JulSep/0434 and 2010JulSep/0440. Details in replies to those messages. Revision 1.89 2010/09/21 11:04:30 aseaborne Update grammar Revision 1.88 2010/09/08 20:40:06 aseaborne Move property path material to query document. Reformat notes and ToDo items Revision 1.87 2010/09/07 14:45:02 sharris2 Added english text to aggregate definitions Added definition of Having() Revision 1.86 2010/08/31 14:03:27 aseaborne Add placeholders for algebra translation (MINUS/SERVICE/SubSELECT) Revision 1.85 2010/08/28 12:15:40 aseaborne Add section placeholder for Federated Query Revision 1.84 2010/08/27 12:45:21 aseaborne Note work needed on SELECT * Revision 1.83 2010/08/27 12:33:12 aseaborne Move EXISTS defintion to the 'Testing Values' section Revision 1.82 2010/08/26 15:46:33 aseaborne Move MINUS defintion to algebra section Revision 1.81 2010/08/26 14:27:16 aseaborne Make the two lists of solution modifiers orderings agree Revision 1.80 2010/08/25 09:22:55 sharris2 Reworded paragraph on projecting non-GROUP varaibles, following Axel's feedback Revision 1.79 2010/08/23 18:21:28 aseaborne Fixed typos mentioned in 2010JulSep/0233 Revision 1.78 2010/08/17 14:10:29 sharris2 Fixed typos in section 10.2 mentioned in http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JulSep/0233.html Revision 1.77 2010/08/06 12:05:20 aseaborne Update author details for Andy Revision 1.76 2010/07/29 19:17:07 aseaborne Add @@ Revision 1.75 2010/07/27 11:12:55 sharris2 Fixed typographic errors noted by Dave Beckett in http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Jul/0011.html Revision 1.74 2010/07/09 16:47:20 aseaborne Correction Revision 1.73 2010/06/04 19:48:53 aseaborne Reset to editors working draft state Revision 1.72 2010/06/04 19:46:27 aseaborne IN, NOT IN - protoype uses expressions as evaluation is error-sensitive) Revision 1.71 2010/06/04 19:44:34 aseaborne IN, NOT IN - protoype uses expressions as evaluation is error-sensitive) Revision 1.70 2010/06/04 17:14:48 aseaborne Added note for IRI with explicit base Revision 1.69 2010/06/04 17:02:42 aseaborne Added note for IRI with explicit base Revision 1.68 2010/06/03 12:41:23 aseaborne First draft text for new SPARQL 1.1 functions Revision 1.67 2010/05/25 14:33:06 lfeigenb move version to after "SPARQL" in title Revision 1.66 2010/05/24 10:25:22 aseaborne Changes for WD publication Revision 1.65 2010/05/24 08:06:21 aseaborne Editorial fix 2010May/0002 Revision 1.64 2010/05/20 19:01:23 aseaborne Comments from 2010AprJun/0220 Revision 1.63 2010/05/19 21:33:53 sharris2 Fix HTML problems with blockquotes inside ps Revision 1.62 2010/05/19 19:54:13 aseaborne Fix link into old spec Revision 1.61 2010/05/18 18:15:45 sharris2 Fix HTML errors Revision 1.60 2010/05/18 18:08:34 aseaborne Fix typo Revision 1.59 2010/05/18 17:13:19 aseaborne Update section "negation" to reflect ISSUE-29. Revision 1.58 2010/05/18 13:51:02 sharris2 Fix subsection numbering in Aggregates section Revision 1.57 2010/05/18 09:29:18 aseaborne Fix XSL/CSS to work from same directory - aids publishing portability Revision 1.56 2010/05/17 21:33:36 aseaborne Update grammar Revision 1.55 2010/05/17 20:03:05 aseaborne Clean up some validation errors Revision 1.54 2010/05/17 09:43:08 sharris2 Added missing {s to example in Aggregates section Revision 1.53 2010/05/08 19:21:13 aseaborne WG comments: see 2010AprJun/0115 Revision 1.52 2010/05/07 22:23:32 aseaborne Correct MINUS example Revision 1.51 2010/05/04 10:39:29 aseaborne Add example for MINUS Add section about differences in MINUS and NOT EXISTS Revision 1.50 2010/04/29 16:58:11 sharris2 More work on aggregates, now closer to being a complete description Revision 1.49 2010/04/28 17:03:25 sharris2 Much more work on aggregates, now mostly hangs together, not yet complete Revision 1.48 2010/04/27 13:59:17 sharris2 Partial update of Aggregates section to match F2F discussion. Set functions refeined down to GroupConcat Revision 1.47 2010/04/27 11:44:28 sharris2 Fix references to "aggregate functions". Revision 1.46 2010/04/27 09:11:02 aseaborne Minor: Fix example in 2.5 Revision 1.45 2010/04/26 09:22:05 aseaborne Placeholders for grammar notes Revision 1.44 2010/04/22 13:02:18 aseaborne Typo in grammar section Revision 1.43 2010/04/22 12:47:38 aseaborne Edit BGP extension conditions 1 and 4 Revision 1.42 2010/04/16 09:33:56 aseaborne More editting for SELECT expressions and algebra definitions Revision 1.41 2010/04/15 22:20:01 aseaborne Moved definitions for SELECT expression into various definitions sections. Add @@ placeholders Revision 1.40 2010/04/01 13:59:07 aseaborne Added more placeholders Revision 1.39 2010/03/30 08:33:28 aseaborne Add placeholders for SPARQL 1.1 extra functions Revision 1.37 2010/03/30 08:29:52 aseaborne Add placeholders for SPARQL 1.1 extra functions Revision 1.36 2010/02/26 10:21:04 aseaborne Add @@ to note library functions to be documented Revision 1.35 2010/01/26 16:13:16 aseaborne Put in references from SPARQL 1.0 to fix broken links Revision 1.34 2010/01/24 15:24:04 apollere2 Commented Revision 1.33 2010/01/22 01:15:08 apollere2 Changed previous version link, pubrules complained about different shortname and we have a new previous version. Revision 1.32 2010/01/22 01:05:50 apollere2 Changed previous version to FPWD sparql 1.1 Revision 1.31 2010/01/22 00:49:06 apollere2 Fixed some validation error. Revision 1.30 2010/01/06 13:59:51 aseaborne Add previous editor Revision 1.29 2010/01/05 13:42:05 aseaborne Corrections in response to 2010JanMar/0022. See 2010JanMar/0025. Revision 1.28 2010/01/05 11:01:08 aseaborne Editorial corrections Revision 1.27 2010/01/05 10:57:17 sharris2 Fixed typo SELCT -> SELECT Fixed error in query in §10 Added text about variable scope in subqueries to end of §10 Revision 1.26 2010/01/04 16:16:41 aseaborne Fix markup Revision 1.25 2010/01/04 16:04:34 aseaborne Editorial fixes from 2010JanMar/0001. See 2010JanMar/0014. Revision 1.24 2010/01/04 14:12:53 aseaborne Editorial fixes from 2010JanMar/0000. Revision 1.23 2010/01/04 11:30:00 sharris2 Fix english in §9 (aggregateFunctions) Fix defn. of key(), added ref. to ISSUE-53 in §9.2 Changed 2nd subquery example in §10 (subqueries) Fixed typo funstion -> function reuslting -> resulting Revision 1.22 2009/12/30 21:30:26 aseaborne Put in editors and document name Revision 1.21 2009/12/22 12:23:59 sharris2 Added paragraph to Security Considations section about indirection attacks to close ACTION-135 Revision 1.20 2009/12/21 15:06:31 aseaborne Editorial Revision 1.19 2009/12/21 14:56:23 aseaborne Editorial Revision 1.18 2009/12/21 13:00:00 sharris2 Cleanup section heading for aggregates Revision 1.17 2009/12/21 12:51:06 sharris2 Added section on subqueries from FPWD Revision 1.16 2009/12/21 12:16:20 sharris2 Added text explaining the rules around projecting in aggregated queries Revision 1.15 2009/12/20 19:49:37 sharris2 Removed dead link marker Revision 1.14 2009/12/20 19:48:09 sharris2 Added section on aggregate functions Revision 1.13 2009/12/19 18:35:03 aseaborne Typo Revision 1.12 2009/12/19 18:23:02 aseaborne Update abstract Revision 1.11 2009/12/16 13:12:53 aseaborne Editorial Revision 1.10 2009/12/16 13:10:55 aseaborne Added content for NOT EXISTS as a new section. Changed affilation for Andy Make use of bold in definitions consistent. Revision 1.9 2009/12/14 14:20:50 aseaborne Put SELECT expression text into SELECT section. Fixup <pre> (had leading blank line) Revision 1.8 2009/12/14 06:25:53 lfeigenb add relative path for xmlspec.dtd Revision 1.7 2009/12/07 17:12:02 aseaborne 12.1.6 Solution Mapping Remove bold on Solution Mapping and Solution Sequence Add "isBLANK" to keyword table. Revision 1.6 2009/12/07 16:56:05 aseaborne Missed applying s/non-unique/non-distinct/ Fixed section depth in 10.2.1, .2, .3 Revision 1.5 2009/12/07 16:31:50 aseaborne Errata applied (SPARQL 1.0): Sections numbers refer to SPARQL 1.0: See Wiki Errata page. 1-- 11.4.1 SELECT ?name .., ?givenName Should be SELECT ?givenName 2-- TOC /Restricting the Value/ should be /Values/ TOC is now automatcially created 3-- 12.1.7 REDUCED s/non-unique/non-distinct/ 4-- 9.1 Order By Remove incorrect example (was third in list) 5-- 9.3.1 DISTINCT s/solution set/solution sequence/ 6-- 12.4 SPARQL Algebra (Left Join showed in full) Added "or Ω2 is empty" to cases 2 and 3. 7-- 10.3 ASK Fix SPARQL XML Results example 8-- 11.3 Operator Mapping of SameTerm s/sameTERM(A)/sameTERM(A, B)/In 9.3.2 REDUCED, s/an REDUCED/a REDUCED 9-- 12 Definition of SPARQL s/outcome of executing a SPARQL/outcome of executing a SPARQL query/ 10-- 12.6 Extending SPARQL Basic Graph Matching s/pattern solution mapping/pattern instance mapping/ 11-- 12.1.6 Definition: Solution Mapping s/V -> T/V -> RDF-T/ 12-- 12.2.1 s/the point at the simplification step/the point at which the simplification step/ 13-- 9.3.2 REDUCED s/an REDUCED/a REDUCED 14-- 12.2.1 Converting Graph Patterns s/a SPARQL graph patterns/a SPARQL graph pattern/ 15-- In 12.6 Extending SPARQL Basic Graph Matching, s/share no/shares no/ Revision 1.4 2009/11/08 17:07:09 aseaborne Use common XML processing from ../shared Revision 1.3 2009/09/29 15:40:39 eric ... Revision 1.2 2009/09/29 15:31:36 eric ... Revision 1.1 2009/09/29 15:27:28 eric CREATED Revision 1.7 2009/09/01 14:45:46 eric ~ fixed prev version link Revision 1.6 2009/09/01 14:25:51 eric ~ abandoning relative refs to the xmlspec DTD Revision 1.5 2009/09/01 14:22:20 eric ~ trying validating with relative refs to the TR/2008/REC-xml-20081126/xmlspec.dtd DTD Revision 1.4 2009/09/01 14:20:12 eric ~ experimenting with boundries on the CVS log Revision 1.3 2009/09/01 14:15:51 eric + cvs log Revision 1.2 2009/09/01 14:13:54 eric + sections for Subqueries, Negation, Project Expressions