Re: on sh:resultPath

On 10/12/2016 2:44, Peter F. Patel-Schneider wrote:
> The wording about value nodes at the beginning of Section 4 in the document
> needs to be tightened.  The document doesn't even define the notion of
> reachability.

Do you have specific input to address that?

Thanks,
Holger


>
> peter
>
>
> On 12/08/2016 11:49 PM, Dimitris Kontokostas wrote:
>> Thank you for your feedback Peter,
>> would something like the following wording resolve this issue?
>> Validation results may have a <a>SHACL property path</a> as value for the
>> property <code>sh:resultPath</code> that represents the <a>property path</a>
>> from the focus node to the value node.
>>
>> On Fri, Dec 9, 2016 at 6:21 AM, Holger Knublauch <holger@topquadrant.com
>> <mailto:holger@topquadrant.com>> wrote:
>>
>>      I have raised ISSUE-217 for this.
>>
>>      https://www.w3.org/2014/data-shapes/track/issues/217
>>      <https://www.w3.org/2014/data-shapes/track/issues/217>
>>
>>      Holger
>>
>>
>>
>>      On 9/12/2016 11:29, Peter F. Patel-Schneider wrote:
>>
>>                                                                          ISSUE<<<<<<<<<<<<<<<<<<
>>
>>          The requirements for values of sh:resultPath in validation results are
>>          impossible to achieve, poorly defined, contradictory, and problematic for
>>          applications that consume validation reports..
>>
>>                                                                          ISSUE<<<<<<<<<<<<<<<<<<
>>
>>
>>          3.4.2.2 Path (sh:resultPath)
>>          Validation results may have a value for the property sh:resultPath
>>          pointing
>>          at a well-formed property path starting with the given sh:focusNode. For
>>          results produced by a property constraint, this path is always
>>          identical to
>>          either the sh:predicate or sh:path of the constraint.
>>
>>
>>          A property path is a "possible route in a graph between two graph nodes".
>>          There is no definition of route to be found in the document.  It is
>>          thus not
>>          possible to point to a property path, well-formed or not.
>>
>>          The values of sh:predicate and sh:path in shapes graphs are SHACL property
>>          paths.  As objects of triples in a graph these values are nodes in the
>>          graph, and certainly not routes of any kind.
>>
>>          Identity of RDF terms is not defined in RDF, so it is not completely clear
>>          what the second sentence in the description above means.  The only
>>          reasonable interpretation appears to be that value of sh:resultPath is the
>>          same as the object of the sh:predicate or sh:path triple, which
>>          implies that
>>          validation results will contain nodes taken from shapes graphs.  This is
>>          contradictory as nodes are not paths.
>>
>>          This is also problematic for applications that consume validation
>>          reports as
>>          it requires the ability to take a blank node from one graph and find the
>>          same blank node in another graph, which is not always possible in RDF.
>>
>>
>>          This is yet another case of malformed descriptions in the document.  The
>>          document needs to be changed to provide a well-formed description for the
>>          value of sh:resultPath in validation results.  A complete examination
>>          of the
>>          document by a competent member of the working group is needed to find and
>>          eliminate other similar problems in the document.
>>
>>
>>          Peter F. Patel-Schneider
>>          Nuance Communications
>>
>>
>>
>>
>>
>>
>>
>>
>> -- 
>> 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
>>

Received on Saturday, 10 December 2016 01:23:56 UTC