Re: formal objection to SHACL property path syntax

I think the main issue here is one of timing.

If we are to make the change Peter is asking for, we will need to re-do the CR. I don’t know how quickly this could happen. I assume this means another transition meeting? Then, there will be a need for updates to implementations, new tests, etc.

It seems to me that we do not have time for it.

Essentially, the spec (potentially) made one small slip. It may not have said clearly enough that the sequence path can only have list members and nothing else. All other paths say “exactly one triple”, so there is no issue. Here, we are specifying two triples, but we do not say “exactly two”.

Sequence path is defined as follows:

A sequence path is a blank node <https://www.w3.org/TR/shacl/#dfn-blank-node> that is a SHACL list <https://www.w3.org/TR/shacl/#dfn-shacl-list> with at least two members <https://www.w3.org/TR/shacl/#dfn-members> and each member is a well-formed <https://www.w3.org/TR/shacl/#dfn-well-formed> SHACL property path.


SHACL Lists
A SHACL list in an RDF graph G is an IRI <https://www.w3.org/TR/shacl/#dfn-iri> or a blank node <https://www.w3.org/TR/shacl/#dfn-blank-node> that is either rdf:nil (provided that rdf:nil has no value <https://www.w3.org/TR/shacl/#dfn-value> for either rdf:first or rdf:rest), or has exactly one value <https://www.w3.org/TR/shacl/#dfn-value> for the property rdf:first in G and exactly one value <https://www.w3.org/TR/shacl/#dfn-value> for the property rdf:rest in G that is also a SHACL list in G, and the list does not have itself as a value of the property path rdf:rest+ in G. 
 The members of any SHACL list except rdf:nil in an RDF graph G consist of its value for rdf:first in Gfollowed by the members in G of its value for rdf:rest in G. The SHACL list rdf:nil has no members in any RDF graph.

So, something like the following would clarify things:

A sequence path is a blank node <https://www.w3.org/TR/shacl/#dfn-blank-node> that is a SHACL list <https://www.w3.org/TR/shacl/#dfn-shacl-list> with at least two members <https://www.w3.org/TR/shacl/#dfn-members> and each member is a well-formed <https://www.w3.org/TR/shacl/#dfn-well-formed> SHACL property path. A sequence path is the subject of exactly two triples in G.

I wonder if there is any way to clarify this and position it as an editorial change. I hope that this is arguable because of the “symmetry”. All other paths explicitly exclude any “extraneous” triples. 

What did the implementations do? How have they understood the spec?

I think that this (ensuring that sequence paths only have list members) is also something that could be potentially detected by SHACL-SHACL.

This would continue to disallow comments and other extraneous triples in the paths, but I think it is perfectly OK. We don’t have a requirement for supporting comments as part of the path expressions. Instead, a comment could be associated directly with the property shape itself. 


> On May 1, 2017, at 10:27 PM, Holger Knublauch <holger@topquadrant.com> wrote:
> 
> 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 <mailto:public-rdf-shapes@w3.org>
> Date: Mon, 1 May 2017 08:56:15 -0700
> From: Peter F. Patel-Schneider <pfpschneider@gmail.com> <mailto:pfpschneider@gmail.com>
> To: public-rdf-shapes@w3.org <mailto: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
>