W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > November 2016

Re: two interesting test cases for SHACL

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Mon, 14 Nov 2016 05:34:33 -0800
To: Holger Knublauch <holger@topquadrant.com>, public-rdf-shapes@w3.org
Message-ID: <f6c40069-ee1a-e1e6-914d-78a45d455adc@gmail.com>
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.

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

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

> Holger

Peter F. Patel-Schneider
Nuance Communications
Received on Monday, 14 November 2016 13:35:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:46 UTC