Mappings based on Subclass Definitions

OWL classes and properties can be considered as sets. Each set contains all individuals that are instances of the class or property. When synchronizing models using OWL, a mapping is needed, which allows to determine all individuals that are required in the opposite domain to restore a synchronous state (cf. Sect. 7.2). To determine these individuals, the formalization of the relation between classes is needed. For the most basic mapping case (cf. row 1 in Table 7.1), classes can be defined as being equivalent. OWL explicitly provides the EquivalentTo construct for such purposes. In this case, subclasses are solely used to separate the mapping ontology and the domain ontologies. A respective class definition in OWL can be put as shown in Listing 7.1.

1 Prefix: owl: <http://www.w3.org/2002/07/owl#>

2 Ontology: <example://equivalence>

3

4 Class: Package SubClassOf: owl:Thing

5 Class: Section SubClassOf: owl:Thing

6 Class: Package2Section EquivalentTo: Package, Section

Listing 7.1: Definition of equivalent classes in OWL.

The second row of Table 7.1, contains the first type of mapping which can be han- dled by defining subclasses—a distribution. First, consider the most simple case, where instances of one class (e.g., Table) are distributed over two classes in the opposite do- main (e.g., Entityand Service). Instances of Tablecan either belong toEntity or to Service. In general, it is also possible that some instances of Table do not belong to any of the two classes. This situation is visualized by the Venn diagram in Fig. 7.3.

7 Ontology-based Round-Trip Engineering

In the lower part of Fig. 7.3, the same facts are encoded in a class diagram. One can find the classes that are defined by the original metamodels of both domains—depicted as boxes with solid border. Then, for each potential case of mapping, a subclass is intro- duced. For a mapping between one class—in one of the domains—and two classes—in the other domain, we obtain five such subclasses. The number of these classes corresponds to the subsets that can be found in the Venn diagram above.

In Fig. 7.3, we consider the mapping between Entities, Services and Tables. We introduce two subclasses of Table. One that denotes the set ofTables that corresponds toEntities, another one that represents allTables that are related toServices. These additionally defined subclasses use dashed borders. The first subclass (E\T) denotes all Entitiesthat do not have a correspondingTable. In our example, this set is empty, but for other mappings it might be not. The second subclass (E∩T) represents allEntities that correspond to aTable. The definition of this class is crucial for the mapping. The concrete definition determines which Entities map to Tables and which do not. The third subclass ((T\E)\S) contains allTables that are neither mapped to Entities nor to Services. In our example this set is also empty, but this may not be the case for other mappings. The two remaining classes (T∩Sand S\T) are reverse to E∩TandE\T.

By defining subclasses that extend classes from both domains, pairs of individuals can be represented as one individual belonging to two classes. For example, aEntity-Table pair is represented by an individual of classE∩T. If anEntityis created, one can reason that it also belongs to class E∩T, because E\T is empty. This implies that the newly createdEntity individual is an instance of classTable. We will use this in Sect. 7.5.

We think this is a very intuitive way to create mappings. One must determine which sets of individuals in the source domain map to which sets in the target domain. Then, the sets need to be split until pairs of sets remain where individuals correspond pairwise. This yields a general procedure of using subclass definitions. We can derive that ar- bitrary pairwise relations between domain concepts (i.e., metaclasses) can be handled in this fashion. Supposing that the individuals of the left domain are spread across m classes and the ones in the right domain span n classes, one can enumerate all intersec- tions between the two sets of classes. In general the number of these intersection sets countintersect can be computed as follows:

countintersect = m ∗ n

For the basic example discussed above, this yields a number of 2 (1 ∗ 2). Although we had five subsets in Fig. 7.3, three of them represented individuals that are not mapped to the opposite domain. Thus, no definitions (i.e., no subclass restrictions) are required for them.

If the classes from both domains that are involved in such a mapping are known, the intersection sets can be derived and the mapping ontology can be filled with respective subclass restrictions. For example, if a class extends classAandB(i.e., it is the intersec-

7.4 Specifying Model Mappings using Ontologies

tion of two classes) we must specify which individuals belong to this class. Depending on this definition (i.e., the subclass restriction) a reasoner can decide which individuals of Acorrespond to individuals of Band vice versa.

We call the general process to create specifications for such pairwise correspondences subset splitting and mapping. It consists of the following steps:

1. determine all potential classes for left individuals, 2. determine all potential classes for right individuals, 3. derive set of intersection sets (i.e., subclasses),

4. add subclass restrictions to those intersection classes that are required (i.e., that actually contain individuals that are represented in both domains).

We split the classes for each ontology using subclass restrictions. By using the same subclasses (i.e., intersection classes), a mapping is established between the two ontologies. The mapping based on subclass definitions does work for the first three types shown in Table 7.1 (i.e., all cases where pairs of individuals are related). It cannot be applied if multiple individuals take part in a relation, because domain classes are defined to be disjoint within one domain in the modeling space. Thus, we can only define non-empty subclasses that extend classes from different domains. Extending two classes from the same domain yields an empty set of individuals, because the classes are disjoint unless they inherit from each other (cf. Sect. 5.4.1). Besides this restriction, the approach seems very intuitive. Once the designer of a mapping has decided that individuals are related pairwise, she must clarify which set of individuals is mapped to which class in the opposite domain. The resulting set definitions can be formalized using OWL class definitions as shown in Listing 7.2.

1 Ontology: <example://subclasses>

2

3 Class: Entity DisjointWith: Service

4 Class: Service DisjointWith: Entity

5

6 Class: Table

7

8 DataProperty: isSimple Domain: Table Range: xsd:boolean Characteristics: Functional

9

10 Class: Entity2Table SubClassOf: Table EquivalentTo: Entity, Table and isSimple value false

11 Class: Service2Table SubClassOf: Table EquivalentTo: Service, Table and isSimple value true

Listing 7.2: Subclass definitions for mapping Entities and Services to Tables. Depending on the value of the data propertyisSimple, individuals of class Tableare defined to correspond either to Entities or Services. A reasoner can use these class definitions to determine the correspondences between the classes of the two domains.

7 Ontology-based Round-Trip Engineering

We believe that splitting classes into subsets, where each subset corresponds to one class in the opposite domain, is easy to understand. Besides its simplicity, another advantage of the subclass mapping approach is that it is bidirectional. The mapping is independent of the synchronization direction. We can add individuals to any domain and infer missing ones in the opposite domain.

Moreover, the definition of subclass restrictions can be checked by OWL reasoners. Thus, one can easily detect overlapping subclasses, because these are reported by the reasoner as inconsistencies in the ontology. We have experienced this multiple times during our experiments.