![]() |
|||
![]()
|
![]() |
![]() |
![]() |
11. METHODOLOGY TO BUILD ONTOLOGIESIn general, methodologies give you a set of guidelines of how you should carry out the activities identified in the development process, what kinds of techniques are the most appropriate in each activity, and what products each one produces. Until now, few methodological approaches to building ontologies have been reported. In Mizoguchi, Vanwelkenhuysen, and Ikeda (1995), the authors provide an ad-hoc method to build task ontologies. Bernaras, Laregoiti, and Corera (1996) present the ontology building process carried out for the applications of disturbance diagnosis and service recovery planning in electrical networks, and identify the phases of ontology specification, ontology design, ontology use, and ontology reuse. However, Uschold and Grüninger (1996) and Gómez-Pérez, Fernández, and de Vicente (1996) propose a method with phases that are independent of the domain of the ontology. Figure 7 summarizes the phases proposed and their equivalence. Obviously, it is almost impossible to take the above contributions to propose a general method for building any kind of ontology or meta-ontology. However, it is important to make an effort to define a methodology that guides the building of ontologies and that helps novice developers. Here, METHONTOLOGY is presented as a structured method to build ontologies. The phases of this methodology are presented as part of the ontology development process. METHONTOLOGY extends that section, showing how to carry out each of these phases. 11.1. SPECIFICATIONThe goal of the specification phase is to produce either an informal, semiformal, or formal ontology specification document written in natural language, using a set of intermediate representations or using competency questions, respectively. METHONTOLOGY proposes that at least the following information be included:
The formality of the ontology specification document varies depending on whether you use natural language, competency questions (Grüninger and Fox, 1994), or a middle-out approach. For example, in a middle-out approach, you can use a glossary of terms to define an initial set of primitive concepts and use these concepts to define new ones. It is also advisable to group concepts in concepts classifications trees. The use of these intermediate representations will allow you not only to verify, at the earliest stage, relevant terms missed and include them in the specification document, but also to remove terms that are synonyms and no longer relevant in your ontology. The goal of these checks is to guarantee the conciseness and completeness of the ontology specification document. Figure 8 shows a short example of an ontology requirements specification document in the domain of chemicals. An excellent argument on the use of a middle-out approach, as opposed to the classic bottom-up and top-down approaches, in identifying the main terms of your glossary is given by Uschold and Grüninger (1996). The middle-out approach allows you to identify the primary concepts of the ontology you are starting on. After reaching agreement on such terms and their definitions, you can move on to specialize or generalize them, only if this is necessary. As a result, the terms that you use are more stable, and less re-work and overall effort are required. Grüninger and Fox (1994) propose the use of motivating scenarios that present the problem as a story of problems or examples and a set of intuitive solutions to the scenario problem. A set of informal competency questions includes the questions that an ontology must be able to answer in natural language. Then, the set of informal competency questions are translated into a formal set of competency questions using first-order logic (or possibly second-order logic). This formal set is also used to evaluate extensions of the ontology. Ontology Requirement Specification Document
FIGURE 8 Ontology requirements specification. As an ontology specification document cannot be tested for overall completeness, someone may find a new relevant term to be included at any time and anywhere. A good ontology specification document must have the following properties:
|
![]() |
|
Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details. |