Comments on SPARQL 1.1 Query Language

On Fri, Jul 29, 2011 at 2:32 PM, David Booth <david@dbooth.org> wrote:
> Regarding
> http://www.w3.org/TR/2011/WD-sparql11-query-20110512/
>
> It is great to see this in Last Call!  Just a few things I noticed:

Hi David, thank you for the comments


> 1. Section 8.3
> http://www.w3.org/TR/2011/WD-sparql11-query-20110512/#id35836025
> says: "whereas with MINUS, there is no shared variable between the first
> part (?s ?p ?o) and the second (?x ?y ?z) so no bindings are
> eliminated".  However, MINUS does not appear elsewhere in the TOC, and I
> do not see any other direct explanation of the relevance of shared
> variables between the first and second parts.

None of the major section headers have the keyword names in them; it's
not just MINUS. The heading 8.3 mentions MINUS and it's discussed in
the immediately preceding section.


> I think I figured it out by looking at Sec 18.3 "Definition: Compatible
> Mappings" in combination with the sec 18.4 "Definition: Minus".
> Basically, if I understand correctly, *any* use of a variable in the
> second part that does not appear in the first part likely amounts to a
> user error because it can never remove any bindings involving that
> variable, because the MINUS operator removes matching bindings and a
> binding includes *both* variable names and their values.  I think it
> would be helpful to state this (with the rationale) more prominently and
> directly.

It's when there are no variables in common; it's about patterns, not
the variables in a pattern independently.

The working group decided that it would be confusing if MINUS
eliminated all the solutions in the case of no variables in common as
it is a feature of the patterns independent of the data.

?s ?p ?o MINUS { ?x ?y ?z }

This is reflected in the definition

Minus(Ω1, Ω2) = { μ | μ in Ω1 . ∀ μ' in Ω2, either μ and μ' are not
compatible or dom(μ) and dom(μ') are disjoint }

by adding the condition "dom(μ) and dom(μ') are disjoint".


> 2. In Sec 18.3 "Definition: Compatible Mappings":
> [[
> Two solution mappings μ1 and μ2 are compatible if, for every variable v
> in dom(μ1) and in dom(μ2), μ1(v) = μ2(v).
> ]]
> that should be an "iff" instead of "if", right?  Or are there other ways
> that μ1 and μ2 can be compatible?

No, there are no other ways. This is the only definition and because
it's the definition, anything not included does not, implicitly, meet
the terminology of "if and only if".

However, this text is in SPARQL 1.0 in exactly this form, and we also
want to not imply a change in the definition between SPARQL 1.0 and
SPARQL 1.1. Therefore, we have not made the change.


> 3.
> http://www.w3.org/TR/sparql11-update/#graphStore
> "Operations may specify graphs to work with, or they may rely on a
> default graph for that operation."
> But don't operations use RDF Datasets, rather than graphs?

This is not about query despite the subject line :-)

It is always a graph, or set of graphs that is modified in an Update
operation. Only the DELETE/INSERT operation and its derivatives use
Datasets, and this is for the query portion of the operation.

The text "to work with" is ambiguous, so it has been updated to the
following: "Operations may specify graphs to be modified, or they may
rely on a default graph for that operation."


> 4. Regarding the typographical conventions that you use for conformance
> keywords:
> [[
> When this document uses the words must, must not, should, should not,
> may and recommended, and the words appear as emphasized text, they must
> be interpreted as described in RFC 2119 [RFC2119].
> ]]
> As you can see in the excerpt quoted above, the typographical emphasis
> of these keywords (i.e., bolding) is lost when the document is viewed as
> plain text or copied and pasted as plain text.  This makes it more
> difficult to quote and discuss portions of the specification precisely.
> To ensure clarity, please make these keywords UPPER CASE (perhaps in
> addition to being bold).

In the query document, the RFC 2119 terminology isn't used. The
describe states what SPARQL query is (this carries over from SPARQL
1.0).

Several other documents including Update use RFC 2119. These terms
have now been capitalized both for consistency between documents, and
for the clarity that you requested.

> 5. Typo:  s/righ hadn side/right hand side/

Fixed.


We would be grateful if you would acknowledge that your comment has
been answered by sending a reply to this mailing list.

Andy and Paul (on behalf of the SPARQL WG)

Received on Tuesday, 6 December 2011 02:35:11 UTC