Definition Integration Process
by
Adil KABBAJ
Definition classification-based integration process
Definition Generalization-based integration process
Definition Integration Process API
Definition Integration Process and Dynamic Ontology GUI
Like Situation and Rule Integration Process, Definition Integration Process is based on Dynamic Integration Process, described in Dynamic Ontology. This basic process is augmented, in the case of Definition Integration Process, by additional treatments that are specific to Definitions Integration Process. For instance, if the definition of the new type T1 is more specific than the definition of a type T2 that exists already in the ontology/KB/memory, then the definition of T2 should be contracted from the definition of T1 and replaced by the type T2. This treatment leads to Knowledge Reformulation; reformulation of types definitions.
Suppose now that the definition of type T1 is more specific than definitions of two exclusive subtypes of T2: T21 and T22. In this case, the two definitions should be contracted from the definition of T1, and the type T2 should be replaced by a conjunction of T21 and T22.
Next sections illustrate and discuss in more detail these important aspects of Definition Integration Process.
Definition classification-based integration process
Let us illustrate definition classification-based integration process with the following three examples.
Example #1:
This example uses ontology "aminePlatform/samples/ontology/LivingSample.xml" and the definitions to be integrated are stored in file "aminePlatform/dataForDynamicOntology/LivingExample.txt".
Definition of Human is integrated first in the current ontology:
Human
is [Object :super] -
-Life->[Life],
-Intelligence->[Intelligence]
Then, we
proceed to the integration, by classification, of the definition of Vegetable
(Figure 1):
Vegetable is [Object :super] -
-Life->[Life],
-lack->[Intelligence]
Figure 1 shows the specification of pertinent types for the definition of Vegetable. Next, a Multiple Selection window appears for pertinent super-types. If the user considers none of these super-types as pertinents, he/she has to close the Multiple Selection window, in order to consider the next step.
Figure 1: Integration (by classification) of the definition of Vegetable
Figure 2 shows the next step; the specification of the new type: Vegetable.
Figure 2: Integration (by classification) of the definition of Vegetable (continue)
"Human" and "Vegetable" are recognized as two specialization/subtypes of "Object" (Figure 3).
The integration/classification of the definition of Sea_Vegetable follows the same steps:
Sea_Vegetable is [Object :super] -
-Life->[Life],
-lack->[Intelligence],
-loc->[Sea]
The integration/classification process found that the definition of "Sea_Vegetable" is more specific then the definition of "Vegetable". Thus, the definition of Vegetable is contracted from the definition of Sea_Vegetable and the type "Objet" is replaced, in the definition of Sea_Vegetable, by the type "Vegetable" (Figure 3). Figure 3 shows the result of the integration/classification of the definition of Sea_Vegetable as well as the transformations of its definition.
Figure 3: Integration (by classification) of the definition of Sea_Vegetable
Integration, by classification, of the definition of the type Living (Figure 4):
Living is [Life]<-Life-[Object:super]
Figure 4: Integration (by classification) of the definition of Living
Figure 5 shows the result of the integration/classification of the definition of Living: a) Living is identified as being more general than Vegetable and Human. These two types are no more direct subtypes of Object, but are now direct subtypes of Living. As a consequence of this re-organization, the definition of Living is contracted from the definitions of Vegetable and Human, and the type Object is replaced by the type Living (Figure 5). Note that the transformation in this case doesn't concern the definition of the new type but definitions that exist already in the ontology/KB/memory.
Figure 5: Result of the integration (by classification) of the definition of Living
Let us consider now the integration/classification of the definition of the new type Person (Figure 6):
Person is [Object :super] -
-Life->[Life],
-Intelligence->[Intelligence]
Figure 6: Integration (by classification) of the definition of Person
The integration/classification process recognizes that the definition of Person is equal/identical to the definition of Human. Person is thus recognized as a synonym for Human (Figure 7).
Figure 7: Type "Person" is recognized as a synonym of type "Human"
Example #2
This example uses ontology "aminePlatform/samples/ontology/PelicanScientist.xml" and the definitions to be integrated are stored in file "aminePlatform/dataForDynamicOntology/PelicanScientist.txt".
Here is another example. Figure 8 shows the initial state of the ontology.
Figure 8: The initial state of the ontology
Classification of new definitions:
Pelican is [Beak] -
-attr->[Size = big],
<-poss-[Bird :super]<-agnt-[Eat #0]-obj->[Fish]
PelicanScientist is [Study #0] -
-obj->[Pelican],
-pat->[Scientist :super]
HPS
is [Beak] -
-attr->[Size = big],
<-poss-[Bird]-
<-agnt-[Eat #0]-obj->[Fish],
<-obj-[Study]-pat->[Scientist:super]<-agnt-[Work]-manr->[Hard]
Figure 9 shows the first steps in the integration/classification of the definition of HPS.
Figure 9: Initial steps in the integration/classification of the definition of HPS
During the integration/classification process, it is recognized that the definition of HPS is more specific than the definition of Pelican. The type "Bird" in the definition of HPS is then replaced by the type "Pelican". Then, the definition of HPS is compared to the definition of PelicanScientist: definition of HPS is more specific than the definition of PelicanScientist. The type "Scientist" in the definition of HPS is replaced by the type "PelicanScientist" and the type HPS is integrated as a direct subtype of PelicanScientist (Figure 10).
To recognize that the definition of HPS is more specific than the definition of PelicanScientist, the integration/classification should recognize first that the definition of HPS is more specific than the definition of Pelican (because PelicanScientist is defined in terms of Scientist and Pelican).
At the end of the integration/classification process, definitions of Pelican and PelicanScientist are contracted from the definition of HPS (Figure 10).
Figure 10: Result of the integration/classification of the definition of HPS
Example #3
This example uses ontology "aminePlatform/samples/ontology/DefinitionKB.xml" and the definitions to be integrated are stored in file "aminePlatform/dataForDynamicOntology/DefinitionsEx.txt".
Our third example illustrates an important point in definitions integration/classification process. To illustrate clearly this point, we use meaningless identifiers. Figure 11 shows the main part of the ontology.
Figure 11: The initial state of the ontology
Integration/Classification of new types definitions:
TT1
is [TT:super]-rr2->[AA1]
TT2 is [TT:super]-
-rr2->[AA1],
-rr4->[AA2]
TT3 is [TT:super]-rr1->[AA3]
TT4 is [TT:super]-
-rr2->[AA1],
-rr3->[AA4]
QQ1 is [QQ:super]-rr5->[AA2]
QQ2 is [QQ:super]-
-rr5->[AA2],
-rr8->[AA7]
QQ3 is [QQ:super]-
-rr6->[AA5],
-rr8->[AA7]
Figure 12 shows the result of the classification of the above definitions:
TT2 and TT4 are more specific than TT1, and QQ2 is more specific than QQ1.
Let us
consider now the classification/integration of the definition of the new type
TT5 (Figure 12) :
TT5 is [TT:super]-
-rr2->[AA1],
-rr4->[AA2:x]<-rr5-[QQ]-
-rr6->[AA5]-
-rr8->[AA6],
-rr7->[AA4:y];
-rr8->[AA7];
-rr1->[AA3],
-rr3->[AA4:y]-rr1->[AA6]
Figure 12: The state of the ontology after the integration/classification of TT1, TT2, TT3, TT4, QQ1, QQ2 and QQ3
Integration/classification of the definition of TT5 starts with the two pertinent types TT and QQ. Starting the integration/classification of TT5 by its "propagation" from the type node TT in the ontology leads to recognize that the definition of TT5 is more specific than the definition of TT3 and the definition of TT1. Then, when definition of TT5 continues its propagation through TT1, it is recognized that TT5 is more specific than TT4 and TT2. So, the definition of TT5 is more specific than definitions of TT2, TT4 and TT3, all are subtypes of TT. Thus, according to the classification of TT5 through TT, the type TT in concept [TT :super] in the definition of TT5 should be replaced by the conjunction of TT2, TT4 and TT3. Instead of allowing a concept type to be explicitly a conjunction of types, we choose to create a new type that is defined as a conjunction of concepts (Figure 13). Hence, in this example, the integration/classification process creates a new type "TT2_TT4_TT3" defined as a conjunction of [TT2:super], [TT4:super], [TT3:super], and the type TT in the definition of TT5 is replaced by "TT2_TT4_TT3" (Figure 13).
The same process is performed when integration/classification of the definition of TT5 is performed through the type node QQ: definition of TT5 is more specific than the definition of QQ1, QQ2 and QQ3. Hence, a new type is created: "QQ2_QQ3" and this type replaces the type QQ in the concept [QQ] in the definition of TT5 (Figure 13). In conclusion, definition of TT5 is indexed under types "QQ2_QQ3" and "TT2_TT4_TT3" and the specification of its definition is reformulated after contraction of definitions of TT3, TT1, TT2, TT3, TT4, QQ1, QQ2 and QQ3 (Figure 13).
Figure 13: The state of the ontology after the integration/classification of the definition of TT5
In our definition and implementation of definition integration/classification process, definitions contraction is done at the end of the integration/classification process; not during the integration/propagation process. If the contraction of definitions is done during the integration/classification/propagation process, it maybe possible to contract parts that are contained in more than one type definition, and in this case some definitions will not be recognized as being subsumer of the new type definition. For instance, if the definition of the type QQ2 is contracted as soon as it is recognized as a subsumer of the definition of TT5, then the branch [QQ:super]-rr8->[AA7] would be contracted from the definition of TT5. Next, when the definition of TT5 is compared with the definition of QQ3, the integration/classification will not recognize that the definition of QQ3 subsumes the definition of TT5.
Definition Generalization-based integration process
Recall that classification-based integration process considers only the cases of MORE_GENERAL, MORE_SPECIFIC and EQUAL; it doesn't consider the case of HAVE_INTERSECTION (i.e. it doesn't consider the case where the two descriptions have only common generalization). Generalization-based integration process considers also the case of HAVE_INTERSECTION. Examples below illustrate Definition Generalization-Based process, and illustrate also the difference between the two integration modes.
Example #1
Figure 14 shows the result of the integration of definitions of Human and Vegetable. The most specific common generalization of the two definitions is computed and represented by the (abstract) situation: [Object]-Life->[Life].
Figure 14: State of the ontology after the integration/generalization of Human and Vegetable
The definition of Sea_Vegetable is then integrated. The integration process recognizes that Sea_Vegetable is more specific than Vegetable (Figure 15).
Figure 15: State of the ontology after the integration/generalization of Sea_Vegetable
When the definition of Living is integrated, the integration process recognizes that this definition is identical to the common generalization of Vegetable and Human. The definitions of Vegetable and Human are reformulated to take into account the result of this new integration (Figure 16).
Figure 16: State of the ontology after the integration/generalization of Living
Example #2
Figure 17 shows the result of the integration/generalization of TT2 and TT4. TT2 and TT4 have only a Common generalization that is added to the ontology as an abstract situation (Figure 17). The definition of TT3 is then integrated.
Figure 17: State of the ontology after the integration/generalization of TT4, TT2 and TT3
Figure 18 shows the integration of TT1.
Figure 18: Integration/generalization of the definition of TT1
The integration/generalization process recognizes that definition of TT1 is identical to the common generalization of TT4 and TT2 (Figure 19). Definitions of TT2 and TT4 are reformulated to consider this new integration (Figure 19).
Figure 19: Reformulation of the definitions of TT2 and TT4
Figure 20 shows the result of the integration/generalization of definitions of QQ2 and QQ3.
Figure 20: State of the ontology after the integration/generalization of QQ2 and QQ3
When QQ1 is integrated, it is compared to the situation (common generalization of QQ3 and QQ2) and since the situation doesn't subsume QQ1, QQ1 is not compared to QQ2 and QQ3. So, the integration process will not discover that QQ1 subsumes (is more general than) QQ2 (Figure 21).
Figure 21: State of the ontology after the integration/generalization of QQ1
If we start however with the integration of QQ2, followed by the integration of QQ1 and QQ3, the integration/generalization process will discover that QQ1 subsumes QQ2 (Figures 22-24). This example shows that the order of the integration of definitions has an impact on the integration/generalization process; and may leads to different content and orgranization of the ontology/KB/memory.
Figure 22: State of the ontology after the integration/generalization of QQ2
Figure 23: State of the ontology after the integration/generalization of QQ1
Figure 24: State of the ontology after the integration/generalization of QQ3
Let us consider now another scenario of integration/classification of definitions: let us start with the integration of QQ1. QQ1 is classified as a direct subtype of QQ (Figure 25). We consider next the integration of QQ2 with pertinent types QQ and AA7. QQ2 is classified as a direct subtype of QQ1 (Figure 25). We consider next the integration of QQ3 with pertinent types QQ and AA7. Since QQ3 is not more specific than QQ1, it will not arrive at QQ2 via QQ1, but it will arrive at QQ2 via AA7. After their comparison, the integration process will discover that the two descriptions have a common generalization (Figure 25). Please, consider the difference between the result of this scenario (Figure 25) and the previous one (Figure 24).
Figure 25: State of the ontology after the integration/generalization of
Figure 26 shows the result of the integration/generalization of the definition of TT5.
Figure 26: State of the ontology after the integration/generalization of TT5
Definition Integration Process API
Definition Integration Process can be activated from Dynamic Ontology GUI, or by the use of the Definition Integration Process API (described below).
Constructors (for the Definition Integration Process)
public IntegrateDefinition(Ontology ont)
public IntegrateDefinition(Ontology ont, Lexicon lex)
public IntegrateDefinition(Ontology ont, Lexicon lex, JTextArea txtArea)
Member Methods for the three kinds/modes of definition integration process
public IntegrationResult classify(Identifier idType, CG newDescr, AmineList pertinentTypes)
public IntegrationResult classify(Identifier idType, CG newDescr, AmineList pertinentTypes, AmineList superTypesPertinentTypes)
public IntegrationResult generalize(Identifier idType, CG newDescr, AmineList pertinentTypes)
public IntegrationResult generalize(Identifier idType, CG newDescr, AmineList pertinentTypes, AmineList superTypesPertinentTypes)
public IntegrationResult ask(CG newDescr, AmineList pertinentTypes)
public IntegrationResult ask(CG newDescr, AmineList pertinentTypes, AmineList superTypesPertinentTypes)
Static Methods for the three kinds/modes of situation integration process
public static IntegrationResult classify(Ontology ontology, Object newDescr, AmineList pertinentTypes)
public static IntegrationResult classify(Ontology ontology, Object newDescr)
public static IntegrationResult generalize(Ontology ontology, Object newDescr, AmineList pertinentTypes)
public static IntegrationResult generalize(Ontology ontology, Object newDescr)
public static IntegrationResult ask(Ontology ontology, Object newDescr, AmineList pertinentTypes)
public static IntegrationResult ask(Ontology ontology, Object newDescr)
Definition Integration Process and Dynamic Ontology GUI
See Dynamic Ontology GUI for this section.