If you read a paper, or a journal, or an article, or a note recommending NOT to use a Production Rule System, you will find that one of their strongest point is that Rule Systems are too… logical. In fact, a Rule Base must be built with complete and correct Knowledge of its domain, and it is expected to evaluate exact data, to yield new exact information. No need to say that domain knowledge can hardly ever be defined complete and correct – and even then, when can the input data be defined exact?
Actually, there are many applications for which these conditions ARE true, but what happens when they are not – e.g. medicine, finance, forecasts, …. A RBS is an all-or-nothing solution: either the knowledge and the inputs are precisely defined, or no information will ever be entailed. Yet there is another option: letting the engine become imperfect, so that it can deal with the imperfection in its inputs. Is it ironic for an engine to become more powerful by being less perfect? If it seems so, consider the simple example:
when
Room ( temperature > 25 , $f : fan )
then
$f.activate();
end
This rule, “turn the fan on, if the room is hot (and you have one)”, is perfectly acceptable, but could easily become inadequate under a few circumstances:
- Imagine the temperature fluctuates with imprecision around 25°, say from 24.9° to 25.1°: should you activate the fan or not? Such action could have a cost, and with the energy prices rising…
- Imagine you have a sensor measuring 30°, but it is placed in a sunny spot just under the window: the value it returns may not be the real one. Or the sensor could be broken and, from time to time, yield random, unreliable values. Is your confidence strong enough to justify the activation of the fan?
- Imagine you don’t have a temperature sensor: you know that the room is hot, for sure more than 20°, but not the exact value of the temperature. Should the fan be turned on even in presence of such a vague estimate?
- Imagine you are getting back home from work, and can activate the fan using a SMS. You know your room IS hot, unless someone opened the window earlier in the afternoon. There is some probability that you need to turn on the fan, but some that you need not
- In any case, is turning on the fan always the right decision? Maybe there are exceptions to be considered…
- and so on…
The target of the new sub-project, Drools:Chance, is to make our favorite rule engine capable of dealing with any – possibly even more than one – type of imperfect information natively. This means that the degrees of imperfection will not have to be processed explicitly in the rules, as the engine will take care of it behind the scenes. Moreover it will be possible to configure the behavior of the engine to reason with different types of imperfection without changing the rules: like different flavors, a user will be able to pick his favorite one.
I have been working on a prototype for some time, and have implemented several new features, which I will show in this blog. However, there is still much to do: from implementation, to optimization, to documentation, to testing, to providing advice. So any help, even a simple but constructive comment, will be appreciated.
Davide “sotty” Sottara
— No Laws, just Rules.
coming soon: Custom Degrees, Evaluators and much more…
