SPARQL Query Language for RDF

Appendices

• A SPARQL Grammar
  • A.1 IRI References
  • A.2 White Space
  • A.3 Keywords
  • A.4 A.4 Comments
  • A.5 Escape sequences in strings
  • A.6 Escape sequences in IRI references, prefixed names and variable names
  • A.7 Grammar
• B Conformance
• C Security Considerations
• D Collected Formal Definitions
• E Internet Media Type, File Extension and Macintosh File Type
• F References
• G Acknowledgements
• H Change Log

In addition, the collected formal definitions are collected into a single document "SPARQL Query Language for RDF - Formal Definitions".

1 Introduction

An RDF graph is a set of triples; each triple consists of a subject, a predicate and an object. This is defined in RDF Concepts and Abstract Syntax [CONCEPTS]. 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; or they may be the RDF expression of data stored in other formats, such as XML or relational databases. The RDF graph may be virtual, in that it is not fully materialized, only doing the work needed for each query to execute.

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.

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

1.1 Document Conventions

In this document, examples assume the following namespace prefix bindings unless otherwise stated:

2 Making Simple Queries

The SPARQL query language is based on matching graph patterns. The simplest graph pattern is the triple pattern, which is like an RDF triple, but with the possibility of a variable instead of an RDF term in the subject, predicate or object positions. Combining triple  gives a basic graph pattern, 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 graph patterns can be grouped together; 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.

2.1 Writing a Simple Query

The example below shows a SPARQL query to find the title of a book from the information in the given RDF graph. The query consists of two parts, the SELECT clause and the WHERE clause. The SELECT clause identifies the variables to appear in the query results, and the WHERE clause has one triple pattern.

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

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

2.1.1 Syntax for IRIs

The terms delimited by "<>" are IRI references [RFC3987]. They stand for IRIs, either directly, or relative to a base IRI.  IRIs are a generalization of URIs [RFC3986] and are fully compatible with URIs and URLs.

SPARQL provides a two abbreviation mechanisms for IRIs, prefixed names and relative IRIs.

Prefixed names

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 ":". It is mapped to an IRI by concatenating the local part to the IRI corresponding to the prefix.

Relative IRIs

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

2.1.2 Syntax for Literals

The general syntax for literals is a string (enclosed in quotes, 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 and are interpreted as typed literals of datatype xsd:integer; decimal numbers, where there is '.' in the number but no exponent, are interpreted as xsd:decimal and a number with an exponent is interpreted as an xsd:double. Values of type xsd:boolean can also be written as true or false.

2.1.3 Syntax for Variables

Variables in SPARQL queries have global scope; it is the same variable everywhere in the query that the same name is used. Variables are indicated by "?"; the "?" does not form part of the variable. "$" is an alternative to "?". In a query, $abc and ?abc are the same variable. The possible names for variables are given in the SPARQL grammar.

2.1.4 Syntax for Blank Nodes

A blank node can appear in a query pattern and will take part in the pattern matching.  Blank nodes are indicated by either the form "_:a" or use of "[ ]".  Further syntactic forms involving blank nodes are described below.

2.1.5 Syntax for Triple Patterns

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

2.1.6 Examples of Query Syntax

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 }

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 in a serialization of the data. The following query is equivalent to the previous examples and will give the same results when applied to the same data:

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

2.1.7 Data descriptions used in this document

The data format used in this document is Turtle [TURTLE], 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/> .
:book1  dc:title  "SPARQL Tutorial" .

 ?book dc:title ?title .

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

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

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

2.5 Basic Graph Patterns

A basic graph patterns is a set of triple patterns and forms the basis of SPARQL query matching. Matching a basic graph pattern is defined in terms of generic entailment to allow for future extension of the language.

This specification covers only simple entailment [RDF-MT] as E-entailment. Examples of other E-entailment regimes are RDF entailment [RDF-MT], RDFS entailment [RDF-MT], OWL entailment [OWL-Semantics].

This definition extends that for RDF graph-equivalence to basic graph patterns by preserving variables names across equivalent graphs

2.5.1 General Framework

A scoping set B is some set of RDF terms. The scoping set restricts the values of variable assignments in a solution. The scoping set may be characterized differently by different entailment regimes.

The scoping graph makes the graph to be matched independent of the chosen blank node names.

The same scoping set and scoping graph is used for all basic graph pattern matching in a single SPARQL query request.

The introduction of the basic graph pattern BGP' in the above definition makes the query basic graph pattern independent of the choice of blank node names in the basic graph pattern.

2.5.2 SPARQL Basic Graph Pattern Matching

These definitions allow for future extensions to SPARQL. This document defines SPARQL for simple entailment and the scoping set B is the set of all RDF terms in G'.

When using simple entailment, the operation of querying an RDF graph provides access to the graph structure, up to blank node renaming; nothing that is not already in the graph G needs to be inferred or constructed, even implicitly.

A pattern solution can then be defined as follows: to match a basic graph pattern under simple entailment, it is possible to proceed by finding a mapping from blank nodes and variables in the basic graph pattern to terms in the graph being matched; a pattern solution is then a mapping restricted to just the variables, possibly with blank nodes renamed. Moreover, a uniqueness property guarantees the interoperability between SPARQL systems: given a graph and a basic graph pattern, the set of all the pattern solutions is unique up to blank node renaming.

2.5.3 Example of Basic Graph Pattern Matching

