RE: [sub-select] Some examples and discussion

> -----Original Message-----
> From: Lee Feigenbaum [mailto:figtree@gmail.com] On Behalf Of Lee
> Feigenbaum
> Sent: 12 March 2009 06:40
> To: Seaborne, Andy
> Cc: SPARQL Working Group
> Subject: Re: [sub-select] Some examples and discussion
> 
> Seaborne, Andy wrote:
> >
> > Sub-select's would cost little in terms of spec changes.  That's not
> > the same as implementation costs.
> >
> > The features that make sub-selects useful would be more costly to
> > spec.
> 
> Andy, I don't get these two paragraphs - can you explain a bit?
> In general, I like that sub-selects give a SQL-like (i.e. recognizable)
> way to bring new functionality to SPARQL, and that they're already
> implemented in at least one or two places.
> 
> My main concern with sub-selects is whether they are complex to properly
>   specify & implement, which is why i ask for more clarification here.

My sense is that the changes for sub-selects in the algebra are quite small and do not disturb other parts of the algebra.  Subs-selects combine with other patterns as a join and join already exists.  Syntax-wise, it was an extra clause in the pattern grouping rule.

Specifying aggregation and select-expressions/assignment (esp. aggregation) just seems more work - not impossible or even unclear, just more.  Some detail to be worked through in corner cases.

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.

	Andy