- From: Sandro Hawke <sandro@w3.org>
- Date: Thu, 11 May 2006 01:06:08 -0400
- To: Michael Kifer <kifer@cs.sunysb.edu>
- Cc: Chris Welty <cawelty@frontiernet.net>, public-rif-wg@w3.org
> > 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?
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).
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.
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:06:20 UTC