The goal of this document is to identify requirements for an editing and browsing tool for ontologies. This document integrates points of view of researchers, developers and use case partners.
The rest of this document is structured as follows: Sections 2 to 4 list the requirements regarding editing and browsing, group editing and the tool’s usability. Finally this document is concluded in section 5.
Basic Editing and Browsing Requirements
In cooperation with our partners in the DIP project (http://dip.semanticweb.org), we gathered the relevant use cases of an editing and browsing tool. A simple mapping of these use cases results in the following list of requirements:
Editing an ontology schema and a knowledge base
Adding, removing and changing components of an ontology schema (i.e. classes, relations and axioms) and a knowledge base (i.e. the instances and relation instances) in a GUI environment has to be supported so that this task can be performed by non-experts, too. On the other hand, editing of the source representation (XML or other syntax) of ontology schemas should also be possible in order to allow maximal efficiency for expert users.
Browsing available ontology schemas and knowledge bases
So that a user knows which ontology schemas and knowledge bases are available (on the file system, in a repository, on the Web etc.), a list of these should be provided in the browsing tool.
Browsing contents of an ontology schema and of a knowledge base
The tool should support browsing by the conceptual components and also displaying details of the selected elements so that a user knows what is included in an ontology schema or in a knowledge base.
Export/import different ontology languages
The editing and browsing tool should support multiple ontology systems and languages, for example the W3C standard OWL (McGuinness, 2004) in order to restrict the group of potential users as little as possible and so that definitions can be performed on the knowledge level (Gruber, 1993).
Support large-scale ontologies
The tool should be able to deal with ontology schemas that contain thousands of concepts and relationships and with knowledge bases larger by orders of magnitude because it can hardly be predicted how big ontologies usually will be in the future. Such a scalability has also been exposed as one of the most important requirements in (Das, 2001).
Query modeling and storage
A non-expert user may need assistance with formulating logical queries; therefore the environment should provide such assistance. Also, such queries could be stored in a repository or a reasoner component for future reuse and reevaluation.
Access to a repository of ontology schemas and knowledge bases
Because simple files don’t scale with big amounts of data, the tool should support getting the available ontology schemas and/or knowledge bases from a variety of sources and storing edited ontologies and/or knowledge bases in those sources.
To keep up their usefulness, ontologies produced using the editing tool should be checked and the user should be warned about any inconsistencies. The tool should be able to work with inconsistent ontologies, though, as any version changes in reused ontologies may invalidate an edited ontology. The tool may help the user with any changes necessary to update the ontology to the latest version of the reused ontology, for instance by pointing out the individual statements that cause inconsistency.
In order to ease modularization, the tool should support factoring an ontology into independent related sub-ontologies, with additional support like automatically indicating independent parts.
For distributed (asynchronous) collaboration over an ontology, it is necessary that various users can add comments on various elements of the ontology, so that the development process and intentions can be communicated.
Ontology editing is a collaborative task (Farquhar, 1996). That’s why it requires “computer-based systems that support groups of people engaged in a common task (or goal) and that provide an interface to a shared environment” – which is the definition of groupware (Ellis, 1991).
To track the evolution of an ontology, it is desirable to also know about the authors of the editing steps. Therefore the identity of users has to be recognized which means that some sort of access control is required.
Another critical requirement of any collaborative activity is the awareness of other participants (Dourish, 1992). This information can be generated implicitly or explicitly. An example of the former case is the ability to the track the actions of other users. An example for the latter case are annotations attached to ontology object, e.g.
In a collaborative environment the responsiveness is of crucial importance. A collaborative tool cannot expect a user to accept any additional response times compared to a conventional tool.
Any software tool has to make sure that it doesn’t produce undefined states, i.e. it must not put data into unusable conditions. Therefore it is necessary to allow for transactions so that batches of operations (as for instance moving=delete + add) can be performed completely or not at all.
As every interactive system, not only the utility but also the usability is of high importance. I.e., included functionality is of less value if it can’t be accessed in a proper way. Following (Nielsen, 1993), this requirement will be split up in the following sections.
The learnability requirement means that it must be as easy as possible to learn the usage of a tool. This requirement is motivated by the fact that the faster the sooner phase ends, the sooner the actual usage may begin. Also if from the intended users – i.e. developers – a certain basic understanding can be expected, the learning aspect cannot be ignored.
Efficiency simply regards the question, how much time it takes to perform a certain task. Obviously, an increased efficiency can be of directly countable benefit. The concrete motivation will depend on future salary levels of ontology developers.
A high memorability allows the restart of a tool usage after a longer interruption without the need of passing the learning phase again. It can hardly be predicted how ontology development will look like in the future and thus, how focused ontology developers will be on this specific task.
Errors have to be undoable and fatal errors have to be excluded. Even in a tool that allows for rolling back through versioning, there is still the responsibility to minimize the error likelihood in order to not confuse the user and in order to not waste any time.
The individual pleasure in the usage of a tool might be less central in the case of a professional developer tool. Still, it is surely no disadvantage if the ontology developers enjoy their work. However, a concrete picture of an ontology developer can be grasped in the future only.
In this document the requirements for editing and browsing tool for ontologies were outlined and analyzed. It was stated that ontological, groupware and usability engineering requirements reside on one and the same level of importance.