This version:
http://www.omwg.org/TR/d8/d8.2/v0.1/20041008
Latest version:
http://www.omwg.org/TR/d8/d8.2
Previous version:
none
Copyright © 2004 DERI ®, All Rights Reserved. DERI liability, trademark, document use, and software licensing rules apply.
As described in [3] our Ontology Management system shall support the functionalities of Versioning, Merging/Aligning, Editing/Browsing, Storing and Querying. This document is regarding the editing and browsing part. In more detail we will design the architecture of an editing and browsing tool based on identified requirements and allowing for a subsequent implementation.
In this section we describe the functionalities to be offered by our editing and browsing tool.
In [2] 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 [1] 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 ORDIElement also classes have non-functional properties. And thus of course also these have to be modifiable. 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 of course 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 [2] 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 thats corresponds to the parts of the identifying URIs. The last node in such a hierarchy should be labeled with the value of the non-functional attribute “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. While keeping the tree view of classes in one widget, a second widget should be used to display these properties as a list or as a dataset/table. This functionality should be realized by responding to an id of a class with ids of attributes and strings representing their ranges.
The OMS also requires the browsing of available instances. They shall be returned as a response to a given knowledge base id. As classes are visualized by sub nodes of schema nodes instances shall be visualized as sub nodes of knowledge base nodes.
As already mentioned, concrete relations are special instances and therefore should be treated equally.
Instance descriptions include attributes and values assigned to them. They shall be returned as a reply to the id of an instance. Their visualization is comparable to the one of class descriptions except that the display is realized in a different window/ widget.
The major components derived from the necessary functionalities are a class explorer and an instance explorer. Both can be compared to the windows explorer that’s why the names were chosen like this. Both consist of a tree view widget to the left and a list view widget to the right. Switching between them can be realized through a “Window” menu item which should also include a split view. For later versions it is also planned to allow for interactions between these two windows, but currently this shall be spared out for the sake of simplicity.
A draft view of the OMS including a class and an instance explorer is depicted in Figure 1.
Figure 1: The editing and browsing tool of the OMS
The class explorer 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 selected in the tree view the respective subclasses and attributes shall be displayed in the list view. In order to be visually distinguishable subclasses should be visualized as folders and properties as files. The list widget should also allow for an detailed view. Therein a dataset /table widget shall be used to display further information about the items.
Definitions of relations should be visually distinguishable from other classes but nevertheless be processable in the class explorer.
Figure 2: The class explorer window
The class explorer component is intended to be used for editing and browsing of instances. In order to allow for a high usability [4] of the OMS, the instance explorer (see Figure 3) should perfectly resemble the class explorer. That is, instances shall be visualized as classes and instance attributes just like class attributes.
Concrete relations should be visually distinguishable from other instances but nevertheless be processable in the instance explorer.
Figure 3: The instance explorer window
In this document we designed the architecture of an editing and browsing tool based on the identified requirements and allowing for a subsequent implementation. We described how the browsing and editing functionalities should be realized via a class explorer and an instance explorer component.
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] Kiryakov, Atanas (2004): An Ontology Representation and Data Integration (ORDI) Framework
[2] Kopecký, Jacek; Fox Joshua (2004): D8.1: Editing and Browsing Requirements; http://www.omwg.org/2004/d8/d8.1
[3] Kopecký, Jacek; Scharffe François (2004): D4: Architecture; http://www.omwg.org/2004/d4
[4] Nielsen, Jakob (1993): Usability Engineering. Morgan Kaufmann - An imprint of Academic Press
$Date: 2004/10/09 14:19:58 $