- From: Axel Polleres <axel.polleres@deri.org>
- Date: Sat, 11 Feb 2012 20:22:49 +0100
- To: "Gregory Williams" <greg@evilfunhouse.com>
- Cc: "Lee Feigenbaum" <lee@thefigtrees.net>, "SPARQL Working Group" <public-rdf-dawg@w3.org>
> Why do we need to define the equivalence or potential optimization spots at all? If there had been an easy way to define an equivalence with what we have, it would probably have simplified answering/addressing the comment directly. [...] > Why can't we leave other semantics and optimizations to implementors and any future WG to nail down? Sure, I was just summarizing what I had understood as the two options to address the comment from the last Telco. Just leaving things as they are, and pointing to a future WG is another Option. Should we call it Option3? Axel On 11 Feb 2012, at 20:12, Gregory Williams wrote: > On Feb 11, 2012, at 2:02 PM, Axel Polleres wrote: > > > Sure, the query was kept simple just to show the problem why I think that it's not trivial to find an equivalent way of expressing Jorge's semantics, > > So the path expression wasn't my point, but the blank node... I simply don't know a way how to write > > an equivalent DISTINCT subquery where these things wouldn't intermingle. > > > > So, I am unsure how exactly we "implement" Option 1: > > > >> Option 1... keep everything as it is in the grammar, and explain which DISTINCT path subqueries can be optimized > > > > What I am missing is an understanding/definition of which DISTINCT path subquerise could be optimized and how. > > Jorge's paper outlines how this can be done for their semantics, if we don't have a way to express their > > semantics, what are the queries that can be optimized and how? > > Why do we need to define the equivalence or potential optimization spots at all? This email thread alone has me convinced that we don't know enough about this to force it into a standard. We've defined one set of semantics, and provided reasons why we think it's important. Why can't we leave other semantics and optimizations to implementors and any future WG to nail down? > > .greg > >
Received on Saturday, 11 February 2012 19:23:19 UTC