handling recursive shapes in SHACL

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 Monday, 20 February 2017 15:48:23 UTC