Re: behaviour of ASK-based validators

Ok, I was probably too much thinking in terms of computer science than 
maths. My implicit assumption was that a "solution" is an "object" that 
encapsulates a set of bindings as private members. But you are right 
that from a math point of view, a solution is indeed still a set, so mea 
culpa for not seeing the obvious. This is just to explain my thinking in 
case there are similar glitches elsewhere.

Holger


On 23/02/2017 12:31, Peter F. Patel-Schneider wrote:
> Let me make this a simple as possible.
>
> Suppose a SPARQL ASK query returns false for focus node ex:f and two value
> nodes ex:v1 and ex:v2.  Two solution mappings are created, one looking like
> { (this,ex:f), (value,ex:v1) } and the other looking like
> { (this,ex:f), (value,ex:v2) }.
>
> The union of these two solutions is
> { (this,ex:f), (value,ex:v1), (value,ex:v2) }.
> This is not a solution sequence, which is defined as a list of solution
> mappings, possibly unordered.  It is not even a solution mapping.
>
> The unordered list of these two solutions has two elements, namely the two
> solution mappings, and is a solution sequence.
>
> The difference is indeed very significant.
>
> Peter F. Patel-Schneider
> Nuance Communications
>
> On 02/22/2017 05:33 PM, Holger Knublauch wrote:
>> 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 Monday, 27 February 2017 06:41:32 UTC