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

Re: Negation decision : unexpected effects

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Tue, 06 Apr 2010 10:36:28 +0100
Message-ID: <4BBB009C.1010007@talis.com>
To: Steve Harris <steve.harris@garlik.com>
CC: Lee Feigenbaum <lee@thefigtrees.net>, SPARQL Working Group <public-rdf-dawg@w3.org>

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.

Minus(Ω1, Ω2) =
     { μ | μ in Ω1 such that for all μ' in Ω2,
     either μ and μ' are not compatible or dom(μ) and dom(μ') are disjoint }

Filter(expr, Ω) = { μ | μ in Ω and expr(μ) is an expression that has an
     effective boolean value of true }

Both are of the form:

    { μ | μ in LHS-Ω such that .... }

and cardinality determined solely by the LHS.

Received on Tuesday, 6 April 2010 09:36:55 UTC

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