Re: behaviour of ASK-based validators

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.

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

Received on Monday, 13 February 2017 03:29:33 UTC