GENERAL INFORMATION - ELEMENTARY EXACT FORWARD CHAINING

The elementary exact rule- and model-based expert system shell rmes_EE may be used for forward chaining with elementary exact knowledge bases. Generally, an Elementary Exact Knowledge Base may contain following components:

1) An Elementary Exact Rule Base
2) An Elementary Exact Model Base
3) An Elementary Exact Constraint Base
4) An Elementary Exact Advice Base
5) Advice Text Files
6) An Elementary Exact Graphics Base
7) Graphics Files
8) An Elementary Exact Sound Base
9) Sound Files
10) An Abstract Text File

A rule base together with a model base are (jointly) elementary if:

    • no rule conclusion appears in negated form as condition of any other rule, and
    • no rule conclusion appears in negated form as go-ahead condition of any model, and
    • no relational model conclusion appears in negated form as condition of any rule, and
    • no relational model conclusion appears in negated form as go-ahead condition of any other model.

Otherwise stated - nesting with negation is infeasible.

A rule base is exact if its conditions and conclusions are logical string variables with includes taking values from the set (true, false).

A model base is exact if the conclusions of relational models are logical string variables with includes values from the set (true, false).

Elementary exact forward chaining aims at:

    • determining all rule conclusions which are true, and
    • determining all results of tractable models, and
    • determining all relational model conclusions which are true

for a given knowledge base, for a set of askable conditions with known logical values and for a set of askable arguments with known arithmetic values.

It should be noted that forward chaining is not producing any messages about conclusions of rules and relational models, which do not happen to be true. This is a direct consequence of the open world assumption.

It should be noted as well that forward chaining is determining all conclusions that are true and determining all results of tractable models, regardless of whether the user is interested in them or not.


GENERAL INFORMATION - ELEMENTARY EXACT BACKWARD CHAINING

The elementary exact rule- and model-based expert system shell rmes_EE may be used for backward chaining with elementary exact knowledge bases. Generally, an Elementary Exact Knowledge Base may contain following components:

1) An Elementary Exact Rule Base
2) An Elementary Exact Model Base
3) An Elementary Exact Constraint Base
4) An Elementary Exact Advice Base
5) Advice Text Files
6) An Elementary Exact Graphics Base
7) Graphics Files
8) An Elementary Exact Sound Base
9) Sound Files
10) An Abstract Text File

A rule base together with a model base are (jointly) elementary if:

    • no rule conclusion appears in negated form as condition of any other rule, and
    • no rule conclusion appears in negated form as go-ahead condition of any model, and
    • no relational model conclusion appears in negated form as condition of any rule, and
    • no relational model conclusion appears in negated form as go-ahead condition of any other model.

Otherwise stated - nesting with negation is infeasible.

A rule base is exact if its conditions and conclusions are logical string variables with includes taking values from the set (true, false).

A model base is exact if the conclusions of relational models are logical string variables with includes values from the set (true, false).

Elementary exact backward chaining aims at testing a hypothesis declared by the user, for a given knowledge base, for a set of askable conditions with known logical values and for a set of askable arguments with known arithmetic values.

The tested hypothesis must be a conclusion of at least one rule or relational model.

The testing may finish in one of two ways:

    • successfully: the hypothesis is true;
    • undeterminedly: the hypothesis remains un-instantiated. This is a consequence of the open world assumption: for elementary exact bases a hypothesis can never be proven to be false.

Hypotheses may be either narrow-sense or wide-sense:

    • narrow sense hypotheses are given by any conclusions of rules and relational models, which are not at the same time conditions of other rules or go-ahead conditions of models;
    • wide sense hypotheses are given by any conclusions of rules and relational models, no matter whether they are or are not conditions of other rules or go-ahead conditions of models.


ELEMENTARY EXACT RULE BASE

The Elementary Exact Rule Base for Knowledge Base KBN is named RUKBN.EEB and contains following clauses:

rule(Rule_Number, "Conclusion", List_of_Conditions, Display_Semaphore)

and:

fact("Askable Condition")

where:

    • Rule_Number is an integer, distinct from other rule numbers and distinct from model numbers;
    • "Conclusion" is a logical string variable corresponding to the name of the rule conclusion.
      E.g. the conclusion "Give credit" means, that Give credit is a logical variable that may be instantiated with either 'true' or 'false'.
      The conclusion "end" has special properties: if a rule with that conclusion is satisfied, the chaining is stopped;
    • List_of_Conditions is a list of logical string variables, corresponding to names of rule conditions. E.g.: List_of_Conditions =["Condition_1",...,"Condition_n"], where "Condition_i" denotes the logical string variable corresponding to the name of Condition_i. The condition "No condition" is always true;
    • Display_Semaphore should be equal
      • 0 - if no message about the rule being evaluated is to be displayed while chaining, or
      • 1 - if a message about the rule being evaluated is to be displayed while chaining.

The meaning of the rule is as follows:

    • Conclusion is true if all logical variables included in the List_of_Conditions are true. The rule is then said to be resolved.
    • Conclusion is undetermined if at least one of the logical variables included in the List_of_Conditions is false. The rule is then considered to be unresolved.

This way of handling negations is sometimes called the open world assumption. Its aim is to leave an open door for cases which in view of the given evidence cannot be considered as true: perhaps the knowledge base designer may eventually envisaged another rule for the same conclusion but with different conditions, for which the conclusion may turn out to be true.

A single rule thus serves to declare that the Conclusion is an implication of the conjunction of all conditions from the List_of_Conditions .

The rule is thus an IF...THEN rule with the following properties:

    • IF all conditions from the List_of_Conditions are true, THEN Conclusion is true.
    • IF at least one condition from the List_of_Conditions is false, THEN Conclusion is undetermined.

Sometimes the truth of a conclusion may be established by either one of two sets of totally or partially independent conditions like this:

rule(N, "Conclusion", List_of_Conditions_1,_)

rule(N+1, "Conclusion", List_of_Conditions_2,_)

The meaning of those two rules is as follows:

    • IF all conditions from the List_of_Conditions_1 are true, or IF all conditions from the List_of_Conditions_2 are true, THEN Conclusion is true.
    • IF at least one condition from the List_of_Conditions_1 is false and one condition from the List_of_Conditions_2 is false, THEN Conclusion is undetermined.

Sometimes we do need to have negated conclusions of some rules. Consider the following example:

rule(1,"I am going to buy a new car",["I got a huge bonus"],1)

rule(2,"I am going to buy a new car",["I inherited a lot of money"],1)

rule(3,"I am going to buy a new car",["I scored on Bingo"],1)

If none of rules 1, 2 or 3 is resolved, then - in accordance with the open world assumption - the system will not determine a logical value for the conclusion I am going to buy a new car: some other circumstances may arise (e.g. I might get a large sum of money for selling my expert system) which eventually will enable me to buy a new car. As a matter of fact the system will say nothing when confronted with No's to all conditions.

However, if our set of rules is covering all imaginable cases for which I might eventually buy a new car (i.e. all rules are considered as straightforward conjunctions of their conditions) and all conditions are false, then obviously I won't by a new car and have to settle for a second-hand one. How to put it into rules? First, the negation of conclusion I am going to buy a new car me be generated by an additional rule 4:

rule(4,"I am not going to buy a new car",["I got no huge bonus",
"I didn't inherit a lot of money","I didn't score on Bingo"],1)

Rule 4 follows from a straightforward application of de Morgans law. The need to purchase a second-hand car may now be described by rule 5:

rule(5,"I am going to buy a second-hand car",["I am not going to buy a new car"],1)

Additionally, constraint base clauses need to be created to inform the expert system that askable conditions:

    • I got a huge bonus and I got no huge bonus
    • I inherited a lot of money and I didn't inherit a lot of money
    • I scored on Bingo and I didn't score on Bingo

are forming mutually exclusive pairs.

