Introduction
This deliverable describes the implementation of an editing and browsing tool as a part of an ontology management system. Based on the architecture designed in [1] I show 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 are described. After that, section 3 addresses the components that realize these functionalities. Finally the deliverable is concluded in section 4.
Functionalities
In this section the editing and the browsing functionality are described. Hereby 2.1 focusses on ontology elements before 2.2 addresses document elements.
Editing and Browsing of Ontology Elements
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 [2] the four there defined ontology parts can be processed. Therefore the following sections address the editing of Concepts, Relations, Instances and Axioms.
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.
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 concept 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
Concepts
A new concept can be created using the context menu of the concept 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 a later 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 is 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. Beyond this, the specification of data type ranges and further attribute properties (constraining, reflexive, symmetric, transitive) can be invoked through the context menu.
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 disappear.
Relations
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 of 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. In contrast to attributes no name can be given as parameters only get numbered. In order to set the range of a parameter a concept can be dragged and dropped onto it. Also here, data type ranges and a further property (constraining) can be set through the context menu.
As expected, the removal of relations is performed through the context menu, as well. In doing so, all sub nodes also get lost.
Instances
Instances can be created by right clicking the concept to be instantiated and choosing the respective context menu item. In consequence a new row appears 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 values in a pop-up dialog and confirming with the return key. This includes both referring to instances as well as specifying literal values.
Axioms
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 a later version of the tool.
Editing and Browsing of Document Elements
Document Elements refer to WSML elements which are variants, namespaces and headers. Headers again include NFPs, imports and mediators. NFPs are not addressed at this point as they are processed in a separate view and described in a later section. The visual representation of document elements is shown in table 2.
| Element | Icon |
| Namespaces |  |
| Imports | |
| Mediators | 
|
Table 2 Visual representation of document elements
WSML Variants
The Web Service Modeling Language (WSML) is built up of different layers called Core, DL, Flight, Rule and Full. Respectively, a combo box in the editor can be used to select the desired one. This selection determines against which variant the model is validated.
Namespaces
A namespace determines a location where vocabulary is defined. To increase usability, prefixes can be used to refer to such locations without much typing. Respectively, the processing of namespaces in the editor means to create objects that consist of a prefix string and an IRI that belongs to it. For convenience reasons the tool allows for the renaming of namespaces although they are immutable by nature. This means, whenever a namespace is renamed, internally it is removed and a new one is created.
Imports
WSML supports importing of ontologies in order to easily allow for reuse. The editor displays such imports like normal ontology nodes except that no sub nodes are revealed.
Mediators
A mediator can mediate between ontologies, goals and web services. Inside the editor, so far they can be created, renamed and removed.
Components
In this section the components that realize the described functionalities are addressed. First the components visible to the user namely the ontology editor, the mapping editor and the NFP view are described. After that, a closer look is taken at the underlying models, views and controllers.
User interface components
As already mentioned, the editing and browsing tool was realized in the shape of a eclipse plug-in. It includes two editors and one view. While the editors are used for the modification of ontologies and mappings, the view allows for the processing of non-functional properties.
The Ontology Editor
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. The ontology editor is depicted in figure 1.
Figure 1 The Ontology Editor
The concept tree (see the upper part) is responsible for the schema 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 instance table (see the lower part) 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 concept 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, modified in a pop-up dialog and confirmed with the return key.
At the top of the editor, the WSML variant as well as a mapping operator can be determined. Beyond this, it can be selected which elements shall be displayed.
The ontology editor 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.
The Mapping Editor
The mapping editor (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 concept 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 editor. For the deletion of such a rule, the context menu in the mapping tree can be utilized.
Also the mapping editor 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 editor
The NFP View
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 wherever it may be invoked, is reflected automatically in all of the registered views.
The NFP view (see Figure 3) allows for the inspection and modification of non-functional properties (NFPs). Whenever an ontology or an ontology element is selected in the ontology editor, the NFP view 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. 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.
Figure 3 The NFP view
Underlying components
Because the implementation of the editing and browsing tool sticks to the MVC design pattern [4] the subsequent description is structured respectively.
Model
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 concept 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
View
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 concept 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
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 and drop functionality
Conclusions
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.
I show 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 are described. After that, section 3 addresses the components that realize these functionalities. Finally the deliverable is concluded in section 4.
Functionalities
In this section the editing and the browsing functionality are described. Hereby 2.1 focusses on ontology elements before 2.2 addresses document elements.
Editing and Browsing of Ontology Elements
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 [2] the four there defined ontology parts can be processed. Therefore the following sections address the editing of Concepts, Relations, Instances and Axioms.
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.
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 concept 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
Concepts
A new concept can be created using the context menu of the concept 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 copyfunctionality i.e. the assignment of a new super concept by keeping the existent super concepts - will be integrated into a later 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 is 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. Beyond this, the specification of data type ranges and further attribute properties (constraining, reflexive, symmetric, transitive) can be invoked through the context menu.
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 disappear.
Relations
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 of 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. In contrast to attributes no name can be given as parameters only get numbered. In order to set the range of a parameter a concept can be dragged and dropped onto it. Also here, data type ranges and a further property (constraining) can be set through the context menu.
As expected, the removal of relations is performed through the context menu, as well. In doing so, all sub nodes also get lost.
Instances
Instances can be created by right clicking the concept to be instantiated and choosing the respective context menu item. In consequence a new row appears 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 values in a pop-up dialog and confirming with the return key. This includes both referring to instances as well as specifying literal values.
Axioms
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 a later version of the tool.
Editing and Browsing of Document Elements
Document Elements refer to WSML elements which are variants, namespaces and headers. Headers again include NFPs, imports and mediators. NFPs are not addressed at this point as they are processed in a separate view and described in a later section. The visual representation of document elements is shown in table 2.
| Element | Icon |
| Namespaces | |
| Imports | |
| Mediators |
|
Table 2 Visual representation of document elements
WSML Variants
The Web Service Modeling Language (WSML) is built up of different layers called Core, DL, Flight, Rule and Full. Respectively, a combo box in the editor can be used to select the desired one. This selection determines against which variant the model is validated.
Namespaces
A namespace determines a location where vocabulary is defined. To increase usability, prefixes can be used to refer to such locations without much typing. Respectively, the processing of namespaces in the editor means to create objects that consist of a prefix string and an IRI that belongs to it. For convenience reasons the tool allows for the renaming of namespaces although they are immutable by nature. This means, whenever a namespace is renamed, internally it is removed and a new one is created.
Imports
WSML supports importing of ontologies in order to easily allow for reuse. The editor displays such imports like normal ontology nodes except that no sub nodes are revealed.
Mediators
A mediator can mediate between ontologies, goals and web services. Inside the editor, so far they can be created, renamed and removed.
Components
In this section the components that realize the described functionalities are addressed. First the components visible to the user namely the ontology editor, the mapping editor and the NFP view are described. After that, a closer look is taken at the underlying models, views and controllers.
User interface components
As already mentioned, the editing and browsing tool was realized in the shape of a eclipse plug-in. It includes two editors and one view. While the editors are used for the modification of ontologies and mappings, the view allows for the processing of non-functional properties.
The Ontology Editor
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. The ontology editor is depicted in figure 1.
Figure 1 The Ontology Editor
The concept tree (see the upper part) is responsible for the schema 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 instance table (see the lower part) 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 concept 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, modified in a pop-up dialog and confirmed with the return key.
At the top of the editor, the WSML variant as well as a mapping operator can be determined. Beyond this, it can be selected which elements shall be displayed.
The ontology editor 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.
The Mapping Editor
The mapping editor (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 concept 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 editor. For the deletion of such a rule, the context menu in the mapping tree can be utilized.
Also the mapping editor 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 editor
The NFP View
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 wherever it may be invoked, is reflected automatically in all of the registered views.
The NFP view (see Figure 3) allows for the inspection and modification of non-functional properties (NFPs). Whenever an ontology or an ontology element is selected in the ontology editor, the NFP view 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. 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.
Figure 3 The NFP view
Underlying components
Because the implementation of the editing and browsing tool sticks to the MVC design pattern [4] the subsequent description is structured respectively.
Model
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 concept 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
View
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 concept 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
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 and drop functionality
Conclusions
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.
Acknowledgement
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.
Appendix A. References
[1] Henke, Jan (2004): OMWG D8.2v0.2: Design of an Editing and Browsing tool
[2] Lausen, H.et al.WSML - a Language Framework for Semantic Web Services. W3C Workshop on Rule Languages for Interoperability, Washington DC, USA (2005)
[3] Nielsen, Jakob (1993): Usability Engineering. Morgan Kaufmann - An imprint of Academic Press
[4] Reenskaug, Trygve (1979): Models - Views - Controllers
[5] Scharffe, François and de Bruijn, Jos. A Language to Specify Mappings between Ontologies. In IEEE SITIS'05, Yaoundé, Cameroon, November 27th - December 1st, 2005