Re: behaviour of ASK-based validators

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
>>>>>>>