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#d0e297 
>
>
> - 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/oraclebusinessrulestechnicalwhitepaper.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.iea.wpi_v6/wpswid/6.0/BusinessRules/WPSWIDv6_BusinessRules_Overview.pdf?dmuid=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 18:18:22 UTC