Re: two interesting test cases for SHACL

On 11/14/2016 11:03 PM, Holger Knublauch wrote:
>
> 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.

Yes, I am indeed saying that you don't understand the Shapes Constraint
Language (SHACL) document.

This document is SHACL and SHACL is this document.  SHACL is not some
intent.  SHACL is not some prototype implementation.  SHACL is instead
defined by the document or documents that the W3C RDF Data Shapes Working
Group produces, and currently the only relevant such document is this
document.

If the document does not match the intent of some working group members, or
even the working group as a whole, the document wins.  If the document does
not match some prototype implementation then the document wins.

The working group could, of course, decide to make some implementation of
SHACL be normative, in which case the situation would change, but right now
all that there is is the document, nothing else.

It is thus surprising that the document is so poorly understood within the
working group, even including editors of the document.  I don't see how the
document can be advanced in status with such demonstrated poor understanding
of the document.

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

But it *is* the case that this Turtle file is not part of the document, so
this file has absolutely no effect on SHACL.  There is not even any
indication in the document that this might be the case.

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

Even if the working group made this Turtle file a normative part of SHACL,
there still would be absolutely no normative effect of rdfs:domain triples
in this file.  The definition of SHACL is quite explicit that RDFS
processing is *not* part of SHACL.  Because of this, rdfs:domain triples in
this Turtle file would not even have any significant role in signalling
intent.

Even if there was some signalling of intent, that would not be sufficient to
overturn the relatively clear language in the document as to what is (and is
not) a shape.  Even if there was wording in the document to the effect that
the RDFS consequences of this Turtle file formed the definition of shapes
there would have to be an analysis of the relationship between this
definition of shapes and the textual definitions in the document.

It turns out that the definition of shapes in the document is still a bit
squishy, so maybe no changes would have to be made.  This, however, is a
problem with the definition of shapes in the document, which still needs to
be made precise.

> 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 a value
> <#dfn-values> for a target <#dfn-target> property such as |sh:targetClass| in
> the shapes graph <#dfn-shapes-graph>."

Has the working group signed off on this substantive change to one of the
fundamental aspects of SHACL?

What are the target properties of SHACL?

Are there other ways in which a node in a shapes graph can be a shape?

Are there other ways in which a node in a shapes graph can be a property
constraint besides those mentioned in the definition of property shapes in
Section 2.5.1?  What about the other important categories in SHACL?

As the "can be" wording has just been shown to be non-comprehensive in one
definition in the document, what about all the other places where this
wording is used?  I see sixty nine of them in the current document.

> Holger

Peter F. Patel-Schneider
Nuance Communications

>>> 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 15:32:08 UTC