Conflict Resolution in Rules - Part 1

Greetings:

One more time - and this will be the first part of several editions on the subject. Later blogs will consider the details of the various Conflict Resolutions (CR) systems, when to use which one, and why each one is important. So, since CR has been such a critical part of a rulebased systems in the past, why is it that most rulebased systems being written and used today use either priority (salience) or the order of the rules as they were entered into the system to resolve conflict resolution? The answer is simple: It's easier to code the engine that way. Only a few (4 at last count) of today's rulebase engines still allow you to have a system that can allow you to depend on a true conflict resolution. Dr. Forgy discussed this with John McDermott way back in the 1980's in an article ("Production System Conflict Resolution Strategies; Pattern-Directed Inference Systems") that emphasized the importance of CR. Later, they wrote that MEA (Means-Ends-Analysis) was a slightly better system of CR than was LEX (Lexicographical) and WHY we can not use conflict resolution as a center of intelligence. It's a way to think about rules and how they should be enforced, not the rules themselves.

So why have most vendors moved away from MEA? Ease of programming AND because most Java programmers who are pretending to be rulebased consultants or engine programmers have no understanding of CR nor its importance to rules in general. So, why IS CR so blooming important? Aren't the rules just put into a big bucket enough to do the job? Two-part answer: (1) For a small job with less than a few thousand rules, you probably won't see any difference; usually because the "architect" has been able to arrange the rules and objects such that the CR has little or not effect on the performance nor the answer. (2) However, for a large project (10K rules or more along with several thousand objects) the process of "thinking" about the rules becomes paramount.

Think of it this way: If your rulebase is concerned with only one project, one problem (an insurance policy approval comes to mind) then all of the rules are, for all practical purposes, focused on solving a single problem. However, what if you have to think about a lot of things at one time, much like the human mind has to deal with many problems at one time and all of them in different time slots and conflicting time slots and many shades of priorities? Conflict Resolution is best discussed in some of the text books listed at http://www.kbsc.com/aiBooks.html because the academics (and this is NOT a derogatory term) don't have to support the idea of CR when actually writing a rulebased engine.

Here is a proposition: If you are using priority of the rules ONLY as the method of CR, then you may as well write the system in straight-up Java. It would, after all, be far easier to understand, to write and to put into operation. If you are using the order of entry as the means of resolving the CR, then why NOT just use a straight-up CASE statement or a huge IF-THEN system of Java clauses. After all, isn't that the kind of technique that is being taught in most rulebased classes?

Ah, because both the CASE statement nor the IF-THEN clause are monotonic - meaning that you can go through the rules one time and then quit. But, really now; implementing nonmonotonicity in either clause is just a matter of bookkeeping a huge WHILE clause (or maybe several while clauses) of some kind. So then, again, why use CR to resolve which rule to fire next?

The answer is that we are trying to insert some kind of intelligence into the system. CR of rules in the human brain is one of its distinguishing features in comparison to computers. Most of the CR in the human brain is done through the neural network of the brain and is not a cut-and-dried process as you might think at first. When we lose the ability to directly affect the thought process of the brain, we become stumbling idiots incapable of the simplest tasks. When we refuse to us CR for rules, we move from an intelligent rulebase to an idiot rulebase. It has been shown that as we remove the CR from the rules we do two things: (1) We make them far more fragile and (2) we make rule maintenance a nightmare.

Please, Rulebase Designers: Stop and think. Push back to the project manager who says that CR is not important because your competitor has dropped it and nobody noticed it. (Which might be true.) But, unfortunately, if the developers at that company did notice, there probably is very little that they could do other than complain and since the developers are not the ones who pay the bills, they wouldn't be noticed back at the vendor level. But what leaving CR out of the rulebase mix has done is to move us further and further away from what was, at one time, one of the defining factors of intelligent rules and a step up from the straight up IF-THEN rules of COBOL, C, C++ and/or Java.

Yes, I know that someone who actually lived back then will say that the only reason that they did this was to increase performance. Well, partially, that's true. BUT, that is not the main reason.

Next time: What is MEA and LEX and how do they differ both from each other and from common paradigms of CR. Thanks for listening...

SDG

jco