W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > February 2017

Re: behaviour of ASK-based validators

From: Holger Knublauch <holger@topquadrant.com>
Date: Thu, 16 Feb 2017 10:08:06 +1000
To: public-rdf-shapes@w3.org
Message-ID: <b1f6271c-2524-3207-1686-1e17879db99f@topquadrant.com>


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 00:08:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:48 UTC