- From: Francis McCabe <frankmccabe@mac.com>
- Date: Sat, 16 Dec 2006 16:19:43 -0800
- To: W3C RIF WG <public-rif-wg@w3.org>
Perhaps this leads to one of the reasons that I have been uncomfortable about the lingua franca approach as a whole. Because, I can use the same argument to eliminate what is interesting about production rule systems: Logic does not have actions. Therefore RIF core should not support actions. Since, I assume, some flavor of logic will be in the RIF core. The intersection of all rule based languages is almost certainly empty. Frank On Dec 15, 2006, at 4:16 PM, Gary Hallmark wrote: > > I don't understand your argument. I may want to exchange a single > "hello world" fact, but it doesn't mean I want to restrict RIF Core > to doing just that. > > Here is my argument. Can you point out the fallacy, or if not, > accept the conclusion? > > RIF Core is a common subset of all RIF Dialects. > > There will be a RIF dialect for production rules. > > A RIF dialect should capture common and useful language features of > important real world rule languages because those are the ones we > care about interchanging. > > Support for recursive rules is not common among real production > rule languages. > > Therefore, RIF Core should not include recursive rules. > > Michael Kifer wrote: > >>>> This would be a ridiculous and unjustified restriction. >>>> >>>> The core is for exchange. There is no requirement for any concrete >>>> system to properly include the core. (Don't confuse concrete >>>> systems with >>>> RIF dialects.) >>>> >>> I'm not sure where the disagreement or misunderstanding here is. >>> >>> My understanding fits with what Gary said, that RIF Core is a >>> dialect >>> and it's a part of every RIF dialect, so every rule engine using RIF >>> must implement RIF Core. >> >> I think that this requirement makes no sense and, furthermore, is >> meaningless. >> Suppose people want to exchange aggregate-free subsets of SQL 1992 >> through RIF. >> Does it mean that RIF core should be limited to relational algebra? >> Or does it mean that we will kick them out even though they can >> perfectly >> use RIF core to exchange their stuff (preserving semantics etc.) >> we will >> somehow stop them until they implement full RIF Core? >> >> (Note that different SQL vendors have various deviations from SQL >> 1992 >> (even though most of them claim to support it!), so such an >> exchange is not >> completely out of question.) >> >> --michael >> >>> We'll need some normative Conformance text at some point, >>> something a >>> bit like: >>> http://www.w3.org/TR/owl-test/#consistencyChecker >>> >>> We could say something like (as a rought first cut): >>> >>> A "RIF Core Rule Engine" is a rule engine which can perform >>> sound >>> and complete reasoning on any rule set which can encoded in >>> one or >>> more RIF Core documents. It must be able to answer all queries >>> against the deductive closure of the ruleset, where a query is >>> equivalent to a RIF Core anticedent, and to answer a query >>> means to >>> provide every matching set of bindings to the variables in the >>> anticedent. >>> At the moment, unless some new information comes along, I'm >>> inclined to >>> agree that we need to leave recursive Horn rules out of the core. >>> >>> My understanding is that recursive Horn rules are also a problem for >>> prolog. As with rete systems, there are lots of clever and >>> effective >>> ways of dealing with this problem (I was once an enthusiastic XSB >>> user), >>> but my sense is that they are still kind of cutting edge instead >>> of the >>> kind of dirt simple we want in RIF Core. With non-recursive >>> rules, one >>> can do the trivial mapping to prolog or rete rules and any halfway >>> decent engine will be a sound and complete reasoner for RIF Core >>> rules. >>> I think that's what we want. >>> >>> We could go another step back for RIF Core, all the way to >>> datalog, but >>> I think non-recursive terms are still quite useful (eg for defining >>> uncle), so I'd rather not do that. >>> >>> -- Sandro >>> >>> >> >> >> >
Received on Sunday, 17 December 2006 00:20:07 UTC