November 28, 2007 Leave a comment
Ontology Development Methodologies take two.
Pictorially, Uschold and King’s methodology can be summarized as follows:
As can be seen, the process can be broken down into a number of discreete steps: identification of the ontology’s purpose, ontology capture, ontology coding, integration of existing ontologies, ontology evaluation and ontology documentation.
Let’s look at each of these steps in turn:
Identification of the Ontology’s Purpose
All methodologies for the development of ontologies that will be surveyed in this series of blog posts agree, that the definition of the purpose is of vital importance as it essentially helps to define scope and granularity of the ontology. However this is where agreements usually ends and while Grueninger and Fox are relatively prescriptive about how this could be achieved, Uschold and King essentially leave the puropose and scope definition up to the ontological engineer. They do, however, discuss a number of purposes which have been reported in the literature and thus provide some criteria which an ontological engineer could consider when attempting to formulate a “mission statement” for his ontology. These are:
- definition of a vocabulary?
- meta-level specification of a logical theory?
- ontology primarily intended for use of a small group?
- re-use by large community?
- ontology a means to structure a kowledge base?
- ontology part of knowledge base?
Uschold and King define ontology as a process, which can again be broken down into a number of smaller steps:
- identification of the key concepts and relationships in the domain of interest
- production of precise, unambiguous text definitions for such concepts and relationships
- identification of of terms to refer to such consepts and relationships
- achieving community agreement on all of the above
For the initial stages of the ontology capture process, Uschold and King recommend a brainstorming phase, which should produce all relevant concepts and relationships the ontology should contain. At this stage, concepts are represented by terms (labels) which my hide differences in interpretation and understanding of fundamental concepts. Furthermore, the authors point out that, while, in their experience, brainstorming works well, it may have to be supplemented with other sources of information if domain expertise is required.
In a second step then, the identified concepts should be arranged into “work areas corresponding to naturally arising sub-groups”. To decide whether a term should be included or excluded from a grouping and the ontology in general, a reference should be made to the requirements specification of the ontology. The authors thus underline again the vital importance of the availability of such a document. They furthermore recommend, that inclusion or exclusion decisions be documented for future reference. Finally, it is recommended that “semantic cross-references” be identified which link concepts in one group to those of another group.
In a third step in the capture process, Uschold and King recommend the identification of metaontologies which may be suitable for the particular domain ontology to be constructed, without, at this stage, making a firm ontological commitment. They recommend that a consideration of the concepts in the domain ontology and their interrelationships guide the choice of a metaontology.
In a fourth step, precise definitions of all terms and concepts in the ontology should be produced. For this purpose, the authors recommend that defintions for concepts which have a maximum semantic overlap between work areas should be produced first, as these are more likely to be the most important concepts and it is important to get these definitions right in the first instance. Furthermore, Uschold and King advocate to focus initially on the definition of cognitively basic terms as opposed to more abstract ones, arguing that this should facilitate the process of relating terms in different areas. To develop the definitions, Uschold and King recommend that precise natural language text definitions of all terms be produced, while takinng great care to ensure consistency with other terms which are already in use. Furthermore, the introduction of new terms to to be avoided at this stage. The provision of examples is considered to be helpful.
Possible guidelines for dealing with ambiguous or hard terms are also provided. These are:
- Do not use the term if it is too ambiguous to define and consensus cannot be reached.
- Before attempting a definition, clarify the underlying idea. This can, for example be done by consulting dictionaries and trying to avoid technical terms as much as possible.
- To avoid getting hung up on concept labels, give term meaningless labels such as x1, x2, x3 and then attempt the definition of the underlying idea.
- If a definition/clarification has been achieved, attach a term to the concepts, which, if possible avoids the previous ambiguous term.
Once this has been done, an ontological commitment to a meta-ontology should be made at this stage, which will support the following coding stage.
Ontology coding denotes the representation of the conceptualization which has been developed during the capture phase in a formal language. In essence, this involves three sub-stages: a commitment to a meta-ontology, the choice of a formal ontology language and the coding itself. Furthermore, existing ontologies which are to be re-used should be included during the coding stage. In general, the merging of two different ontologies is no trivial task, but can be facilitated, if a meta-ontology is available in all used ontologies to provide some sort of “schema definition”.
Ontology evaluation is in essence a technical judegement of the performance of an ontology w.r.t. its requirements specification, its ability to answer questions and its associated software environment.
We have already alluded to the fact that decisions concerning the inclusion or exclusion of terms from the ontology should be documented. Furthermore, Uschold and King point out that a large obstacle to efficient ontology sharing is the absence of documentation or inadequate documentation.