Copyright © 2005 DERI®, All Rights Reserved. DERI liability, trademark, document use, and software licensing rules apply.
This deliverable describes the implementation of the editing and browsing tool as a part of an ontology management system. Based on the architecture designed in [2] it will be shown which functionalities have been realized and which components implement them.
The described tool has been realized in the shape of a java-based Eclipse plug-in (see http://www.eclipse.org). Beyond the platform independence of Java and the wide spread of the Eclipse environment also the ease of integration and reuse of those plug-ins motivated this decision.
The plug-in includes two distinct sub-tools for editing ontology schemas and knowledge bases. The rationale for this is the target of enhanced usability [3] by means of increased clarity and flexibility.
New versions of the here described implementation are always available both as a source and a binary distribution. While the former is published through the DOME module of the Sourceforge CVS server (http://cvs.sourceforge.net/viewcvs.py/dome/) the latter is provided in the shape of an installer to be downloaded from (http://dome.sourceforge.net/download.shtml).
The remainder of this deliverable is structured as follows: In section 2 the functionalities of the editing and browsing tool will be described. After that, section 3 will address the components that realize these functionalities. Finally the deliverable will be concluded in section 4.
In this section the implemented functionalities of the editing and browsing tool are described. Therefore 2.1 shows how the tool allows ontologies to be edited before 2.2 addresses the browsing part of the implementation.
The implementation described in this deliverable allows for editing of ontologies. That is, ontologies as well as their contents can be created, removed and modified. Based on the ontology language defined in [1] the four there defined ontology parts can be processed. Therefore the following sections address the editing of Concepts, Relations, Instances and Axioms.
A new concept can be created using the context menu of the class tree. After right clicking on an ontology node or a concept node the respective menu entry can be chosen. After entering a name for the resulting concept node the operation has to be confirmed by the return key.
An important part of concept definition is their placement in a hierarchy of concepts. This determination of sub- and super concept relationships can be realized through drag and drop. That is, a concept that is dragged from its current position and dropped onto another concept gets assigned this other concept as its parent. Currently only this “moving” functionality is realized while the “copy” functionality – i.e. the assignment of a new super concept by keeping the existent super concepts - will be integrated into the next version.
A further way of concept definition is the assignment of attributes and their ranges. In the described tool this can be realized by right-clicking on a concept and choosing the respective entry in a context menu. A new sub node will be added to the concept node which can be given a name as it is known from the Windows Explorer. Through dragging a concept and dropping it onto an attribute the range of this attribute can be specified.
Also the removal of concepts can be realized through the context menu. After choosing the appropriate menu entry the respective node and all its sub nodes will disappear.
The creation of relations resembles the concept creation. Either ontology or relation nodes can be right clicked to pop up the context menu.
The definition sub- and super relations is done through drag and drop. As in the case of concepts a “move” operation is performed – i.e. the former position in the hierarchy gets lost.
In order to assign parameters to relations respective sub nodes can be created through the context menu. Comparably to attributes a name can be given and confirmed. In order to set the range of a parameter a concept can be dragged and dropped onto it.
As expected, the removal of relations is performed through the context menu, as well. In doing so, all sub nodes will also get lost.
Instances can be created by right clicking the concept to be instantiated and choosing the respective context menu item. In consequence a new row will appear in the instance table. In this table the attributes are visualized through the header cells while the normal cells represent the attribute values. These can be modified through clicking on them, changing the respective text and confirming with the return key. In the next version, also instances will be assignable as attribute values.
The creation and removal of axioms can already be performed by the current implementation. The modification of the logical expressions that the axioms are defined by will be allowed in the next version of the tool.
The browsing of ontologies as allowed by the here described tool is derived from the functionality of the Windows Explorer. That is – based on a combination of a tree view and a table view – the user can explore the hierarchy of an ontology on the one side and inspect the contents of the knowledge base on the other side. The explorer concept is extended through more flexibility: The tree and the table are not integrated into one view, but exist as separate widgets. This way, the user can decide how they shall be arranged on the screen, and also the reusability of these tools is increased by far.
By clicking the “+”/”-“symbols the user can recursively expand or collapse tree nodes and thus reveal or hide ancillary contents. Beyond this, the instances of the class selected in the tree view are displayed in the table view.
All elements that may appear in an ontology schema are represented by tree nodes and can be processed respectively. The distinction of the different kinds of ontology schema and knowledge base elements is realized through different symbols in front of the item's label (see Table 1 ).
Element |
Icon |
Ontologies |
|
Concepts, Instances |
|
Relations, Relation Instances |
|
Axioms |
|
Attributes |
|
Parameters |
|
Table 1 Visual representation of ontology elements
In this section the components that realize the described functionalities are addressed. First the components visible to the user – namely the class tree, the instance table, the mapping editor and the properties view are described. After that, a closer look is taken at the underlying models, views and controllers.
As already mentioned, the editing and browsing tool was realized in the shape of a eclipse plug-in. It includes two editors and two views. While the editors are used for the modification of ontology schemas and ontology mappings, the views allow for the processing of instances and non-functional properties.
An editor in Eclipse is a file based approach for data modification. It allows for the change of file contents, signals modifications to the user and stores them only upon explicit invocation.
As can be expected from the name, the class tree (see Figure 1 ) is responsible for the schema part of an ontology. Thus beneath the ontology root nodes it displays concepts and their attributes, relations and their parameters as well as axioms. Respectively, the context menu entries are adopted for the creation, modification and removal of these entities.
The class tree extends the Eclipse multi page editor which allows for multiple views onto one file. In the current version, besides the tree view, a WSML serialization is provided as one further view. For future versions it is planned to plug-in support for more ontology languages and to provide this to the user through more tabs at the bottom edge of the editor.
Figure 1 The class tree
The mapping tree (see Figure 2) visualizes ontology mappings that stick to the mapping language described in [5]. In order to create such mappings one has to open two class tree editors and arrange them besides each other. By dragging an ontology element out of the one ontology and dropping it onto an ontology element of the other ontology a mapping rule is created and gets visualized in the mapping tree. For the deletion of such a rule, the context menu in the mapping tree can be utilized.
Also the mapping tree extends the multi page editor. As a second tab at the bottom edge of it, it offers the source of the mapping language for direct editing.
Figure 2 The mapping tree
Based on the MVC design pattern [4], an Eclipse view visualizes the data of some model - in Eclipse terms, a content provider. This data changes immediately upon user interaction, i.e. no explicit storage is required. The other way around, an update of the underlying model, from whereever it may be invoked, is reflected automatically in all of the registered views.
The instance table (see Figure 3) is the sub-tool for processing the knowledge base of an ontology. In the shape of table rows it displays instances of the concept that is currently selected in the class tree. While the header cells of the table represent the attributes, the normal cells represent their values. For editing, the respective value can be clicked, textually modified and confirmed with the return key.
Figure 3 The instance table
The NFP tree (see Figure 4) allows for the inspection and modification of non-functional properties (NFPs). Whenever an ontology or an ontology element is selected in the class tree, the NFP tree displays its non-functional properties. That is, it displays the properties in the shape of an expandable tree in the first column and the values in the respective row of the second column.
New properties can be added through the respective menu at the top right of this view. Currently only Dublin Core properties are supported. For editing of values, the respective cell can be clicked, the text can be modified and the operation can be confirmed with the return key.
So far, NFP editing for instances and relation instances is not supported, yet. In the next version, a selection of an instance or relation instance in the instance table will reveal their NFPs in the NFP tree either.
Figure 4 The NFP tree
Because the implementation of the editing and browsing tool sticks to the MVC design pattern [4] the subsequent description will be structured respectively.
The base model utilized in the editing and browsing tool is the set of ontologies currently available which is saved within an instance of the class Model (see Figure 5). From this, a model especially adopted for trees and one especially adopted for tables is derived. The table model is based on the selection in the class tree and is directly used for the instance table. The tree model gets further refined for ontology schemas on the one hand and for mapping language elements on the other hand. (Although the mapping document doesn't need to access the ontology set, it still can reuse the functionality provided by the super classes.)
org.omwg.ui.Model | |||
org.omwg.ui.models.TreeModel |
org.omwg.ui.models.TableModel |
||
ClassTreeModel |
MappingDocumentModel |
||
Figure 5 Hierarchical position of model classes
As already mentioned the editing and browsing tool utilizes a tree view and a table view (see Figure 6 ). The functionality of the Eclipse JFace framework is reused and applied in specially designed view classes - once for the class tree and once for the instance table.
org.eclipse.jface.viewers... |
|||
org.eclipse.jface.viewers.TreeViewer |
org.eclipse.jface.viewers.TableViewer |
||
org.omwg.ui.TreeView |
org.omwg.ui.TableView |
||
Figure 6 Hierarchical position of view classes
Controller objects are the ones that allow for the manipulation of the model. In the case of the editing and browsing tool this manipulation is done through context menus and via drag and drop.
The integration of the context menus is based on predefined classes and interfaces in the eclipse action package (org.eclipse.jface.action). Interfaces like the IMenuListener (gets informed when a menu is about to show) have been implemented and classes like the MenuManager (realizes itself and its items in a menu control) have been instantiated.
The drag and drop functionality utilizes the org.eclipse.swt.dnd package. A drag source adaptor, a transfer object and a drop target adaptor (see Figure 7) realize the change of the data model upon the respective mouse operations. Because of the MVC structure the view is updated automatically.
org.eclipse.swt.dnd.DragSourceAdapter |
org.eclipse.swt.dnd.ByteArrayTransfer |
org.eclipse.swt.dnd.DropTargetAdapter |
 |
||
org.eclipse.jface.viewers.ViewerDropAdapter |
||
|
||
IdentifiableDragSourceAdapter |
IdentifiableTransfer |
IdentifiableDropTargetAdapter |
Figure 7 Classes that realize the drag & drop functionality
This document described the implementation of the editing and browsing tool supposed to be part of an ontology management system. As the tool has the status of a first prototype it was described which functionalities have been realized by now and which ones will be added in subsequent versions.
The work is funded by the European Commission under the projects DIP, Knowledge Web, Ontoweb, SEKT, SWWS, Esperonto and h-TechSight; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate programme.
The authors would like to thank to all the members of the OMWG working group for their advices and inputs to this document.
[1] de Bruijn, Jos et. al. (2005): The Web Service Modeling Language WSML
[2] Henke, Jan (2004): OMWG D8.2v0.2: Design of an Editing and Browsing tool
[3] Nielsen, Jakob (1993): Usability Engineering. Morgan Kaufmann - An imprint of Academic Press
[4] Reenskaug, Trygve (1979): Models - Views - Controllers
[5] Scharffe, Francois (2005): Mapping & Merging Design
$Date: 2005/07/18 14:43:53 $
