Old Version of Dynamic Integration Process

by

Adil KABBAJ

In previous versions of Dynamic Integration Process, we adopted a simple definition and implementation of knowledge explicitation and reformulation during dynamic integration process. This document presents these definition/implementation. At the end of this document, we discuss the limit of this definition/implementation. See Definition Integration Process for the new definition/implementation.

Knowledge Explicitation and Reformulation before Integration

The new description to integrate (description of a type definition or of a situation) may contain the definition of a type T; the type is implicitly presents in the description. In order to make the description as precise as possible, the integration process calls an explicitation operation which replaces the definition by the type T (using the contraction operation). Assume for instance that the ontology contains the following two type definitions: Pelican is "a bird with big beak and that eats fish" and PelicanScientist is "a scientist who study pelican". Assume also that the new description S to integrate is "A scientist who study bird with big beak and that eats fish, works hard". The explicitation operation will find that S contains the definition of Pelican. Hence, the definition will be replaced by the type Pelican. This change leads to a more precise version of S: "A scientist who study pelican, works hard". The explicitation operation can make this version even more precise. Indeed, the current version contains the definition of PelicanScientist (once the type Pelican is made explicit in the description), leading to a more precise version of S: "A pelicanScientist works hard".

Thus, knowledge explicitation is an iterative operation that tries to find in the new description, at each iteration, the definition of a (known) type T. If such a definition is found, then the definition is replaced by the type T. Iteration enables the explicitation operation to find type definitions that are dependent on other type definitions (like the dependence of PelicanScientist on Pelican). Knowledge explicitation operation terminates if no (new) definition is found in the new description.  Knowledge explicitation leads to knowledge reformulation of the initial description.

After the explicitation step, the new description is then integrated in ontology (or agent memory). Figures 1-4 show the execution of this example using DynamicOntology GUI. To run the example, load first the ontology "samples/ontology/ManOntology2.xml". Definitions and situations used in this example are stored in the file dataForDynamicOntology/PelicanScientist.txt. Figure 1 shows an excerpt of the ontology, especially the "location" of type Pelican with its definition and the "location" of PelicanScientist with its definition.

Figure 1: Definitions of Pelican and PelicanScientist

Figure 2 shows the new description to integrate. It shows also that the "Trace" option is selected and shows the multiple selection, by the user, of the pertinent types (Bird, Scientist and Work; the user wants to integrate the new description via those types/indexes).

Figure 2: The new description to integrate and selection of the pertinent Types

Figure 3 shows the trace of the integration. Reader can see that the integration process identified first the definition of Pelican and then the definition of PelicanScientist. The trace shows also the result of the explicitation operation; the new description to integrate becomes: [PelicanScientist]<-agnt-[Work]-manr->[Hard].

Figure 3: Explicitation operation

Figure 4 shows the result of the integration which is reduced in this case to the indexation of the new description under PelicanScientist and Work (Figure 4 shows the frame that provides direct superTypes of the new situation). Note that the description is indexed under PelicanScientist and not Scientist, as specified initially by the user. The reason is that due to the explicitation operation, the index (i.e. a pertinent type) Scientist has been refined to PelicanScientist.

Figure 4: Result of the Integration process

Explicitation may discover type synonymy

If the integration process is called to integrate the definition of a new type, and upon the call to the explicitation operation the integration process finds that an identical definition exists already for another type, then it will conclude that the two types are synonym. Figures 5 and 6 illustrate this case. Figure 5 shows the integration of a new type "BirdEaterFish" with its definition (with the specification of Bird as the pertinent type for the integration).

Figure 5: Integration of a Type Definition

During the explicitation operation, the integration process discovers that the new definition to integrate is equal to the definition of Pelican. Hence, it adds "BirdEaterFish" as synonym for Pelican and it highlights the Pelican node as the node for the new type (Figure 6). Figure 6 shows also a frame that provides the synonyms of Pelican (in English). See DynamicOntology GUI for the detail of how to display the frame for synonyms.

Figure 6: Integration Process discovers that the new type is a synonym of an existent type

Knowledge Explicitation and Reformulation II

