Ontologies have become increasingly relevant to the modelling community, providing a knowledgebase to support several software engineering activities. As such, several e orts have been made to integrate ontology technology with modelling technology. This has resulted in the Ontology De nition Metamodel (ODM), which allows model transformation languages to interact directly with ontologies. The ODM limits itself to data structure, however, and does not integrate the reasoning capabilities within ontologies. Therefore, we have done an experiment with an OWL DL driver for ATL, where ATL has direct access to the reasoning capabilities of the OWL DL ontology language. OWL DL is used as a metamodelling framework, where OWL classes serve as metaclasses and OWL individuals serve as model elements. The envisioned bene ts are optimisation possibilities through automatic classi cation, and static analysis of ATL transformations written using OWL DL expressions. This paper will discuss our ndings so far regarding these two envisioned bene ts.
Ontologies are becoming more and more prominent, and they can provide a
supporting knowledgebase for several software engineering activities, such as
domain engineering [
The envisioned bene ts of using OWL DL as a metamodelling framework are optimisation possibilities through automatic classi cation of OWL DL class expressions, and static analysis of ATL transformations written using OWL DL expressions. In the remainder of this paper, we will rst discuss the development of the OWL4ATL driver, and our ndings of mapping the ATL metamodelling constructs onto OWL DL constructs. Then, we will discuss our ndings so far regarding the two envisioned bene ts. 2
OWL4ATL The ATL virtual machine allows for de ning new drivers that implement ATL's model and metamodel abstractions. We've implemented such a driver for OWL DL1, which maps metaclasses onto OWL classes and model elements onto OWL individuals. Table 1 shows how ATL's main language constructs for (meta-) model representation are mapped onto OWL language constructs, with the implementing Java classes in parentheses. ATL's primitive data types are mapped onto the closest XSD data types used by OWL.
2.1
As the OWLAPI does not provide a metacircular implementation of OWLClass (where OWLClass is an instance of OWLClass) in the OWL DL language, the metametamodel must be implemented separately. This has not yet been done, and as a result only M2 models can be used as metamodels. This means that OWL ontologies of instances can be transformed, using OWL ontologies of classes as metamodels. As a consequence, we've used the Eclipse EODM2 implementation of the ODM to generate an initial metamodel in OWL, consisting of OWL classes. As an example metamodel, we've used the Eclipse UML metamodel, as it covers all features of the EMF Ecore metamodelling language. The ATL transformation module used is called \ECORE2OWL.atl", the resulting metamodel \ontologies/UML.owl", which can both be found at http://soft.vub.ac.be/viewvc/ATL/OWLMatching/.
During the mapping of the UML metamodel to OWL, some of the semantic di erences between Ecore and OWL became apparent: { OWL properties are de ned within the namespace of the ontology, not the namespace of the OWL class on which one can de ne property values. Whereas Ecore EAttributes and EReferences are de ned within the namespace of a single EClass, OWL properties have a domain and a range. The domain speci es all OWL classes for which one can de ne property values, and the range speci es the valid types of the values. The domain of an EReference or EAttribute is always limited to a single EClass. When mapping only from Ecore to OWL, it is su cient to add the name of the domain class to the property name to make sure the OWL property has a unique name within the ontology. { OWL properties do not support containment. EMF models are in the form of a containment tree, where EReferences can be de ned as containment references. OWL does not support the concept of containment, other than ontology elements being contained in an ontology (namespace). In order to retain the information of whether an OWL property represents a containment EReference, four \meta-properties" are introduced in the ontology: \allContainment", \allContainer", \containment", and \container". \allContainment" is a transitive property and represents the transitive closure of contained model elements. \allContainer" is a transitive property that represents the transitive closure of containing (parent) model elements. \containment" and \container" are non-transitive subproperties of \allContainment" and \allContainer", and represent the direct contained and containing model elements. All containment properties are represented as subproperties of \containment", and all container properties are represented as subproperties of \container". The OWL subproperty relationship means that each value of a subproperty can also be considered as a value of its superproperties. For example, any value of the UML \packagedElement" property is also a value of the \containment" and \allContainment" property. This 2 http://www.alphaworks.ibm.com/tech/semanticstk representation also allows for the implementation of the ATL \refImmediateComposite()" helper method. 2.2
Bridging the above semantic di erences between Ecore and OWL is su cient to create an OWL representation of the UML metamodel expressed in Ecore. It is also possible to copy a UML model based on Eclipse UML to an ontology based on the generated UML meta-ontology. Another, more fundamental semantic difference became apparent when trying to copy that UML ontology to another UML ontology: { OWL DL follows the Open World Assumption, whereas Ecore follows the Closed World Assumption. This basically comes down to the principle that OWL DL assumes the available knowledge to be incomplete, whereas Ecore assumes it to be complete. The concrete issue that rises here is whether or not a model element can be considered an instance of a speci c class. In Ecore, declaring a model element to be an instance of a metaclass is su cient to know that it is only an instance of that metaclass (and its superclasses). In OWL DL, however, one must explicitly state that an individual is not an instance of a certain class. A partial solution for bridging this di erence is to assert each new OWL individual as an instance of its OWL class, as well as of the complement of each subclass of that OWL class.
The ATL transformation rules that triggered this issue is the following: rule Model { from s : UML2 ! Model to t : UML2 ! Model (
...) } } rule Package { from s : UML2 ! Package (s. oclIsTypeOf ( UML2 ! Package )) to t : UML2 ! Package ( ...)
The Model rule copies all instances of the \Model" metaclass, and Package copies all instances of \Package". The Package rule explicitly checks that it does not accidentally copy \Model" instances, as \Model" is a subclass of \Package" in the metamodel, and would otherwise trigger the Package rule. In OWL DL, any instance s of \Package" must explicitly be marked as not an instance of \Model" for the reasoner to conclude that s.oclIsTypeOf(UML2!Package) is false.
A complete solution to the Open World vs. Closed World Assumption problem would require additional \closing" assertions to be added to the OWL representation of the metamodel: { Each pair of OWL classes that do not have a common sub- or superclass must be declared disjoint. This enforces that OWL individuals are considered not to be instances of other classes than its asserted class, or superclasses of its asserted class. This follows the general semantics of metamodelling languages such as Ecore. This cannot be done statically, as Ecore models and OWL ontologies can both be extended with new classes. Multiple inheritance may cause a pair of classes that previously had no common subclasses to now have common subclasses. Currently, OWL4ATL does not address this issue. 2.3
Up to this point, the experiment has remained limited to OWL class/property expressions that re ect Ecore expressions. ATL uses OCL to navigate over metamodels and express restrictions on from statements. OWL DL provides its own language constructs for expressing restrictions. Consider the following example ATL rule, which transforms all UML Properties that are public: rule PublicProperty { from s : UML2 ! Property (
s. oclIsTypeOf ( UML2 ! Property ) and s. visibility = # public ) to t : UML2 ! Property (
...) }
In OWL DL, this OCL restriction can be written as an OWL class expression in extended OWL Manchester syntax: PublicProperty subClassOf Property PublicProperty equivalentWith ( ( Property_visibility value " public ") and not ExtensionEnd and not Port )
This means that PublicProperty is the set of all Property instances that have Property visibility set to \public" and are not an ExtensionEnd or a Port (the subclasses of Property). As this expression is encapsulated as an OWL class, it can be used from ATL as follows: rule PublicProperty { from s : UML2 ! PublicProperty to t : UML2 ! Property (
...) } } rule AllProperty { from s : UML2 ! Property (
s. oclIsTypeOf ( UML2 ! Property )) to t : UML2 ! Property ( ...)
The OWL DL reasoner also automatically classi es OWL class expressions in the inferred class hierarchy. Consider the following ATL rule and its OWL representation: AllProperty subClassOf Property AllProperty equivalentWith (not ExtensionEnd and not Port )
The OWL DL reasoner would classify PublicProperty as a subclass of AllProperty, which in turn is a subclass of Property. Based on the inferred OWL class hierarchy, we can derive whether there is any overlap between the from parts of ATL rules. Overlap is not allowed between separate matched rules, while overlap is required between a super- and subrule in ATL. 3
This paper has presented an experiment with using OWL DL as a metamodelling framework for ATL. The experiment is still in progress, but some results are already available. First of all, the development of the OWL4ATL driver that enables the use of OWL DL within ATL has uncovered several semantic differences between a regular metamodelling language, such as Ecore, and OWL DL. Two of these di erences are structural di erences, regarding namespaces and containment of elements, and can be bridged without many problems. Another di erence is the Open World vs. Closed World Assumption, which is a fundamental di erence in language semantics. The result is that complex mappings are required between regular metamodelling and OWL DL in order to represent the same modelling language. A start has been made with providing these mappings, but more mappings are required. Some of these mappings are also dynamic, and can change as the metamodel is extended. Whether or not these mappings are needed, depends on whether one wants to represent a regular metamodel in OWL DL, or whether one just wants to use an existing OWL DL ontology as a metamodel (and retain the Open World Assumption).
The rst envisioned bene t of using OWL DL as a metamodelling framework is the possibility to optimise through automatic classi cation of OWL DL class expressions. We have demonstrated how OWL DL class expressions can be used in the from part of an ATL rule. ATL currently relies on caching of helper attributes to achieve a performance speedup. This only works if the developer uses helper attributes in the right places. By using OWL DL class expressions, the OWL DL reasoner can use its inferred class hierarchy to make smart assumptions about the instances of the classes. A subclass will have no more instances than its superclass, for example. We currently don't know if the OWL DL reasoner can be more e cient in nding class instances that ATL using helper attribute caching. We do know that current OWL DL reasoners have a limit in how many class equivalence expressions in combination with property restriction expressions they can handle, which lies somewhere below 1000. This puts a limit on the complexity of the transformation module.
The second envisioned bene t is the ability to perform static analysis of ATL
transformations written using OWL DL expressions, similar to what is currently
done in graph transformation using critical pair analysis [
The author would like to thank Ragnhild Van Der Straeten, Ulrike Sattler, and Carsten Lutz for their discussion on mapping regular MOF/Ecore style metamodelling languages onto OWL DL, and using OWL DL as a metamodelling framework in a model transformation context.