GENERAL INFORMATION - AUGMENTED EXACT FORWARD CHAINING

GENERAL INFORMATION - AUGMENTED UNCERTAIN FORWARD CHAINING

The augmented uncertain rule- and model-based expert system shell rmes_AU may be used for forward chaining with augmented uncertain knowledge bases. Generally, an Augmented Uncertain Knowledge Base may contain following components:

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

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

    • some rule conclusions may appear in negated form as conditions of other rules, or
    • some rule conclusions may appear in negated form as go-ahead conditions of some models, or
    • some relational model conclusions may appear in negated form as conditions of some rules, or
    • some relational model conclusions may appear in negated form as go-ahead conditions of some models.

Otherwise stated - nesting with negation is feasible.

A rule base is uncertain if:

    • each rule is associated with a certainty factor, and
    • conditions and conclusions are uncertain string variables with includes taking values from the range of certainty factor values, and
    • certainty factors are real numbers from the interval [-1,1].

A model base is uncertain if:

    • each relational model is associated with a certainty factor (CF), and
    • conclusions of relational models are uncertain string variables with includes taking values from the range of certainty factor values, and
    • each arithmetical model is associated with a certainty factor CF=1, and
    • certainty factors are real numbers from the interval [-1,1]

Augmented uncertain forward chaining aims at:

    • determining certainty factors for the conclusions of all rules and relational models, and
    • determining all results of tractable models

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

It should be noted that forward chaining is finding certainty factors for all conclusions and determining all results of tractable models, regardless of whether the user is interested in them or not.


GENERAL INFORMATION - AUGMENTED UNCERTAIN BACKWARD CHAINING

The augmented exact rule- and model-based expert system shell rmes_AU may be used for backward chaining with augmented exact knowledge bases. Generally, an Augmented Uncertain Knowledge Base may contain following components:

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

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

    • some rule conclusions may appear in negated form as conditions of other rules, or
    • some rule conclusions may appear in negated form as go-ahead conditions of some models, or
    • some relational model conclusions may appear in negated form as conditions of some rules, or
    • some relational model conclusions may appear in negated form as go-ahead conditions of some models.

Otherwise stated - nesting with negation is feasible.

A rule base is uncertain if:

    • each rule is associated with a certainty factor, and
    • conditions and conclusions are uncertain string variables with includes taking values from the range of certainty factor values, and
    • certainty factors are real numbers from the interval [-1,1].

A model base is uncertain if:

    • each relational model is associated with a certainty factor (CF), and
    • conclusions of relational models are uncertain string variables with includes taking values from the range of certainty factor values, and
    • each arithmetical model is associated with a certainty factor CF=1, and
    • certainty factors are real numbers from the interval [-1,1]

Augmented uncertain backward chaining aims at determining the certainty factor for a hypothesis declared by the user, for a given knowledge base, for a set of askable conditions with known certainty factors and for a set of askable arguments with known arithmetic values.

The testing is always establishing the certainty factor of the tested hypothesis.

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

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

    • narrow sense hypotheses are given by all 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 all conclusions of all rules and all relational models, no matter whether they are or are not conditions of other rules or go-ahead conditions of models.


AUGMENTED UNCERTAIN RULE BASE

The Augmented Uncertain Rule Base for Knowledge Base KBN is named RUKBN.AUB and contains following clauses:

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

fact("Askable Condition", "Askable_Condition_CF")

and:

disjunctive_rule("Conclusion")

Uncertain augmented rules have following arguments:

    1. Rule_Number is an integer, distinct from other rule numbers and distinct from model numbers;
    2. "Conclusion" is an uncertain string variable corresponding to the name of the rule conclusion.
      E.g. the conclusion "Give credit" means, that Give credit is a uncertain variable for which a certainty factor may be determined.
    3. List_of_Conditions is a list of uncertain string variables, corresponding to names of rule conditions. E.g.: List_of_Conditions =["Condition_1",...,"Condition_n"], where "Condition_i" denotes the uncertain string variable corresponding to the name of Condition_i.
      With any Condition_i is associated its certainty factor CF_Condition_i. It is a real from the interval [-1,1].

      Negation will be denoted using the negation prefix n (small): the negation of an uncertain condition or conclusion A(CF) is thus denoted by nA(-CF): negation reverses the sign of the certainty factor and adds the prefix n to the name of condition or conclusion.
      If the certainty factor of an uskable condition has been dedeclared as CF(Condition), the system automatically asserts the certainty factor for the negated condition CF(nCondition) as:

      CF(nCondition) = -CF(Condition).

      If the certainty factor of a conclusion has been calculated by the expert system as CF(Conclusion), the system automatically asserts the certainty factor for the negated conclusion CF(nConclusion) as:

      CF(nConclusion) = -CF(Conclusion).

      CF_Condition_i=1 indicates that Condition_i is absolutely true. CF_Condition_i=-1 indicates that Condition_i is absolutely false. Intermediate values of Condition_i indicate intermediate degrees of certainty.

      The List_of_Conditions is characterised by its certainty factor:

      CF(List_of_Conditions) =
      Minimum(CF_Condition_1,...,CF_Condition_n)

    4. 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.
    5. "Rule_CF" is an instantiated uncertain string variable with an include equal to the value of the rule certainty factor (e. g. "Rule_CF"="0.5").
      It is declared for the rule while designing the rule base and is interpreted as a measure of certainty attached to the rule. Consider e.g. the following two rules:

      rule(1,"Grant Credit",["Excellent collateral",
      "Excellent reputation"],1,"0.9")

      rule(2,"Grant Credit",["Good collateral","Good reputation"],1,"0.5")

      The difference of Rule_CF values reflects the obviously greater certainty when granting a credit in case rule 1 is resolved as compared with the case when rule 2 is resolved.

The uncertain variable included in the uncertain string variable "Conclusion" has certainty factor CF(Conclusion) determined as follows:

    1. If CF(List_of_Conditions) >= 0 or Rule_CF >= 0 and the rule is disjunctive or if no matter what the signs of CF(List_of_Conditions and Rule_CF) but the rule is cumulative, then it is uncertainly fulfilled and:

      CF(Conclusion) = CF(List_of_Conditions) * Rule_CF.

      This will be called standard rule processing. Thus:
        • Rule_CF=1 indicates that the conclusion is as certain as the list of conditions is; in other words - the conclusion is supported entirely by the certainty of the list of conditions, whatever it may be;
        • Rule_CF=-1 indicates that the conclusion is as uncertain as the list of list of conditions is certain; in other words - the negated conclusion is supported entirely by the certainty of the list of conditions;
        • Intermediate values of Rule_CF indicate intermediate degrees of support.
      The use of positive and negative certainty factors is convenient for modelling conditions which strengthen the certainty of the conclusion as well as conditions that weaken the certainty of the conclusion.
    2. If CF(List_of_Conditions)< 0 and Rule_CF < 0 and the rule is disjunctive, it is discarded. This is so because disjunctive rules with negative Rule_CF values cannot be used to generate conclusions with positive CF values.
    3. If the certainty factor of the conclusion has been determined as CF(Conclusion), the system automatically asserts the certainty factor for the negated conclusion CF(nConclusion) as:

      CF(nConclusion) = -CF(Conclusion);

For augmented uncertain chaining the CF values for all conclusions are displayed, no matter whether their CF is positive or negative.