Part of the problems caused by negated conditions may be bypassed using augmented exact chaining for augmented exact knowledge bases.

The ordering of rules in the rule base may be arbitrary. In particular, rules with the same Conclusion need not be adjacent in the rule base for the chaining to be performed correctly. However, in order to make the rule base readable and transparent for the user and developer, it is recommended to group together rules having the same Conclusion. It should also be remembered that the testing of the rule base proceeds from its top to its bottom.

The ordering of conditions in the List_of_Conditions may also be arbitrary. However, it should be remembered that the first condition of the List_of_Conditions will be the first to be tested.

Any condition usually consists of some attribute and its value and may be looked upon as having the general form Attribute has value, e.g. The power consumption of the apparatus is < 15 W. This convention makes it easy to have conditions which are solely logical variables. No prior declaration of all attributes is needed.

Rules may be nested with other rules and models, i.e.:

    • conclusions of some rules may serve as conditions of other rules, or
    • conclusions of some rules may serve as go-ahead conditions of models.

However, elementary rule base nesting may not be accompanied by negation: no conclusion of any rule may ever appear in negated form as condition of some other rule. This hindrance will be removed for augmented exact knowledge bases.

Because of rule nesting, all conditions belong to one of the following two categories:

    1. Askable conditions are those conditions, which are not conclusions of any rules or relational models. The expert system asks the user to declare logical values ('true','false') of askable conditions.
    2. Unaskable conditions are those conditions, which are conclusions of some rules or relational models. Logical values ('true','false') of unaskable conditions result from chaining done by the expert system.

Obviously, in order to start chaining for a Knowledge Base with no Model Base, the Rule Base must contain at least one rule having only askable conditions.

If logical values for some askable conditions remain 'true' for a number of expert consultations, they may be declared beforehand as 'true' by clauses:

fact("Askable Condition")

where "Askable Condition" is a logical string variable corresponding to a name of true askable condition Askable Condition. The user is then freed from the task of declaring the logical values each time a new consultation begins.

The chaining always starts with presenting facts declared in the rule base using fact() clauses, if any. If some askable conditions are not declared using fact() clauses and are not related by the constraint base to conditions declared by fact() clauses, the expert system asks the user (in a proper place of the chaining process) about the logical values of those conditions.


ELEMENTARY EXACT MODEL BASE

The Elementary Exact Model Base for Knowledge Base NBW is named MONBW.EEB and may contain elementary basic models, elementary extended models, elementary linear models, elementary polynomial models, askable argument values and true go-ahead conditions

An elementary exact model for some Result/Conclusion is:

    • singular, if the model base does not contain other models with the same Result/Conclusion;
    • multiple, if the model base contains at least on more model with the same Result/Conclusion.

For all elementary exact models:

    • Model_Number is an integer, distinct from other model numbers and distinct form rule numbers;
    • "Go-Ahead Condition" is a logical string variable, controlling the model usage. The model may be used (i.e. the values of Result/Conclusion may be determined) only if:
      • Go-Ahead Condition is true or if
      • "Go-Ahead Condition" = "No condition";
      The Go-Ahead Condition is then said to be satisfied. Otherwise it is considered unsatisfied and its model is bypassed in the chaining process.
      Go-Ahead Conditions different from No condition are applied for following purposes:
      • to indicate the multiple model, which has to be used in a particular situation;
      • to indicate the unique model, which has to be bypassed in a particular situation.
      Go Ahead Conditions may be direct, but not negated, conclusions of some rules or some relational models.
    • Display_Semaphore should be equal:
      • 0 if no data about the model being evaluated is to be displayed while chaining, or
      • 1 if data about the model being evaluated is to be displayed while chaining.
------------------------------------------------------------------------------------
    1. Clauses for basic models are of the form:

      model_b(Model_Number,"Go-Ahead Condition","Result"/"Conclusion",
      "First Argument","Operation"/"Relation","Second Argument",
      Display_Semaphore)

      where:
        • "Result"/"Conclusion" is:
          • a real string variable "Result" for arithmetical models;
          • a logical string variable "Conclusion" for relational models;
        • "First Argument" and "Second Argument" are real strings variables for arithmetical as well as for relational models;
        • "Operation"/"Relation" is a string staying for:
          • an arithmetical operation symbol "Operation" for arithmetical models with two arguments. Following operations are supported: "+", "-" ,"*", "/", "=","div", "mod", "min", "max","%", "round_to_N","A^N";
          • an arithmetical operation symbol "Operation" for arithmetical models with a single argument only. Following operations are performed on the value of First Argument are supported: "sqrt", "sin", "cos", "tan", "arctan", "log", "ln", "exp", "round", "trunc", "abs" while "Second Argument"="0.0".
          • a relational symbol "Relation" for relational models. Following relations between values of First Argument and Second Argument are supported: ">", "==", "<", ">=", "<=", "><", "<>";

      The meaning of a basic model is as follows:
      • for an arithmetical model with two arguments, provided the Go-Ahead Condition is fulfilled, a Result is generated which corresponds to the real value obtained by operation performed on values of both arguments. If the First Argument is a number to be rounded, the Second Argument is the number of decimal positions N, and Operation = round_to_N, then the result is the First Argument rounded (up or down, depending upon its value) to the given number N of decimal positions;
      • for an arithmetical model with a single argument, provided the Go-Ahead Condition is fulfilled and Second_Argument = 0, a Result is generated which corresponds to the real value obtained by Operation performed on the value of First Argument;
      • for a relational model, provided the Go-Ahead Condition is satisfied, the Conclusion is unified with the logical value determined by the Relation:
        • if the Relation is satisfied, the Conclusion is true;
        • if the Relation is not satisfied, the Conclusion remains uninstantiated.
        This way of handling negations is sometimes called the open world assumption. Its aim is to leave an open door for cases which in view of the given evidence cannot be considered as true: perhaps the knowledge base designer may eventually envisage another relational model for the same Conclusion, but with a different Relation, for which the Conclusion may turn out to be true;
      • for any model, for which the Go-Ahead Condition is not satisfied, the Result, or Conclusion, remains uninstantiated.

      -----------------------------------------------------------------------------------------

    2. Clauses for extended models are of the form:

      model_e(Model_Number, "Go-Ahead Condition","Result"/"Conclusion",
      "Operation"/"Relation", List_of_Arguments, Display_Semaphore)

      where:
        • "Result"/"Conclusion" is:
          • a real string variable "Result" for arithmetical models;
          • a logical string variable "Conclusion" for relational models;
        • "Operation"/"Relation" is a string staying for:
          • an arithmetical operation symbol "Operation" for arithmetical models with any number of arguments. Following operations are supported: "+", "*" ,"max_list","min_list";
          • a relational symbol "Relation" for relational models. Following two-sided relations between values of from the List_of_Arguments are supported: "<,<", "<=,<", "<,<=", "<=,<=";
        • List_of_Arguments is a list:
          • of any number of real string variables for an arithmetical extended model;
          • of three real string variables defining a binary relation:
            ["Lower Bound","Tested Variable","Upper Bound"]
            for a relational extended model;

      The meaning of an extended model is as follows:
      • for an arithmetical extended model, provided the Go-Ahead Condition is satisfied, a Result is generated which corresponds to the real value obtained by Operation performed on values of all real variables from the list of arguments;
      • for a relational extended model, provided the Go-Ahead Condition is satisfied, the Conclusion is unified with the logical value determined by the Relation between the values of Lower Bound, Tested Variable and Upper_Bound:
        • if the Relation is satisfied, the conclusion is true;
        • if the Relation is not satisfied, the conclusion remains un-instantiated.
        This way of handling negations is sometimes called the open world assumption. Its aim is to leave an open door for cases which in view of the given evidence cannot be considered as true: perhaps the knowledge base designer may eventually envisage another relational model for the same Conclusion, but with a different Relation, for which the Conclusion may turn out to be true;
      • for any model, for which the Go-Ahead Condition is not satisfied, the Result, or Conclusion, remains uninstantiated.

      ----------------------------------------------------------------------------------------

    3. Clauses for linear models are of the form:

      model_lin(Model_Number,"Go-Ahead Condition","Result",
      List_of_Coefficients, List_of_Variables, Display_Semaphore)

      where:
        • "Result" is a real string variable corresponding to the value of the linear form;
        • List_of_Coefficients is a list of any number of real string variables corresponding to consecutive coefficients of the linear model. The list may be mixed: some strings may correspond to names, some other to values;
        • List_of_Variables is a list with the same number of real string variables as the List_of_Coefficients. The strings correspond to names or values of consecutive variables of a linear model. The list may be mixed: some strings may correspond to names, some other to values;

      The meaning of a linear model is as follows:
      • provided the Go-Ahead Condition is satisfied, all Coefficients and all Variables have been instantiated, a Result is generated which equals the real value of the linear form:
        Result = A1*X1 + A2*X2 + ... + AN*XN
        where:
        List_of_Coefficients = ["A1", "A2",...,"AN"]
        List_of_Variables = ["X1", "X2",...,"XN"]
      • if the Go-Ahead Condition is not satisfied, the Result remains uninstantiated.

      --------------------------------------------------------------------------------------

    4. Clauses for polynomial models are of the form:

      model_poly(Model_Number,"Go-Ahead Condition","Result",
      "Polynomial_Variable", List_of_Coefficients, List_of_Powers,
      Display_Semaphore)

      where:
        • "Result" is a real string variable corresponding to the value of the polynomial;
        • "Polynomial_Variable" is a real string variable corresponding to the value of the variable, for which the polynomial is determined;
        • List_of_Coefficients s a list of any number of strings corresponding to names or values of real variables being consecutive coefficients of a polynomial model. The list may be mixed: some strings may correspond to names, some other to values;
        • List_of_Powers is a list of integers. The number of integers must be equal to the number of coefficients of the List_of_Coefficients. The integers correspond to powers of the polynomial variable. The order of the elements of the integer in the list of powers must correspond to the order of coefficients in the list of coefficients.

      The meaning of a polynomial model is as follows:
      • provided the Go-Ahead Condition is satisfied, the Polynomial variable and all Coefficients have been instantiated, a Result is generated which equals the real value of the polynomial form:
        Result = A0 + A1*X + A2*X^2 + ... + AN*X^N
        where
        List_of_Coefficients = ["A0","A1","A2",...,"AN"]
        List_of_Powers = [0, 1, 2,...,N] LI>if the Go-Ahead Condition is not satisfied, the Result remains uninstantiated.
