ISSUE-180: Should IRI paths always be interpreted as predicates? [SHACL - Core]

Hi!

> I think it would be easier to have a policy that all IRI paths are
> counted as PredicatePaths, i.e. all complex paths such as inverse
> paths must be IRIs.

Just for clarification, consider following example :

-------------
ex:A
   a sh:Shape ;
   sh:property [
     sh:predicate ex:parent .
   ]
   sh:property [
     sh:path ex:parent .
   ] .

ex:B
   a sh:Shape ;
   sh:property [
     sh:path ex:child .
   ] .

ex:C
   a sh:Shape ;
   sh:property [
     sh:predicate ex:parent .
   ]
   sh:property [
     sh:path [ sh:alternativePath ( ex:father ex:mother  ) ].
   ] .

ex:parent sh:alternativePath ( ex:father ex:mother  ) .
ex:child sh:inversePath ex:parent .
-------------

According to the current spec (and correct me if I'm wrong):

  1) property constraints of ex:A denote different paths
  2) property contraint of ex:B considers ex:child being the 
sh:inversePath of ex:parent
  3) property constraints of ex:C denote different paths

According to proposed change:

  1) property constraints of ex:A denote the same (predicate) path
  2) ?
  3) property constraints of ex:C denote different paths

How should the property constraint of ex:B be treated?

br,
simon

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

www: http://www.steyskal.info/  twitter: @simonsteys

Am 2016-09-29 06:58, schrieb RDF Data Shapes Working Group Issue 
Tracker:
> shapes-ISSUE-180 (Path bnodes): Should IRI paths always be interpreted
> as predicates? [SHACL - Core]
> 
> http://www.w3.org/2014/data-shapes/track/issues/180
> 
> Raised by: Holger Knublauch
> On product: SHACL - Core
> 
> Currently we have the policy that all elements of a Path in RDF syntax
> may be IRI nodes, and only if a node is neither of sh:inversePath etc
> then a IRI is regarded as a PredicatePath. See rules 1. - 4. in
> 
> https://www.w3.org/TR/shacl/#path-syntax
> 
> However, this leads to complications e.g. as outlined in 2.3.5 of the
> current editor's draft.
> 
> I think it would be easier to have a policy that all IRI paths are
> counted as PredicatePaths, i.e. all complex paths such as inverse
> paths must be IRIs.
> 
> This is also related to the public comment mentioned in
> 
> https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Sep/0031.html
> 
> because with the new policy it would be clearer to describe how a
> "deep copy" is supposed to work.

Received on Thursday, 29 September 2016 05:35:17 UTC