Hi all, this is a comment from Patrick ALBERT, new to the group, but not so new to Business Rules. I am actually a Fellow at ILOG, of which I was a founder, and former CTO/VP R&D. for about 15 years, having started all this by implementing an early object + Rules systems (KOOL, for Knowledge and Object Oriented Language) about 25 years ago... About the rules semantic, I'd support Gary's statement below related to how updates should impact rules activation: if we want clean semantic, asserting a new object of a given class should activate all rules relative to the class and superclasses of the new object: rules that test the existence of such an object, and rules that test one or more slots. Updating a slot of an object should only activate the rules relative to this slot. And, ideally, we might support a more declarative semantic making a difference between equality and affectation. Affectation has the usual memory oriented semantic: a (possibly new) value is placed in the slot of an object. It then triggers the relevant rules. Equality assert that the slot of a object has a given value. Three cases arise: - the slot had no value: the new value is asserted and the rules that test the slot are activated - the slot already had this value: nothing happens. - the slot had another value, and a contradiction is raised. Such a definition allows for using rules for describing event triggered actions -- basic production rules -- and declarative business logic. > 3.1.1.5. > > In my PR system, assign to a frame slot (aka a java bean property) is > not the same as removing and asserting (or just re-asserting) the frame. > Assert will activate rules whose conditions reference *any* frame slot, > whereas assign will activate rules whose conditions reference the > assigned slot. Not sure I understand: can you give me a simple example?Received on Tuesday, 19 February 2008 09:29:23 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:07:42 UTC