- From: Paul Vincent <pvincent@tibco.com>
- Date: Fri, 20 Jun 2008 11:58:52 -0700
- To: "RIF WG" <public-rif-wg@w3.org>
-1 on acceptance-by-wider-PR-community-is-unimportant +1 on PRD representation compatibility with BLD -1 on PRD *presentation syntax* compatibility with BLD presentation syntax (different audiences, different needs) +1 this is a interchange representation not a rule language (hence presentation syntax differences between BLD and PRD is relatively unimportant - presentation syntax is for convenience of users only, so should be that which is more familiar to them (eg in Dutch if need be) ----- Hmmmm I see from the above scores that net net I am +0 / neutral over agreeing with Gary or Christian on this one. Paul Vincent TIBCO | Business Optimization | Business Rules & CEP > -----Original Message----- > From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] > On Behalf Of Gary Hallmark > Sent: 20 June 2008 19:16 > To: Christian de Sainte Marie > Cc: RIF WG > Subject: Re: [PRD] ACTION-531 Update PRD examples complete > > > Christian, > > I am unmoved by your repeated non-technical worries that "the PR crowd > won't like us". (And to have a schism based on what comes first, the > "if" or the "then", is truly straight from Gulliver's Travels) > I would like to hear some technical arguments. My argument is that by > definition of "rule interchange format", the default should be that PRD > and BLD are aligned. For every deviation, you must have a rational > technical argument. By the way, "the PR crowd won't like us", or any of > the countless variations, or even testimonials by real PR people that > they won't like use, DO NOT COUNT. > > Obviously, from a technical point of view (the only one that I really > care about here) the syntax and semantics should overlap to the greatest > extent possible. We are talking about an interchange format, not a > production rule language. It simply *must* look at least a little > "weird" to some of the participants in the interchange. I'll not defend > BLD/PRD PS as a great rule language. But I don't have to. It's not a > rule language! It's a (mostly) common language for interchange. > > I certainly don't mind including your informal PS as a "comment" to the > BLD-derived PS I added to the document. But there is already an > equivalent English description, clause for clause. But you cannot just > throw my work away without a technical reason why we should not clearly > show the large overlap between BLD and PRD because this is precisely > what we've been trying to do with RIF! > > Christian de Sainte Marie wrote: > > > > Gary, all, > > > > Sorry if it sounds like I am backtracking on something I agreed to, > > but, after having a look at the examples in the new presentation > > syntax, I realized that I cannot live with that. > > > > Long, detailled, substantiated explanations follow, but, to make a > > long story short, I propose that: > > - either we revert to a more production rules friendly PS; > > - or we restrict the use of the PS for what if was initailly designed, > > that is, make the semantics easier to specify and read, and that we > > use some informal pseudo-code for the presentation of the running > > example in the introduction. E.g.: > > > > IF ?c is a chicken such that the age of ?c in months is > 8 > > AND ?p is a potato such that ?p is owned by ?c; > > AND the weight in decigrams of ?p > (age of ?c)/2; > > AND today is not Tuesday > > AND there is no fox in the hen house > > THEN mash ?p > > AND increase the grain allowance of ?c by 10% > > AND remove the couple (?c, ?p) from the ownership relation. > > > > The current PS for the running example just looks too weird: a > > significant share of PRD's target will not be able to relate to it, > > even to the point of not being able to understand what it means > > without quite some effort and rewriting work, esp. among that part of > > the crowd that is most important wrt adoption, that is, the commercial > > developpers (application developpers and rule engines/management > > system vendors). > > > > Gary, honestly, what would be the reaction of the developers in your > > team if you showed them the example without some serious background > > explanation (and even with)? > > > > As I said and wrote again and again, I do not buy into the argument > > that PRD's PS must make the overlap with BLD more obvious. The main > > reason is because that argument is completely irrelevant: > > 1. The primary target for PRD will not be familiar with BLD, at least > > not when they will read PRD (because they are more likely to read PRD > > first), so, they will see no similarity anyway; > > 2. The people who will be interested in the overlap will either read > > the comparison in the appendix, and read BLD with that in mind, or, if > > they are familiar with BLD already, they are likely to look at the > > appendix first, when they look at PRD; > > 3. The people who want to write PRD-compatible BLD rules will write > > them in their prefered BLD syntax, rather than some weird > > BLD-like-but-not-quite PRD PS, anyway; > > 4. The nice thing about sharing a common XML serialisation for the > > intersection between BLD and PRD is precisely that one does not have > > to care which kind of language and syntax a rule has been initially > > written in (BLD-ish or PRD-ish): if you can parse it, you can use it, > > whether you parse it in BLD or PRD. The beauty of it and the appeal of > > it *is* the transparency. > > > > Again, I believe that the first example must tell the PR people that, > > yes, this is the kind of familiar looking rule that PRD is about; and, > > yes, this is what PRD serialize, including those parts of the > > condition that are attached to the declaration of variable and that > > Gary dislikes so much: they are so currently used that many people > > believe that the clauses in the condition of a PR are ordered, and, if > > people write their rules that way, PRD must preserve the investment > > they made in deciding the scopes for the variables (and our running > > example must tell them that it is the case). That is why I insist that > > we keep the "such that" parts in the example rule as well. > > > > To make sure that it was not just me, I did some research and gathered > > some evidence that the overwhelming usage in the PR crowd is IF > > condition THEN action. See below. > > > > Cheers, > > > > Christian > > ------------------ > > First, I did a quick poll amongst the developers in the JRules team at > > ILOG. I wrote: > > > > A :- B > > > > on a piece of paper, and I shown it to the first 10 people I met from > > the team, asking what it was. The result is striking: > > - 6 did not know (3 guessed that it might be a assignement in some > > weird programming language; after I told them that it was a rule, 4 > > still did not know what to make out of it, and 2 read it A implies B, > > one of which 1 said she had had some training in Prolog at the > > University) > > - the remaining 4, who recognised that it was a rule, said: A implies B. > > > > I also googled the Web for evidence. And I only found more evidence > > that everybody in the PR world wrote their rules, and thought of > > rules, with the condition part first and the conclusion/action part > next: > > > > - First example of a rule in the documentation of Drools (JBoss Rules) > > [1] > > > > rule "Primitive int manual unbox" > > when > > $c : Cheese( $price : price ) > > then > > $c.setPrice( $price.intValue() * 2 ) > > end > > > > [1] > > > http://downloads.jboss.com/drools/docs/4.0.7.19894.GA/html/ch01s02.html# d0 > e297 > > > > > > - Jess documentation [2] about rules: > > > > "Rules are defined in Jess using the defrule construct. A very simple > > rule looks like this: > > > > Jess> (defrule welcome-toddlers > > "Give a special greeting to young children" > > (person {age < 3}) > > => > > (printout t "Hello, little one!" crlf)) > > > > This rule has two parts, separated by the "=>" symbol (which you can > > read as "then".) The first part consists of the LHS pattern (person > > {age < 3}). The second part consists of the RHS action, the call to > > println. If you're new to Jess, it can be hard to tell the difference > > due to the LISP-like syntax, but the LHS of a rule consists of > > patterns which are used to match facts in the working memory, while > > the RHS contains function calls." > > > > [2] http://herzberg.ca.sandia.gov/docs/70/rules.html > > > > - First example of a rule in CLIPS documentation [11]: > > "The pseudocode for a rule about duck sounds might be > > > > IF the animal is a duck > > THEN the sound made is quack" > > > > (and the rule is: > > defrule duck "Here comes the quack" ; Rule header > > > > (animal-is duck) ; Pattern > > > > => ; THEN arrow > > > > (assert (sound-is quack))) ; Action > > > > [11] http://clipsrules.sourceforge.net/documentation/v630/ug.htm > > > > - First example in Oracle rule language I found [3] > > > > rule approvePO > > { > > if (fact PurchaseOrder po > > && po.amount > 1000 > > && po.approvalLevel == null) > > { > > po.approvalLevel = "VP"; > > assert(po); > > } > > } > > > > [3] > > > http://www.oracle.com/technology/products/ias/business_rules/pdf/oracleb us > inessrulestechnicalwhitepaper.pdf > > > > > > - Basic operation of a production system, according to Wikipedia [4] > > (notice the refence to LHS and RHS without an explanation, as if it > > was obvious): > > "Rule interpreters generally execute a forward chaining algorithm for > > selecting productions to execute to meet current goals, which can > > include updating the system's data or beliefs. The condition portion > > of each rule (left-hand side or LHS) is tested against the current > > state of the working memory. > > > > In idealized or data-oriented production systems, there is an > > assumption that any triggered conditions should be executed: the > > consequent actions (right-hand side or RHS) will update the agent's > > knowledge, removing or adding data to the working memory. The system > > stops processing either when the user interrupts the forward chaining > > loop; when a given number of cycles has been performed; when a "halt" > > RHS is executed, or when no rules have true LHSs." > > > > [4] http://en.wikipedia.org/wiki/Production_system > > > > - Pega does not provide an example in their front page about rule > > technology, but it mentions "if-then" rules [5]. Same for Fair Isaac > > [6] (I do not have access to either Pega nor Blaze documentation). > > > > [5] http://www.pega.com/Products/RulesTechnology.asp > > [6] > > http://www.fairisaac.com/fic/en/product-service/product-index/blaze- > advisor/what-are-business-rules.htm > > > > > > - IBM on business rules: "Business rules can be thought of as an > > if-then business decision". (Googling "IBM production rule" points > > towards CommonRule, which is not alive anymore at IBM, as far as I > > know (IBM folk?), so I tried again with "IBM business rule"). > > > > [7] > > > http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/topic/com.ibm.i ea > .wpi_v6/wpswid/6.0/BusinessRules/WPSWIDv6_BusinessRules_Overview.pdf?dmu id > =20061231125325214974 > > > > > > - The first example of a rule on the RuleML home page [8] is a > > production rule: > > "If you want to review rule principles, (then) you may look at > > Rule-Based Expert Systems. (BTW, this is itself a simple rule.)" > > > > [8] http://www.ruleml.org/ > > > > - And the first example in the presentation to wich 'Rule-Based Expert > > Systems' links [9] is another production rule: > > "IF the engine is getting gas AND the engine will turn over THEN the > > problem is spak-plugs" > > > > [9] http://www.cs.nott.ac.uk/~sxp/ES3/sld003.htm > > > > - The first example rules in REWERSE is not a production rule, but > > their visualisation tools still produces an if-then form [10]: > > "Rule Text: If X is the parent of Y and X is brother of Z then Z is > > the uncle of Y" > > > > [10] http://oxygen.informatik.tu-cottbus.de/visualization/v1/ > > > > - First definition and example of a rule in Haley's RuleBurst > > documentation [12]: > > > > "A rule is an if-then statement." > > > > ;if a then b > > ;or, in other words, a implies b > > ;or, in Eclipse, > > (defrule a_implies_b > > (a) > > => > > (assert (b)) > > ) > > > > Etc... > > > >
Received on Friday, 20 June 2008 19:09:14 UTC