Clauses of the form:

fact("Askable_Condition", "CF_Askable_Condition")

have the following meaning: "Askable_Condition" is an uncertain string variable corresponding to the name of some askable condition, for which the certainty factor CF_Askable_Condition is declared beforehand, because it does not change for a number of expert consultations. The user is thus freed from the task of declaring the values of certainty factors for some askable condiions each time a new consultation is done.

Clauses of the form:

disjunctive_rule("Conclusion")

are used to inform the expert systems, that there is a number of rules with the same Conclusion and dependent lists of conditions. Therefore all conclusions should have their CF calculated, but only the CF of one of those conclusions would be considered as overall CF for all conclusions, see 4.Certainty Factor Algebra.

By default, all rules (including rules with unique conclusions) which have not been declared as disjunctive, are considered to be cumulative.

If the need arises for using a negated conclusion as condition of some rule, the negated conclusion need not be defined by separate rules, but just by prefixing the conclusion with the letter n . E.g. consider the rule:

rule(1,"Going for a holiday abroad",["Got leave of absence",
"Can afford it financially"],1,"CF_1")

and the rule using the negation:

rule(2,"Rising of level stress",["nGoing for a holiday abroad"],1,"CF_2")

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 uncertain string variables. No prior declaration of all attributes is needed.

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

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

Thus, in contrast to elementary uncertain rule bases, for augmented rule bases nesting may be accompanied by negation. Implicit negation as used for elementary uncertain bases, is also feasible for augmented uncertain bases. Its application as exemplified below for rules:

rule(1,"Going for a holiday abroad",["Got leave of absence",
"Can afford it financially"],1,"CF_1")

rule(2,"Rising of level stress",["Going for a holiday abroad"],1,"CF_2")

where obviously CF_1 > 0 and CF_2 < 0, could be made more readable by expressing it like this:

rule(1,"Going for a holiday abroad", ["Got leave of absence",
"Can afford it financially"],1,"CF_1")

rule(2,"Rising of level stress",
["nGoing for a holiday abroad"],1,"CF_2"),

this time with CF_1 > 0 and CF_2 < 0. 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 certainty factors for any askable condition found while chaining.
    2. Unaskable conditions are those conditions, which are conclusions of some rules or relational models. Certainty factors of unaskable conditions result from chaining done by the expert system.

The chaining always starts with presenting askable conditions and their CF values as declared in the rule base using fact(_,_) clauses, if any.

If some askable conditions are neither declared using fact(_,_) clauses nor related through 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 values of the certainty factors for those conditions.

Each Knowledge Base must contain a Rule Base. If the entire domain knowledge resides in the model base, the rule base must contain a single trivial rule like this:

rule(0," ",["no condition"],0,"1")

The Display Semaphore equal 0 assure, that this "rule" will not be quoted while chaining.


CERTAINTY FACTOR ALGEBRA

To calculate certainty factors for conclusions, a modified Stanford Certainty Factor Algebra is used.

The following assumptions are made:

    1. Each rule has a rule certainty factor CF_rule, which is a real from the range [-1, 1]. It is a measure if the rule certainty.
    2. The user must declare for any askable Condition its certainty factor CF_Condition, which is a real from the range [-1, 1]. It is a measure of the certainty of condition being true (CF_Condition>0) or false (CF_Condition<0).
    3. The user must declare for any Conclusion of a resolved relational model a positive value of certainty factor CF_Conclusion, which is a measure of the extent, to which the Conclusion is true.
    4. The user must declare, for any Conclusion of an unresolved relational model, a positive value of certainty factor for the conclusion nConclusion of aN inverse relational model, from which the original certainty factor is calculated as:

      CF(Conclusion) = - CF(nConclusion)

