Merging process

Ontology merging is one of the basic processes (ontology-based processes) offered by Amine platform, it helps the user to merge two Amine’s ontologies into a new single one. Integration, Composition, Fusion, and Synergizing can all be used as “synonyms” of the term merging, and it’s defined in the literature as follows: is the process of reusing or unifying existing ontologies to build a new more general or more complete one that can be utilized by a specific application or by existing applications already using the input ontologies that were integrated or merged.

Let us illustrate this process with an example. Figure 1 shows the ontologies used in this example. These two source ontologies have been created using Ontology GUI and, stored in "samples/ontology" repository, to make some small tests, and we tried to put in them all the different cases that we treated

The examples in the bottom illustrate some of the most pertinent cases that we have dealt with while developing our system:

• Two different Definitions for the same identifier:

  For instance, Living has two different definitions in O1 and O2 respectively ([Universal:super]-has->[Vehicule] and [Universal:super]-agnt->[AutoBus]) If the user asserts that the definitions of the concept Living aren’t complete, by setting the parameter isCompleteDefinition to false, which means they’re open to being completed by joining them (if it is possible). Then in the merged ontology, Living has a definition that is the result of joining the two definitions as follows:
  [Universal : ”1”]-
  -has->[Vehicule],
  -agnt->[AutoBus]
  When isCompleteDefinition is set to true, which means the definition in the main ontology (the first one) is complete and should not be changed, here we only pop-up a warning to the user of the existence of two different definition, and we complete our merge process.

• Two different Canons for the same identifier:

  In Amine's ontology, a Type can have at most one Canon, which is a conceptual graph that describes constraints on the use of the related type. Generally, it's more used with relations and actions.
  Let’s see, in figure 2, the case when we have two similar concepts with different Canons, here we should only keep one.

  

  There are two approaches, either generalization or specialization. Assuming O1 has a restricted canon and O2 has an extended one for the same concept (see the figure), and the parameter CG Canonicity is checked, the Specialization will exclude a huge part (The CGs that don’t match the canon) from O2 and the Generalization will include a huge part in O1 which was not concerned originally with the canon).
  For example, if we choose a specialization in our case, the situation:[Eat]-agnt->[Horse] is verified in the second ontology but not in the resulting Canon for the merged ontology, because even if Horse is a Living, it’s not a Human.
  This was important and gave us an insight into the order we should follow during the merging processes, because we need first to define the Canon and then the other conceptual graphs, to make sure we only keep the relevant ones that verify the Canon.
  Solution: User involvement, we decided to let the choice to the user depending on his needs, he can either choose the specialization or the generalization and that is the reason behind creating the fourth parameter “Canon specialization over generalization”.

• Conversion Type to Individual and vice versa:

  The conceptual mismatches are widely found, because the ontologists can see things from different perspectives, like when someone assumes number (one, two, three…) as subtypes of the abstract entity Number while other can see them as individuals, or it can be also found a lot in Attributes (small, tall, short…). Thus, there was a must to add the TypeOverIndividual parameter that let the user decides which approach he wants to keep.

  

• Two different Identifiers with the same definition:

  The definition similarity algorithm uses the definition of entities optionally available in some ontologies as a CG. This algorithm assumes that two entities belonging to different ontologies are similar if their associated definitions (descriptions) are equal. For instance, the concept Human in O1 and Person in O2 have the following definition ([Living:supert]-has->[Intelligence]) , therefore, they are considered as synonyms.

The GUI for these process is AmineMerger GUI.