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

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

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