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

Received on Thursday, 12 March 2009 13:15:56 UTC