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

Issue-185 filter execution ordering

From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
Date: Thu, 10 Nov 2016 07:20:35 +0200
Message-ID: <CA+u4+a2VuwT=8dtcp6bbrccKrOFy+fHU=JYogq1Wz232w2=Ckw@mail.gmail.com>
To: public-data-shapes-wg <public-data-shapes-wg@w3.org>
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
Received on Thursday, 10 November 2016 05:21:35 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 10 November 2016 05:21:36 UTC