W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2010

Re: limit per resource rethought...

From: Steve Harris <steve.harris@garlik.com>
Date: Sat, 21 Aug 2010 18:09:44 +0100
Cc: Axel Polleres <axel.polleres@deri.org>, Paul Gearon <gearon@ieee.org>, SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <B06124E7-0932-40C0-BE45-EC7A5822642E@garlik.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
On 2010-08-21, at 16:18, Andy Seaborne wrote:
> On 13/08/2010 11:22 AM, Steve Harris wrote:
>> On 2010-08-13, at 09:59, Axel Polleres wrote:
>>> Just for comparison... this is how that would work in SQL ... assume I have the
>>> knows relation in a table KNOWS(A,B):
>> That kind of subquery isn't really equivalent, but SQL subqueries work bottom-up, like SPARQL:
> The interesting thing about Axel's SQL query is that it uses an outer reference (SQL terminology) where k1.A is referring to a column outside the ()-SELECT.
> Evaluation is defined as:
> """ SQL-92
> 2) Each <subquery> in the <search condition> is effectively exe-
>   cuted for each row of T and the results used in the application
>   of the <search condition> to the given row of T. If any executed
>   <subquery> contains an outer reference to a column of T, then
>   the reference is to the value of that column in the given row of
>   T.
> """
> but I'm not immediately clear from that what happens in the SQL equivalent of nested optionals as I read it as saying the <subquery>
> is (logically) executed for every row of the outer query with the outer reference bound to the value in the outer query.

Ah, that's interesting - I'd missed that when I read the section on subqueries, so at least one part of SQL is explicitly top-down. Hmmm.

- Steve

Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  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 Saturday, 21 August 2010 17:10:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:01 UTC