Re: Issue-185 filter execution ordering

I am not sure I follow the relation with the targets here, the definition
on targets is quite clear and defined for a long time.
"A data graph validates against a shape if and only if each node that is in
any of the targets of the shape validates against the shape"

With filters it was different, the definition did not require ordering but
we changed (many times) other parts in the spec to require or not require
ordering of the execution
So the spec was inconsistent at some points in time.
Now the spec is consistent with the validation definition we have for
almost a year (or more) and everyone agreed on.


On Thu, Nov 10, 2016 at 12:55 PM, Holger Knublauch <holger@topquadrant.com>
wrote:

> 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.
>
> Holger
>
>
>
> On 10/11/2016 15:20, Dimitris Kontokostas wrote:
>
> Hi Marq,  thanks for the pull request
> 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
>
>
>


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