W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2009

Re: [sub-select] Some examples and discussion

From: Steve Harris <steve.harris@garlik.com>
Date: Fri, 13 Mar 2009 15:20:27 +0000
Message-Id: <FE960143-159A-4314-825C-1ED09186CEB3@garlik.com>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
On 12 Mar 2009, at 23:04, Eric Prud'hommeaux wrote:

> On Fri, Mar 13, 2009 at 03:48:38AM +0600, Ivan Mikhailov wrote:
>> Hello all,
>>
>>> I'm curious as to the interplay between:
>>>
>>> projected expressions
>>> sub-selects
>>> assignment
>>> Is there a combination of these that makes the 3rd irrelevant?
>
> I'd say that assignments give you the same expressivity as
> projected expression + sub-selects.

I think that's only really true if you take a very broad view on what  
constitutes an assignment.

>> Sub-selects can't be avoided, period. Projected expressions can be
>> avoided if assignments are allowed --- just LET a fake variable and
>> return it. Assignments can be avoided if projected expressions are
>> allowed (but macroexpansion of LET may result a huge amount of text).
>
> Let's examine the uses of sub-selects in SQL:
>  union - each disjoint is created from a select.
>
>  complex optionals - outer joins accepting solutions requiring a join
>  e.g. outjoin ( ... Employees JOIN Managers ON  
> Employees.id=Projects.manager ).
>
>  aggregate functions - SQL only provides aggregate operators
>  at the SELECT, so operations like "managers whose total employee
>  income is less than .5M" must wrap the intermediate aggregates
>
>  assignments - if you want to banty about someones total IQ and
>  shoesize, you can select that in a sub-select.
>
> SPARQL already has inline unions and complex optionals.  I can't
> promise that at syntax for inline aggregates, e.g.
>  { ?manager :manages ?department .
>    { ?employee :worksFor ?manager ;
>                :hasSalary ?salary .
>      LET ?total := :sum(?salary) GROUP BY ?manager
>    }
>    FILTER ( ?total > 5000000 )
>  }
> is very attractive, but then
>  { ?manager :manages ?department .
>    SELECT ?manager :sum(?salary) AS ?total
>    { ?employee :worksFor ?manager ;
>                :hasSalary ?salary .
>    }
>    FILTER ( ?total > 5000000 )
>  }
> doesn't seem to get any prettier for is reduced expressivity.

No, neither of those is exactly readable. The 1st one is more  
expressive, but then it introduces two new keywords, so you'd expect  
it to be.

While my brain likes global variable scope, I can see it being awkward  
for people trying to compose queries, especially programatically.  
Being able to wrap a sub-query completely, and only expose the project  
variables to the outer part of the query is a useful feature in and of  
itself.

- Steve

-- 
Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD
Received on Friday, 13 March 2009 15:21:14 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:38 GMT