Re: behaviour of ASK-based validators

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