Re: two interesting test cases for SHACL

On 15/11/2016 14:00, Peter F. Patel-Schneider wrote:
> On 11/14/2016 06:41 PM, Holger Knublauch wrote:
>>
>> On 15/11/2016 10:48, Peter F. Patel-Schneider wrote:
>>> On 11/14/2016 03:00 PM, Holger Knublauch wrote:
>>> All I am doing is following through the wording in the SHACL document.  se:s2
>>> is a shape and thus will initiate target processing.  se:s3 is not and thus
>>> won't.
>> Shapes don't require a sh:Shape triple. sh:targetXY triples are sufficient to
>> trigger the validation. At least that was the intention. Where in the spec
>> does it say otherwise?
> Where in the spec does it say that sh:targetClass triples are sufficient to
> trigger validation?  Nowhere.
>
> The definition of validation, from Section 3, says
>
> "A data graph validates against a shapes graph if and only if the data graph
> validates against each shape in the shapes graph."
>
> So something has to be a shape for targets to have any effect.  There is no
> wording anywhere in the document that states that the subject of any of the
> target properties is a shape.  Failure to recognize these simple aspects of
> the document is a failure to understand the definition of SHACL.

You are saying that I haven't understood the document that I edited 
myself. I hope you agree that this is unlikely. What is rather likely is 
that the intended meaning is obvious to me, but it may not be properly 
expressed in the document. So it's good to have more people reading it 
in depth.

On the specific topic, the rdfs:domain of the sh:targetXY properties is 
sh:Shape. (Yes I know the TTL file is not yet linked from the spec, but 
it will, meanwhile it's on 
https://github.com/w3c/data-shapes/blob/gh-pages/shacl/shacl.ttl). As a 
result of this, any node with targets would become an sh:Shape in RDFS 
processors. Although SHACL isn't based on RDFS, I believe this clarifies 
the intention, and this brings us back to my understanding vs what is 
currently written down.

In any case, to clarify the situation further, I have added a 
half-sentence to the definition of Shapes (now section 2.1): "... or a 
node that has avalue <#dfn-values>for atarget <#dfn-target>property such 
as|sh:targetClass|in theshapes graph <#dfn-shapes-graph>."

Holger



>
>> For future reference, maybe it would have been more
>> helpful to ask for clarification on this topic such as "Can only typed shapes
>> trigger target-based validation?" instead of burying this into a rather
>> cryptic example without explanation?
>> There still may be editorial issues, and I want to help iron them out.
> This is *not* an editorial issue.  Editorial issues are those where the
> wording of a document needs to be modified, but the modification does not
> change the meaning of the document.
>
>> I am
>> not sure how other WGs handle these ambiguities.
> This is *not* an ambiguity.  The document is quite clear in this case on what
> is supposed to happen.  The working group is producing a document.  The
> definition of SHACL will be what that document says, not any intuitions that
> members of the working group may have nor even any behaviour of prototype
> implementations.
>
> What other working groups do is have multiple members of the group go over the
> documents with a fine-tooth comb, looking for flaws in definitions and trying
> to figure out what happens with unusual input.   This is a very simple example
> of an only slightly unusual input that targets the very important notion in
> SHACL of what it takes to initiate target processing.
>
>> In older versions I had
>> started an "Operations" section that was explaining the algorithms and
>> triggering mechanisms unambiguously. But the WG saw not enough value in
>> maintaining this section.
> I don't remember any version of the document that had targetting triples by
> themselves being adequate to set up focus nodes.
>
>> I assume the test cases will be normative, and they
>> may add additional clarity for implementors. Other ideas?
> Test cases are not normative.  Instead they serve both as guidance to
> implementors and partial validation of implementations.  If a test case goes
> against a normative part of the document it is the document that wins.  Test
> cases can help to resolve ambiguities in the document but even then there is a
> problem that should be addressed via an erratum to the document.
>
>> Thanks,
>> Holger
>>
>>
>>> That these simple cases are not understood by the working group is proof that
>>> the document has not undergone adequate examination from within the working
>>> group.  The working group needs to take a close look at the document to see
>>> just what it is saying about SHACL.
>>>
>>>> Holger
>>>>
>>>>
>>>>>> Holger
>>>>> Peter F. Patel-Schneider
>>>>> Nuance Communications
>>>>>
>>