ISSUE-41: Yet another take on property paths

I believe we need to resolve ISSUE-41 before things like ISSUE-139. The 
question of whether and how to allow paths has been ongoing for quite a 
while, and there are good arguments both ways. On the one hand side, 
paths are yet another feature that adds up to the cognitive, spec and 
implementation burden. On the other hand side, such paths would expand 
the use cases of SHACL Core and also may allow better code reuse (I say 
this with the SPARQL hat on - a single path query would reduce the need 
to have forward and backward queries).

If we are to support paths, my requirement is that we do not change the 
current syntax, i.e. do not throw away sh:property and 
sh:inverseProperty as currently specified. That would break the elegance 
and predictability of SHACL as a declarative language, e.g. for form 
building and static analysis. Instead, I suggest we support paths as a 
separate syntactic construct only, and then only for paths that are 
different from the simple paths. Users should always express their 
property/inverseProperty constraints using the more specialized syntax.

Under these conditions, here is what I would support (possibly even as a 
Core feature):

ex:MyShape
     a sh:Shape ;
     sh:pathConstraint [  # or better name...
         sh:path [
             sh:sequencePath [
                 sh:path1 [ sh:predicatePath rdf:type ] ;
                 sh:path2 [ sh:zeroOrMorePath [ sh:predicatePath 
rdfs:subClassOf ] ]
              ]
         ] ;
         sh:hasValue ex:MyClass ;
     ] .

which would check that the path rdf:type/(rdfs:subClassOf*) contains 
ex:MyClass. We could support most of 
https://www.w3.org/TR/sparql11-query/#pp-language and define a mapping 
from our syntax to SPARQL 1.1 expressions. SPIN has something similar 
(http://spinrdf.org/sp.html#sp-TriplePath)

The reason why I would support this is that it would help with the 
definition of validators and other SPARQL queries that currently need to 
be written in two directions (for sh:property and sh:inverseProperty). 
For example, unless a sh:propertyValidator exists, the system would fall 
back to sh:pathValidator, which uses a special variable $path as 
placeholder for the actual property or path. So while we have additional 
work to do in the spec and implementations, the overall cost for the end 
user will be smaller. And while technically busy work, I don't think it 
would be particularly difficult to specify the semantics, based on the 
syntax mapping to SPARQL.

Arnaud, could this be put onto the agenda before we discuss ISSUE-139 again?

Thanks
Holger

Received on Thursday, 2 June 2016 23:32:32 UTC