As an example of a Basic Graph Pattern:

Data:

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

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

_:b  foaf:name   "A. N. Other" .
_:b  foaf:mbox   <mailto:other@example.com> .

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

This query contains a basic graph pattern of two triple patterns, each of which must match with the same solution for the graph pattern to match. The pattern solution matching the basic graph pattern maps the variable 'x' to blank node _:a and variable 'mbox' to the IRI mailto:outlaw@example.com. The query only returns the variable'mbox'. 

2.5.4 Basic Graph Patterns in the SPARQL Syntax

In the SPARQL syntax,  Basic Graph Patterns are sequences of triple patterns mixed with value constraints. Other graph patterns separate basic patterns. The two query fragments below each contain the same basic graph pattern of

{ _:x :p ?v . _:x :q ?w . }

with the scope of the blank node label being the basic graph pattern.

{ _:x :p ?v .
  FILTER (?v < 3) .
  _:x :q ?w .
}

{ _:x :p ?v .
  _:x :q ?w .
  FILTER (?v < 3) .
}

2.6 Multiple Matches

The results of a query is the set of all pattern solutions that match the query pattern, giving 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> .

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

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 basic graph pattern match, and all the variables used in the query pattern must be bound in every solution.

2.7 Blank Nodes in Query Results

The presence of blank nodes in query results can be indicated by labels in the serialization of query results.

Blank nodes in the results of a query are identical to those occurring in the dataset graphs, but this information cannot be used by an application or client which receives these results, since all blank nodes in subsequent queries are treated as being local to that query. In effect, this means that information about co-occurrences of blank nodes may be treated as scoped to the results as defined in "SPARQL Variable Binding Results XML Format" or the CONSTRUCT result form.

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

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

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

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

2.8 Other Syntactic Forms

There are a number of syntactic forms that abbreviate some common sequences of triples. These syntactic forms do not change the meaning of the query.

2.8.1 Predicate-Object Lists

Triple patterns with a common subject can be written so that the subject is only written once, and 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 .

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

Note that both the tripe patterns involving foaf:nick will need to match, not that one of the other shodul match.

Object lists can be combined with predicate-object lists:

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

giving:

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

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

is equivalent to the two triples:

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

and as an object:

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

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

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

2.8.4 RDF Collections

RDF collections can be written in triple patterns using the syntax "(  )". The form () is an alternative for the IRI rdf:nil which is  http://www.w3.org/1999/02/22-rdf-syntax-ns#nil. When used with collection elements, such as (1 ?x 3 4), then triple patterns and blank nodes are allocated for the collection and the blank node at the head of the collection can be used as a subject or object in other triple patterns.

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

is a short form for:

    _: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 a short form 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 .

2.8.4 rdf:type

The keyword "a" can be used as a predicate in a triple pattern and is an alternative for the IRI rdf:type which is http://www.w3.org/1999/02/22-rdf-syntax-ns#type.

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

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

2.9 Querying Reification Vocabulary

RDF defines reification vocabulary which provides for describing RDF statements without stating them. These descriptions of statements can be queried by using the defined vocabulary.

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix dc:  <http://purl.org/dc/elements/1.1/> .
@prefix :    <http://example/ns#> .

_:a   rdf:subject   <http://example.org/book/book1> .
_:a   rdf:predicate dc:title .
_:a   rdf:object    "SPARQL" .
_:a   :saidBy       "Alice" .

_:b   rdf:subject   <http://example.org/book/book1> .
_:b   rdf:predicate dc:title .
_:b   rdf:object    "SPARQL Tutorial" .
_:b   :saidBy       "Bob" .

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

SELECT ?book ?title
WHERE
{ ?book dc:title ?title }

PREFIX rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX dc:   <http://purl.org/dc/elements/1.1/>
PREFIX :     <http://example/ns#>

SELECT ?book ?title
WHERE
{ ?t rdf:subject    ?book  .
  ?t rdf:predicate  dc:title .
  ?t rdf:object     ?title .
  ?t :saidBy       " Bob" .
}

3 Working with RDF Literals

An RDF Literal is written in SPARQL as a string containing the lexical form of the literal, followed by an optional language tag or an optional datatype. There are convenience forms for numeric-types literals which are of type xsd:integer, xsd:decimal, xsd:double and also for  xsd:boolean.

Examples of literal syntax in SPARQL include:

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

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 .

SELECT ?v WHERE { ?v ?p 42 }

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

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

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

@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 ns:price ?price .
          FILTER (?price < 30) .
          ?x dc:title ?title . }

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

3.3 Value Constraints – Definition

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. There is a set of functions & operators in SPARQL for constraints. In addition, there is an extension mechanism to provide access to functions that are not defined in the SPARQL language.

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.

3.4 Matching Values and RDF D-entailment

RDF defines D-Entailment where extra semantic conditions are allowed for datatypes. When matching RDF literals in graph patterns, the datatype lexical-to-value mapping may be reflected into the underlying RDF graph, leading to additional matches where it is known that two literals are the same value. RDF semantics does not require this of all RDF graphs.

4 Graph Patterns

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

• Basic Graph Patterns, where a set of triple patterns must match
• Group Graph Pattern, where a set of graph patterns must all match using the same variable substitution
• 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

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

In a SPARQL query string, a group graph pattern is delimited with braces: {}.

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

4.2 Unbound variables

Solutions to graph patterns do not necessarily have to have every variable bound in every solution. SPARQL query patterns are built up from basic patterns which do associate RDF terms with each variable mentioned in the pattern; 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, independently of the order that may be implied by the lexical order of the graph patterns in the group.

5 Including Optional Values

Basic graph patterns allow applications to make queries where entire 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. However, regular, complete structures can not be assumed in all RDF graphs and it is useful to be able to have queries that allow information to be added to the solution where the information is available, but not to have the solution rejected because some part of the query pattern does not match. Optional matching provides this facility; if the optional part does not lead to any solutions, variables can be left unbound.

5.1 Optional Pattern Matching

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

pattern OPTIONAL { pattern }

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

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

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

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

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

This query finds the names of people in the data. If there is a triple with predicate mbox and same subject, a solution will contain 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.

The OPTIONAL keyword is left-associative :

pattern OPTIONAL { pattern } OPTIONAL { pattern }

matches the same as:

{ pattern OPTIONAL { pattern } } OPTIONAL { pattern }

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

5.4 Optional Matching – Formal Definition

In an optional match, either an additional graph pattern matches a graph, thereby defining one or more pattern solutions; or it passes any solutions without adding any additional bindings.

The syntactic form:

{ optional { pattern } }

is defined to be

{ } optional { pattern }

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. Any non-optional part of the outer optional graph pattern must be matched if any solution is given involving matching the nested optional pattern are returned.

The outer optional graph pattern must match for any nested optional pattern to be matched.

@prefix foaf:       <http://xmlns.com/foaf/0.1/> .
@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" .

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

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 finds that as well.

By nesting the optional pattern involving vcard:Family, the query only reaches these if there is a vcard:N predicate. 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.

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

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

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

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 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, 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 such a collection of graphs. Different parts of the query 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 involve the default graph; the query can just involve matching named graphs.

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.

# 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 RDF merge [RDF-MT] 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.

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

8 Querying the Dataset

When querying a collection of graphs, the GRAPH keyword is used to match patterns against named graphs. This is by either using an IRI to select a graph or using a variable to range over the IRIs naming graphs.

The following two graphs will be used in examples:

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

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

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

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

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

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

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

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

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

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

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

SELECT ?mbox ?nick ?ppd
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 an 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, 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:>

g:graph1 dc:publisher "Bob" .
g:graph1 dc:date "2004-12-06"^^xsd:date .

g:graph2 dc:publisher "Bob" .
g:graph2 dc:date "2005-01-10"^^xsd:date .

# Graph: locally allocated IRI: tag:example.org,2005-06-06:graph1
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

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

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

# Graph: locally allocated IRI: tag:example.org,2005-06-06:graph2
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

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

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

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

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

The IRI for the date datatype has been abbreviated in the results for clarity.

9 Specifying RDF Datasets

A SPARQL query may specify the dataset to be used for matching.  The FROM clauses give IRIs that the query processor can use to create the default graph and the FROM NAMED clause can be used to specify named graphs. 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.

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.

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.

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.

9.1 Specifying the Default Graph

The FROM clause contains an IRI that indicates the graph to be used to form 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.

In this example, there is a single default graph:

# Default graph (stored at http://example.org/foaf/aliceFoaf)
@prefix  foaf:  <http://xmlns.com/foaf/0.1/> .

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

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

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.

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

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). For further details see [WEBARCH].

9.3 Combining FROM and FROM NAMED

The FROM clause and FROM NAMED clauses 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 }
}

This query finds the  mbox together with the information in the default graph about the publisher. <http://example.org/dft.ttl> is just the IRI used to form the default graph, not it's name.

10 Query Result Forms

SPARQL has four query result forms. These result forms use the solutions from pattern matching to form result sets or RDF graphs. The query forms are:

SELECT

Returns all, or a subset of, the variables bound in a query pattern match.

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 an unordered collection of solutions, each solution being a function from variables to RDF terms. These solutions are then treated as a 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 SPARQL result forms.

The elements of a sequence of solutions can be modified by:

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.

applied in the order given by the list.

10.1.1 Projection

The solution sequence can be transformed into one involving only a subset of the variables. For each solution in the sequence, a new solution is formed using a specified selection of the variables.

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 }

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

@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 or OFFSET are specified, then duplicates are eliminated before the limit or offset is applied.

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

The "<" operator (see the Operator Mapping) defines the relative order of pairs of numerics, xsd:dateTimes and xsd:strings.

IRIs are ordered by comparing the character strings making up each IRI using the "<" operator.

SPARQL also defines 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 is lower than an RDF literal with type xsd:string of  the same lexical form.

If the ordering criteria do not specify the order of values, then the ordering in the solution sequence is undefined.

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.

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

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

10.2 Selecting Variables

The SELECT form of results returns the variables directly. The syntax SELECT * is an abbreviation that selects all of the 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 }
  }

<?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>
      <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), then that triple is not included in the output RDF graph. The graph template can contain ground or explicit triples, that is, triples with no variables, and these also appear in the output RDF graph returned by the CONSTRUCT query form.

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

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

PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
PREFIX vcard:   <http://www.w3.org/2001/vcard-rdf/3.0#>
CONSTRUCT   { <http://example.org/person#Alice> vcard:FN ?name }
WHERE       { ?x foaf:name ?name }

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

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

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

@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 (which have labels _:a and _:b in the data) causes different blank node labels (_:v1 and _:v2) as shown by the results.

10.3.2 Accessing Graphs in the RDF Dataset

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

10.3.3 Solution Modifiers and CONSTRUCT

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 2 of the solutions from graph pattern matching. The query outputs a graph with the names of the people with the top 2 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" .

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

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

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

10.4.1 Explicit IRIs

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

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

10.4.3 Descriptions of Resources

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

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

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

foaf:mbox_sha1sum  rdf:type  owl:InverseFunctionalProperty .

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

10.5 Asking "yes or no" 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/> .

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

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

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

yes

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

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 a given expression. Specifically, FILTERs eliminate any solutions that, when substituted into the expression, result in either an effective boolean value of false or produce an error. Effective boolean values are defined in section 11.2.2 Effective Boolean Value, errors are defined in XQuery 1.0: An XML Query Language [XQUERY] section 2.3.1, Kinds of Errors.

SPARQL expressions are constructed according to the grammar and provide access to functions (named by IRI) and operations (keywords in the SPARQL grammar). The datatypes of the operands of these functions and operators are the subset of the XML Schema datatypes {xsd:string, xsd:decimal, xsd:float, xsd:double, xsd:boolean, xsd:dateTime} and types derived from xsd:decimal: xsd:integer; xsd:nonPositiveInteger; xsd:negativeInteger; xsd:long; xsd:int; xsd:short; xsd:byte; xsd:nonNegativeInteger; xsd:unsignedLong; xsd:unsignedInt; xsd:unsignedShort; xsd:unsignedByte and xsd:positiveInteger.

The SPARQL operations are listed in section 11.3 and are associated with their productions in the grammar. In addition, SPARQL imports a subset of the XPath casting functions, listed in section 11.5, 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 [FUNCOP].

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

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

Literals may be cast to typed literals in order to use the SPARQL operators.

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

The following typographical conventions are used in this section:

• XPath operators are labeled with the prefix op:. XPath operators have no namespace; op: is a labeling convention.
• Operators introduce by this specification are indicated with the SPARQLoperator class.

11.1 Operand Data Types

SPARQL imports a subset of the XPath functions and operators. 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.

SPARQL introduces additional operators which operate on RDF terms. The following terms are imported from Resource Description Framework (RDF): Concepts and Abstract Syntax [CONCEPTS]:

• IRI (corresponds to the Concepts and Abstract Syntax term "RDF URI reference")
• literal
• lexical form
• plain literal
• language tag
• typed literal
• datatype IRI (corresponds to the Concepts and Abstract Syntax term "datatype IRI")
• blank node

When referring to a type, the following terms denote a typed literal with the corresponding XML Schema [XSDT] datatype IRI:

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

When referring to a type, the following terms denote a typed literal with the corresponding RDF Schema [RDFS] datatype IRI:

• rdfs:Datatype

The following terms identify additional types used in SPARQL tests:

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

11.2 Filter Evaluation

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

• Unlike XPath/XQuery, SPARQL functions do not process node sequences. When interpreting the semantics of XPath functions, assume that each argument is a sequence of a single node.
• Functions invoked with an argument of the wrong type (except xsd:boolean) will produce a type error. Functions requiring an argument of type xsd:boolean are coerced to xsd:boolean using the EBV rules in section 11.2.2 .
• Any expression other than logical or (||) or logical and (&&) that encounters an error will produce that error.
• A logical or that encounters an error on only one branch will return will return TRUE if the other branch is TRUE and an error if the other branch is FALSE.
• A logical and that encounters an error on only one branch will return will return an error if the other branch is TRUE and FALSE if the other branch is FALSE.
• A logical or or logical and that encounters errors on both branches will produce either of the errors.

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

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.
• 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 errors are defined in Filter Evaluation.

11.2.2 Effective Boolean Value (EBV)

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:

• If the argument is a typed literal with a datatype of xsd:boolean, the EBV is the argument.
• If the argument is a plain literal or a typed literal with a datatype of xsd:string, the EBV is false if the operand value has zero length; otherwise the EBV is true.
• If the argument is a numeric type or a typed literal with a datatype derived from a numeric type, the EBV is false if the operand value is NaN or is numerically equal to zero; otherwise the EBV is true.
• All other arguments produce a type error.

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 with a lexical value of "false".

[Informative: 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.]

11.3 Operator Mapping

The SPARQL grammar identifies a set of operators (for instance, &&, *, isIRI) used to construct constraints. The following table associates each of these grammatical productions with an operator defined either by XPath 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 upper-most viable candiate is the most specific.

See the XPath Operator Mapping for the definition of all operators under the heading "XQuery Tests", respecting numeric type promotions and subtype substitution for arguments to numeric operators. 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 equivilence can be tested with RDF term equivilence.

11.4 Operators Definitions

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.

11.4.1 bound

 xsd:boolean   bound (variable var)

Returns true if a var is bound to a value. Returns false otherwise. Variables with the value NaN or INF are considered bound. See 4.2 Unbound Variables for a discussion of why variables may be unbound.

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

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

Because Bob's dc:date was known, "Bob" was not a solution to the query.

11.4.2 isIRI

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

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

11.4.3 isBlank

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

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

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

11.4.4 isLiteral

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

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

11.4.5 str

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

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

11.4.6 lang

 simple literal   lang (literal ltrl)

Returns the language tag of ltrl, if it has one. It returns "" if ltrl has no 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> .

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

11.4.7 datatype

 rdfs:Datatype   datatype (typed literal ltrl)

Returns the datatype IRI of ltrl.

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

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

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

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

11.4.8 logical-or

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

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

Note: see section 11.2, Filter Evaluation, for the the || operator's treatment of errors.

11.4.9 logical-and

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

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

Note: see section 11.2, Filter Evaluation, for the the && operator's treatment of errors.

11.4.10 RDFterm-equal

 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]. 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.