Following operations are defined:

    1. Certainty Factor for a list of conditions:
      Let:

      List_of_Conditions =
      ["Condition_1",..,"Condition_i",..,"Condition_n"]

      with conditions having certainty factors:

      CF_Condition_1,...,CF_Condition_i,...,CF_Condition_n

      The overall certainty factor for the list of conditions is give by the smallest certainty factor of conditions from the list:

      CF(List_of_Conditions) =
      Minimum(CF_Condition_1...,Condition_i_CF,...,CF_Condition_n)

      This is sometimes referred to as chain rule: the chain strength is determined by its weakest link.
    2. Certainty Factor for a single rule:
      • If CF(List_of_Conditions) >= 0 or Rule_CF >=0 and the rule is disjunctive or the rule is cumulative with any signs of CF(List_of_Conditions) and Rule_CF, then the certainty factor for the conclusion is given by the product:

        Conclusion_CF = CF(List_of_Conditions) * Rule_CF

        This establishes the meaning of a single uncertain rule:
        the Conclusion is true with certainty factor Conclusion_CF. If Conclusion_CF>0, the rule is said to be uncertainly resolved. If Conclusion_CF<=0, the rule is said to be uncertainly unresolved.
      • If List_of_Conditions_CF < 0 and Rule_CF < 0 for a disjunctive rule, the rule will not be accounted for in subsequent chaining.

    3. Rules with the same conclusion:
      If there are two or more rules sharing the same conclusions, they should be designed in one of the following ways only: either as cumulative rules or as disjunctive rules:

      1. Cumulative rules are rules with only independent lists of conditions. Independency in lists of conditions means that their certainty factor may have any feasible values. E. g.:

        rule(1,"Promotion to Headquarters", ["IQ>100"],"0.4")

        rule(2,"Promotion to Headquarters",
        ["Excellent sales"],"0.7")

        The two lists of conditions are clearly independent: there is no iunctim between the managers intelligence quotient and his/her sale performance. Therefore both factors contribute to the certainty of the promotion and both rules must be taken into account.In other words - the certainty factor for "Promotion to Headquarters" is cumulated from both rules.

        Any rule with a unique conclusion is considered to be a special case of cumulative rules. Obviously such rule is processed in the same manner as cumulative rules.

      2. Disjunctive rules have only dependent lists of conditions. Dependency in lists of conditions means that their certainty factors may not have any feasible values. E. g.:

        rule(4,"Financial accomplishments",
        ["Huge profit"],1,"0.5")

        rule(5,"Financial accomplishments",
        ["Large profit"],1,"0.4")

        rule(6,"Financial accomplishments",
        ["Small profit"],1,"0.2")

        rule(7,"Financial accomplishments",
        ["Losses"],1,"-0.8")

        The four lists of conditions are clearly dependent: if the profit is very large, it is not large neither small and there are no losses. On the other hand, we may have CF(Losses)>0, and CF(Huge profit)=-1, CF(Large profit)=-1 and CF(Small profit)=-1; but we cannot have CF(Losses)>0, CF(Huge profit)>0, CF(Large profit)>0 and CF(Small profit)>0.

      It should be emphasized, that:
      • using rules with shared conclusion, which are neither cumulative nor disjunctive, leads to incorrect chaining;
      • any rules with shared conclusions may always be designed as either cumulative or disjunctive, perhaps by introducing auxiliary rules, see e.g. the transition from the e knowledge base.

    4. The overall certainty factor for the shared conclusion Conclusion of two cumulative rules is obtained by a process called cumulation. It is performed as follows:
      • If for two cumulative rules:

        rule(1, "Conclusion", List_of_Conditions_1, Rule_CF_1)

        rule(2, "Conclusion", List_of_Conditions_2, Rule_CF_2)

        the certainty factors for the conclusions are equal respectively CF_1_Conclusion>0 and CF_2_Conclusion>0, the overall certainty factor for the shared conclusion is given by the acumulation formula:

        CF_Conclusion = CF_1_Conclusion + CF_2_Conclusion - CF_1_Conclusion * CF_2_Conclusion

        That means that a positive CF for the conclusion from any rule is increasing the overall certainty factor of the conclusion. However, due to the the subtraction of the product CF_1_Conclusion * CF_2_Conclusion the overall certainty factor CF_Conclusion is never larger than 1.
      • If for two cumulative rules:

        rule(1, "Conclusion", List_of_Conditions_1, Rule_CF_1)

        rule(2, "Conclusion", List_of_Conditions_2, Rule_CF_2)

        the certainty factors for the conclusions are respectively CF_1_Conclusion<0 and CF_2_Conclusion<0, the overall certainty factor for the shared conclusion is given by the acumulation formula:

        CF_Conclusion = CF_1_Conclusion + CF_2_Conclusion + CF_1_Conclusion * CF_2_Conclusion

        That means that a negative CF for the conclusion from any rule is decreasing the overall certainty factor of the shared conclusion. However, due to the the addition of the product CF_1_Conclusion * CF_2_Conclusion the overall certainty factor CF_Conclusion is never smaller than
        -1.
      • If for two cumulative rules:

        rule(1, "Conclusion", List_of_Conditions_1, Rule_CF_1)

        rule(2, "Conclusion", List_of_Conditions_2, Rule_CF_2)

        the certainty factors for the conclusions are equal respectively CF_1_Conclusion>0 and CF_2_Conclusion<0, the overall certainty factor for the common conclusion is given by the acumulation formula:

        CF_Conclusion =
        (CF_1_Conclusion + CF_2_Conclusion)/
        [1-min(|CF_1_Conclusion|,|CF_2_Conclusion|)]

        That means that for large certainty the influence of a newly appearing small uncertainty is small, whereas for large uncertainty the influence of a newly appearing small certainty is also small, which is what we intuitively expect.
      • If for two cumulative rules:

        rule(1, "Conclusion", List_of_Conditions_1, Rule_CF_1)

        rule(2, "Conclusion", List_of_Conditions_2, Rule_CF_2)

        the certainty factors for the conclusions are equal respectively CF_1_Conclusion=1 and CF_2_Conclusion=-1, the overall certainty factor for the shared conclusion is equal to:

        CF_Conclusion = 0

        This is also plausible: if the strength of arguments for something is eqaul to the strength of arguments against that something, we better abstain from judgment.
      • The overall certainty factor for the common conclusion Conclusion of more than two cumulative rules with equal conclusions having CF of the same sign is determined as follows: any two of them are cumulated into CF_1_2 using the proper cumulation formula; next the cumulated CF_1_2 is cumulated in turn with the certainty factor for the third conclusion, and so on.
      • If certainty factors for the shared conclusions of more than two cumulative rules have different signs, then:
        • all positive certainty factors are acumulated into CF_plus;
        • all negative certainty factors are acumulated into CF_minus
        • finally, CF_plus and CF_minus are acumulated into the overall certainty factor for the common conclusion.

        This assures a unique overall certainty factor the common conclusion, no matter what is the order of cumulating positive and cumulating negative certainty factors.

    5. The overall certainty factor for the common conclusion of two disjunctive rules is determined as follows:
      • As already mentioned , disjunctive rules with non-positive certainty factors, for which the certainty factor of the list of conditions is established as non-positive, are not accounted for in subsequent chaining. This will be referred to as principle of CF positivity. This principle is best justified by referring to the already discussed set of disjunctive rules:

        rule(4,"Financial accomplishments",
        ["Huge profit"],1,"0.5")

        rule(5,"Financial accomplishments",
        ["Large profit"],1,"0.4")

        rule(6,"Financial accomplishments",
        ["Small profit"],1,"0.2")

        rule(7,"Financial accomplishments",
        ["Losses"],1,"-0.8")

        If CF(Losses)=-1, CF(Small profit)=0.3, CF(Large profit)=-1 and CF(Huge profit)=-1, then CF(Financial accomplishments) must necessarily be determined bu rule 3 as equal 0.06, and not be rule 4 as equal 0.8.
        In other words: the disjunctive rule with negative CF_rule may not be used to generate positive certainty factors for the common conclusion, but only to generate negative certainty factors for this conclusion.
      • If for disjunctive rules which have not been skiped as the result of applying the principle of CF positivity, the certainty factors for their lists of conditions are of the same sign, the shared conclusion gets the greatest certainty factor of all conclusions determined by the set of disjunctive rules.
        This is illustrated by the following examples:

        Example 1:

        rule(2,"Concl",["A"],1,"0.9") --> CF("Concl")=0.63

        rule(3,"Concl",["B","C"],1,"0.8") --> CF("Concl")=0.64

        rule(4,"Concl",["D"],1,"0.6") --> CF("Concl")=0.3

        disjunjctive_rule("Concl")

        fact("A","0.7")

        fact("B","0.8")

        fact("C","0.9")

        fact("D","0.5")

        All rule conclusions have positive CF values, the maximum is equal 0.64 for rule 3; Therefore the overall certainty factor CF(Concl)=0.64.

        Example 2:

        rule(2,"Concl",["A"],1,"0.9") --> CF("Concl")=0.63

        rule(3 "Concl",["B", "C"],1,"0.8") --> CF("Concl")=0.63

        rule(4 "Concl",["D"],1,"0.6") --> CF("Concl")=0.63

        disjunjctive_rule("Conc")

        fact("A","-0.7")

        fact("B","-0.8")

        fact("C","-0.9")

        fact("D","-0.5")

        All rule conclusions have negative CF values, the maximum is equal -0.3 for rule 3; Therefore the overall certainty factor CF(Concl)=-0.3.

        Example 3 is less abstract and refers to the rule base RUCRE.EUB:

        rule(26,"Bad collateral",
        ["I-class collateral (%)<60"],1,"0.9")

        rule(27,"Bad collateral",
        ["I-class collateral (%)<70",
        "II-class collateral (%)<10"],1,"0.7")

        rule(28,"Bad collateral",
        ["I-class collateral (%)<70",
        "III-class collateral (%)<30"],1,"0.7")

        rule(29,"Bad collateral",
        ["I-class collateral (%)<100",
        "II-class collateral (%)<30",
        "III-class collateral (%)<30"],1,"0.4")

        disjunjctive_rule("Bad collateral")

        If e.g.:

        I-class collateral (%) = 50

        II-class collateral (%) = 5

        III-class collateral (%) = 20

        then for all rules is CF(Bad collateral)>0 and the CF value for the shared conclusion will be equal to the largest CF values for all those conclusions.

        If on the other hand:

        I-class collateral (%) = 80

        II-class collateral (%) = 35

        then for all rule is CF(Bad collateral)<0 and the CF value for the common conclusion will also be equal to the largest CF values for all those conclusions.
      • If for disjunctive rules, which have not been skiped as the result of applying the principle of CF positivity, the certainty factors for their lists of conditions are of different signs, the overall certainty factor is given by the certainty factor of the conclusion for the rule, which has the greatest certainty factor among all rules with positive certainty factors of their lists of conditions. This is illustrated by the following example:

        Example 1:

        rule(4,"Financial accomplishments",
        ["Huge profit"],1,"0.5")

        rule(5,"Financial accomplishments",
        ["Large profit"],1,"0.4")

        rule(6,"Financial accomplishments",
        ["Small profit"],1,"0.2")

        rule(7,"Financial accomplishments",
        ["Losses"],1,"-0.8")

        disjunctive_rule("Financial accomplishments")

        fact("Huge profit","-1")

        fact("Large profit","-1")

        fact("Small profit","-1")

        fact("Losses","0.6")

        It follows from rules:

        rule 1 --> CF(Financial accomplishments) = –0.5

        rule 2 --> CF(Financial accomplishments) = –0.4

        rule 3 --> CF(Financial accomplishments) = –0.2

        rule 4 --> CF(Financial accomplishments) = –0.48

        Rule 4 is the only rule with positive positive certainty factor of the list of conditions. It follows that:

        CF(Financial accomplishments) = –0.48

        The result may be justified hAUristicall: we have losses, so the cartainty factor for Financial accomplishments should be determined by rule 4 only.

    6. To inform the expert systems that rules with shared conclusion are disjunctive, the clauses disjunctive_rule("Conclusion") are used. By default, all rules with shared conclusion not pinpointed by disjunctive_rule() clauses, are considered to be cumulative.

    7. The certainty factor for a negated askable condition is equal to the complement to zero of the certainty factor for the non-negated askable condition:

      CF("Negated Askable condition") = - CF("Askable condition")

    8. The results for overall certainty factors are rounded and truncated to get no more than 2 figures after the decimal point. This is justified by the fact that original certainty factors for askable conditions and rules, resulting from rather crude "measurements", are seldom declared with more than one figure after the decimal point.


