Basic Ontology Processes:
Elaboration and Elicitation
by
Adil KABBAJ and Khalid El HACHIMI
Amine offers the following three basic ontology-based processes:
§ Elaboration process: a process that enables an incremental elaboration of a given description by adding relevant information from the current ontology,
§ Elicitation process: an interactive process that helps the user to make its description more precise and more explicit,
§ Information retrieval process: a process that enables the retrieval of information from the ontology,
.
An ontology in Amine is a graph (in general), the above processes represent different ways to explore and interpret the graph structure and components of the ontology: elaboration uses inheritance mechanism and performs upward breadth-first search to get relevant information for a specific type node, elicitation performs downward breadth-first search to get relevant information for a specific type node, dynamic integration propagates the new information via several nodes, and information retrieval calls dynamic integration process to locate and situate the new information in the ontology and to identify its neighbourhood. Figure 1 illustrates this point.
Figure 1: Ontology Basic Processes
Besides these three basic processes, Amine provides also Dynamic Integration Process and Ontology Based Inferences.
Elaboration is a process that enables an incremental elaboration of a given description by adding relevant information from the current ontology. This is done by using an inheritance mechanism that performs an upward breadth-first search, starting from specific type nodes; nodes (in the ontology) that represent types specified in the description. See the example below.
We differentiate between “deductive elaboration” and “plausible elaboration”, the first concerns the inheritance of definitions only, the second concerns the inheritance of situations only. A situation provides a plausible information about a type while a definition provides certain information. The key operation used by the inheritance mechanism is the specialization operation (i.e. specialize a CG by joining to it another CG).
As noted before, deductive elaboration process performs an upward breadth-first search of definitions to join to the current description. The process looks for definitions of types that are specified in the current description and since the description is updated after each join operation, the set of types to expand (may) change after each join. In the current implementation, elaboration is an iterative process: each type expansion constitutes an iteration. Also, the elaboration process operates in two modes: interactive elaboration and non-interactive elaboration. In the interactive mode, the user identifies, at each iteration, which type (in the current description) to expand. In the non-interactive mode, the elaboration process selects itself, at each iteration, which type to expand.
Let us illustrate this process with an example. Figure 1 shows the ontology used in this example. This ontology has been created and stored in "samples/ontology/vehicleOntology.xml", using Ontology GUI. To run these examples, you should load this ontology first. Vehicle ontology has been inspired from a working note of Adil KABBAJ [Kabbaj 96] in his response to a working note of Peter Clark on Elaboration and Composition of Concepts. Reader can use this GUI to open the ontology and try this example (see OntologyProcesses GUI for more detail on how to proceed).
Figure 1: Vehicle Ontology
The process starts with the user’s description (for instance: [Bus]-engn->[PetrolEngine]). It locates the definition of PetrolEngine and join this definition to the current description which becomes:
[PetrolEngine #0] -
-fuel->[Gasoline],
-force->[Average],
<-engn-[Bus]
The process continues with the join of the Gasoline definition:
[PetrolEngine #0] -
-fuel->[Gasoline]-state->[state = Volatile],
-force->[Average],
<-engn-[Bus]
The elaboration process terminates because all superTypes of types that are present in the current description have no definition. Note that the elaboration process doesn’t replace the type by its genus, due to the expansion operation (for instance, it doesn’t replace PetrolEngine by Engine) because the specificity of the description is required (required by the user and also by plausible elaboration). Indeed, the most specific type remains in the description (for instance PetrolEngine) but the process maintains a HashMap that associates to each specific type of the description its current generalization. For instance, in the first iteration the process associates RoadVehicle to Bus (Bus is a subtype of RoadVehicle) and join the definition of Bus (if there is a definition) to the current description. Then, in the next iteration where the process continues upward in the ontology, it associates to Bus its super-type Vehicle (which is a direct super-type of RoadVehicle) and join the definition of RoadVehicle (if there is a definition) to the current description, and so on.
A similar treatment is performed for plausible elaboration: iterative specialization of the current description by cumulative join of inherited situations. An inherited situation that can’t be joined with the current description is ignored. To illustrate plausible elaboration, let us continue with the above example: after deductive elaboration, user can initiate plausible elaboration. The next update of the above description is:
[PetrolEngine #1] -
-fuel->[Gasoline]-state->[state = Volatile],
-force->[Average],
<-engn-[Bus #0]-mass->[Average]
And the last update produces the final elaboration of the user description:
[Bus #0] -
-engn->[PetrolEngine #1] -
-fuel->[Gasoline]-state->[state = Volatile],
-force->[Average]-arg1->[Div #3] -
-Out->[Number #2]<-topSpeed-[Bus #0],
<-arg2-[Average]<-mass-[Bus #0]
Figure 2 provides a summary. See OntologyProcesses GUI for more detail on how to run this example.
Figure 2: Elaboration Process
Elicitation process is an interactive process that helps the user to make its description more precise and more explicite. In his/her formulation of a description, user may use general types instead of specific types (for instance, Person instead of Man, Vehicle instead of Bus, etc.) even if the underlying semantic of his/her description is about the semantic of the specific types. This situation can occur if the user doesn’t know the specific type or its definition, or (for some reason) he/she uses a general type to intent a more specific type. To deal with this situation, Amine elicitation process looks for subtypes of the types used in the current description. It then asks the user which subtype is intented by the used type. For instance, if the description contains the type Engine, the user is asked if the intended type is PetrolEngine or RocketEngine. The user may ask for the definition of the specified subtype (to decide if the proposed subtype is indeed the intended type). If the user selects one subtype, the description is updated (Engine will be replaced by PetrolEngine for instance) and the process will continue iterativelly: it considers all the types used in the current description including the new types (PetrolEngine could be replaced by a more specific type, like Bus).
As an example, the user can specify the following description: [Vehicle]-engn->[Engine]
After the interaction with the user, the description becomes: [Bus]-engn->[PetrolEngine]
The elicitation process can continue in two ways:
Elicitation can continue, if required by the user or the application system, by looking at situations related to the concept types of the current description. We call this type of elicitation local situation-directed elicitation.
Elicitation can continue after a simulation of an integration of the current description in the ontology. The goal of this integration is to situate the description in the ontology and to identify especially situations that are directly more specific than the currrent description. We call this type of elicitation integration situation-directed elicitation.
Local situation-directed elicitation
Elicitation considers all situations associated directly to each concept type in the current description. It then asks for each situation if it fits with the intented description (recall that the aim of the elicitation is to help user to elicitate his current description to make it more closer to the intended description, which is stored deeply in his head !). If the answer is "yes", more specific situations of the current situation are considered. If the answer is "no" the current situation is ignored. Let us start for instance with the description specified in Figure 2 and ask Amine for local situation-directed elicitation (button "By Type Situation" in Figure 2).
Figure 2: Local situation-directed elicitation
The process found a situation, under Vehicle (see Figure 1) that corresponds exactly to the specified description. User responds yes, the join of the situation to the current description produces no change and the process continue as specified in Figure 3.
Figure 3: Local situation-directed elicitation (continue)
Assume that user responds yes, the join of the situation to the current description is specified in Figure 4 and the process continue as specified in Figure 4.
Figure 4: Local situation-directed elicitation (continue)
Integration situation-directed elicitation
While definition-directed and local situation-directed elicitations operate at the component level (change of concept types or join of specific situations), situation-directed elicitation operates at the structural level: the current description is integrated in the ontology, using the dynamic integration process described in section 5, in order to situate the description in the ontology and to identify its neighborhood; to determine situations that are more specific. The user is then asked if one of these situations fits his/her intended description.
For instance, situation-directed elicitation may start from the result of the definition-directed elicitation ([Bus]-engn->[PetrolEngine]). The user gets a request from Amine (Figure 5).
If user’s response is yes, the current description is replaced by the selected situation and the process continues with the situations that are more specific than the selected situation.
Figure 5: Elicitation process
Figure 6 provides a summary:
Figure 6: Elicitation Process (definition and local situation-directed)
From the concept types used in the specified description (the request), the system tries to identify type definitions that can cover all parts of the description. Definitions are looked for in an upward search, starting from Type nodes that correpond to the concept types used in the request. Figure 7 illustrates this coverage process.
Figure 7: Parts covered by definitions
Note that the part identified as known is a composition (a join) of two definitions: definition of PetrolEngine and definition of Gasoline (see Figure 1).
The GUI for these processes is OntologyProcesses GUI