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