In this section, we evaluate the ontology-based approach to RTE that was presented in Chap. 7 using an example scenario from [212]. This work was jointly performed with Federico Rieckhof and parts thereof have been published in [199].
9.3.1 Scenario Description
To evaluate the ontology-based RTE approach, we used a scenario where two domain models need to be kept in sync. This scenario is taken from [212]. The involved domains are Petri nets [219] and toy trains. The goal of the synchronization is to make sure the Petri net model implements the dynamic semantics of the train model.
The metamodel for Petri nets is shown in Fig. 9.8(a). Each Petri net consists of a set of arcs and nodes. Arcs connect nodes in a given direction. Nodes are either places or transitions. The former can hold multiple tokens. A constraint, which is not depicted in Fig. 9.8(a), forbids that arcs connect two places or two transitions. The types of the
9.3 Synchronizing Domain-specific Models using OWL and SWRL
Name Petri net elements Toy train elements
Petrinet2Project PetriNet Project
Place2Out Place Out
Transition2In Transition In
Connection2Arc Connection Arc
(fromOuttoIn port) (fromPlacetoTransition)
Track2Arc Track Arc
(fromIntoOut port) (fromTransition toPlace)
SwitchA2Arc Switch Two Arcs, one Transition,
(with oneIn and two Outports) and two Places
SwitchB2Arc Switch ThreeArcs, oneTransition,
(with twoIn and one Outport) and one Place Table 9.1: Mappings between Petri nets and toy train models.
connected elements must be different. In addition, Petri nets, arcs, nodes and tokens have a name.
The metamodel for toy trains is depicted in Fig. 9.8(b). Each toy train project consists of components and connections. Components can be either tracks or switches and expose ports. Connections connect ports. Here, the direction is given by making a distinction between ports of type Inand Out. Tracks have exactly one incoming and one outgoing port, whereas switches can have two ports of the same type (i.e., either two Inand one Outport or vice versa). Furthermore, trains 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 Inports to transitions. Similar to tracks, connections between ports are related 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. In total, six mappings are required, which are summarized in Table 9.1.
To give an example of a pair of synchronized models, consider the models that are shown in Fig. 9.9. The figure uses concrete graphical syntax for both models. To make the mapping more obvious the components of the toy train model (shown in Fig. 9.8(b)) are also depicted in gray shade in Fig. 9.9. This way it is easier to see which parts of the Petri net correspond to which parts of the train model.
As the example is taken from a paper on the TGG formalism [212], one can derive that the synchronization at hand can be solved using a set of bidirectional transformation rules. Now, the question is, to what extent ontology tools can perform the same task.
9 Evaluation
Y
I
Y
IY
Transition Place Arc In Port Out Port Track Switch ConnectionFigure 9.9: Example of synchronized Petri net (left) and toy train model (right).
9.3.2 Applying the Approach Prerequisites
To use tools that are capable of reading and processing OWL ontologies and SWRL rules, the metamodels from Fig. 9.8 must be translated to respective ontologies. To do so, we used the OWLizer tool developed within the MOST project1. The OWLizer takes Ecore metamodels and produces corresponding ontologies in OWL Manchester syntax. As discussed in Sect. 5.4, we obtain disjoint OWL classes for all metaclasses, object properties for all defined references and data properties for all attributes. In addition, the OWLizer is capable of transforming models to sets of OWL individuals and corresponding facts. Thus, transferring metamodels and their instances to the ontology space was easy to achieve.
The complete ontologies of both metamodels, as they are produced by the OWLizer, can be found in Appendix A2. For the sake of readability, we will omit the prefixes for all features that have unique names in the following. For example, we will usesource instead of Arc_source, as there is no second feature named source.
Synchronization Rules
To capture the synchronization rules between Petri nets and toy trains models we used both OWL subclass definitions and SWRL rules. The former were employed to map Petri net elements to toy train projects, places toOutports, and transitions toInports. Thus, they cover the mappings Petrinet2Project, Place2Out and Transition2In. The concrete subclass definitions can be found in Listing 9.1.
1 Class: Petrinet2Project EquivalentTo: PetriNet, Project SubClassOf: owl:Thing
2 Class: Place2Out EquivalentTo: Place, Out SubClassOf: owl:Thing
3 Class: Transition2In EquivalentTo: Transition, In SubClassOf: owl:Thing
Listing 9.1: OWL subclass definitions for Petri net and toy train models.
9.3 Synchronizing Domain-specific Models using OWL and SWRL
The definition of these subclasses is straightforward, because there is a simple 1-to-1 mapping between these classes. To express the more complex relations in the evaluation scenario, we employed SWRL rules. In particular, if multiple model elements must form a pattern to represent one or more concepts of the opposite domain, SWRL rules are feasible. The mappings Connection2Arc, Track2Arc, as well as SwitchA2Arc and SwitchB2Arc are examples for such a cases in our evaluation scenario.
To illustrate how rules for these mappings can be designed, let us first consider the Track2Arc mapping. Here, the fact that whenever a Petri net contains an arc that connects a transition to a place, a corresponding track must exist, can be expressed using the following rule:
Arc(?x) ∧ P lace(?y) ∧ T ransition(?z)∧ (9.1) target(?x, ?y) ∧ source(?x, ?z) →
T rack(?x) ∧ Out(?y) ∧ In(?z)∧ ports(?x, ?y) ∧ ports(?x, ?z)
One can read rule 9.1 as follows. All individuals of type Arc, which are related with one place and one transition by the object propertiestargetandsource, imply that the individuals of type Arc are also of type Track, the individuals of typeTransition are also of typeInand that the individuals of typePlaceare also of typeOut. Furthermore, the object property portsmust connect the track with its ports.
As rule 9.1 does only work in one direction, a second rule is required 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:
T rack(?x) ∧ Out(?y) ∧ In(?z)∧ (9.2)
ports(?x, ?y) ∧ ports(?x, ?z) → Arc(?x) ∧ P lace(?y) ∧ T ransition(?z)∧
target(?x, ?y) ∧ source(?x, ?z)
As one can see, both a forward and a backward rule is needed to synchronize individ- uals of typeTrackfrom the toy train metamodel. Using rule 9.1 and rule 9.2, a reasoner is able to infer the synchronization in both directions. The need for two rules confirms that SWRL rules can only work in one direction, that is, they are not equivalent to bidi- rectional model transformations. Rather, they provide means to realize unidirectional incremental transformations.
The rules 9.1 and 9.2 establish the Track2Arc mapping. If we closely inspect the mappings between the two domains (cf. Table 9.1), we can find other mappings (e.g., SwitchB2Arc) that can interfere. Similar to tracks, switches with two incoming ports
9 Evaluation
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 (Connections2Arc). Obviously, we need to distinguish between arcs that represent tracks, arcs that correspond to switches and arcs that are related to connections.
To do so, we must take the relations of the arcs into account. The Connection2Arc mapping applies exactly if arcs connect places to transitions. If arcs point in the opposite direction (i.e., from transitions to places), they must be mapped to a track. However, one must be careful here, because this applies only if the respective transition does have at most one outgoing and at most one incoming arc. Otherwise, the transition is part of a pattern that corresponds to a switch.
To ease the specification of SWRL rules that implement this logic, we decided to add two helper rules, which compute whether a transition has multiple incoming or outgoing arcs. The result is then stored in a data propertyhasMultipleIncomingArcs andhasMultipleOutgoingArcs respectively. The two helper rules are as follows:
T ransition(?t) ∧ Arc(?a1) ∧ Arc(?a2)∧ (9.3) target(?a1, ?t) ∧ target(?a2, ?t)∧
dif f erentF rom(?a1, ?a2) → hasM ultipleIncomingArcs(?t, true)
T ransition(?t) ∧ Arc(?a1) ∧ Arc(?a2)∧ (9.4) source(?a1, ?t) ∧ source(?a2, ?t)∧
dif f erentF rom(?a1, ?a2) → hasM ultipleOutgoingArcs(?t, true)
Using these two helper rules, one can specify all remaining mappings without any conflicts. To give an example, consider the rule for mapping arcs to switches of type A (i.e., switches that have twoOutports):
Arc(?x1) ∧ Arc(?x2) ∧ T ransition(?z)∧ (9.5) P lace(?y1) ∧ P lace(?y2)∧
source(?x1, ?z) ∧ source(?x2, ?z)∧ target(?x1, ?y1) ∧ target(?x2, ?y2)∧ hasM ultipleOutgoingArcs(?z, true) → Switch(?x1) ∧ Out(?y1) ∧ Out(?y2) ∧ In(?z)∧ ports(?x1, ?y1) ∧ ports(?x1, ?y2) ∧ ports(?x1, ?z)
9.3 Synchronizing Domain-specific Models using OWL and SWRL
Here we use the data property hasMultipleOutgoingArcs to make sure that only patterns are matched that actually correspond to switches of type A.
9.3.3 Discussion Applicability
Applying our ontology-based model synchronization approach to synchronize Petri nets and toy train models was feasible. We were able to realize all required mappings using OWL subclass definitions and SWRL rules. However, the mappings that were formalized using the latter specification mechanism, required two rules—one for each transformation direction. For the scenario at hand, we did not experience any problems w.r.t. expres- sivness, but this may not be the case for other synchronization applications.
Transferring models to the ontological space was easy since the existing OWLizer tool provided the required functionality. Both Ecore metamodels and models were translated to respective OWL ontologies.
Gained Benefits
During the design of the SWRL rules, we discovered one major benefit that can be gained from employing DL. We successively extended the set of rules and the example models that were used to check the correctness of the synchronization. Throughout this process, the Pellet reasoner detected inconsistencies among the set of rules—multiple times. For example, first sets of our rules were conflicting, because the constraints of the number of incoming and outgoing arcs for transitions were missing. Both rules to map arcs to tracks and to map them to switches were applicable. Thus, the reasoner inferred both types and issued an exception, because the types Track and Switch are declared to be disjoint. We found this consistency checks for rules particularly useful.
For other model transformation languages, the very same problem can be observed if rules overlap. If multiple transformation rules expose patterns which are not disjoint, multiple rules can match the same input. This is usually resolved by assigning priorities to rules, but often not detected automatically. More sophisticated transformation for- malisms allow to perform a critical pair analysis [220] to detect such problems instantly (i.e., before the actual execution of the rules).
Discovered Drawbacks
Having said that the detection of inconsistencies in our ontologies was beneficial, we must add that the explanations given by the reasoner were not always very helpful. Pellet gives the set of all axioms that cause the inconsistency, but in general this set can be very large. Thus, resolving the problem did often involve tedious inspections of the rules.
9 Evaluation
Moreover, ontologies were reported to be inconsistent if structural errors were present (e.g., if an object property is assigned to individual of the wrong type—a type that is not in the domain of the property). Such errors cannot occur when creating models, because their abstract syntax does not allow this. Ontology tools should similarly report such errors as syntactic problems rather than as inconsistencies.