Re: on sh:resultPath

That's a bug in my definitions.  I was trying to come up with something that
fit into Section 9 of the SPARQL document.


The wording in the current SHACL document

The values of a property path path for a given node s are the distinct
bindings produced by a SPARQL processor for the variable o from a
TriplesBlock of the form s path ?o.

captures the general idea.  However, this definition doesn't work for blank nodes.

A solution is to use something like

An RDF term n has value v for *SPARQL property path expression* p in an RDF
graph G if there is a solution mapping in the result of the SPARQL query
SELECT ?s ?o WHERE { ?s p' ?o } on G that binds ?s to n and ?o to v where p'
is SPARQL surface syntax for p.


peter




On 12/11/2016 11:49 PM, Dimitris Kontokostas wrote:
> Thank you for your great feedback Peter,
> 
> regarding the definition of *path* what was your intent wrt the existing
> definition of *property paths* , replace or add?
> I am asking because this definition allows only forward paths (not inverse)
> 
> Best,
> Dimitris
> 
> On Sat, Dec 10, 2016 at 8:33 PM, Peter F. Patel-Schneider
> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
> 
>     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>
>     >>> <mailto: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>
>     >>>      <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
>     <http://aksw.org/DimitrisKontokostas>
>     >>> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>     >>>
>     >
> 
> 
> 
> 
> -- 
> 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 Monday, 12 December 2016 18:08:27 UTC