- From: Dave Beckett <dave.beckett@bristol.ac.uk>
- Date: Thu, 7 Apr 2005 15:38:27 +0100
- To: public-rdf-dawg@w3.org
General comments
OK to publish. The items at the top should be at least considered,
the detailed changes below if possible, especially where I say
confused - but could be done later
Dave
--------
Bad N-Triples/Turtle
Some sparql examples uses
"foo"^^http://blah.com
and some
"foo"^^<http://blah.com>
they should be the same
Using illegal blank nodes _:1
Nested patterns are not defined, only nested (optional) patterns
which seem to be called nested patterns sometimes (!)
Constraints/Value Constraints - are they graph patterns or not?
Sometimes seem to be GPs, sometimes not. The grammar puts them under
PatternElement which might be a grammar-only construct.
Solution Sets vs Solution Sequences (section 10.1)
What is a complete query solution variable binding? Each
individual query result is a set of variables and terms but are
these grouped as a set of results or a sequence? This is important
in 10.1 as the set is ordered.
Hard to see what of the steps in 10.1 applies to what result forms.
Consistency in wording
bNode -> blank node (jargon)
bNodes -> blank nodes (jargon)
(set of) triple patterns -> Basic Pattern (maybe)
these are the same thing as far as I can tell
basic graph pattern -> Basic Pattern
the former wording is never defined
Optional Pattern Matching (5.1 title) OR Optional Block (5.2, 5.3, text)
- I prefer Optional Graph Pattern as that's used as the grammar terms
and would makes things align.
- Explain what's the difference if Optional Block != Optional (Graph) Pattern
Graph Labels / Graph Names
I prefer graph names
Detailed read through
----------------------------------------------------------------------
>
> W3C
>
> SPARQL Query Language for RDF
>
> Editors working draft.
> Live Draft - version:
> $Revision: 1.293 $ of $Date: 2005/04/05 14:26:19 $
>
> Editors:
> Eric Prud'hommeaux, W3C <eric@w3.org>
> Andy Seaborne, Hewlett-Packard Laboratories, Bristol
> <andy.seaborne@hp.com>
>
> published W3C Technical Report Version:
> 17 Feb 2005; see also public-rdf-dawg-comments@w3.org Mail Archives
> _________________________________________________________________
>
> Abstract
>
> RDF is a flexible, extensible way to represent information about World Wide
> Web resources. It is used to represent, among other things, personal
> information, social networks, metadata about digital artefacts, like music
> and images, as well as provide a means of integration over disparate sources
> of information. A standardized query language for RDF data with multiple
> implementations offers developers and end users a way to write and to
> consume the results of queries across this wide range of information. Used
> with a common protocol, applications can access and combine information from
> across the web.
>
> This document describes the query language part of SPARQL Protocol And RDF
> Query Language for easy access to RDF stores. It is designed to meet the
> requirements and design objectives described in the W3C RDF Data Access
> Working Group (DAWG) document "RDF Data Access Use Cases and Requirements".
>
> Status of This document
>
> This is a live document and is subject to change without notice. See also
> the change log. It reflects the best effort of the editors to reflect
> implementation experience and incorporate input from various members of the
> WG, but is not yet endorsed by the WG as a whole.
> _________________________________________________________________
>
> Table of Contents
>
> * 1 Introduction
> + 1.1 Document Conventions
> * 2 Making Simple Queries
> + 2.1 Writing a Simple Query
> + 2.2 Graph Patterns
> + 2.3 Graph Pattern Matching
> + 2.4 Examples of Graph Patterns
> + 2.5 Multiple Matches
> + 2.6 Blank Nodes
> + 2.7 Other Syntactic Forms
> * 3 Working with RDF Literals
> + 3.1 Matching RDF Literals
> + 3.2 Constraining Values
> * 4 Combining Graph Patterns
> + 4.1 Unbound Variables
> * 5 Including Optional Values
> + 5.1 Optional Pattern Matching
> + 5.2 Multiple Optional Blocks
> + 5.3 Constraints in Optional Blocks
> + 5.4 Optional Matching ___ Definition
> + 5.5 Nested Optional Blocks
> + 5.6 Requirements for Grouped Optional Patterns
> * 6 More Pattern Matching ___ Alternatives
> + 6.1 Joining Patterns with UNION
> + 6.2 Blocks in UNION Patterns
> + 6.3 Alternative Matching ___ Definition
> * 7 RDF Dataset
> + 7.1 Examples of RDF Datasets
> * 8 Querying the Dataset
> + 8.1 Accessing Graph Labels
> + 8.2 Restricting by Graph Label
> + 8.3 Restricting via Query Pattern
> + 8.4 GRAPH and background graph
> + 8.5 Definition for GRAPH
> * 9 Query Execution Ordering
> * 10 Query Forms
> + 10.1 Solutions and Result Forms
> + 10.2 Selecting which Variables to Return
> + 10.3 Constructing an Output Graph
> + 10.4 Descriptions of Resources
> + 10.5 Asking "yes or no" questions
> * 11 Testing Values
> + 11.1 Standard Operations on XML Datatypes
> + 11.2 Value Testing / RDF Types
> + 11.3 Extending Value Testing
>
> Appendices
>
> * A SPARQL Grammar
> * B References
> * C Change Log
>
> See also:
> * The protocol document
> * XML result format
> * DAWG Test Cases
> * Slide set
>
> Issues
>
> DAWG issues list
> _________________________________________________________________
>
> @@ToDo@@ Tidy up HTML
>
> @@ToDo@@ Ensure markup around examples enables XSLT extraction.
>
> @@ToDo@@ Make sure there are no @@ToDo@@ in the document.
>
> 1 Introduction
>
> An RDF graph is a set of triples, each triple consisting of a subject, a
> predicate and an object, as defined in RDF Concepts and Abstract syntax.
> These triples can come from a variety of sources. For instance, they may
> come directly from an RDF document. They may be inferred from other RDF
> triples. They may be the RDF expression of data stored in other formats,
> such as XML or relational databases.
>
> SPARQL (SPARQL Protocol And RDF Query Language) is a query language for
The <acronym> in the html here doesn't need repeating.
> getting information from such RDF graphs. It provides facilities to:
> * extract information in the form of URIs, bNodes, 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.
> When used across networks, the companion SPARQL Protocol for RDF document
> [11] describes a remote access protocol.
>
> 1.1 Document Conventions
>
> When undeclared, the prefix rdf stands in place of
> http://www.w3.org/1999/02/22-rdf-syntax-ns# , the prefix rdfs stands in
> place of http://www.w3.org/2000/01/rdf-schema#, and the prefix xsd for
> http://www.w3.org/2001/XMLSchema# .
>
> 2 Making Simple Queries
>
> The SPARQL query language is based around matching graph
> patterns. The simplest graph patterns are triple patterns, which
> are like an RDF triple but with the possibility of a variable in
add:
.. the ..
> subject, predicate or object position. Combining these gives a
> basic pattern, where an exact match to a graph is needed to
Basic Pattern [fwd ref]
> fulfil a pattern. Further graph patterns can be built using the
insert
^graph
> operators of OPTIONAL and UNION. Parts of a query can be
terminology: are these operators? Later on they are not consistently
used this way.
> directed to match against a collection of named graphs. It is
> also possible to restrict the values allowed in matching a
> pattern.
>
> In this section, we cover simple triple patterns, basic patterns and the
> SPARQL syntax that related to these.
>
> 2.1 Writing a Simple Query
>
> The example below shows a SPARQL query to find the title of a book from the
> information in an RDF graph. The query consists of two parts, the SELECT
> clause and the WHERE clause. The SELECT clause identifies the variables of
> interest to the application, and the WHERE clause has one triple pattern.
>
> Data:
>
> <http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title> "SPARQL
> Tutorial" .
>
> Query:
>
> SELECT ?title
> WHERE { <http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title
> > ?title }
>
> Query Result:
>
> title
> "SPARQL Tutorial"
>
> Query Term Syntax
>
> The terms delimited by "<>" are URI relative references [RFC 3896].
terminology: Relative URI References or possibly RDF URI References
>
> The query terms delimited by double quotes ("") are literals which,
> following N-Triples syntax [7], are a string, in quotes, an optional
> language tag, introduced with '@', or an optional datatype URIRef,
> introduced by '^^'.
insert: ^ but not both.
> Single quotes ('') are also allowed instead of double
> quotes. As a convenience, integers can be directly written and are
> interpreted as typed literals of datatype xsd:integer; floating point
> numbers can also be directly written and are interpreted as xsd:double.
insert:
xsd:boolean literal can also be written as TRUE, FALSE, true or false
>
> Variables in SPARQL queries have global scope; it is the same variable
> everywhere in the query that the name is used. Variables are indicated by
> '?'; the '?' does not form part of the variable. '$' is an alternative to
> '?' to help where systems use '?' as a substitution character. In a query,
> $abc and ?abc are the same variable.
>
> Because URIs can be long, SPARQL provides an abbreviation
> mechanism. Prefixes can be defined and a QName-like syntax [14]
> provides shorter forms. Prefixes apply to the query after they
> are defined;
confusing, maybe:
Prefixes apply from the point in the query where they are defined
onwards.
> redefining a prefix causes the new definition to be
> used from that point in the syntax. The base for the resolution
insert: ^ URI
> of URI relative references can be explicitly given with BASE. [RFC 3896].
better as?
... Relative URI References ... with the BASE clause.
>
> After parsing, URIs in queries are always absolute URIs. The term "URI" in
> this document should be read as "absolute URI".
maybe:
absolute URI References
but I'm not up-to-date with RFC3896 terms.
>
> Triple Patterns (definition link) are written as a list of subject,
> predicate, object; there are abbreviated ways of writing some common triple
> pattern constructs.
>
> Examples of Query Syntax
insert:
The following examples are three ways to express the same query:
> # Comment
> PREFIX dc: <http://purl.org/dc/elements/1.1/>
> SELECT ?title
> WHERE { <http://example.org/book/book1> dc:title ?title }
>
> PREFIX dc: <http://purl.org/dc/elements/1.1/>
> PREFIX : <http://example.org/book/>
> SELECT $title
> WHERE { :book1 dc:title $title }
> BASE <http://example.org/book/shelf/>
> PREFIX dc: <http://purl.org/dc/elements/1.1/>
> SELECT $title
> WHERE { <book1> dc:title $title }
>
> Data descriptions used in this document
>
> The data format used in this document is Turtle [15] used to show each
> triple explicitly. Turtle allows URIs to be abbreviated with prefixes:
>
> @prefix dc: <http://purl.org/dc/elements/1.1/> .
> @prefix : <http://example.org/book/shelf/> .
> :book1 dc:title "SPARQL Tutorial" .
>
> Prefixes are syntactic: the prefix name does not affect the
> query, nor do prefix names in queries need to be the same
> prefixes as used for data. This query is equivalent to the
> previous one and will give the same results when applied to the
> same graph.
confusing:
"previous one" is refering to any of the 3 previous queries, "this
query" is to the following:
possibly:
The following query is equivalent to the any of the previous ones
and will give the same results when applied to the same data.
>
> BASE <http://example.org/book/shelf/>
> PREFIX dcore: <http://purl.org/dc/elements/1.1/>
> SELECT ?title
> WHERE { <book1> dcore:title ?title }
>
> Result Descriptions used in this document
>
> The term "binding" is used as a descriptive term to refer to a pair of
> variable and RDF term.
wording reads like "pair of variable", "and RDF term"
better as:
.. to a pair (variable, RDF term).
or even just s/of/:/
> In this document, we illustrate bindings in results
> in tabular form so if variable x is bound to "Alice" and variable y is bound
> to "Bob", we show this as:
>
> x y
> "Alice" "Bob"
>
> Not every binding needs to exist in every row of the table. Optional matches
> and alternative matches may leave some variables unbound (see the bound
Alternative Matches (section title)
> test).
>
> Results can be returned in RDF, in XML the SPARQL Variable Binding Results
insert: ^with
> XML Format [16] and also in forms specific to implementation APIs.
>
> 2.2 Graph Patterns
>
> The building blocks of queries are triple patterns. Syntactically, a SPARQL
first mention: Triple Patterns (emphasis)
> triple pattern is a subject, predicate and object delimited by parentheses.
> The example in section 2.1 shows a triple pattern with a subject variable
> (the variable book), a predicate of dc:title and an object variable (the
> variable title).
No it doesn't. The example in 2.1 does not have an object variable.
Wording should be:
.. The following triple pattern has a subject variable ...
>
> ( ?book dc:title ?title )
>
> Matching a triple pattern to a graph, gives bindings between variables and
> RDF Terms so that the triple pattern, with the variables replaced by the
> corresponding RDF terms, is a triple of the graph being matched.
>
> Definition: RDF Term
> An RDF Term is anything that can occur in the RDF data model.
> let RDF-U be the set of all RDF URIs
> let RDF-L be the set of all RDF Literals
> let RDF-B be the set of all bNodes
> The set of RDF Terms, RDF-T, is RDF-U union RDF-L union RDF-B.
>
> Definition: Query Variable
> Let V be the set of all query variables. V and RDF-T are disjoint.
>
> An RDF triple contains three components:
> * the subject, which is an RDF URI reference or a blank node
> * the predicate, which is an RDF URI reference
> * the object, which is an RDF URI reference, a literal or a blank node
>
> In SPARQL, a triple pattern is similar to an RDF triple but with the
> addition that components can be a query variable.
suggestion:
... with the change that any component can be a query variable.
>
> Definition: Triple Pattern
> The set of triple patterns is
> (RDF-T union V) x (RDF-U union V) x (RDF-T union V)
>
> This definition of Triple Pattern includes literal subjects. This has been
> noted by RDF-core.
> "[The RDF core Working Group] noted that it is aware of no reason why literals
> should not
> be subjects and a future WG with a less restrictive charter may
> extend the syntaxes to allow literals as the subjects of statements."
>
> Definition: Basic Pattern
> A basic pattern is a set of Triple Patterns.
consistent definition emphasis: on A Basic Pattern like for things
defined above in RDF Term - RDF URIs.
>
> An RDF graph is a set of RDF triples. In the same way, a SPARQL Basic
> Pattern is a set of Triple Patterns.
>
> Definition: Query Pattern
> A query has one main graph pattern. It is called the Query Pattern.
First mention of graph pattern in a definition, not yet defined. So
Query Pattern is based on undefined.
consistent definition emphasis: Query Pattern
>
> 2.3 Graph Pattern Matching
>
> Definition: Substitution
> Substitution is a function from a subset of the set of variables, V, the
> domain of the substitution, dom(S), to the set of RDF terms, T.
> We write S(v) for the substitution of variable.
consistent definition emphasis: subtitution
>
> Definition: Restriction
> If X is a subset of dom(S) and dom(S')=X and S'(v) = S(v) for all v in X
> then S' is the restriction of S to X, written S|X.
consistent definition emphasis: restriction
>
> Definition: Pattern Instance
> If S is a substitution then the result of replacing any v in a basic pattern
> P by S(v) is a pattern instance of P, written S(P).
consistent definition emphasis: pattern instance
>
> For example, the query:
>
> SELECT ?x ?v WHERE ( ?x ?x ?v )
>
> has a single triple pattern as the query pattern. It matches a graph of a
> single triple:
>
> rdf:type rdf:type rdf:Property .
>
> with substitution:
>
> x v
> rdf:type rdf:Property
>
> It does not match the graph of a single triple:
>
> rdfs:seeAlso rdf:type rdf:Property .
>
> because the variable x would need to be both rdfs:seeAlso and rdf:type.
>
> Definition: Pattern Solution
> A Pattern Solution of Graph Pattern GP on graph G is any substitution S such
> that S(GP) is a subgraph of G.
>
> Where it is clear, a pattern solution is simply called a solution.
>
> 2.4 Examples of Graph Patterns
>
> The keyword WHERE is followed by a Graph Pattern, called the Query Pattern.
suggest:
The keyword WHERE is followed by the Query Pattern.
(already has been defined as that)
> The simplest form of Graph Pattern is the Triple Pattern. More complex
insert: graph
> patterns can be created by combining patterns in various ways
suggest insert: ... such as using pattern operators or groupings.
> ... One of these
insert: forms
> is the Basic Pattern. The other operators are for Optional Patterns[@link@],
reword: "The operators are Optional ..."
> Alternate Patterns [@link], and an operator that provides access to source
> information [@link@].
>
> In the basic pattern, for the pattern to match, there must be a substitution
insert:
^ graph
> where each of the triple patterns matches with the same substitution.
(important since this paragraph mentions both triple and graph patterns).
> Data:
>
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>
> _:a foaf:name "Johnny Lee Outlaw" .
> _:a foaf:mbox <mailto:jlow@example.com> .
>
> There is a bNode [12] in this dataset, identified by _:a. The label is only
> used within the file for encoding purposes. The label information is not in
> the RDF graph. No SPARQL query will be able to identify that bNode by the
> label used in the serialization.
>
> Query:
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?mbox
> WHERE
> { ?x foaf:name "Johnny Lee Outlaw" .
> ?x foaf:mbox ?mbox }
>
> Query Result:
>
> mbox
> <mailto:jlow@example.com>
>
> This query contains a basic pattern of two triple patterns, each of which
> must match for the graph pattern to match.
>
> 2.5 Multiple Matches
>
> The results of a query are all the ways a query can match the graph being
> queried. Each result is one solution to the query and there may be zero, one
> or multiple results to a query, depending on the data.
suggest delete: depending on the data.
>
> Definition: Query Solution
> A Query Solution is a Pattern Solution for the Query Pattern. A substitution
> in a query solution only contains variables mentioned in the query.
>
> Definition: Query Results
> The Query Results, for a given graph pattern GP on graph G, is written
> R(GP,G), and is the set of all query solutions S such that S is a solution
> for GP on G.
> R(GP, G) may be the empty set.
>
> Data:
>
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>
> _:a foaf:name "Johnny Lee Outlaw" .
> _:a foaf:mbox <mailto:jlow@example.com> .
> _:b foaf:name "Peter Goodguy" .
> _:b foaf:mbox <mailto:peter@example.org> .
>
> Query:
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?name ?mbox
> WHERE
> { ?x foaf:name ?name .
> ?x foaf:mbox ?mbox }
>
> Query Result:
>
> name mbox
> "Johnny Lee Outlaw" <mailto:jlow@example.com>
> "Peter Goodguy" <mailto:peter@example.org>
>
> The results enumerate the RDF terms to which the selected variables can be
> bound in the query pattern. In the above example, the following two subsets
> of the data caused 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> .
>
> For a simple, conjunctive graph pattern match, all the variables used in the
> query pattern will be bound in every solution.
"conjunctive graph pattern match" never before mentioned or defined.
suggest "For a Basic Pattern match"
refering to previously defined term. Otherwise this needs expanding.
>
> 2.6 Blank Node
suggest: Blank Nodes.
most other titles are plural
>
> Blank Nodes and Queries
>
> A blank node can appear in a SPARQL query patterns. It behaves as a
suggest: delete SPARQL, we know this.
> variable, although it can not be named in the query result form, such as
> SELECT.
suggest add: or be mentioned outside a graph pattern.
Still rather terse as "behaves as a variable" needs more explanation.
>
> Blank Nodes and Results
suggest: Blank Nodes and Query Results
more consistent with previous title
>
> In the results of queries, the presence of bNodes can be indicated by labels
> in the serializations of results but the labels can be relabelled on 1:1
> basis.
"relabelled on 1:1 basis." I know what this means but it says both
too little to explain what and too much in that if confuses if you
don't know about blank node scoping.
suggest: reword later
> An application or client receiving the results of a query can tell
> that two solutions or two variable bindings differ in bNodes but this
> information is only scoped to the results as defined in "SPARQL Variable
> Binding Results XML Format" or CONSTRUCT result form.
insert: ^the
>
> @@ToDo@@Tie to RDF graph form - or don't mention
>
> Data:
>
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>
> _:a foaf:name "Alice" .
> _:b foaf:name "Bob" .
>
> Query:
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?x ?name
> WHERE { ?x foaf:name ?name }
>
> x name
> _:c "Alice"
> _:d "Bob"
>
> The results above could equally be given with different bNode labels because
> the labels in the results only indicate whether RDF terms in the solutions
> were the same or different.
>
> x name
> _:r "Alice"
> _:s "Bob"
>
> These two results have the same information: the blank node used to match
grammar: nodes
> the query was different in the two solutions. There is no relation between
are
> using _:a in the results and any internal blank node label in the data
delete: internal ^^^^^^^^
> graph.
>
> 2.7 Other Syntactic Forms
>
> SPARQL uses a "Turtle-like" syntax for writing basic graph patterns, with
consistency:
Basic Patterns
> the addition of named variables. There are a number of syntactic forms that
> abbreviate some common sequences of triples. These syntactic forms do not
> change the meaning of the query. All these syntactic forms can be nested and
> combined.
pointer to where nested patterns (NOT nested optional patterns) are defined.
>
> Predicate-Object Lists
>
> Triples with common subject can be written so that the subject is written
replace:
Triple Patterns ...
> once, and used for more than one triple using the ";" notation.
insert:
^ pattern
> ?x foaf:name ?name ;
> foaf:mbox ?mbox .
>
> This is the same as writing the triple patterns:
> ?x foaf:name ?name .
> ?x foaf:mbox ?mbox .
>
> Object Lists
>
> If triples share both subject and predicate, then these can be written using
insert: ^patterns
> the "," notation.
> ?x foaf:nick "Alice" , "Alice_" .
>
> is the same as writing the triple patterns:
> ?x foaf:nick "Alice" .
> ?x foaf:nick "Alice_" .
>
> Blank Nodes
>
> Blank nodes have labels for the scope of the query syntax. They are written
> as "_:a", assigning label "a".
rewording::
Blank nodes have labels which are scoped to the query syntax. They
are written as "_:a", for a blank node with label "a".
> A blank node form that is used in only one place in the query syntax can be
delete: ^^^^ form
> abbreviated with "[]". A unique blank node will be created and used to form
> the triples.
replace:
triple patterns.
>
> The "[:p :v]" construct can used to form triples with a blank node for
replace: triple patterns
> subject.
insert:
^ the triple pattern
Insert:
The following two forms:
> [ :p "v" ] .
> [] :p "v" .
>
> Both these allocate a unique blank node label (here "b57") and writing:
> _:b57 :p "v" .
replace with
allocate a unique blank node label (here "b57") and are
equivalent to writing:
_:b57 :p "v" .
>
> Abbreviated blank node syntax can be combined with the abbreviated form for
insert: ^ other ^s
> common predicates and common objects.
insert: ^ such as:
> [ foaf:name ?name ;
> foaf:mbox <alice@example.org> ]
>
> This is the same as writing the following basic pattern for some uniquely
> allocated blank node:
reword:
which is the same as the following basic pattern for some uniquely
allocated blank node:
> _:b18 foaf:name ?name .
> _:b18 foaf:mbox <alice@example.org> .
>
> RDF Collections
>
> RDF collections can be written in triple patterns using the syntax
> "( )". The form "()" is short for resource rdf:nil or
> http://www.w3.org/1999/02/22-rdf-syntax-ns#nil.
URI syntax:
<http://www.w3.org/1999/02/22-rdf-syntax-ns#nil>
> (1 ?x 3)
>
> is short for:
> _:b0 rdf:first 1 .
> _:b0 rdf:rest _:b1 .
> _:b1 rdf:first ?x .
> _:b1 rdf:rest _:b2 .
> _:b2 rdf:first 3 .
> _:b2 rdf:rest rdf:nil .
>
> Reification Syntax
>
> Reification vocabulary for the three predicates rdf:subject, rdf:predicate
> and rdf:object can be abbreviate using "<< >>".
spelling: ^d
insert at end: around a triple pattern:
> ?id << ?s ?p ?o >> .
>
> is short for the triple patterns:
> ?id rdf:subject ?s .
> ?id rdf:predicate ?p .
> ?id rdf:object ?o .
>
> This syntax can be used where a subject or object is expected and a unique
> blank node will be allocated for the three triples using the reification
replace: triple patterns
> vocabulary terms:
> << ?s ?p ?o >> :saidBy "Bob" .
>
> is short for the triple patterns:
> _:b34 rdf:subject ?s .
> _:b34 rdf:predicate ?p .
> _:b34 rdf:object ?o .
> _:b34 :saidBy "Bob" .
>
> No triple for the type of the subject is included in the "<< >>" short form.
> It can be added if needed:
reword:
No triple pattern for the rdf:type of the subject is included in
the "<< >>" short form. It can be added if needed:
> << ?s ?p ?o >>
> rdf:type rdf:Statement ;
> :saidBy "Bob" .
> is short for the triple patterns:
insert:
^ which
> _:b34 rdf:subject ?s .
> _:b34 rdf:predicate ?p .
> _:b34 rdf:object ?o .
> _:b34 rdf:type rdf:Statement .
> _:b34 :saidBy "Bob" .
>
> Other
>
> The keyword "a" can be used as a predicate in a triple pattern and is short
possibly insert: ^ (lowercase only)
> for rdf:type.
insert:
^ the URI
> ?x a :Class1 .
> [ a :myClass ] :p "v" .
> ?x rdf:type :Class1 .
> _:b0 rdf:type :myClass .
> _:b0 :p "v" .
>
> 3 Working with RDF Literals
>
> An RDF Literal is written in SPARQL as a string containing the lexical form
> of the literal, delimited by "", followed by an optional language tag
> (indicted by '@') or optional datatype (indicated by '^^')
insert: but not both.
> .. There are
> convenience forms for numeric-types literals which are xsd:integers and
> xsd:doubles.
insert at end: and for xsd:booleans.
>
> Examples of literal syntax in SPARQL:
> * "chat"
> * "chat"@fr
> * "xyz"^^<http://example.org/ns/userDatatype>
> * "abc"^^myNS:myDataType
> * 1, which is the same as "1"^^xsd:integer
> * 1.0e6, which is the same as "1.0e6"^^xsd:double
insert:
* TRUE, FALSE, true, false
> 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 .
> :x ns:p "abc"^^dt:specialDatatype .
> :x ns:p "cat"@en .
suggest the data here has different subjects :x, :y, :z
(see below)
>
> Matching Integers
>
> The pattern in the following query has a solution because 42 is syntax for
then you can reword: has a solution ?v = :x because ...
> "42"^^http://www.w3.org/2001/XMLSchema#integer.
wrong syntax, should be: "42"^^<http://www.w3.org/2001/XMLSchema#integer> .
> SELECT ?v WHERE { ?v ?p 42 }
>
> Matching Arbitrary Datatypes
>
> The following query has a solution: note that the query processor does not
similarly: has a solution ?v = :y
suggest remove 'note that'.
> have to have any understanding of the values in the space of the datatype
> because, in this case, lexical form and datatype URI both match exactly.
> SELECT ?x WHERE { ?x ?p "abc"^^<http://example.org/datatype#specialDatatype> }
(Aside: here the datatyped literal syntax is right)
>
> Matching Language Tags
>
> This following query has no solution because "cat" is not the same RDF
> literal as "cat"@en:
>
> SELECT ?x WHERE { ?x ?p "cat" }
>
> but this does find a solution:
similarly: a solution ?x = :z:
> SELECT ?x WHERE { ?x ?p "cat"@en }
>
> 3.2 Constraining Values
>
> Graph pattern matching creates bindings of variables. It is possible to
> further restrict solutions by constraining the allowable binding of
> variables to RDF Terms. Constraints in SPARQL take the form of
> boolean-valued expressions; the language also allows application-specific
> constraints on the values in a query solution.
>
> Data:
>
> @prefix dc: <http://purl.org/dc/elements/1.1/> .
> @prefix : <http://example.org/book/> .
> @prefix ns: <http://example.org/ns#> .
>
> :book1 dc:title "SPARQL Tutorial" .
> :book1 ns:price 42 .
> :book2 dc:title "The Semantic Web" .
> :book2 ns:price 23 .
>
> Query:
>
> PREFIX dc: <http://purl.org/dc/elements/1.1/>
> PREFIX ns: <http://example.org/ns#>
> SELECT ?title ?price
> WHERE { ?x ns:price ?price .
> FILTER ?price < 30 .
> ?x dc:title ?title . }
>
> Query Result:
>
> title price
> "The Semantic Web" 23
suggestion:
mention that ?x is bound :book2 but not returned.
>
> By having a constraint on the "price" variable, only one of the books
> matches the query because there is a restriction on the allowable values of
> "price".
>
> Definition: Constraints
> A pattern may be a constraint, which is a boolean-valued expression of
^ graph
> variables and RDF Terms that restricts query solutions.
>
> Constraints may be restrictions of the value of an RDF Term or they may be
> restrictions on some part of an RDF term, such as its lexical form. SPARQL
> defines a set of functions & operations (sections 11.1 and 11.2) that all
> implementations must provide. In addition, there is an extension mechanism
> (section 11.3) for operations that are specific to an application domain or
> kind of data.
>
> A constraint may lead to an error condition when testing some RDF term. The
> exact error will depend on the constraint: for example, in numeric
> operations, solutions with variables bound to a non-number or a bNode will
> lead to an error. Any potential solution that causes an error condition in a
> constraint will not form part of the final results.
insert at end: but does not cause the query to fail.
> * Open: whether to allow "foo"@?v or ?v@fr or ?v^^xsd:integer or "foo"^^?v
> One way to address this is to allow expressions in SELECT
Let's close this open issue with: No we don't allow it.
>
> 4 Combining Patterns
>
> Complex graph patterns can be made by combining simpler patterns. The ways
insert: ^graph
> of creating patterns from triple patterns are:
insert: ^graph
> * Group Pattern, where a set of patterns must all match
insert: ^graph
> * Constraints, which restrict RDF terms in a solution
> * Optional patterns, where additional patterns may extend the solution
insert: ^graph
> * Alternatives, where two or more possible patterns are tried
insert: ^graph
> * GRAPH, where patterns are matched against named graphs
insert: ^graph
>
> A group of patterns is delimited with {}s (that is, braces).
>
> Definition: Graph Pattern ___ Grouping
> A graph pattern GP may be a set of graph patterns, GP[i]. A solution of
> Graph Pattern GP on graph G is any solution S such that for each element
> GP[i] of GP, S is a solution of GP[i].
>
> For any solution, the same variable is given the same value everywhere in
> the set of graph patterns.
or: ^^^^^^^^^^^^^^^^^^^^^ = Group Pattern
> ... A Basic Graph Pattern is, as described above,
it was called:
A Basic Pattern
> group of triple patterns. For example, this query has a group pattern of one
> basic pattern as the query pattern.
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?name ?mbox
> WHERE {
> ?x foaf:name ?name .
> ?x foaf:mbox ?mbox
> }
>
> The same solutions would be obtained from a query that grouped the patterns
insert: ^graph
> as below:
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?name ?mbox
> WHERE { { ?x foaf:name ?name ;
> foaf:mbox ?mbox }
> }
>
> Because a solution to a group is a solution to each element of a group, and
insert: ^pattern ^^^replace:the
> a solution of a basic pattern is a solution to each triple pattern, these
> queries also have the same solutions as:
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?name ?mbox
> WHERE { ?x foaf:name ?name ;
> foaf:mbox ?mbox
> }
>
> using the abbreviation for a common subject between triple patterns.
>
> 4.1 Unbound variables
>
> @@ToDo@@Discussion of unbound variables.
>
> 5 Including Optional Values
>
> Basic patterns and value constraints allow queries to perform queries where
change:
^^^^^^^^^^^^^^^^^ constraints
They were never called value constraints before.
Or edit the earlier section (3.2) to use that phrase.
reword:
from "allow queries to perform queries"
to "allow performing of queries
> all of the query pattern must match for there to be a solution. For every
> solution of the query, every variable is bound to an RDF Term in a pattern
> solution. RDF is semi-structured so a regular, complete structure can not be
> assumed and it is useful to be able to have queries that allow information
> to be added to the solution where the information is available, but have the
important insert: ^not to
> solution rejected just because that part of the query pattern does not
> match. Optional matching provides this facility; if the optional part does
> not lead to any solutions, variables can be left unbound.
replace:
^^^^^^= are
>
> 5.1 Optional Pattern Matching
consistency: later called Optional Block
>
> Optional parts of the graph pattern may be specified syntactically with the
> OPTIONAL keyword:
suggest adding:
... called an Optional Block
>
> OPTIONAL { ?s ?p ?o }
>
> Data:
>
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>
> _:a rdf:type foaf:Person .
> _:a foaf:name "Alice" .
> _:a foaf:mbox <mailto:alice@work.example> .
>
> _:b rdf:type foaf:Person .
> _:b foaf:name "Bob" .
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?name ?mbox
> WHERE { ?x foaf:name ?name .
> OPTIONAL { ?x foaf:mbox ?mbox }
> }
>
> With the data above, the query result is:
>
> name mbox
> "Alice" <mailto:alice@example.com>
> "Bob"
>
> There is no value of mbox in the solution where the name is "Bob". It is
> left unbound.
>
> This query finds the names of people in the data, and, if there is a triple
> with predicate mbox and same subject, retrieves the object of that triple as
> well. In the example, only a single triple pattern is given in the optional
> match part of the query but, in general, it is any graph pattern. The whole
> graph pattern of an optional block must match for the optional to add to the
^^^^^^^^^^^^^^ or "optional pattern", if that
remains the phrase for this concept
> query solution.
>
> 5.2 Constraints in Optional Blocks
>
> Constraints can be given in optional blocks as this example shows:
etc. optional graph pattern
>
> @prefix dc: <http://purl.org/dc/elements/1.1/> .
> @prefix : <http://example.org/book/> .
> @prefix ns: <http://example.org/ns#> .
>
> :book1 dc:title "SPARQL Tutorial" .
> :book1 ns:price 42 .
> :book2 dc:title "The Semantic Web" .
> :book2 ns:price 23 .
>
> PREFIX dc: <http://purl.org/dc/elements/1.1/>
> PREFIX ns: <http://example.org/ns#>
> SELECT ?title ?price
> WHERE { ?x dc:title ?title .
> OPTIONAL { ?x ns:price ?price . FILTER ?price < 30 }
> }
>
> title price
> "SPARQL Tutorial"
> "The Semantic Web" 23
>
> No price appears for the book with title "SPARQL Tutorial" because the
> optional block did not lead to a solution involving the variable price.
>
> 5.3 Multiple Optional Blocks
>
> Query patterns are defined recursively. A query may have zero or more
insert:
^pattern
> optional blocks and any part of a query pattern may have an optional part.
> In this example, there are two optional blocks.
>
> Data:
>
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>
> _:a foaf:name "Alice" .
> _:a foaf:homepage <http://work.example.org/alice/> .
>
> _:b foaf:name "Bob" .
> _:b foaf:mbox <mailto:bob@work.example> .
>
> Query:
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?name ?mbox ?hpage
> WHERE { ?x foaf:name ?name .
> OPTIONAL { ?x foaf:mbox ?mbox } .
> OPTIONAL { ?x foaf:homepage ?hpage }
> }
>
> Query result:
>
> name mbox hpage
> "Alice" <http://work.example.org/alice/>
> "Bob" <mailto:bob@example.com>
>
> 5.4 Optional Matching ___ Formal Definition
>
> In an optional match, either an additional graph pattern matches a graph and
insert: ^optional
> so defines one or more pattern solutions, or gives an empty pattern
> solution but does not cause matching to fail overall, leaving existing
replace: ^^^=and
as both occur (empty solution AND no failure)
> solutions in the query results.
>
> Definition: Optional Matching
> Given graph pattern GP1, and graph pattern GP2, Opt(GP1, GP2) is the
> optional match of GP2 of graph G, given GP1.
> Let GP = (GP1 union GP2) then S is a solution of Opt(GP1, GP2) if
> S is a solution for a match of GP on G, or else S is a solution for GP1 and
> S is not a solution for GP.
> S in R(Opt(GP1, GP2), G) if:
> S in R(GP, G)
> or
> S not in R(GP,G) and S in R(GP1, G).
>
> This definition can introduce ordering issues in queries - this is discussed
> in section "Query Execution Ordering".
>
> 5.5 Nested Optional Blocks
>
> Optional patterns can occur inside any pattern, including another optional
^^^^^^^^^^^
not any pattern, it can't be inside a triple pattern. This probably
means a graph pattern.
> pattern, forming a nested pattern. The outer optional block must match for
new terminology: ^^^^^^^^^^^^^^
but the section title is about "Nested Optional Blocks" not "Nested Patterns"
> any nested one to be matched.
etc. terminology consistency optional blocks/optional graph patterns
>
> Data:
>
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
> @prefix vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> .
>
> _:a foaf:name "Alice" .
> _:a foaf:mbox <mailto:alice@work.example> .
> _:a vcard:N _:x .
>
> _:x vcard:Family "Hacker" .
> _:x vcard:Given "Alice" .
>
> _:b foaf:name "Bob" .
> _:b foaf:mbox <mailto:bob@work.example> .
> _:b foaf:N _:z .
>
> _:z vcard:Family "Hacker" .
>
> _:e foaf:name "Ella" .
> _:e vcard:N _:y .
>
> _:y vcard:Given "Eleanor" .
>
> Query:
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> PREFIX vcard: <http://www.w3.org/2001/vcard-rdf/3.0#>
> SELECT ?foafName ?mbox ?gname ?fname
> WHERE
> { ?x foaf:name ?foafName .
> OPTIONAL { ?x foaf:mbox ?mbox } .
> OPTIONAL { ?x vcard:N ?vc .
> ?vc vcard:Given ?gname .
> OPTIONAL { ?vc vcard:Family ?fname }
> }
> }
>
> Query result:
>
> foafName mbox gname fname
> "Alice" <mailto:alice@work.example> "Alice" "Hacker"
> "Bob" <mailto:bob@work.example>
> "Ella" "Eleanor"
>
> This query finds the name, optionally the mbox, and also the vCard given
> name; further, if there is a vCard Family name as well as the Given name,
> the query gets that as well.
>
> By nesting the optional access to vcard:Family, the query only reaches these
> if there is a vcard:N predicate. It is possible to expand out optional
> blocks to remove nesting at the cost of duplication of expressions. Here,
> the expression is a simple triple pattern on vcard:N but it could be a
> complex graph match with value constraints.
insert: ^pattern
^^^^^^^^^^^^^^^^^^
may need to match any earlier defining of this term.
>
> 5.6 Requirements for Nested Optional Patterns
>
> @@ToDo@@ Move to execution order section.
>
> There is an additional condition that must be met for nested optional
> blocks. Considering the graph pattern as a tree of blocks, then a variable
^^^^^^^^^^^^^ query pattern?
tree of blocks? Why not use tree of graph patterns? Is a block a
graph pattern? confusion.
> in an optional block can only be mentioned in other optional blocks nested
> within it (or in the SELECT clause). A variable can not be used in two
> optional blocks where the outermost mention (shallowest occurrence in the
> tree for each occurrence) of the two uses is not the same block.
>
> For each variable v that occurs in a nested block, consider all paths from
^^^^^^^^^^^^
consistency:
nested optional block or nested optional pattern (section title) or ...
This is really not about any nested patterns, just optional ones.
> that variable in any block to the root of the tree. Those paths must all
I don't like root of the tree; "to the outermost graph pattern" works
better for me.
> intersect at a block that also contains the variable v.
>
> The purpose of this condition is to enable the query processor to process
> the query blocks in arbitrary (or optimized) order. If a variable was
> introduced in one optional block and mentioned in another, it would be used
> to constrain the second. Reversing the order of the optional blocks would
> reverse the blocks in which the variable was introduced and was used to
> constrain. Such a query could give different results depending on the order
> in which those blocks were evaluated.
>
> 6 More Pattern Matching ___ Alternatives
title suggestion: Combining Graph Patterns
as earlier mentions of this talk about use of operators for graph
patterns, way back at the start of section 2.
>
> 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
Maybe the Alternatives word could go in this title if the sec 6 title changes
>
> The UNION keyword is the syntax for pattern alternatives.
>
> Data:
>
> @prefix dc10: <http://purl.org/dc/elements/1.0/> .
> @prefix dc11: <http://purl.org/dc/elements/1.1/> .
>
> _:a dc10:title "SPARQL Query Language Tutorial" .
>
> _:b dc11:title "SPARQL Protocol Tutorial" .
>
> _:c dc10:title "SPARQL" .
> _:c dc11:title "SPARQL (updated)" .
>
> Query:
>
> PREFIX dc10: <http://purl.org/dc/elements/1.0/>
> PREFIX dc11: <http://purl.org/dc/elements/1.1/>
>
> SELECT ?title
> WHERE { { ?book dc10:title ?title } UNION { ?book dc11:title ?title } }
>
> Query result:
>
> title
> "SPARQL Protocol Tutorial"
> "SPARQL"
> "SPARQL (updated)"
> "SPARQL Query Language Tutorial"
>
> This query finds titles of the books in the data, whether the title is
> recorded using Dublin Core properties from version 1.0 or version 1.1. If
> the application wishes to know how exactly the information was recorded,
> then the query:
>
> PREFIX dc10: <http://purl.org/dc/elements/1.0/>
> PREFIX dc11: <http://purl.org/dc/elements/1.1/>
>
> SELECT ?x ?y
> WHERE { { ?book dc10:title ?x } UNION { ?book dc11:title ?y } }
>
> x y
> "SPARQL (updated)"
> "SPARQL Protocol Tutorial"
> "SPARQL"
> "SPARQL Query Language Tutorial"
>
> will return results with the variables x or y bound depending on which way
> the query processor matches the pattern to the data. Note that, unlike an
> OPTIONAL pattern, if neither part of the UNION pattern matched, then the
^^^^^^^^^^^^^^^^
"<tt>OPTIONAL</tt> pattern" or "Optional (Graph) Pattern" or "Optional Block"?
ditto UNION.
Preference to the grammar terms - Optional|Union Graph Pattern
> query pattern would not match.
> * The working group decided on this design and closed the disjunction
> issue without reaching consensus. The objection was that adding UNION
> would complicate implementation and discourage adoption. If you have
> input to this aspect of the SPARQL that the working group has not yet
> considered, please send a comment to public-rdf-dawg-comments@w3.org.
>
> 6.2 Blocks in UNION Patterns
suggestion: UNION of Basic Patterns/Graph Patterns
(which is it?)
it's not union of (triple) patterns
>
> More than one triple pattern can be given in each alternative possibility:
>
> PREFIX dc10: <http://purl.org/dc/elements/1.1/>
> PREFIX dc11: <http://purl.org/dc/elements/1.0/>
ERROR the prefixes don't match the right URIs
>
> SELECT ?title ?author
> WHERE { { ?book dc10:title ?title . ?book dc10:creator ?author }
> UNION
> { ?book dc11:title ?title . ?book dc11:creator ?author }
> }
>
> author title
> "Alice" "SPARQL Protocol Tutorial"
> "Bob" "SPARQL Query Language Tutorial"
>
> This query will only match a book if it has both a title and creator
> predicate from the same version of Dublin Core.
>
> 6.3 Alternative Matching ___ Formal Definition
>
> Definition: Pattern Matching (Union)
> Given graph patterns GP1 and GP2, and graph G, then a union pattern solution
> of GP1 and GP2 is any pattern solution S such that either S(GP1) matches G
> or S(GP2) matches G with substitution S.
> Query results involving a pattern containing GP1 and GP2, will include
> separate solutions for each match where GP1 and GP2 give rise to different
> sets of bindings.
>
> 7 RDF Dataset
>
> The RDF data model expresses information as graphs, comprising of triples
> with subject, predicate and object. Many RDF data stores hold multiple RDF
> graphs, and record information about each graph, allowing an application to
> make queries that involve information from more than one graph.
>
> A SPARQL query is made against an RDF Dataset which represents such a
> collection of graphs. Different parts of the query are matched against
> different graphs as described in the next section. There is one graph which
> does not have a name, called the background graph, and zero or more named
> graphs, identified by URI reference.
insert: ^each
>
> Definition: RDF Dataset
> An RDF dataset is a set = { G, (u[1], G[1]), (u[2], G[2]), . . . (u[n],
> G[n]) } where G and each G[i] are graphs, and each u[i] is a URI. Each u[i]
> is distinct.
> G is called the background graph. G[i] are named graphs.
>
> In the previous sections, all queries have been shown executed against the
> single, background graph. A query does not need to involve the background
> graph; the query can just involve the named graphs. ...
how can a query can do this? Not specified. [at least since
WITH/FROM were junked]
> .... A query processor is not
> required to support named graphs.
but? This sentence ends abruptly. Say why it is not required. The
default should be that all features of a specification are required.
>
> 7.1 Examples of RDF Datasets
>
> The definition of RDF Dataset does not restrict the relationships of named
> and background graphs. Two useful arrangements are:
> 1. place provenance information about the named graphs in the background
> graphs
> 2. include the RDF merge of the named graphs in the background graph.
>
> These are not the only useful arrangements of graphs in an RDF Dataset.
>
> Example 1:
>
> # Background graph
> @prefix dc: <http://purl.org/dc/elements/1.1/> .
>
> <http://example.org/bob> dc:publisher "Bob" .
> <http://example.org/alice> dc:publisher "Alice" .
> # Graph: http://example.org/bob
suggestion for examples: Use
# Named Graph: URI
to counterpoint
# Background Graph
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>
> _:a foaf:name "Bob" .
> _:a foaf:mbox <mailto:bob@oldcorp.example.org> .
> # Graph: http://example.org/alice
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>
> _:a foaf:name "Alice" .
> _:a foaf:mbox <mailto:alice@work.example.org> .
>
> In this example, the background graph contains the publisher names of two
> named graphs. The triples in the named graphs are not visible in the
> background graph and, thought of as the default knowledge base, the
> application is not directly trusting the information in the named graphs.
>
> Example 2:
>
> In this next example, the named graphs contain the same information as
> before. The RDF dataset includes an RDF merge of the named graphs in the
> background graph, relabelling blank nodes to keep them distinct. Doing this
> is trusting the contents of the named graphs. An implementation can
> efficiently provide datasets of this form without duplicating stored
> triples.
The last sentence does not add any information and could be deleted.
> # Background graph
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>
> _:x foaf:name "Bob" .
> _:x foaf:mbox <mailto:bob@oldcorp.example.org> .
>
> _:y foaf:name "Alice" .
> _:y foaf:mbox <mailto:alice@work.example.org> .
> # Graph: http://example.org/bob
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>
> _:a foaf:name "Bob" .
> _:a foaf:mbox <mailto:bob@oldcorp.example.org> .
> # Graph: http://example.org/alice
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>
> _:a foaf:name "Alice" .
> _:a foaf:mbox <mailto:alice@work.example> .
>
> 8 Querying the Dataset
>
> When querying a collection of graphs, the GRAPH keyword allows access to the
> URIs naming the graphs in the RDF Dataset, or restricts a graph pattern to
grammar: restrict
> be applied to a specific named graph.
>
> The following two graphs will be used in examples:
>
> # Graph: http://example.org/foaf/aliceFoaf
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>
> _:a foaf:name "Alice" .
> _:a foaf:mbox <mailto:alice@work.example> .
> _:a foaf:knows _:b .
>
> _:b foaf:name "Bob" .
> _:b foaf:mbox <mailto:bob@work.example> .
> _:b foaf:age 32 .
> _:b rdfs:seeAlso <http://example.org/foaf/bobFoaf> .
>
> <http://example.org/foaf/bobFoaf>
> rdf:type foaf:PersonalProfileDocument .
>
> # Graph: http://example.org/foaf/bobFoaf
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>
> _:1 foaf:mbox <mailto:bob@work.example> .
> _:1 rdfs:seeAlso <http://example.org/foaf/bobFoaf> .
> _:1 foaf:age 35 .
> <http://example.org/foaf/bobFoaf>
> rdf:type foaf:PersonalProfileDocument .
syntax: _:1 is not allowed as a blank node label in n-triples or Turtle.
Suggest it is changed to _:c
>
> 8.1 Accessing Graph Labels
Earlier named graphs was the term and graph names used and now they
are labeled. I suggest s/label/name/ throughout.
>
> Access to the graph labels of the collection of graphs being queried is by
> variable in the GRAPH expression.
grammar: ^^with
^^^^^^^^^^^^^^^^
It's been called 'clause' near other similar forms, suggest: GRAPH clause.
>
> The query below matches the pattern on each of the named graphs in the
insert:
^graph
> dataset and forms solutions which have the src variable bound to URIs of the
> graph being matched. The pattern part of the GRAPH only matched triples in a
> single named graph in the same way that a graph pattern matches the
> background graph when there is no GRAPH clause being applied.
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>
> SELECT ?src ?bobAge
> WHERE
> {
> GRAPH ?src
> { ?x foaf:mbox <mailto:bob@work.example> .
> ?x foaf:age ?bobAge
> }
> }
>
> The query result gives the label of the graphs where the information was
if changing this:
^^^^^ name
> found and the value for Bob's age:
>
> src bobAge
> <http://example.org/foaf/aliceFoaf> 32
> <http://example.org/foaf/bobFoaf> 35
>
> 8.2 Restricting by Graph Label
if changing it
... Name
>
> The query can restrict the matching applied to a specific graph by supplying
> the graph label. This query looks for the age as the graph
> http://example.org/foaf/bobFoaf asserts it.
if changing,
s/label/name/
Also prefernce to not using assert. Suggest:
This query looks for the age in the graph named
http://example.org/foaf/bobFoaf
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> PREFIX data: <http://example.org/foaf/>
>
> SELECT ?age
> WHERE
> {
> GRAPH data:bobFoaf {
> ?x foaf:mbox <mailto:bob@work.example> .
> ?x foaf:age ?age }
> }
>
> which yields a single solution:
>
> age
> 35
>
> 8.3 Restricting via Query Pattern
>
> A variable used in the GRAPH clause may also be used elsewhere in the query,
> whether in another GRAPH clause or in a graph pattern matched against the
> background graph in the dataset.
>
> This can be used to find information in one part of a query, and using it to
> restrict the graphs matched in another part of the query. The query below
> uses the graph with URI http://example.org/foaf/aliceFoaf to find the
> profile document for Bob; it then matches another pattern against that
> graph. Note that the pattern in the second GRAPH part finds the bNode for
^^^^^^^^^
style, suggest delete
> the person with the same mail box (given by variable mbox) as found in the
> first GRAPH part, because the blank node used to match for variable whom
> from Alice's FOAF file is not the same as the blank node in the profile
> document (they are in different graphs).
if earlier changes, s/GRAPH part/GRAPH clause/ twice in para
>
> PREFIX data: <http://example.org/foaf/>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
>
> SELECT ?mbox ?age ?ppd
> WHERE
> {
> GRAPH data:aliceFoaf
> {
> ?alice foaf:mbox <mailto:alice@work.example> ;
> foaf:knows ?whom .
> ?whom foaf:mbox ?mbox ;
> rdfs:seeAlso ?ppd .
> ?ppd a foaf:PersonalProfileDocument .
> } .
> GRAPH ?ppd
> {
> ?w foaf:mbox ?mbox ;
> foaf:age ?age
> }
> }
>
> mbox age ppd
> <mailto:bob@work.example> 35 <http://example.org/foaf/bobFoaf>
>
> Any triple in Alice's FOAF file giving Bob's age is not used to provide an
> age for Bob because the pattern involving variable age is restricted by ppd
> to a particular Personal Profile Document.
I had to write down what was going on here, it might help to add a
paragraph explaining parenthetically what happened to the variables
not selected.
(where ?whom was bound to _:b in data:aliceFoaf and ?w was bound
to _:1 in data:bobFoaf)
this edit will need to match any fix to the bad bnode _:1 mentioned above.
>
> 8.4 GRAPH and a background graph
>
> Query patterns can involve both the background graph and the named graphs.
> In this example, an aggregator has read in a web resource on two different
> occasions. Each time a graph is read into the aggregator, it is given a URI
> by the local system. The graphs are nearly the same but the email address
> for "Bob" has changed.
>
> The background graph is being used to record the provenance information and
> the RDF data actually read is kept in two separate graphs, each of which is
> given a different URI by the system. The RDF dataset consists of two, named
> graphs and the information about them.
>
> RDF Dataset:
> # Background graph
> @prefix dc: <http://purl.org/dc/elements/1.1/> .
>
> <urn:x-local:graph1> dc:publisher "Bob" .
> <urn:x-local:graph1> dc:date "2004-12-06"^^xsd:date .
>
> <urn:x-local:graph2> dc:publisher "Bob" .
> <urn:x-local:graph2> dc:date "2005-01-10"^^xsd:date .
> # Graph: locally allocated URI: urn:x-local:graph1
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>
> _:a foaf:name "Alice" .
> _:a foaf:mbox <mailto:alice@work.example> .
>
> _:b foaf:name "Bob" .
> _:b foaf:mbox <mailto:bob@oldcorp.example.org> .
> # Graph: locally allocated URI: urn:x-local:graph2
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>
> _:a foaf:name "Alice" .
> _:a foaf:mbox <mailto:alice@work.example> .
>
> _:b foaf:name "Bob" .
> _:b foaf:mbox <mailto:bob@newcorp.example.org> .
>
> This query finds email addresses, detailing the name of the person and the
> date the information was discovered.
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> PREFIX dc: <http://purl.org/dc/elements/1.1/>
>
> SELECT ?name ?mbox ?date
> WHERE
> { ?g dc:publisher ?name ;
> dc:date ?date .
> GRAPH ?g
> { ?person foaf:name ?name ; foaf:mbox ?mbox }
> }
>
> The results show that "Bob" email address has changed.
>
> name mbox date
> "Bob" <mailto:bob@oldcorp.example.org> "2004-12-06"^^xsd:date
> "Bob" <mailto:bob@newcorp.example.org> "2005-01-10"^^xsd:date
>
> The URI for the date datatype has been abbreviated in the results for
> convenience.
>
> 8.5 Definition for GRAPH
>
> Definition: DataSet Graph Pattern
> If D is a dataset {G, (<u1> G1), ...}, and P is a graph pattern then S is a
> pattern solution of GRAPH(g, P) if:
> g is a URI where g = <u[i]> for some i, and S is pattern solution of P on
> G[i ]or g is a variable, S maps the variable g to <u[i]> and S is a pattern
> solution of P on G[i].
>
> 9 Query Execution and Ordering
>
> Outline : help in wording appreciated.
>
> Examples
>
> Examples of where is matters: OPTIONALs, and FILTERS
>
> Evaluation Rules : Definitions
In all this section "pattern" usually means graph pattern, not triple
pattern or some other pattern (query pattern, others?)
>
> For pattern P, let var(P) be the variables mentioned
> by P or any of its sub patterns.
>
> For pattern P, let var-u(P) be the variables mentioned
> by P or any of its sub patterns such that x is in var-u(P)
> and P is a union expression, then x occurs all sub-patterns.
>
> For group GP = { P1 or C1, (P2 or C2), ... (CN or PN) }
> P pattern
> C constraint
> Fixed patterns: basic patterns and UNIONS
> Recursive definition for nested patterns
This seems to imply constraints/Value Constraints are not (graph) patterns?
>
> Evaluation rule: Optional-1
>
> Informally, this rule states that optional patterns must be executed as if
> it came after any basic patterns, where there is a common variable.
> If variable x in var(P[i]), and P[i] is an optional
> and x in var(P[j]) and P[j] is a triple pattern or union
> then
> j < i
>
> Evaluation rule: Optional-2
>
> Informally, this rule states that there can't be two optionals with a common
preference s/can't/cannot/
> variable, if that variable does not occur in a basic pattern as well.
> If variable x in var(P[i]), and P[i] is an optional
> and x in var-u(P[j]) and P[j] an optional, i != j
> then x must occur in some fixed P[k]
>
> By rule opt 1, k < i and j.
>
> Evaluation rule: Constraint
>
> Informally, this rule states that constraints are evaluated after variable
> are assigned values.
> If C[i] is a constraint expression, variable x in var(C[i])
> and x in var(P[j])
> then
> j < i
>
> 10 Result Forms
>
> SPARQL has a number of result forms for returning results. These result
> forms use the solutions from pattern matching to form result sets or RDF
> graphs. The query forms are:
>
> SELECT
> Returns all, or a subset of, the variables bound in a query pattern
> match. Formats for the result set can be in XML or RDF/XML (see the
^^^^^
I don't think it needs to have a match to return variables. You
could have a query with all optionals, and get an all empty result
with no bindings.
suggest last sentence: The result can be in formats such as XML ..
> result format document)
> @@ToDo@@Links to result format documents
please add a link to the XML results document here.
>
> CONSTRUCT
> Returns an RDF graph constructed by substituting variables in a set
> of triple templates.
suggest add:
The result can be in formats such as RDF/XML.
(that's the only one we require I think)
>
> DESCRIBE
> Returns an RDF graph that describes the resources found.
ditto.
suggest add:
The result can be in formats such as RDF/XML.
>
> ASK
> Returns whether a query pattern matches or not.
suggest add:
The result can be returned in the XML result format.
(only format for this we have now).
>
> 10.1 Solution Sequences and Result Forms
sets or sequences issue
>
> Query patterns generate a number of solutions and each solution is a set of
> variables and associated RDF terms. These solutions are passed through a
> stage to control the solution sequence, then passed to the result form for
> the query.
The last sentence is hard to understand. Is this the intended
meaning:
The solutions are passed through several optional steps and then
returned as a result.
Not sure what "passed to the result form for the query" was trying to say.
The following is an ordered list, please change it to one:
> The controls on the sequence of solutions are:
1.
> * Projection
2.
> * DISTINCT: ensure solutions in the sequence are unique.
no. at this stage, you have a solution set
3.
> * ORDER BY: put the solutions in order
more precisely. order the solution set to create a solution sequence
4.
> * LIMIT: restrict the number of solutions processed for query results
this applies to either the solution set (if no ORDER BY was used)
or solution sequence how it choses items from the solution set
isn't given.
5.
> * OFFSET: control where the solutions processed start from in the overall
> sequence of solutions.
this fails if you still have an (unordered) solution set
>
> The effect of applying these controls is as they are applied in the order
> given.
>
> Projection
>
> The solution sequence can be transformed to one only involving a subset of
> the variables. For each solution in the sequence, a new solution is formed
> using a specified selection of the variables.
>
> Definition: Projection
> For a substitution S and a finite set of variables VS,
> project(S, VS) = { (v, S[v]) | v in VS }
> For a query solution Q project(Q, VS) is { project(S, VS) | S in Q }
> For a set QS of query solutions, project(QS, VS) is { project(Q, V) | Q in
> QS }
>
> DISTINCT
>
> The DISTINCT modifier applies only for the SELECT result form.
>
> @@ToDo@@ could make sense, with LIMIT and OFFSET, in CONSTRUCT and DESCRIBE
but at present all of 10.1 only applies to SELECT? yes?
>
> The solution sequence can be modified by adding the DISTINCT keyword which
> ensures that every combination of variable bindings (i.e. each solution) in
> the sequence is unique. Thought of as a table, each row is different.
Might be worth mentioning how bnodes in DISTINCT work.
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>
> _:a foaf:name "Alice" .
> _:a foaf:mbox <mailto:alice@org> .
>
> _:z foaf:name "Alice" .
> _:z foaf:mbox <mailto:smith@work> .
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT DISTINCT ?name WHERE { ?x foaf:name ?name }
>
> name
> "Alice"
>
> If DISTINCT and LIMIT/OFFSET are specified, then duplicates are eliminated
> before the limit or offset is applied.
>
> 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.
"one gives the indication of the ordering." ???
Can we (some time) have an example of two ASC/DESC constructs?
also suggest adding a phrase:
The ordering may still remain undefined after ordering conditions
since as far as I understand you still can get unordered results even
if you asked for them. Explained in the later sections on Ordering
By Expression and Ordering by RDF Term
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>
> SELECT ?name
> WHERE { ?x foaf:name ?name }
> ORDER BY ?name
>
> PREFIX : <http://example.org/ns#>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
>
> SELECT ?name
> WHERE { ?x foaf:name ?name ; :empId ?emp }
> ORDER BY DESC[?emp]
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>
> SELECT ?name
> WHERE { ?x foaf:name ?name ; :empId ?emp }
> ORDER BY ?name DESC[?emp]
>
> Using ORDER BY on a solution sequence for a result form other than SELECT
> has no direct effect because only SELECT returns a sequence of results, not
delete: ^^^^^^
because more than that, ORDER BY on other forms does nothing. It has
no indirect effect on other forms.
> an RDF graph. However, in combination with LIMIT and OFFSET, it can be used
> to return partial results.
That seems to be a different issue as it's talking about when you
*do* have SELECT and have ORDER BY, LIMIT and/or OFFSET . Replace
"However, in" with "In"
sounds awfully like cursors to me
>
> Ordering by expression
>
> When ordering a solution sequence involves an expression, it is possible
> that the ordering conditions do no give a completely determined ordering for
> the sequence. In this case the ordering of solutions that are not
> distinguished, is not determined.
bafflement on last sentence.
Is this what it means?
" In this case the ordering of solutions is not determined."
which seems the same thing as the first sentence.
>
> Ordering by RDF term
>
> If an ordering condition is a variable, SPARQL defines an fixed, arbitrary
> order between some kinds of RDF terms that would not otherwise be ordered.
> This arbitrary order is necessary to provide slicing of query solutions by
> use of LIMIT and OFFSET.
> 1. (Lowest) no value assigned to the variable in this solution.
> 2. Blank nodes
> 3. URIs
> 4. RDF literals
>
> RDF Literals are compared with the "<" operator (see below) where possible.
Right here should be moved a note that later on explains that some things
are not covered by this rules:
Add or edit:
xsd:string and plain literal [RDF Literals] are comparable with
"<". They are not covered by these rules.
need to make sure "compared ... where possible" above is what is
meant here.
I'm confused about the formatting of this area. What's the scope of
Case1 or Case2? Are the examples in case2? Is the Note:?
> * There is a choice to be made between just requiring consistent (so
> LIMIT/OFFSET work as slices), but arbitrary ordering of otherwise equal
> values as compared with a specified ordering in all cases.
>
> Case 1: arbitrary consistent ordering:
>
> If the ordering criteria do not specify the order of two solutions, then the
> ordering in the solution sequence is undefined. However, an implementation
^^of
> must consistently impose the same order so that applying LIMIT/OFFSET will
> not miss any solutions.
>
> Ordering a sequence of solutions always results in a sequence with the same
^^^^^^^^^^^^^^^^^^^^^
solution sequence
insert: ^new solution
> number of solutions in it, even if the ordering criteria does not
> differentiate between two solutions.
>
> NB: "03"^^xsd:integer and "3"^^xsd:integer are not ordered by the rules so
> far (they represent the same value).
This might benefit from rewording explaining with pointers. suggest
Note that according to the rules given so far, "03"^^xsd:integer and
"3"^^xsd:integer represent the same value and are thus not ordered.
>
> @@ToDO@@ Case 1 better allows for ordering by processor-understood datatypes
> e.g. introducing a "distance"
>
> Case2: a define ordering for anything not ordered so far:
>
> RDF Literals are compared with the "<" operator (see below) where possible.
> Where not possible, the following rules are applied in order:
> 1. If the literals are both plain literals with language tags, compare
> lexical forms then compare language tags.
> 2. If the literals have the same datatype, order by order of lexical form.
> 3. If one is a plain literal and one a literal with a datatype type
> 1. order by lexical form
> 2. if still the same, plain literals come first (lower)
> 4. If both have datatypes
> 1. order by lexical form
> 2. if still the same, order by datatype URIs.
>
> Examples:
> * "foo"@xx < "foo"@zz (rule 1)
> * "abc"^^:myType < "xyz"^^:myType (rule 2)
> * "03"^^xsd:integer < "3" (lexical forms rule 3.1)
> * "3"< "3"^^xsd:integer (plain literals before typed literals, 3.2)
> * "03"^^xsd:integer < "3"^^xsd:integer (lexical form rule 4.1)
> * "03"^^:myType < "3"^^:myType (lexical form rule 4.1)
> * "rst"^^<http://example.org/type1> < "rst"^^<http://example.org/type2>
> (lexical form rule 4.2)
>
> Note: xsd:string and plain literal are comparable with "<". They are not
> covered by these rules.
>
> 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 will cause no results to be returned. A limit may not be
> negative.
suggest: A limit of 0 causes ...
>
> OFFSET
>
> OFFSET causes the solutions generated to start after the specified number of
suggest:
^The OFFSET clause allows solutions ...
> solutions. An OFFSET of zero has no effect.
>
> The order in which solutions are returned is undefined so using LIMIT and
suggest: ^initially
> OFFSET to select different subsets of the query solutions will given not be
> useful unless the order is made predictable by ensuring ordered results
> using ORDER BY.
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>
> SELECT ?name
> WHERE { ?x foaf:name ?name }
> ORDER BY ?name
> LIMIT 5
> OFFSET 10
>
> 10.2 Selecting which Variables to Return
suggest title: Selecting All Variables
which is what it does describe
>
> The SELECT form of results returns the variables directly. The syntax SELECT
> * is shorthand for "select all the named variables".
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>
> _:a foaf:name "Alice" .
> _:a foaf:knows _:b .
> _:a foaf:knows _:c .
>
> _:b foaf:name "Bob" .
>
> _:c foaf:name "Clare" .
> _:c foaf:nick "CT" .
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?nameX ?nameY ?nickY
> WHERE
> { ?x foaf:knows ?y ;
> foaf:name ?nameX .
> ?y foaf:name ?nameY .
> OPTIONAL { ?y foaf:nick ?nickY }
> }
>
> nameX nameY nickY
> "Alice" "Bob"
> "Alice" "Clare" "CT"
Suggest new section here:
10.X Formatting Results
then it can be refered to earlier
>
> Result sets can be accessed by the local API but also can be serialized into
^^^^^^^^^^^
well, earlier it was called solution sets and solution sequences.
maybe these need formally linking in with result sets
> either XML or an RDF graph. The XML result set form gives:
> <?xml version="1.0"?>
> <sparql
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
> xmlns="http://www.w3.org/2001/sw/DataAccess/rf1/result" >
> <head>
> <variable name="nameX"/>
> <variable name="nameY"/>
> <variable name="nickY"/>
> </head>
> <results>
> <result>
> <nameX>Alice</nameX>
> <nameY>Clare</nameY>
> <nickY>CT</nickY>
> </result>
> <result>
> <nameX>Alice</nameX>
> <nameY>Bob</nameY>
> <nickY bound="false"/>
> </result>
> </results>
> </sparql>
>
> And in RDF/XML, using the Variable Binding Results XML Format [16] gives:
wrong reference. That's the RDF/XML format for test cases
> <rdf:RDF
> xmlns:rs="http://www.w3.org/2001/sw/DataAccess/tests/result-set#"
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
> <rs:ResultSet>
> <rs:resultVariable>nickY</rs:resultVariable>
>
> <rs:resultVariable>nameX</rs:resultVariable>
> <rs:resultVariable>nameY</rs:resultVariable>
> <rs:solution rdf:parseType="Resource">
> <rs:binding rdf:parseType="Resource">
> <rs:variable>nameX</rs:variable>
> <rs:value>Alice</rs:value>
> </rs:binding>
> <rs:binding rdf:parseType="Resource">
> <rs:value>CT</rs:value>
> <rs:variable>nickY</rs:variable>
> </rs:binding>
> <rs:binding rdf:parseType="Resource">
> <rs:value>Clare</rs:value>
> <rs:variable>nameY</rs:variable>
> </rs:binding>
> </rs:solution>
> <rs:solution rdf:parseType="Resource">
> <rs:binding rdf:parseType="Resource">
> <rs:variable>nameX</rs:variable>
> <rs:value>Alice</rs:value>
> </rs:binding>
> <rs:binding rdf:parseType="Resource">
> <rs:value>Bob</rs:value>
> <rs:variable>nameY</rs:variable>
> </rs:binding>
> </rs:solution>
> </rs:ResultSet>
> </rdf:RDF>
>
> Results can be thought of as a table, with one row per query solution. Some
> cells may be empty because a variable is not bound in that particular
> solution.
>
> 10.3 Constructing an Output Graph
>
> The CONSTRUCT result form returns a single RDF graph specified by
suggest: ^result
> a graph template.
first mention, suggest Graph Template emphasised as a new thing,
which is not a Graph Pattern.
Definition: A Graph Template is a set of Triple Patterns.
> The result is an RDF graph formed by taking each query solution in
> the solution sequence, substituting for the variables into the graph
^^^^^^^^^^^^^^^^^^ or result set or solutions set?
> template and merging the triples into a single RDF graph.
>
> If any such instantiation produces a triple containing an unbound variable,
> or an illegal RDF construct (such as a literal in subject or predicate
> position) then that triple is not included in the RDF graph, and a warning
> may be generated.
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>
> _:a foaf:name "Alice" .
> _:a foaf:mbox <mailto:alice@example.org> .
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> PREFIX vcard: <http://www.w3.org/2001/vcard-rdf/3.0#>
> CONSTRUCT { <http://example.org/person#Alice> vcard:FN ?name }
> WHERE { ?x foaf:name ?name }
>
> creates vcard properties from the FOAF information:
>
> @prefix vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> .
> <http://example.org/person#Alice> vcard:FN "Alice" .
>
> Templates with bNodes
s/bNodes/Blank Nodes/ and in following para, and later on
>
> A template can create an RDF graph containing bNodes. The labels are scoped
insert: ^blank node
> to the template for each solution. If two such prefixed names share the same
> label in the template, then there will be one bNode created for each query
> solution but there will be different bNodes 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 } .
> }
>
> creates vcard properties corresponding to the FOAF information:
>
> @prefix vcard: <http://www.w3.org/2001/vcard-rdf/3.0#> .
> _:v1 vcard:N _:x .
> _:x vcard:givenName "Alice" .
> _:x vcard:familyName "Hacker" .
> _:v2 vcard:N _:z .
> _:z vcard:givenName "Bob" .
> _:z vcard:familyName "Hacker" .
>
> The use of variable ?x in the template, which in this example will be bound
> to bNodes, causes an equivalent graph to be constructed with a different
> bNode as shown by the document-scoped label.
insert:
^label
s/bNode/blank node/
suggest changing end of sentence to add:
... labels _:a and _:b written in the result graph as _:v1 and _:v2
>
> Accessing Graphs in the RDF Dataset
>
> Using CONSTRUCT it is possible to extract parts of, or the whole of, graphs
> from the target RDF dataset. This first example returns the graph (if it is
> in the dataset) with URI label http://examples.org/myGraph otherwise it
> returns an empty graph.
> CONSTRUCT { ?s ?p ?o } WHERE { GRAPH <http://examples.org/myGraph> { ?s ?p ?o }
> . }
>
> The access to the graph can be conditional on other information. Suppose
> the background graph contains metadata about the named graphs in the dataset
> then a query like this next one can extract one graph based on information
suggest
^^^^^^^^^^^ construct a
> about the named graph:
> PREFIX dc: <http://purl.org/dc/elements/1.1/>
> PREFIX app: <http://example.org/ns#>
> CONSTRUCT { ?s ?p ?o } WHERE
> {
> GRAPH ?g { ?s ?p ?o } .
> { ?g dc:publisher <http://www.w3.org/> } .
> { ?g dc:date ?date } .
> FILTER app:myDate(?date) > "2005-02-28T00:00:00Z"^^xsd:dateTime .
> }
>
> where app:myDate identified an extension function to turn the data format
> into an xsd:dateTime RDF Term..
>
> 10.4 Descriptions of Resources
>
> The DESCRIBE form returns a single RDF graph containing RDF data about
insert: ^result
> resources. This data is not prescribed by a SPARQL query, where the query
> client would need to know the structure of the RDF in the data source, but,
> instead, is determined by the SPARQL query processor.
>
> The query pattern is used to create a result set. The DESCRIBE form takes
> each of the resources identified in a solution, together with any resources
> directly named by URI, and assembles a single RDF graph by taking a
> "description" from the target knowledge base. The description is determined
> by the query processor implementation and should provide a useful
> description of the resource, where "useful" is left to nature of the
> information in the data source.
Unavoidable repetition of description would be nice to remove from
the last sentence particularly. Maybe start:
"The result graph is determined..."
>
> 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.
>
> Explicit URIs
>
> The DESCRIBE clause itself can take URIs to identify the resources. The
> simplest query is just a URI in the DESCRIBE clause:
>
> DESCRIBE <http://example.org/>
>
> Identifying Resources
>
> The resources can also be a query variable from a result set. This enables
> description of resources whether they are identified by URI or bNode in the
> dataset being queried.
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> DESCRIBE ?x
> WHERE { ?x foaf:mbox <mailto:alice@org> }
>
> The property foaf:mbox is defined as being an inverse function property in
> the FOAF vocabulary so, if treated as such, this query will return
> information about at most one person. If, however, the query pattern has
> multiple solutions, the RDF data for each is the union of all RDF graph
> descriptions.
suggest ending:
... the RDF result graph is the union of all the RDF graphs for
the described resources
it's not "for each" as there is only one result RDF graph
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> DESCRIBE ?x
> WHERE { ?x foaf:name "Alice" }
>
> More than one URI or can be given:
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> DESCRIBE ?x ?y <http://example.org/>
> WHERE {?x foaf:knows ?y}
>
> Descriptions of Resources
>
> The RDF returned is the choice of the deployment and may be dependent on the
^result graph
> query processor implementation, data source and local configuration. It
> should be the useful information the server has (within security matters
> outside of SPARQL) about a resource. It may include information about other
> resources: the RDF data for a book may also include details of the author.
This is all implementation-talk. deployment seems the wrong word.
How about starting:
The RDF result graph returned is not defined here and may depend on
the query processor implementation, data sources, local
configuration and other factors.
Question: what about duplicate described resources? Is that up to
the implementation, or is duplicate elimination work done before
hand?
> A simple query such as
>
> PREFIX ent: <http://myorg.example/employees#>
> DESCRIBE ?x WHERE { ?x ent:employeeId "1234" }
>
> might return a description of the employee and some other potentially useful
> details:
>
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> @prefix vcard: <http://www.w3.org/2001/vcard-rdf/3.0> .
> @prefix myOrg: <http://myorg.example/employees#> .
>
> _:a myOrg:employeeId "1234" ;
> foaf:mbox_sha1sum "ABCD1234" ;
> vcard:N
> [ vcard:Family "Smith" ;
> vcard:Given "John" ] .
>
> foaf:mbox_sha1sum rdf:type owl:InverseFunctionalProperty .
syntax error: owl: is not defined in the data
>
> which includes the bNode closure for the vcard vocabulary vcard:N. For a
> vocabulary such as FOAF, where the resources are typically bNodes, returning
> sufficient information to identify a node such as the
> InverseFunctionalProperty foaf:mbox_sha1sum as well information which as
> name and other details recorded would be appropriate. In the example, the
> match to the WHERE clause was returned but this is not required.
>
> 10.4 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/> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>
> _:a foaf:name "Alice" .
> _:a foaf:homepage <http://work.example.org/alice/> .
>
> _:b foaf:name "Bob" .
> _:b foaf:mbox <mailto:bob@work.example> .
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> ASK { ?x foaf:name "Alice" }
>
> yes
>
> @@ToDo@@ Align results to XML results format or some result form for ASK
>
> on the same data, the following returns no match because Alice's mbox is not
> as described.
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> ASK { ?x foaf:name "Alice" ;
> foaf:mbox <mailto:alice@work.example> }
> no
>
> 11 Testing Values
>
> SPARQL expressions are constructed according to the grammar and provide
> access to named functions and syntactically constructed operations. The
> operands of these functions and operators are the subset of XML Schema
> DataTypes {xsd:string, xsd:decimal, xsd:double, xsd:dateTime} and types
> derived from xsd:decimal. The SPARQL operations are listed in table 11.1 and
> are associated with productions in the grammar. In addition, SPARQL imports
insert: ^ their
> a subset of the XPath functions, listed in table 11.2, which are invokable
> by name within a SPARQL query. These functions and operators are taken from
> the XQuery 1.0 and XPath 2.0 Functions and Operators [17].
>
> Namespaces:
>
> The namespace for XPath functions that are directly available by name is
> http://www.w3.org/2004/07/xpath-functions. The associated namespace prefix
> used in this document is fn:. XPath operators are named with the prefix op:.
> SPARQL operators are named with the prefix sop:.
>
> 11.1 Operand Data Types
>
> As described above, RDF Terms are made of URIs (URI References), Literals
> and Blank Nodes. RDF Literals may have datatypes which may come from
> instance data:
html: RDF Literals doesn't need <tt>
>
> @prefix a: <http://www.w3.org/2000/10/annotation-ns#>
> @prefix dc: <http://purl.org/dc/elements/1.1/>
>
> _:a a:annotates <http://www.w3.org/TR/rdf-sparql-query/> .
> _:a dc:created "2004-12-31T19:00:00-05:00" .
>
> _:b a:annotates <http://www.w3.org/TR/rdf-sparql-query/> .
> _:b dc:created "2004-12-31T19:01:00-05:00"^^http://www.w3.org/2001/XMLSche
> ma#dateTime .
syntax error, should be:
... "2004-12-31T19:01:00-05:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
>
> The first dc:created arc has no type information. The second is tagged with
> the type xsd:dateTime (indicating a software upgrade sometime between 19:00
> and 19:01.)
>
> Literals may be cast to typed literals:
>
> PREFIX a: <http://www.w3.org/2000/10/annotation-ns#>
> PREFIX dc: <http://purl.org/dc/elements/1.1/>
> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
>
> SELECT ?annot
> WHERE { ?annot a:annotates <http://www.w3.org/TR/rdf-sparql-query/> .
> ?annot dc:created ?date .
> FILTER xsd:dateTime(?date) < xsd:dateTime("2005-01-01T00:00Z") }
>
> SPARQL defines a subset of the XPath functions and operators when used with
> operands of the following XML Schema datatypes:
> * xs:string
> * xs:double
> * xs:float
> * xs:decimal
> * xs:integer
> * xs:dateTime
>
> In addition, SPARQL introduces additional operators which operate on RDF
> terms. RDF terms are identified by r:term and the constituant subclasses by:
> * r:URI
> * r:Literal
> * r:bNode
>
> 11.1.1 Type Promotion
>
> XQuery defines a set of Numeric Type Promotions. Numeric operators are
> defined for the following three primitive XML Schema numeric types:
> * xs:double
> * xs:float
> * xs:decimal
The above is an ordered list, in that in promotion you start at one
end and move along it. Change to 1..2..3.. which will help the rules
below
>
> These invoke XQuery's numeric type promotion to promote function arguments
> to the appropriate type. In summary: Each of the numeric types may be
> promoted to any type higher in the above list. The operators defined below
"higher" here now makes more sense if the above list is ordered,
replace with "earlier in the above ordered list"
> that take numeric arguments expect all arguments to be the same type. This
> is accomplished by promoting the argument with the lower type to the same
html: promoting doesn't need <tt>
> type as the other argument. For example, xs:integer(7) + xs:float(6.5) would
> call op:numeric-add(xs:float(7), xs:float(6.5)). In addition, any r:Literal
> may be cast to xs:string or xs:numeric when used as an argument to an
> operator expecting that type.
There is no such thing as xs:numeric. suggest
xs:string or any of the three numeric types xs:double, xs:float
and xs:decimal.
>
> XML Schema [] defines a set of types derived from decimal: integer,
> nonPositiveInteger, negativeInteger, long, int, short, byte,
> nonNegativeInteger, unsignedLong, unsignedInt, unsignedShort, unsignedByte
> and positiveInteger. These are all treated as decimals for computing
> effective boolean values. SPARQL does not specifically require integrity
> checks on derived subtypes. SPARQL has no numeric type test operators so the
> distinction between a primitive type and a type derived from that primitive
> type is unobservable.
>
> 11.2 SPARQL Functions and Operators
>
> SPARQL provides a subset of the functions and operators defined by XQuery
> Operator Mapping. XQuery 1.0 sections 2.2.3 Expression Processing and 3.1.5
> Function Calls describe 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 sequences of a single node.
grammar: a sequence
> * Functions invoked with an argument of the wrong type will produce a type
> error.
> * Any expression other than value disjunction (or) that encounters a type
> error will produce a type error.
> * A value disjunction that encounters a type error on only one branch will
> return the result of evaluating the other branch.
> * A value disjunction that encounters type errors on both branches will
> produce a type error.
> * A FILTER will eliminate any solutions that yield an effective boolean
> value of false or produce a type error.
I think this last point should be more prominent, and maybe should be
in a different section. It's also not a difference in execution
model of expression evaluation between sparql and xquery, it's part
of how sparql queries are executed, and I think belongs better in the
section on constraints/value constraints and how they work.
>
> 11.2.1 Invocation
>
> SPARQL defines a syntax for invoking functions and operators on a set of
> arguments. These are invoked as follows:
> * Arguments expressions are evaluated, producing argument values. The
> order of argument evaluation is not defined.
> * For functions and operators where the expected type is specified as
> boolean, the effective boolean value is calculated.
^^^^^^^ xs:boolean ?
Where is the expected (return?) type specified? This means the list
in the table 11.1 - what about for extension functions (a few
sections later)?
also 11.2 calls it Result Type not expected type
> * Numeric arguments are promoted as necessary to fit the expected types
> for that function or operator.
> * The function or operator is invoked on the argument values.
>
> If any of these steps fails, the invocation generates an error. The effects
> of type errors are defined in SPARQL Functions and Operators.
>
> 11.2.1.1 Effective Boolean Value
>
> When a operand is coerced to xs:boolean through invoking a function that
> takes a boolean argument, the following rules apply:
^^^^^^^ xs:boolean
>
> The result is TRUE unless any of the following are true:
> * The operand is a boolean with a FALSE value.
^^^^^^^ xs:boolean
> * The operand is a 0-length untyped RDF literal or xs:string.
> * The operand is any numeric type with a value of 0.
> * The operand is an xs:double or xs:float with a value of NaN
>
> Table 11.1 Operator Mapping
>
> The SPARQL grammar identifies a set of operators (for instance, &&, *,
> isUri) used to construct constraints. This table associates each of these
> grammatical productions with an operator either defined by XQuery Operator
> Mapping or the additional SPARQL operators specified in section 11.2.2. The
> following table associates SPARQL infix operators taking specific argument
> types with the XPath operation name.
>
> CAPTION: SPARQL Operators
html: The links in the Operator column are still far too small to see
or click on.
> Operator Type(A) Type(B) Function Result type
some unary operations such as negation do not seem to be defined
here. I guess that should be:
Operator Type(A) Type(B) Function Result type
not(A) xs:boolean N/A fn:not(A) xs:boolean
From the draft, SPARQL also has (in UnaryExpression): unary minus and
unary plus operators which should point to:
http://www.w3.org/TR/2004/WD-xpath-functions-20041029/#func-numeric-unary-minus
http://www.w3.org/TR/2004/WD-xpath-functions-20041029/#func-numeric-unary-plus
somewhere.
(did bit negation ~ disappear?)
> XQuery Connectives
> A || B xs:boolean xs:boolean sop:logical-or(A, B) xs:boolean
> Returns a boolean: TRUE if either A or B is true, else FALSE.
> A && B xs:boolean xs:boolean sop:logical-and(A, B) xs:boolean
> Returns a boolean: TRUE if both A and B are true, else FALSE.
> XPath Tests
> A = B xs:string xs:string op:numeric-equal(fn:compare(A, B), 0) xs:boolean
> A != B xs:string xs:string fn:not(op:numeric-equal(fn:compare(A, B), 0))
> xs:boolean
> A = B numeric numeric op:numeric-equal(A, B) xs:boolean
> A = B xs:dateTime xs:dateTime op:dateTime-equal(A, B) xs:boolean
> A != B numeric numeric fn:not(op:numeric-equal(A, B)) xs:boolean
> A != B xs:dateTime xs:dateTime fn:not(op:dateTime-equal(A, B)) xs:boolean
> A < B numeric numeric op:numeric-less-than(A, B) xs:boolean
> A < B xs:dateTime xs:dateTime op:dateTime-less-than(A, B) xs:boolean
> A > B numeric numeric op:numeric-greater-than(A, B) xs:boolean
> A > B xs:dateTime xs:dateTime op:dateTime-greater-than(A, B) xs:boolean
> A <= B numeric numeric op:numeric-less-than(A, B) or op:numeric-equal(A, B)
> xs:boolean
> A <= B xs:dateTime xs:dateTime fn:not(op:dateTime-greater-than(A, B))
> xs:boolean
> A >= B numeric numeric op:numeric-greater-than(A, B) or op:numeric-equal(A,
> B) xs:boolean
> A >= B xs:dateTime xs:dateTime fn:not(op:dateTime-less-than(A, B))
> xs:boolean
> A * B numeric numeric op:numeric-multiply(A, B) numeric
> A / B numeric numeric op:numeric-divide(A, B) numeric; but xs:decimal if
> both operands are xs:integer
> A + B numeric numeric op:numeric-add(A, B) numeric
> A - B numeric numeric op:numeric-subtract(A, B) numeric
> SPARQL Tests: defined in section 11.2.2
> A = B r:term r:term sop:RDFterm-equal(A, B) xs:boolean
> A != B r:term r:term fn:not(sop:RDFterm-equal(A, B)) xs:boolean
> bound(A) variable N/A sop:isBound(A) xs:boolean
> isURI(A) variable N/A sop:isURI(A) xs:boolean
> isBlank(A) variable N/A sop:isBlank(A) xs:boolean
> isLiteral(A) variable N/A sop:isLiteral(A) xs:boolean
> matches(STRING, PATTERN [, FLAGS]) xs:string xs:string [, xs:string]
> fn:matches(STRING, PATTERN)
> fn:matches(STRING, PATTERN, FLAGS) xs:boolean
> The XPath fn:matches is defined on the basis of Unicode code points; it
> takes no account of collations ^___. (Unicode's Character Foldings)
> SPARQL Casts
> str(A) rdf:uri or rdf:literal N/A sop:str(A) xs:string
> lang(A) rdf:literal N/A sop:lang(A) xs:string
> datatype(A) rdf:literal N/A sop:datatype(A) rdf:uri
>
> ^___ fn:string-match requires a collation to define character order and string
> equivalence. The XQuery 1.0 and XPath 2.0 Functions and Operators [F&O]
> defines the semantics of fn:string-compare and establishes a default
> collation. In addition, it identifies a specific collation with a
> distinguished name,
> http://www.w3.org/2004/10/xpath-functions/collation/codepointwhichprovides
> the ability to compare strings based on code point values. Every
> implementation of SPARQL must support the collation based on code point
> values.
>
> 11.2.3 Operators introduced in SPARQL
>
> This section defines the operators introduced by the SPARQL Query language.
> The names of the operators are prefixed with sop:. The examples show the
> behavior of the operators as invoked by the appropriate grammatical
> constructs.
>
> 11.2.3.1 sop:RDFterm-equal
>
> Returns TRUE if the two arguments are the same RDF term or they are known to
> be semantically equivalent. The latter is tested with an XQuery function
> appropriate to the arguments. This function is overloaded because there is
> no syntactic way to separate xs:string = xs:string from r:literal =
> r:literal (or r:uri or r:bNode). I think I'm happy with that. Are you, dear
> reader?
>
> The following sop:RDFterm-equal example passes the test because the mbox
> terms are the same RDF term:
>
> ?u = ?v
>
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>
> _:a foaf:name "Alice".
> _:a foaf:mbox <mailto:alice@work.example> .
>
> _:b foaf:name "Ms A.".
> _:b foaf:mbox <mailto:alice@work.example> .
>
> This query finds the people who have multiple foaf:name arcs:
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?name1 ?name2
> WHERE { ?x foaf:name ?name1 ;
> foaf:mbox ?mbox1 .
> ?y foaf:name ?name2 ;
> foaf:mbox ?mbox2 .
> FILTER ?mbox1 = ?mbox2 && ?name1 != ?name2
> }
>
> Query result:
>
> name1 name2
> "Alice" "Ms A."
>
> In this query for documents that were annotated on new years day (2004 or
> 2005), the RDF terms are not the same, but have equivalent values:
>
> @prefix a: <http://www.w3.org/2000/10/annotation-ns#>
> @prefix dc: <http://purl.org/dc/elements/1.1/>
>
> _:b a:annotates <http://www.w3.org/TR/rdf-sparql-query/> .
> _:b dc:created "2004-12-31T19:01:00-05:00"^^http://www.w3.org/2001/XMLSche
> ma#dateTime .
syntax error, should be:
... "2004-12-31T19:01:00-05:00"^^<http://www.w3.org/2001/XMLSche ma#dateTime>
>
> PREFIX a: <http://www.w3.org/2000/10/annotation-ns#>
> PREFIX dc: <http://purl.org/dc/elements/1.1/>
> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
>
> SELECT ?annotates
> WHERE { ?annot a:annotates ?annotates .
> ?annot dc:created ?date .
> FILTER ?date = xsd:dateTime("2004-01-01T00:00Z" || ?date = xsd:dateTime
> ("2005-01-01T00:00Z") }
>
> annotates
> <http://www.w3.org/TR/rdf-sparql-query/>
>
> 11.2.3.2 sop:bound
>
> Queries with union and optionals may have solutions with some unbound
html: uppercase the union and optionals keywords
> variables. The operator bound tests that a variable has been bound to a
> value. NaNs and INFs count as defined.
>
> bound(?v)
>
> Data:
>
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> @prefix dc: <http://purl.org/dc/elements/1.1/>
> @prefix xs: <http://www.w3.org/2001/XMLSchema#>
>
> _:a foaf:name "Alice".
>
> _:b foaf:givenname "Bob" .
> _:b dc:created "2005-04-04T04:04::04Z"^^xs:dateTime .
>
> This query matches the people with a name and an mbox:
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> PREFIX dc: <http://www.w3.org/2001/XMLSchema#>
> SELECT ?name ?givenName
> WHERE { { ?x foaf:name ?name } UNION { ?x foaf:givenName ?givenName; dc:creat
> ed ?created }
> FILTER bound(?name) || ?created < "2005-01-01T00:00::00Z" }
syntax: I think that should be:
FILTER bound(?name) || ?created < xsd:dateTime("2005-01-01T00:00::00Z") }
in order for it to be a dateTime comparison.
>
> Query result:
>
> name givenName
> "Alice"
>
> One may test that a graph pattern is not expressed by specifying an optional
> graph pattern that introduces a variable and testing to see that the
> variable is not bound. This is called Negation as Failure in logic
> programming.
>
> This query matches the people with a name but no expressed mbox:
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?name
> WHERE { ?x foaf:name ?name )
> OPTIONAL { ?x foaf:mbox ?mbox }
> FILTER !bound(?mbox) }
>
> Query result:
>
> name
> "Bob"
>
> Because Alice's mbox was known, "Alice" was not a solution to the query.
>
> 11.2.3.3 sop:isURI
>
> Returns whether a variable is bound to a URI.
>
> isURI(?v)
>
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>
> _:a foaf:name "Alice".
> _:a foaf:mbox <mailto:alice@work.example> .
>
> _:b foaf:name "Bob" .
> _:b foaf:mbox "bob@work.example" .
>
> This query matches the people with a name and an mbox which is a URI:
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?name ?mbox
> WHERE { ?x foaf:name ?name ;
> foaf:mbox ?mbox .
> FILTER isUri(?mbox) }
isUri here, ISURI at start of doc. Style I guess.
>
> Query result:
>
> name mbox
> "Alice" <mailto:alice@work.example>
>
> 11.2.3.4 sop:isBlank
>
> Returns whether a variable is bound to a bNode (blank node).
>
> isBlank(?v)
>
> @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:creator "Alice B. Toeclips" .
>
> _:b a:annotates <http://www.w3.org/TR/rdf-sparql-query/> .
> _:b dc:creator _:c .
> _:c foaf:given "Bob".
> _:c foaf:family "Smith".
>
> This query matches the people with a name and an mbox which is a URI:
> PREFIX a: <http://www.w3.org/2000/10/annotation-ns#>
> PREFIX dc: <http://purl.org/dc/elements/1.1/>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>
> SELECT ?annot ?given ?family
> WHERE { ?annot a:annotates <http://www.w3.org/TR/rdf-sparql-query/> .
> ?annot dc:creator ?c .
> OPTIONAL { ?c foaf:given ?given ; foaf:family ?family } .
> FILTER isBlank(?c)
> }
>
> Query result:
>
> given family
> "Bob" "Smith"
>
> In this example, there were two objects of foaf:knows predicates, but only
> one (_:c) was a bNode.
>
> 11.2.3.5 sop:isLiteral
>
> Returns whether the argument is a literal.
>
> isLiteral(?v)
>
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>
> _:a foaf:name "Alice".
> _:a foaf:mbox <mailto:alice@work.example> .
>
> _:b foaf:name "Bob" .
> _:b foaf:mbox "bob@work.example" .
>
> This query is similar to the one in 1.2.1.3 except that is matches the
> people with a name and an mbox which is a Literal. This would be used to
s/would/could/
it's a possibility, not a requirement
> look for erroneous data (foaf:mbox should only have a URI as its object).
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?name ?mbox
> WHERE { ?x foaf:name ?name ;
> foaf:mbox ?mbox .
> FILTER isLiteral(?mbox) }
I wasn't convinced by this example. !isUri(?mbox) would actually do
what the example says - ensure foaf:mbox only has a URI as it's object
>
> Query result:
>
> name mbox
> "Bob" "bob@work.example"
>
> 11.2.3.6 sop:str
>
> Returns an xs:string representation of an r:URI. This useful for examining
insert: is
> parts of a URI, for instance, the host-name.
>
> str(?v)
>
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>
> _:a foaf:name "Alice".
> _:a foaf:mbox <mailto:alice@work.example> .
>
> _:b foaf:name "Bob" .
> _:b foaf:mbox <mailto:bob@home.example> .
>
> This query selects the set of people who use their work.example address in
> their foaf profile:
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?name ?mbox
> WHERE { ?x foaf:name ?name ;
> foaf:mbox ?mbox .
> FILTER regex(str(?mbox), "@work.example") }
>
> Query result:
>
> name mbox
> "Alice" <alice@work.example>
>
> 11.2.3.7 sop:lang
>
> Returns a valid RFC 3066 language string representing the XML schema
> language datatype for a variable.
>
> lang(?v)
>
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>
> _:a foaf:name "Robert"@EN.
> _:a foaf:name "Roberto"@ES.
> _:a foaf:mbox <mailto:bob@work.example> .
>
> This query finds the Spanish foaf:name and foaf:mbox:
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?name ?mbox
> WHERE { ?x foaf:name ?name ;
> foaf:mbox ?mbox .
> FILTER lang(?name) = "ES" }
Hmm, xml:lang values should do case independent compares (or
smarter). should we make/allow lang() to do normalising, say to
lower/upper case?
>
> Query result:
>
> name mbox
> "Roberto"@ES <mailto:bob@work.example>
>
> 11.2.3.8 sop:datatype
>
> Returns the datatype of its argument if that argument is a typed literal.
> Otherwise it fails.
>
> datatype(?v)
>
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> @prefix eg: <http://biometrics.example/ns#> .
> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
>
> _:a foaf:name "alice".
> _:a eg:shoeSize "9.5"^^xsd:float .
>
> _:b foaf:name "bob".
> _:b eg:shoeSize "42"^^<http://...integer> .
>
> This query finds everyone's foaf:name and integer foaf:shoeSize:
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
> PREFIX eg: <http://biometrics.example/ns#>
> SELECT ?name ?size
> WHERE { ?x foaf:name ?name ; eg:shoeSize ?size .
> FILTER datatype(?size) = xsd:float }
>
> Query result:
>
> name shoeSize
> "Bob" 42
>
> 11.2.3.9 sop:logical-or
>
> Returns a logical OR of the arguments. As with other functions and operators
> with boolean arguments, sop:logical-or operates on the effective boolean
> value of its arguments.
>
> ?u || ?v
>
> 11.2.3.10 sop:logical-and
>
> Returns a logical AND of the arguments. As with other functions and
> operators with boolean arguments, sop:logical-and operates on the effective
> boolean value of its arguments.
>
> ?u && ?v
>
> Table 11.2 SPARQL Casting Functions
>
> SPARQL imports casting functions from the XPath. The XQuery Functions &
> Operators Primitive Type Mapping table [17] specifies a which primitive
> types are castable to which other primitive types. The table is reproduced
> below, omitting casting operations that are not in the SPARQL language, and
> adding the additional datatypes imposed by the RDF data model.
>
> bool = xs:boolean
> dbl = xs:double
> flt = xs:float
> dec = xs:decimal
> int = xs:integer
> dT = xs:dateTime
> str = xs:string
> URI = r:URIRef ___ introduced by the RDF data model
> ltrl = r:Literal ___ introduced by the RDF data model
Could we please have a key for this table S\T, Y M, N need explaining
This shouldn't be a pointer to another doc
>
> S\T str flt dbl dec int dT bool URI ltrl
> str Y M M M M M M M M
> flt Y Y Y M M N Y N N
> dbl Y Y Y M M N Y N N
> dec Y Y Y Y Y N Y N N
> int Y Y Y Y Y N Y N N
> dT Y N N N N Y N N N
> bool Y Y Y Y Y N Y N N
> URI Y N N N N N N Y N
> ltrl Y M M M M M M M Y
>
> 11.3 Extensible Value Testing
>
> Implementations may provide custom extended value testing operations, for
> example, for specialized datatypes. These are provided by functions in the
> query that return true or false for their arguments.
>
> qname( expression, expression , ...)
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> PREFIX my: <http://my.example/functions#>
> SELECT ?name ?id
> WHERE { ?x foaf:name ?name ;
> my:empId ?id .
> FILTER my:even(?id) }
> PREFIX myGeo: <http://my.example.org/geo#>
>
> SELECT ?x ?y
> WHERE { ?x myGeo:placeName "SWEB Town" .
> ?x myGeo:location ?xLoc .
> ?y myGeo:location ?yLoc .
> FILTER myGeo:distance(?x, ?y) < 10 .
> }
>
> A function returns an RDF term. It might be used to test some application
> datatype not supported by the core SPARQL specification, it might be a
> transformation between datatype formats, for example into an XSD dateTime
> RDF term from another date format.
>
> The function is called during FILTER evaluation for each possible query
> solution. A function is named by URI in a QName form, and returns an RDF
> term.
>
> If a query processor encounters a function that it does not provide, the
> query is not executed and an error is returned.
>
> Functions should have no side-effects. A SPARQL query processor may remove
> calls to functions if it can optimize them away.
>
> A. SPARQL Grammar
This section NOT REVIEWED, skip to references
>
> Section status: drafted ___ terminal syntax not checked against that of the
> XML 1.1 spec
>
> A SPARQL query is a sequence of characters in the language defined by the
> following grammar, starting with the Query production. The EBNF format is
> the same as that used in the XML 1.1 specification. Please see the
> "Notation" section of that specification for specific information about the
> notation.
>
> Whitespace
>
> Whitespace is used to separate two terminals which would otherwise be
> (mis-)recognized as one terminals. Whitespace in terminals is significant.
> Otherwise whitespace is ignored. Terminals are shown below enclosed in <> or
> shown in-line.
>
> Keywords
>
> Keywords are shown in uppercase and are matched in a case insensitive
> manner. The exception is the keyword 'a' which, in line with Turtle and N3,
> is used in place of the URI rdf:type (in full,
> http://www.w3.org/1999/02/22-rdf-syntax-ns#type).
>
> Comments
>
> Comments in SPARQL queries take the form of '#', outside a URI or string,
> and continue to the end of line or end of file if there is no end of line
> after the comment marker.
> * We expect to state some formal characteristics of the grammar in later
> drafts.
>
>
> [1] Query ::= Prolog
> ( SelectClause | ConstructClause | DescribeClause | AskClause )
> WhereClause ?
> OrderClause ?
> LimitClause ?
> OffsetClause ?
> [2] Prolog ::= BaseDecl? PrefixDecl*
> [3] BaseDecl ::= 'base' QuotedURIref
> [4] PrefixDecl ::= 'prefix' <QNAME_NS> QuotedURIref
> [5] SelectClause ::= 'select' 'distinct'? Var+
> | 'select' 'distinct'? '*'
> [6] DescribeClause ::= 'describe' VarOrURI+
> | 'describe' '*'
> [7] ConstructClause ::= 'construct' ConstructTemplate
> [8] AskClause ::= 'ask'
> [9] WhereClause ::= 'where'? GraphPattern
> [10] OrderClause ::= 'order' 'by' OrderCondition+
> [11] OrderCondition ::= ( 'asc' | 'desc' ) '[' OrderExpression ']'
> | OrderExpression
> [12] OrderExpression ::= FunctionCall | Var
> [13] LimitClause ::= 'limit' <INTEGER_10>
> [14] OffsetClause ::= 'offset' <INTEGER_10>
> [15] GraphPattern ::= '{' ( PatternElement ( '.' PatternElement )* (
> '.' )? )? '}'
> [16] PatternElement ::= Triples
> | OptionalGraphPattern
> | UnionGraphPattern
> | GraphPattern
> | GraphGraphPattern
> | Constraint
> [17] OptionalGraphPattern ::= 'optional' GraphPattern
> [18] GraphGraphPattern ::= 'graph' VarOrBNodeOrURI GraphPattern
> [19] UnionGraphPattern ::= GraphPattern ( 'union' GraphPattern )*
> [20] Constraint ::= 'filter' Expression
> [21] ConstructTemplate ::= '{' Triples ( '.' Triples )* ( '.' )? '}'
> [22] Triples ::= VarOrTerm PropertyList
> | TriplesNode PropertyList?
> [23] PropertyList ::= ( VarOrURI | 'a' ) ObjectList ( ';' PropertyList
> )?
> | Reification
> [24] ObjectList ::= VarOrTerm
> | TriplesNode ( ',' ObjectList )?
> [25] TriplesNode ::= Collection
> | BlankNodePropertyList
> | Reification
> [26] BlankNodePropertyList ::= '[' PropertyList ']'
> [27] Reification ::= "<<" GraphNode GraphNode GraphNode ">>"
> [28] Collection ::= '(' GraphNode+ ')'
> [29] GraphNode ::= VarOrTerm
> | TriplesNode
> [30] VarOrTerm ::= Var | GraphTerm
> [31] VarOrURI ::= Var | URI
> [32] VarOrBNodeOrURI ::= Var | BlankNode | URI
> [33] Var ::= <VAR>
> [34] GraphTerm ::= RDFTerm | '(' ')'
> [35] Expression ::= ConditionalOrExpression
> [36] ConditionalOrExpression ::= ConditionalAndExpression ( '||'
> ConditionalAndExpression )*
> [37] ConditionalAndExpression ::= ValueLogical ( '&&' ValueLogical )*
> [38] ValueLogical ::= RelationalExpression
> [39] RelationalExpression ::= NumericExpression
> ( '=' NumericExpression
> | '!=' NumericExpression
> | '<' NumericExpression
> | '>' NumericExpression
> | '<=' NumericExpression
> | '>=' NumericExpression )?
> [40] NumericExpression ::= AdditiveExpression
> [41] AdditiveExpression ::= MultiplicativeExpression
> ( '+' MultiplicativeExpression
> | '-' MultiplicativeExpression )*
> [42] MultiplicativeExpression ::= UnaryExpression ( '*'
> UnaryExpression | '/' UnaryExpression )*
> [43] UnaryExpression ::= '!' CallExpression
> | '+' CallExpression
> | '-' CallExpression
> | CallExpression
> [44] CallExpression ::= 'str' '(' Expression ')'
> | 'lang' '(' Expression ')'
> | 'datatype' '(' Expression ')'
> | <REGEX> '(' Expression ',' String ( ',' String )? ')'
> | 'bound' '(' Var ')'
> | 'isURI' '(' Expression ')'
> | 'isBlank' '(' Expression ')'
> | 'isLiteral' '(' Expression ')'
> | FunctionCall
> | PrimaryExpression
> [45] PrimaryExpression ::= Var | RDFTerm | '(' Expression ')' )
> [46] FunctionCall ::= URI '(' ArgList ')'
> [47] ArgList ::= ( Expression ( ',' Expression )* )?
> [48] RDFTerm ::= URI | RDFLiteral | NumericLiteral | BooleanLiteral |
> BlankNode
> [49] NumericLiteral ::= Integer | FloatingPoint
> [50] RDFLiteral ::= String ( ( <LANGTAG> )
> | ( '^^' URI ) )?
> [51] BooleanLiteral ::= 'true'
> | 'false'
> [52] String ::= <STRING_LITERAL1> | <STRING_LITERAL2>
> [53] URI ::= QuotedURIref | QName
> [54] QName ::= <QNAME> | <QNAME_NS>
> [55] BlankNode ::= <BNODE_LABEL> | '[' ']'
> [56] QuotedURIref ::= <Q_URIref>
> [57] Integer ::= <INTEGER_10>
> [58] FloatingPoint ::= <FLOATING_POINT>
> [59] <Q_URIref> ::= '<' ([^> ])* '>' /* A URI relative reference : RFC
> 3896 */
> [60] <QNAME_NS> ::= <NCNAME_PREFIX>? ':'
> [61] <QNAME> ::= <NCNAME_PREFIX>? ':' (<NCNAME1>
> |<NCNAME2>)?
> [62] <BNODE_LABEL> ::= '_:' ( <NCNAME1> | <NCNAME2> )
> [63] <VAR> ::= ('?'|'$') (<NCNAME2> | <NCNAME1> )
> [64] <LANGTAG> ::= '@' <A2Z>+ ('-' (<A2ZN>)+)*
> [65] <A2Z> ::= [a-zA-Z]
> [66] <A2ZN> ::= [a-zA-Z0-9]
> [67] <INTEGER_10> ::= <DIGITS>
> [68] <FLOATING_POINT> ::= [="token">'a'.' [0-9]* <EXPONENT>?
> | '.' ([0-9])+ <EXPONENT>?
> | ([0-9])+ <EXPONENT>
> [69] <EXPONENT> ::= [eE] [+-]? [0-9]+
> [70] <STRING_LITERAL1> ::= "'" ( ([^'\\\n\r])
> | ('\\' [^\n\r]) )* "'"
> [71] <STRING_LITERAL2> ::= '"' ( ([^"\\\n\r])
> | ('\\' [^\n\r]) )* '"'
> [72] <DIGITS> ::= [0-9]+
> [73] <NCCHAR1> ::= [A-Z] | [a-z]
> | [#x00C0-#x00D6] | [#x00D8-#x00F6] | [#x00F8-#x02FF]
> | [#x0370-#x037D] | [#x037F-#x1FFF] | [#x200C-#x200D]
> | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF]
> | [#xF900-#xFFFF]
> [74] <NCCHAR_END> ::= <NCCHAR1> | '_' | '-' | [0-9] | #x00B7
> [75] <NCCHAR_FULL> ::= <NCCHAR_END> | '.'
> [76] <NCNAME1> ::= <NCCHAR1> (<NCCHAR_FULL>* <NCCHAR_END>)?
> [77] <NCNAME2> ::= '_' (<NCCHAR_FULL>* <NCCHAR_END>)?
> [78] <NCNAME_PREFIX> ::= <NCCHAR1> <NCCHAR_FULL>*
>
> B. References
>
> @@ToDo@@ Split into acknowledgements and references, noting whether
> normative or not.
>
> References
>
> @@ToDo@@How many of these are still used?
>
> @@ToDo@@Mention SeRQL or reference emails
Yes, please cite SeRQL.
These should also be in the w3c references style, linking to specifc
versions, now more important if XML F&O detail is changing and we
rely on it.
>
> [1] "Three Implementations of SquishQL, a Simple RDF Query Language", Libby
> Miller, Andy Seaborne, Alberto Reggiori; ISWC2002
>
> [2] "RDF Query and Rules: A Framework and Survey", Eric Prud'hommeaux
>
> [3] "RDF Query and Rule languages Use Cases and Example", Alberto Reggiori,
> Andy Seaborne
>
> [4] RDQL Tutorial for Jena (in the Jena tutorial).
>
> [5] RDQL BNF from Jena
>
> [6] Enabling Inference, R.V. Guha, Ora Lassila, Eric Miller, Dan Brickley
>
> [7] N-Triples
>
> [8] RDF http://www.w3.org/RDF/
>
> [9] "Representing vCard Objects in RDF/XML", Renato Iannella, W3C Note.
>
> [10] "RDF Data Access Working Group"
>
> [11] "RDF Data Access Use Cases and Requirements ? W3C Working Draft 2 June
> 2004", Kendall Grant Clark.
>
> [12] "Resource Description Framework (RDF): Concepts and Abstract Syntax",
> Graham Klyne, Jeremy J. Carroll, W3C Recommendation.
>
> [13] RFC 3986, "Uniform Resource Identifier (URI): Generic Syntax", T.
> Berners-Lee, R. Fielding, L. Masinter
>
> [14] "Namespaces in XML 1.1", Tim Bray et al., W3C Recommendation.
>
> [15] "Turtle - Terse RDF Triple Language, Dave Beckett.
>
> [16] "SPARQL Variable Binding Results XML Format", Dave Beckett.
>
> [17] "XQuery 1.0 and XPath 2.0 Functions and Operators", Ashok Malhotra et
> al., W3C Working Draft.
Received on Thursday, 7 April 2005 14:39:43 UTC