- 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
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. --michael
Received on Thursday, 11 May 2006 04:43:13 UTC