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


9. ONTOLOGY DEVELOPMENT PROCESS

The ontology development process refers to which tasks you carry out when building ontologies. Verbs are used to refer to such tasks since they denote activities. Adapting the IEEE (IEEE, 1991) software process representation to the ontology development process, the tasks identified are classified in three categories as shown in Figure 4. Note that the development process does not imply an order of the execution of such tasks. Its goal is only to identify the list of activities to be completed.

If the ontologies are built on a small scale, some ontology tasks can be skipped. But, if you mean to build large ontologies on a large scale and with some guarantee of correctness and completeness, you should complete the three categories of activities presented below and steer clear of anarchic constructions.

9.1. PROJECT MANAGEMENT ACTIVITIES

Unless you are making a toy ontology, you need to perform management activities. Their main aim is to assure a well-running ontology. The tasks included in this category are:

  • Planning. Before building your ontology, you should decide what will be the main tasks of your ontology development process, how they will be arranged, and how much time you need to perform them and with which resources (people, software, and hardware). The chosen life cycle helps to order the set of activities that comprise the plan. This task produces a plan with detailed drawings that show a series of tasks to be done. This activity is done before starting development-oriented and integral activities.
  • Control. Its goal is to guarantee that planned tasks are done in the way that they were intended to be performed. In other words, to control is to make all the important decisions about the way that your ontology is running. This activity should be completed as part of each and every task and between tasks in order to prevent delays, errors, omissions, etc. that could be propagated.
  • Quality Assurance. The aim is to assure that each and every product obtained reaches the appropriate level of quality. As will be shown in later sections, the ontology codified in a formal language is not the only product you get when you construct your ontology. Documentation, requirements specification documents, conceptual models, etc. are all products also produced by the ontology development process. Evaluation and quality assurance are different tasks. Evaluation is a technical activity that improves products by testing their correctness and validity. Once you have evaluated the product technically, the quality manager reviews the product and approves it.

9.2. DEVELOPMENT-ORIENTED ACTIVITIES

The following tasks describe the practical skills, techniques and methods used to develop an ontology.

  • Specify. You should not start the development of your ontology without knowing why this ontology is being built and what are its intended uses and end-users. As an example of an informal and formal specification of two independent ontologies in the domain of enterprise modeling, we cite the Enterprise ontology (by Uschold) and TOVE ontology (by Grüninger) (Uschold and Grüninger, 1996). Although their outputs are almost the same (a set of terms), the degree of formality in writing their requirements specification documents are different. The Enterprise ontology has been specified in natural language and the TOVE ontology using a set of competence questions (Grüninger and Fox, 1995).
  • Conceptualize. The goal is to build a conceptual model that describes the problem and its solution. A set of intermediate representations1 for conceptualizing a domain ontology of objects were presented in Gómez-Pérez, Fernández, and de Vicente (1996).

    1These intermediate representations have their roots in those presented in Pazos (1995).
  • Formalize. This activity transforms the conceptual model into a formal model that is semicomputable. Frame-oriented or description logic representations systems could be used to formalize the ontology.
  • Implement. To make your ontology computable, you need to codify it in a formal language. As a reference framework for selecting target languages, we would cite the comparative study completed by Speel et al. (1995) as part of the Plinius project (Vet, Speel, and Mars, 1995).
  • Maintain. Someone could ask for definitions to be included or modified in the ontology at anytime and anywhere. Guidelines for maintaining ontologies are also needed.

9.3. INTEGRAL ACTIVITIES

These activities back up development-oriented activities, giving them the support they need to succeed. The interaction between development-oriented and integral activities will be shown when the life cycle of the ontology is described. They include:

  • Acquire knowledge. Unless you wish to build a toy ontology or you are an expert in the domain, you will elicit knowledge using KBS knowledge elicitation techniques. As a result, you should be able to list the sources of knowledge and give a rough description of how you carried out the processes and of the techniques you used. The most extensive work on capturing knowledge was reported by Uschold and Grüninger (1996).
  • Integrate. Ontologies are built to be reused. Accordingly, duplication of work in building ontologies has even less sense than its duplication when you build traditional software. So, you should reuse existing ontologies as much as possible in your ontology. A method to integrate ontologically heterogeneous taxonomic knowledge and its application to the medical domain was presented in Gangemi, Steve, and Giacomelli (1996). However, no work has been done on selecting ontologies to be reused in other ontologies, although four kinds of relationships between ontologies that have been integrated (inclusion, polymorphic refinement, circular dependencies, and restrictions) are identified in (Farquhar et al., 1995).
  • Evaluate. Before making your ontology available to others, make a technical judgment with respect to a framework of reference. A framework for evaluating ontologies is given by Gómez-Pérez (1994) and Gómez-Pérez, Juristo, and Pazos (1995).
  • Document. The absence of a sound documentation is also an important obstacle when you reuse/share built ontologies. So, if you wish your ontology to be reused/shared by others, try to document it as best you can. Skuce briefly analyzes how different ontologies are documented (Skuce, 1995).
  • Configuration management. This activity involves records of each and every release. Software Engineering sets out how to perform this activity.


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.