Knowledge Explicitation and Reformulation may occur also when the new description S to integrate (especially type definition) is equal to a description N (especially a situation) that exists already in the ontology/KB/memory. Let us consider this second case in more detail.

When the new description S to integrate is equal to a description of a node N, we specified that the node for S is joined with the node N. This involves that one of the two nodes will be removed and all links related to it will be linked to the remained node. This involves also a special treatment when one of the two nodes is a definition of a type T and the other a situation St: the situation St is now re-interpreted as the definition of the type T and this re-interpretation should be propagated to every description D (definition or situation) that is indexed under St: replace St by T in D (using the contraction operation). The operation is recursive: if the description corresponds to the description of a situation that is itself specialized by other situations, then apply the contraction operation on these situations too, and so on. The recursion terminates when the description D corresponds to the definition of a type.

Let us illustrate this important feature with the following example. To run the example, load first the ontology "samples/ontology/LivingSample.xml". Definitions and situations used in this example are stored in the file dataForDynamicOntology/LivingExample.txt. Figure 7.a shows the initial state of this ontology, while Figure 7.b shows its state after the integration of the following two definitions:

Human is [Object :super] -
                     -Life->[Life],
                     -Intelligence->[Intelligence]  with pertinent types Object, Life, Intelligence

Vegetable is [Object :super] -
                                   -Life->[Life],
                     -lack->[Intelligence] with pertinent types Object, Life, Intelligence

        (a) initial state of the ontology                (b) Integration of Human and Vegetable definitions

Figure 7: Dynamic Knowledge Reformulation Example

Consider now the integration of the following type definition:

Sea_Vegetable is [Object :super] -
                        -Life->[Life],
                        -lack->[Intelligence],
                        -loc->[Sea]   with pertinent types Object, Life, Intelligence, Sea

Figure 8.a shows the result of the integration: the definition of Sea_Vegetable contains the definition of Vegetable, so the explicitation operation replaced the definition by the corresponding type. Note that the definition of Sea_Vegetable is not indexed under Object but under Vegetable (and under Sea).

         (a) Integration of Sea_Vegetable                                      (b) Integration of a Situation

Figure 8: Dynamic Knowledge Reformulation Example (continue)

Figure 8.b shows the result of the integration of the following situation:

[Object] -
    -Life->[Life],
    -Intelligence->[Intelligence],
    <-agnt-[Study]-obj->[Intelligence] with pertinent types Object, Life, Intelligence, Study

Note again the role of the explicitation operation in the reformulation of the description: the definition of Human is replaced by the type Human (Figure 8.b). Let us consider now the integration of the following definition:

Living is [Life]<-Life-[Object:super] with pertinent types Life and Object

The integration process discovers that the above definition is equal to the description of situation SIT#0 (Figure 8.b). So SIT#0 "becomes" the definition of the new Type Living (Figure 9) and a knowledge reformulation operation is initiated (Figure 9): definition of Human and Vegetable (that were specialization of SIT#0) are reformulated in order to replace the definition of Living by the type Living (once it is recognized that [Life]<-Life-[Object] is the definition of Living).

Figure 9: Dynamic Knowledge Reformulation Example (continue)

In summary, this section illustrates two sources of dynamic knowledge explicitation and reformulation: reformulation of the new description due to the explicitation operation and reformulation of existent descriptions due to the equality of the new definition with an existent situation.

Limit of the current knowledge explicitation and reformulation operation

One limit of this definition and implementation of explicitation operation is that a description may contains several definitions of subtypes for the same type; we consider only the first definition encountered. For instance, consider the following situation: "a very rich person that plays football and that practice medecine meets the president of BSS compagny". The above explicitation operation will recognize that "a person that plays football" is the definition of type "Football_Player" and will replace "person" by "Football_player". The problem is that the other definition "person that practice medecine"; the definition of type "Physician", will not be recognized and identified. The situation contains two subtypes definition ("Football_Player" and "Physician") for the same type (person). What is required here is a common subtype for the two types "Football_Player" and "Physician". If the type "Football_player_Physician" doesn't exist, it should be created and the situation should be indexed under it. The situation should be reformulated like this: "a very rich physician and football player meets the president of BSS compagny".

Definition Integration Process incorporates this treatment.