W3C home > Mailing lists > Public > public-rif-wg@w3.org > May 2006

Re: soundness for RIF

From: Michael Kifer <kifer@cs.sunysb.edu>
Date: Thu, 11 May 2006 00:40:13 -0400
To: Sandro Hawke <sandro@w3.org>
Cc: Chris Welty <cawelty@frontiernet.net>, public-rif-wg@w3.org
Message-ID: <30316.1147322413@kiferserv.kiferhome.com>

Sandro Hawke <sandro@w3.org> wrote:
> > >             I want it to be able to safely include the ruleset
> > > containing both these rules and make inferences which will be sound,
> > > even though it has no idea what the second rule is supposed to mean.  It
> > > will certainly be incomplete because of not knowing what the second rule
> > > means, if it wasn't incomplete already.
> > >   
> > 
> > Regardless of what Francois thinks "sound" means, this argument of yours 
> > above seems to make assumptions about monotonicty and negation.  What if 
> > e.g. the rule you understand expresses a default and the rule you don't 
> > understand expresses an exception?  You may draw a conclusion that is 
> > incorrect, i.e. unsound wrt the semantics of the unknown dialect.
> I believe this is the same as the biggest issue at the workshop,
> although in a slightly different form.  The simpler form of this issue
> comes up when the rules are in the same dialect but in different
> rulesets.  Can you merge rulesets?  See
> http://www.w3.org/2004/12/rules-ws/report/#negation-as-failure
> That summary doesn't really do it justice.  At the workshop this
> conflict -- represented mostly by Benjamin Grosof and TimBL -- got to
> the point of being funny.  Everyone seemed to kind of settle on the idea
> that "scoping" was the answer, but there wasn't a clear consensus on a
> technical definition of scoping.
> It came up again in chartering, mostly under the keyword "monotonicity",
> eg in the thread around
> http://lists.w3.org/Archives/Public/public-rule-workshop-discuss/2005Aug/0087
> 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.

Received on Thursday, 11 May 2006 04:43:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:39 UTC