Re: two interesting test cases for SHACL

On 15/11/2016 10:48, Peter F. Patel-Schneider wrote:
> On 11/14/2016 03:00 PM, Holger Knublauch wrote:
>>
>> On 14/11/2016 23:34, Peter F. Patel-Schneider wrote:
>>> On 11/13/2016 09:14 PM, Holger Knublauch wrote:
>>>> On 14/11/2016 13:24, Peter F. Patel-Schneider wrote:
>>>>> Here are two test cases that exhibit interesting situations, along with
>>>>> their results according to the SHACL document as of 13 November.
>>>>>
>>>>> Data Graph D:
>>>>>
>>>>> ex:i1 rdf:type ex:c ;
>>>>>     ex:p1 ex:i2 .
>>>>>
>>>>> 1/ property constraints and focus node constraints
>>>>>
>>>>> Shapes Graph S1:
>>>>>
>>>>> se:s1 rdf:type sh:Shape ;
>>>>>      sh:targetClass ex:c ;
>>>>>      sh:property [ sh:predicate ex:p2 ;
>>>>>                    sh:property se:s2 ] ;
>>>>>      sh:shape se:s2 .
>>>>> se:s2 sh:predicate ex:p1 ;
>>>>>      sh:class ex:c .
>>>>>
>>>>> Validating D against S1 produces the following validation report
>>>>>
>>>>> [ rdf:type sh:ValidationResult ;
>>>>>      sh:severity sh:Violation ;
>>>>>      sh:focusNode ex:i1 ;
>>>>>      sh:sourceConstraintComponent sh:ShapeConstraintComponent ;
>>>>>      sh:sourceShape se:s1 ] .
>>>> I don't see why this validation report would be produced. The sh:property
>>>> constraint on ex:p2 doesn't do anything because it has no constraint
>>>> parameters. The sh:shape se:s2 statement is also passing OK because the only
>>>> thing to test here is sh:class ex:c, which is true due to the targetClass
>>>> triple. The sh:predicate statement on s2 has no effect. Could you clarify why
>>>> you think SHACL engines should produce the violation above?
>>> se:s2 is a property constraint, hence it will produce a validation result for
>>> focus node ex:i1 which will then cause se:s1 to produce a validation result
>>> for focus node ex:i1.
>> No, s2 is never referenced correctly via sh:property and therefore never used
>> as a property constraint.
> Hmm, perhaps you mean that there has to be a shape in the middle, i.e., the
> above shapes graph is syntactically invalid and the graph should be
>
> se:s1 rdf:type sh:Shape ;
>      sh:targetClass ex:c ;
>      sh:shape [ sh:property [ sh:predicate ex:p2 ;
>                    sh:property se:s2 ] ] ;
>      sh:shape se:s2 .
> se:s2 sh:predicate ex:p1 ;
>      sh:class ex:c .

No, this is still probably not what you are trying to express. the line

                   sh:property se:s2 ] ] ;

doesn't "do" anything, because property constraints cannot include other 
property constraints directly - only shapes can. The extra sh:shape 
triple is unnecessary, although it doesn't do harm either.

>
> OK, then S1 is an interesting syntactic test case, and this new graph (S3)
> produces the validation result above.  But S1 should be syntactically valid.
> Why require this extra shape that serves no purpose?
>
> Further, this syntactic invalidity isn't particularly relevant to the actual
> test.  se:s2 has expected type sh:PropertyConstraint, regardless of whether
> the subject of the relevant triple is a shape or not.  The expectation is then
> that se:s2 is a property constraint (although this is not explicitly mentioned
> in the document).  Since se:s2 is a property constraint it acts like a
> property constraint even when reached via sh:shape and thus produces the
> validation report shown above.

No, the interpretation depends entirely on whether a constraint is 
reached via sh:shape vs sh:property. Only if reached via sh:property it 
will be interpreted as a property constraint. Which statements in the 
spec contradict this interpretation?

>
>>>>> It is actually a tiny bit unclear what makes a property constraint.  There
>>>>> is wording that values of sh:property have sh:PropertyConstraint as expected
>>>>> type, but there is no actual explicit connection between nodes with expected
>>>>> type sh:PropertyConstraint.  However, se:s2 is definitely a property
>>>>> constraint as it is the value of sh:property in a shape.
>>>>> 2/ finding shapes
>>>>>
>>>>> Shapes Graph S2:
>>>>>
>>>>> se:s1
>>>>>      sh:not se:s2 .
>>>>> se:s2
>>>>>      sh:targetClass ex:c ;
>>>>>      sh:class ex:d .
>>>>> se:s3
>>>>>      sh:targetClass ex:c ;
>>>>>      sh:nodeKind sh:BlankNode .
>>>> se:s1 is unreferenced - intentional?
>>>>
>>>>> Validating D against S2 produces the following validation report
>>>>>
>>>>> [ rdf:type sh:ValidationResult ;
>>>>>      sh:severity sh:Violation ;
>>>>>      sh:focusNode ex:i1 ;
>>>>>      sh:sourceConstraintComponent sh:ClassConstraintComponent ;
>>>>>      sh:sourceShape se:s2 ] .
>>>> In addition, the sh:nodeKind constraint is also violated and reported.
>>> Why should the sh:nodeKind triple have anything to do with validation in S2?
>>> Its subject is not a shape or a constraint.
>> Ok, if you only validate s2 then s3 unrelated. Then why did you even include
>> it into the example (same question for s1)?
>>
>>>> I am lost what this example is supposed to show.
>>> It is showing what the current SHACL document is mandating about shapes in a
>>> shapes graph.
>> I have still no clue what your issue is. Could we try to be less cryptic?
> 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? 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. I 
am not sure how other WGs handle these ambiguities. 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 assume the test cases will be normative, 
and they may add additional clarity for implementors. Other ideas?

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 02:41:55 UTC