AUGMENTED UNCERTAIN MODEL BASE

The Augmented Uncertain Model Base for Knowledge Base NBW is named MONBW.AUB and may contain augmented basic models, augmented extended models, laugmented inear models, augmented polynomial models, askable argument values and true go-ahead conditions with CF > 0.

An augmented uncertain 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 augmented uncertain models:

    • Model_Number is an integer, distinct from other model numbers and distinct form rule numbers;
    • "Go-Ahead Condition" is an uncertain string variable, controlling the model usage. The model may be used (i.e. the values of Result/Conclusion may be determined) only if:
        • CF(Go-Ahead Condition) > 0 or if
        • "Go-Ahead Condition" = "No condition"
      The Go-Ahead Condition is then said to be satisfied. Otherwise it is considered unsatisfied.
      Go-Ahead Conditions different from No condition are applied always for multiple models, to indicate the particular situations for which their use is suitable. Go-Ahead Conditions different from No condition must not be used for singular models, because it may brake the chaining process.

      Go Ahead Conditions may be direct or 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.

Models for augmented uncertain model bases differ from those of elementary uncertain model bases:

    • nesting with negation is allowed;
    • for any resolved relational model the certainty factor CF(Conclusion) for the conclusion is determined by the user, but the certainty factor for the negated conclusion CF(nConclusion) is determined by the system as:

      CF(nConclusion) = -CF(Conclusion);

    • for any unresolved relational model the user is asked to determine the certainty factor for the negated conclusion CF(nConclusion) (in the now resolved negated relation), which is used by the system to determine the certainty factor for the original non-negated conclusion CF(Conclusion) as

      CF(Conclusion)) = -CF(nConclusion).

Augmented uncertain models may be characterised as follows:

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

    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,"CF_Model")

      where:
      • "Result"/"Conclusion" is:
        • a real string variable "Result" for arithmetical models;
        • an uncertain 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, 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: ">", "==", "<", ">=", "<=", "><", "<>";
      • CF_Model is:
        • the integer 1 for arithmetical models;
        • a string corresponding to the name of the model certainty factor for relational models.
        For a basic relational model CF_Model is a measure of the extent the relation is fulfilled. Because for basic relational models it is usually difficult if not impossible to estimate beforehand (while designing a model base) the extent the relations will eventually be fulfilled in the chaining process, the include for "CF_Model" is always a variable name, to be properly instantiated in the chaining process by the user.

        This is done as follows:
        • for a resolved Go-Ahead Condition and resolved Relation, the Conclusion is associated with positive value of CF_Model>0, declared by the user in the process of chaining. The value is a measure of the extent to which the user considers the relation to be fullfiled;
        • for a resolved Go-Ahead Condition and unresolved Relation, the user is asked to declare a positive value CF(nConclusion)>0 for the fulfiled negated conclusion nConclusion. The original Conclusion is made automatically equal to the negative value of the declared CF(nConclusion):

          CF(Conclusion) = - CF(nConclusion).

      The meaning of the basic model is as follows:
      • for an arithmetical model with two arguments, provided the Go-Ahead Condition is resolved, 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 resolved and Second_Argument = 0, a Result is determined 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 resolved, a certainty factor for the Conclusion is generated which corresponds to the uncertain relation between both arguments:
          • if the Relation is true, the conclusion has the certainty factor equal to the positive value of CF_Model declared then by the user;
          • if the Relation is false, a certainty factor for the negated conclusion is declared by the user and the certainty factor for the original conclusion is automatically made equal to the negative of the former;
      • if for any singular model the Go-Ahead Condition is different from No condition and is not satisfied, the chaining process is interrupted;
      • if for any multiple model the Go-Ahead Condition is different from No condition and is not satisfied, the model is bypassed in the chaining process.

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

    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,"CF_Model")

      where:
      • "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;
      • CF_Model is:
        • the integer 1 for arithmetical models;
        • a string corresponding to the name of the model certainty factor for relational models.
        For an extended relational model CF_Model is a measure of the extent the relation is fulfilled. Because for extended relational models it is usually difficult if not impossible to estimate beforehand (while designing a model base) the extent the relations will eventually be fulfilled in the chaining process, the include for "CF_Model" is always a variable name, to be properly instantiated in the chaining process by the user.

        This is done as follows:
        • for a resolved Go-Ahead Condition and resolved Relation, the Conclusion is associated with positive value of CF_Model>0, declared by the user in the process of chaining. The value is a measure of the extent to which the user considers the relation to be fullfiled;
        • for a resolved Go-Ahead Condition and unresolved Relation, the user is asked to declare a positive value CF(nConclusion)>0 for the fulfiled negated conclusion nConclusion. The original Conclusion is made automatically equal to the negative value of the declared CF(nConclusion)is made automatically equal to the negative value of the declared CF(nConclusion):

          CF(Conclusion) = - CF(nConclusion).

      The meaning of the extended model is as follows:
      • for an arithmetical model, provided the Go-Ahead Condition is fulfilled, 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 model, provided the Go-Ahead Condition is resolved, a certainty factor for the Conclusion is generated which corresponds to the uncertain relation between both arguments:
          • if the Relation is true, the Conclusion has the certainty factor equal to the positive value of CF_Model declared then by the user;
          • if the Relation is false, a certainty factor for the negated Conclusion is declared by the user and the certainty factor for the original conclusion is automatically made equal to the negative of the former;
      • if for any singular model the Go-Ahead Condition is different from No condition and is not satisfied, the chaining process is interrupted;
      • if for any multiple model the Go-Ahead Condition is different from No condition and is not satisfied, the model is bypassed in the chaining process.

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

    3. Clauses for linear models are of the form:

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

      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 the linear model is as follows:
      • provided the Go-Ahead Conditionn is fulfilled, all Coefficients and all Variables have been instantiated, a Result is generated with certainty factor 1 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 for any singular linear model the Go-Ahead Condition is different from No condition and is not satisfied, the chaining process is interrupted;
      • if for any multiple linear model the Go-Ahead Condition is different from No condition and is not satisfied, the model is bypassed in the chaining process.

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

    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,"1")

      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 the polynomial model is as follows:
      • provided the go-ahead condition is fulfilled, the polynomial variable and all coefficients have been instantiated, a result is generated a result is generated with certainty factor 1 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]
      • if for any singular polynomial model the Go-Ahead Condition is different from No condition and is not satisfied, the chaining process is interrupted;
      • if for any multiple polynomial model the Go-Ahead Condition is different from No condition and is not satisfied, the model is bypassed in the chaining process.