------------------------------------------------------------------------------------

A model is tractable, if all its arguments have been instantiated.

Models may be nested with other models and rules:

    • results of some arithmetical models may serve as arguments of other arithmetical or relational models, or
    • conclusions of some relational models may serve as go-ahead conditions of other models, or
    • conclusions of some relational models may serve as conditions of rules, or
    • conclusions of some rules may serve as go-ahead-conditions of models.

However, elementary model base nesting may not be accompanied by negation: no conclusion of any relational model may ever appear in negated form as go-ahead condition of some other model or as condition of some other rule.

Because of model nesting all model arguments belong to one of the following two categories:

    1. Askable arguments are those arguments, which are not results of any arithmetical models. The expert system asks the user to determine real values of askable arguments.
    2. Unaskable arguments are those arguments, which are results of some arithmetical models. Real values of unaskable arguments result from calculations done by the expert system.

Because of model nesting all model go-ahead conditions belong to one of the following two categories:

    1. Askable go-ahead conditions are those go-ahead conditions, which are not which are not conclusions of some relational models or rules of the rule base. The expert system asks the user to determine logical values of askable go-ahead conditions.
    2. Unaskable go-ahead conditions are those go-ahead conditions, which are conclusions of some relational models or conclusions of rules of the rule base or are equal to No condition. Logical values ('true','false') of unaskable go-ahead conditions result from the chaining done by the expert system. The expert system considers the unaskable go-ahead condition No condition as always 'true'.

Obviously, in order to start chaining, either the Rule Base must contain at least one rule with askable conditions only, or the Model Base must contain at least one model with askable arguments only and askable go-ahead condition.

If numerical values for some askable arguments do not change for a series of expert consultations, they may be declared beforehand by clauses:

argument_known("Askable Argument",Askable_Argument_Value)

where:

    • "Askable Argument" is a real string variable;
    • Askable_Argument_Value is its value.

The user is then freed from the task of declaring the numerical values each time a new consultation begins.

The chaining starts with presenting argument values declared in the model base using argument_known(_,_) clauses, if any.

If some askable arguments are not declared using argument_known(_,_) clauses, the expert system asks the user (in a proper place of the chaining process) about the real values of those arguments.

If values for some askable go-ahead conditions remain unchanged for a number of expert consultations, they may be declared by clauses:

m_fact("Askable go-ahead condition")

where Askable go-ahead condition is considered to be true.

If some askable go-ahead-conditions are not declared using m_fact() clauses of the model base, the expert system asks the user (in a proper place of the chaining process) about the logical values of those conditions.

If some relational models for the same variable argument are exclusive to one (that means only one of those models may ever be satisfied) or exclusive to non (that means only one or none of those models may ever be fullfilled), and the conclusions of those relational models serve as go-ahead conditions for a set of arithmetical models, it should be declared by a clause:

exclusive_models([List_of_relational_model_conclusions])

This is illustrated by the following example:

model(1,"use A","Result","A","+","10",1),

model(2,"use B","Result","B","-","5",1),

model(2,"use C","Result","C","*","12",1),

exclusive_models(["use A","use B","use C"]),

Often the same conclusion may be true for a number of relations. This can be declared by a number of relational models:

model_b(1,"No condition","Conclusion","A",">=","10",1)

model_e(2,"No condition","Conclusion","<=,<=",["15","B","20"],1)

For sucha group of relational models no additional declarations are needed: Conclusion is true, if for any of the models 1 or 2 its relation is fulfilled. This is a perfect analogy with elementary exact rules having the same conclusion.

If some erronous numerical data is inputed while chaining there is no need to start the chaining all over again provided we have declared the erronous numerical data with a relational model using the key-word conclusion:

"Error in data",

like this:

model_b(1,"Go-Ahead Condition","Error in data", "Number","<","0",1)

This works as follows: if for any model the value of Number is declared as negative, the message:

Error in data! Erroneous data is removed. Continue chaining and declare corrected data when asked.

id displayed, the negative value for Number is removed and - for some next browsing of the model base the user may declare a correct value for Number.


ELEMENTARY EXACT CONSTRAINT BASE

The Elementary Exact Constraint Base for knowledge base KBN is named COKBN.EEB and contains clauses of the form:

constraint(Constraint_number,List_of_Askable_Exact_Collectively_Exhaustive_Conditions)

where:

    • Constraint_number is an integer, distinct from other constraint numbers;
    • List_of_Askable_Exact_Collectively_Exhaustive_Conditions is a list of logical string variables corresponding to askable conditions, which are mutually exclusive and completely exhaust the set of values of the (often default) attribute they correspond to.

Example:

constraint(1,["Age <= 20","20 < Age <= 40","Age > 40"])

The askable conditions Age <= 20, 20 < Age <= 40, Age > 40 are mutually exclusive and completely exhaustive for the attribute Age. Obviously, only one of askable conditions in the list is true, the remaining being false.

The purpose of Constraint Bases is twofold:

    1. To keep the expert system from asking questions about the truth of conditions, that may be inferred from answers already given.
    2. To define pairs of dichotomous askable conditions. E.g. the constraint:

      constraint(2,["Getting leave of absence",
      "Getting no leave of absence"])>

      informs the expert system, that the askable condition Getting no leave of absence is the negation of askable condition Getting leave of absence and vice versa. The confirmation or refutation of any of those askable conditions keeps the expert system from asking about the truth of the remaining one.

