Re: soundness for RIF

> 
> > > To put it in different terms, the requirement I'm proposing is a
> > > requirement for many of our use cases, but yes, it conflicts with other
> > > requirements.  We need some clever solution.  Several people (including
> > > TimBL and Michael Kifer) have suggested they have solutions.  I believe
> > > I can represent Tim's solution (which is essentiall N3's log:notIncludes
> > > predicate).
> > 
> > Solution for what? notIncludes is not negation as failure. It is simply a
> > built-in. It is a predicate on lists of elements with a single fixed
> > interpretation. You are confusing it with negation as failure probably
> > because you *implemented* it in Prolog using negation as failure.
> 
> Michael, am I reading your tone right -- that the previous discussions
> left you frustrated about this subject?   Or did I say something above
> which annoyed you?

No, I am not frustrated and sorry if the tone is wrong. I didn't intend to
be abrasive.
I just asked a short pointed question and corrected you on a small point
which I thought was misleading.

So far I didn't take part in the discussion of soundness because I am still
trying to understand better what you want to do.

> I don't really have any opinion about particular solutions here.  I've
> written a few rules doing defaults with log:notIncludes (and
> log:conclusion to get some inference, maybe), but I haven't ever
> implemented them (in Prolog or otherwise).

I thought you were referring to
http://lists.w3.org/Archives/Public/public-rule-workshop-discuss/2005Aug/0103.html
where you proposed an implementation of log:notIncludes.

> 
> We have use cases involving ad-hoc mixing of rulesets.  People also like
> using defaults.  As long as people have some processing model in mind
> for when mixing will happen with respect to when defaults are processed,
> this may be fine.   If they don't, it's probably not.

It is possible to model what may look like simple defaults with a builtin like
log:notIncludes, but this is not negation as failure. I also suspect that
this trick doesn't go very far.


	--michael  

> 
> I'm not sure we want to get into specific examples yet, or wait a few
> weeks/months.
> 
>       -- Sandro
> 
>

Received on Thursday, 11 May 2006 05:39:33 UTC