next up previous
Next: Rules Up: Facts Previous: Interface Attributes

Fact Relations


Establishing relations between facts is a very useful and common mechanism of knowledge structuring. Relations are declared as fact attributes. A fact can have several of these relation attributes. These attributes define named relations between the fact with the attribute and other facts of the system. By means of these declarations a labelled directed graph of facts is established. This graph can be used to define a hierarchy of facts, to establish an order of evaluation, etc. We can distinguish between relations defined by the programmer and predefined relations. The programmer can define relations among facts and give them sense and properties when defining the control component of the module because these relations can appear as conditions of meta-rules, Section 6. Here we present some examples of relations defined by the medical expert programming the Terap-IA application:

There is a set of common problems faced by experts that can be solved using relations. Predefined relations are relations with a system-defined meaning.

Experts usually build hierarchies in their applications. This predefined relation, meaning inclusion, is thought for that purpose and makes an off-line application of the transitive property of inclusion, giving a more efficient system. For instance when the expert defines the next two relations between antibiotics, doxi belongs_to tetras, and tetras belongs_to tetraciclines, the system adds the new relation doxi belongs_to tetraciclines.

There are several relations which are used to induce the order of the questions to be made to the user when getting values for facts in the import interface.

When the system is going to ask for the value of a fact, and this fact has a needs relation with another fact, the last fact will be asked first. For instance the relation pregnant needs sex means that before asking if a person is pregnant the system will ask for the value of fact sex. This relation can be used between facts of any type.

Needs_true and Needs_false:
This cases are similar to the previous one, but the behaviour is different depending on the answer to the first question being asked. Consider the following example of relation, pregnant needs_true female. The first question to the user would be if the person is female. If the user answers ``yes'', the question pregnant would be asked. If the user answers ``no'', then the fact pregnant would become false and no question about it would be made. The only difference of needs_false is that the behaviour is the inverse one with respect to the answer to the first question. These relations can be declared between facts of any type and non-numeric facts. For a set fact, we consider its value to be true when all the elements of the set are true; we consider it to be false when all the elements of the set are false. Similarly, for linguistic facts we consider its value to be true when all the linguistic values are true; and false when all the linguistic values are false.

Similar to needs_true and needs_false relations but between facts of any type and numeric facts. If the numeric fact gets a value then the question of the fact is made. If the numeric fact does not get a value, the value of the fact holding the relation will be unknown.

As saw in Section 3.1.1 the value of fuzzy and linguistic facts depends on a numeric fact. This relation with a quantitative fact (numeric) is then mandatory to inform the system to first ask for the value of that fact and then fuzzify it with the characteristic functions.

Similar to the previous relation, it asks for the value of a qualitative fact (fuzzy or linguistic) and then defuzzifies that fact value to produce a number.

As a common rule for all relations r of one of the previous types, given r(a, b), if b's value is unknown then a will be unknown as well.

next up previous
Next: Rules Up: Facts Previous: Interface Attributes

Josep Puyol-Gruart
Thu Oct 23 15:34:13 MET DST 1997