Introduction
As described in [4] our Ontology Management system shall support the functionalities of Versioning, Mapping & Merging and Editing & Browsing. This document is regarding the editing and browsing part. In more detail the architecture of an editing and browsing tool will be designed based on identified requirements and allowing for a subsequent implementation.
The remainder of the deliverable is structured as follows: Section 2 describes the provided functionalities before section 3 addresses the components through which they are offered. Finally the deliverable is concluded in section 4.
Functionalities
In this section the functionalities to be offered by the editing and browsing tool are described.
Basic functionalities
In this section we detail the functionalities of an editing and browsing tool. This includes the editing of classes and instances as well as the browsing of schemas and knowledge bases.
Editing classes
A class is described by its properties, i.e. its attributes. Thus the editing functionality has to allow for the changing of attributes. An attribute is defined by the values it permits, i.e. its range. Beyond attributes, a class is defined by its position in the class hierarchy. Changing the hierarchy should be realized graphically – that is, the user should be enabled to drag classes to new hierarchical positions. Similarly, relations are defined through their parameters and their hierarchical position. They should be treated equally.
Editing instances
Instances are described by their attribute values. Depending on whether a certain value is literal or a resource, it can be changed by direct entry or by selecting from a resource list. Beyond attribute values an instance is described by its class memberships. To change this, the user should be allowed to select from the hierarchy of available classes. This is comparable to the “select directory” dialogs known from operating systems. Relation instances are defined through their parameter values and relation memberships. Therefore they should be treated similarly.
Browsing available schemas and knowledge bases
As we identified earlier, the editing and browsing tool requires the functionality of browsing available ontology schemas. That is, given a certain repository, the included ontology schemas should be presented to the user. They are represented by the parts of the identifying URIs. The last node in such a hierarchy should be labeled with a human-readable name of the respective ontology schema. The browsing of available knowledge bases is comparable to the browsing of available schemas. They are also described by ids and labels – and visually represented by URI hierarchies. In order to keep up a certain clarity and to distinguish between ontology schemas and knowledge bases, they should be displayed separately.
Browsing available classes and instances
Another requirement identified is browsing the classes included in an ontology. The root classes should become sub-nodes of the ontology nodes and the subclasses should be sub-nodes of their super classes. As already mentioned, relations should be treated in the same way. As attributes and their ranges have to reveal the context of the respective class(es), further sub-nodes should be used to display these properties. Because a range of an attribute is only a link to a class it should be visually distinguishable from the actual class. The OMS must also support browsing of available instances. They are returned as a response to selecting a given defining class. As already mentioned, relation instances should be treated equally. Instances are described by attribute values. These have to reveal their relation with both their type and their instance.
Integration of further functionalities
As described in [3] the editing and browsing tool requires the integration of versioning and mapping & merging as well as the editing of axioms and non-functional properties. Therefore this section describes the design of these extensions.
Versioning
The versioning functionality shall be both integrated into the editing and browsing and also be supported through a separate tool. The integrated part shall work as a kind of "details view". That is, further columns will be provided in the class tree that allow for the display and the modification of version information. Beyond this, a separate tool shall allow for the browsing of the version information itself. That is, some kind of tree shall represent the version history including branching and tagging.
Mapping & Merging
Also the mapping and merging functionality shall both be integrated and also be supported by some extra tool. The integration mainly addresses the extension of the already available drag & drop functionality. I.e., while "normal" drag & drop invokes the movement of classes, attributes a.s.o. the same operation with the control key pressed shall cause a mapping operation between the respective items. If no mapping file is existent, yet, it will be created and subsequently opened. Finally the new mapping rule is added and visualized in a comprehensive way.
Editing of NFPs
As the ontology model that the here described tool is based on includes non-functional properties the editing and browsing tool has to allow for the display and the modification of them. In order to keep the clarity the NFPs shall be processed inside an extra tool. The visual representation provides a mapping from each non-functional property to its values. Beyond this, properties and values are creatable, modifyable and removable.
Editing of Axioms
The processing of axioms requires a special tool as logical expressions have to be edited. The functionality is based on common text editing. The user is supported through term suggestions and syntax highlighting as it is known from source code editing in integrated development environments. The axiom editor is tightly integrated with the class tree as it is invoked through a double click on a there selected axiom.
Components
In this section we describe the components to realize the required functionalities. First we address the basic editing and browsing components. Afterwards we take a look at further components.
Basic components
The major components derived from the necessary functionalities are a class tree and an instance table. As can be guessed from the names one consists of a tree view while the other consists of a table view . Interactions between these two are necessary and thus will be supported.
Class Tree
The class tree component is intended to be used for editing and browsing of classes (see Figure 2). The root nodes in the tree view represent the ontology schemas available from the repository. These nodes can be expanded in order to show the included root classes. Each class node again can be expanded in order to reveal the subclasses.
When a class is expanded also its attributes shall be displayed as sub nodes. In order to be visually distinguishable subclasses should be visualized as folders and attributes as files.
Definitions of relations should be visually distinguishable from other classes but nevertheless be processable in the class tree.
Instance Table
The instance table component is intended to be used for editing and browsing of instances. In order to allow for a high usability [6] of the OMS, the instance table (see Figure 3) visualizes the table metaphor as described in [1]. That is, instances are visualized as rows of a table whose header represents the defining class.
Concrete relations should be visually distinguishable from other instances but nevertheless be processable in the instance table.
Further components
Beyond the above described integration of further functionalities into the editing and browsing tool it also takes some additional tools to really fulfill the requirements. In later versions they might be described in the respective deliverables for versioning, mapping a.s.o.. For the moment they shall be addressed at this point as they are very strongly related to the editing and browsing tool.
Version history
The OMS shall both provide a link from an ontology item to its version history as well as links from versions to the corresponding items. For the second use case some tree view shall be utilized. This version tree allows for the concise browsing through a history of versions through the visualization of branches and tags. Whenever a version number is selected the contents of the class tree gets updated in order to display only the items belonging to this version.
Mapping document
The mapping part of the OMS is based on the respective API described in [7]. The there defined model uses a document metaphor to describe the set of mapping rules. Accordingly the intended UI component represents such a document and reveals its contents. The mapping document again corresponds to a file and therefore the mapping document editor is opened whenever a .map file is double-clicked. When no editor is opened and a mapping is invoked, a new mapping file is created and opened automatically.
NFP View
The NFP view utilizes a table tree. There are two columns required - one for properties and one for values. As one property may have several values it is represented by a tree node that can be expanded and collapsed. Values can be modified directly inside the view. A menu is utilized for the creation of new NFPs. It allows both for the selection of standard Dublin Core properties as well as the creation of custom properties.
Axiom editor
Whenever an axiom is double-clicked in the class tree it shall be opened in a respective editor. This tool can be seen as some kind of extended text editor. It supports the user with syntax highlighting and makes on-the-fly suggestions based on the logical expressions model described in [5] and the items included in the processed ontology. Also the validity of expressions is checked during input and possible errors are marked respectively.
Conclusions
In this document the architecture of an editing and browsing tool based on the identified requirements and allowing for a subsequent implementation was designed. It was described how the editing and browsing functionalities shall be realized via a class tree, an instance table and some further components.
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 program.
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 (2005): The table metaphor: A representation of a class and its instances
[2] Kiryakov, Atanas (2004): An Ontology Representation and Data Integration (ORDI) Framework
[3] Kopecký, Jacek; Fox Joshua (2004): D8.1: Editing and Browsing Requirements; https://www.omwg.org/TR/d8/d8.1
[4] Kopecký, Jacek; Scharffe François (2004): D4: Architecture; https://www.omwg.org/TR/d4
[5] Krummenacher, Reto (2005): Logical Expressions API; available from http://cvs.sourceforge.net/viewcvs.py/wsmo4j/wsmo-api/org/omwg/logicalexpression/
[6] Nielsen, Jakob (1993): Usability Engineering. Morgan Kaufmann - An imprint of Academic Press
[7] Scharffe, Francois (2005): Mapping & Merging Design