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

Hi Eric,

On Thu, Sep 29, 2016 at 11:08 AM, Eric Prud'hommeaux <eric@w3.org> wrote:

> * 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.
>

Personally speaking, I think paths give a great advantage & flexibility in
SHACL
they also allow for a consistent way to do recursion so I would be in favor
of keeping them.
If we generalize them as I suggested above we will also reduce a lot of
definitions in the spec.
On the other hand, if we go back again we will make the spec more
complicated by including new type of constraints (reverse, path, etc)

There are some editorial issues raised by peter that can be easily
addressed and this technical issue for finalizing the structure of a
property path
(personally again) I do not see this as a big hassle

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.
>
>


-- 
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