Project Topics
Get Complete Project Material File(s) Now! »
The Knowledge Base
A rule-based system holds a collection of general principles and concepts that can potentially be applied to solve problems or answer the user requests. This static information is stored in a knowledge base which consists in a specic database representing a wide variety of knowledge and containing various kinds of data. For example, in the context of an application for banks and insurances, a user can ask the system if a particular loan request has been accepted. Then, Depending on the automated decision results, he may ask the system to explain its reasoning. In order to answer to the user request, both the inference mechanism and the explanation tool need general information that are contained in the knowledge base. Consequently, the design and the organization of a knowledge base is a very important point that requires special caution. Increasing the expressibility and the intelligibility of this knowledge base makes more ecient the knowledge exchanges between the experts and the rule-based system and facilitates the management (modication and extension) of the knowledge base.
In this perspective, a knowledge base is often decomposed into three kinds of knowledge depending on their role.
The domain knowledge that encompasses facts and rules considered by the system for problem solving.
The technical knowledge that describes control procedures, meta-rules and other knowledge required for the working of the inference mechanism.
The explanatory knowledge that contains at least the traces of the automated decision taken by the rule-based system. Moreover, it may also include additional knowledge about the domain as justications that could be needed to produce explanations.
In resume, a Knowledge Base, sometimes referred as Domain Knowledge, contains all the essential knowledge about the concepts and the heuristics used by the engine to make inferences. It encompasses:
the concepts manipulated in the domain: that can be represented as object classes.
and the laws used in the domain to manipulate these objects: that take the form of business-rules.
However, characterizing more precisely the exact nature of the knowledge encoded in the knowledge base will be very important for us for, as noticed in (Chandrasekaran and Mittal, 1983), one very important aspect in the perspective of explanation is the depth at which a rule-based system represents its knowledge and uses it to solve problems.
The Working Memory
A rule-based system also holds a collection of specic details that apply to the current problem. This dynamic information encompasses temporary data corresponding to the current decision and includes details about the inputs, the progression of the reasoning process, the triggered rules and the outputs. A Working Memory that contains the facts base where each fact is a concept of the domain that has been instantiated with a dened value and represents a specic object. Its role is to hold these dynamic information in order to support the working of inference mechanism during the whole reasoning process.
The Inference Mechanism
An inference mechanism processes domain and technical knowledge to make deductive inferences about the temporary data contained in the working memory. In rule-based systems, such a mechanism is typically referred as the inference engine or rule engine.
Inference engines have been used to deal with logical rules in the rst expert systems and work in a simple way. Logical rules are applied to the facts in the working memory and new facts are deduced. This process would iterate as each new fact in the working memory could trigger additional rules in the knowledge base.
(1) Detection (lter relevant rules): creation of the conict set. Given the state of the working memory, an interpreter selects the executable [N: eligible?] rules in the knowledge base (ie. the business rules whose the conditions in the premisses are satised) and stores them into an agenda. This set of executable [N: eligible] business rules is called the conict set.
(2) Selection (select the rule with the highest priority): conict resolution and selection of a rule to be executed (control strategy). The technical knowledge is used to establish priority among the business rules.
(3) Execution (execute an instance of this rule): execution of the rule and modi- cation of the working memory.
The IBM business rules management system
Business Rule Management Systems, often abbreviated as BRMS, have emerged from the convergence of production systems mainly used as reasoning tools for problem-solving and business rules essentially seen by their users as a knowledge representation tool.
In fact, a BRMS consists in a software that provides a way to manage variety and complexity of the decision logic used by operational systems within organizations. The decision logic takes the form of a declarative language, expressed through business rules as described in the previous section, that enables the description of business policies, business requirements and conditional statements that are used to determine the business actions that occur during an operational decision. By using business rules, an operational decision associated to them can be dened, deployed, executed, monitored and maintained separately from its core application code.
In this perspective, BRMS provide robust platforms dedicated to the management of business rule-based systems and allow the companies to increase the readability of their knowledge base, reduce operational and maintenance costs and react more quickly to the market changes.
The eld of business rule management systems is characterized by a number of normative, open source or proprietary technologies and languages that makes them far ecient than classical approaches. The key players include IBM (IBM Operational Decision Manager), Bosch Software Innovations (Visual Rules), Progress Software (Corticon), Oracle (Oracle Business Rules), Red Hat (JBoss Drools), SAP (SAP NetWeaver DSM) and FICO (FICO Blaze Advisor).
In the context of this thesis about automated decision-making and explanation, we are interested by the business rule management system provided by IBM, called IBM Operational Decision Manager. This product is the evolution of the well known ILOG JRules. As IBM Operational Decision Manager separates decision management from application code, the business experts can dene and manage the business logic without the support of IT experts. By adopting this way of managing decisions, there is a huge reduction in the amount of time and eort that is required to update the business logic in production systems. Thus, by using this approach, organizations increase their ability to respond to changes in their business environment.
Hierarchy of decision service in IBM ODM
The business rule applications designed by using IBM ODM rely on two key aspects:
the establishment of a hierarchy among the elements of a business rule project. The hierarchy of a decision service (i.e. rule project) allows the decision service behavior to be governed and deployed consistently.
the denition of the vocabulary that is used for authoring business rules. This vocabulary is used to refer to the business objects and functions that are manipulated during the decision process.
Denition 2.5 (Ruleset). A ruleset is a set of coherent business rules, in the sense that each set represents a specic aspect of the decision logic and takes the form of an executable decision unit. A ruleset uses input and output parameters to pass data to and from the client application. Each ruleset must have a unique signature that describes the sets of input and output parameters that are used by this specic ruleset to communicate with the rest of the client application. In a decision service, the decision operations dene the content and signature of each ruleset.
Each of these rulesets having its own dedicated resources and form a decision unit that has a all the necessary materials to be parsable and executable by the rule engine. These decision units can then be referred in tasks which are responsible for splitting the reasoning process. More concretely, each task embeds an independent chunk of the decision-making.
Based on that, a decision process encompasses one or more tasks whose the executions result in the dierent reasoning steps of the corresponding decision. The orchestration of these reasoning steps is managed by the ruleows.
Table of contents :
1 Introduction
1.1 Context
1.1.1 A brief history of decision-making systems
1.1.2 Business rule management systems
1.1.3 Explanation in rule-based systems
1.2 Motivations and objectives
1.3 Thesis outlines
2 Rule-Based systems, BRMS and decision automation
2.1 General information about rule-based systems
2.2 Rules in decision automation
2.2.1 Business rules: basic denitions
2.2.2 Basic architecture for rule-based systems
2.3 The IBM business rules management system
2.3.1 Hierarchy of decision service in IBM ODM
2.3.2 IBM Operational Decision Manager: platform and architecture
2.3.3 The rule engine of IBM ODM
2.3.4 Applications
2.4 Discussion and conclusions
3 An overview of explanation in rule-based Systems
3.1 The need for explanation
3.2 Philosophical background on the theory of explanation
3.3 Explanations in rule-based systems
3.3.1 Categorization by temporal context / explanation orientation
3.3.2 Type of questions
3.3.3 Content types of explanations
3.3.4 Context sensitivity
3.4 A quick historical overview of expert systems with explanation capabilities
3.5 Causality in rule-based systems
3.5.1 Causal explanations in rule-based systems
3.5.2 Choosing a causal model / formal model for causal ascription
3.6 Requirements for an IBM ODM explanation feature
4 A simplied causal model for rule-based systems
4.1 Introduction
4.2 Concepts and denitions
4.2.1 Business rules
4.2.2 Towards a normalized business rule formalism
4.2.3 Orchestration and execution of the business rules
4.2.4 Tracing the process: what should be in the decision trace?
4.3 Representing causality in business rule-based systems
4.3.1 Events typology in a business rule decision
4.3.2 Dening the signature of a rule-based system
4.3.3 Causality between events
4.3.4 Typology of the relations
4.3.5 Hierarchical causal model
4.4 Process of construction of a minimal causal model
4.4.1 Causal model of the system and list of relevant events
4.4.2 Minimal decision trace
4.4.3 Minimal causal model of the decision
4.4.4 Conclusion
5 Engineering the causal model
5.1 A Framework for Causal Ascription and Representation in Rule-Based System
5.1.1 Encoding business rules (BR) into BR-Objects
5.1.2 Extracting the business rules of a decision project
5.1.3 Ascribing causal relations between the business rule elements .
5.1.4 Recording the minimal trace of a decision
5.1.5 Constructing the minimal causal model of a decision
5.2 Experiments and assessment protocol
5.2.1 Reduction for the business rule-based system’s causal model .
5.2.2 Reduction for minimal traces of the decision
5.3 Conclusion
6 Towards an architecture of an explanation service for business rulebased systems: basics and insights
6.1 Introduction
6.2 The basics towards a service architecture to support explanatory models150
6.3 The components of an explanatory model
6.3.1 Conceptual model as a part of the explanatory model
6.3.2 User model as a part of the explanatory model
6.4 Exploitation of the explanatory model: discussion and insights
6.4.1 How we deal with each criterion
6.4.2 A graphical representation for engineering the explanation .
7 Conclusion
Bibliography
