Re: handling recursive shapes in SHACL

The first part is just a variation on syntax checking.

The second part is somewhat more difficult.   For non-recursive shapes the
answer is clear.  Even if there are recursive shapes in the shapes graph,
validation of non-recursive shapes is not to be affected.

For recursive shapes, it is also possible to require that if a validation
report is returned then even recursive shapes have to be processed according
to the definitions in SHACL.   If no loops are encountered it is obvious that
this is the way to go.  If a loop is encountered then the situation is more
complex.  Perhaps the conservative approach is to keep recursive shapes undefined.

peter


On 02/20/2017 05:26 PM, Holger Knublauch wrote:
> Hi Peter,
> 
> do you have a proposal on how to handle this?
> 
> Thanks,
> Holger
> 
> 
> On 21/02/2017 1:47, Peter F. Patel-Schneider wrote:
>> There needs to be stricter requirements on the behaviour of SHACL
>> implementations on shapes graphs that contain recursive shapes.  First, a
>> SHACL implementation needs to provide a way of determining whether the
>> shapes graph contains recursive shapes that the implementation does not
>> handle.  Second, if a SHACL implementation produces a validation report for
>> a shapes graph that contains recursive shapes then the results reported
>> needs to conform with the definition of SHACL at least on the non-recursive
>> shapes in the shapes graph.
>>
>> For example, it is currently possible for SHACL implementations to implement
>> the following shapes graph as requiring that all SHACL instances of ex:C1 be
>> either ex:i1, ex:i2, or ex:i3.  But it is also possible for SHACL
>> implementations to implement the shapes graph as any behaviour whatsoever,
>> for example as requiring that all SHACL instances of ex:C1 are SHACL
>> instances of ex:C2.
>>
>> se:s2 rdf:type sh:NodeShape ;
>>    sh:node se:s2 .
>> se:s3 rdf:type sh:NodeShape ;
>>    sh:targetClass ex:C1 ;
>>    sh:in ( ex:i1 ex:i2 ex:i3 ) .
>>
>>
>> If there are not such requirements interoperability will be severely
>> compromised.  Users of a SHACL implementation will have no way of
>> determining whether their shapes graphs containing recursive shapes can be
>> interoperably processed by other SHACL implementations.
>>
>>
>> Peter F. Patel-Schneider
>> Nuance Communications
>>
> 
>

Received on Tuesday, 21 February 2017 01:44:56 UTC