Loading a proper constraint base is not necessary in order to proceed with chaining for a loaded rule base. The chaining may however be irritating to the user because of some "unnecessary" questions being asked.


ELEMENTARY EXACT GRAPHICS BASE

The Elementary Exact Graphics Base for knowledge base KBN is named GRKBN.EEB and contains clauses of the form:

graphics(Rule/Model_Number,"Name_of_Graphics_for_Rule/Model.bmp")

where:

    • Rule/Model_Number is an integer, equal to the number of some rule or relational model, which - when resolved - generates a proposal to display the relevant graphics. The user may or may not accept the proposal to display the graphics;
    • Name_of_Graphics_for_Rule/Model.bmp is the name of the relevant graphics file.

Graphics files for knowledge base KBN reside in the Graphics Subdirectory .\GRAPHICS\KBN. A Graphics Base may be loaded only if the corresponding Graphics Subdirectory with graphics files exists.

Each rule and each relational model may by associated with at most one graphics file from the corresponding Graphics Subirectory. Rules and relational models with no associated graphics files are acceptable.


ELEMENTARY EXACT SOUND BASE

The Elementary Exact Sound Base for knowledge base KBN is named SOKBN.EEB and contains clauses of the form:

sounds(Rule/Model_Number,"Name_of_Sound_for_Rule/Model.wav")

where:

    • Rule/Model_Number is an integer, equal to the number of some rule or relational model, which - when resolved - generates a proposal to play the relevant sound. The user may or may not accept the proposal to play the sound;
    • Name_of_Sound_for_Rule/Model.wav is the name of the relevant sound file.

Sound files for knowledge base KBN reside in the Sounds Subdirectory .\Sounds\KBN. A Sound Base may be loaded only if the corresponding Sound Subdirectory with graphics files exists.

Each rule and each relational model may by associated with at most one sound file from the corresponding Sounds Subirectory. Rules and relational models with no associated sound files are acceptable.


KNOWLEDGE PARTITION PRINCIPLE

The partition of domain knowledge between rule- and constraint- bases on the one side and a model base on the other, is done according to the following obvious principles:

    • all purely logical knowledge (conjunctions, disjunctions, negations) must be embedded into the rule- and constraint bases;
    • all procedural knowledge (arithmetical operations) and all relational knowledge (inequality and equality relations) must be embedded into the model base.


ELEMENTARY EXACT ADVICE BASE

The Elementary Exact Advice Base for knowledge base KBN is named ADKBN.EEB and contains clauses of the form:

advice(Rule/Model_number, "Name_of_Advice_for_Rule/Model.HLP")

where:

    • Rule/Model_Number is an integer, equal to the number of some rule or relational model which - when resolved - generates a proposal to display the relevant advice. The user may or may not accept the proposal to display the advice;
    • Name_of_Advice_for_Rule/Model.HLP is the name of the relevant advice file.

Advice files for knowledge base KBN reside in the Advice Subdirectory .\ADVICES\KBN. An Advice Base may be loaded only if the corresponding Advice Subdirectory with advice files exists.

Each rule and each model may by associated with at most one advice file from the corresponding Advice Subirectory. Rules and models with no associated advice files are acceptable.

The expert system differentiates between advices for rules and advices for models thanks to different rule numbers and model numbers.


ADVICE TEXT FILES

To each Knowledge Base named KBN may by assigned an Advice Sub-directory with the same name KBN, residing in the directory .\ADVICES. E.g. advices for the knowledge base CRE thus reside in the file .\ADVICES\CRE.

The Advice Sub-directory contains advice text files with names from the Advice Base. All advice text files have extensions .HLP. Creating, editing and deleting of advice text files is initiated by choosing a proper option form the Advice Base menu.


ABSTRACT TEXT FILES

To each knowledge base named KBN may by assigned an abstract text file named KBN.ABS in the directory .\ABSTRACTS. The file presents an explanation of the domain knowledge used by Knowledge Base KBN

If such file exists for a particular knowledge base, it is automatically loaded after the respective rule base has been loaded.

Its content is displayed when the option Forward chaining or Backward chaining from Main Menu is chosen. However, the existence of the abstract text file is not necessary for chaining to be performed.


NAMING CONVENTIONS AND DIRECTORIES

Names for elementary exact rule bases, model bases, constraint bases, advice bases, graphics bases and sound bases are generated by concatenating a standard 2-letter abbreviation identifying the nature of the base (RU, MO, CO, AD, GR, SO) with the proper knowledge base name KBN and the extension EEB (Elementary Exact Base).

Thus Elementary Exact Rule Bases names have the general form:
RUKBN.EEB,

Elementary Exact Model Bases:
MOKBN.EEB,

Elementary Exact Constraint Bases:
COKBN.EEB,

Elementary Exact Advice Bases:
ADKBN.EEB,

Elementary Exact Graphics Bases:
GRKBN.EEB,

and Elementary Exact Sound Bases:
SOKBN.EEB.

Therefore, for the credit evaluation knowledge base CRE the rule base is RUCRE.EEB, the model base MOCRE.EEB, the constraint base COCRE.EEB and the advice base ADCRE.EEB.

All bases are in the directory .\BASES.

The knowledge base name KBN is also used:

    • for naming the advice text file subdirectory for this knowledge base. It may be found in .\ADVICES\KBN;
    • for naming the abstract text file for this knowledge base. It bears the name KBN.ABS and may be found in .\ABSTRACT\KBN.ABS;
    • for naming the graphics file subdirectory for this knowledge base. It may be found in .\GRAPHICS\KBN;
    • for naming the sound file subdirectory for this knowledge base. It may be found in .\SOUNDS\KBN.

Chaining reports may be saved in text files with names *.RPT and may be found in .\REPORTS\*.RPT Chaining summaries may be saved in text files with names *.TXT in .\SUMMA\*.TXT Askable conditions and arguments for a given knowledge base may be saved in a text file *.TXT in .\ASKABLES\*.TXT


BASE LOADING MODES

There are two modes of Knowledge Base loading:

    1. Loading for applications (diagnostics, analysis and chaining). It is done by first choosing the option Exact Rule Base/Rule Base Loading of Main Menu. It is impossible to use this mode for loading a model base, constraint base or advice base, if the corresponding rule base has not been loaded and accepted as correct. That means no chaining is possible with no rule base. If the rule base is loaded, a series of diagnostics checks is performed. If the rule base does not pass the checks, it is removed from the expert system shell and a proper diagnostic message, with details of the error nature and advice about removing it, is generated. It means that only syntacticly correct rule bases may be loaded for application. If the rule base passes the checks, some (or all) of the remaining bases may be loaded, provided the Knowledge_Base_Name part of their names corresponds to the Knowledge_Base_Name part of the rule base already loaded. The loading of each of the remaining bases is concluded by a series of relevant diagnostic checks to be discussed in details later. If the base does not pass the checks, it is removed from the expert system shell and a proper diagnostic message, with details of the error nature and advice about removing it, is generated.
    2. Loading for editing is done by choosing the Exact Rule Base/Rule Base Editing, Exact Modele Base/Modele Base Editing, Exact Constraint Base/Constraint Base Editing option. Any base may be loaded for editing as a straightforward text file, irrespective of its syntactic correctness.


DIAGNOSTIC CHECKS

