SPARQL Query Language for RDF

Appendices

• A SPARQL Grammar
• B References
• C Change Log

See also:

• The protocol document
• XML result format
• DAWG Test Cases
• Slide set

Issues

DAWG issues list

@@Ensure markup around examples enables XSLT extraction. Do this when document is TOC-stable, to combine with labeling everything.

@@Matching is on a graph from a dataset.

@@Query Results XML Format uses a namespace that may not be final.

1 Introduction

An RDF graph is a set of triples, e. Each triple consistings of a subject, a predicate and an object, as defined in RDF Concepts and Abstract sSyntax. These triples can come from a variety of sources. For instance, they may come directly from an RDF document. They may be inferred from other RDF triples. They may be the RDF expression of data stored in other formats, such as XML or relational databases.

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

• extract information in the form of URIs, blank nodes, plain and typed literals.
• extract RDF subgraphs.
• construct new RDF graphs based on information in the queried graphs.
• Why not say something here about ASK too?

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

1.1 Document Conventions

In this document, examples may [may or do assume?] assume the following namespace prefix bindings:

@@See if there are any - consider rewriting if a just a few.

2 Making Simple Queries

The SPARQL query language is based on around matching graph patterns. The simplest graph patterns are triple patterns, which are like an RDF triples, except that variables may occur in any combination of but with the possibility of a variable in any of the subject, predicate or object positions. Combining these gives a basic graph patternA basic graph pattern, in which an exact match to a graph is needed to fulfill a pattern, is formed from combining one or more triple patterns., where an exact match to a graph is needed to fulfill a pattern.

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

In this section, we cover simple triple patterns, basic graph patterns, as well as their and the SPARQL syntax related to these.

2.1 Writing a Simple Query

The example below shows a SPARQL query to find the title of a book from the information in angiven RDF graph. The query consists of two parts,: the SELECT clause and the WHERE clause. The SELECT [I don't understand why there are two different SELECTs here: one using the code class, the other using the wasSpan class.]clause identifies the variables of interest to the application[I don't like this "of interest to the application" language. What application? What does it mean for an application to find something "of interest"? How about language like "the SELECT clause lists the variables to appear in the bindings results" or some such?], and the WHERE clause has one triple pattern.

Data:

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

Query:

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

Query Result:

Query Term Syntax

The terms delimited by "<>" are IRI [Note: in a few places below the text reads "a IRI", but I think "an IRI" is preferable.] references [19]. They stand for IRs, either directly, or relative to a base IRI.  IRIs are a generalization of URIs [13]  and are fully compatible with URIs and URLs.

