Re: SNAF, NAF, and monotonicity [was: Comments on * DRAFT * Rules...]

Dan Connolly wrote:
>
> On Aug 24, 2005, at 8:11 PM, Michael Kifer wrote:
> [...]
> > No, you got me wrong. I do believe that nonmonotonicity is important,  
> > but
> > you already have it in the form of SNAF.
> 
> I'm having trouble understanding that. I see it shows up in several of  
> your recent messages, e.g.
> 
> "SNAF is nonmonotonic."
> http://lists.w3.org/Archives/Public/public-rule-workshop-discuss/ 
> 2005Aug/0029.html
> 
> My understanding is that SNAF is monotonic.
> 
> Earlier[1] we discussed this example rule...
> 
> { :car.auto:specification log:notIncludes {:car auto:color []}}
>      => {:car auto:color auto:black}.
> 
> That rule is monotonic; if the antecedent is true, the consequent  
> remains
> true regardless of how many other things are also true.

Hi Dan,
Welcome to the discussion! Yes, it is very important to get to the bottom
of it so that everybody will start speaking the same language.

No, the above rule is nonmonotonic. If you add a color specification to
that car then :car.auto:specification will now include a color
specification and log:notIncludes will become false. Therefore 
    :car auto:color auto:black
will no longer be derived.

> Your flora-2 translation[2] (for which thanks; I've been studying it  
> for a while...)
> also seems monotonic:
> 
> ?X[realColor->?Color] :- ?X[color->?Color]@allAboutCars.
> ?X[realColor->black] :- not ?X.color[]@allAboutCars.

The same with this example. If we don't have anything about the color of
some car123 in scope allAboutCars then car123[realColor->black] will be
derived. If we now insert car123[color->green] into allAboutCars then
car123[realColor->black] is no longer derivable because now
	car123.color[]@allAboutCars
becomes true and, therefore,
	not car123.color[]@allAboutCars
becomes false.

> Earlier you wrote that
> "NAF is a special case of SNAF."
> http://lists.w3.org/Archives/Public/public-rule-workshop-discuss/2005Aug/0012.html
> 
> I don't see how that's the case. The whole point of SNAF is that the  
> scope is
> explicit and hence the construct is monotonic. I don't see how to look  
> at NAF
> as a special case of that.

The "hence" part here is not warranted. Scoping doesn't make nonmonotonic
NAF into a monotonic SNAF. Has nothing to do with monotonicity (as I showed
using the above examples).

We all agree that "naive" NAF (see * below) doesn't make sense on the
Web. But this is not because it is nonmonotonic. The reason is that "naive"
NAF is not defined in a context like the Web, where the extent of the
knowledge base cannot be known at any given moment. Has nothing to do with
scalability or anything. It is just because naive NAF is like the Unicorn
-- doesn't exist.

* By naive NAF I mean a statement like "if X can't be proved on the Web
  then X is false."
  In all cases where people attacked NAF as non-scalable, inappropriate, or
  as making no sense for the Web I could see that they were talking about
  that "naive" NAF. And they were right! The only trouble was that they are
  talking about a concept that doesn't exist in the scientific literature.

On the other hand, NAF where the scope is implicit *but rigorously defined*
does make sense on and outside the Web. This is what most Prologs do.  In
my experience, however, implicitly scoped NAFs are inconvenient even in
Prologs.  This is how scoped inference (and a form of SNAF) got into
FLORA-2.

On the Web, explicit scope can have many uses -- not just for negation.
This is what the TRIPLE people have been saying for a few years also.


> Monotonicity is an important scaling property of a language, so I'm  
> very interested to understand this point.

I am not clear what does monotonicity have to do with scalability.


	regards
	  --michael

Received on Thursday, 25 August 2005 04:00:53 UTC