• term1 and term2 are equivalent literals as defined in 6.5.1 Literal Equality.
• term1 and term2 are the same blank node as described in 6.6 Blank Nodes.

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

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

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

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

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("2004-01-01T00:00:00Z") || ?date = xsd:dateTime("2005-01-01T00:00:00Z") ) }

11.4.11 langMatches

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

Returns true if language-range (second argument) matches language-tag (first argument) per Tags for the Identification of Languages [RFC3066] section 2.5. RFC3066 defines a case-insensitive, hierarchical matching algorithm which operates on ISO-defined subtags for language and country codes, and user defined subtags. In SPARQL, 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" .

PREFIX dc: <http://purl.org/dc/elements/1.1/>
SELECT ?title
 WHERE { ?x dc:title  "That Seventies Show"@en ;
            dc:title  ?title .
         FILTER langMatches( lang(?title), "FR" ) }

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

11.4.12 regex

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

11.5 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:

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

The table below summarizes the casting operations that are always allowed (Y), never allowed (N) and dependent on the lexical value (M). For example, a casting operation from an xsd:string (the first row) to an xsd:float (the second column) is dependent on the lexical value (M).

bool = xsd:boolean
dbl = xsd:double
flt = xsd:float
dec = xsd:decimal
int = xsd:integer
dT = xsd:dateTime
str = xsd:string
IRI = IRI
ltrl = simple literal

11.6 Extensible Value Testing

A PrimaryExpression (see the grammar, production [58]) can be a call to an extension function named by an IRI. An extension function takes some number of RDF terms as arguments and returns an RDF term. The semantics of these functions are identified by the IRI that identifies the function.

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

As an example, consider a function called func:even:

 xsd:boolean   func:even (numeric value)

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

For a second example, consider a function aGeo:distance that calculates the distance between to points, which is used here to find the places near Grenoble:

 xsd:boolean   aGeo:distance (numeric x, numeric y)

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

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

A. SPARQL Grammar

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.  The EBNF format is the same as that used in the XML 1.1 specification[XML11]. Please see the "Notation" section of that specification for specific information about the notation.

In addition, the following sections apply.

A.1 IRI References

Text matched by the Q_IRI_REF production and QName (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 Q_IRI_REF <abc#def> may occur in a SPARQL query string, but the Q_IRI_REF <abc##def> must not.

Base URIs declared with the BASE keyword must be absolute URIs. A prefix declared with the PREFIX keyword may not be re-declared in the same query. See see section 2.1.1, Syntax of IRI Terms, for a description of BASE and PREFIX.

A.2 White Space

White space (production WS) is used to separate two terminals which would otherwise be (mis-)recognized as one terminal. Rule names below in capitals indicate where whitespace is significant; these form a possible choice of terminals for constructing a SPARQL parser. White space is significant in strings.

A.3 Keywords

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

A.4 Comments

Comments in SPARQL queries take the form of '#', outside an IRI or string, and continue to the end of line (marked by characters 0x0D or 0x0A) or end of file if there is no end of line after the comment marker. Comments are treated as white space.

A.5 Escape sequences in strings

Strings are used for the lexical form of RDF terms and in expressions. Within a string, the following escape sequences apply. The escape character is backslash "\"  (#x5C). No other escape sequences are defined for strings.  Names for characters given are the common names.

These escape sequences apply to all rules making up the rule for string (rules: STRING_LITERAL1, STRING_LITERAL2, STRING_LITERAL_LONG1, STRING_LITERAL_LONG2).

where HEX is a hexadecimal character

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

Examples:

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

A.6 Escape sequences in IRI references, prefixed names and variable names

The following escape sequences can be used in variable names, IRI references, that is, quoted IRI references, qnames and namespace prefixes.

Examples:

<ab\u00E9xy>
\u0041:ab\u00E9xy

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

A.7 Grammar

When choosing a rule to match, the longest match is chosen. Matching is case-sensitive except as noted above for keywords.

The SPARQL grammar is LL(1) when the rules with uppercased names are used as terminals.

Some grammar files for some commonly used tools is avaiable here (parsers/).

B. Conformance

See appendix A SPARQL Grammar regarding conformance of SPARQL Query strings, and section 10 Query Result 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.

C. Security Considerations

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.

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.

D. Collected Formal Definitions

The collected formal definitions are collected into a single document "SPARQL Query Language for RDF - Formal Definitions".

E. Internet Media Type, File Extension and Macintosh File Type (Normative)

STATUS:

This is a draft of a possible SPARQL Query Language MIME type registration for adding to a WD. This has not been reviewed or approved by the RDF Data Access Working Group.

contact:

Eric Prud'hommeaux

See also:

How to Register a Media Type for a W3C Specification

Internet Media Type registration, consistency of use
TAG Finding 3 June 2002 (Revised 4 September 2002)

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

This information that follows is intended to be submitted to the IESG for review, approval, and registration with IANA.

Type name:

application

Subtype name:

sparql-query

Required parameters:

None

Optional parameters:

None

Encoding considerations:

The syntax of the SPARQL Query Language is expressed over code points in Unicode [UNICODE]. The encoding is always UTF-8 [RFC3629].

Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F]