Diagnostic checks on elementary exact knowledge bases are initiated after loading the rule base for chaining. They include:

    1. Formal checks on rule base syntax. Syntax errors generate messages pinpointing syntactic errors in the rule base and blocking further work with the faulty base beside this of editing. The user is urged to choose the option Rule Base Editing in the menu for Exact Rule Base,load the faulty base and remove the fault.

    2. If there are no syntax errors, a mandatory check for external IEE1-inconsistencies i.e. for rules with conclusions inconsistent with their conditions, is performed. The detection of IEE1-inconsistencies is blocking further base loading and chaining. The reason for this is that external inconsistencies may cause infinite loops in the chaining process and externally inconsistent rule bases cannot be flattened.

      The user may have a look at a diagnostic message, describing the type of inconsistency and the rules generating it. For this the option Diagnosing External Inconsistencies in the menu for Exact Rule Base has to be chosen.

    3. If there are no syntax errors and external IEE1-inconsistencies, an optional check for REE1-redundancies (redundant rules, subsumed rules) may be performed.

      The detection of REE1-redundancies is not blocking further base loading and chaining, because redundancies do not cause system breakdown due to infinite loops. They may however lead to an unnecessarily large number of conditions to be fulfilled for the truth of some conclusions to be established.

      However, redundancies tests are performed on flattened rule bases and this flattening may take - for large and heavily nested rule bases - an extraordinarily large amount of time. Therefore for routine use of already well-tested knowledge bases, testing of redundancies is usually bypassed. If performed and redundancies were detected, the user may get a diagnostic message, describing the type of redundancy and the rules and constraints generating it.

    4. If there are no external IEE1-inconsistencies, an obligatory check on unaskable conditions in fact() clauses is performed. The detection of such conditions generates a message and blocks chaining with the rule base.

    5. If all previous tests have been passed successfully, the system proposes to make an optional test for rules with single conditions. Such rules are most often tautologies and the user is urged to have a closer look at them. However, further work with the base is not blocked.

    6. If the rule base has been successfully loaded, all askable conditions of the rule base are determined. The user may have a look at them choosing a proper option in the Exact Rule Base menu.

    7. If the rule base has been accepted by the expert system shell rmes_EE as error-free, the model base may be loaded and formal checks on model base syntax are performed. Syntax errors generate messages pinpointing errors in the model base and block any further work with the bases loaded so far, beside this of editing them.

    8. If the model base has no syntactic error, an obligatory test on model inconsistency is performed. Two types of model inconsistency may be detected:
      1. The result of some arithmetical model is equal to one of its arguments, either directly or via a chain of nested models.
      2. The conclusion of some relational model is the same as its go-ahead condition, either directly or via a chain of nested models.
      If the model base is inconsistent, further work with the knowledge base is blocked.

      If the model base is consistent, a test on joint model-rule inconsistency is performed. Such inconsistency may occur for a relational model with go-ahead condition defined by a rule with a condition - either directly or via a chain of nested rules - equal to the conclusion of the relational model. If the model- and rule-bases are jointly inconsistent, further work with the knowledge base is blocked.

    9. If the model base has passed all previous tests, a number of tests for more subtle semantic errors is performed:
      • the presence of same name serving as relational model conclusion and rule conclusion is checked;
      • the presence of same name serving as rule conditions and arithmetical model arguments is checked;
      • the presence of same name serving as relational model conclusion and arithmetical model argument is checked.
      If any of these double-naming errors occur, further work with the knowledge base is blocked.

    10. If everything is O.K. up to now, obligatory checks on unaskable conditions in m_fact() clauses and unaskable arguments in argument_known(_) clauses are performed. The detection of such conditions or arguments there generates a message and blocks further work with the knowledge base.

    11. If the model base has been successfully loaded, all askable conditions and askable arguments of the model base are determined. This may change at times the set of previously generated askable conditions: some of those detected as askable for the rule base alone may be determined latter on by relational models and therefore stop being askable.

      The user may have a look at them choosing a proper option in Exact Model Base.

    12. If the model base has been successfully loaded or no model base loading has been requested, the constraint base may be loaded and formal checks on constraint base syntax are performed. If the constraint base syntax is OK, checks are performed to confirm the askability of all conditions of the constraint base. If an unaskable condition is found in the constraint base, a message pinpointing the error in the constraint base is displayed and any further work with the bases loaded so far (besides this of editing them) is blocked. If everything is O.K., a check is performed to make sure that there are no sets of mutually exclusive conditions containing only one condition.

      Next, if a model base has been loaded, the go-ahead conditions for models with same results are tested to see whether the constraint base (perhaps together with the rule base) assures that the go-ahead conditions are mutually exclusive. If they are not further work with the model base is blocked.

    13. If everything is O.K. up to this moment, a test for joint rule- and constraint-based IEE2-inconsistency is proposed. This is a test which discovers constraints which make some rules internally inconsistent by constraining some of their conditions to be mutually exclusive. The test is not mandatory for the following reasons:
      • joint rule-constraint inconsistency is not critical, i. e. it does not lead to the chaining process breaking down. It simply removes some rules from the rule base;
      • to test this inconsistency, all rules must be flattened, which may be a very time-consuming process.
      The eventual detection of IEE2-inconsistencies is not blocking further base loading and chaining. The user should however remember that IEE2-inconsistencies are effectively removing rules with inconsistent conditions from the rule base.

      If the test was performed, the user may get a diagnostic message, describing the type of inconsistency and the rules and constraints generating it.

    14. Next, checks for joint rule-constraint base REE2-redundancies are proposed, i.e. for constraints, which make some rules redundant. The non-mandatory nature of this test is justified in the same way as for the joint rule-model base inconsistencies: detection of REE2-redundancies is not blocking further base loading and chaining, because redundancies do not cause system breakdown. They may however lead to an unnecessarily large number of conditions to be fulfilled for the truth of some conclusions to be established. As a result of running the test a diagnostic message is generated, describing the type of redundancy and the rules and constraints generating it.

    15. To facilitate the removal of rule base and constraint base inconsistencies and redundancies, diagnostic reports may be generated for each type of inconsistency and redundancy detected.

    16. If the rule base has been successfully loaded and the model- and constraint bases have been either successfully loaded or no attempt at loading them has been made and the corresponding advice file is in the directory .\ADVICES, the advice base may be loaded and formal checks on advice base syntax are performed. If no advice file exists, the loading of advice base is blocked.

      If the advice base is OK or no advice base has been loaded, the system is ready to perform chaining.


EDITING BASES AND TEXT FILES

The editing options include:

    1. Options for creating new bases and text files.
    2. Options for editing bases and text files.
    3. Options for deleting bases or text files.

All groups of options for editing bases or files are available for any kind of bases or files correspondingly in the submenus for Exact Rule Base, Exact Model Base, Exact Constraint Base or Exact Advice Base.

Abstract text files may be edited by choosing options from the submenu Abstracts and Reports.

A multi-editing option for simultaneous editing a number of bases or files is available.


REPORTS OF CHAINING AND DIAGNOSING

For a loaded Knowledge Base a text file *.TXT with names of all askable conditions and arguments may be generated. This may be done using a suitable sub-option of the Askable Conditions and Arguments Activites option of the Main Menu. The askable conditions and arguments file is stored in .\ASKABLE.

Using another sub-options of the Askable Conditions and Arguments Activites, the askable conditions and arguments files may be read or deleted.

All messages displayed while chaining may - at the end of it - be accumulated into a report. All messages displayed while diagnosing inconsistencies and redundancies may - at the end of it - be accumulated into a report. Both kinds of reports are stored in the same directory .\REPORTS and both share the same extension .RPT. The reports are available for reading or deleting through a directory browser from the Report Inspection and Report Deleting options of the Abstracts and Reports menu.

All facts and argument values used and established while chaining may - at the end of it - be accumulated into a summary text file *.TXT. The summary text files are stored - together with a number of labels defining the subject for which chaining has been done - in the directory .\SUMMA. The summary text files are available for reading or deleting through a directory browser from the Summary Reading or Summary Deleting options of the Abstracts and Reports menu.


FLAT RULES AND RULE FLATTENING

Flat rules are rules with only askable conditions.

