At the OMG standards meeting today presenting to a “packed audience” on Business Rule Standards on Production Rules and Decisioning… basically introducing the OMG PRR (version 1) and OMG DMN (pre-RFP) specifications. However, as talking metamodels and roles and graphical models etc risked sending even the most ardent standards-supporter asleep, I thought to interject some educational value of a different kind into the presentation – to wit, 1-page “tutorials” on what does it mean to be a “Rete-type” and “inference” rule engine. Sadly we didn’t have time to do the accompanying certification test in this session.
So… here are the condensed versions of “all you need to know” about Rete-type rules and Inference rules (with apologies to Charles Forgy and all the other rule engine designers and implementers out there…).
Click on the images for the PDF versions of these, er, “courses”.
Disclosure: both these characteristics are covered by OMG PRR, and used in the TIBCO BusinessEvents inference engine…
I am splitting hairs, but it’s an important distinction to me. I’ve seen business rule people write a bunch of simple rules and claim they used inferencing. My bias opinion is the term “inference” has been misused and abuse to the point where it means nothing. Writing inference rules means the developer has to understand some of the data is missing or cannot be known. If the rules aren’t written properly, the application won’t produce the desired result. This is especially true of RETE engines, since it’s data driven. If the data is missing, the rules dependent on that data may not fire. It’s one of the reasons existential quantifier and negation are critical for writing inference rules. I think we do a disservice to developer by hand waving over critical details for the sake of marketing.
Add to that conflict resolution, writing inference rules is far from easy or trivial. I’m sure you’ve seen plenty examples of this in your long career with rules.
Hi Peter – I certainly won’t argue about the need for better inference rule / rule chaining modelling constructs – something that OMG PRR failed to achieve for example, although OMG DMN might if the other rule engine vendors support the idea. Hmmm… maybe you should propose this topic at RulesFest?
Cheers
The example of “inference” doesn’t really look like inference to me. When I think of inference, I think reasoning over partial data. Take the following example. I see a person running down the street and behind him are two cops running in the same direction. I “could” infer the cops are chasing the person, but that could be wrong. If the person has head phones on, is wearing running shoes, shorts and a tank top, it could be pure coincidence. The example demonstrates rule chaining, but it doesn’t necessarily demonstrates “inference”. To really demonstrate inference, more rules would be needed. I feel it’s important to point this out, so that people don’t think rule chaining == inference. Inference rules use rule chaining, but rule chaining does not equal inference.
Hi Peter – I think you are splitting hairs – we are not talking philosophy but rule engine behaviors….
In the example, from the fact that transaction priority is high we infer the new fact that we need to ship today. This is an example of how the inference mechanism in a rule engine links (chains) rules. I concur of course that the conditions for such inferences can be elaborated ad infinitum, but not in a 1-minute training course!
Cheers
I did get another comment here at OMG on a follow-up topic: how do rule engines deal with the details of inference regarding:
- depth first versus breadth first inferencing: do I follow the inference chain for each fact (tuple) before dealing with all tuples in a particular rule?
- conflict resolution: if more than 1 rule is valid, what is the semantics for choosing 1 rule over another to fire first?
- condition triggering: when will rules be triggered:
– when the condition expression changes value
– when the fact used in the condition changes value
– when the fact used in the condition is updated to possibly the same value…
etc
This is important for detailed semantics for rule interchange (in the new W3C RIF standard for example). W3C studied some of the rule engine behaviors during RIF standard development, but there is likely more work to be done here…
Cheers