Security considerations:

See SPARQL Query appendix C, Security Considerations as well as RFC 3629 [RFC3629] section 7, Security Considerations.

Interoperability considerations:

There are no known interoperability issues.

Published specification:

This specification.

Applications which use this media type:

No known applications currently use this media type.

Additional information:

Magic number(s):

A SPARQL query may have the string 'PREFIX' (case independent) near the beginning of the document.

File extension(s):

".rq"

Base URI:

The SPARQL 'BASE <IRIref>' term can change the current base URI for relative IRIrefs in the query language that are used sequentially later in the document.

Macintosh file type code(s):

"TEXT"

Person & email address to contact for further information:

public-rdf-dawg-comments@w3.org

Intended usage:

COMMON

Restrictions on usage:

None

Author/Change controller:

The SPARQL specification is a work product of the World Wide Web Consortium's RDF Data Access Working Group. The W3C has change control over these specifications.

G. Acknowledgements

The SPARQL RDF Query Language is a product of the whole of the W3C RDF Data Access Working Group, and our thanks for discussions, comments and reviews go to all present and past members.

In addition, we have had comments and discussions with many people though the working group comments list.  All comments go to making a better document.  Andy would also like to particularly thank Geoff Chappell, Bob MacGregor, Yosi Scharf and Richard Newman for exploring specific issues related to SPARQL. Eric would like to acknowledge the invaluable help of Björn Höhrmann.

 
$Log: Overview.html,v $
Revision 1.11  2018/10/09 13:29:10  denis
fix validation of xhtml documents

Revision 1.10  2017/10/02 10:32:30  denis
add fixup.js to old specs

Revision 1.9  2006/02/21 20:24:46  connolly
removing links in CVS changelog to stuff to be published later

Revision 1.8  2006/02/21 19:57:49  connolly
emphasize rdfSemantics edits in SOTD

Revision 1.7  2006/02/21 19:52:12  connolly
link fixes from rq23 1.651

Revision 1.6  2006/02/21 19:49:54  connolly
link fixes from rq23 v1.646 - v1.650

Revision 1.5  2006/02/18 05:45:30  connolly
propagate more XQuery errors; divide by zero, in particular

Revision 1.4  2006/02/17 23:46:02  connolly
copyright boilerplate

Revision 1.3  2006/02/17 23:43:58  connolly
pubrules fixes:
 - stylesheet URIs, order
 - latest version comes before previous
 - copyright year
 - SOTD fixes, incl LC comment due date and patent policy text

Revision 1.2  2006/02/17 23:26:56  connolly
first try at pubrules-happiness

Revision 1.1  2006/02/17 23:21:18  connolly
copied over from rq23 in preparation for publication

Revision 1.645  2006/02/17 23:13:35  connolly
truncated CVS log at fifth WD

Revision 1.644  2006/02/17 23:11:11  connolly
struck question about alternative design for datatype()
due to lack of feedback

Revision 1.643  2006/02/17 23:04:04  connolly
fix langMatches order of args and example, per
DB 5Jan

Revision 1.642  2006/02/17 21:56:56  connolly
deleted obsolete comment status info
removed RFC2119 reference and fixed conformance section
markup per BH's suggestions

Revision 1.641  2006/02/16 17:05:18  aseaborne
Fixed appendix titles : put in appendix D

Revision 1.640  2006/02/14 17:50:08  aseaborne
Edits:

~ Removed "occurring in G" from defn text for Pattern Solution
~ Corrected defn of E-entailment regime

Revision 1.639  2006/02/14 09:22:37  eric
added xsd:string <= >= xsd:string to Operator Mapping perl DAWG decision RESOLVED: add xsd:string to 11.3 Operator Mapping and hence < and and ORDER BY

Revision 1.638  2006/02/08 15:00:47  aseaborne
@@ removal:

+ Added (at end of TOC) a link to "sparql-defns.html"
  This will be the tidied up definitions consolidated into
  one place.  For now, this contains a XSLT-produced version.

~ Expanded on "virtual graphs" in intro.

- Removed alternative, duplicate defn text for BGP equivalence

- Removed note to check sec 11 vs sec 2 as check now done.

+ Reference (informative) to RDFS added as per @@ 11.1
  Updated XQuery reference to CR version

+ parsers/ directory

Revision 1.637  2006/02/07 15:39:11  eric
added xsd:string < > xsd:string to Operator Mapping perl DAWG decision RESOLVED: add xsd:string to 11.3 Operator Mapping and hence < and and ORDER BY

Revision 1.636  2006/02/06 12:14:22  aseaborne
Links in grammar got broken - fixed

Revision 1.635  2006/02/06 11:51:35  aseaborne
Editorial changes in response to 2006Jan/0061
(part 4)

~ Edits in sec 10.4 (Describe)
~ A.2 Whitespace: states where whitespace matters more clearly.
~ Reordered grammar rules
~ Removed defn "query solution" as no longer used anywhere
~ Sec 11 intro : changed
  "The operands of these functions and operators"
to
  "The datatypes of the operands of these functions and operators"

Revision 1.634  2006/02/03 18:51:47  aseaborne
Editorial changes in response to 2006Jan/0061
(part 3)

