Ontology Requirements Specification Document
[edit] ORSD, part (i): Goal, Domain and Scope
In the beginning one should specify the particular domain in use, which might e.g. help to identify already existing ontologies. The feasibility study made clear proposals about interesting areas to be supported by a knowledge management project. The ontology engineer may use the outcomes of the task analysis to describe the goal of the ontology.
[edit] Example
- The ontology serves as a means to structure skills and job profiles,
- The ontology serves as a guideline for the knowledge distribution between the Human Resource department and the Research and Development department,
- The ontology serves as a base for semantic search.
[edit] ORSD, part (ii): Design Guidelines
[edit] Number of Concepts and Granularity
The guidelines might e.g. contain an estimation of the number of concepts and the level of granularity of the planned model. This estimation is based on the knowledge item analysis, a further outcome of the feasibility study. E.g. if the requirements analysis specified that an ontology should support browsing through a domain which includes around 100 concepts and the ontology engineer ended up with modeling 1000 concepts, either the ontology grew too big and should be modified to fulfill the requirements or the requirement specification is not up to date any longer and should be updated.
[edit] Naming Convention
Also, one might specify common rules how to name concepts and relations. A typical approach for a naming convention is to begin all concepts with capitals and all relations with small caps. Whatever rules one might specify, they should be used consistently when modeling an ontology. Ideally an ontology engineering tool should support to set these kinds of constraints and check it during the modeling process. There exist standardized naming conventions for concepts and relations such as (ISO 704, 1987).
[edit] Pragmatic guidelines
Ontology Development 101 proposes a set of pragmatic guidelines for modelling ontologies. Especially domain experts not familiar with modelling find these guidelines quite helpful.
[edit] ORSD, part (iii): Knowledge Sources
- domain experts (interviews, competency questionnaires)
- (reusable) ontologies
- dictionaries
- thesauri
- other sources
- databases
- index lists
- regulations
- standard templates
- product and project descriptions
- technology white papers
- telephone indices
- web pages / site statistics
- organization charts
- employee role descriptions
- business plans
[edit] ORSD, part (iv): (Potential) Users and Usage Scenarios
This includes a list of potential users or user groups and a description of each usage scenario. These scenarios might be described by potential users who may report from own experiences: In what situation occurred a need for such a system (better search for information, information distribution etc.)? How did they proceed without it? How would they like to be supported? The usage scenarios sketch the point of view of each individual user, which may vary between extreme degrees. Those views give interesting input to the structure of the ontology. The descriptions of the hindering blocks include also important hints for the design of the ontology based system. The acquisition of the usage scenarios is done via structured or informal interviews. A common way of modeling usage scenarios in software engineering are use cases. In particular they help to identify stakeholders and to clarify their roles in the scenario.
