Re: [rules-dev] Naive questions on rules

Hi Wei Tai, So here I try to answer your questions "from a very high level of view" :-D An expert system uses deduction, abduction and induction as inferencing mechanisms. The interaction between knowledge base and inference engine can be summarized as follows: * deduction: cause + rule ----> effect * abduction: effect + rule ----> cause * induction: cause + effect ----> rule Inference engines that implement deduction are called forward-chaining inference engines, those implement abduction are called backward-chaining inference engines. They are also understood as data-driven and goal-driven inference engines. Many modern inference engines are hybrid engines, as many problems require both deduction and abduction for their solutions. The induction, however, happens usually in knowledge acquisition components and heavily employs pattern recognition and machine learning techniques such as Bayesian Nets and Artificial Neural Nets. *You need to know what your application exactly wants to achieve and then apply different styles of inference.* Expert systems enable domain experts and software engineers to program declaratively. Both facts and rules can be declared without any particular order (only specifying what but not how). This has two major benefits: 1. Facts and rules can be organized in any order or structure that better reflects the semantic of the problem. 2. Ignoring the sequences of facts and rules may significantly reduce a developer's cognitive load, therefore increases her efficiency and reduce her errors during engineering. But no problem can be solved if the application contains only declarations. The "declarative programming" only largely applies in the knowledge base. Normally, an inference engine is strictly algorithmic, which means it must be programmed procedurally. It is also an over-generalization to think that all knowledge bases contains only declarations and all inference engines only procedures. In practice, the "then" part of a rule declaration often contains procedures, more or less. Also, there are inference engines progammed declaratively in languages such as Prolog. Nevertheless, eventually all declarative instructions are translated into procedural machine code. In fact, the declarative programming model has nothing to contribute to a program's run-time performance but it may dramatically increase the performance of domain experts, software engineers, and information managers. The "if-then"-like rules are a type of production whose orgins go back to the 1940s. Production systems were first used in symbolic logic by Emil L. Post who originated the name. Post proved that any system of mathematics or logic is equivalent to a certain type of production rule system. This result established the great possibility of representing most kinds of knowledge in a canonical, if-thenlike form. Post's production rule system was never really practical because it lacked the specification guiding how the rules should be applied. When facts meet rules, should a fact seek applicable rules or should a rule seek suitable facts? No matter which strategy we choose, then in what kind of order should facts and rules match each other? In 1960, Andrey A. Markov published his string rewrite algorithm, which is a control strategy of how rules should be applied in a production system. The Markov algorithm organizes the rules in order of priority, with higher-priority rules ordered first. Given a string that is to be rewritten, the whole list of rules is scanned from the beginning to the end whenever a to-be-substituted symbol occurs in the string. Although directly the Markov Algorithm is only about string rewrite, most problems are in fact encoded as strings for computation. Therefore, this algorithm made the beautiful Post theorem practical. In practice, new problems arose when people put more and more rules and facts into knowledge bases. Modern knowledge bases usually contain hundreds, thousands or tens of thousands of rules. If the whole list of rules is iterated whenever there is a fact to be examed (the Markov Algorithm's principle: fact seeks the rules), the system performs poor. In the late 1970s, some production systems spent more than 90% of the total run time performing rules-iteration. In 1979, Charles L. Forgy invented the Rete Algorithm to increase the pattern-matching efficiency of production systems. The Rete Algorithm solved the scalability problem of modern production systems, was then widely implemented in many expert systems. Many variants of Forgy's original algorithm, such as Rete II, Rete III, and ReteOO, were spawned. I hope this explanation is high-level enough. Please refer to Drools docs, papers and books if you want to know more about different algorithms. And BTW, you better post such kind of questions to the rules-user mailing list. This dev list is for the development-related topics of the Drools project, it is normally for stuff like "Hi the svn 24567 does not build, there is a problem in the pom.xml in the package org.drools.guvnor.etc, I've submitted a JIRA with a patch, please have a look.....". Best Regards, Ellen N. Zhao On Thu, Oct 23, 2008 at 12:41 PM, Wei Tai <taiw(a)cs.tcd.ie&gt; wrote: