Re: handling recursive shapes in SHACL

You can also look at https://arxiv.org/pdf/1702.01795 which has the
conservative approach.

peter


On 02/20/2017 05:43 PM, Peter F. Patel-Schneider wrote:
> 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:49:16 UTC