W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > July 2015

ISSUE-41 : new thoughts on property paths

From: Simon Steyskal <simon.steyskal@wu.ac.at>
Date: Fri, 17 Jul 2015 08:32:15 +0200
To: Public-data-shapes Wg <public-data-shapes-wg@w3.org>
Message-ID: <c041341739f5cd559de206170da10ba7@wu.ac.at>

During refactoring of our UCR document, I stumbled across two use 
cases[1,2] which require that SHACL should allow to express constraints 
between different properties. While basic scenarios can be handled by 
using sh:NativeConstraints (as already discussed), a more generic 
approach that allows to define property paths using the high-level 
vocabulary might be more feasible (and is requested by [2]).

I was working on a SHACL helper function that takes a focus node and a 
sh:Path (utilizing SPIN's[3]/Jena's strategy for expressing property 
paths) as arguments and defines a SPARQL query that should recursively 
resolve the path, returning a final set of property values. 
Unfortunately I failed, probably due to well-known limitations of BIND 
(i.e. wasn't able to pass more than one node through the path).

Since Holger recently made his SHACL API public, I was able to make some 
first "hard coded" path parsing attempts which seemed to work out quite 
well. So I was wondering whether such a high-level path representation 
whose semantics would have to (most likely) be defined without using a 
SPARQL template as backbone (but maybe just by providing mappings 
between path expressions and their respective representation using 
sh:Path constructs) would be worth to discuss?

For example, (ex:A|ex:B)/ex:C would be represented as:

ex:path a sh:SeqPath ;
    sh:path1 [ a sh:AltPath ;
       sh:path1 ex:A ;
       sh:path2 ex:B
    sh:path2 ex:C .


[3] http://www.w3.org/Submission/spin-sparql/#sp-TriplePath

DDipl.-Ing. Simon Steyskal
Institute for Information Business, WU Vienna

www: http://www.steyskal.info/  twitter: @simonsteys
Received on Friday, 17 July 2015 06:32:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:25 UTC