This version:
http://www.omwg.org/TR/d8/d8.2/v0.2/20050426
Latest version:
http://www.omwg.org/TR/d8/d8.2/v0.2
Previous version:
http://www.omwg.org/TR/d8/d8.2/v0.1
Copyright © 2004 DERI ®, All Rights Reserved. DERI liability, trademark, document use, and software licensing rules apply.
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.
In this section the functionalities to be offered by the editing and browsing tool are described.
In [3] there have been identified several requirements regarding the editing of ontologies. The functionalities derived from there shall be described in the following paragraphs.
As defined in ORDI [2] a class is described by attributes. Thus the editing functionality will have to allow for a change of those. Given the ids of a certain class, the id of an attribute and an attribute range this new range has to be stored in the repository accordingly.
Beyond attributes, a class is also defined by its position in the class hierarchy. Thus the editing has to support the change of the “subClassOf” value. This should be realized graphically – that is the user should be enabled to drag classes to new positions in the tree.
As every ORDI element classes have non-functional properties. Thus these have to be modifiable in the provided tool. Because the values are mostly literal the user can be offered changeable text areas / input fields.
Definitions of relations are classes, too. Therefore they should be treated equally. The only difference consists in the editing of parameters instead of attributes.
Instances are described by their attribute values. Depending on whether a certain value is literal or a resource – an input field or an selection widget has to be displayed.
Beyond attribute values an instance is described by its class membership. If the user wants to change this a selection widget should be displayed containing the tree of available classes. This is comparable to the “select directory” dialogs known from operating systems.
Last but not least also instances have non-functional properties. The editing of these doesn't differ from the classes case.
Concrete relations are instances, too. Therefore they should be treated equally. The only difference consists in the editing of parameter values instead of attribute values.
In [3] there have been identified several requirements regarding the browsing of ontologies. The functionalities derived from there shall be described in the following paragraphs.
As identified the editing and browsing tool requires the functionality of browsing available ontology schemas. That is, given a certain repository, the included ontology schemas shall be returned and presented to the user. Because of its wide spreading and high familiarity, a tree view should be utilized for this visualization task. In there, the schemas could be represented by a tree that corresponds to the parts of the identifying URIs. If available, the last node in such a hierarchy should be labeled with the value of the non-functional property “dc:title” of the respective ontology schema.
The browsing of available knowledge bases is comparable to the browsing of available schemas. Also they shall be described by ids and labels – and visually represented by URI hierarchies. In order to keep up a certain clarity a separate window / widget should be used.
Another requirement identified is the one of browsing the classes included in an ontology. Based on a tree view, the root classes should become sub nodes of the ontology nodes and subclasses should become sub nodes respectively. After sending the id of an ontology schema to the repository, the ids and the names/labels of included classes should be returned.
As already mentioned, relation definitions are special classes and therefore should be treated equally.
Class descriptions like attributes and their ranges should be displayed when the respective class is selected. Further sub nodes should be used to display these properties. This functionality should be realized by responding to an id of a class with ids of attributes and ids representing their range classes.
The OMS also requires the browsing of available instances. They shall be returned as a response to a given id of the defining class. As described in [1] they shall be visualized as rows of a table whose header represents the defining class.
As already mentioned, concrete relations are special instances and therefore should be treated equally.
Instances are described by attribute values. They shall be returned as a reply to the id of an instance. Their visualization is taken over by some table widget as mentioned above.
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.
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 comparably to the "details view" of the Windows Explorer. 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.
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.
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.
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.
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 widget while the other consists of a table view widget. Interactions between these two windows are necessary and thus will be supported.
A draft view of the OMS including a class tree and an instance table is depicted in Figure 1.
Figure 1: The editing and browsing tool of the OMS
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.
Figure 2: The class tree window
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.
Figure 3: The instance table window
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.
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 widget 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.
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.
The NFP view utilizes a table tree widget. 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 widget as it is known from the renaming functionality inside the Windows Explorer. 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.
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.
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.
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.
[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; http://www.omwg.org/2004/d8/d8.1
[4] Kopecký, Jacek; Scharffe François (2004): D4: Architecture; http://www.omwg.org/2004/d4
[5] Krummenacher, Reto (2005): Logical Expressions API; available from http://cvs.deri.at/cgi-bin/viewcvs.cgi/wsml/logicalexpression/
[6] Nielsen, Jakob (1993): Usability Engineering. Morgan Kaufmann - An imprint of Academic Press
[7] Scharffe, Francois (2005): Mapping & Merging Design
$Date: 2005/04/26 12:38:15 $