- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Thu, 02 Dec 2004 17:13:42 +0000
- To: Kevin Wilkinson <wilkinson@hpl.hp.com>
- CC: public-rdf-dawg@w3.org
Changes in sections 3 to 6 inclusive:
> 3 Working with RDF Literals
>
> -RDF Literals are written in SPARQL as strings, with optional language
> tag (indicted by '@') or optional datatype (indicated by '^^'), with
> additional convenience forms for xsd:integers and xsd:doubles:-
>
> +An RDF Literal is written in SPARQL as a string containing the lexical
> form of the literal delimited by doulbe quotes, optionally followed by a
> language tag (indicated by '@') or a datatype (indicated by '^^'). There
> are convenience forms for the numeric-typed literals xsd:integer and
> xsd:double in which the datatype may be omitted.+
Done.
>
> 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
>
>
> 3.1 Matching RDF Literals
>
> The dataset 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 .
>
> -The pattern in the query matches because 42 is interpreted as "42" with
> datatype URI | http://www.w3.org/2001/XMLSchema#integer.-|
>
> The pattern in the following query has a solution because 42 is
> interpreted as "42"^^ |http://www.w3.org/2001/XMLSchema#integer.+|
>
> SELECT ?v WHERE (?x ?p 42)
>
> -This query matches, without requiring the query processor to have any
> understanding of the values in the space:-
>
> +The following query has one solution. Note that the query processor has
> no understanding of the datatype. This is a syntactic match.+
>
> SELECT ?v WHERE ( ?x ?p "abc"^^<http://example.org/datatype#specialDatatype> )
>
> -This query has a pattern that-+The following query+ fails to match
> because "cat" is not the same RDF literal as "cat"@en:
>
> SELECT ?v WHERE ( ?x ?p "cat" )
>
> but -this does find-+the following query does have+ a solution:
>
> SELECT ?v WHERE ( ?x ?p "cat"@en )
Changed to talk about "solutions" not matches.
>
> *Implementation Requirements*
>
> An implementation of SPARQL only needs to -be able to- match +lexical+
> forms and datatypes in graph patterns. It is not required to -provide-
> support the datatype hierarchy of XML schema
> <http://www.w3.org/TR/xmlschema-2/#built-in-datatypes> nor -for-+any+
> application-defined hierarchies. It is not required to provide matching
> in patterns based on value spaces. Thus, testing +numerical+ equality in
> a constraint is not identical to +literal matching+ in pattern matching.
>
> (KW Comment: I don't follow this. It seems to say that constraint
> matching is different from pattern matching but I don't understand why.
> Could you motivate this? It seems intuitive that the two queries below
> should return the same result.)
It is different and it is unfortunate but either way produces a surprise.
Triple stores today don't store values - they store lexical forms and do look up
on same. So "42"^^xsd:short is not matched by "42"^^xsd:byte but, as values,
they are the same. ==, taking from F&O is a value test.
Making graph matching do datatype processing is not required in RDF but having
numercial operations do value comparisons, when XSD datatypes do have a defined
hierarchy, is also strange.
>
> In this dataset,
>
> @prefix ns: <http://example.org/ns#> .
> @prefix : <http://example.org/ns#> .
> @prefix xsd: <|http://www.w3.org/2001/XMLSchema#> .|
>
> :x ns:p "42"^^xsd:short .
>
> there is no match required for the query:
>
> SELECT ?v WHERE ( ?x ?p 42 )
>
> but there is for this query,
>
> SELECT ?v WHERE ( ?x ?p ?v ) AND ?v == 42
>
> because of the use of numeric +equallity+.
No - "equality" in my spellchecker :-)
>
> An implementation may choose to -provide-+support+ datatype hierarchies
> and value based pattern matching. Applications using a SPARQL processor
> should not assume that the processor provides datatype hierarchies or
> matching based on value-spaces of literals unless the application knows
> explicitly that this is the case.
>
>
> 3.2 Constraining Values
>
> Graph pattern matching creates bindings of variables. It is possible to
> further restrict possible 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 filter functions.
>
> 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 dc:title ?title )
> ( ?x ns:price ?price ) AND ?price < 30
>
> Query Result:
>
> title price
> "The Semantic Web" 23
>
> By having a constraint on the "price" variable, only one of the books
> matches the query. Like a triple pattern, this is just a restriction on
> the allowable values of a variable.
>
> *Definition:* Constraints
>
> A constraint is a boolean-valued expression of variables and RDF Terms
> that can be applied to restrict query solutions.
>
> *Definition:* Graph Pattern (Partial Definition) â?? Constraints
>
> A graph pattern can also include constraints. These constraints further
> restrict the possible query solutions of matching a graph pattern with a
> graph.
>
> SPARQL defines a set of operations <#StandardOperations> that all
> implementations must provide. In addition, there is an extension
> mechanism <#TestingExtensions> for boolean tests that are specific to an
> application domain or kind of data.
>
> (KW Comment: 1) you should reference the section number (11.3?). this
> helps readers who print this document. 2) may a constraint reference
> another variable, e.g. ?x < ?y. it's not clear if this is allowed or not.)
Reference included. In that section, ?x < ?y is allowed because of the way that
op:numeric-less-than works.
It woudl take another complete example to talk about this. I don't think it is
worth it at the moment but if another example is going in for something else,
then I can explicitly cover it.
>
> A constraint may lead to an error condition when testing some variable
> binding. The exact error will depend on the constraint: in numeric
> operations, supplying a non-number or a bNode will lead to such an
> error. Any potential solution that causes an error condition in a
> constraint will not form part of the final results.
>
> (KW Comment: Is any error indication provided or is it silent or
> implementation-dependent. Please specify.)
No (standard) error provided but then there is no standard way of providing
results at all in rq23. That could go in the protocol if anywhere. In terms of
query results, the effect is as stated - no such solution included. SPARQL only
has positive tests -- "all solutions for which is is true that (..query patten +
constraints..)"
>
>
> 4 Including Optional Values
>
> ...
>
>
> 4.1 Optional Matching
>
> Optional -portions of the-+matches on a+ graph may be specified in
> either of two equivalent ways:
"""
Optional parts of the graph pattern may be specified in either of two equivalent
ways:
"""
we are avoiding "matches".
>
> OPTIONAL (?s ?p ?o)...
>
> [ (?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" .
>
> -Query (these two are the same query using slightly different syntax):-
>
> +The following two queries have different syntax but identical semantics:+
"""
The following two queries have different syntax but give the same results:
"""
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?name ?mbox
> WHERE ( ?x foaf:name ?name )
> OPTIONAL ( ?x foaf:mbox ?mbox )
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?name ?mbox
> WHERE ( ?x foaf:name ?name )
> [ ( ?x foaf:mbox ?mbox ) ]
>
> Query result:
>
> name mbox
> "Alice" <mailto:alice@example.com>
> "Bob"
>
> Now, there is no value of mbox where the name is "Bob". It is left
> -unset-+unbound+ in the result.
>
> (KW Comment: I think this raises the question of HOW to determine if a
> variable is unset/unbound in a result. Does SPARQL assume this is
> implementation-dependent? Or does it require that an implementation
> provide an isBound function? This should be stated.)
The variable is not part of a binding in a substitution.
Some implementations may use internal things like NULLs but that's their choice.
Other implementations do not use a special value for not bound.
isBound is later in section 11 - but it's broken / needs to be better defined.
>
> This query finds the names of people in the dataset, and, if there is an
> mbox property, +retrieves+ that 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 a graph pattern.
"""
This query finds the names of people in the dataset, and, if there is a triple
with predicate mbox and same subject, retrieves the object of that triple as well.
"""
>
> For each optional block, the query processor attempts to match the query
> pattern. Failure to match the block does not cause this query solution
> to be rejected. The whole graph pattern of an optional block must match
> for the optional to add to the query solution.
>
> (KW Comment: you should state if or if not there may be constraints in
> an optional block. Also, I think a good conceptual model for
> understanding optional blocks is that all solutions are found for the
> required part of the query. Then, for each solution, each optional block
> is tried and additional bindings are defined. Is this description worth
> including? Perhaps it will help in understanding the optional blocks.)
Example of constraints in an optional block added. New section 4.2.
That conceptual model is correct but it is procedural. Until now, the language
in the document avoids it because order does not matter.
>
>
> 4.2 Multiple Optional Blocks
>
> A query may have zero or more top-level optional blocks. These blocks
> will fail or provide bindings independently. Optional blocks can also be
> nested, that is, an optional block may appear inside another optional
> block +(as described in Section 5)+.
That particular case is described in this section. Section 5 generalises it.
"""
A query may have zero or more top-level optional blocks. These blocks will fail
or provide bindings independently. SPARQL graph patterns can have nested blocks
(see section 5); optional blocks can be nested, that is, an optional block may
appear inside another optional block.
"""
>
> 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 )
> [ ( ?x foaf:mbox ?mbox ) ]
> [ ( ?x foaf:homepage ?hpage ) ]
>
> Query result:
>
> name mbox hpage
> "Alice" <http://work.example.org/alice/>
> "Bob" <mailto:bob@example.com>
>
> In this example, there are two independent optional blocks. Each depends
> only on variables defined in the non-optional part of the graph pattern.
> If a new variable is mentioned in an optional block (as mbox and hpage
> are mentioned in the previous example), that variable can be mentioned
> in that block and can not be mentioned in a subsequent block.
>
>
> 4.3 Optional Matching â?? Formal Definition
>
> In an optional match, either a graph pattern matches a graph and so
> defines one or more pattern solutions, or gives an empty pattern
> solution but does not cause matching to fail overall.
>
> *Definition:* Optional Matching
>
> Given graph pattern GP1, and graph pattern GP2, let GP= (GP1 union GP2).
>
> The optional match of GP2 of graph G, given GP1, defines a pattern
> solution PS such that:
>
> If GP matches G, then the solutions of GP is the patterns solutions of
> GP else the solutions are the pattern solutions of GP1 matching G.
>
>
> 5 Nested Patterns
>
> Graph patterns may contain nested patterns. -We've seen this earlier in
> optional matches <#OptionalMultiple>. Nested patterns are delimited with
> ()s:- (KW Comment: you haven't really seen it; it was just mentioned but
> not explained. I'd drop this sentence.)
"""
Graph patterns may contain nested patterns. Nested patterns are delimited with
{}s, that is, braces, and in the special case of optionals blocks, by using[]
"""
>
> { ( ?s ?p ?n2 ) ( ?n2 ?p2 ?n3 ) }
>
> *Definition:* Graph Pattern â?? Nesting
>
> A graph pattern GP can contain other graph patterns GP_i . A query
> solution of Graph Pattern GP on graph G is any B such that each element
> GP_i of GP matches G with binding B.
>
> For example:
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?name ?foafmbox
> WHERE ( ?x foaf:name ?name )
> { ( ?x foaf:mbox ?mbox ) }
>
> Because this example has a simple conjunction for the nested pattern,
> and because the nested pattern is a conjunctive element in the outer
> pattern, this has the same results:
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> SELECT ?name ?foafmbox
> WHERE ( ?x foaf:name ?name ) ( ?x foaf:mbox ?mbox )
>
> Optional blocks can be nested. The outer optional block must match for
> any nested one to apply. That is, the outer graph pattern pattern is
> fixed for the purposes of any nested optional block.
>
> 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 _:d .
>
> _:d vcard:Family "Hacker" .
> _:d vcard:Given "Alice" .
>
> _:b foaf:name "Bob" .
> _:b foaf:mbox <mailto:bob@work.example> .
>
> _:c foaf:name "Eve" .
> _:c vcard:N _:e .
>
> _:e vcard:Family "Hacker" .
> _:e vcard:Given "Eve" .
>
>
> Query:
>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> PREFIX vcard: <http://www.w3.org/2001/vcard-rdf/3.0#>
> SELECT ?foafName ?mbox ?fname ?gname
> WHERE ( ?x foaf:name ?foafname )
> [ ( ?x foaf:mbox ?mbox ) ]
> [ ( ?x vcard:N ?vc )
> [ ( ?vc vcard:Family ?fname )
> ( ?vc vcard:Given ?gname )
> ]
> ]
>
> Query result:
>
> foafName mbox fname gname
> "Alice" <mailto:alice@work.example> "Hacker" "Alice"
> "Bob" <mailto:bob@work.example>
> "Eve" "Hacker" "Eve
>
> This query finds the name, optionally the mbox, and also optionally the
> vCard structured name components. By nesting the optional access to
> vcard:Family and vcard:Given, the query only reaches these if there is a
> vcard:N property. 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.
>
> (KW Comment: this example could be more illustrative. In particular, the
> result of this query is the same without the nesting, i.e., if Family
> and Given are part of the top-level, vcard:N block. It would be more
> interesting if there were an additional person with a vcard but no
> family or given name. Then, the top-level optional block would match but
> not the nested blocks. Would it return a result or not? This would
> improve the example since, for me, the result is somewhat ambiguous.)
Changed the query to get information in the outer nesting as well.
>
>
> 5.1 Nested Optional Blocks
>
> There is an additional condition that must be met for nested optional
> blocks. Considering the -query-+graph+ pattern as a tree of blocks, then
> a variable in an optional block can only be mentioned in other optional
> blocks nested within -this one-+it+. 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.
>
> -All occurences of variable, v, in a query, the outermost mention of v
> must be the same.-+For each variable v that occurs in a nested block,
> consider all paths from that variable in any block to the root of the
> tree. Those paths must all intersect at a block that also contains the
> variable v.+
Thanks for the wording.
>
> Suggestions for better wording most welcome!
>
> 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 -was-
> introduced and was used to constrain. Such a query could give different
> results depending on the order in which those blocks were evaluated.
>
Typos done.
>
> 6 More Pattern Matching â?? Alternatives
>
> +SPARQL provides a means combining graph patterns in to more complex
> ones so that one of several possibilities is attempted to see if it
> matches.-+SPARQL provides a means 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.
Sugested text used.
>
> * Or call it OR
(Aside: That is now done).
>
>
> 6.1 Joining Patterns with UNION
>
> The UNION keyword is the syntax for pattern alternatives.
>
> Data:
>
> @prefix dc10: <http://purl.org/dc/elements/1.0/> .
> @prefix dc11: <http://purl.org/dc/elements/1.1/> .
>
> _:a dc10:title "SPARQL Query Language Tutorial" .
> _:a dc10:creator "Alice" .
>
> _:b dc11:title "SPARQL Protocol Tutorial" .
> _:b dc11:creator "Bob" .
>
> Query:
>
> PREFIX dc10: <http://purl.org/dc/elements/1.1/>
> PREFIX dc11: <http://purl.org/dc/elements/1.0/>
>
> SELECT ?title
> WHERE ( ?book dc10:title ?title ) UNION ( ?book dc11:title ?title )
>
> Query result:
>
> title
> "SPARQL Protocol Tutorial"
> "SPARQL Query Language Tutorial"
>
> This query finds titles of the books in the dataset, whether the title
> is recorded using Dublin Core <http://dublincore.org/> 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.1/>
> PREFIX dc11: <http://purl.org/dc/elements/1.0/>
>
> SELECT ?title10 ?title11
> WHERE ( ?book dc10:title ?title10 ) UNION ( ?book dc11:title ?title11 )
>
> title11 title10
> "SPARQL Protocol Tutorial" Â
> Â "SPARQL Query Language Tutorial"
>
> will return results with the variables title10 or title11 bound
> depending on which way the query processor matches the pattern to the
> dataset. Note that, unlike optionals, if no part of the union pattern
> matched, then the query pattern would not match.
>
> (KW Comment: the above examples are a bit misleading as they suggest
> that the variables used in the disjuncts must be identical. In fact,
> they need have no intersection at all. This is worth pointing out.)
In the second example, the variables were different "title10" and "title11" but
changed to "x" and "y" to be clearer.
>
>
> 6.2 Blocks in Union Patterns
>
> More than one triple pattern can be given in a +graph+ pattern being
> used in a pattern union:
Text got changed anyway when "OR" used.
>
> PREFIX dc10: <http://purl.org/dc/elements/1.1/>
> PREFIX dc11: <http://purl.org/dc/elements/1.0/>
>
> SELECT ?title ?author
> WHERE { ( ?book dc10:title ?title ) ( ?book dc10:creator ?author ) }
> UNION
> { ( ?book dc11:title ?title ) ( ?book dc11:creator ?author ) }
>
> author title
> "Alice" "SPARQL Protocol Tutorial"
> "Bob" "SPARQL Query Language Tutorial"
>
> This query will only match a book if it has both a title and creator
> property 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.
Committed v1.144
Received on Thursday, 2 December 2004 17:14:18 UTC