Re: formal objection on pre-binding

This is the first requirement that SHACL implementations signal a failure
when they encounter shapes that are ill-formed or that they do not handle.

This is a significant change to SHACL-SPARQL and requires sigmificant change
to SHACL-SPARQL implementations.  Checking the restrictions on pre-binding
is not simple at all as it requires determining whether pre-bound variables
are in scope in subqueries.

The test pre-binding-006.ttl does not return all potentially pre-bound
variables from its subquery and thus now results in a failure.  The test
suite is missing an example showing a subquery using SELECT * that does
return all potentially pre-bound results, such as

ex:s1 a sh:NodeShape ;
 sh:sparql [ sh:select """
  SELECT ?this {
     SELECT * WHERE { $this a $value . $shapesGraph a $currentShape }
     }""" ] .


Given that there is now a requirement on SHACL implementations to check for
certain kinds of ill-formed shapes or shapes that they do not handle it is
even less defensible to not require them to check for other kinds of
ill-formed shapes and shapes that they do not handle.


Peter F. Patel-Schneider
Nuance Communications




On 05/03/2017 07:06 PM, Holger Knublauch wrote:
> On 3/05/2017 1:52, Peter F. Patel-Schneider wrote:
>> 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.
> 
> This has been changed today: engines are now required to produce a failure if
> they detect such queries.
> 
>>
>> 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.
> 
> You have enumerate various issues that had already been fixed before you wrote
> your formal objection. MINUS and VALUES were already made illegal. The example
> at sh:equals was already removed. You may want to update your objection to
> reflect the latest changes.
> 
> You have been a very vocal critic of pre-binding for over two years now. But
> it is much easier to criticize a design than to propose workable alternatives.
> No-one has produced a better definition of pre-binding so far. Dropping the
> whole feature of SHACL-SPARQL only because of some cases that can easily be
> worked around is not a productive proposal. Pre-binding has been used
> successfully in practice in many applications including those based on SPIN.
> If you can produce a better definition of such a feature that still covers
> similar use cases then it will certainly happily be considered for future
> revisions of SHACL. This is version 1.0 only, and few of the widely used
> standards (RDF, SPARQL, OWL) have solved everything perfectly in their first
> iterations.
> 
> Holger
>

Received on Thursday, 4 May 2017 18:04:45 UTC