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

+1


> On 29 Sep. 2016, at 6:32 pm, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> wrote:
> 
> 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
>