OWLizer

Developped during the MOST Project.

Based on OWLText.

Features

• Translates any model based on Ecore into an ontology that contains the information of the model.
• Distinguish between metamodel translation which creates classes and properties only and model transformation where the resulting ontology can contain individuals as well as classes and properties.
• Integration in the project explorer's context menu to start transformation.

Update-Site

http://st.inf.tu-dresden.de/owlizer/

Usage

To use the OWLizer, there are two ways:

1. Use it unmodified, i.e. out of the box. With this approach, it is possible to transform any (ecore-based) model into an ontology. To start a transformation, first install the plugins from the update-site. Then right-click on the file containing the model to transform and choose Transform Model to OWL in the context menu. After finishing, there will be a new file with the name name plus the additional extension owl, located in the same folder.
   Additionally, a metamodel (always assumed to have the ecore file extension) can be transformed seperatly choosing Transform Metamodel to OWL from the context menu. In either case, all imported models will be transformed as well and saved in the same directory.

2. If the default transformation algorithmn does not create the desired result, one can adapt the behaviour as follows. First create a subclass of org.emftext.runtime.owltext.transformation.Ecore2Owl. This is not strictly necessary, but will ease the use of the new behaviour.
   To define a new transformation algorithmn, create a class implementing the interface org.emftext.runtime.owltext.transformation.TransformationStrategy and start the transformation, call either Ecore2Owl.transform(Collection, TransformationStrategy) or Ecore2Owl.transformMetamodel(EPackage, URI, TransformationStrategy) and pass an instance of the newly created strategy class.

   This interface requires four methods to be implemented, but one of them, transformEObject(EObject), is the most important, as it defines the way how each object encountered during parsing of the model will be transformed. The other methods include a pre-, a postprocessor method and a way to make the necessary data available to the strategy.
   In the class Ecore2Owl, there are already two default strategies implemented, which are used by this class to perform the two different transformation scenarios (model and metamodel). If there are only small changes needed to fulfill the desired transformation, one can also subclass these default strategies, e.g. changing the way how EAttributes are transformed.

   To describe the different objects, which an ontology can have (including the ontology itself), a seperate language is used. This language is generated from a metamodel and can be found in the org.emftext.language.owl plugin or at http://www.emftext.org/index.php/EMFText_Concrete_Syntax_Zoo_OWL2_Manchester. Internally, it uses the OWL-API, but it has also a parser and pretty-printer generated to easily store the modelled ontology.

   Using this way to transform models into an ontology, an extra UI-plugin has to be created, which uses the created subclass of Ecore2Owl.