Re: behaviour of ASK-based validators

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.

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

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

Received on Friday, 10 February 2017 05:46:50 UTC