Re: behaviour of ASK-based validators

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 Thursday, 23 February 2017 03:04:21 UTC