pre-binding as used in SHACL document

I took a quick look at the use of pre-binding in the SHACL document, version
07 May 2017.  Previously I had been looking at the definition of pre-binding
and only looking at its use when I found problems.

I found that many uses of pre-binding in the document produce unsuitable or
unexpected results.  This shows that there has been no effective review of
the current definition of pre-binding to check whether it is suitable for
use in SHACL, a very surprising situation for such a central part of
SHACL-SPARQL.


Here are a few of the uses of pre-binding where it produces unsuitable or
unexpected results.

The very first use of pre-binding in the document produces completely
unsuitable results.
  SELECT DISTINCT ?this WHERE { BIND ($targetNode AS ?this) }
with the variable targetNode pre-bound to some RDF term will produce a
solution sequence containing a single solution.  That solution will have
the variable this unbound.

The second use of pre-binding also produces completely unsuitable results.
  SELECT DISTINCT ?this WHERE {
    ?this rdf:type/rdfs:subClassOf* $targetClass .
    }
with the variable targetClass pre-bound to some RDF term will produce a
solution sequence containing solutions binding the variable this to each
node in the graph that is the subject of a triple in the graph with rdf:type
as predicate.

The second-last use of pre-binding produces unexpected results.  The
results of
  SELECT DISTINCT $this ?value WHERE {
    $this $PATH ?value .
    FILTER (!isLiteral(?value) || !langMatches(lang(?value), $lang))
    }
are independent of the pre-binding of the variable lang.  This query forms
the basis of one of the SHACL-SPARQL tests, with expected results
dramatically different from the ones actually produced by the current
definition of pre-binding.  SHACL-SPARQL implementations thus are not
implementing pre-binding as currently defined.


Peter F. Patel-Schneider
Nuance Communications

Received on Tuesday, 9 May 2017 10:54:26 UTC