Re: two interesting test cases for SHACL

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 .

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.

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

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 00:48:55 UTC