Rule which are not flat and not externally inconsistent may be flattened by exchanging all their unaskable conditions with conditions of those rules, which have the unaskable conditions as conclusions. In the process of flattening rules their display semaphores are neglected. E.g.: flattening the rule:

rule(i,"Conclusion_i",["Condition_i1","Condition_i2"],_)

provided the following rules are in the same rule base:

rule(m, "Condition_i1", ["Cond_m1","Cond_m2"],_)

rule(n, "Condition_i2", ["Cond_n1","Cond_n2"],_)

and all their conditions are askable, gives rule i flattened with rules m and n:

rule_flattened(i,"Conclusion_i",["Cond_m1","Cond_m2","Cond_n1","Cond_n2"],
[m,n])

The expert shell may be asked to flatten a single chosen rule or flatten all rules in turn. The options are available in the Knowledge Base Analysis option of the Main Menu. Flattened rules are made available for inspection by displaying:

Original_rule_number, "Conclusion", List_of_askable_conditions,
List_of_rules_used_for_flattening

For rules originally formulated as flat,

List_of_rules_used_for_flattening=[].

For a loaded rule base the result of flattening may be displayed by choosing the sub-option Rule base flattening of the Knowledge Base Analysis menu. The sub-option makes possible to flatten a single chosen rule or to flatten consecutively all rules.

If a non-flat rule may be flattened in a number of different ways, using different rules for flattening, all possible flattened rules are made available for inspection.

Because the number of flat rules may - for a heavily nested rule base - be enormous, the flattened rules are not stored, but only displayed.

For elementary exact rule bases flattened rules are useful for:

    • detecting and diagnosing rule base redundancies;
    • detecting and diagnosing joint redundancies of rule bases and constraint bases;
    • detecting and diagnosing joint rule- and constraint base inconsistencies.


VARIABLES

Elementary exact expert system shells make use of string variables. String variables are sequences of characters starting and ending with double quote ". The item inside the double quote will be referred to as Include of string variable, or shorter - include:

String variable = "Include of string variable"

String variables for elementary exact expert systems may be of logical, real or integer type.

    1. Logical string variables
      The include for any logical string variables presents always the name of the logical variable.
      E.g. the string variable Age > 45 years is a logical string variable, because any age may be either greater or not greater than 45 years.

      An askable logical variable may be uninstantiated or instantiated with only two values true or false:
      • Positive instantiation of askable logical variables is done using the clause fact(_) in the rule base or - if no such clause is present - by the user declaring the truth of the askable condition at a proper phase of the chaining.
      • Negative instantiation of askable logical variables is done by the user declaring the falsehood of the askable condition at a proper phase of the chaining

      Logical variables are handled in following ways:
      1. If the askable logical variable is un-instantiated, the expert system will - at a proper instant of chaining - ask the user about its logical value.
      2. If the askable logical string variable is instantiated, the expert system will ask no question, but simply use it for some rule.
      3. If the logical variable is unaskable and uninstantiated, the expert system will determine its positive logical value - if this is possible - in the chaining process.
      4. It is not allowed to instantiate unaskable logical variables using fact(_) clauses; the expert system will not accept it.

    2. Real and integer string variables
      The include for any real or integer string variable may be either:
      1. instantiated, i.e. given directly by its numerical values, e.g. 67.85, or declared using the clause argument_known(_,_);
      2. uninstantiated i.e. given by the variable names, e.g. Maximum temperature.
      Real and intedger string variables are handled in following ways:
        1. If the include of a real or integer string variable is an un-instantiated askable argument, the expert system will - at a proper instant of chaining - ask the user about its numerical value.
        2. If the include of a real or integer string variable is a un-instantiated unaskable argument, the expert system will determine its value using proper models in the chaining process.
        3. If the include of a real or integer string variable is an instantiated askable argument, the expert system will ask no question, but simply use it for some model.
        4. If the include of a real or integer string variable is an instantiated unaskable argument, the expert system will not accept it.
      Using string variables makes rules and models readable and flexible:
        • names of conditions, conclusions and arguments need not be atoms, but may be multi-element expressions as used in natural languages;
        • they may represent either results (for arithmetical models), conclusions (for relational models and rules) or conditions (for rules);
        • model arguments (as declared by the user in the model base) may have includes which are either instantiated or un-instantiated;
        • for a broad spectrum of problems solved with rmes_EE expert systems, no other data type seems to be needed.


COMMENTS IN BASES

Bases may be supplemented with comments placed in between any base items. Any comment must be a string argument of a proper clause:

    1. For rule bases:

      rem_rule("Text of comment").

    2. For model bases:

      rem_model_b("Text of comment");

      rem_model_e("Text of comment");

      rem_model_lin("Text of comment");

      rem_model_poly("Text of comment");

    3. For constraint bases:

      rem_constraint("Text of comment").

    4. For advice bases:

      rem_advice("Text of comment")

Any element of any base may be temporarily removed by prefixing it with an underscore:

    1. For rule bases:

      _rule(Nr,"Conclusion",List_of_conditions,_)

      _fact("Askable_condition")

    2. For model bases:

      _model_b(Nr, "Go-ahead condition","Result"/"Conclusion",
      "Arg1","Operation"/"Relation","Arg2",Display_Semaphore)

    3. In a similar way other models may be temporarily removed. Also:

      _argument_known("Name",Value) and:

      _m_fact("Askable_Go_Ahead_Condition")

    4. For constraint bases:

      _constraint(Nr,List_of_conditions)

    5. For advice bases:

      _advice(Nr,"Advice_name")

    6. For graphics bases:

      _graphics(Nr,"Grafics_name")

    7. For sound bases:

      _sounds(Nr,"Sounds_name")

The editing of comments is done for each kind of base in the same way as base editing, see EDITING BASES AND TEXT FILES.


INCONSISTENCIES IN RULE BASES

Elementary exact rule bases may contain external inconsistencies named IEE1 (Inconsistencies of Elementary Exact single bases). External means that the inconsistencies occur between conditions from the list of conditions and the conclusion, i. e. they are external with respect to the list of conditions.

A rule is externally IEE1-self-inconsistent, if the rule conclusion is among its conditions:

rule(Nr,"Conclusion",["Condition_1","Conclusion","Condition_2"], _)

The rules display semaphores are not influencing their inconsistencies,therefore they are omitted.

External IEE1-self-inconsistencies are canonical in this sense, that any other external inconsistency may be reduced to some IEE1-self-inconsistency.

Two rules are externally directly IEE1 inconsistent, if the conclusion of one of them is a condition of the other, which has a conclusion which is the condition of the former:

rule(N_1,"Conclusion_1",["Condition_11","Conclusion_2","Condition_12"],_)

rule(N_2,"Conclusion_2",["Condition_21","Conclusion_1","Condition_22"],_)

If in place of Conclusion_2 the conditions of rule N_2 are introduced into rule N_1, an externally IEE1-self-inconsistent rule is obtained:

rule(N_1,"Conclusion_1",["Condition_11","Condition_21","Conclusion_1",
"Condition_22","Condition_12"],_)

Consider also three rules which are externally inconsistent in a more complicated way:

rule(1,"H",["K","B"],_)

rule(2,"K",["C","D","X"],_)

rule(3,"X",["H","A"],_)

We say that rule n is externally undirectly IEE1 inconsistent with rule m if introducing conditions of rule m to some other rule, conditions of this rule to yet some other rule, etc., we arrive eventually at an externally IEE1-self-inconsistent rule:

rule(1,"H",["C","D","H","A","B"],_)

External inconsistencies are critical in this sense, that their presence may break down the chaining process. Therefore they are automatically detected and diagnosed, while their usage for chaining is blocked.


JOINT INCONSISTENCIES IN RULE- AND CONSTRAINT BASES

Elementary exact rule bases and constraint bases may contain joint inconsistencies, denoted by the abbreviation IEE2 (Inconsistencies of Elementary Exact pairs of bases). Their essence is that - due to constraints - of some rules may have lists of conditions which cannot be made true all at the same time.

