- From: David Booth <david@dbooth.org>
- Date: Tue, 06 Dec 2011 12:57:27 -0500
- To: Paul Gearon <pgearon@revelytix.com>
- Cc: public-rdf-dawg-comments <public-rdf-dawg-comments@w3.org>
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