Fwd: formal objection on pre-binding

Ahead of tomorrow’s meeting, I thought I should write some thoughts about this formal objection.

There are two parts to it:

1. “exclusion of a large number of SPARQL queries from SHACL.”

I think this is an overstatement. The exclusions boil down to not supporting MINUS, VALUES and SERVICE keywords.

The first two are essentially syntactic sugar and could be replaced by other expressions. Thus, there is no loss of functionality - the same results could be obtained by different means.

Allowing SERVICE would introduce security issues. I don’t think Peter would argue for that.

2. Possible interoperability issues:

> The
> behaviour of SHACL-SPARQL implementations on these excluded shapes is
> undefined but SHACL-SPARQL implementations are not required to produce any
> sort of signal when they encounter these excluded shapes.  Different
> completely conforming SHACL-SPARQL implementations are thus allowed to
> silently produce different results for these shapes.

I think we are not allowing these queries, but we are not saying that SHACL-SPARQL processors should fail when such disallowed queries are encountered.

We could make such statement. This would eliminate any interoperability issues. I think it would be easy for implementations to check if queries contain prohibited keywords. I think, however, we would then need to introduce a couple of tests to test for this and implementations would need to be updated, pushing out the date by which we can submit the transition request.

Lets discuss.

> Begin forwarded message:
> 
> From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
> Subject: formal objection on pre-binding
> Date: May 2, 2017 at 11:52:40 AM EDT
> To: "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
> Resent-From: public-rdf-shapes@w3.org
> 
> This is a formal objection to the definition of pre-binding approved by the
> working group in its meeting of 26 April 2017 and in the SHACL Editor's
> Draft current as of 28 April 2017 (but with date indicated as 11 April
> 2017).
> 
> Pre-binding has never had a suitable definition in SHACL.  Problems with
> pre-binding have been known to the working group since at least June of
> 2015.  The current definition of pre-binding has multiple documented
> problems.  The only change to pre-binding from Candidate Recommendation has
> been to paper over some of these problems by excluding large numbers of
> SPARQL queries from SHACL-SPARQL.
> 
> These exclusions introduce new interoperability problems for SHACL.  These
> exclusions remove many useful SPARQL queries from SHACL-SPARQL, including an
> example SPARQL query in the SHACL document.  These exclusions also do not
> exclude all SPARQL queries whose meaning is not as expected with
> pre-binding.
> 
> The solution to the continuing problems with pre-binding is not to exclude
> more and more of SPARQL but to either fix pre-binding so that it works
> correctly or eliminate pre-binding from SHACL.
> 
> 
> 
> Although this is nowhere stated in the SHACL document, it appears that the
> indent of the current definition of pre-binding is to make the binding of a
> pre-bound variable available everywhere in the query except for in
> sub-queries that do not project the variable.  The current definition of
> pre-binding tries to achieve this by two main mechanisms.  The first
> mechanism is renaming of variables in sub-queries that are not projected to
> fresh variables.  The second mechanism joins pre-bound bindings to all basic
> graph patterns, property path expressions, and named graph patterns in the
> query.
> 
> However, the current definition of pre-binding fails to achieve the goal
> stated above.  The bindings of pre-bound variables are sometimes not
> available when needed.  This causes problems in a large number of queries,
> many of which have been already pointed out.  Also the pre-bound bindings
> are available even in places where none of the variables are in scope.  This
> causes problems for MINUS.
> 
> The recent changes to the pre-binding section of the SHACL document do not
> actually change the definition of pre-binding to fix these problems but
> instead just exclude many SPARQL queries from SHACL, presumably to keep only
> non-problematic queries.  The exclusions are very broad, and eliminate many
> queries that do not have any problems for the current definition of
> pre-binding.
> 
> The exclusion of so many SPARQL queries, particularly as many of them are
> non-problematic, is a new source of interoperability problems for SHACL.  It
> is easy for users to write SHACL-SPARQL shapes that are excluded.  The
> behaviour of SHACL-SPARQL implementations on these excluded shapes is
> undefined but SHACL-SPARQL implementations are not required to produce any
> sort of signal when they encounter these excluded shapes.  Different
> completely conforming SHACL-SPARQL implementations are thus allowed to
> silently produce different results for these shapes.
> 
> The exclusions are so broad that they even exclude the example potential
> definitional query for sh:EqualsConstraintComponent in the current SHACL
> document itself.
> 
> The exclusions do not even exclude all problematic queries.  For example, a
> SPARQL-SHACL shape based on the non-excluded query
>  SELECT DISTINCT $this WHERE {
>    { SELECT $this ?class WHERE { VALUES ?class { ex:C ex:D } } }
>    BIND ( $this AS ?that )
>    ?that a ?class . }
> will produce violations for all target nodes whenever any node in the graph
> has ex:C or ex:D as a value for rdf:type counter to the expectation that it
> should produce violations only for target nodes that have ex:C or ex:D as a
> value for rdf:type.
> 
> The use of a problematic definition of pre-binding needs to be eliminated
> from SHACL.  Papering over these problems, even if possible, is not a
> suitable solution.
> 
> 
> Peter F. Patel-Schneider
> Nuance Communications
>