W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > February 2017

Re: behaviour of ASK-based validators

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Fri, 10 Feb 2017 05:47:37 -0800
To: Holger Knublauch <holger@topquadrant.com>, public-rdf-shapes@w3.org
Message-ID: <a67af73f-0a17-d6bc-56da-d7439f83a94c@gmail.com>

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.

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

>>>> 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 13:48:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:48 UTC