~ ensured its says "group graph pattern" everywhere, not "group pattern"
~ 4.1. - mention braces earlier
~ 5. Removed "semi-structured" text
~ 7 "comprising of" / "consisting of"
~ s/named variables/variables/g

Revision 1.633  2006/02/03 14:53:19  aseaborne
(cat log.txt)

Revision 1.632  2006/02/02 10:15:41  aseaborne
Correct CONSTRUCT defn to ensure bNodes don't class with solution

Revision 1.631  2006/02/01 15:17:15  aseaborne
Editorial changes in response to 2006Jan/0061 (part 1)

~ Changed titles of 2.1.1 and 2.1.2 to not use the word "term"
~ Chnaged 2.1.X from "Syntax of" to "Syntax for"
~ Explictly say prefixes do not need to correspond with the serialization
  of the data
~ Link to VARNAME in "2.1.3 Syntax of Variables"
~ Edited intro sentence in 2.6

Revision 1.630  2006/01/31 10:48:52  aseaborne
Editorial:
~ Simple statement that the scoping set is a set of RDF terms.
~ Sentence about the role of BGP' in BGP matching
~ Tidy text about restriction to simple entailment
~ BGP equivalence : short and long versions (to be decided which)

Revision 1.629  2006/01/30 17:38:14  aseaborne
- Removed bnodes from triple pattern predciate position
  Definition and syntax
~ Fixed escape sequence text and put UCHAR and ECHAR into the grammar.

Revision 1.628  2006/01/30 13:28:21  aseaborne
Informative reference to OWL Semantics

Revision 1.627  2006/01/30 12:37:59  aseaborne
Map p in BGP-equiv defn

Revision 1.626  2006/01/30 12:35:52  aseaborne
~ More formal defn of BGP-equivalence
+ Added definition of E-entailment regime
+ Added a separate definition of basic graph pattern
~ Rename to defn to "basic graph pattern E-matching"

Revision 1.624  2006/01/28 17:22:51  aseaborne
~ Changed CONSTRUCT definition in line with email
~ Finished BGP equivalence definition

Revision 1.623  2006/01/26 16:52:30  aseaborne
Edit during telecon (5)

Revision 1.618  2006/01/26 11:09:51  aseaborne
Drafted text for basic graph pattern matching

Revision 1.617  2006/01/25 17:42:13  aseaborne
Typos in matching text

Revision 1.616  2006/01/25 15:49:46  aseaborne
Removed @@ about IRIs and RDF URI references.
Note RDF concepts anticipation of this.

More updates in line with 2006JanMar/0257

Revision 1.615  2006/01/25 15:08:42  aseaborne
Updated BGP matching in line with 2006JanMar/0257

Revision 1.614  2006/01/24 20:07:56  aseaborne
Use rule name FilteredBasicGraphPattern

Revision 1.613  2006/01/23 13:13:08  aseaborne
More drafting for BGP matching

Revision 1.612  2006/01/21 21:16:08  aseaborne
~ Grammar change to be clearer abou tbasic graph patterns
  There are no language changes.
  + Rule for a BasicGraphPattern (triples and constaints)
  ~ Triples1 renamed TriplesSameSubject

Revision 1.611  2006/01/20 17:29:13  aseaborne
Scoping Graph defn word fix

Revision 1.610  2006/01/20 12:06:13  aseaborne
Drafting for 2.5

Revision 1.609  2006/01/19 11:55:23  aseaborne
First draft of basic graph pattern matching.

Revision 1.608  2006/01/18 01:33:37  eric
~ clarify value of an EBV per message to DAWG

Revision 1.607  2006/01/18 01:04:15  eric
+ fixed an ommision: xsd:integer is supported by SPARQL and derived from xsd:decimal
+ additional BASE text responding to Richard Newman — BASE absolute IRIs
+ invented PREFIX re-declaration constraint text at the same time

Revision 1.606  2006/01/17 12:57:16  aseaborne
In response to 2006Jan/0056
added text to A.7 to note matching is case-sensitive.

In response to 2006Jan/0052
added distinct() to set of things to be DESCRIBEd.

In response to 2006Jan/0051
removed text about possible warning in CONSTRUCT on unbound variable.  Left
to implementations to decide what to do.

In response to 2006Jan/0057
clarified that comments end in 0x#A 0x#D and are treated as whitespace.

Revision 1.605  2006/01/16 17:58:09  aseaborne
~ Fixed the Modifier/Construct example.  Again.
  Maybe the changes will stick this time.

Revision 1.604  2006/01/12 23:54:36  connolly
assign comment on  5.4 Optional matching - formal definition to this spec

Revision 1.603  2006/01/12 11:22:19  aseaborne
+ Aded text to say a query service/processor can reject a query if
  it does not like the dataset description (case of serving
  queries on one dataset only)

Revision 1.602  2006/01/09 14:18:06  aseaborne
In response to: 2005Oct/0068
~ Changed the order of list in Defn Graph Pattern to be in document order.
~ Edited the definition of DISTNICT to be clearer in response to:
~ Definition of CONSTRUCT template: union works on sets.

Revision 1.601  2006/01/09 11:12:22  aseaborne
+ Add informtive reference to Concise Bounded Descriptions for comment 2005Nov/0042

Revision 1.600  2006/01/05 18:18:41  aseaborne
Comment: 2005Dec/0049

Fix for long literals.

