W3C home > Mailing lists > Public > public-rif-wg@w3.org > October 2008

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

From: Changhai Ke <cke@ilog.fr>
Date: Fri, 10 Oct 2008 11:52:33 +0200
Message-ID: <3E5E1A634BBD5C4A94C4D4A6DE0852E7019BDFE4@parmbx02.ilog.biz>
To: "Gary Hallmark" <gary.hallmark@oracle.com>
Cc: "RIF WG" <public-rif-wg@w3.org>

Hi Gary,

Thanks for your quick feedback.

I understand that on the first part, about "assert", we are essentially

On the second part ("modify"), at least we share a common understanding
about the "modify" capability provided by the various PR engines. I
think "modify" can be considered a convenient syntax, let's try to not
enforce too much on the operational semantics. Let's discuss this
further in the next meetings.


-----Original Message-----
From: Gary Hallmark [mailto:gary.hallmark@oracle.com] 
Sent: jeudi 9 octobre 2008 23:58
To: Changhai Ke
Subject: Re: [PRD] ACTION-619: Examples in JRules to support discussion
on Assert and Modify


> insert Book
> {
> ISBN = "978-0-201-72789-0"
> title = "The Power of Events";
> price = 40;
> year = 2007;
> author = "David Luckham";
> category = "computer science";
> };
Oracle has a textual rule language (called simply "RL") similar to 
yours. We say
assert(new Book(ISBN: "978-0-201-72789-0", title: "The Power of Events",

price: 40));
We can also call a constructor with arguments.
> *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.
Yes, we need constructors and methods (eventually).
>     */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;
> }
RL is similar: modify(b, year: 2008, price: 50)
> Without a "modify" statement, the object modifications will be 
> simulated in RIF-PRD using "retract" and "assert", in the following
> retract ?b;
> ?b.year = 2008;
> ?b.price = 50;
> insert ?b;
No. They will be implemented as either:

a. Core compatible mode
?b[year->2008 price->50]

b. PRD mode
retract(?b[year->?oldyear price->?oldprice])
?b[year->2008 price->50]

In Core there is no retract, so you just add new slots/values. Whether 
this "works" depends on the use case.
I might be in favor of allowing wildcards in place of ?oldyear and 
?oldprice, so our translators don't have to add these variables and bind

them in the condition.
> This is much more verbose and ugly than a native "modify" statement.
Be careful. Beauty is subjective, and we aren't designing an end-user 
language. This is an interchange format that we would like to work 
across many kinds of rule engines, not just production rules. That said,

I could see that
modify(?b[year->2008 price->50])
could be short for
retract(?b[year->* price->*])
?b[year->2008 price->50]

However, it has the same semantics.
> 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.
yes but they probably have subtle differences in both syntax and 
semantics. We must define a standard syntax and semantics, and we must 
consider non-PR systems as well.
> * This indicates that an object is being modified. The engine can be 
> prepared accordingly. This also improves human readability.
The only real issue is: can you build a translator? Neither your engine 
nor your users will see RIF-PRD syntax.
> * It is an essential feature to build Truth Maintenance System. 
> Retract/assert would break the truth maintenance.
I don't think this is true if you consider the frame-level 
retract/assert. You seem to have been assuming object-level retract -- 
which is not correct.
Received on Friday, 10 October 2008 09:53:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:53 UTC