As example consider a rule base with the rule:

rule(Nr_rule,"Conclusion",["A","B","C","D"],1)

and its corresponding constraint base with the constraint:

constraint(Nr_co,["A","C"])

The presence of the constraint results in an always false conjunction of the rules condition. I. e. the rule will never be used.

Joint inconsistencies of rule- and constraint bases are not critical. Their presence never causes a break down of the chaining process. They only remove some rules from the rule base.

The detection of joint inconsistencies may be a time-consuming process. This is due to the fact that in order to do it all rules must be flattened in all possible ways. Only then can be tested, whether the mutually exclusive conditions of all constraints form subsets of the conditions of all flattened rules.

Therefore the test for joint rule- and model base inconsistencies is not obligatory.

The test should be used while developing or modifying rule bases. For routine uses of satisfactorily performing rule- and constraint bases the test should be bypassed.


INCONSISTENCIES IN MODEL BASES

A model base is directly inconsistent if it contains an arithmetical model with result equal to one of its arguments, like in this example:

model_b(N,"No condition","Result","A","+","Result",1])

A model base is deeply inconsistent, if it contains an arithmetical model with result equal to the argument of one of the models nested with it. E.g.:

model_b(N,"No condition","Result","A","+","B",1)

model_b(M,"No condition","B","C","*","Result",1)

Inconsistencies of model bases are critical in this sense, that their presence may break down the chaining process. Therefore they are automatically detected and diagnosed, while their usage for chaining is blocked.


JOINT INCONSISTENCIES IN MODEL- AND RULE BASES

A model base is directly inconsistent with a rule base if the former contains a relational model with go-ahead condition equal to the conclusion of a rule, which has as its condition the model conclusion, like e.g.:

model_b(N, "Go-ahead condition", "Model conclusion",
"A","<=","B",1])

rule(M,"Go-ahead condition",["Model conclusion",....],1)

A model base is indirectly inconsistent with a rule base if the former contains a relational model with a go-ahead condition equal to the conclusion of a rule, which is nested with such rule, that has as its condition the model conclusion, like e.g.:

model_b(N, "Go-ahead condition", "Model conclusion",
"A","<=","B",1])

rule(M,"Go-ahead condition",["Condition",....],_)

rule(P,"Condition",["Model conclusion",....],_)

Joint inconsistencies of model- and rule bases are critical in this sense, that their presence may break down the chaining process. Therefore they are automatically detected and diagnosed, while their usage for chaining is blocked.


REDUNDANCIES IN RULE BASES

Elementary exact rule bases may contain redundancies, denoted by the abbreviation REE1 (Redundancies of Elementary Exact single bases). Following REE1 redundancies are distinguished:

    1. REE1_1 redundancies: the rule base contains rules with equal conclusions and the same conditions, like e.g.:

      rule(1,"Y",["A","B","G"],1)

      rule(2,"A",["C","D"],1)

      rule(3,"B",["E","F"],1)

      rule(4,"Y",["C","D","E","F","G"],1)

      where rule 4 has the same conclusion and the same condition like rule 1 after being flattened using rule 2 and 3. It is thus possible to remove either rule 4 or rules 1, 2 and 3 from the rule base. Perhaps removing rule 4 may be a better choice, because rules 2 and 3 are providing additional information about conditions A and B which may be of interest in some case.
    2. REE1_2 redundancies: the rule base contains rules subsumedby other rules, like e.g.:

      rule(1,"W",["A","B","C","D"],1)

      rule(2,"W",["A","B"],1).

      Rule 1 is subsumed by rule 2 because they share the same conclusion and the set of conditions of rule 2 is a subset of the set of conditions of rule 1. Obviously, if rule 1 succeeds, the more general rule 2 succeed as well. Thus rule 1 may be removed from the rule base. If it remains in the rule base, it may well distort the results of chaining, by making the conclusion W dependent upon condition C and D, which as a matter of fact do not influence the truth of W.

Redundancies of rule bases are not critical. Their presence never causes a break down of the chaining process. They may at worst only falsify the conditions for some conclusions.

The detection of rule redundancies may be a time-consuming process. This is due to the fact that in order to do it all rules must be flattened in all possible ways. Only then can be tested, whether flattened rules for the same conclusion contain overlapping sets of conditions.
Therefore the test for rule base redundancies is not obligatory. The test should be performed while developing or modifying rule bases. For routine uses of satisfactorily performing rule bases the test should be bypassed.


JOINT REDUNDANCIES IN RULE- AND CONSTRAINT BASES

Elementary exact rule bases and constraint bases may contain joint redundancies, denoted by the abbreviation REE2 (Redundancies of Elementary Exact pairs of bases). Its essence is that the presence of the constraints makes some rules redundant. As example consider the rules:

rule(1,"Y",["A","B","C"],1)

rule(2,"Y",["A","B","D"],1)

rule(3,"Y",["A","B","E"],1)

which in the presence of the constraint:

constraint(1,["C","D","E"])

are really equivalent to a single rule:

rule(123,"Y",["A","B"],1)

No matter whether C, D or E are true, the truth of A and B is sufficients for Y to be true.

Joint redundancies of rule- and constraint bases are not critical. Their presence never causes a break down of the chaining process. They may simply falsify the chaining results by making some conclusions depend upon unnecessary conditions.

The detection of joint redundancies may be a time-consuming process. This is due to the fact that in order to do it all rules must be flattened in all possible ways. Only then can be tested, whether the mutually exclusive conditions of all constraints appear in flattened rules with the same conclusion.

Therefore the test for joint rule- and model base redundancies is not obligatory.

The test should be done while developing or modifying rule bases. For routine uses of satisfactorily performing rule- and constraint bases the test should be bypassed.


MUTUALLY EXCLUSIVE CONCLUSIONS

