PRFO2

This is a formal objection to SHACL path syntax.

Submitted by: Peter Patel-Schneider

Description of the issue

SHACL defines the following 7 property paths: PredicatePath, InversePath, SequencePath, AlternativePath, ZeroOrMorePath, OneOrMorePath and ZeroOrOnePath.

The formal objection is two fold:

1. The syntax rules for 5 of the paths say that a well formed path is a blank node that is a subject of exactly one triple.

This rule means that paths like the following are ill 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 .

Submitter does not identify any "functional loss" as an issue, but, instead, he is concerned that SHACL users may think such shapes to be well formed - even though the spec contains the syntax rule and SHACL meta-shapes graph checks for such extraneous triples providing a readily available way for users to identify issues.

2. The syntax rule for the SequencePath says that it is a blank node that is a SHACL list with at least two members. The intention of the rule is to indicate that the blank node should only be s subject of triples with rdf:first and rdf:rest predicates.

Submitter believes that the rule as stated is not strict enough because the path below would not be considered ill 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 .

Submitter is concerned that a human user of shapes, when looking at RDF serialization of the shape above, would mistake the path for the InversePath.

Submitter requests changes to 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

Relevant information

E-mail

The prohibition of rdfs:comment triple does not result in the appreciative functional deficiency. Since each property shape is about exactly one path, users can make comments about paths directly on the property shape. Tests to detect syntax issues with shapes described in the part 1 of the FO are available in the SHACL meta-shapes graph.

Tests for the handling of shapes described in the part 2 of the FO were created by submitter and were added to the test suite. All submitted implementations handle the above shape the same - they understand the path as the SequencePath and ignore extraneous triples. Check for such extraneous triples is currently not in the shapes meta-graph, but it could easily be added.

WG Response

Submitter offered an alternative proposal for the path syntax. WG decided that the issues with the current syntax, as identified by the submitter, are too minor to warrant a change at such a late date.

Lacking a compelling use case, the WG feels that incremental improvement in PRFO2 is suitable for SHACL 1.1/2.0, but is not necessary for SHACL 1.0.