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 09:59:42 +0100
Message-ID: <4BBAF7FE.9040806@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 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:
>>> On 2010-04-05, at 21:51, Lee Feigenbaum wrote:
>>>>>>
>>>>>> I wouldn't be in favor of this proposal - I'd find it very difficult to
>>>>>> justify adding 2 forms of negation to SPARQL that seem virtually
>>>>>> indistinguishable from one another in most scenarios.
>>>>>
>>>>> We are doing that under the F2F3 resolution (the second one) regardless
>>>>> of my proposal and under the first proposal of the F2F, negation used
>>>>> the syntax "NOT EXISTS".
>>>>
>>>> I believe that most of the user world would simply accept that the words used for negation as a graph pattern and negation in a filter are different. I don't think any such easy explanation can be given when both can be used as graph pattern keywords.
>>>
>>> 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.

MINUS (or EXCEPT) does have the extra condition about non-disjointness 
of mapping domains.

	Andy
Received on Tuesday, 6 April 2010 09:00:13 GMT

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