- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Mon, 12 Dec 2016 09:49:11 +0200
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Cc: Holger Knublauch <holger@topquadrant.com>, "public-rdf-sha." <public-rdf-shapes@w3.org>
- Message-ID: <CA+u4+a0ksaqQ+XGqmonLV4qybs9BmX1FW_T40kFy-va2ARes+A@mail.gmail.com>
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> 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>> 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 > >>> > > > > -- 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 17:56:05 UTC