- From: Vincent, Paul D <PaulVincent@fairisaac.com>
- Date: Wed, 19 Apr 2006 15:35:57 -0700
- To: "Dave Reynolds" <der@hplb.hpl.hp.com>, "Michael Kifer" <kifer@cs.sunysb.edu>
- Cc: "RIF WG" <public-rif-wg@w3.org>
- Message-ID: <B3636F07C8359844A9A2370C5EA08CCBDEA4E3@SRFMSGMB00.corp.fairisaac.com>
> If you > intended that one set of production rules for Vendor X's engine will pass > through RIF and emerge on the other end as a bunch of rules for Vendor Y's > engine and the results will stay the same then keep dreaming. The rule vendors can address this better than I ... however, I've been assuming that there is some interesting subset of customer applications for which use of Vendor X's feature set can be sufficiently constrained that translation to vendor Y's rule language is indeed possible, at least so that the results from the translated ruleset will be equivalent as far as application-observable effects are concerned. If that's not the case then what's the point of RIF for the production rule vendors? The [OMG] PRR team are addressing this by looking at 2 common types of production rule semantics (Rete rule engine and procedural / sequential execution of rules). There are enough similarities between the commonly used engines (Fair Isaac Blaze, ILOG JRules, JESS/Oracle, etc) that a broad area of commonality is possible. However, EVERY vendor of course has their own "quirks" which means PRR is a SUBSET of possible rule languages (albeit, we feel, a common subset). Which means PRR is a bit like SQL I guess - a common core with vendor extensions, and caveat emptor for developers (ie use the common subset for portability, or vendor extensions for, er, "non-portability"). I'd assume the same (common subset implementation) would be true for logic representations / KR / OWL rules, for RIF v1-n at least? PS: Note that for many business rule applications, "different results" is not necessarily as fatal as a logician might expect. For example, say a set of production rules represents multiple rules for the same eventuality, effectively defining an "or" in the consequent. This is taken to mean that either of the results would be good. So a rule engine X might give result A for state S applied to rules (ruleset) R, whereas rule engine Y might give result B for state S applied to R. The fact that the ruleset R is non-exclusive for state S is, in this case, simply a fact of life. If the rules in R were exclusive, then I'd expect A=B... Paul Vincent Fair Isaac Blaze Advisor --- Business Rule Management OMG Standards for Business Rules, PRR & BPMI mobile: +44 (0)781 493 7229 ... office: +44 (0)20 7871 7229 -----Original Message----- From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] On Behalf Of Dave Reynolds Sent: Tuesday, April 18, 2006 6:25 PM To: Michael Kifer Cc: RIF WG Subject: Re: [UCR] Design constraints: early example goal/csf hierarchy Michael Kifer wrote: > On 04 Apr 2006 Dave Reynolds <der@hplb.hpl.hp.com> wrote: > >>This is an incomplete attempt to sketch out an example goal/csf/requirement >>hierarchy to help me at least see the wood for the trees. >> >>This is not "right", just preliminary musings, so it can't go into the >>Design Constraints page (violates the stated ground rules for that). Posted >>in its current highly preliminary state in case it is a useful seed. > > > Dave, > This is a good high-level start. It needs to be refined and weeded out > (i.e., there are problems :-) > See below. Sorry to be slow to respond - just back from holiday. >>** Goals >>G1 Enable effective interchange of rules between existing rule systems >>G2 Widespread adoption >>G3 Foundation for a semantic web rule language >> >>** Breakdown >> >>G1 Enable effective interchange of rules between existing rule systems >> C1.1 Able to express the main features of relevant commercial rule systems >> R1.1.1 Support for production rule languages >> ... > > > The devil is in the details. What is "effective" supposed to mean? Whatever we want it to :-) Goals aren't themselves measurable, they are broad statements of intent which get more measurable as you turn them into requirements. I'd agree that my examples were light on details and precision but I felt brevity was more important, to help see the overall shape. The detailed versions can get thrashed out on the Wiki but I was trying to address my own concerns that the linear Wiki encouraged focus on the details while missing the gestalt. > If you > intended that one set of production rules for Vendor X's engine will pass > through RIF and emerge on the other end as a bunch of rules for Vendor Y's > engine and the results will stay the same then keep dreaming. The rule vendors can address this better than I ... however, I've been assuming that there is some interesting subset of customer applications for which use of Vendor X's feature set can be sufficiently constrained that translation to vendor Y's rule language is indeed possible, at least so that the results from the translated ruleset will be equivalent as far as application-observable effects are concerned. If that's not the case then what's the point of RIF for the production rule vendors? >> C1.2 Interchanges can be meaning preserving >> R1.2.1 RIF semantics is clear and precise >> R1.2.2 RIF semantics is compatible with the rule languages to be >> exchanged > > > I hope that by RIF you mean a family of languages and you take the word > semantics as plural (i.e., that there will be different semantics for > different sublanguages of RIF). Agreed. >> C1.3 Cohesive, sufficiently few RIF dialects that there is useful >> interchange > > > I may be reading too much into your "sufficiently few" here, because later > you talk about extensibility. But just in case, let me say this. > > One important requirement is that RIF should be *useful* and should not > become irrelevant as technology marches on. This implies that RIF should be > extensible, and this flies in the face of the "sufficiently few" requirement. > > I agree that we should start with few well-known paradigms, but the > mechanism should be designed thoughtfully to enable extensibility. > One way to do that is to propose a taxonomy of languages characterised by > their salient semantic and syntactic features, as we proposed at the F2F. I fully agree that RIF is extensible and there shouldn't be arbitrary limits on that extensibility. This CSF is simply an encouragement to moderate the number of RIF dialects we start off with. If we start off with N RIF dialects where N ~= length of our list of rule languages then we don't achieve much useful interchange. Clearly N ~= 1 is not tenable either. This CSF is an encouragement to us to look for a modest number of useful starting dialects. >> R2.2.2 Sufficiently inexpressive that RIFdialect -> RLj is easy > > > Can't make sense out of it. If RIF is as expressive as every RLi then what > does it mean to be "sufficiently inexpressive"? The expressivity referred to the RIFDialect (and thus also to RIF Core) rather than RIF overall. If RIF Core is too expressive (or example the first draft charter called for the core to be FOL with equality) then the task of an implementer trying to translate any RIFDialect into their specific rule language is untenable. I'm trying to say it should be possible to have RIFDialects that are sufficiently constrained that the job of the implementer of the consuming-translator is reasonable, that it is possible for a vendor to reasonably say we support RIFDialects "foo" and "bar". As stated this is not yet a sufficiently well defined requirement, it's certainly not measurable. However, if the principle was acceptable to the working group I should think it could be turned into an adequately requirement. I was, naively, seeking some agreement on the broad principles and shapes of the requirements that could then be refined into more precise statements. >> C3.3 Compatible with OWL >> R3.3.1 RIF Standard inference and OWL inference can be combined in a >> well-defined fashion > > > RIF "standard" inference? There can be no such thing given the diversity of > the group. There are at least 3 streams in the RIFWG: pure FOL, logic > programming, and production rules. Another member has joined recently, > which brings in one more: reactive rules. Agreed, bad phrasing on my part. > In my F2F2 presentation mentioned above and in the RuleML 2005 paper > http://www.debruijn.net/publications/msa-ruleml05.pdf > a realistic hybrid architecture was proposed, which allows to combine the > different paradigms in a loosely coupled fashion. "combined in a well-defined fashion" was supposed to include such options, so you could propose a hybrid architecture as a way of meeting this requirement. > It is more realistic to push for *interoperability* among RIF dialects and > OWL/RDF rather than for "compatibility." In some important cases, compatibility > is achievable (as shown by Rosati), but we should allow more flexibility > (what we called "ad-hoc interoperability" in the DERI/RuleML presentation > at F2F2). > > It is thus more realistic to build RIF around the roadmap that Harold presented > at F2F2 > http://www.w3.org/2005/rules/wg/wiki/F2F2?action=AttachFile&do=get&targe t=RoadmapSessionSlides > http://lists.w3.org/Archives/Public/public-rif-wg/2006Feb/0255.html Well, having missed F2F2 (and there being no phone or IRC access of any utility) I don't fully understand that roadmap but I took it to be roadmap for the for the actual design work. So again it sounds like an answer to the requirement rather than a different set of requirements. Dave This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.
Received on Wednesday, 19 April 2006 22:36:57 UTC