The query terms delimited by double quotes ("") are literals which, following Turtle [15] syntax, are a string, in quotes,(in quotes), an optional language tag, introduced with '@'(introduced with "@"), or an optional datatype IRI, introduced by '^^'(introduced by "^^"). [FWIW, I find this very confusing, as it reads like an explanation of the query, but it's really an explanation of some bits of Turtle syntax. I kept looking back at the query to find the "@" or quoted literal or "^^", none of which are there. Very confusing!]Single quotes ('') are also allowed instead of double quotes.[Huh? Allowed? Allowed where? When? This is also confusing. What relation does it have to the preceding sentence?] As a convenience, integers can be directly written and are interpreted as typed literals of datatype xsd:integer; floating point numbers can also be directly written directly and are interpreted as xsd:double. Boolean values of type xsd:boolean literals can also be written directly as true or false[Here's a third typographical convention, presumably, which has not been explained yet in this document, and about which I haven't the slightest clue, unless I view source and assume a CSS class "token" means "token"].

Variables in SPARQL queries have global scope; [This is really awkward: it is the same variable everywhere in the query that the name is used. How about something like this instead: "Each syntactically identical occurrence of the same variable string is semantically the same variable" That's no good, but something in that direction is more clear that the present text. IMO.] Variables are indicated by '?'; the '?' does not form part of the variable. '$' is an alternative to '?' to help where systems use '?' as a substitution character. In a query, $abc and ?abc are the same variable.

[First, it would be nice to use one quoting style consistently: sometimes the document uses single-quotes ('?' and '$') and sometimes it uses double quotes (above: "<>"). Please pick one and stick with it. Second, mixing explication of with justification for design decisions ("'$' is an alternative to '?' to help where systems use '?' as a substitution character") is, IMO, distracting, unhelpful, and bad form. Third, there are two issues that are conflated here: (1) that variables have global scope, such that every lexical occurrence of a variable is the same variable; (2) that variables can be spelled in two ways: either prefaced by a "?" or prefaced by a "$". For my money, this entire paragraph needs to be rewritten from scratch. Or something.].

Because IRIs can be long and repetitive, SPARQL provides an abbreviation mechanism for IRIS. Prefixes can be defined and a QName-like syntax [14] provides shorter forms. Prefixes may be used anywhere after they are declared; redefining a prefix causes the new definition to be used from that point in the syntax [or "in the query"?]. The base IRI for the resolution of relative IRIs can be explicitly declared with the BASE keyword.

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

Examples of Query Syntax

The following examples are three ways to express the same query:

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

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

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

Prefixes are syntactic: the prefix name does not affect the query, nor do prefix names in queries need to be the same prefixes as used for data. The following query is equivalent to the anyall of the previous ones and will give the same results when applied to the same data.:

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

Data descriptions used in this document

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

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

Result Descriptions used in this document

The term "binding" is used as a descriptive term to refer to a pair of (variable, RDF term). In this document, we illustrate results bindings in results in tabular form.so if If variable x is bound to "Alice" and variable y is bound to "Bob", we show this as:

Not every binding needs to exist in every row of the table. Optional matches and alternative matches may leave some variables unbound.

Results can be returned in RDF, in XML with the SPARQL Variable Binding Results XML Format [16] and also in forms specific to implementation APIs. [Even if so, I don't think this document should say that in this way, here.]

2.2 Initial Definitions

This definition of RDF Term collects together several basic notions from the RDF data model.[This adds nothing to the spec, IMO.]

Note that all IRIs are absolute; they may or may not include a fragment identifier [3987, sec 3.1].  Also note that IRIs include URIs [13] and URLs.  This definition also matches the definition of RDF URI Reference from [12].

Queries can also involve include blank nodes; the blank nodes in a query are disjoint from all blank nodes in the RDF graphs being matched.

Each of these pattern types is defined in sections of this document.

Some of these tuple elements are optionalmay be absent. [Which ones? I don't see the value of mentioning *here* that some may be absent, or optional, without saying which ones. If the next two sentences are meant to tell us that, I don't read them that way, because they talk about elements being *empty*, not being absent, which doesn't seem the same thing at all. If it is the same thing here, then the same word should be used.] The graph pattern may be empty (and absent in the serialized form). The set of solution modifiers may be empty.

2.3 Basic Graph Patterns

The building blocks of queries are triple patterns. Syntactically, SPARQLIn SPARQL's syntax, the triple pattern is a subject, predicate and object. The following triple pattern has a subject variable (the variable book), a predicate of dc:title and an object variable (the variable title).

 ?book dc:title ?title .

Matching a triple pattern to a graph, givesgraph gives bindings between variables and RDF Terms so that the triple pattern, with the variables replaced by the corresponding RDF terms, is a triple of the graph being matched.

In SPARQL, a triple pattern is similar to an RDF triple but with the change that any component can be a query variable.A SPARQL triple pattern is similar to an RDF triple, but any part of the pattern can be a query variable.

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

Any SPARQL triple pattern involvingwith a literal as subject will fail to match on any RDF graph. An RDF graph is a set of RDF triples. In the same way, a SPARQL Basic Graph Pattern is a set of Triple Patterns. [This is incongruous here. It might preface the defn of Basic Graph Pattern, but it would be slightly redundant there. But better there, or not at all, than here.]

2.4 Matching of Basic Graph Patterns

"Pattern Solution" is abbreviated to "Solution" where it is clear to do so. [Are "query result" and "solution" also synonyms? They are used interchangeable herein. Further, this comment really only confuses me. Now every time I see "solution", I wonder if you mean "pattern solution" or are you speaking generically? Shurely it's not worth saving 7 characters a few times?]

For example, the query:

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

has a single triple pattern as the query pattern. It matches a graph of a single triple:

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

with solution:

Note that this means that every variable mentioned in the graph pattern must be in the domain of the solution for a basic graph pattern.

2.5 Examples of Basic Graph Patterns

The SPARQL syntax uses the keyword WHERE to introduce the Query Pattern.

For a basic graph pattern to match, there must be a solution where each of the triple patterns matches with the same solution.

Data:

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

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

There is a blank node [12] in this dataset, identified by _:a. The label is only used within the file for encoding purposes. The label information is not in the RDF graph. No SPARQL query will be able to identify that blank node by the label used in the serialization.

Query:

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

Query Result:

This query contains a basic graph pattern of two triple patterns, each of which must match for the graph pattern to match.

2.6 Multiple Matches

The results of a query are all the ways a query can match the graph being queried. Each result is one solution to the query and there may be zero, one or multiple results to a query.

Data:

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

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

Query:

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

Query Result:

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

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

 _:b foaf:name  "Peter Goodguy" .
 _:b foaf:box   <mailto:peter@example.org> .

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

2.7 Blank Nodes

Blank Nodes and Queries

A blank node can appear in a query pattern. It behaves as a variable, although it can not cannot be mentioned in the query result form or anyplace else in any part of the query other than outside a graph pattern.

Blank nodes in queries are distinct from all blank nodes in the data. A blank node in a graph pattern does not match a blank node in the data by blank node label.

Blank Nodes and Query Results

In the results of queries, tThe presence of blank nodes can be indicated in query results by labels in the serializations of those results. An application or client receiving the results of a queryA consumer of query results can tell that two solutions or two variable bindings differ in blank nodes but this information is only scoped to the results as defined in "SPARQL Variable Binding Results XML Format" or the CONSTRUCT result form.

Data:

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

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

Query:

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

The results above could equally be given with different blank node labels because the labels in the results only indicate whether RDF terms in the solutions were the same or different.

These two results have the same information: the blank nodes used to match the query are different in the two solutions. There is no relation between using _:a in the results and any blank node label in the data graph.

2.8 Other Syntactic Forms

The SPARQL uses a "Turtle-like" syntax for writing syntax for representing basic graph patterns, is Turtle plus with the addition of named variables. There are a number of syntactic forms that abbreviate some common sequences of triplescommon triple sequences. These syntactic forms do not change the meaning of the query.

Predicate-Object Lists

Triple patterns with a common subject can be written so that the subject is only written once, andbut used for more than one triple pattern by employingusing 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 . 

Object Lists

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

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

is the same as writing the triple patterns:

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

Blank Nodes

Blank nodes have labels which are scoped to the query. They are written as "_:a" for a blank node with label "a".

A blank node that is used in only one place in the query syntax [Does this mean used in only one place in the string that represents a particular query?] can be abbreviated with "[]". A unique blank node will be created and used to form the triple pattern.

The "[:p :v]" construct can be used to form a triple patterns with a blank node for its subject.

The following two forms:

[ :p "v" ] .

[] :p "v" .

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

_:b57 :p "v" .

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

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

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

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

RDF Collections

RDF collections can be written in triple patterns using the syntax "(  )". The form "()" is short for an abbreviatio of resource rdf:nil or <http://www.w3.org/1999/02/22-rdf-syntax-ns#nil>.

(1 ?x 3)

is short for:

  _:b0  rdf:first  1 .
  _:b0  rdf:rest   _:b1 .
  _:b1  rdf:first  ?x .
  _:b1  rdf:rest   _:b2 .
  _:b2  rdf:first  3 .
  _:b2  rdf:rest   rdf:nil .

Other

The keyword "a" can be used as a predicate in a triple pattern and is short foran abbreviation of rdf:type.

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

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

3 Working with RDF Literals

An RDF Literal is written in SPARQL as a string containing the lexical form of the literal, delimited by "", followed by an optional language tag (indicted by '@') or optional datatype (indicated by '^^')[Why aren't these "@" and "^^"? More to the point, since all of this query syntax is explained, in detail, here, what purpose does 2.1's Query Term Syntax section serve? It would reduce the size of the spec to put a link in that section to this section, with text like: "(Note: for a discussion of query term syntax, please see section @@.)"]. There are convenience forms for numeric-types literals which are of type xsd:integer, xsd:double or  xsd:boolean. There are convenience forms for the xsd:integer, xsd:double, and xsd:boolean literals.

Examples of literal syntax in SPARQL:

• "chat"
• "chat"@fr
• "xyz"^^<http://example.org/ns/userDatatype>
• "abc"^^myNS:myDataType
• 1, which is the same as "1"^^xsd:integer
• 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

3.1 Matching RDF Literals

The data below contains a number of RDF literals:

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

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

Matching Integers

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

SELECT ?v WHERE { ?v ?p 42 }

Matching Arbitrary Datatypes

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

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

Matching Language Tags

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

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

but this does find a solution :z:

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

3.2 Value Constraints

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

Data:

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

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

Query:

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

Query Result:

By having a constraint on the "price" variable, only book2 matches the query because there is a restriction on the allowable values of "price".

Constraints may be restrictions of the value of an RDF Term or they may be restrictions on some part of an RDF term, such as its lexical form. SPARQL defines a set of functions & operations (sections 11.1 and 11.2) that all implementations must provide. In addition, there is an extension mechanism (section 11.3) for operations that are specific to an application domain or kind of data.

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

• Open: whether to allow "foo"@?v or ?v@fr or ?v^^xsd:integer or "foo"^^?v
  One way to address this is to allow expressions in SELECT

  [Is this still an open issue?]

4 Graph Patterns

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

• Basic Graph Patterns
• Group Pattern, where a set of graph patterns must all match
• Value constraints, which restrict RDF terms in a solution
• Optional graph patterns, where additional patterns may extend the solution
• Alternative graph pattern, where two or more possible patterns are tried
• Patterns on Named Graphs, where patterns are matched against named graphs

4.1 Group Graph Patterns

Syntactically, A group graph pattern is syntactically delimited with braces: {}.

For any solution, the same variable is given the same value everywhere in the set of graph patterns making up the group graph pattern. A Basic Graph Pattern is, as described above, a group of triple patterns. For example, this query has a group pattern of one basic graph pattern as the query pattern.

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

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

Because a solution to a group graph pattern is a solution to each element of the group, and a solution of a basic graph pattern is a solution to each triple pattern, these queries also have the same solutions as:

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

using the abbreviation for a common subject between triple patterns.

4.2 Unbound variables

Solutions to graph patterns do not necessarily have to have every variable bound in every solution that causes a graph pattern to be matched. In particular, the OPTIONAL and UNION graph patterns can lead to query results where a variable may be bound in some solutions, but not in others.

4.3 Order of Evaluation

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

5 Including Optional Values

Basic graph patterns allow applications to make queries where the whole of theentire query pattern must match for there to be a solution. For every solution of the query, every variable is bound to an RDF Term in a pattern solution. But RDF is semi-structured: so a regular, complete structure can notcannot be assumed. and iIt is useful to be able to have queries that allow information to be added to the solution where the information is available, but not to have the solution rejected just because that part [Which part? Strike "that"?] of the query pattern does not match. Optional matching provides this facility; if the optional part does not lead to any solutions, variables can be left unbound.

5.1 Optional Pattern Matching

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

OPTIONAL { ?s ?p ?o }

Data:

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

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

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

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

With the data above, the query result is:

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

This query finds the names of people in the data., and, iIf there is a triple with predicate mbox and same subject, it retrieves ["binds" or "matches" better than "retrieves" here?] the object of that triple as well. In the example, only a single triple pattern is given in the optional match part of the query but, in general, it is any graph pattern. The whole graph pattern of an optional graph pattern must match for the optional graph pattern to add to the query solution.

5.2 Constraints in Optional Pattern Matching

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

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

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

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

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.

5.3 Multiple Optional Graph Patterns

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

Data:

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

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

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

Query:

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

Query result:

5.4 Optional Matching: – Formal Definition

In an optional match, either an additional graph pattern matches a graph and so defines one or more pattern solutions,  or gives an empty pattern solution but does not cause matching to fail overall, leaving existing solutions in the query results.In an optional match, either an additional graph pattern matches a graph, thereby defining one or more pattern solutions; or it gives an empty pattern solution, leaving existing solutions in the query results, but does not thereby cause matching to fail overall.

5.5 Nested Optional Graph Patterns

Optional patterns can occur inside any group graph pattern, including a group graph pattern which itself is optional, forming a nested pattern. The outer optional graph pattern must match for any nested one [One what? a graph pattern? an optional graph pattern?] to be matched.

Data:

@prefix foaf:       <http://xmlns.com/foaf/0.1/> .
@prefix rdf:        <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs:       <http://www.w3.org/2000/01/rdf-schema#> .
@prefix vcard:      <http://www.w3.org/2001/vcard-rdf/3.0#> .
 
_:a  foaf:name     "Alice" .
_:a  foaf:mbox     <mailto:alice@work.example> .
_:a  vcard:N       _:x .

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

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

_:z  vcard:Family  "Hacker" .

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

_:y  vcard:Given   "Eleanor" .

Query:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX vcard: <http://www.w3.org/2001/vcard-rdf/3.0#>
SELECT ?foafName ?mbox ?gname ?fname
WHERE
  {  ?x foaf:name ?foafName .
     OPTIONAL { ?x foaf:mbox ?mbox } .
     OPTIONAL {  ?x vcard:N ?vc .
                 ?vc vcard:Given ?gname .
                 OPTIONAL { ?vc vcard:Family ?fname }
              }
  }

Query result:

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

By nesting the optional access [I don't understand this use of "access".] to vcard:Family, the query only reaches these if there is a vcard:N predicate. It is possible to expand out optional graph patterns to remove nesting at the cost of duplication of expressions. [I don't understand the point of this sentence here; is it implementation advice? Or is it a suggestion for how a user might write equivalent queries without nesting?] Here, the expression is a simple triple pattern on vcard:N but it could be a complex graph pattern with value constraints.

6 Matching Alternatives

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

6.1 Joining Patterns with UNION

The UNION keyword is the syntax for pattern alternatives.

Data:

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

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

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

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

Query:

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

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

Query result:

This query finds titles of the books in the data, whether the title is recorded using Dublin Core properties from version 1.0 or version 1.1. If the application wishes to know how exactly the information was recorded, then the query:

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

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

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

• The working group decided on this design and closed the disjunction issue without reaching consensus. The objection was that adding UNION would complicate implementation and discourage adoption. If you have input to this aspect of the SPARQL that the working group has not yet considered, please send a comment to public-rdf-dawg-comments@w3.org.

The UNION operator combines graph patterns, and syntactically[I don't understand what work "syntactically" is supposed to do here.] group graph patterns, so more than one triple pattern can be given in each alternative possibility:

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

SELECT ?title ?author
WHERE  { { ?book dc10:title ?title .  ?book dc10:creator ?author }
         UNION
         { ?book dc11:title ?title .  ?book dc11:creator ?author }
       }

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

6.2 Union Matching – Formal Definition

Query results involving a pattern containing GP1 and GP2,GP2 will include separate solutions for each match where GP1 and GP2 give rise to different sets of bindings.

7 RDF Dataset

The RDF data model expresses information as graphs, comprising of triples with subject, predicate and object. Many RDF data stores hold multiple RDF graphs,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 madeexecuted against an RDF Dataset which may represents such a collection of graphs [Is one graph "such a collection of graphs"?]. Different parts of the query are may be matched against different graphs as described in the next section. There is one graph, the default graph, which does not have a name, and zero or more named graphs, each identified by IRI.

In the previous sections, all queries have been shown executed against a single, default graph. A query does not need to involvebe executed against the default graph; the query can just involvemay be executed against the named graphs. [Has this been synched up with the design of fromUnionQuery we decided on Tuesday? I'm not sure it's consistent with that design.]

@@Need not have a default graph.

7.1 Examples of RDF Datasets

The definition of RDF Dataset does not restrict the relationships of named and default graphs. Two useful arrangements are:

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

Example 1:

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

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

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

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

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

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

In this example, the default graph contains the publisher names of two named graphs [I don't know what is meant by "the publisher names of two named graphs"...]. The triples in the named graphs are not visible in the default graphand, thought of as the default knowledge base, the application is not directly trusting the information in the named graphs.

Example 2:

RDF data can be combined by RDF merge of graphs so that the default graph can be made to include the RDF merge of some or all of the information in the named graphs. Because this information is now being published without qualification, and a query application accepts as coming from the publisher, not just from a source (a named graph) that the publisher incorporated.[I cannot parse this sentence sufficient to offer more perspicuous replacement text.]

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

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

[I see very little value in this section. I won't request, at this stage, that it be struck entirely, but I think it's a good idea. At the very least, there are three or four problematic sentences or phrases that need to be reworked or struck.]

8 Querying the Dataset

When querying a collection of graphs, the GRAPH keyword allows access to the IRIs naming the graphs in the RDF Dataset, or restricts a graph pattern to be applied to a specific named graph.

The following two graphs will be used in examples:

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

8.1 Accessing Graph Names

Access to the graph names of the collection of graphs being queried is by variable in the GRAPH clause. [This would benefit, I think, from being de-passive-voice'ified...Sorry, but I failed to come up with a suggested rewrite. It's a very awkward sentence.]

The query below matches the graph pattern on each of the named graphs in the dataset and forms solutions which have the src variable bound to IRIs of the graph being matched. The pattern part of the GRAPH only matched triples in a single named graph in the same way that a graph pattern matches the default graph when there is no GRAPH clause being applied. [Sorry, no replacement text here, either, but I find this paragraph difficult to parse. I had to read it three times, slowly.]

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

SELECT ?src ?bobNick
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:

8.2 Restricting by Graph IRI

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

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

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

which yields a single solution:

8.3 Restricting by Bound Variables

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

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

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

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

8.4 Named and Default Graphs

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

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

RDF Dataset:

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

<urn:x-local:graph1> dc:publisher "Bob" .
<urn:x-local:graph1> dc:date "2004-12-06"^^xsd:date .

<urn:x-local:graph2> dc:publisher "Bob" .
<urn:x-local:graph2> dc:date "2005-01-10"^^xsd:date .

# Graph: locally allocated 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 IRI for the date datatype has been abbreviated in the results for clarity.

8.5 Definition for GRAPH

9 Specifying RDF Datasets

A SPARQL query may specify the dataset against which it is to be executed for the query.  The FROM clause gives an IRI that the query processor can use to create the default graph and the FROM NAMED clause can be used to specify named graphs. [Is this text consisetent with grammar productions 9 and 10? Are they consistent with the recent decision to allow multiple FROMs? Consider this merely a reminder. :)]

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

@@Add text to say that specifying the dataset overrides an service dataset.

@@ Text from DanC:

The FROM and FROM NAMED keywords allow a query to specify an RDF dataset by reference; they indicate that the dataset should include graphs that are obtained from representations of the resources identified by the given IRIs (i.e. the absolute form of the given IRI references). The dataset resulting from a number of FROM and FROM NAMED clauses is
- a default graph consisting of the merge of the graphs referred to in the FROM clauses
- a set of (IRI, graph) pairs, one from each FROM NAMED clause.

9.1 Specifying the Default Graph

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

@@Change to allowing multiple FROM's meaning merge into default graph

In this first example, there is a single default graph:

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

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

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

9.2 Specifying Named Graphs

A query can supply IRIs for the named graphs in the RDF Dataset using the FROM NAMED clause.  Each IRI is used to provide one, one named graph in the RDF Dataset.

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

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

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

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

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

SELECT ?src ?name

FROM NAMED <http://example.org/alice>
FROM NAMED <http://example.org/bob> 

WHERE
{ GRAPH ?src { ?x foaf:name ?name } }

@@Text from DanC:

 NOTE: The "FROM NAMED" syntax suggests that the IRI identifies the corresponding graph, but actually the relationship between a URI and a graph in an RDF dataset is indirect: the IRI identifies a resource, and the resource is represented by a graph (or, more precisely: by a document that serializes a graph). See also the diagram in section "1. Introduction" of [webarch].

http://www.w3.org/TR/webarch/#intro

9.3 Combining FROM and FROM NAMED

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

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

Here, we extractThis query finds the mbox together with the information in the default graph about the publisher. <dft2.ttl> is just the location of the default graph, not it's name.

10 Query Result Forms

SPARQL has a number offour query formsresult forms for returning results. These resultquery 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.

DESCRIBE

Returns an RDF graph that describes the resources found.

ASK

Returns a boolean indicating whether a query pattern matches or not.

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

10.1 Solution Sequences and Result Forms

Query patterns generate a set of solutions, each solution being a function from variables to RDF terms. These solutions are treated as a sequence. A number of sequence modifiers are [I think "may be" might be better than "are" here?] applied before the solutions are used to form the final query result.

The elements of a sequence of solutions can be modified with modifiersby:

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

The effect of applying these controls is as if they are applied in the order given.

Projection

The solution sequence can be transformed to one only involving 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.

DISTINCT

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

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

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

_:z    foaf:name   "Alice" .
_:z    foaf:mbox   <mailto:smith@work> .

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

If DISTINCT and LIMIT/OFFSET [The "/" can be read in two ways: as "and" and as "or". I assume you mean "or"? I'd replace it with "and" or "or" rather than "/", which is vague.] are specified, then duplicates are eliminated before the limit or offset is applied.

ORDER BY

The ORDER BY clause takes a solution sequence and applies ordering conditions. An ordering condition can be a variable or a function call. The direction of ordering is ascending by default. It can be explicitly set to ascending or descending by enclosing the condition in ASC[] or DESC[] respectively. If multiple conditions are given, then they are applied in turn until one gives the indication of the ordering.

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

SELECT ?name
WHERE { ?x foaf:name ?name }
ORDER BY ?name

PREFIX     :    <http://example.org/ns#>
PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
PREFIX xsd:     <http://www.w3.org/2001/XMLSchema#>     

SELECT ?name
WHERE { ?x foaf:name ?name ; :empId ?emp }
ORDER BY DESC[?emp]

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

SELECT ?name
WHERE { ?x foaf:name ?name ; :empId ?emp }
ORDER BY ?name DESC[?emp]

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

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

If the ordering condition is a named variable, RDF Literals are compared with the "<" operator (see below)[How about linking '"<" operator' to the "see below" location?] where possible. SPARQL defines andefines a fixed, arbitrary order between some kinds of RDF terms that would not otherwise be ordered. This arbitrary order is necessary to provide slicing of query solutions by use of LIMIT and OFFSET.

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

If the ordering criteria do not specify the order of values, then the ordering in the solution sequence is undefined. However, an implementation must consistently impose the same order so that applying LIMIT/OFFSET[LIMIT or OFFSET? LIMIT and OFFSET?] will not miss any solutions.

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

LIMIT

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

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

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

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

OFFSET

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

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

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

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

10.2 Selecting Variables

The SELECT form of results returns the variables directly. The syntax SELECT * is shorthand for an abbreviation "select all the named variables"that selects all of the named variables.

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

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

_:b    foaf:name   "Bob" .

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

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

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

Result sets can be accessed by the local API but also can be serialized into either XML or an RDF graph[I request this be removed, as there is no other mention of this anywhere in our specs, nor is there any specification of what this RDF graph might look like.]. The Query Results XML Format [Use the full form of the title here]form of this result set gives:

<?xml version="1.0"?>
<sparql
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:xs="http://www.w3.org/2001/XMLSchema#"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.w3.org/2001/sw/DataAccess/rf1/result2.xsd"
    xmlns="http://www.w3.org/2001/sw/DataAccess/rf1/result2" >
  <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>
      <binding name="nickY">
        <unbound/>
      </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>

10.3 Constructing an Output Graph

The CONSTRUCT result form returns a single RDF graph specified by a graph template. The result is an RDF graph formed by taking each query solution in the solution sequence, substituting for the variables into the graph template, and combining the triples into a single RDF graph by set union.

If any such instantiation produces a triple containing an unbound variable, or an illegal RDF construct (such as a literal in subject or predicate position)position), then that triple is not included in the RDF graph, and a warning may be generated.[Do we have a suitable warning in the protocol spec? If not, I think we need one, and there should be a pointer here to it.]

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

Templates with Blank Nodes

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

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

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

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

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

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

The use of variable ?x in the template, which in this example will be bound to blank nodes (which have labels _:a and _:b in the data) and cause different blank node labels (_:v1 and _:v2) as shown by the results.[As written, this is a sentence fragment or incomplete sentence. It's missing a main verb. Not sure about replacement text because I'm not sure what was intended.]

Accessing Graphs in the RDF Dataset

Using CONSTRUCT it is possible to extract parts of, or the whole of,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/myGraph otherwise; otherwise, it returns an empty graph.

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

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

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

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

10.4 Descriptions of Resources

The DESCRIBE form returns a single result RDF graph containing RDF data about resources. This data is not prescribed by a SPARQL query, where the query client would need to know the structure of the RDF in the data source, but, instead, is determined by the SPARQL query processor.

The query pattern is used to create a result set. The DESCRIBE form takes each of the resources identified in a solution, together with any resources directly named by IRI, and assembles a single RDF graph by taking a "description" from the target knowledge base. The description is determined by the query processor implementation and should provide a useful description of the resource, where the meaning of"useful" is left to nature of the information in the data sourcedetermined by the query processor, the knowledge base, or other domain-specific information.

If a data source,source has no information about a resource, no RDF triples are added to the result graph but the query does not fail.

• The working group adopted DESCRIBE without reaching consensus. The objection was that the expectations around DESCRIBE are very different from CONSTRUCT and SELECT, and hence it should be specified in a separate query language. If you have input to this aspect of the SPARQL that the working group has not yet considered, please send a comment to public-rdf-dawg-comments@w3.org.

Explicit IRIs

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

DESCRIBE <http://example.org/>

Identifying Resources

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

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

The property foaf:mbox is defined as being an inverse function property in the FOAF vocabulary so, if; 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}

Descriptions of Resources

The RDF returned is the choice of thedetermined by the deployment and may be dependent on the query processor implementation, data source and local configuration.  It should be the useful information the server has (within security matters outside of SPARQL) [Instead, how about a link to the privacy/security section of the protocol spec?] about a resource. It may include information about other resources: the RDF data for a book may also include details ofabout the author.

A simple query such as

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

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

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

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

foaf:mbox_sha1sum  rdf:type  owl:InverseFunctionalProperty .

which includes the blank node closure for the vcard vocabulary vcard:N. For a vocabulary such as FOAF, where the resources are typically blank nodes, returning sufficient information to identify a node such as the InverseFunctionalProperty foaf:mbox_sha1sum as well information which as name and other details recorded would be appropriate. In the example, the match to the WHERE clause was returned but this is not required.

10.5 Asking "yes or no" boolean questions

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

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

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

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

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

yes

The Query Results XML Format [Full form of title...]form of this result set gives:

<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2001/sw/DataAccess/rf1/result2">
  <head></head>
  <results>
    <boolean>true</boolean>
  </results>
</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

11 Testing Values

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

SPARQL expressions are constructed according to the grammar and provide access to named functions and syntactically constructed operations. The operands of these functions and operators are the subset of XML Schema DataTypes {xsd:string, xsd:decimal, xsd:double, xsd:dateTime} and types derived from xsd:decimal. The SPARQL operations are listed in table 11.1 and are associated with their productions in the grammar. In addition, SPARQL imports a subset of the XPath casting functions, listed in table 11.2, which are invokable by name within a SPARQL query. These functions and operators are taken from the XQuery 1.0 and XPath 2.0 Functions and Operators [17].

As described above, RDF Terms are made of IRIs (@@ which match the RDF definition of a URI Reference @@), Literals and Blank Nodes. RDF Literals may have datatypes in the instance data:

@prefix a:          <http://www.w3.org/2000/10/annotation-ns#> .
@prefix dc:         <http://purl.org/dc/elements/1.1/> .

_:a   a:annotates   <http://www.w3.org/TR/rdf-sparql-query/> .
_:a   dc:date       "2004-12-31T19:00:00-05:00" .

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

The first dc:date arc [No replacement text, but arc should either be defined, or a link to a definition should be given, or self-explanatory text should be used.] has no type information. The second is tagged with the type xsd:dateTime. SPARQL operators 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 }

A significant amount of RDF data has untyped literals. Literals may be cast to typed literals to use the SPARQL operators.

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

Namespaces:

The namespace for XPath functions that are directly available by name is http://www.w3.org/2004/07/xpath-functions. The associated namespace prefix used in this document is fn:. XPath operators are named with the prefix op:, XML Schema datatypes with the prefix op:, and types of RDF terms with the prefix r:. SPARQL operators are named with the prefix sop:.

11.1 Operand Data Types

SPARQL defines a subset of the XPath functions and operators with operands of the following XML Schema datatypes:

1. xs:string
2. xs:double
3. xs:float
4. xs:decimal
5. xs:integer
6. xs:dateTime

In addition, SPARQL introduces additional operators which operate on RDF terms. RDF terms are identified by r:term and the constituant subclasses:

• r:IRI
• r:Literal
• r:bNode

11.1.1 Type Promotion

XPath defines a set of Numeric Type Promotions. Numeric operators are defined for the following three primitive XML Schema numeric types:

• xs:double
• xs:float
• xs:decimal

These invoke XQuery's numeric type promotion to cast function arguments to the appropriate type. In summary: each of the numeric types is promoted to any type earlier in the above ordered list when used as an argument to function expecting that higher type. When an argument is promoted, the value is cast to the expected type. For instance, a "7"^^xs:decimal will be converted to an "7.0E0"^^xs:double when passed to an argument expecting an xs:double. Promotion does not change the bindings of variables.

The operators defined below that take numeric arguments expect all arguments to be the same type. This is accomplished by promoting the argument with the lower type to the same type as the other argument. For example, "7"^^xs:decimal + "6.5"^^xs:float would call op:numeric-add("7"^^xs:float, "6.5"^^xs:float). In addition, any r:Literal may be cast to xs:string or xs:numeric when used as an argument to an operator expecting that type.

XML Schema [] defines a set of types derived from decimal: integer; nonPositiveInteger; negativeInteger; long; int; short; byte; nonNegativeInteger; unsignedLong; unsignedInt; unsignedShort; unsignedByte and positiveInteger. These are all treated as decimals for arithmetic operations in FILTERs. SPARQL does not specifically require integrity checks on derived subtypes. SPARQL has no numeric type test operators so the distinction between a primitive type and a type derived from that primitive type is unobservable.

11.2 SPARQL Functions and Operators

SPARQL provides a subset of the functions and operators defined by XQuery Operator Mapping. XQuery 1.0 section 2.2.3 Expression Processing describes the invocation of XPath functions. The following rules accommodate the differences in the data and execution models between XQuery and SPARQL:

• Unlike XPath/XQuery, SPARQL functions do not process node sequences. When interpreting the semantics of XPath functions, assume that each argument is a sequence of a single node.
• Functions invoked with an argument of the wrong type will produce a type error.
• Any expression other than value disjunction (||) that encounters a type error will produce a type error.
• A value disjunction that encounters a type error on only one branch will return the result of evaluating the other branch.
• A value disjunction that encounters type errors on both branches will produce a type error.

11.2.1 Invocation

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

• Arguments expressions are evaluated, producing argument values. The order of argument evaluation is not defined.
• For functions and operators where the result type is specified as xs:boolean, the effective boolean value (defined in section 11.2.1.1) is calculated.
• Numeric arguments are promoted as necessary to fit the expected types for that function or operator.
• The function or operator is invoked on the argument values.

If any of these steps fails, the invocation generates an error. The effects of type errors are defined in SPARQL Functions and Operators.

11.2.1.1 Effective Boolean Value

When a operand is coerced to xs:boolean through invoking a function that takes a xs:boolean argument, the following rules apply:

The result is TRUE unless any of the following are true:

• The operand is unbound.
• The operand is an xs:boolean with a FALSE value.
• The operand is a 0-length untyped RDF literal or xs:string.
• The operand is any numeric type with a value of 0.
• The operand is an xs:double or xs:float with a value of NaN

Table 11.1 Operator Mapping

The SPARQL grammar identifies a set of operators (for instance, &&, *, isURI) used to construct constraints. The following table associates each of these grammatical productions with an operator defined by either the XQuery Operator Mapping or the additional SPARQL operators specified in section 11.2.2.

Some of the operators are 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 return an error if their argument is an error.

^† fn:string-match requires a collation to define character order and string equivalence. The XQuery 1.0 and XPath 2.0 Functions and Operators [F&O] defines the semantics of fn:string-compare and establishes a default collation. In addition, it identifies a specific collation with a distinguished name, http://www.w3.org/2004/10/xpath-functions/collation/codepoint which provides the ability to compare strings based on code point values. Every implementation of SPARQL must support the collation based on code point values.

11.2.3 Operators introduced in SPARQL

This section defines the operators introduced by the SPARQL Query language. The names of the operators are prefixed with sop:. The examples show the behavior of the operators as invoked by the appropriate grammatical constructs.

11.2.3.1 sop:RDFterm-equal

Returns TRUE if the two arguments are the same RDF term or if they are literals known to have the same value. The latter is tested with an XQuery function appropriate to the arguments.

The following sop:RDFterm-equal example passes the test because the mbox terms are the same RDF term:

 ?u = ?v

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

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

_:b  foaf:name       "Ms A.".
_:b  foaf:mbox       <mailto:alice@work.example> .

This query finds the people who have multiple foaf:name arcs:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name1 ?name2
 WHERE { ?x foaf:name  ?name1 ;
            foaf:mbox  ?mbox1 .
         ?y foaf:name  ?name2 ;
            foaf:mbox  ?mbox2 .
         FILTER ?mbox1 = ?mbox2 && ?name1 != ?name2
       }

Query result:

In this query for documents that were annotated on new years day (2004 or 2005), the RDF terms are not the same, but have equivalent values:

@prefix a:          <http://www.w3.org/2000/10/annotation-ns#> .
@prefix dc:         <http://purl.org/dc/elements/1.1/> .

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

PREFIX a:      <http://www.w3.org/2000/10/annotation-ns#>
PREFIX dc:     <http://purl.org/dc/elements/1.1/>
PREFIX xsd:    <http://www.w3.org/2001/XMLSchema#>

SELECT ?annotates
WHERE { ?annot  a:annotates  ?annotates .
        ?annot  dc:date      ?date .
        FILTER ?date = xsd:dateTime("2004-01-01T00:00:00Z") || ?date = xsd:dateTime("2005-01-01T00:00:00Z") }

11.2.3.2 sop:bound

Queries with union and optionals may have solutions with some unbound variables. The operator bound tests if a variable has been bound to a value. Variables with the value NaN or INF are considered bound.

 bound(?v)

Data:

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

_:a  foaf:givenName  "Alice".

_:b  foaf:givenName  "Bob" .
_:b  dc:date         "2005-04-04T04:04:04Z"^^xs:dateTime .

This query finds the people with a dc:date property:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dc:   <http://purl.org/dc/elements/1.1/>
PREFIX xsd:   <http://www.w3.org/2001/XMLSchema#>
SELECT ?name ?givenName
 WHERE { ?x foaf:givenName  ?name .
         OPTIONANL { ?x dc:date ?date } .
         FILTER bound(?date)) }

Query result:

One may test that a graph pattern is not expressed by specifying an optional graph pattern that introduces a variable and testing to see that the variable is not bound. This is called Negation as Failure in logic programming.

This query matches the people with a name but no expressed date:

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

Query result:

Because Alice's mbox was known, "Alice" was not a solution to the query.

11.2.3.3 sop:isURI

Returns whether a variable is bound to a URI.

 isURI(?v)

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

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

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

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

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

Query result:

11.2.3.4 sop:isBlank

Returns whether a variable is bound to a blank node.

 isBlank(?v)

@prefix a:          <http://www.w3.org/2000/10/annotation-ns#> .
@prefix dc:         <http://purl.org/dc/elements/1.1/> .
@prefix foaf:       <http://xmlns.com/foaf/0.1/> .

_:a   a:annotates   <http://www.w3.org/TR/rdf-sparql-query/> .
_:a   dc:creator    "Alice B. Toeclips" .

_:b   a:annotates   <http://www.w3.org/TR/rdf-sparql-query/> .
_:b   dc:creator    _:c .
_:c   foaf:given    "Bob".
_:c   foaf:family   "Smith".

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

PREFIX a:      <http://www.w3.org/2000/10/annotation-ns#>
PREFIX dc:     <http://purl.org/dc/elements/1.1/>
PREFIX foaf:   <http://xmlns.com/foaf/0.1/>

SELECT ?given ?family
 WHERE { ?annot  a:annotates  <http://www.w3.org/TR/rdf-sparql-query/> .
         ?annot  dc:creator   ?c .
         OPTIONAL { ?c  foaf:given   ?given ; foaf:family  ?family } .
         FILTER isBlank(?c)
       }

Query result:

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

11.2.3.5 sop:isLiteral

Returns whether the argument is a literal.

 isLiteral(?v)

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

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

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

This query is similar to the one in 1.2.1.3 except that is matches the people with a name and an mbox which is a Literal. This could be used to look for erroneous data (foaf:mbox should only have a URI as its object).

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

Query result:

11.2.3.6 sop:str

Returns an xs:string representation of an r:IRI. This is useful for examining parts of a URI, for instance, the host-name.

 str(?v)

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

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

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

This query selects the set of people who use their work.example address in their foaf profile:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name ?mbox
 WHERE { ?x foaf:name  ?name ;
            foaf:mbox  ?mbox .
         FILTER regex(str(?mbox), "@work.example") }

Query result:

11.2.3.7 sop:lang

Returns a valid RFC 3066 language string representing the XML schema language datatype for a variable.

 lang(?v)

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

_:a  foaf:name       "Robert"@EN.
_:a  foaf:name       "Roberto"@ES.
_:a  foaf:mbox       <mailto:bob@work.example> .

This query finds the Spanish foaf:name and foaf:mbox:

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

Query result:

11.2.3.8 sop:datatype

Returns the datatype of its argument if that argument is a typed literal. Otherwise it fails.

 datatype(?v)

@prefix foaf:       <http://xmlns.com/foaf/0.1/> .
@prefix eg:         <http://biometrics.example/ns#> .
@prefix xsd:        <http://www.w3.org/2001/XMLSchema#> .

_:a  foaf:name       "alice".
_:a  eg:shoeSize     "9.5"^^xsd:float .

_:b  foaf:name       "bob".
_:b  eg:shoeSize     "42"^^xsd:integer .

This query finds everyone's foaf:name and integer foaf:shoeSize:

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

Query result:

11.2.3.9 sop:logical-or

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

 ?u || ?v

11.2.3.10 sop:logical-and

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

 ?u && ?v

Table 11.2 SPARQL Casting Functions

SPARQL imports casting functions from the XPath. The XQuery Functions & Operators Primitive Type Mapping table [17] specifies a which primitive types are castable to which other primitive types. The table is reproduced below, omitting casting operations that are not in the SPARQL language, and adding the additional datatypes imposed by the RDF data model.

bool = xs:boolean
dbl = xs:double
flt = xs:float
dec = xs:decimal
int = xs:integer
dT = xs:dateTime
str = xs:string
IRI = r:IRI — introduced by the RDF data model
ltrl = r:Literal — introduced by the RDF data model

11.2.4 Extensible Value Testing

An expression can also be a function call to an extension function. A function is named by an IRI, and returns an RDF term. The semantics of these functions are identified by the IRI identifying the function.

If a query request contains a function that it is not supported, the query is not executed and an error is returned.

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

Syntax:

x:qname( expression, expression , ...)

Examples:

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

PREFIX myGeo: <http://my.example.org/geo#>

SELECT ?x ?y
WHERE { ?x myGeo:placeName "SWEB Town" .
        ?x myGeo:location ?xLoc .
        ?y myGeo:location ?yLoc .
        FILTER myGeo:distance(?x, ?y) < 10 . 
      }

A function returns an RDF term.  It might be used to test some application datatype not supported by the core SPARQL specification, it might be a transformation between datatype formats, for example into an XSD dateTime RDF term from another date format.

A. SPARQL Grammar

A SPARQL query string is a sequence of characters in the language defined by the following grammar, starting with the Query production. The EBNF format is the same as that used in the XML 1.1 specification. Please see the "Notation" section of that specification for specific information about the notation.

Whitespace

Whitespace is used to separate two terminals which would otherwise be (mis-)recognized as one terminals.  Whitespace in terminals is significant. Otherwise whitespace is ignored. Terminals are shown below enclosed in <> or shown in-line.

Keywords

Keywords are shown in uppercase but are matched in a case-insensitive manner.

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

Comments

Comments in SPARQL queries take the form of '#', outside a IRI or string, and continue to the end of line or end of file if there is no end of line after the comment marker.

Grammar

C. Change Log

Changes since the 19 Apr 2005 Working Draft:

 
$Log: Overview.html,v $
Revision 1.377  2005/06/08 10:02:30  eric
note that i'm not sure about the best definition of an IRI

Revision 1.376  2005/06/08 09:54:36  eric
s/(URIRef|URI)/IRI/ in section 11

Revision 1.375  2005/06/07 19:23:51  connolly
- removed reference to the WG from the abstract
- truncated the changelog to show just diffs
  since last WD (19 Apr)

Revision 1.374  2005/06/07 19:09:10  connolly
- linked to extracted definitions from status section

- fixed XML wf problems in grammar section
  by adding space before title attributes

Revision 1.373  2005/06/06 14:45:18  aseaborne
Need to note that there need not be a default graph

Revision 1.372  2005/06/06 11:07:55  aseaborne
+ Changes to use IRIs in SPARQL, not URIs, as per
  2005AprJun/0156
  except for section 11 changes.

+ All " class=wasSpan" removed

Revision 1.371  2005/06/03 18:02:50  aseaborne
+ Added @@ with text from Dan about relationship of URI and graphs
+ Added @@ with text from Dan about use of IRIs for graphs to be
  about graphs obtained from representations.
+ Added @@ for multiple FROMs to mean merge to form the default graph

Revision 1.370  2005/06/02 11:27:25  aseaborne
Corrections in 9.1 from Yoshio.

Revision 1.369  2005/06/01 10:23:39  eric
~ fixing bugs reported by DaveB

Revision 1.368  2005/05/31 22:29:23  connolly
split normative refs from informative refs from acks
formatted refs to W3C tech reports per bib generator

Revision 1.367  2005/05/31 08:31:36  eric
get rid of issue

Revision 1.366  2005/05/31 08:14:57  aseaborne
Grammar mistakes fixed:
+ added \ to literal \ in triple
+ Remove unreferenced rule QueryPatternTail

Revision 1.365  2005/05/31 07:55:24  eric
~making rule markup backslash-consitent

Revision 1.364  2005/05/30 15:24:16  eric
made 11.2.3.2 less stupidly broken

Revision 1.363  2005/05/30 05:00:23  eric
~ s/foaf:age/foaf:nick/
~ minor edits in sections 8 and 9

Revision 1.362  2005/05/30 02:51:06  eric
~ cleaned up FandO table token style
+ added titles to the production references

Revision 1.361  2005/05/30 01:11:38  eric
s/span class="code"/code class="wasSpan"/g

Revision 1.360  2005/05/30 00:25:36  eric
validated and got rid of extraneous comments

Revision 1.359  2005/05/28 03:32:00  eric
simplified style-sheets

Revision 1.358  2005/05/27 11:15:21  aseaborne
Style for grammar table

Revision 1.357  2005/05/27 10:45:02  aseaborne
Text for section 4.2 on noting unbound variables

Revision 1.356  2005/05/27 09:27:20  aseaborne
sync

Revision 1.355  2005/05/27 09:14:32  aseaborne
Gramnmar update

Revision 1.354  2005/05/27 08:50:55  eric
trying different table format

Revision 1.353  2005/05/27 08:49:28  aseaborne
+ Turned section 11.3 into section 11.2.4

Revision 1.352  2005/05/26 16:29:30  aseaborne
+ Added example in section 9.3

Revision 1.351  2005/05/26 15:40:38  aseaborne
Validation corrections

Revision 1.350  2005/05/26 15:38:13  aseaborne
+ Added example in XML result format for ASK
+ Removed some @@ToDo@@'s that had been done or no longer were relevant

Revision 1.349  2005/05/25 14:56:16  aseaborne
+ Definitions for SELECT/CONSTRUCT/DESCRIBE/ASK

Revision 1.348  2005/05/25 14:00:32  eric
addressing Steve's comments starting in #dawg at 2005-05-25T10:27:01Z

Revision 1.347  2005/05/25 13:29:08  eric
s/dc:created/dc:date/g per Steve's observation

Revision 1.346  2005/05/25 06:00:06  eric
pass through DaveB's comments on section 11.

Revision 1.345  2005/05/25 05:00:24  eric
some words on extensibility

Revision 1.344  2005/05/23 12:49:50  aseaborne
Continued editorial changes: sections 8,9,10

+ Section 8
  graph label => graph name or graph URI (depending on context)

Other editorial changes.

Revision 1.341  2005/05/20 12:59:22  aseaborne
+ Trivia: Grammar: Moved parens into definition of
  ArgList so production is not empty.  No change to language.

Revision 1.340  2005/05/20 10:50:36  aseaborne
+ Definitions of sequnce sequnces and modifiers.

Revision 1.339  2005/05/20 09:55:11  aseaborne
+ s/substitution/solution/g
  "Substitution" is more focused on the mechanisms of definition
  "Solution" terminolgy is more focused on the outcome to the application

+ Rewording inconsistent language.

Revision 1.338  2005/05/19 14:33:59  aseaborne
HTML fixing

Revision 1.337  2005/05/19 14:30:43  aseaborne
HTML tidying

Revision 1.336  2005/05/19 14:20:08  aseaborne
Definition editing
  + Graph Pattern: Move list outside defn box
  + Reworded "Query Pattern"
  + Reworded "Query Solution"
  + Reworded "SPARQL Query" to enumerate the tuple
    Carried through to other definitions
  + Reworded "Value constraint" to include "matching"

Formatted all definitions based on <div class="defn">.

Revision 1.335  2005/05/18 13:53:55  aseaborne
+ Definitions
  + Named and unnamed query variables
  + Basic patterns match by entailment (was "subgraph")

Revision 1.334  2005/05/18 13:11:54  aseaborne
+ Editing pass over definitions:
  Rewording prior to review
  Definitions work on the name of the graph pattern, not the name of
  the "matching" operation

+ Added draft definitions for sequence sequence and it's modifiers

+ Changed the working example of a triple pattern match (2.3)

+ Update the XML result example to latest schema

+ Grammar: removed 2 rules which only had a single
  token as their production

+ Removed section 9 ("Ordering") and inserted text in Group Pattern section
  to say that all orders are valid.

Revision 1.333  2005/05/17 16:14:29  aseaborne
+ Change "set" to "tuple" in definition of SPARQL Query
+ Fixing HTML

Revision 1.332  2005/05/16 13:01:03  aseaborne
+ Use "SPARQL Query string" for the grammar
  "SPARQL query" for the abstraction

+ Typo in order section

Revision 1.331  2005/05/13 04:19:09  aseaborne
Fixed TOC headings (5.2/5.3 text was switched)

Revision 1.330  2005/05/06 12:50:45  aseaborne
Grammar update:

+ Removed special case of {}-less QueryPattern
+ VARNAME corrected to NCNAME - "." and "-"
+ Removed some lookahead in SELECT and DISTINCT
+ Changed SelectClause to SelectQuery and moved the clasues into the
  per-query type rule.
  Same for Construct/Describe/Ask
+ s/URI/IRIref/

Revision 1.329  2005/05/04 17:22:30  aseaborne
+ Added definition boxes in sec 10.1
  Content to TBD.
+ s/background graph/default graph/g

Revision 1.328  2005/05/03 12:34:36  aseaborne
+ Comments based on
2005AprJun/0013
  + Def Substitution : reworded
  + Def Restriction: Pattern Insatnce - clarified what happnes when
    a variable is not in the substitution.

Revision 1.327  2005/04/29 14:15:22  aseaborne
Changes based on comments by Bijan Parsia
  + Change to definition of "RDF Term" - moved descriptive reference
    to RDF Data Model to text.
  + Note that set of query variables is infinite.


Other changes:
 + Split 2.2 into basic definitions and basic graph patterns
   + Repaired HTML for Graph Pattern definition.
 + Add definition of "SPARQL query"

Revision 1.326  2005/04/26 13:56:51  aseaborne
+ Fixed grammar (over zealous neating by perl in rules 27 and 50)

Revision 1.325  2005/04/26 13:12:02  aseaborne
+ Fixed markup in grammar

Revision 1.324  2005/04/26 12:39:24  aseaborne
+ Tuning the grammar
   + added long literals
   + qnames have trailing dots (c.f. Turtle)

Revision 1.323  2005/04/25 17:08:06  aseaborne
+ Tuning the grammar

Revision 1.322  2005/04/22 16:58:31  aseaborne
+ Fixed HTML for results in 10.3

Revision 1.321  2005/04/22 15:16:29  aseaborne
+ Removed text-transform in class .token
  and explicit include uppercase in HTML
  (aids searching).

Revision 1.319  2005/04/20 08:28:01  eric
changed back to an editor's draft