RE: [PRD] ACTION-619: Examples in JRules to support discussion on Assert and Modify --> same in TIBCO BE

Hi Paul,

 

Thanks for your prompt feedback. I would like to hear inputs from the
others on your question ("is the cost of using frame / BLD definitions
outweighing the compactness of object oriented notions? "). It seems
this is a policy which leads to the answers of many questions.

 

Not sure that I fully understand your explanations about Tibco. Do you
mean that Tibco has a sort of proprietary object system (like the
traditional expert system shells), so the notion of assert, retract and
modify are natively captured in the constructors/destructors/accessors?
BTW it's a mixed model, as I understood there are also Java objects, and
surely XML ones. By "classic AI-type frames", do you mean Minsky's
frames, that are objects with slots, slots with facets and procedural
attachments etc.?

 

Changhai

 

________________________________

From: Paul Vincent [mailto:pvincent@tibco.com] 
Sent: jeudi 9 octobre 2008 18:12
To: Changhai Ke; RIF WG
Subject: RE: [PRD] ACTION-619: Examples in JRules to support discussion
on Assert and Modify --> same in TIBCO BE

 

Excellent example :-)

 

TIBCO's BusinessEvents rule engine (used for CEP) is similar to the
classic own-object-model AI / KBS systems of the early 90s, which used
custom object models and classic AI-type frames. In (our) CEP the
"events" fed in are not existing Java objects (even if a Java object was
the original source). But still, an event is usually decomposed into a
created object (ie a fact is asserted representing the event)*. The fact
is in object form, so uses a constructor as if it was a Java object. The
creation of the object is *generally* the same as asserting it into the
rule engine WM (the boundary case is that, outside of a rule agent, I
can create objects and stuff them into the data grid for later
collection / assertion under program control, or use in some other kind
of agent, or load an existing object from cache - but that is irrelevant
for RIF purposes).

 

The same is true for the retract / destructor (ie we can remove the
object which also removes it from WM). For distributed agent systems,
outside of the scope of RIF PRD, we also have object control commands to
remove from WM (but leave in the cache for other agents to use).

 

Also true for "modify" (like other PR engines, we don't explicitly say
"modify" but simply define actions against objects)...

 

The qu for RIF PRD - is the cost of using frame / BLD definitions
outweighing the compactness of object oriented notions? I wonder if a
object-predicate PRD-BLD notation mapper isn't the way to go, and keep
PRD more useful and focused on the object world?

 

Notes: * the representation of rules in terms of objects is irrespective
of whether the underlying representation of the objects are tuples. 

 

Paul Vincent

TIBCO | Business Optimization | Business Rules & CEP

 

________________________________

From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
On Behalf Of Changhai Ke
Sent: 09 October 2008 16:36
To: RIF WG
Subject: [PRD] ACTION-619: Examples in JRules to support discussion on
Assert and Modify

 

Hello all,

 

Per my action-619: http://www.w3.org/2005/rules/wg/track/actions/619
booked during the RIF-PRD meeting of 07/10, below is an example of
"assert" and some explanations about "modify".

Regards,

 

Changhai


Syntax of "assert" in ILOG JRules


 

In production rule systems, "assert" allows to add an object to the rule
engine's working memory.

 

In ILOG JRules, the original "assert" has been renamed to "insert" to
avoid confusion with JDK's assert capability (since JDK 1.4).

 

This is an example:

 

rule BuyNewBooks

{

   when

   {

      // some conditions not expressed here, 

      // because not relevant for our discussion

   }

   then

   {

      insert Book("978-0-201-72789-0")

      {

         title = "The Power of Events";

         price = 40;

         year = 2007;

         author = "David Luckham";

         category = "computer science";

      }

   }

}

 

Explanations

*     "insert" is the rule language keyword, it is to assert a new
object.

*     "Book" is the name of the class. It is optionally followed by a
list of arguments within (). Here we want to use a constructor with one
argument: the ISBN number. The argument can be typed string, or more
strongly typed. The choice is up to the object model designer.

*     After the book object is created using the selected constructor,
the block of statements within {} is executed in the scope of the
current object. Here, we assign some values to its fields. "title" means
the field "title" of the current object.

*     After all the statements are executed, the object is reputed
well-initialized.

*     Finally, the object is added to the rule engine's working memory.
The real assertion is done here.

 

Comments

*     JRules provides the capability to select a constructor. If PRD
chooses to always use a constructor with no argument (this puts a little
constraint on the business object model), the previous statement can be
rewritten as:

 

insert Book

{

   ISBN = "978-0-201-72789-0"

   title = "The Power of Events";

   price = 40;

   year = 2007;

   author = "David Luckham";

   category = "computer science";

};

 

*     Here, the 0-arg constructor is used, and the ISBN field is
explicitly assigned.

*     Although the absence of arguments in the constructor is a
weakness, it can be acceptable in a first version.

*     JRules "insert" adds a whole object to the WM, after it is
initialized. 

*     In JRules, we don't have a notion of "asserting a field value", we
assert a whole object. But the fields can be multi-valued, and it is
possible to add a value to a multi-valued field. Can this be understood
as the capability of "asserting a field value"?

 

Non-intrusiveness of production rule systems

One important principle of rule systems is being non-intrusive to the
application object model. When an application is designed, the designer
had the freedom to design the object model accordingly to the pure
business requirements. He/she designs the classes, and will assign them
some constructors. Some of them will be with arguments, and some others
without arguments, this is dictated by the business needs. Only later
on, the rules are brought into the application. The rules must then
infer on an existing object model, without requiring altering it. As a
matter of fact, people who write rules are not necessarily the ones who
designed the object model. In this sense, the inability of RIF-PRD to
use any form of constructor violates the non-intrusiveness of production
rule systems. Although we are making the decision to support only
zero-arg constructors, this weakness needs to be understood and
acknowledged.


Necessity of a "modify" for RIF-PRD


A "modify" statement signifies that an object in the WM is being
modified, one or several fields are assigned new values. Below is an
example of syntax in ILOG JRules:

 

modify ?b

{
   year = 2008;

   price = 50;

}

 

Here, the variable ?b must be previously bound to an object. Its
notation and the manner it has been bound are out of the scope of this
discussion.

 

The statement block within {} assigns new values to some fields of the
object. After all the assignments are done, the modified object is used
by the rule engine (to infer new rule instances to fire).

 

Without a "modify" statement, the object modifications will be simulated
in RIF-PRD using "retract" and "assert", in the following way:

 

retract ?b;

?b.year = 2008;

?b.price = 50;

insert ?b;

 

This is much more verbose and ugly than a native "modify" statement.

 

A modify statement is required for a few reasons:

*     Most of the production rule systems, ILOG JRules, Fair Isaac,
Drools, Jess, OPS family, have a "modify" statement (sometimes called
"change", "update") etc.

*     This indicates that an object is being modified. The engine can be
prepared accordingly. This also improves human readability.

*     It is an essential feature to build Truth Maintenance System.
Retract/assert would break the truth maintenance.

*     The paper attached in this e-mail discusses the interests of an
in-place modify, although this can be considered as an implementation
detail (a relatively significant challenge in production systems). Note
this paper has been followed by several other papers.

*     A "modify" does not necessarily mean that all the rule systems
must implement this in a specific way. It is firstly a convenient syntax
to express object modifications. In the operational semantics, we can
figure out a way, such that this can be implemented as a retract/assert
pair, or as an in-place update.