Implementing a GUI for defining ontology/model mappings

By Stefan Beyer, Raimund Hirz, and Christopher Tunkl

Motivation

In the domains of Software Engineering and Model Engineering, models can be used to describe and document complex systems from many different viewpoints with varying levels of detail. If multiple models about the same system are created, the models might potentially contain inconsistencies and contradictions. In order to detect and eliminate such inconsistencies, a way to define constraints on how two or more specific models should relate to each other - on how some model should be mapped to another - needs to be found. While there exist countless approaches to generate such mappings in an automated or semi-automated way by using various heuristics, our task was to develop a graphical user interface for domain experts for manually specifying and modifying mappings. In our case, those models are represented as ontologies, the cornerstone of the Semantic Web. Most standard technologies used in this area make an open-world assumption, which does not allow to express such constraints. Because of that we use SPARQL, the standard query language for Semantic Web data, to build queries that act as our mapping constraints. We define those constraints on separate models which in turn describe the ontologies

Goal

Our task was to create an extensible, Java-based GUI to define mappings between instances of a given meta-model. In particular, we had to fulfill the following requirements: - The implementation must be developed in Java. Whenever possible, the JFace UI toolkit should be used. - A graphical editor should be used to enable the user to create mappings by using drag & drop or similar “direct” interaction methods. The editor should allow mapping between the elements of two distinct models. - It should be possible to open a dialog to define further constraints for a specific mapping. - The user should be able to save the entire mapping as well as all constraints in a machine-readable file format. In addition to these mandatory requirements, four optional requirements were defined: - Instead of a separate application, the mapping editor should be implemented as an Eclipse plug-in so it can be used within other Eclipse-based applications. - It should be possible to load two or more models into the editor. - The nature of a mapping should be visible directly in the editor without having to open the mapping dialog. - In addition to saving the mapping, it should also be possible to load it again.

Terms and Concepts

Amongst others, the meta-model provided to us contains three key elements: - PackageDeclaration: A collection of TypeDeclarations (similar to packages in Java). Mappings are defined between the elements of two or more PackageDeclarations. - TypeDeclaration: The equivalent of a class. It contains AttrDeclarations and AssocDeclarations. - AttrDeclaration: An attribute, consisting of a name and a type - AssocDeclaration: A reference to another TypeDeclaration AttrDeclarations and AssocDeclarations are collectively known as StructuralFeatures



We distuingish between two kinds of mappings in our editor:

SFMapping

A mapping between two or more StructureFeatures, although our implementation is restricted to AttrDeclarations. It consists of a set of arbitrary value transformations and a mapping function, which defines the specific constraints for the values. Examples for value transformers are string operations such as concatentation or mathematical operations such as addition. Mapping functions define the required relations between two or more values, such as equality or order relations.

TDMapping

A mapping between two TypeDeclarations, consisting of a mapping function. For the sake of usability, TDMappings define constraints on the set of attributes as a whole. They can be seen as shortcuts or convenience mappings. For instance, the TDAllAttrEqual required all attributes sharing the same names to have equal values. That way, the user does not have to define the equality relation between each set of same-named attributes separately. It is easily possible to add further value transformers and mapping functions.

The Editor

Our editor consists of a main canvas, which displays the TypeDeclarations from the loaded models in a similar way to an UML class diagram. On the right edge of the canvas, the tool box contains tools to define and extend mappings.



To change the type of an TDMapping, it is possible to choose one of the predefined types using the context menu of the mapping.



In order to further refine SFMappings, the user can double-click the mapping rectangle in order to open the EditSFMappingDialog. The EditSFMappingDialog consists of the following views: - the toolbox on the left side of the window, containing the lists of available value transformers and mapping functions – the attribute list at the top, listing all the attributes and associations belonging to the TypeDeclarations of the current mapping – the mapping specification in the center, showing the mapping function and all used value transformers – the SPARQL view at the bottom, displaying the specified mapping as a SPARQL query



In order to add value transformers to the mapping or to change the mapping function, the user can double-click the corresponding entry in the toolbox. When adding a value transformer, the it is possible to set its arguments by selecting attributes or other value transformers using the respective combobox. For constant arguments, a textfield is displayed instead. Whenever any changes are performed, the SPARQL query at the bottom is updated in real-time.

Future Work

Our editor is designed in a way, that it can be modified and extended quite easily. There are currently plans to enhance and integrate it into an enterprise modeling environment, which uses the described meta-model. Also we would like to encourage others to create more sophisticated user interfaces for mapping tools of all kinds in order to help end users to better understand and leverage the capabilities of those tools.