CommentResponse:DB-4

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 variabl ein 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 terminolgy of "if and only if" would be correct.

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 document, and 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 (on behalf of the SPARQL WG)