Re: two interesting test cases for SHACL

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.

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

Holger


>
>> Holger
> Peter F. Patel-Schneider
> Nuance Communications
>

Received on Monday, 14 November 2016 23:00:37 UTC