W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > November 2016

Re: Issue-185 filter execution ordering

From: Holger Knublauch <holger@topquadrant.com>
Date: Thu, 10 Nov 2016 20:55:54 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <6c7e0ede-fff8-0799-4af8-3ef95cd34f2d@topquadrant.com>
If we take SPARQL generation as an argument, then shouldn't we extend 
this to targets, too? Typically an engine would generate a SPARQL query 
that includes the target binding clause in the beginning, then applies 
the filters and then the constraints. But of course, an optimizer may 
reorder these pieces.

So in a sense, your argument that keeping the order undefined is 
consistent with the rest of SHACL is not really valid, because we assume 
that targets are selected first, before filters and constraints - they 
produce the pre-bindings for ?this. And even if we hypothetically 
deleted filter shapes, we would still have the same questions with targets.


On 10/11/2016 15:20, Dimitris Kontokostas wrote:
> Hi Marq,  thanks for the pull request
> https://github.com/w3c/data-shapes/pull/23 
> <https://github.com/w3c/data-shapes/pull/23>
> Since you were one of the main people pushing to enforce ordering 
> during the call (with Ted) I am trying to see what use cases you are 
> trying to cover with this change.
> The way I see it it is like this, but maybe I am missing something
> A) with ordering
>  - there is NO room for engine optimisations
>  - we avoid some strange / rare situations when fatal errors occur.
> but fatal errors are a) implementation specific and b) from my 
> experience come  from badly written / malformed SPARQL queries (in 
> SPARQL-based systems).
> going further into fatal errors and execution ordering, we have the 
> exact same issue for sh:and and sh:or
> where we decided to allow the engines to choose the execution ordering 
> despite the fact that fatal errors may change the results
> https://www.w3.org/2014/data-shapes/track/issues/76
> https://www.w3.org/2015/08/20-shapes-minutes.html#resolution04
> B) without dictating execution ordering
>  - it is consistent with the existing design of SHACL
>  - We allow the engine to decide what is the best way to the processing
>  - we can fit all filters / shape constraints into a single SPARQL query
> I see consistency and two use cases in (B), what can you achieve with (A)?
> Best,
> Dimitris
> -- 
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia 
> Association
> Projects: http://dbpedia.org, http://rdfunit.aksw.org, 
> http://aligned-project.eu
> Homepage: http://aksw.org/DimitrisKontokostas 
> <http://aksw.org/DimitrisKontokostas>
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT 
> <http://aksw.org/Groups/KILT>
Received on Thursday, 10 November 2016 10:56:28 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 10 November 2016 10:56:28 UTC