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

* Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> [2016-09-29 09:47+0300]
> Hi Simon,
> 
> This problem came up while working on the results graph.
> sh:path there needs to be copied from the shapes graph and in such cases
> where sh:path / sh:predicate are different we would have a conflict.
> 
> The solution we came up with was the one suggested by Holger in the raised
> issue
>  - is IRI, use a simple predicate
>  - is blank node, try to parse it as a SHACL property path
> 
> If we decide to do this change, what I was also in favour of is drop
> sh:predicate completely
> IIRC we kept sh:predicate just for simpler querying but we can use
> isBlankNode() instead and remove a lot of duplication from the spec

I believe the motivation for adding property paths to SHACL was to
simplify constraints (i.e. factor out the commonalities in forward and
reverse constraints). Given the hassle they cause, why don't we just
go back to having constraints with a single predicate? We could get
the simplicity we originally sought by having a "reverse" flag.


> Best,
> Dimitris
> 
> 
> On Thu, Sep 29, 2016 at 8:34 AM, Simon Steyskal <simon.steyskal@wu.ac.at>
> wrote:
> 
> > 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.
> >>
> >
> >
> 
> 
> -- 
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia Association
> Projects: http://dbpedia.org, http://rdfunit.aksw.org,
> http://aligned-project.eu
> Homepage: http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Thursday, 29 September 2016 08:08:09 UTC