Revision 1.599  2005/12/22 11:35:23  aseaborne
~ Edited the target graph definition (removed unnecessary text).
  Linked to it from sec 2.
- Removed red "please comment" text in sec 3.
- Remove sentence referring to triple patterns - we
  now use basic patterns as the building block.

Revision 1.598  2005/12/21 15:19:53  aseaborne
+ Remove told bNode text
+ Remove 3.1.4 which is duplicated by 3.4

Revision 1.597  2005/12/21 09:39:17  eric
~ applied all class="add" and class="remove" changes in section 11

Revision 1.596  2005/12/19 15:14:39  eric
~ (editorial) gathered redundant results

Revision 1.595  2005/12/19 09:28:35  aseaborne
Note that OPTIONAL is left-associative

Revision 1.594  2005/12/19 00:53:07  eric
+ (editorial) add resultSet style to something in the XML ResultSet

Revision 1.593  2005/12/18 21:31:42  eric
+ added support for alternate report formats in examples extraction

Revision 1.592  2005/12/16 23:05:15  eric
+ created prototype and dataExcerpt classes for rq23
- removed extraneous <div class="exampleOuter exampleInner">s
+ grouped all complete examples in the spec with their data and results
+ labeled all incomplete examples with the untested class
+ added examples.css for examples document, in progress
~ tweaked examples-extract.xsl to show examples structure in boxes

Revision 1.591  2005/12/16 17:29:42  aseaborne
Use term 'partial pattern rename'

Revision 1.589  2005/12/16 15:34:00  eric
~ working on an XSLT for extracting examples

Revision 1.588  2005/12/16 13:48:39  aseaborne
~ Put in, and highlight, alternative appraochs for told/no-told bnodes.

~ Editorial corrections based on message 2005Dec/0016

- Removed [NAMESPACE] as no longer used

Revision 1.587  2005/12/15 18:42:42  aseaborne
Example tidying in sec 4 due to defining all matching as starting
from basic pattern, not triple patterns.

Revision 1.585  2005/12/15 18:27:41  aseaborne
Fix CVS logs for last 3 versions

Revision 1.584  2005/12/15 18:23:02  aseaborne
~ Fixed 11.4.1 (?name/?givenName inconsistency

Revision 1.582  2005/12/15 16:37:06  aseaborne

~ Changes based on message 2005Dec/0018

~ A.2 Explicitly indicate terminals (correct whitespace handling)

+ Added defintion of "target graph" and incorporated it into the
  matching for GRAPH.

Revision 1.581  2005/12/15 13:35:24  aseaborne
Changes based on message 2005Dec/0018
~ Editorial as noted in the message
~ Changed definition pattern solution and basic graph pattern (in progress)

Revision 1.580  2005/12/13 18:32:39  aseaborne
Added comment about longest rule match wins

Revision 1.579  2005/12/13 14:10:44  eric
~ s/datatype URI/datatype IRI/ in section 11
+ todo to move imported RDF terms to earlier in the document
- removed alternate presentation of extra RDF terms

Revision 1.578  2005/12/13 13:48:00  eric
~ use function class

Revision 1.577  2005/12/13 10:33:14  eric
validated

Revision 1.576  2005/12/12 18:38:53  aseaborne
Changes in response to: 2005Dec/0004
~ Fix TOC
~ Sec 2.8.2: fix examples ; add mailto:
~ Sec 11.4.5: fix example ; add mailto:

Revision 1.574  2005/12/12 18:12:23  eric
+ langMatches(, "*") example per Bjoern's suggestion (response)
~ re-arranged presentation for working group decision on changes

Revision 1.573  2005/12/09 23:08:06  eric
~ moved derived subtypes into intro to Testing Values
+ flagged subtype substitution and numeric type promotion as relevent to SPARQL XQuery operators
+ defined semantics of XPath casts on RDF Terms
- removed casts to IRI and ltrl
+ tied Extensible Value Testing to PrimaryExpression grammar production.
~ reworked examples in Extensible Value Testing

Revision 1.572  2005/11/30 19:51:29  eric
s/xsd:string/simple literal/g — announcement to dawg

Revision 1.571  2005/11/28 13:32:11  eric
- removed sentence mis-defining the promotion of literal to string or numeric.
- removed sentence asserting that "SPARQL has no numeric type test operators".
- (follow-on to substantive) removed a reference to collation in REGEX operator description.
  (should have been done in V1.569)

Revision 1.570  2005/11/27 21:47:56  eric
~ (editorial) fixed link text in pointers to SPARQL operators

Revision 1.569  2005/11/27 18:53:20  eric
~ clarified fn:collation

Revision 1.568  2005/11/25 19:29:42  eric
~ change "sop" class to the more descriptive "SPARQLoperator"

Revision 1.567  2005/11/25 16:49:23  eric
~ moved fn: namespace definition to join the other prefix definitions.
~ updated typographical conventions for chapter 11.
+ point Operator Mapping "XQuery Tests" at the XPath Operator Mapping.

Revision 1.566  2005/11/25 13:51:43  eric
+ mapping of RDF typed literal to XML Schema typed value for XPath functions and operators
~ corrected use of the term RDF URI reference
+ imported definition of rdfs:Datatype
~ clarified definition of numeric
~ reused term RDF term from earlier in the document

Revision 1.565  2005/11/25 01:19:21  eric
~ reformatted 11 Testing Values
+ clarified Operand Data Types

! published fifth WD