- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 15 Feb 2017 19:33:36 -0800
- To: Holger Knublauch <holger@topquadrant.com>, public-rdf-shapes@w3.org
Given that I don't know what the working group wants the definition to be, I can't produce wording for it. All I can say is that the current wording does not make sense because it produces results that are not what would come from a SPARQL query. The union of a set of SPARQL solutions, even if a solution is considered to be a set of pairs, is neither a solution sequence nor a set of solutions nor even necessary a solution. peter On 02/15/2017 04:08 PM, Holger Knublauch wrote: > > > On 13/02/2017 13:28, Peter F. Patel-Schneider wrote: >> rom 6.3: >> For each value node v where the SPARQL ASK query returns false with v >> pre-bound to the variable value, create one solution consisting of the >> bindings ($this, focus node) and ($value, v). Let QS be the union of these >> solutions. >> >> >> In SPARQL a solution mapping, a.k.a. solution, is a partial function from >> variables to RDF terms. The result of a SPARQL SELECT query is a sequence >> of solution mappings. > > As defined in the terminology section, the SHACL spec uses the term solution > as a set of bindings, and a binding is a pair. We are not talking about > partial functions. Therefore the rest of your email does not apply. > >> >> Union is not an operation directly defined on partial functions. So the >> wording in Section 6.3 is broken from the start. However, partial functions >> can be considered to be a set of bindings of variables to RDF terms where >> there is at most one binding for any particular variable. So the union in >> the construction is then the union of the partial functions considered as >> sets of bindings. >> >> But then there is the problem that the parallel construction for SELECT >> queries is just the result of the query, which is a sequence of solution >> mappings. A sequence of solution mappings is not the same as the union of a >> set of solution mappings. >> >> First, a sequence is not a set at all. However, often the order of the >> solution mappings is unimportant so the result of a SPARQL SELECT query can >> often be considered to be a set of solution mappings. But even then a set >> of solution mappings is not the same as the union of solution mappings. >> >> >> Consider what happens in this situation: >> Focus Node Value Node query result solution mapping >> ex:F1 ex:V1 false {(this,ex:F1),(value,ex:V1)} >> ex:F1 ex:v2 false {(this,ex:F1),(value,ex:V2)} >> ex:F2 ex:V1 false {(this,ex:F2),(value,ex:V1)} >> ex:F2 ex:V1 true > > How can F2/V1 first produce false and then true? > >> Result {(this,ex:F1),(value,ex:V1),(value,ex:V2),(this,ex:F2)} >> The result is not a set of solution mappings. It isn't even itself a >> solution mapping. >> >> >> This is yet another example of the continuing sloppiness in the SHACL >> document. It does not appear that anyone from the working group with any >> significant mathematical expertise has bothered to take even a quick look at >> the definition of SHACL. > > Peter, the WG has several members with significant mathematical expertise, and > yes we do bother a lot about the document. Making general statements and > claims as above is unhelpful and unfounded, and does not contribute to a > constructive dialog. > > The WG sees no issue with the language, but feel free to propose an > alternative, and this is the third time in this email thread that I am > suggesting this way forward. > > Holger > > >> >> >> Peter F. Patel-Schneider >> Nuance Communications >> >> >> On 02/12/2017 06:06 PM, Holger Knublauch wrote: >>> >>> On 10/02/2017 23:47, Peter F. Patel-Schneider wrote: >>>> On 02/09/2017 09:46 PM, Holger Knublauch wrote: >>>>> On 10/02/2017 8:49, Peter F. Patel-Schneider wrote: >>>>>> On 02/09/2017 02:23 PM, Holger Knublauch wrote: >>>>>>> On 10/02/2017 1:18, Peter F. Patel-Schneider wrote: >>>>>>>> On 02/08/2017 10:50 PM, Holger Knublauch wrote: >>>>>>>>> On 9/02/2017 8:54, Peter F. Patel-Schneider wrote: >>>>>>>>>> This part of the description of the behaviour of ASK-based validators >>>>>>>>>> doesn't >>>>>>>>>> make any sense at all. I have no idea what is supposed to be going on >>>>>>>>>> here. >>>>>>>>>> >>>>>>>>>> "Let QS be the union of the solutions produced for each value node v >>>>>>>>>> in vs >>>>>>>>>> so that the solution variable this is bound to the focus node and >>>>>>>>>> value is >>>>>>>>>> bound to v." >>>>>>>>> I don't see what's difficult or ambiguous here. QS is a set of >>>>>>>>> solutions. >>>>>>>>> Each >>>>>>>>> solution is a set of name-value pairs (as defined by SPARQL) and I am >>>>>>>>> enumerating these pairs. >>>>>>>>> >>>>>>>>> If you have a specific suggestion for wording that you would find >>>>>>>>> clearer to >>>>>>>>> understand, then I'd be happy to include that. >>>>>>>>> >>>>>>>>> Holger >>>>>>>> What does produce mean here? >>>>>>>> What is doing the producing? >>>>>>>> What does "so that" mean? >>>>>>> I have reworded that paragraph, please let me know if things remain >>>>>>> ambiguous >>>>>>> from your point of view. >>>>>> "For each value node v where the SPARQL ASK query returns false with v >>>>>> pre-bound to the variable value, create one solution consisting of the >>>>>> bindings ($this, focus node) and ($value, v). Let QS be the union of these >>>>>> solutions." >>>>>> >>>>>> Ok, so now the bindings don't come from SPARQL at all. Instead the SHACL >>>>>> impelementation constructs them. That was previously not clear at all. >>>>>> >>>>>> But now there appears to be several errors. >>>>>> >>>>>> The construction of QS doesn't end up with a solution sequence or even >>>>>> generally a solution at all. >>>>> QS is the set of solutions. There is no need for those to form a sequence. >>>>> Also if that set is empty, then no violation will be produced, which is >>>>> intentional. >>>> No, the construction of QS ends up with a set of mappings, not a set of >>>> solutions or a solution sequence, and this set of mappings is likely not even >>>> a solution. >>> See https://www.w3.org/TR/sparql11-query/#docResultDesc SPARQL uses the terms >>> - binding: a pair (variable, RDF term) >>> - solution: a set of bindings >>> - result set: set of solutions >>> >>> The terminology used in the description of the ASK semantics is IMHO >>> consistent with this terminology and I don't see how it could be >>> misinterpreted. If you have a better proposal, please give me a substitution >>> paragraph. >>> >>>>>> Now ASK-based validators only get one pre-bound variable, value. (Or is it >>>>>> instead that the value node is the variable that is being pre-bound?) This >>>>>> doesn't seem right. >>>>> The paragraph below the two bullet items also states that ?this will be >>>>> bound. >>>> That's not actually what the paragraph says. What it does say doesn't make >>>> sense at all. How can an execution be required to *use* a variable at all, >>>> and, in particular, how can it be required to *use* a variable only if the >>>> implementation supports something? >>> I don't agree with your statement that the current wording "doesn't make sense >>> at all". Even if the term "use" is not formally defined there is really only >>> one possible interpretation of that term, assuming the reader applies a tiny >>> bit of good will. Anyway, I have removed the term "use" if you feel so >>> strongly about these details. >>> >>> Holger >>> >>> >>>>>>>> How is this bound to a focus node in a property shape? >>>>>>> That's consistent with how it works for SELECT queries and node shapes. I >>>>>>> don't see that issue. >>>>>> A quick examination of 5.3.1, *the* place where the pre-binding of this (by >>>>>> the way, there are still $'s there) >>>>> I think that using $ in these cases is more readable, but anyway, >>>>> switched to >>>>> name only. >>>>> >>>>>> and also linked to from 6.3, produces: >>>>>> >>>>>> $this The value node. >>>>>> >>>>>> I noticed this wording some time ago. It looked to me like a nice >>>>>> change but >>>>>> it is hard to see how the variable this can then end up bound to the focus >>>>>> node in SPARQL-based constraint components in most property shapes. >>>>> Right. I felt uneasy with this too, so thanks for pointing this out. I have >>>>> raised >>>>> >>>>> https://www.w3.org/2014/data-shapes/track/issues/230 >>>>> >>>>> with the suggestion of using $this always for the focus node, but adding the >>>>> ability to use $PATH in sh:sparql. This will make it consistent with >>>>> SPARQL-based constraint components. Do you have any concerns with this >>>>> proposal? >>>>> >>>>> I have meanwhile updated the editor's draft to reflect the changes that I'd >>>>> like to see. I have added a new example to 5.1 to bring attention to using >>>>> sh:sparql in property shapes. I fixed some other smaller glitches along the >>>>> way. >>>>> >>>>> Thanks, >>>>> Holger >>>> peter >>>> > >
Received on Thursday, 16 February 2017 03:34:42 UTC