Re: pre-binding as used in SHACL document

Peter,

Examples, tests and implementations are correct.

I believe you are referring to the projection and re-mapping definitions in the appendix A and interpreting them broader than intended. These have always been intended to apply only to sub-queries, not to the top level queries. There is no need to do the remapping for the variables in the top level queries.  Implementors did understand it correctly  - as per the tests and examples.

Further, given that the SHACL WG decided a week ago to always require for the sub-queries to return all pre-bound variables,  there is now no need to stipulate this for the subqueries either. These definitions are no longer needed by SHACL and have been removed from the document. 

I believe that in the context of the EXIST CG Note, they are still needed and the note may need to further clarify their applicability.

Regards,

Irene


> On May 9, 2017, at 6:53 AM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> 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 Friday, 12 May 2017 02:52:43 UTC