Re: [NEW ISSUE?] NAF & !BOUND

On Sep 12, 2006, at 11:19 PM, Pat Hayes wrote:

>> I'm raising this mostly on behalf of Jorge Pérez, Axel Polleres,  
>> and myself, though we all have slightly different perspectives. I
>>
>> http://www.w3.org/2001/sw/DataAccess/rq23/rq24.html#func-bound
>>
>> """One may test that a graph pattern is not expressed by  
>> specifying an optional graph pattern that introduces a variable  
>> and testing to see that the variable is not bound. This is called  
>> Negation as Failure in logic programming."""
>>
>> The main concern is that if we are going to allow NAF (which we  
>> currently do)
>
> Well, wait a minute. I don't think that we do.

We offer what I'd consider to be a NAF operator, restricted to  
queries. Seems straightfoward.

> And I would prefer that the spec not mention NAF this explicitly.  
> Just checking that something is not present in the KB does not, in  
> itself, constitute NAF reasoning. What makes it NAF is to infer  
> from its absence that it is false,

Well, you can add an answer based on the lack of information. That's  
definitely nonmonontonic. If we are going to offer a nonmon operator,  
I'd prefer it to be more usable.

If we used SPARQL queries as a condition language for rules (which is  
a perfectly sane reading of sparql as it stands; answers are views;  
views are rules; these views are nonrecursive), the it seems like  
straightfoward NAF.

> and *that* isn't sanctioned either by the RDF or SPARQL semantics,  
> although to be fair its also not explicitly ruled out by them  
> either. It seems to me that being able to detect non-binding -  
> which I agree is too useful for us not to provide it - is what  
> might be called NAF-neutral: it allows someone to implement NAF if  
> they want to, but it does not of itself sanction it semantically.

Well, I don't see that in the SPARQL semantics it's *not* sanctioned.  
It allows you to put in an answer based on missing information. You  
retract that answer as you gain more information. If you formalized  
the whole of the sparql query evaluation process, you would almost  
certainly map it to a NAF operator (e.g., I don't see how you could  
do this in a SWRL flavored language). If it looks like NAF, sNAFfs  
like NAF, it's close enough to NAF for me.

> Which, I suggest, is exactly the stance we should adopt, since RDF  
> is also neutral on the matter. It is possible to have an RDF  
> semantic extension which would make NAF valid, as well as those  
> like OWL that do not.

Seems like SPARQL is doing that.

>> , then we should allow for it in a more convenient form, e.g., a  
>> not or \+ operator. I think if we stick with it in this limited  
>> form, then we should call it out better as it's a pretty  
>> fundamental (though very useful) shift in SemWeb philosophy at the  
>> W3C.
>
> I don't think that what we have now amounts to a shift of policy. I  
> agree we should state it differently, and more carefully, than we  
> currently do, however.

I'd welcome such text, though I don't know if it would satisfy Axel.

Cheers,
Bijan.

Received on Wednesday, 13 September 2006 08:21:43 UTC