DevBooststLogotudLogorewerseLogo modelplexLogo
OWLText Logo


Syntax- and Semantics-Enabled Metamodelling


OWLText Documentation

In the following we present the foundations of OWLText.

Overview of OWLText

OWLText is a metamodelling approach that was motivated by the lack of semantics support in current metamodelling approaches. It was developed in the MOST Project that aimed at exploiting the reasoning capabilities of ontology technology in modelling and metamodelling.

OWLText integrates the technical spaces of grammar world, metamodelling world and ontology world to deliver a comprehensive approach to syntax and semantics-enabled metamodelling.

How to setup a new OWLText project

(1) Create a new EMFText project. Therefore, you can use the new project wizard. File > New > Project ... > EMFText Project. Please adapt the language name to the name of yourLanguage and other settings as required in the wizard.

(2) In the language plugin (org.emftext.language.yourLanguage) open the MANIFEST file (/META-INF/MANIFEST) and add a dependency to the plug-in "org.emftext.runtime.owltext". This plug-in contains the runtime classes of OWLText, required to transform models and metamodels to ontologies.

(3) Open the language metamodel (/metamodel/yourLanguage.ecore) and introduce the modelling concepts your language requires.

(4) Create an OWL-CS specification in your /metamodel/ folder (File > New > Other... > EMFText .owlcl file). Add OWL-CL constraints for your langauge.

(5) Reload the .genmodel (/metamodel/yourLanguage.genmodel, context menu > Reload...) to reflect the current changes in your metamodel and the OWL CL specification. In the root element of .genmodel adapt the property "Root Extends Class" to org.emftext.runtime.owltext.OWLTextEObjectImpl. This class implements a wrapper that automatically transforms any model of your language to a ontology.

(6) Open the .cs syntax specification file (/metamodel/yourLanguage.cs). Add the syntax rules for your language and the following OPTIONS:

 	overrideBuilder = "false";
 	additionalDependencies = "org.emftext.runtime.owltext";

These prevent your custom language builder from being overridden during each code-generation and the add a dependency to to the OWLText runtime.

(7) Run the code generators for EMF (root element of the .genmodel > Generate Model Code) and EMFtext (.cs file > context menu > Generate Text Resource)

