Re: handling recursive shapes in SHACL

Hi Peter,

do you have a proposal on how to handle this?


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:27:58 UTC