Models are the central artifact in Model-Driven Software Development (MDSD). Being de ned by meta models, they expose a strict syntactic structure. This property allows for processing models mechanically and using generic tools for arbitrary models. However, the wellknown meta modelling languages (e.g., Essential MOF (EMOF)) do not have a formal semantical foundation. Rather, the semantics of models is de ned implicitly and informal in respective speci cation documents. To resolve this restriction, the integration of models and ontologies has been proposed earlier [1]. In contrast to models, ontologies do have a formal grounding and allow for more sophisticated reasoning about the information represented therein. This paper presents an approach to employ the ontological representation of models for synchronising changes across related models. Existing ideas from ontology mapping and alignment are applied to model synchronisation to investigate to what extent these technologies can be used in MDSD.
With the advent of MDSD, code is replaced by models as the primary artifact in software development processes. By using standardised meta modelling languages (e.g., EMOF) the structure (i.e., the abstract syntax) of such models can be formally de ned. If augmented with a description of the concrete syntax, either graphical or textual, models can be created and edited. To obtain actual software products from models, the latter are usually transformed over multiple stages. Starting from very abstract descriptions, more information is added yielding re ned (i.e., more concrete) models. The most concrete models are then transformed to source code, which implements desired functionality.
When looking at models involved in such a development process one can detect lots of redundancy. For example, information is duplicated by the transformations between models. Even though one should strike for as little duplication as possible, there is often sound reasons for giving up this goal in favour of other objectives. For example, di erent views on the same data enable to focus on certain aspects of a system without worrying about others. This is the central idea behind using Domain-Speci c Languages (DSLs) to model a system. Each of the DSL models shares some information with other models, yet it allows to model a speci c concern (e.g., the user interface or the persistence strategy) separately. In other cases, information may be duplicated because tools can operate only on speci c data formats and conversion and thereby duplication is needed to use these tools. A last reason for introducing redundancy in software artifacts is performance. Complex analysis of models (or source code) often requires to extract relevant information in order to perform the analysis in reasonable time.
Despite the sound reasons for introducing redundancy, there is the strong need to maintain consistency among all software artifacts. Inconsistent models must yield inconsistent implementations, which will de nitely cause systems to fail. So whenever redundancy is introduced, action must be taken to make sure consistency preservation for this particular duplicated information is ensured.
In the MDSD community various approaches have been developed to solve
this problem. Trace information is collected to explicitly capture the relations
between duplicated information [
Recent research has shown that the strength of modelling languages (i.e., the
precise speci cation of abstract syntax) can be augmented with the power of
formal semantics. In [
We believe that this shift toward explicit, formal model semantics can foster solutions to the model synchronisation problem. In particular we expect the following bene ts from using ontologies in the context of model synchronisation: 1. Reduce speci cation e ort - Existing synchronisation approaches need complex speci cations. Ontologies may help here because implicit information can be derived by reasoners. 2. Intuitive speci cation - OWL-DL uses a very intuitive representation of knowledge. Classes are sets of individuals and subclasses are sub sets of their super classes. This may ease the understanding of models mapping. 3. Bidirectionality - Existing unidirectional synchronisation approaches require separate speci cation for each synchronisation direction. The declarative style of ontologies may support the speci cation of both directions at once. 4. Reuse ontology mapping technology - The whole existing body of work in the area of ontology mapping can be applied to obtain model mappings.
In this paper we investigate the rst three points. To do so we introduce
a running example in Sect. 2. Before presenting our OWL-based approach to
model synchronisation in Sect. 4, we will recapitulate the mapping of models
to ontologies in Sect. 3. This mapping has been discussed earlier [
PetriNet name : EString 0..* arcs source 1
Arc name : EString 0..* nodes
Node name : EString target 1 a)
Place
To illustrate our approach we will use a basic scenario where two domain models
need to be kept in sync. This scenario is taken from [
The meta model for petri nets is shown in Fig. 1a). Every petri net consists of arcs and nodes. Arcs do connect two nodes in a given direction. Nodes can be either places or transitions. The former can hold multiple tokens. A constraint not depicted in Fig. 1 forbids that arcs connect two nodes or two transitions. In addition, petri nets, arcs, nodes and tokens have a name.
The meta model for toy trains is depicted in Fig. 1b). Each toy train project consists of components and connections. Components can be either tracks or switches and expose ports. Connections connect ports, the direction is here given by making a distinction between ports of type In and Out. Tracks do have exactly one incoming and one outgoing port, whereas switches can have two ports of the same type (i.e., either two In and one Out port or the other way around). Furthermore, trains and maintenance vehicles can reside on tracks and switches.
The mapping between the two domains can be put as follows. Each petri net relates to one toy train project. Each track relates to an arc. Out ports relate to places and In ports to transitions. Connections between ports do also relate to arcs. A more complicated mapping is needed for switches. Switches with two incoming ports relate to an arc connecting a transition and a place. Switches with two outgoing ports relate to two arcs that connect a single transition with two places. An example of two synchronised models in shown in Fig. 2.
The gure uses concrete graphical syntax for both models. To make the mapping more obvious the components of the toy train model (shown in Fig. 1b) are also depicted in grey shade in Fig. 1a)). This way it is easier to see which parts of the petri net correspond to which parts of the train model. Place Arc
In Port
Out Port
Track/Switch
Connection
To use ontological tools for the synchronisation of models, a bridge is needed to
transfer models to the world of ontologies. Ontology tools and services operate on
ontology repositories and a process is needed to present models to these services.
The mapping of models and meta models to OWL has been discussed in [
For our experiments we used Ecore on the modelling side|the Eclipse implementation of the EMOF standard. Therefore, we will restrict the mapping in this section to this particular meta modelling language. For other meta modelling languages a similar mapping might be suitable. On the ontology side, we used OWL-DL, which is why the mapping will refer to OWL concepts in the following. We will not map the concepts EOperation, EFactory and EParameter, because these are not relevant to model synchronisation. For the sake of simplicity we will also assume that domain meta models span one EPackage only.
As EMOF (and Ecore as its implementation) is an object-oriented modelling approach, the dominant concepts are classes and objects. Classes are also a concept in OWL, objects correspond to OWL individuals. Both Ecore and OWL do have the notion of instance-of, but with a di erent semantics. Ecore objects can be instance of at most one class unless classes are related by inheritance. In this case, objects are also instances of all super types of their class. In OWL individuals can be instances of multiple classes even if these are not related by inheritance. To correctly represent the semantics of meta models in OWL, classes are declared to be disjoint if there is no inheritance relation between them.
Attributes of Ecore classes (i.e., EAttributes) can be naturally mapped to OWL data properties. Opposed to attributes, data properties are not bound to one speci c class in OWL, but can exists on their own. This can cause a name clash if two Ecore classes de ne attributes with the same name. When translating meta models to OWL quali ed names can be used to solve this issue. References connect classes in Ecore and can be represented by OWL object properties. Again, name clashes can occur which the mapping tool must take care of.
To return from OWL to the modelling world, a reverse mapping is needed. This is not possible in general. However, if the OWL knowledge base conforms to our construction schema, models can be created from OWL data. The constraints must be met, because they explicitly model the implicit semantics of models. If an OWL knowledge base does not do so, the corresponding model is not valid w.r.t. the semantics of models. Furthermore, only concepts that do have an equivalent in the modelling world can be used. Since we will use OWL behind the scenes only, this can be easily ensured.
Equipped with this mapping one can either implement a bridge based on
(1) adaptors, build one that relies on (2) transformations or (3) fully integrate
model and ontologies as shown in [
Being equipped with the bidirectional mapping between models and ontologies, one can now focus on model synchronisation, which is essentially about propagating changes that are made to one model to all related models. In the scope of this paper, we will restrict the synchronisation to two models. So whenever a change is made to one of the two, appropriate changes need to be applied to the other one. As we want to use ontological tool machinery to do so, changes need to be transferred to the respective ontology, before the set of implied changes can be determined by reasoning. This procedure is depicted in Fig. 3.
After the models and the performed changes are transferred to the respective ontology a mapping between the two modelling domains is needed. This information is captured in a so-called Mapping Ontology, which is similar to transformation speci cations in the modelling worlds. This ontology refers to the involved meta models by using the concepts that were derived from the meta
models. Note that this mapping is handcrafted as it requires distinct knowledge of the involved domains (i.e., the respective modelling languages).
In this section, we will rst discuss possible mappings between meta models in terms of the derived ontologies in Sect. 4.1. For di erent types of mappings possible realisations are presented. Based on the domain ontologies (i.e., the ones derived from the meta models and the models) and the mapping ontology a reasoner can infer information that is needed in order to synchronise the models. Details of this procedure can be found in Sect. 4.2. 4.1
Mapping Speci cation between Models using Ontologies OWL-DL|being the concrete ontology language used in this paper|is based on Description Logics and is therefore strongly connected to set theory. OWL classes basically denote sets of individuals. When we speak of synchronising ontologies (i.e., the ontologies derived from our models), we refer to the synchronisation of individuals. We are interested in the actions that must be taken if a new individual is created in one of the two domains. The relation between the sets (i.e., the classes) de ned in each ontology is the key to this decision. We will therefore closely look at typical types of relations that do exist between domain classes and how they can be handled in terms of set de nitions. Thus, the general idea behind the mapping speci cations, which will be presented shortly, is based on the consideration of classes as sets of individuals. The objective of synchronisation mappings is therefore to de ne the relations between these sets.
When looking at relations between objects one can distinguish di erent types of mappings depending on the number of related individuals. For example, relations between individuals can be pairwise|one individual of one domain corresponds to exactly one in the other domain. An individual can also be related to a group of individuals in the opposite domain. In the most general case groups of individuals are related to each other. These three main relation types form the rst column in Table 1. The rst type (i.e., the 1:1 relation between individuals) can be further split into sub types depending on the number of classes involved in the mapping. These types are best explained using our running example.
Individual Relation Class Relation Example Relation (Individuals)
Let us rst consider the relation between petri nets and toy train projects. Each petri net corresponds to one project. If we denote the individuals that form a pair as left and right, all left individuals belong to the same class (from the left domain) and all right ones belong to another class (from the right domain). The same can be observed for the relation between transitions and InPorts, as well as places and OutPorts. The situation is slightly di erent for tokens, trains and maintenance vehicles. Here, individuals again form pairs, but classes di er within one domain. Some tokens correspond to trains, others to maintenance vehicles. The more general case where classes di er in both domains cannot be found in the running example. If petri nets would have di erent kinds of tokens, which would correspond to trains and maintenance vehicles we could observe the general case. This is not the same as having one type of token corresponding to trains and another one to maintenance vehicles.
Having seen the di erent types of mappings, the question is how to implement
such a mapping in terms of OWL constructs. In this paper, we will present two
approaches to specify mappings. The rst one is based on de ning mappings
using subclass de nitions. The second one employs Semantic Web Rule Language
(SWRL) [
Mappings based on Subclass De nitions OWL classes and properties can be considered as sets. Each set contains all the individuals that are instances of the class or property. When synchronising models using OWL, a mapping is needed, which allows to determine all the individuals that are required in the opposite domain to restore a synchronous state. To determine these individuals the formalisation of the relation between classes is needed. For the most basic mapping case (cf. Row 1 in Table 1), classes can be de ned as being equivalent. In this case, subclasses are not even required.
The second row of Table 1, contains the rst type of mapping which can be handled by de ning subclasses. To specify that some tokens are mapped to trains and others are mapped to maintenance vehicles, we introduce two subclasses of Train. One that denotes the set of tokens that corresponds to trains, another one that represents all tokens that are related to maintenance vehicles. To elaborate this in more detail consider Fig. 4.
Trains
Tokens
MVs Tr/To
Tr∩To
To∩MV (To/Tr)/MV
MV/To
Sets of individuals Class hierarchy Train (Tr)
Token (To)
MaintenanceVehicle (MV)
The domain classes (Train, Token and MaintenanceVehicle) are depicted as boxes with solid border. The additionally de ned subclasses use dashed borders. In Fig. 4 ve such subclasses are depicted. The rst one (Tr/To) denotes all trains that do not have a corresponding token. In our example this set is empty, but for other mappings it might be not. The second subclass (Tr\To) represents all trains that correspond to a token. The de nition of this class is crucial for the example mapping. The concrete de nition determines which tokens map to trains and which do not. The third subclass ((To/Tr)/MV) contains all tokens that are neither mapped to trains nor to maintenance vehicles. Again in our example this set is empty, but this may not be the case for other mappings. The two remaining classes (To\MV and MV/To) are reverse to the rst two.
By de ning subclasses that extend classes from both domains, the pairs of individuals are represented as one individual belonging to two classes. For example, a train-token pair is represented by an individual of class Tr\To. If a train individual is created, one can reason that it also belongs to class Tr\To, which in turn implies that it is an instance of class Token. We will use this in Sect. 4.2.
The mapping based on subclass de nitions does work for the rst three types shown in Table 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 de ned to be disjoint within one domain. Thus, we can only de ne non-empty subclasses that extend classes from di erent domains. Extending two classes from the same domain yields an empty set of individuals, because the super classes are disjoint. 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 de nitions can then be formalised as OWL class de nitions. 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 its bidirectionality. The mapping is independent of the synchronisation direction. We can add individuals to any domain and infer missing ones in the opposite domain.
Mappings based on SWRL rules A second approach to express mappings is based on SWRL. SWRL is an extension of OWL that enables the use of Hornlike rules in combination with the OWL knowledge base. In this paper, we will restrict ourselves to the DL-safe subset of SWRL. A SWRL rule can be read as follows. If all atoms in the antecedent are true, then the consequent must also be true. Using SWRL rules one can specify dependencies between domains. For example, whenever a petri net contains an arc that connects a transition to a place, a corresponding track must exist, expressed by the following rule: Arc(?x) ^ P lace(?y) ^ T ransition(?z)^
petriIn(?x; ?y) ^ petriOut(?x; ?z) ! T rack(?x) ^ InP ort(?y) ^ OutP ort(?z)^ haveP ort(?x; ?y) ^ haveP ort(?x; ?z) (1)
One can read rule 1 as follows. All individuals of type Arc, which are related with one Place and one Transition by the object properties petriIn and petriOut, imply that the individuals of type Arc are also of type Track, the individuals of type Transition are also of type OutPort and that the individuals of type Place are also of type InPort. Furthermore, the object property havePort must be true. As this rule does only de ne the dependency in one direction, a second rule is needed to express that each track and its respective ports must be mapped to an arc connecting a transition and a place in the petri net. The rule to express this is as follows:
Arc(?x) ! Connection(?x) Connection(?x) ! Arc(?x) (5) (6)
Suppose there is an arc that connects a transition and a place. Obviously both rules (rule 1 and rule 5) can match. Thus, a reasoner will infer that the arc has both type Track and type Connection. If there is also a rule for mapping haveP ort(?x; ?y) ^ haveP ort(?x; ?z) !
As one can see, both a forward and a backward rule is needed to synchronise individuals of type Track from the toy train meta model. Using rule 1 and rule 2, a reasoner is able to infer the synchronisation in both directions without any problems. More simple relations between classes can also be expressed. For example, the next two rules state that Places and OutPorts are equivalent.
P lace(?x) ! OutP ort(?x)
OutP ort(?x) ! P lace(?x)
This case can be handled more easily using subclass de nitions as this does not require separate speci cations for each direction. But, to clarify the relation between both approaches, it must be said that the use of SWRL rules subsumes the subclass de nition approach in terms of expressiveness.
Returning to the rst two rules (i.e., the ones mapping arcs to tracks), one may wonder whether these two rules interfere with other rules (e.g., the ones for mapping arcs to switches). Similar to tracks, switches with two incoming ports are mapped to an arc that connects a transition to a place. But, not only switches are mapped to arcs. Connections between toy train components are also mapped to arcs. So, how can one distinguish between arcs that represent tracks, arcs that correspond to switches and arcs that are related to connections? Let us have a look at the initial rules for mapping arcs and connections: (2) (3) (4) switches, it might in addition infer that the arc is also of type Switch. As our domain classes are disjoint by de nition, this is obviously a contradiction.
To resolve this problem, we propose to combine the subclass approach and the SWRL rules. Instead of using the classes de ned by our meta models in the SWRL rules, we use distinct subclasses. So instead of mapping all arcs to connections (as in rule 5) and all connections to arcs (as in rule 6), we map only subsets, i.e., the arcs that represent connections and, respectively the connections that represent arcs. This yields the following rules, which replace rule 5 and 6: Arc2Connection(?x) ! Connection2Arc(?x) Connection2Arc(?x) ! Arc2Connection(?x) (7) (8)
The class Arc2Connection denotes the arcs that map to connections, class Connection2Arc is the set of connections that map to arcs. The same procedure is applied to all other rules concerned with mapping the same set of classes. By introducing subclasses we resolve the contradiction faced before. However, to make this work, the relation between the newly introduced subclasses and the original classes (derived from the meta model) must be de ned. For example, all connections are mapped to arcs. Therefore, class Connection2Arc is equivalent to class Connection. This is not the case for arcs. Here we must specify, which arcs are mapped to connections and which represent tracks or switches.
To do so, we de ne subclass restrictions. For example, class Arc2Connection is de ned as a subclass of Arc, but with the restriction that is must connect a place to a transition. All other types of arcs (i.e., the ones mapped to tracks and switches) do connect transitions to places, which is the other way around. To distinguish arcs that must map to tracks and switches, other conditions are speci ed. For arcs representing tracks the source transition must have exactly one incoming and one outgoing arc. For the two types of switches, the situation is di erent. Here, the source transition can have two incoming arcs (for switches with two in ports) or two outgoing arcs (for switches with two out ports). The restrictions can be implemented using OWL or SWRL|whatever is more easy.
Once the subclasses are restricted like this, the reasoner can infer which subclass a concrete arc belongs to and consequently which rule applies. By the combination of SWRL rules and the subclass construction we can synchronise individuals which do have di erent counterparts depending on their context. This allows to handle both the 1:n and n:m mapping cases from Table 1.
Handling Primitive Data Types In addition to classes and relations, meta models can de ne attributes, which have a primitive type. These attributes can be mapped to data properties, when translating models to ontologies. When synchronising models, one must take care of these attributes and their values. In principle, there are two cases that can appear when handling primitive types.
In the rst case attributes are mapped directly. For example, the name attribute of a class in one meta model is mapped to the identi er attribute of another meta class. In this case no processing is applied to the attribute value. To handle such mappings the previously described approach for synchronising classes and object properties can be employed. Based on the de nition of sub properties the sets of attribute values can be distributed across the classes that need to hold these values. For example, the name of class Token can be split into two sub properties (i.e., the names for trains and for maintenance vehicles).
The second case can be observed whenever values need to be processed (e.g., set conditionally or concatenated). In this case we de ne sub data properties and process these using SWRL built-ins. Because operations performed by built-ins can do arbitrarily complex computations, there is no way to avoid explicit speci cations for each transformation direction. For example, if strings are concatenated by a rule, another rule is required to specify how strings are split.
To give an example lets suppose we would like to pre x the names of all arcs that correspond to a track with the string track_. To do so, rule 9 and rule 10 can be added. Here, rule 9 concatenates the pre x and the value of data property name. The result of the concatenation is set as value for property subArcName.
T rack2Arc(?t) ^ name(?t; ?name)^ stringConcat(?newN ame; "track "^^string; ?name) ! subArcN ame(?t; ?newN ame) ^ Arc2T rack(?t) (9)
In addition to rule 9, another rule is needed that implements the opposite mapping. Here, the pre x is removed from the name of the arc. The remainder is set as value of data property subname, which is the sub property of name in the train ontology.
To summarise, one can say that the handling of primitive types is not much di erent from traditional model synchronisation approaches. Primitive types are often processed using complex and often non-invertible operations. This does leave no other choice than specifying individual rules for each transformation direction. Nonetheless, we believe that support for bidirectional built-ins in SWRL would be bene cial in this context. Such built-ins must then be evaluated similar to relations (i.e., compute values for unbound parameters). 4.2
Propagating Model Changes In the previous section two di erent possibilities to specify mappings between meta models using ontological concepts have been presented. Based on subclass de nitions and SWRL rules one can now specify desired mappings between domain models. Once these mappings have been formalised, the question is how changes that are made to models can be processed by the ontological tool machinery. Thus, this section will give details about this procedure.
The rst logical step required, when synchronising changes across models is to capture the changes made. This step is rather a technical issue and its concrete implementation depends on the editors used to modify models. In Fig. 5 this rst step is depicted on the left. Once information about changes is available, we employ an OWL reasoner2 to infer implicit information. More concretely, we let
2 Open World Resoning
3 Collect Derived
Information
4 Generate New
Individuals
Fig. 5. Change Handling Procedure - Overview.
Pellet perform the realisation task. The goal of this task is to calculate all types for all individuals. To do so, the reasoner must also perform a classi cation, which calculates all subclass and equivalence relations between OWL classes. While performing these tasks, Pellet uses the rules de ned in the speci cation mapping to imply new facts or to derive subclass and equivalence relations. Thus, additional types besides the ones explicitly de ned by the model to OWL transformation are assigned to individuals. When looking at the mapping types presented in Sect. 4.1, one can see that these were intentionally designed to allow a reasoner to infer the information needed to synchronise the domain models.
The result of performing realisation and classi cation using Pellet is a large graph. This is the outcome of step 2. To extract information that is of interest to us, step 3 analyses this graph and extracts a tree structure. To do so, rst, all individuals and all concrete classes are collected by sending a query to Pellet. Using these two sets, we iterate over all individuals and determine their concrete classes using a SPARQL3 query. This data is the rst level of our tree structure.
Next, all secondary classes (i.e., the classes we have introduced in addition to the original classes derived from the domain meta models) are collected. To do so, again the set of all classes for each individual is determined. From this set all original classes are removed to obtain secondary classes only. These sets form the second level of the tree structure. Finally, the object and data properties for all individuals are collected and put into the third and fourth layer of the tree.
By traversing this tree structure from top to bottom we can derive the set of individuals that need to be created. These new individuals are then explicitly added to the knowledge base and the respective models. So, after step 4 a new, incrementally updated, synchronous version of the domain ontologies is obtained. For all new individuals a trace is kept. Thus, if an element is deleted in the source model, the corresponding target model elements can be removed as well.
To ensure the consistency of domain models, the constraints are checked by closed world reasoning using Pellet ICV4. By using closed world reasoning, some issues can be detected that are ignored by the checks performed before. For example, lower bounds for multiplicities are checked in this step. If a transition does have dangling reference, this is not reported by the previous checks, but will issue an error when using Pellet ICV. If no errors are detected, new individuals can be transferred to the respective models yielding a synchronous state again. For subsequent changes the procedure starts from the beginning.
Model Synchronisation and Transformation Model synchronisation can be
performed in various ways. Often ad-hoc approaches based on imperative
languages are used. These are hard to analyse and usually restricted to the
unidirectional synchronisation. Therefore declarative approaches should be favoured.
Here, one can either use pairs of unidirectional model transformation rules (e.g.,
written in Atlas Transformation Language (ATL) [
Compared to OWL, being based on Description Logics, most model
transformation approaches expose a less formal grounding. ATL does not have a formal
semantics at all. QVTR de nes its semantics by a mapping to QVT Core, but
there are still open questions and contradictions in the standard [
Ontology Matching and Alignment The ontology community has put a
lot of e ort into methods to match ontologies. The goal of that work is to
generate a mapping that formalise a common subset of concepts or terms. Di erent
approaches based on string comparison, language analysis, structural matching,
machine learning and combinations thereof [
To represent mappings we used OWL and SWRL, which does have some
drawbacks (see [
In this paper we presented an approach to synchronise models using their ontological representations. Based on existing work, models were mapped to ontologies and vice versa. To specify the synchronisation of models within the technological space of OWL, we presented several types of mappings that can be employed. Depending on the type of relation needed, either subclasses de nitions can be used to map model elements or, for more complex structural relations, SWRL rules can formalise relations between domain models. The former idea is based on the notion of sets formed by individuals of classes. Subclasses are dened to divide sets and equivalence relations map subsets to corresponding sets of individuals in the opposite domain. We de ned types of mappings that can be handled with this approach and other classes that cannot. The latter can be handled using SWRL rules, which sacri ces the bidirectionality that was available when using subclass de nitions. We have implemented the running example based on OWL and the Pellet reasoner to justify the approach practically.
In Sect. 1 our objectives were de ned as reducing speci cation e ort,
increasing intuitivity of speci cation and obtaining bidirectionality. Our results
do con rm these partially. We found the mappings based on subclass de nitions
very intuitive, but unfortunately these can only handle pairwise mappings
between individuals. Also, the need for bidirectional speci cations was met by the
subclass approach. But, more complex mappings using SWRL rules do not posses
this property. Whether speci cation e ort is reduced, cannot be determined at
this point. The technical obstacles one needs to deal with (e.g., when de ning
OWL classes instead of directly working on the meta models) are still to large
to gain bene t from the formal semantical foundation. Modelling languages with
built-in support for semantics [
To further investigate the use of ontological tool machinery for model
synchronisation, we plan to apply the mappings to an industrial case study, where
synchronisation has been realised before using model-based synchronisation tools.
The comparison of both approaches will then gain more insight about both ways
to ensure model consistency. In addition the tight integration of meta models
and formal semantics as proposed in [
In this paper we restricted ourselves to mappings that are explicitly de ned by domain experts. While this is feasible for small mappings, a lot of e ort is needed for meta models of industrial size. Therefore, using ontology matching techniques to derive initial mappings, which can then be re ned by domain experts, is another interesting objective for future research.
This research has been co-funded by the European Commission within the FP6 project Modelplex #034081 and the FP7 project MOST #216691.