Re: behaviour of ASK-based validators

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, 13 February 2017 02:07:33 UTC