Re: closer examination of "possible route" Re: Comments on Shapes Constraint Language (SHACL) W3C Editor's Draft 22 February 2017

I have slightly restructured the path-related terminology to avoid the 
vague definition of "possible routes" and instead talk specifically 
about SPARQL property paths. The pure "path" was barely referenced 
anyway, so that most references are now either SPARQL property paths or 
SHACL property paths.

I hope that, while never perfect for every possible interpretation, the 
prose is now sufficiently clean so that we can move on.

https://github.com/w3c/data-shapes/commit/a2943aca966332c913f33110c88df29a36b3bd0b

Thanks,
Holger


On 10/03/2017 2:20, Peter F. Patel-Schneider wrote:
> 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 Wednesday, 22 March 2017 00:04:26 UTC