Re: formal objection on pre-binding

On 5/05/2017 4:04, Peter F. Patel-Schneider wrote:
> 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.

The only reason why we have changed the policy to be stricter is because 
you have filed a formal objection. I otherwise wouldn't have favored 
this approach, esp because it reduces the flexibility for implementers 
in case more syntax cases get supported in the future. I am very sad 
that the W3C process allows this kind of outside influence and hope it 
doesn't get overused further.

Holger



> 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 21:48:49 UTC