formal objection to SHACL property path syntax

This is a formal objection to two aspects of the syntax of SHACL property
paths.

The syntax for property paths in SHACL is both too liberal and too strict.
This leads to shapes that are unexpectedly well formed or not well formed.
Both of these are significant problems for users when writing and reading
SHACL shapes.  Interoperability problems will also arise from the too-strict
part of the syntax for property paths because the behaviour of SHACL
implementations is undefined for shapes that are not well formed,


On the too-liberal side, paths that are lists can also look like other kinds
of paths.  Here are two examples of well-formed SHACL shapes that should
instead not be well-formed.

ex:s1 a sh:PropertyShape ;
  sh:targetNode ex:i ;
  sh:path [ rdf:first ex:p ; rdf:rest [ rdf:first ex:q ; rdf:rest rdf:nil ] ;
       sh:inversePath ex:q ] ;
  sh:class ex:C .

ex:s2 a sh:PropertyShape ;
  sh:targetNode ex:i ;
  sh:path [ rdf:first ex:p ; rdf:rest [ rdf:first ex:q ; rdf:rest rdf:nil ] ;
       sh:inversePath ( ex:p ) ] ;
  sh:class ex:C .

The first path looks ambiguous to users, being either a sequence path or an
inverse path.  Users will be confused about the correct meaning of this
path.

The second path looks as if is is not well-formed because it contains a
sequence path that is too short.  Users will again be confused because they
will expect the path not to be well-formed when it is.


On the too-strict side, many kinds of paths cannot be the subject of extra
triples, even triples with predicates like rdfs:comment.  For example, the
following shape contains a path that is not well-formed.

ex:s2 a sh:PropertyShape ;
  sh:targetNode ex:i ;
  sh:path [ rdfs:comment "inverse of ex:p" ;
         sh:inversePath ex:p ] ;
  sh:class ex:C .

Users can easily write paths like the one above and will expect shapes
containing paths like these to have a well-defined meaning in SHACL.
However, the meaning of the above shape is undefined in SHACL and different
SHACL implementations can produce different results for these shapes without
signalling an error or warning, leading to silent interoperability problems
between SHACL implementations.



The solution to this problem is to change the following syntax rules

  path-metarule, path-non-recursive, path-predicate, path-sequence,
  path-alternative, path-inverse, path-zero-or-more, path-one-or-more, and
  path-zero-or-one

to

path-non-recursive A node p is not a well-formed SHACL property path if
      p is a blank node and any of the following rules require,
      directly or indirectly, determining whether p is a
      well-formed SHACL property path.

path-metarule     A node is a well-formed SHACL property
    path if it satisfies exactly one of the following
    rules and if the node is a blank node it does not have a
    value for more than one of rdf:first or rdf:rest,
    sh:alternativePath, sh:inversePath, sh:zeroOrMorePath,
    sh:oneOrMorePath, and sh:zeroOrOnePath.

path-predicate    A predicate path is any IRI.

path-sequence    A sequence path is a blank node that is a SHACL list with
    at least two members and each member of the list is a
    well-formed SHACL property path.

path-alternative  An alternative path is a blank node that has exactly one
    value for sh:alternativePath and that value is a SHACL
    list with at least two members and each member of the list
    is a well-formed SHACL property path.

path-inverse      An inverse path is a blank node that has exactly one value
    for sh:inversePath and that value is a well-formed
    SHACL property path.

path-zero-or-more A zero-or-more path is a blank node that has exactly one
    value for sh:zeroOrMorePath and that value is a
    well-formed SHACL property path.

path-one-or-more  A one-or-more path is a blank node that has exactly one
    value for sh:oneOrMorePath and that value is a
    well-formed SHACL property path.

path-zero-or-one A zero-or-one path is a blank node that has exactly one
   value for sh:zeroOrOnePath and that value is a
   well-formed SHACL property path.

These changes to the syntax of SHACL results in a SHACL that is easier to
write, easier to understand, easier to generate, and with fewer
interoperability problems.



Peter F. Patel-Schneider
Nuance Communications

Received on Monday, 1 May 2017 15:56:52 UTC