Fwd: formal objection to SHACL property path syntax

Hi WG,

I see in principle no technical problems with the changes that Peter 
suggests. I do however see serious process issues here. The path syntax 
has been in its current shape for several months, and he could have 
suggested changes earlier. Any change to such definitions now may 
introduce other regression bugs for which we are obviously out of time. 
More importantly, the motivations for the changes appear extremely weak 
to me, e.g. who has ever seen an rdf:List node that also has other 
triples than rdf:first and rdf:rest?! There are plenty of other ways of 
producing "misleading" shapes, including

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

or

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

This all looks artificially constructed. Where to stop?! Given that this 
would be a formal change, we'd also need to publish a new CR.

Holger



-------- Forwarded Message --------
Subject:  formal objection to SHACL property path syntax
Resent-Date:  Mon, 01 May 2017 15:56:53 +0000
Resent-From:  public-rdf-shapes@w3.org
Date:  Mon, 1 May 2017 08:56:15 -0700
From:  Peter F. Patel-Schneider <pfpschneider@gmail.com>
To:  public-rdf-shapes@w3.org



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