Re: behaviour of ASK-based validators

On 22/02/2017 20:38, Peter F. Patel-Schneider wrote:
> A list of something is completely different from the union those things.  This
> should be completely evident to any person in computer science.

Please abstain from inflammatory or insulting statements on this list. 
We both know very well that this discussion does not happen on a level 
playing field. In contrast to external reviewers I have to carefully 
weigh every single word because the W3C process depends on it. I do not 
always succeed but at least I am now trying harder.

The distinction that you have made is IMHO completely unnecessary and 
has zero consequences. Nowhere in the downstream sections of this 
validation process does SHACL require that the solutions are a list. In 
fact the order does not matter at all. In the case of ASK there cannot 
even be duplicates. An unordered list with no duplicates is basically a 
set. The term "union" is better capturing this than "list" IMHO. But, as 
happened so many other times, I was giving in because we are trying to 
progress in the W3C process and otherwise there will be yet another 
follow-up email from you. The sheer amount of traffic on the various 
SHACL mailing lists and the rather academic nature of some questions was 
unfortunately a major reason why some people have lost interest in 
participating.

Holger


>
> 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 Thursday, 23 February 2017 01:34:14 UTC