------------------------------------------------------------------------------------

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 or negated conclusions of some relational models may serve as go-ahead conditions of other models, or
    • conclusions or negated conclusions of some relational models may serve as conditions of rules, or
    • conclusions or negated conclusions of some rules may serve as go-ahead-conditions of models.

Hence augmented model base nesting may be accompanied by negation: any conclusion of a relational model may 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 uncertain 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. Certainty factors of unaskable go-ahead conditions result from chaining done by the expert system. The expert system considers the No condition unaskable go-ahead condition as having always CF>0.

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 uncertain 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 certainty factors 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","CF_Askable_Go-Ahead Condition")

where Askable go-ahead condition is considered to be true with certainty factor CF_Askable_Go-Ahead Condition.

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 certainty factors 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 fullfiled) or exclusive to none (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])

A detailed explanation is provided in 28. Mutually exclusive conclusions.


AUGMENTED EXACT CONSTRAINT BASE

The Augmented Exact Constraint Base for knowledge base KBN is named ECKBN.AUB 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, but not necessareily distinct from rule numbers and model numbers;
      • List_of_Askable_Exact_Collectively_Exhaustive_Conditions is a list of exact string variables corresponding to exact 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 exact, mutually exclusive and completely exhaustive for the attribute Age. Obviously, only one of the above askable exact conditions may have certainty factor equal to 1, the remaining ones must have certainty factors equal to -1.

The adjective augmented means that no negated conditions (with n prefix) may be used in those bases.

The purpose of Exact Constraint Bases is twofold:

    1. To facilitate the declaration of sets of askable exactly mutually exclusive conditions. If we need askable conditions that may be either true (i.e. CF=1) or false (i.e. CF = -1), we have to define them using exact constraint bases. This applies also to pairs of dichotomous conditions, e.g.:

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

      Askable uncertain conditions which may be either true or false should rather not be handled using the n prefix, e.g. for constructs like Getting leave of absence and nGetting leave of absence. If we opt for such constructs, we run the risk of associating the variables (as result of users lack of attention) with CF values from the entire range [-1,...,1].
    2. To prevent the expert system from asking questions about the truth of conditions, that may be inferred from answers already given.

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

If an augmented exact constraint base was loaded the user is asked to declare certainty factors for all conditions of all augmented exact constraint bases at the beginning of chaining, unless this was done using fact(_,_) clauses.


AUGMENTED UNCERTAIN CONSTRAINT BASE

The Augmented Uncertain Constraint Base for knowledge base KBN is named UCKBN.AUB and contains clauses of the form:

constraint_u(Constraint_number,
List_of_Askable_Uncertain_Collectively_Exhaustive_Conditions)

where:

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

Example:

constraint_u(1,["Excellent health","Good health",
"Satisfactory health","Poor health"])

The askable conditions Excellent health, Good health, Satisfactory health and Poor health are uncertainly mutually exclusive and completely exhaustive for the attribute Health. Obviously, only one of the askable conditions in the list may get the largest certainty factor, the remaining having smaller cartainty factors: although all conditions are uncertain, usually one of them must be less uncertain than all the others.

The purpose of Uncertain Constraint Bases is twofold:

    1. To make the user aware to the spectre of uncertain askable conditions which are exclusive in an uncertain way.
    2. To define pairs of dichotomous uncertain askable conditions. E.g. the uncertain constraint:

      constraint_u(2,["Good reputation","Bad reputation"])

      informs the expert system, that the uncertain askable condition Bad reputation is the negation of the uncertain askable condition Good reputation and vice versa. It means that:

      CF(Bad reputation) = - CF(Good reputation)

      The declaration of a CF certainty factor value for one of the pair of dichotomous uncertain conditions associates the other condition automatically with a negative certainty factor value -CF.

Loading a proper uncertain constraint base is not necessary in order to proceed with chaining for a loaded uncertain rule base. However, with no uncertain constraint base:

    • the user may have doubts about the spectre of options available for uncertain askable conditions to choose from;
    • the chaining may be irritating because of some unnecessary questions being asked.


AUGMENTED UNCERTAIN GRAPHICS BASE

The Augmented Uncertain Graphics Base for knowledge base KBN is named GRKBN.AUB and contains clauses of the form:

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