We are distinguishing exclusivity of rule conclusions and exclusivity of relational model conclusions:

    1. Exclusivity of rule conclusions
      Often some rules must have conclusions which should be mutually exclusive.

      The exclusivity of rule conclusions must result from the nature of the rules. It cannot be declared in the constraint base; only askable conditions may be declared as exclusive in the constraint base. However, the constraint base is instrumental in making conclusions exclusive.

      Two types of conclusions exclusivity may be distinguished:
      1. Exclusivity to one, meaning that one and only one rule from the set of rules tested may be true at any time.
      2. Exclusivity to none, meaning that none or at most one rule from the set of rules tested may be true at any time.
      To get mutually exclusive rule conclusions, their conditions must be mutually exclusive. This may be achieved:

      a) directly: the said conditions are askable and declared as mutually exclusive in a proper constraint base;
      b) indirectly: the said conditions are unaskable and given as mutually exclusive conclusions of some rules.

      Case 1a) is illustrated by the following example:

      rule(1,"Conclusion_1",["A","B"],_)

      rule(2,"Conclusion_2",["A","not_B"],_)

      rule(3,"Conclusion_3",["not_A","B"],_)

      rule(4,"Conclusion_4",["not_A","not_B"],_)

      constraint(1,["A","not_A"])

      constraint(2, ["B","not_B"])

      Case 2a) is illustrated by the following example:

      rule(1,"Conclusion_1",["A","B","C"],_)

      rule(2,"Conclusion_2",["A","not_B","C"],_)

      rule(3,"Conclusion_3",["not_A","B","C"],_)

      rule(4,"Conclusion_4",["not_A","not_B","C"],_)

      constraint(1, ["A","not_A"])

      constraint(2, ["B","not_B"])

      Case 1b) is illustrated by the following example:

      rule(1,"Conclusion_1",["A","B"],_)

      rule(2,"Conclusion_2",["A","not_B"],_)

      rule(3,"Conclusion_3",["not_A","B"],_)

      rule(4,"Conclusion_4",["not_A","not_B"],_)

      rule(5,"Option_1",["Conclusion_1"],_)

      rule(6,"Option_1",["Conclusion_2"],_)

      rule(7,"Option_3",["Conclusion_3"],_)

      rule(8,"Option_4",["Conclusion_4"],_)

      constraint(1, ["A","not_A"])

      constraint(2, ["B","not_B"])

      Case 2b) is illustrated by the following example:

      rule(1,"Conclusion_1",["A","B","C"],_)

      rule(2,"Conclusion_2",["A","not_B","C"],_)

      rule(3,"Conclusion_3",["not_A","B","C"],_)

      rule(4,"Conclusion_4",["not_A","not_B","C"],_)

      rule(5,"Option_1",["Conclusion_1"],_)

      rule(6,"Option_1",["Conclusion_2"],_)

      rule(7,"Option_3",["Conclusion_3"],_)

      rule(8,"Option_4",["Conclusion_4"],_)

      constraint(1, ["A","not_A"])

      constraint(2, ["B","not_B"])

      The option Knowledge Base Analysis from Main Menu offers some sub-options for analyzing exclusivity of conclusions for chosen rule sets.

    2. Conclusions of relational models
      Sometimes a set of relational models must have exclusive conclusions, which mutually exhaust all feasible values for some common real variable.

      This property may e.g. be useful to discriminate between arithmetical models with equal results by making mutually exclusive their go-ahead conditions. Consider the following example:

      model_b(11,"No condition","Conclusion_1","A","<","-10",1)

      model_e(12,"No condition","Conclusion_2","<=,<",["-10","A","0.0"],1)

      model_e(13,"No condition","Conclusion_3","<=,<=",
      ["0.0","A","10"],1)

      model_b(14,"No condition","Conclusion_4","10","<","A",1)

      model_b(15,"Conclusion_1","Result","AA","+","BB",1)

      model_b(16,"Conclusion_2","Result","CC","+","DD",1)

      model_b(17,"Conclusion_3","Result","EE","+","FF",1)

      model_b(18,"Conclusion_4","Result","GG","+","HH",1)

      Models 11 - 14 have conclusions exclusive to one, which mutually exhaust the set of feasible values for real A. Those conclusions are envisaged to enable a proper choice of arithmetic model from models 15 - 18 with the same result Result. To inform the system about this and to avoid ambiguity with respect to which of the models 15, 16, 17 or 18 to use for calculating Result, the clause:

      exclusive_models(["Conclusion_1","Conclusion_2",
      "Conclusion_3","Conclusion_4"])

      has to be put into the model base. Similarly, consider the example:

      model_b(11,"No condition","Conclusion_1","A","<","-10",1)

      model_e(12,"No condition","Conclusion_2","<=,<",["-10","A","0.0"],1)

      model_e(13,"No condition","Conclusion_3","<=,<=",
      ["0.0","A","10"],1)

      model_b(15,"Conclusion_1","Result","AA","+","BB",1)

      model_b(16,"Conclusion_2","Result","CC","+","DD",1)

      model_b(17,"Conclusion_3","Result","EE","+","FF",1)

      Models 11 - 13 have conclusions exclusive to none, which do not mutually exhaust the set of feasible values for real A. Those conclusions are envisaged to enable a proper choice of arithmetic model from models 15 - 17 with the same result Result. To inform the system about this and to avoid ambiguity with respect to which one of the models 15, 16 or 18 to use for calculating Result, the clause:

      exclusive_models(["Conclusion_1","Conclusion_2","Conclusion_3"])

      has to be put into the model base.

      However, for the case:

      model_b(11,"No condition","Conclusion_1","A","<","-10",1)

      model_e(12,"No condition","Conclusion_2","<=,<",["-20","A","20"],1)

      model_e(13,"No condition","Conclusion_3","<=,<=",
      ["0.0","A","10"],1)

      model_b(15,"Conclusion_1","Result","AA","+","BB",1)

      model_b(16,"Conclusion_2","Result","CC","+","DD",1)

      model_b(18,"Conclusion_3","Result","EE","+","FF",1),

      models 11 and 12 as well as 12 and 13 have no exclusive conclusions: the conclusions Conclusion_1 and Conclusion_2 as well as Conclusion_2 and Conclusion_3 may be simultaneously pairwise true. Such model base may be faulty and this time - because of models 15,...,18 - it is indeed faulty. That is so because the model used to calculate Result depends upon which of the real string variables AA,...,FF have been instantiated first.

      Because the faulty nature of models 11 - 13 depends upon the presence of models 15 - 18, the fault is not automatically diagnosed. It is up to the user to detect and remove it.


MULTIPLE ARITHMETICAL MODELS

The need often arises for arithmetical models calculating the same result, but in a different way for different situations. A sound model base must provide information to the chaining system as to what model should be used when. This may be achieved by a proper choice of go-ahead conditions for those models: these conditions should be mutually exclusive to one or mutually exclusive to none, besides corresponding to the particular situation demanding the use of a particular model. This may be achieved:

    1. Directly: the said go-ahead conditions are askable and declared as mutually exclusive in a proper constraint base.
    2. Indirectly: the said go-ahead conditions are unaskable and given as mutually exclusive conclusions of some rules.
    3. Indirectly: the said go-ahead conditions are unaskable and given as mutually exclusive conclusions of some relational models; for this situation the inference system has to be informed about the exclusiveness using clauses.

      exclusive_models(List_of_exclusive_conclusions).

Case 1 is illustrated by the following example:

model_b(10,"A","Result",_,"Operation_10",_,_)

model_lin(11,"not_A","Result",_,_,_)

constraint(1, ["A","not_A"])

Case 2 is illustrated by the following example:

model_b(10,"Cond_1","Result",_,"Operation_10",_,_)

model_lin(11,"Cond_2","Result",_,_,_)

model_lin(12,"Cond_3","Result",_,_,_)

model_e(13,"Cond_4","Result","Operation_13",_,_)

rule(1,"Cond_1",["A","B"],_)

rule(2,"Cond_2",["A","not_B"],_)

rule(3,"Cond_3",["not_A","B"],_)

rule(4,"Cond_4",["not_A","not_B"],_)

constraint(1,["A","not_A"])

constraint(2,["B","not_B"])

Case 3 is illustrated by the following example:
consider four relational models with conclusions (Conclusion_1, Conclusion_2, Conclusion_3 and Conclusion_4) depending upon the position of the real A on the real axis:

model_b(11,"No condition","Conclusion_1","A","<","-10",1)

model_e(12,"No condition","Conclusion_2","<=,<",["-10","A","0.0"],1)

model_e(13,"No condition","Conclusion_3","<=,<=",["0.0","A","10"],1)

model_b(14,"No condition","Conclusion_4","10","<","A",1)

The said conclusions are mutually exclusive to one and exhaust the set of possible values for A; it means that one and only one conclusion may be true. This may allow to use them for picking one and only one from the following four arithmetical models with the same result:

model_b(15,"Conclusion_1","Result","AA","+","BB",1)

model_b(16,"Conclusion_2","Result","CC","+","DD",1)

model_b(17,"Conclusion_3","Result","EE","+","FF",1)

model_b(18,"Conclusion_4","Result","GG","+","HH",1)

In order for the chaining system to accept the conclusions of models 11 - 14 as mutually exclusive and exhausting the set of possible values for A, it has to be informed with the clause:

exclusive_models(["Conclusion_1","Conclusion_2",
"Conclusion_3","Conclusion_4"])

in the model base. Only then will the chaining system accept the presence in the model base of arithmetical models 15, 16, 17 and 18 with the same Result. If arithmetical models with the same results do not have mutually exclusive go-ahead conditions, the chaining process is blocked.


ELEMENTARY EXACT

RULE- and MODEL-BASED

EXPERT SYSTEM

rmes_EE


This is a CHM File for the Elementary Exact
Rule- and Model-Based Expert System Shell rmes_EE