Re: Negation decision : unexpected effects

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