Re: two interesting test cases for SHACL

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.

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

Received on Tuesday, 15 November 2016 04:00:36 UTC