Re: Negation decision : unexpected effects

On 05/04/2010 9:51 PM, Lee Feigenbaum wrote:
> 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.

I think this stikes to the heart of the issue here: MINUS isn't negation 
of the pattern, it's remove of compatible, related bindings.

The section headings I've put in so far for this are:

[[
8.1 Testing for the absence of a pattern

8.2 Removing bindings
]]
and the choice of 8.2 wording was based on Steve's wording in:
http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0663.html

(I had tried "resource oriented" but no one picked up on that).

Other suggestions more than welcome.


For example:

{ ?s ?p ?o MINUS { SELECT (:s AS ?s){} } }

removes the ?s=:s binding rows regardless of the contents of the graph.

{ ?s ?p ?o MINUS { ?x ?y ?z } }

where the contents of the graph don't matter for the MINUS (if it's 
empty ?s ?p ?o is zero rows)

 Andy

>
> 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 21:15:26 UTC