Re: Comments on SPARQL 1.1 Query Language

Thank you.  I am satisfied with this resolution.

David

On Mon, 2011-12-05 at 21:34 -0500, Paul Gearon wrote:
> 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)
> 
> 

-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Tuesday, 6 December 2011 17:57:56 UTC