Issue-185 filter execution ordering

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
Research Group: AKSW/KILT http://aksw.org/Groups/KILT