Re: revised formal objection on pre-binding

Peter,

One can create an infinite variety of SPARQL queries. In fact, addition of any SPARQL keyword, by itself, creates an infinite number of queries. Given this, when any single SPARQL keyword is excluded, one could, in principle, claim that a large number of queries are excluded and that this is a ground for a formal objection. In practice, this claim doesn’t hold water.

The excluded keywords are limited to MINUS, VALUES and SERVICE.

As you, yourself, pointed out SERVICE creates all sort of security concerns, so we don’t need to discuss it.

VALUES are used to provide inline data with the primary use case of it being in conjunction with the SERVICE keyword for federated queries.

Some queries that use MINUS could be reformulated not to use it.

In the end, the exclusions are minor. The rest of SPARQL functionality (and it is a rich and extensive functionality) is allowed. Practically speaking, SHACL-SPARQL users have the majority of SPARQL features at their disposal - enough to meet an infinite variety of use cases.

While future efforts could extend the current pre-binding definition or create a new and better definition, this WG has already made a very significant contribution towards extending the arsenal of capabilities and tools users will have at their disposal for validating RDF and addressing other requirements in the WG’s charter. Every single potential user of SHACL I have talked to expressed a strong desire for a stable standard to be available for their use today (in fact, yesterday). Given a choice between a)SHACL-SPARQL being available today with the (really) pretty minor limitations in the allowed SPARQL constructs and b)SHACL-SPARQL being available some months or years from now without these limitations - there is no question as to what these users would choose. It is hands down a). They need the functionality today because it closes a critical gap that has been existing for years. 

Personally, I am proud that we were able to accomplish this and I regret that you don’t share this feeling.

I am sure that SPARQL WG (and other working groups in the past) made exactly the same choice when they released SPARQL 1.0 and, probably, even when they have released SPARQL 1.1. They could still have been working today to add more and more capabilities to the language. Instead, they made the only sensible choice by releasing a more limited set of features that still met a great need.


Irene


> On May 4, 2017, at 2:12 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> This is a formal objection to the definition of pre-binding approved by the
> working group in its meeting of 3 May 2017 and in the SHACL Editor's
> Draft current as of 4 May 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 remove many useful
> SPARQL queries from SHACL-SPARQL, including the SPARQL query that provided
> an alternative definition of the semantics of sh:equals that was in the
> SHACL document.
> 
> 
> 
> 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 pre-bound bindings are available in
> sub-queries, which prevents bottom-up evaluation of sub-queries.
> 
> 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 exclusions are so broad that they even exclude the example potential
> definitional query for sh:EqualsConstraintComponent that was in the SHACL
> document.
> 
> 
> 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.  Papering over these
> problems, even if possible, is not a suitable solution.
> 
> Peter F. Patel-Schneider
> Nuance Communications
>

Received on Friday, 5 May 2017 02:10:23 UTC