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

Re: [sub-select] Some examples and discussion

From: Eric Prud'hommeaux <eric@w3.org>
Date: Thu, 12 Mar 2009 19:04:20 -0400
To: Ivan Mikhailov <imikhailov@openlinksw.com>
Cc: Steve Harris <steve.harris@garlik.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
Message-ID: <20090312230420.GB1114@w3.org>
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. 


> 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.


> I'd recommend to not choose 20 of 3 as soon as all 3 can be implemented.
> Developers have enough reasons for headache, an artificial puzzle of
> weird limitations of the language will not make them happy.
> 
> Best Regards,
> 
> Ivan Mikhailov
> OpenLink Software
> http://virtuoso.openlinksw.com
> 
> 

-- 
-eric

office: +1.617.258.5741 32-G528, MIT, Cambridge, MA 02144 USA
mobile: +1.617.599.3509

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Thursday, 12 March 2009 23:04:36 GMT

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