ngraphics(Rule/Model_Number,"Name_of_nGraphics_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.
    • Name_of_Graphics_for_Rule/Model.bmp is the name of the relevant graphics file displayed when CF(Conclusion) > 0 for the rule or relational model.
    • Name_of_nGraphics_for_Rule/Model.bmp is the name of the relevant graphics file displayed when CF(Conclusion) < 0 for the rule or relational model.

The user may or may not accept the proposal to display the graphics.

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 and one ngraphics file from the corresponding Graphics Subirectory. Rules and relational models with no associated graphics files are acceptable.


AUGMENTED UNCERTAIN SOUND BASE

The Augmented Uncertain Sound Base for knowledge base KBN is named SOKBN.AUB and contains clauses of the form:

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

nsounds(Rule/Model_Number,"Name_of_nSound_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.
    • Name_of_Sound_for_Rule/Model.wav is the name of the relevant sound file played when CF(Conclusion) > 0 for the rule or relational model.
    • Name_of_nSound_for_Rule/Model.wav is the name of the relevant sound file played when CF(Conclusion) < 0 for the rule or relational model.

The user may or may not accept the proposal to play the sound.

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 model may by associated with at most one sound file and one nsound file from the corresponding Sounds Subirectory. Rules and 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 uncertain regulatory knowledge (uncertain rules, uncertain askable conditions) must be embedded into the uncertain rule base and uncertain constraint bases;
    • all uncertain relational knowledge (inequality and equality relations) must be embedded into the uncertain model base.
    • all exact factual knowledge (exact askable conditions) must be embedded into the exact constraint base.
    • all exact procedural knowledge (arithmetical operations) must be embedded into the uncertain model base. <


AUGMENTED UNCERTAIN ADVICE BASE

The Augmented Uncertain Advice Base for knowledge base KBN is named ADKBN.AUB 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 associated with the relevant advice file.
    • Name_of_Advice_for_Rule/Model.HLP is a string pointing at the advice file containing the advice message.

Because the advice for any rule or relational model depends necessarily upon the certainty factor of the conclusion, advices usually contain many options for different certainty value intervals. The advices are therefore not presented on the fly, but only after the chaining is finished, as a result of the user choosing the conclusion of the rule or relational model, for which the advice is needed, from a special Advice menu.

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

Each rule and each relational model may by associated with at most one advice file from the corresponding Advices Subirectory. Rules and relational models with no associated advice files are acceptable: loading a proper advice base is not necessary in order to proceed with chaining. Obviously, in such case no advice will be offered to the user.


ADVICE TEXT FILES

body>

ADVICE TEXT FILES

To each Knowledge Base named KBN may by assigned an Advices Subdirectory 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 Advices Subdirectory 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 Uncertain 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 augmented uncertain rule bases, model bases, exact constraint bases, uncertain 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, EC, UC, AD , GR, SO) with the proper knowledge base name KBN and the extension AUB (Augmented Uncertain Base).

Thus Augmented Uncertain Rule Bases names have the general form:
RUKBN.AUB,

Augmented Uncertain Model Bases:
MOKBN.AUB,

Augmented Exact Constraint Bases:
ECKBN.AUB,

Augmented Uncertain Constraint Bases:
UCKBN.AUB,

Augmented Uncertain Advice Bases:
ADKBN.AUB,

Augmented Uncertain Graphics Bases:
GRKBN.AUBB,

and Augmented Uncertain Sound Bases:
SOKBN.AUB.

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

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 .\ABSTRACTS\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 Uncertain 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 Uncertain Rule Base/Rule Base Editing, Uncertain Modele Base/Modele Base Editing, Exact Constraint Base/Constraint Base Editing option and Uncertain 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 augmented uncertain 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 Uncertain Rule Base,load the faulty base and remove the fault.

    2. If there are no syntax errors, a mandatory check for external IAU1-inconsistencies i.e. for rules with conclusions inconsistent with their conditions, is performed. The detection of IAU1-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 Uncertain Rule Base has to be chosen.

      If there are no external IAU1-inconsistencies, a mandatory check is performed for internal IAU1-inconsistencies i.e. for rules with inconsistent conditions. Internal inconsistencies are not critical critical: their presence does not lead to a break down the chaining process, but simply creates havoc in the chaining process. Therefore chaining with internally inconsistent rules is blocked.
    3. If there are no syntax errors and IAU1-inconsistencies, an optional check for RAU1-redundancies (redundant rules, subsumed rules) may be performed.

      The detection of RAU1-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, redundancy 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 IAU1-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 accepted by the expert system shell rmes_AU 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.

    7. 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 as well.

    8. 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.

    9. 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.

    10. If the model base has been successfully loaded or no model base loading has been requested, the exact constraint base may be loaded and formal checks on exact constraint base syntax are performed. If the exact constraint base syntax is OK, checks are performed to confirm the askability of all conditions of the exact constraint base. If a unaskable condition is found in the exact constraint base, a message pinpointing the error in the 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 exact 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.

    11. If everything is O.K. up to this moment, a test for joint rule- and constraint-based IAU/E2-inconsistency (Inconsistency of Augmented Uncertain/Exact pairs of bases) is proposed. This is a test which discovers exact constraints which make some rules internally inconsistent by constraining some of their conditions to be mutually exclusive. Joint inconsistencies of augmented uncertain rule- and exact constraint bases are not critical, i.e. they do not lead to a breakdown of the chaining process. They may however lead to unexpected outcomes. Therefore farther use of knowledge bases with joint inconsistencies of rule- and constraint bases is blocked.
    12. Next, checks for joint rule-constraint base RAU/E2-redundancies are proposed, i.e. for exact constraints, which make some rules redundant. Joint redundancies of augmented uncertain rule- and exact constraint bases are not critical, i.e. they do not lead to a breakdown of the chaining process. 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.

    13. If the exact constraint base has been successfully loaded or no exact constraint base loading has been requested, the uncertain constraint base may be loaded and formal checks on uncertain constraint base syntax are performed. If the uncertain constraint base syntax is OK, checks are performed to confirm the askability of all conditions of the exact constraint base. If an unaskable condition is found in the uncertain constraint base, a message pinpointing the error in the 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.

    14. This is followed by a test for inconsistency in Augmented Uncertain/Uncertain pairs of bases. This is a test which discovers uncertain constraints which make some rules internally inconsistent by constraining some of their conditions to be mutually exclusive. The test is obligatory for the the same reasons as in case of exact constraint bases. The eventual detection of IAU/U2-inconsistencies is blocking further base loading and chaining.

    15. Next, checks for rule- and uncertain constraint base RAU/U2-redundancies are proposed, i.e. for uncertain constraints, which may 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 RAU/U2-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. The test serves most often to prompt the user to some unusual construct in the bases.

    16. 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.

    17. 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 Uncertain Rule Base menu.

    18. 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 arguments: 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 Uncertain Model Base.

    19. 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",["nCondition_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 the flattened with rules m and n:

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

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

This is obvious because nCondition_i1 may have CF>0 in one of the following two non-exclusive cases:

    1. If nCond_m1 has CF>0, or
    2. if nCond_m2 has CF>0.

Even if there are no negated unaskable conditions, a single rule may be flattened in many ways. Consider the rule:

rule(i,"Conclusion_i", ["nCondition_i1","Warunek_i2"],_,_)

together with rules:

rule(m, "Condition_i2", ["Condition_m1","Condition_m2"],_,_)

rule(n, "Condition_i2", ["Condition_n1","Condition_n2"],_,_)

which have only askable conditions. The flattening of rule i may be done in two ways:

rule_flattened(i,"Conclusion_i",["nCondition_i1","Condition_m1",
"Condition_m2"],[m])

rule_flattened(i,"Conclusion_i",["nCondition_i1","Condition_n1",
"Condition_n2"],[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 augmented uncertain rule bases flattened rules are useful for:

    • detecting and diagnosing rule internal inconsistencies;
    • 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

Augmented uncertain 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 augmented uncertain expert systems may be of uncertain, real or integer type. Augmented uncertain expert systems do not support logical string variables. If the need for such variables arises, it has to be fulfilled by a proper use of 1 and -1 values of certainty factors as well as exact constraint bases.

    1. Uncertain string variables
      The include for any uncertain string variables presents always the name of the uncertain variable. An uncertain variable may be uninstantiated or instantiated with any certainty factor value from the range [-1,1]. E.g. the string variable "Good English" is an uncertain string variable, because the certainty of the condition Good English may be qualified by associating it with a certainty value from the range [-1,1]. An askable uncertain variable may be uninstantiated or instantiated with a certainty factor value. The instantiation is done using the clause fact(_,_).

      Uncertain string variables are handled in following ways:
      1. If the include of an askable uncertain string variable is uninstantiated, the expert system will - at a proper instant of chaining - ask the user about its certainty factor.
      2. If the include of an askable uncertain string variable is instantiated with the clause fact(_,_), the expert system will ask no question, but simply use it for some model.
      3. If the include of an unaskable uncertain string variable is yet uninstantiated, the expert system will determine its logical value using proper rules in the chaining process.
      4. If the include of an unaskable uncertain string variable has been instantiated, with the clause fact(_,_), 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_AU 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 exact constraint bases:

      rem_constraint("Text of comment").

    4. For uncertain constraint bases:

      rem_constraint_u("Text of comment").

    5. 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,_,CF)

      _fact("Askable_condition","CF")

    2. For model bases:

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

      _model_e(Nr,"Go-Ahead Condition","Result"/"Conclusion",
      "Operation"/"Relation", List_of_Arguments,
      Display_Semaphore,"CF_Model")

      _model_lin(Nr,"Go-Ahead Condition","Result",
      List_of_Coefficients, List_of_Variables, "1")

      _model_poly(Nr,"Go-Ahead Condition","Result",
      "Polynomial_Variable", List_of_Coefficients, List_of_Powers,
      Display_Semaphore,"1")

      _argument_known("Name",Value)

      _m_fact("Askable_Go_Ahead_Condition","CF")

    3. For exact constraint bases:

      _constraint(Nr,List_of_conditions)

    4. For uncertain constraint bases:

      _constraint_u(Nr,List_of_conditions)

    5. For uncertain advice bases:

      _advice(Nr,"Advice_name")

    6. For graphics bases:

      _graphics(Nr,"Grafics_name"),

      or:

      _ngraphics(Nr,"nGrafics_name").

    7. For sound bases:

      _sounds(Nr,"Sounds_name"),

      or:

      _nsounds(Nr,"nSounds_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

Augmented uncertain rule bases may contain external and internal inconsistencies named IAU1 (Inconsistencies of Augmented Uncertain single bases):

    1. External inconsistencies are inconsistencies between conditions of flattened rules and their conclusions, i. e. they are external with respect to the list of conditions.

      A direct external inconsistency is illustrated by the rules:

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

      or

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

      with Conclusion being at the same time the rule conclusion and one of its conditions, directly or in negated form. The rules display semaphores are not influencing their inconsistencies,therefore they are omitted.

      Direct external inconsistencies are canonical in this sense, that any other external inconsistency may be reduced to some direct external inconsistency.

      Two rules are mutually externally 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, a directly externally 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 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 a irectly externally 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.

    2. Internal inconsistencies are inconsistencies between conditions of flattened rules, i. e. they are internal with respect to the list of conditions:

      1. A rule of an augmented rule base is considered internally inconsistent, if at least one flattening of this rule is inconsistent, i.e. contains both a condition Condition and its negation nCondition.
      2. However, in contrast to exact rule bases, this time such rule is never automatically eliminated from the rule base, because both Condition and nCondition have some non-zero certainty factors. Therefore the presence of such rules can create unpredictable confusion in the chaining process. Hence any internally inconsistent rule is a danger, which has to be detected, diagnosed and used to stop the functioning of the expert system.
      3. A rule of an augmented rule base is considered internally consistent, if all possible flattening of this rule are consistent, i.e. does not contain both some condition Condition and its negation nCondition.
      Following cases of internal inconsistency may be distinguished:
      1. A rule is internally IAU1-self-inconsistent if its conditions are mutually exclusive , e. g.:

        rule(1,"X",["nA","N","A"],_,_)

        Such internal inconsistency is canonical. It means that any other internal inconsistency may be reduced to an internal IAU1-self-inconsistency.

      2. A rule is internally IAU1-inconsistent if its flattening results in a IAU1-self-inconsistent rule. E. g. the flattening of rule 1 with the help of rule 2 from the pair of rules:

        rule(1,"X",["C","B","Y"],_,_)

        rule(2,"Y",["A","nB"],_,_)

        results in the flattened rule:

        rule_flattened(1,"X",["C","B","A","nB"],[2])

        which is IAU1-self-inconsistent.

      Let us consider the following example:

      rule(1,"W",["A","B"],1,"CF_1")

      rule(2,"W",["X","E"],1,"CF_21")

      rule(3,"X",["C","nE"],1,"CF_3")

      rule(4,"Z",["nW","B"],1,"CF_41")

      The results of flattening those rules are shown in the Table:

      Rule Number | Conclusion | List of conditions | Rules used for flattening
      1 W ["B","A"] []
      2 | W | ["E","C","nE"] | [3]
      3 X ["nE","C"] []
      4 | Z | ["B","nB"] | [1]
      4 | Z | ["B","nA"] | [1]
      4 | Z | ["B","nE"] | [2]
      4 | Z | ["E","B"] | [2,3]
      4 | Z | ["nC","B"] | [2,3]

      Rule 1, rule 3 and rule 4 are internally consistent. However, rule 2 is internally inconsistent and therefore the rule base is classified as inconsistent.

      Internal inconsistencies are not critical: their presence does not lead to a break down the chaining process, but simply causes havoc in the chaining process.

      Therefore the test for rule base IAU1-inconsistencies is mandatory although rather time-consuming.

      Chaining with internally inconsistent rules is blocked.


JOINT INCONSISTENCIES IN RULE- AND CONSTRAINT BASES

    1. Augmented uncertain rule bases and exact constraint bases may contain joint inconsistencies,denoted by the abbreviation IAU/E2 (Inconsistency in Augmented Uncertain/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,"CF_Rule")

      and its corresponding exact constraint base with the constraint:

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

      The presence of the constraint results always in CF(Conclusion) = -CF_Rule. This is perhaps not something the base designer intended to achieve.

    2. Augmented uncertain rule bases and uncertain constraint basesmay contain similar joint inconsistencies, denoted by the abbreviation IAU/U2 (Inconsistency in Augmented Uncertain/Uncertain pairs of bases). Their essence is that - due to uncertain constraints - some rules may have lists of conditions with conditions that are uncertainly mutually exclusive. This usually indicates some flaw in either the rule base or the constraint base design.

      As example consider a rule base with the rule:

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

      and its corresponding uncertain constraint base with the constraint:

      constraint_u(Nr_co,["A","B","C"])

      It is not quite clear what the base designer tried to achieve by such construct. The outcome of a chaining run using the above rule and constraintr is largely unpredictable. The presence of partially uncertainly exclusive askable conditions (A and C) in the same rule is (more often than not) a flaw to be corrected.

Joint inconsistencies of uncertain rule- and uncertain constraint bases are not critical, i.e. they do not lead to a breakdown of the chaining process. They may however lead to unexpected outcomes. Therefore farther use of knowledge bases with joint inconsistencies of rule- and constraint bases is blocked.

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.


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,"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,"1")

model_b(M,"No condition","B","C","*","Result",1,"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

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

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

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

An uncertain model base is indirectly inconsistent with a uncertain 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,"CF_N"])

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

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

Joint inconsistencies of uncertain model- and uncertain 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

Augmented uncertain rule bases may contain redundancies, denoted by the abbreviation RAU1 (Redundancies of Augmented Uncertain single bases). Following RAU1 redundancies are distinguished:

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

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

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

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

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

      disjunctive_rule("Y"),

      where rule 4 has the same conclusion and the same condition like rule 1 after being flattened using rule 2 and 3.
      Because of different rule certainty factors, the rules may not unhesitatingly be considered to be redundant: the presence of condition C in rule 1 may increase the certainty of conclusion W and this may be the reason for having for rule 1 a larger CF value than for rule 2. This may lead us to assume that cases like above should be analyzed only for rules with same rule certainty factors.
    2. RAU1_2 redundancies: the rule base contains rules uncertainly subsumed by other rules, like e.g.:

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

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

      disjunctive_rule("W").

      Rule 1 may seem 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. However, it would be premature to consider rule 1 as subsumed by rule 2 and remove it. The difference of certainty factors for both rules may well indicate that certainty factors for C and D may influence the conclusion certainty factor for both rules. Therefore rule 1 cannot be dismissed out of hand as redundant. Its redundancy cannot be established using some formal tools of analysis, but must be settled each time considering the meaning of the conclusions and of the conditions.

The few examples presented show that rule redundancies is for uncertain rule bases rather uncertain and that it is difficult to propose clear-cut criterions, which - abstracting from the semantics of the rules - will unmistakably diagnose some rules as redundant. Therefore - while sticking to the classification of redundancies presented for exact rule bases - the wording of warnings is made conditional and aims at making the rule base designer to better clarify his/her objectives.
Redundancies of uncertain 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 uncertain 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

    1. Augmented uncertain rule bases and exact constraint bases may contain joint redundancies, denoted by the abbreviation RAU/E2 (Redundancies of Augmented Uncertain/Exact pairs of bases). Its essence is that the presence of the constraints may makes some rules redundant. As example consider the rules:

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

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

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

      disjunctive_rule("Y"),

      which in the presence of the exact constraint:

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

      may be equivalent to a single non-redundant rule:

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

      Whether they are, depends upon the values of CF_1, CF_2 and CF_3:
        • if CF_1 = CF_2 = CF_3 = CF and CF > 0 obviously the rules certainty does not depend upon C, D or E. Therefore rule 123 may be a non-redundant equivalent of rules 1, 2 and 3 with CF_123 = CF;
        • if CF_1, CF_2 and CF_3 are different, rules 1, 2 and 3 may after all not be redundant: the difference of their CF-values may be used to model the different rules certainty depending upon the certainty factors of C, D or E.

    2. The case of augmented uncertain rule- and uncertain constraint bases is more complicated. The presence of joint redundancies of augmented uncertain rule bases and uncertain constraint bases, denoted by the abbreviation RAU/U2 (Redundancies of Augmented Uncertain/Uncertain pairs of bases), is difficult to detect. As example consider the same rules as above:

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

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

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

      disjunctive_rule("Y"),

      in the presence of the uncertain constraint:

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

      This time even for the case CF_1 = CF_2 = CF_3 = CF there is no generally applicable non-redundant representation for the rules.

In other words: for uncertain rule bases the existence of joint redundancies is less certain than for exact rule bases.

Although some rules and constraints suspicious of being jointly redundant may be automatically detected, the answer whether they are truly redundant cannot (for the time being) be given using some formal tools of analysis, but must be settled each time considering the meaning of the conclusions and of the conditions. Therefore - if detected - a warning is issued to the user stressing the need for additional semantic analysis.

Joint redundancies of uncertain rule- and exact or uncertain 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 used 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 exact constraint base or by using the negation prefix n;
      b) indirectly: the said conditions are unaskable and given as mutually exclusive conclusions of some other 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",["nA","B"],_,_)

      rule(4,"Conclusion_4",["nA","nB"],_,_)

      Case 2a) is illustrated by the following example:

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

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

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

      rule(4,"Conclusion_4",["nA","nB","C"],_,_)

      Case 1b) is illustrated by the following example:

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

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

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

      rule(4,"Conclusion_4",["nA","nB"],_,_)

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

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

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

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

      Case 2b) is illustrated by the following example:

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

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

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

      rule(4,"Conclusion_4",["nA","nB","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"],_,_)

      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 also 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,"CF_11")

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

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

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

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

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

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

      model_b(18,"Conclusion_4","Result","GG","+","HH",1,"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,"CF_11")

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

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

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

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

      model_b(17,"Conclusion_3","Result","EE","+","FF",1,"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,"CF_11")

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

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

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

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

      model_b(18,"Conclusion_3","Result","EE","+","FF",1,"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 dychotomic by using the n prefix or 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",_,_,"1")

model_lin(11,"nA","Result",_,_,_,"1")

Case 2 is illustrated by the following example:

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

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

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

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

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

rule(2,"Cond_2",["A","nB"],_,"CF_2")

rule(3,"Cond_3",["nA","B"],_,"CF_3")

rule(4,"Cond_4",["nA","nB"],_,"CF_4",)

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,"CF_11")

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

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

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

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,"1")

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

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

