- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Thu, 12 Mar 2009 21:21:47 -0400
- To: Chimezie Ogbuji <ogbujic@ccf.org>
- CC: "Seaborne, Andy" <andy.seaborne@hp.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
Chimezie Ogbuji wrote: > On 3/12/09 9:14 AM, "Seaborne, Andy" <andy.seaborne@hp.com> wrote: >> As for implementation, putting subs-selects was not hard when I added the >> functionality in ARQ and I didn't have an existing DB engine to pull existing >> features from. I don't think it was luck that other designs decisions had set >> things up, more it was a natural step. Other opinions may differ. >> What is hard, as had been pointed out, is optimization, but that is not to be >> specified. > > I don't think I agree that optimization and implementation effort (which is > a direct consequence of the complexity introduced by more expressive query > forms such as sub-selects) should *not* be a factor. In fact, it is mostly > my concern in this regard that motivates me to suggest that we consider a > spectrum of sub-select features to include. Chime, I was intrigued by your suggestion regarding a limited form of sub-select on the teleconference, but admit that I couldn't immediately see what that would look like. Do you have a concrete proposal for how this might work? (just a sketch would be helpful!) thanks, Lee
Received on Friday, 13 March 2009 01:22:37 UTC