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

Re: behaviour of ASK-based validators

From: Holger Knublauch <holger@topquadrant.com>
Date: Fri, 10 Feb 2017 15:46:09 +1000
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, public-rdf-shapes@w3.org
Message-ID: <0891bf9b-39c4-e31e-600f-b91c848d46be@topquadrant.com>

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 

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


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 

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.

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

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