RE: [PRD] ACTION-531 Update PRD examples complete

-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