Re: on sh:resultPath

Here is a definition of value nodes along with the definitions needed to
support it.






Path:

A **path** in an *RDF graph* from *RDF term* n to RDF term m is a sequence
of *RDF triples* in the graph such that the *subject* of the first RDF
triple is n, the *object* of the last RDF triple is m, and the object of
each RDF triple except the last is the subject of the next.


Value:

An RDF term n has **value** v for property p in an RDF graph if there is an
RDF triple in the graph with subject n, predicate p, and object v.

An RDF term n has value v for *SPARQL property path expression* p in an RDF
graph if there is a path in the graph from n to v that *matches* p.


SHACL List:

A **SHACL list** in an RDF graph is an IRI or a *blank node* that is either
rdf:nil provided that rdf:nil has no value for either rdf:first or rdf:rest
in the graph, or has exactly one value for rdf:first in the graph and
exactly one value for rdf:rest in the graph that is also a SHACL list in the
graph and there is no non-empty path in the graph from the list back to
itself where the predicates of the RDF triples in the path are each
rdf:rest.

The **members** of any SHACL list except rdf:nil in an RDF graph consist of
its value for rdf:first in the graph followed by the members in the graph of
its value for rdf:rest in the graph.  The list rdf:nil has no **members** in
any RDF graph.


SHACL PROPERTY PATHS

A blank node is an **ill-formed SHACL property path** in an RDF graph if it
has a value for more than one of rdf:first, sh:alternativePath,
sh:inversePath, sh:zeroOrMorePath, sh:oneOrMorePath, or sh:zeroOrOnePath in
the graph.

A blank node is an **ill-formed SHACL property path** in an RDF graph if
there is a path in the graph from the node back to itself where the sequence
of predicates of the RDF triples in the path matches the regular expression
( ( rdf:rest* rdf:first ) | sh:alternativePath ( rdf:rest* rdf:first ) |
sh:inversePath | sh:zeroOrMorePath | sh:oneOrMorePath | sh:zeroOrOnePath ) +

An RDF term is an **ill-formed SHACL property path** in an RDF graph
if it does not satisfy exactly one of the conditions in the mapping below.

If an RDF term is not an ill-formed SHACL property path in an RDF graph then
it is a **SHACL property path** in the graph.

The **path mapping** in an RDF graph of a RDF term p that is not an
ill-formed SHACL property path in the graph, path(p,S), is a *SPARQL
property path expression* defined as follows:
1/ If p is an IRI then path(p,S) is PredicatePath(p).
2/ If p is a blank node that is a SHACL list in the graph that has at least
two members in the graph and none of these members are ill-formed SHACL
property paths in the graph then path(p,S) is SequencePath(path(v1,S)
... path(vn,S)) where vi are the members of p in the graph, in order.
3/ If p is a blank node that has exactly one value for sh:alternativePath in
the graph and that value is a SHACL list in the graph that has at least two
members in the graph and none of the members in the graph are ill-formed
SHACL property paths in the graph then path(p,S) is
AlternativePath(path(v1,S) ... path(vn,S)) where vi are the members of the
list in the graph, in order.
4/ If p is a blank node that has exactly one value v for sh:inversePath in
the graph and v is not an ill-formed SHACL property path in the graph then
path(p,S) is InversePath(path(v,S)).
5/ If p is a blank node that has exactly one value v for sh:zeroOrMorePath in
the graph and v is not an ill-formed SHACL property path in the graph then
path(p,S) is ZeroOrMorePath(path(v,S)).
6/ If p is a blank node that has exactly one value v for sh:oneOrMorePath in
the graph and v is not an ill-formed SHACL property path in the graph then
path(p,S) is OneOrMorePath(path(v,S)).
7/ If p is a blank node that has exactly one value v for sh:zeroOrOnePath in
the graph and v is not an ill-formed SHACL property path in the graph then
path(p,S) is ZeroOrOnePath(path(v,S)).

SHACL property paths in same or different RDF graphs are **equivalent** if
their path mappings in their graphs are the same.



Value Nodes:

A shape in an RDF graph with a value for sh:path in the graph that is an
ill-formed SHACL property path in the graph is an **ill-formed shape** in
the graph.  A shape in an RDF graph with more than one value for sh:path in
the graph is an **ill-formed shape** in the graph.

Given f an RDF term, D a data graph, and s a shape in S a shapes graph
the **value nodes** of f with D for s in S is the set containing
the values of f for path(p,S) in D if s has p as value for sh:path in S;
or just f if s has no value for sh:path in S.





On 12/09/2016 05:23 PM, Holger Knublauch wrote:
> 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 18:34:02 UTC