(8) Open the resource plug-in of your language (org.emftext.language.yourLanguage.resource.yourLanguage). Delete the old language builder (/src-gen/org.emftext.language.yourLanguage.resource.yourLanguage.mopp/ Open the custom language builder (/src/org.emftext.language.yourLanguage.resource.yourLanguage.mopp/ There adapt the method isBuildingNeeded(...) to return true and add the following code to the method build(...):

 if (resource.getErrors().isEmpty()) {
 	OWLTextValidationMarker ovm = new OWLTextValidationMarker();
 return org.eclipse.core.runtime.Status.OK_STATUS;

This calls the ontology-based validation every time you safe an instance of your DSL and annotates the reasoning results.

(8) Deploy your language plug-ins. Finished.

You can now iteratively adapt your metamodel, OWL-CL specification and .cs specification. But don't forget to reload the .genmodel and regenerate the model code to reflect changes in the metamodel or the OWL-CL specification (see (5), (7)) and to regenerate the text resource for changes in the .cs (see (7)) specification.

For exemplary projects see the Screencasts section or the EMFText Zoo (e.g. the requirements language)

The OWLText Metamodelling Approach

The OWLText metamodelling approach

The figure on the right gives an overview of the OWLText metamodelling approach.

OWLText involves three roles for language engineers:

Metamodelling Expert The metamodelling expert specifies the language metamodel using Ecore. This metamodel is fed to the EMF, that generates a metamodel implementation.

Textual Syntax Expert The textual syntax expert specifies the languages concrete textual syntax in relation to the metamodel. He uses the CS-language provided by EMFText. Using the language metamodel and the concrete syntax specification OWLText employs EMFText to generate a parser, printer and advanced textual editor.

Ontology Expert The ontology expert specifies semantics constraints in relation to the metamodel. He uses the OWL based constraint language OWL-CL to annotate constraints and error messages. Given the language metamodel and the semantics constraints OWLText generates a component that enables the transformation of language models to an ontology representation and the application of ontology technology to validate and preserve the consistency of language models.

The combination of all generation results is considered the language implementation. Based on a seamless integration of parser, printer, editor, metamodel implementation and semantics validation the suggested approach contributes a generative way to realise a syntax- and semantics-aware DSL editor.

OWLText Technical Space Bridges

OWLText introduces and uses various technical space bridges to integrate metamodelling, textual syntax specification and semantics specification. In the following we will describe the basic architecture of these bridges

Bridging in EMFText

Integration bridge for grammar and metamodelling world.

For the integration of the grammar world and the metamodelling world OWLText integrates EMFText --- a tool for generating parsers, printers, and editors for EMF-based modelling languages. For the specification of concrete textual syntaxes EMFText provides the CS language. A metamodel for CS is given in the figure to the right. It establishes an integration bridge at the M3 metamodelling layer by referencing elements of the Ecore metamodel. Each syntax Rule is associated with an EClass it defines a textual representation for. In the rule body SyntaxElements specify individual syntactic elements of a textual representation (e.g. Keywords). A particular kind of SyntaxElement is FeatureSyntax. Each FeatureSyntax refers to a specific EStructuralFeature in the metamodel to define its textual representation. For containment EReferences in the metamodel a Containment element defines a syntax non-terminal. At this point the parser would descend to the syntax rules defined for EClasses that match the type of the corresponding EReference. For non-containment EReferences and EAttributes a Placeholder element needs to be given, which specifies a grammar terminal to represent reference or attribute values.

As depicted in the figure below, this M3 integration bridge, is applied at M2 to specify textual syntax for language metamodels. Based on the coupling between syntax specification and metamodel EMFText can automatically generate M2 transformation bridges (parser and printer) that are then applied at M1 to synchronise textual and model-based representations of language expressions.

Overview of integration and transformation bridges applied in OWLText.

Bridging for OWL-CL

Integration bridge for ontology and metamodelling world.

For the integration of the ontology world and the metamodelling world OWLText provides the OWL-CL Bridge. The language OWL-CL is used to specify semantic constraints against a given metamodel. The metamodel for OWL CL is depicted in the figure above. OWL-CL uses a combination of two M3 integration and two M3 transformation bridges. One M3 integration bridge connects each OWL-CL Constraint to a constrained EClass. To enable the definition of constraints each Constraint contains to OWL2 to class Descriptions in OWL2 Manchester syntax. As these class descriptions are meant to be defined against the ontology that corresponds to the language metamodel the so-called OWLizer is used as M3 transformation bridge. The OWLizer transparently translates the language to an ontology TBox and OWL-CL constraints are defined against the OWLClasses, ObjectProperties and DataProperties of this TBox. A second M3 transformation bridge is used to incorporate the consistency constraints defined with OWL-CL as consistency classes to the ontology TBox. This bridge is implemented as extension to OWLizer.

As depicted in the figure above that explains the application of all OWLText bridges, the M3 bridges implemented with OWL-CL can be applied at M2 to specify language semantics constraints. Given such OWL-CL based constraint definition the OWL-CL Bridge parameterises a M2 transformation bridge that is applied at M1 for semantics validation. The M2 bridge transforms model-based representations of language expressions, the language metamodel, and the languages constraints to an integrated ontology. Finally, a generated semantics validation component uses reasoning services to find constraint violations in this ontology and to propagate errors back to the corresponding model elements.

Generation and Application of an Advanced DSL Editor

Exemplary DSL Editor with semantic error annotations generated by OWLText

Given these three specifications the language engineer uses the generators provided by OWLText to derive a language implementation. This implementation provides an advanced textual editor for the DSL that integrates reasoning technology to enable semantics- and syntax-aware modelling for language users. An exemplary, fully generated editor is depicted in the figure to the right.

It shows a specification written in an exemplary petrinets DSL that contains inconsistencies. When language users specify a petrinet in the depicted editor OWLText automatically translates the textual representation to a model and then to an ontology. A reasoner is used to find ontology concepts that invalidate the semantic constraints provided with OWL-CL and annotates the given error messages to the corresponding model elements. These annotations are shown to language users as error markers in the petrinets editors. This example indicates the potential of a tight integration of several technical spaces provided by OWLText and the advanced tool support that can be provided.