a problem with shapes and constraints

Here is an example shape that illustrates one problematic aspect of the
current design of SHACL.

se:s1 rdf:type sh:Shape ;
 sh:class ex:c ;
 sh:property [ sh:class ex:c1 ;
         sh:predicate ex:p1 ;
        sh:property [ sh:class ex:c2 ;
               sh:predicate ex:p2 ] ] .

This shape is legal but doesn't do what is expected.  Users will write
shapes like it and be surprised by the result.  Writing the sections of the
SHACL document that address the problem illustrated here and similar
problems has required considerable effort in the working group and will need
still more effort.


There are two methods to fix this problem.

The first method, which I have previously described, is to have the
constraint components completely control the jump from one focus node to
another.  In this method sh:property becomes a parameter for a new
constraint component and loses its special status.  The values for this
parameter are property constraints, which as now have a value for
sh:predicate or sh:path but are also shapes.  The new constraint component
does what is expected for property constraints.  The fact that its value is
now also a shape is irrelevant, because it is the constraint components that
matter.  The current parameters that take shapes, sh:not, sh:and, etc., can
take shapes that are property constraints, but ignore the sh:predicate or
sh:path value.  Again, it is the constraint component that is in control,
not whether the parameter value is a shape or property constraint.  In this
method the above example gives the expected results.

The second method is to have the shape itself completely control the jump
from one focus node to another.  In this method there is no need for
sh:property at all.  A shape that has a value for sh:predicate or
sh:property sets up new focus nodes and associated value nodes; a shape
without either leaves the focus node and value nodes the same.  There is
also no need for property constraints.  In this method the above example
would be written as:

se:s1 rdf:type sh:Shape ;
 sh:class ex:c ;
 sh:shape [ sh:class ex:c1 ;
      sh:predicate ex:p1 ;
      sh:shape [ sh:class ex:c2 ;
              sh:predicate ex:p2 ] ] .

Both methods would also turn sh:sparql into a parameter for a new constraint
component that evaluates the SPARQL query on the current value nodes.


Both methods eliminate the special status and handling of sh:property and
sh:sparql.  They both eliminate problems with nodes that are both shapes and
propertyy constraints.  They both reduce the fundamental concepts of SHACL
to shapes and constraint components.

Neither method requires drastic changes to the SHACL document or to how
SHACL is implemented.  Adopting either would result in a better design for
SHACL and would actually reduce the amount of effect needed to produce a
final version of the SHACL document.



Peter F. Patel-Schneider
Nuance Communications

Received on Tuesday, 29 November 2016 12:12:35 UTC