Brought to you by EarthWeb
IT Library Logo

Click Here!
Click Here!

Search the site:
 
EXPERT SEARCH -----
Programming Languages
Databases
Security
Web Services
Network Services
Middleware
Components
Operating Systems
User Interfaces
Groupware & Collaboration
Content Management
Productivity Applications
Hardware
Fun & Games

EarthWeb Direct EarthWeb Direct Fatbrain Auctions Support Source Answers

EarthWeb sites
Crossnodes
Datamation
Developer.com
DICE
EarthWeb.com
EarthWeb Direct
ERP Hub
Gamelan
GoCertify.com
HTMLGoodies
Intranet Journal
IT Knowledge
IT Library
JavaGoodies
JARS
JavaScripts.com
open source IT
RoadCoders
Y2K Info

Previous Table of Contents Next


10. ONTOLOGY LIFE CYCLE

"Don't build your house starting by the roof," says a Spanish proverb, pointing out that activities have an order and that they should be carried out step by step, in a planned manner, in order to achieve success. In the previous section, we divided the ontology development process into three categories of activities. Each one includes a set of tasks or subactivities. However, we did not indicate the order and depth in which such activities and tasks should be performed.

First, the ontology life cycle answers the previous questions by identifying the set of stage through which the ontology moves during its lifetime. Actually, only development-oriented activities are part of the transformations that conform the life cycle. Project management and integral activities interact with development-oriented activities during the ontology life cycle in order to make the development a success. Making an analogy, we could say that the development-oriented activities used to build ontologies are similar to the activities in a production line in a manufacturing domain. Project management activities (planning and control of the production line, stock control, etc.) and integral activities (raw material buying, inputs to the production line, final product packaging, quality control, and distribution) in a manufacturing domain correspond with their homonyms in the ontology domain. Therefore, the codified ontology and the final product that comes off the production line are the results of the technical activities in both domains.

Just as the life cycle of human beings moves forward sequentially and irreversibly through the following states -- childhood, adolescence, youth, maturity, and old age -- the ontology life cycle moves forward through the following states: specification, conceptualization, formalization, implementation, and maintenance. So, the technical activities transform the raw material (the need you have to build the ontology) into a final product (the evaluated and documented ontology, codified in a formal language). The states through which the ontology passes conform its life cycle, as shown in Figure 5.

Project management tasks and integral tasks interact with the life cycle as shown in Figure 5. Indeed, planning should be completed before starting to build the ontology, and control and quality assurance conducted during the entire building process. As regards integral activities, unless the ontologist is an expert in the application domain, most of the acquisition is done simultaneously with the requirements specification phase and decreases as the ontology development process moves forward. Integration tasks are done during the whole lifetime of the ontology-- most at the conceptualization and less at the implementation. In order to prevent error propagation, most of the evaluation should also be done during the earliest stages of the ontology development process. Finally, you should be drawing a detailed documentation and carefully carry out configuration management at each stage.

Second, the ontology life cycle shows when you should perform the activities to move from a given state to the next and in how much depth. Some life-cycle models have been described in Software Engineering and transferred to Knowledge Engineering (Alonso et al., 1996). As stated before, the main problem facing a KE when (s)he begins a new KBS is to draw up a requirements specification document. On the other hand, an ontologist must be able to partially specify a set of requirements before building an ontology, which will constitute the initial core of the ontology. So, the ontology life cycle is closer to a classic software life cycle than it is to a KBS life cycle.


FIGURE 5 Life cycle states and process phases.

The waterfall life cycle (Royce, 1987) is the traditional life-cycle model. In this model, activities are sequential in the sense that you cannot move onto the next activity until you have completely finished the previous one. This model forces the ontologist to identify all the terms at the beginning, and the implementation must be a mirror of the specification, that is, it must satisfy the complete requirements specification document. The main drawback is that the ontology is static; you cannot include, remove, or modify terms in it during the development of the ontology. You only can modify definitions in the maintenance phase. The main inconvenience is that requirements are static once the project has started. Thus, your frame of reference are the requirements you did. You cannot refer to the real world and implement new definitions until the maintenance starts. Obviously, the use of a waterfall life-cycle model is not adequate due to the absence of a complete requirements specification at the earliest stages of the development process and due to the evolution of the ontology definitions over time. Figure 6a shows how the system grows using this approach.


FIGURE 6 How the ontology grows.

The incremental life cycle (McCracken, 1982) solves some problems, allowing the partial specification of requirements. According to this approach, the ontology would grow by layers, allowing the inclusion of new definitions only when a new version is planned. In other words, this model prevents the inclusion of new definitions if they are not planned, but it permits an incremental development. Figure 6b shows how the ontology grows according to this approach. Finally, the evolving prototype life cycle in Figure 6c solves the previous problems since the ontology grows depending on the needs. Indeed, this model lets you modify, add, and remove definitions in the ontology at any time. So, we propose the evolving prototype as the most appropriate life cycle for building ontologies.


Previous Table of Contents Next

footer nav
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.