Re: behaviour of ASK-based validators

A list of something is completely different from the union those things.  This
should be completely evident to any person in computer science.

Peter F. Patel-Schneider
Nuance Communications

On 02/22/2017 01:42 AM, Holger Knublauch wrote:
> On 22/02/2017 0:41, Peter F. Patel-Schneider wrote:
>> The current wording produces decidedly different results from the previous
>> one.  Previously solution modifiers were stripped off ASK-based validators but
>> this is no longer done.
>>
>> The current wording also produces a set of mappings from variables to terms,
>> which is not a solution mapping if there is more than one value node and is
>> never a solution sequence.  I guess that the simplest fix to get a solution
>> sequence would be to say "Let QS be an unordered list of these solutions."
>> This seems weird but a solution sequence is supposed to be "a list of
>> solutions, possibly ordered".
> 
> I have switched from
> 
> Let <code>QS</code> be the unionof these <a>solutions</a>.
> 
> to
> 
> Let <code>QS</code> be a listof these <a>solutions</a>.
> 
> (calling a list "unordered" sounds like a contradiction to me, so "a list" is
> hopefully OK - it can indeed be any order among these solutions).
> 
> I have to confess I still don't understand why this nuance is so important,
> neither do I agree that whether we allow solution modifiers or not has any
> impact on this topic, but I hope we can close this thread now.
> 
> Holger
> 
>>
>> But I don't know if this is what is supposed to be the case because of the
>> decided change from the previous behaviour.  Going back to the previous
>> behaviour would require more changes.
>>
>> Peter F. Patel-Schneider
>> Nuance Communications
>>
>>
>>
>> On 02/20/2017 09:46 PM, Holger Knublauch wrote:
>>>
>>> On 16/02/2017 13:33, Peter F. Patel-Schneider wrote:
>>>> 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 intended meaning of ASK-based validators has not changed since earlier
>>> versions. See for example
>>>
>>>     https://www.w3.org/TR/2016/WD-shacl-20160814/#SPARQLAskValidator
>>>
>>> which explains how ASK-based validators can be translated into corresponding
>>> SELECT queries, projecting ?this and ?value. We have moved away from this
>>> definition because you pointed out that it relies on SPARQL EXISTS which is
>>> currently poorly defined.
>>>
>>> Holger
>>>
>>>
>>>> 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 Wednesday, 22 February 2017 10:38:38 UTC