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

Re: Negation decision : unexpected effects

From: Steve Harris <steve.harris@garlik.com>
Date: Tue, 6 Apr 2010 11:27:21 +0100
Cc: Lee Feigenbaum <lee@thefigtrees.net>, SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <D94DDCE5-30A0-49CD-BCAC-BF43F60A9D92@garlik.com>
To: Andy Seaborne <andy.seaborne@talis.com>
On 2010-04-06, at 10:36, Andy Seaborne wrote:
> On 06/04/2010 10:19 AM, Steve Harris wrote:
>> On 2010-04-06, at 09:59, Andy Seaborne wrote:
>>> On 06/04/2010 9:20 AM, Steve Harris wrote:
>>>> On 2010-04-06, at 09:07, Andy Seaborne wrote:
>>>>> On 05/04/2010 10:16 PM, Steve Harris wrote:
>>>>>> Indeed, SQL has the MINUS table operation, and NOT EXISTS in the WHERE/FILTER operation as well.
>>>>> In SQL, MINUS goes outside SELECT, making it outside GROUP BY and separate from the join condition part of the SQL query.
>>>> Yup, but so do the other table operations, UNION and friends.
>>> SPARQL UNION does not need the column compatibility rules.  We don't have INTERSECTION directly ... yet.
>> Well, SQL UNION has rules that there must be the same number of columns, and of the same type - SPARQL's UNION is much laxer. This is a good thing IMHO, though I wasn't convinced of that during the previous WG :)
>> SQL doesn't really have a notion of "compatibility" beyond that.
> SQL MINUS has to match as well.
> Really, SPARQL MINUS should be in a FILTER - as an operation, the result can only be the same as the LHS with possibly some rows removed, which is what FILTER does.

I couldn't disagree more.

It's possibly just the view I get from working on the 4store codebase, but there FILTER is a completely different kind of operation from Join, OPTIONAL, UNION, MINUS and co.

The algebraic operators work over tables of binding values in one (possibly distributed) operation using sorted joins, and FILTER iterates over them.

- Steve

Steve Harris, 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 Tuesday, 6 April 2010 10:27:51 UTC

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