Issue-185 filter execution ordering

Hi Marq,  thanks for the pull request

<>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

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

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)?

Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Research Group: AKSW/KILT

Received on Thursday, 10 November 2016 05:21:35 UTC