model_b(18,"Conclusion_4","Result","GG","+","HH",1,"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.


EXACT - UNCERTAIN TRANSFORMATION

It is good practice to start the design of uncertain knowledge bases with designing a corresponding exact knowledge base, which may clarify some of the basic logic of the domain knowledge. This being done, the question arises: How to convert an exact rule base into an uncertain rule base? The answer obviously depends upon the rule base designers aims. They give rise to three procedures for transforming exact rules into uncertain rules, to be illustrated for the following elementary exact rule:

rule(1,"Conclusion",["Condition_1","Condition_2"],1)

    1. The conservative (pessimistic) transformation} results in the following uncertain (cumulative) rule with a properly chosen instantiated certainty factor CF_1:

      rule(1,"Conclusion",["Condition_1","Condition_2"],1,"CF_1")

      The only change that occurred is the appearance of the rule certainty factor. The change means that the smallest CF_Condition_i (the least certain condition) is responsible for CF_Conclusion: we are playing safe! This is precisely what has been done while transforming the elementary exact credit validation rule base RUCRE.EEB into its elementary uncertain form RUCRE.EUB, see examples of Bases: because of the risk involved, the decision to give credit has to be done cautiously.
    2. The balanced transformation results in the following two uncertain cumulative rules:

      rule(2,"Conclusion",["Condition_1"],1,"CF_2")

      rule(3,"Conclusion",["Condition_2"],1,"CF_3")

      The philosophy now is: Let all conditions have their say! Two cumulative rules give the chance to declare preferences and allow each condition to influence the overall conclusion in accordance with the importance of this condition. The independence of the conditions of the original exact rule makes this transformation obvious. This approach has been used while while transforming the elementary exact managerial rule base RUDIR.EEB into the elementary uncertain rule base RUDIR.EUB, see examples of Bases: this time the need has arisesen to estimate separately various aspects of the managers performance.
    3. The greedy (optimistic) transformation results in the following two uncertain disjunctive rules:

      rule(2,"Conclusion",["Condition_1"],1,"CF_2")

      rule(3,"Conclusion",["Condition_2"],1,"CF_3")

      disjunctive_rule("Conclusion")

      The philosophy now is: Winner takes all!. Two disjunctive rules make the overall conclusion certainty factor depend upon only a single rule with the largest local certainty factor. It should be noticed that by considering the rules as disjunctive, the assumption of dependence of the lists of condition is overridden: the conditions were originally (in the exact rule) considered to be independent. However, there is no other way to make the conclusion dependent upon the largest certainty value of its conditions. The greed (or optimism) manifests itself by believing that the best (most certain) conditions will eventually be instrumental in determining the overall certainty factor for the conclusion.

Converting an exact model base into an uncertain model base is much less complicated. All that has to be done is to equip exact models with certainty factors:

    • instantiated to 1 for arithmetical models;
    • uninstantiated for relational models.


AUGMENTED UNCERTAIN

RULE- and MODEL-BASED

EXPERT SYSTEM

rmes_AU


This is a CHM File for the Augmented Uncertain
Rule- and Model-Based Expert System Shell rmes_AU