Re: Negation decision : unexpected effects

On 4/5/2010 4:42 PM, Andy Seaborne wrote:
>
>
> 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".

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.

This may be purely a pedagogical issue, but I think it's pretty 
significant.

Lee

>
> 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:51:47 UTC