When there is no experience in the domain the expert is to define the rules, therefore reasoning in this situation is called Rule-Based Reasoning. As it is started from the generalized rules, which are later applied to particular cases, it is also called deduction.
If the knowledge engineering was successful, the knowledge-based system would propose the same evaluation of cases that the expert would. So what is added? The knowledge base is a transparent description of the knowledge of the expert (or group of experts), which is appropriate to argument the decision proposal easily.
Apart from the transparency the expert may discover new knowledge, realising that some attributes were irrelevant, or reshaping his knowledge by understanding the complex rules. This means, that some tacit relations between the explicit expectations of the expert became explicit.
Knowledge Acquisition always starts with formulation of the aspects of the decision. Aspects are given by the expert as attributes (i.e. the names of the attributes) and their values. A value of an attribute is a decision criterion.
 | Tip: Use short expressions of the special language of your domain of expertise; for better understanding descriptions may be attached to each of the attributes and values. |
The acquisition of attributes and their values happens on the first pane of Doctus named “Attributes”. (See
Figure G-2: Acquiring Attributes and Values. (View Animation)
Different orders of the “goodness” of the values of the attributes are available: it is increasing, when the first value is the worst; decreasing, if the first is the best one; if one value is not better then the other one, the order is nominal.
| Tip: If you use the same value ordering for all attributes, it will make easier to define the rules. |
Once the attributes and their values are defined, if we are building a rule-based knowledge base, the next step is to determine the dependencies between the attributes. This consists of two parts: the “which(s)” and the “how(s)” of dependencies.
The “which(s)” attribute dependencies means to allocate for each attribute on which other attributes it depends on. This is done by constructing a hierarchy of attributes called Rule-Based (or deductive) Graph on the third pane of Doctus, named Rule-Based Graph. (See
Figure G-3: The Rule-Based Graph. (View Animation)
| Tip: Do not connect more then 3-4 attributes onto one node, to make yourself the rule input easy. |
If attribute B is connected onto attribute A (which means that A depends on B), then B is called factor of A. The same attribute may factor of different attributes, though not to itself (directly on indirectly). The root of the graph is not a factor of any other attribute; it is called decision attribute, or outcome. The leaves of the graphs have no factors, they are the input attributes. There will be attributes, which’s are factors of other attributes and having factors themselves; these are the dependent attributes.
When the Rule-Based Graph is constructed, rules are to be defined in each node of the graph.
| Tip: Once your Rule-Based Graph is constructed, don’t start with defining rules, first acquire cases. While acquiring cases the attributes and their values are likely to be modified. |
Knowledge-based systems are used to reason about cases. Cases can be anything that we can describe from all important aspects (i.e. defined attributes). One value of every attribute is assigned to each of the cases. Actually one value is the default but Doctus can also handle “Unknown”, “Don’t care” and distributed values.
The acquisition of cases happens on the second pane of Doctus, named “Cases”. In deduction or Rule-Based Reasoning it follows the construction of the Rule-Based Graph; however, new cases may be added to the knowledge base at any time. To assign a value of an attribute to a case, use the context menu from the right mouse-button. (See
| Tip: To simplify the acquisition of cases adjust the view to show the input attributes only. |
Figure G-4: Acquisition of Cases. (View Animation)
|
Knowledge Import is a feature to get cases directly from external data sources. Built-in types of input sources are (some of them available in advanced mode only): Excel Workbook, Microsoft Query, Mailbox and URL Encoded Cases, though any source may be accessed through ODBC. (See
Figure G-5: Knowledge Import. (Take a Short Tour)
Records from the data sources are retrieved as cases of the knowledge base. The attribute linking and the case import are facilitated by a wizard. Apart from text type values, also called flexible values, numeric input may also be used, handled by a clustering algorithm.
| Tip: Some special characters in the field names of the data sources may not be recognized and they mustn’t contain spaces, thus pay attention to avoid them. Often a space at the end of the field name remains unnoticed! |
The conception of data mining evolved from the observation that organizations store a huge amount of data (in the databases and data warehouses of their information systems) and use most of them for nothing. It is presumed that new knowledge could be discovered finding the rules hidden in relations between these data. The numeric data from the sources are to be transformed into symbols. Once Doctus is connected to external data source via its Knowledge Import module, the transformation is done using a built-in clustering algorithm. (See
Figure G-6: Clustering External Data. (View Animation)
In the Rule-Based Reasoning the data mining concept is applied starting from the point that some of the soft information in the head of the expert may be traced back to some soft relations between hard data stored in databases or data warehouses. Therefore some of the branches of the Rule-Based Graph may at the end (on leaves) have numeric input, namely symbols coming from clusters of a numeric range. As the databases and data warehouses are updated constantly, the knowledge base is always up-to-date in regard to data. Constructing a smart knowledge base an intelligent alerting function can be created, which will call attention only when the changes of data change the output as well.
Selecting an attribute on “Attributes”, “Cases” or “Rule-Based Graph” pane, the name of the fourth pane changes, incorporating the name of the selected attribute in “Rules of¼”. (See
If a rule connects one value of each factor, it is called elementary rule.
 | Maths: Use the markings: Attributes: A, B, C, ¼ (X is the decision attribute) |
Values: A={a1, a2, a3, ¼}; B={b1, b2, b3, ¼}; ¼ X={x1, x2, x3, ¼}
Rules: A=a1 Ù B=b2 Ù C=c1 Ù ¼ Þ X=x1
Read: If A is a1 and B is b2 and C is c1 and ¼ then X is x1
If a rule covers a range greater then one single value for at least one attribute, it is called complex rule. The covered range may contain neighbour values only; it may be closed (between two values) or opened (worst or better then one value).
| Maths: Use the markings from above. |
Rule: AÎ[a2, a5] Ù B=b2 Ù C=c1 Ù ¼ Þ X=x1
Read: If A is between a1 and a5 and B is b2 and C is c1 and ¼ then X is x1
Rule: A ³ a2 Ù B=b2 Ù C=c1 Ù ¼ Þ X=x1
Read: If A is better or equal to a2 and B is b2 and C is c1 and ¼ then X is x1
The complex rules can be seen as aggregations of elementary rules. The knowledge is easier to describe if it is done by fewer complex rules. Of course the same knowledge can be described by different sets of complex rules, i.e. the elementary rules can be variously aggregated.
Doctus provides two different surfaces to handle rules; the user can switch between them. On 1D surface rules are presented in form of rule list, new rules may be defined editing them directly into the table or using the insert new rule command. (See
Figure G-7: Rules in 1D. (View Animation)
Figure G-8: Rules in 2D. (View Animation)
 | Advanced: Input of rules in 1D may be also done by putting in a general rule (any of factors may have any of its values) first and then splitting or dividing the ranges of the factors. (View Animation) In 2D rules may also be defined by levels, which means to use logic “if¼ and¼ then the output is at least¼”. (View Animation) |
Doctus provides advices for the rule input using the previously defined order of values. (See
Figure G-9: Advices for Input of Rules.
Either using the advices or not nothing prevents from putting in an inconsistent rule. However, if the option is selected, Doctus can flag the inconsistent rules. (See
| Tip: Under certain circumstances the inconsistent rules may appear to be logically correct. If it happens to you consider changing the order of values. |
Figure G-10: Checking the Consistency of the Rule Set. (View Animation)
| Tip: Define the rules in 2D, using the advices and the consistency check, then switch to 1D to discover new knowledge from complex rules. |
Reasoning in a Rule-Based system is done by triggering the rules for the cases, getting a value of the decision attribute for each case; therefore it is also called evaluation of cases. The results may be seen on the “Cases” and on the “Rule-Based Graph” panes. (See
Figure G-11: Results of Rule-Based Reasoning. (View Animation)
 | Technical: In Doctus rules are stored in form of rule list, like in 1D view. While reasoning, Doctus searches top-down the rule list for the appropriate rule; stopping if the first one is found. It means that multiple coverage of a domain does not cause a trouble though if there is no appropriate rule result remains “Unknown”. |
| Technical: The real computing is some more altered by “Unknown”, “Don’t care” and distributed values. If there is an “Unknown” case feature or rule outcome the evaluation of the case will be “Unknown” as well. If there is a distributed value, the outcome of the rule set will be distributed in the same proportion, if there are more distributed input values, the outcome will follow the superposition of these distributions. A “Don’t care” is considered to be an equal distribution of all input values. |
To take a decision it would be nice to have one and only one case having the best value of the decision attribute. However, it happens extremely rarely at first try, usually there are none or several cases with the best output. To facilitate the fine-tuning of the knowledge base Doctus is equipped with an explanatory option. (See
Figure G-12: Explaining the Results.
The explanation helps us to locate the reason of the unsatisfactory evaluation, though the refinement is to be done manually. Apart from above mentioned another reason to fine-tune the knowledge base can be to simplify the description of knowledge described by the knowledge base – of course without loosing anything important.
Fine-tuning usually implies one or more of the followings:
After refinement the knowledge base should reflect the opinion of the expert about the decision. The fine-tuning is finished only when the expert agrees with all the elements of the knowledge base.
Doctus is capable of exporting knowledge bases in various forms of intelligent agents. (See
Figure G-13: Knowledge Export. (Take a Short Tour)
The exported knowledge may be:
| Advanced: Build your specialized export templates based on the above listed predefined ones. |
Using the Knowledge Export feature the exported knowledge base can be made available to various users, who will be able to use it for evaluation, though they will not be able to modify it. Some types of the exported knowledge are also appropriate to be placed into portals in forms of portlets. If the knowledge base was previously connected to external sources to retrieve data, this connection may be maintained for the exported knowledge base as well. Thus quick evaluations can be made, when the decision maker needs to fill in only a few fields (assign a value of an attribute for a case), while the rest is retrieved from databases. (
Figure G-14: Evaluation in Intelligent Portal.
