Re: on sh:resultPath

It would have to be something like a SHACL property path whose mapping to a
SPARQL property path matches the path.

I suppose that this would work, but could be very expensive as many different
SHACL property paths might have to be constructed.


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.

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 Friday, 9 December 2016 16:45:26 UTC