Re: Negation decision : unexpected effects

On 05/04/2010 3:53 AM, Lee Feigenbaum wrote:
> On 4/2/2010 5:05 PM, Andy Seaborne wrote:
>> The decision at F2F3 to have just the form of NOT EXISTs in an explicit
>> FILTER has a limitation. I should have realised at the time but it
>> didn't occur to me until after the meeting.
>>
>> FILTERs get moved to the end of the BGP during translation from syntax
>> to algebra. The form without the word "FILTER" does not move e.g.
>>
>> { ?s rdf:type :T
>> NOT EXISTS { ?s :p ?v . }
>> ?s :q ?v
>> }
>>
>> then NOT EXISTS is not moved about by the FILTER placement rules.
>
> Yes, this is a difference. In most cases it doesn't matter, though,
> right? I'd like to understand better the cases in which moving/not moving
> the NOT EXISTS changes the answers.

I am more concerned that is can change the answers in strange ways. 
Because it's negation, I think the effects will be particularly strange.

I did find an old email:

http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0468.html

:-)

>
>> One reason for NOT EXISTS is as a better form of the OPTIONAL/!BOUND
>> idiom, where the OPTIONAL block anchors the location of the existence
>> test by it's effect of setting, or not, a variable to be tested later.
>>
>> The FILTER could be artificially forced using a extra {}
>>
>> { { ?s rdf:type :T
>> FILTER NOT EXISTS { ?s :p ?v . }
>> }
>> ?s :q ?v
>> }
>>
>> This is unnecessary - the more direct syntax is closer to the
>> OPTIONAL/!BOUND idiom that I think it the important thing to make easier.
>>
>> Therefore I propose we adopt both negation proposals without
>> modification.
>
> 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".

This as a more direct syntax for a form with extra {} and FILTER.  I 
don't see the value in forcing extra unnecessary syntax when, for me, 
it's about replacing the OPTIONAL/!BOUND idiom, which manages not to use 
any words that relate to the task of testing for absent triples and 
patterns of triples. That is what NOT EXISTs addresses.

We wish to make other forms more convenient (no {} to LHS of MINUS and 
UNION have been suggested), why not here?

In terms of implementation experience, NOT EXISTs has been received 
quite well.

 Andy

>
>> It only affects the grammar and translation from syntax to algebra -
>> actual execution is unchanged and there is no additional implementation
>> cost for execution.
>
> To me, it makes sense to have one filter form and one graph pattern
> form. So far, I can't really make myself comfortable with the idea of
> adding two new graph pattern operators to the language that both do the
> same thing in almost all cases.
>
> Lee
>
>> Andy
>>
>>
>>

Received on Monday, 5 April 2010 20:43:10 UTC