- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Thu, 9 Mar 2017 08:20:18 -0800
- To: public-rdf-shapes@w3.org
I did a closer examination of the problem with "possible route". It turns out that "possible route" appears in one place in the SPARQL document, at the beginning of Section 9. There is no definition of "possible route" or even "route" anywhere in the SPARQL document. So what is going on in SPARQL with respect to this occurrence? It is actually somewhat difficult to tease out the situation. The SPARQL document has a bunch of terms related to property paths, including "path", "property path", "SPARQL property path", and "property path expression". My reconstruction is that in the SPARQL document, - "path" is a path in an RDF graph, which involves a sequence of triples, - "property path" is a bit of SPARQL surface syntax or a path in a graph, - "SPARQL property path" generally is a bit of SPARQL surface syntax - "property path expression" generally is a bit of SPARQL abstract syntax So "A property path is a possible route in a graph between two graph nodes." has to refer to the second meaning of property path. This doesn't make much sense as a part of Section 9, which is generally talking about syntax. This is annoying, but doesn't matter too much because the real definitions related to property paths are in Section 18.1.7 where "property path" is formally defined in terms of connected triples in an RDF graph and "property path expression" is defined as part of the SPARQL syntax. There is also sort of a definition of property paths in the SPARQL algebra in Section 18.2. So in the end the sentence containing "possible route" doesn't really get used for anything in SPARQL and the lack of a definition for "possible route" in SPARQL is not a serious problem. However, this does mean that using this sentence elsewhere can cause problems. The sentence is used in SHACL in the portion of the SHACL document that sets up the underlying terminology for SHACL. Using undefined terms in here can undermine the entirety of SHACL. Does this dire consequence actually happen? Probably not, but the situation is rather murky. In the SHACL document there are several terms that are related to property paths, including "property path", "SPARQL property path expression", There is considerable sloppiness in the SHACL document related to property paths, but as far as I can determine the general idea is that: - "property path" is a piece of SPARQL surface syntax, - "SPARQL property path expression" is a piece of SPARQL abstract syntax - "SPARQL 1.1 property path" is a piece of SPARQL syntax - "SPARQL property path" is a piece of SPARQL syntax - "SHACL property path" is a node in a shapes graph - "well-formed SHACL property path" is a node in a shapes graph that satisfies certain conditions - "well-formed property path" is probably a node in a shapes graph - "property path expression" is a property path expression from SPARQL 1.1 So there are lots of terms, many of which have the same meaning. At the very least there needs to be a cleanup of these terms. None of these terms are can be considered to mean anything like routes in an RDF graph so the sentence "A property path is a possible route in a graph between two graph nodes." is incorrect for SHACL. Fortunately the unqualified uses of "property path" in SHACL are few and are in contexts where the actual meaning can be generally locally deciphered, overriding the definition in the terminology section. So the incorrect statement there doesn't end up causing irreparable damage to SHACL. It still needs to be removed or replaced with something correct. What needs to be done is to tighten up the terminology and use of terms related to property paths in the SHACL document. This should have been done in response to the original reporting of the problem, not as a response to this message. The working group still needs to take a close look at the SHACL document to identify and fix its continuing problems with sloppy and unfounded definitions and terminology. Peter F. Patel-Schneider Nuance Communications
Received on Thursday, 9 March 2017 16:20:56 UTC