O N T O L O G I E S

Building a Chemical OntologyUsing Methontology and theOntology Design Environment

Mariano Fernández López, Asunción Gómez-Pérez, and Juan Pazos Sierra, Polytechnic University of MadridAlejandro Pazos Sierra, University of Coruña

SOFTWARE AND KNOWLEDGE RE-use have generated considerable interestbecause they reduce development time andthe resources that projects require. For knowl-edge-based systems,in particular, the highcost of knowledge acquisition makes reuseessential. However, reuse involves these chal-lenges:heterogeneity of representation for-malisms,languages,and tools; lexical andsemantic problems; assumptions implicit ineach system; and commonsense-knowledgelosses. Ontologies are a way around theseobstacles. They are useful for unifying data-base, data-warehouse, and knowledge-basevocabularies and even for maintaining con-sistency when updating corporate memoriesused in knowledge management.

To meet the challenge of building ontolo-gies, we’ve developed Methontology,1,2 aframework for specifying ontologies at theknowledge level,3 and the Ontology Devel-opment Environment. This article presentsour experience in using Methontology andODE to build the Chemicals ontology.4

The challenge of buildingontologies

Ontology building is a craft rather than anengineering activity. Each development team

usually follows its own set of principles,design criteria, and phases. The absence ofstructured guidelines and methods hindersthe development of shared and consensualontologies within and between teams,theextension of an ontology by others, and itsreuse in other ontologies and final applica-tions. We believe that the source of theseproblems is the absence of an explicit andfull y documented conceptual model uponwhich to formalize the ontology.

Like knowledge-based-system develop-ment,ontology development faces a knowl-edge-acquisition bottleneck. Unlike KBSdevelopers, ontology developers (ontolo-gists) lack sufficiently tested and generalizedmethodologies recommending what activi-ties should be performed and at what stageof ontology development. (For descriptions

of related work, see the sidebar.)Ontology developers often switch directly

from knowledge acquisition to implementa-tion, which poses these problems:

First, the conceptual models are implicitin the implementation codes. Making theconceptual models explicit usually requiresreengineering.

Second, ontological commitments5 anddesign criteria are implicit and explicit in theontology code.

Third, domain experts and human endusers have no understanding of formal on-tologies codified in ontology languages.6

Research has shown that, using the OntologyServer browser tools,7 experts and userscould gain a full understanding of and vali-date taxonomies and partially understandinstances. However, they were unable to

METHONTOLOGY PROVIDES GUIDELINES FOR SPECIFYING

ONTOLOGIES AT THE KNOWLEDGE LEVEL, AS A SPECIFICATION

OF A CONCEPTUALIZATION. ODE ENABLES ONTOLOGY

CONSTRUCTION, COVERING THE ENTIRE LIFE CYCLE AND

AUTOMATICALLY IMPLEMENTING ONTOLOGIES.

JANUARY/FEBRUARY 1999 1094-7167/99/$10.00 © 1999 IEEE 37

.

understand abstract definitions of concepts,relations,functions,and axioms. From theknowledge-acquisition viewpoint,they werequite unable to formalize their knowledge.

Fourth,as with traditional knowledge bases,direct coding of the knowledge-acquisitionresult is too abrupt a step,especially for com-plex ontologies.

Fifth, ontology-developer preferences ina given language condition the implemen-tation of the acquired knowledge. So,whenpeople code ontologies directly in a targetlanguage, they are omitting the minimalencoding bias criterion defined by TomGruber:5

The conceptualization should be specified at theknowledge level without depending on a par-ticular symbol level encoding. An encoding biasresults when representation choices are madepurely for the convenience of notation or imple-mentation .…

Finally, ontology developers might havedifficulty understanding implemented on-tologies or even building new ontologies. Thisis because traditional ontology tools focus toomuch on implementation issues rather thanon design questions. For example, someonewho knows how to build ontologies but isunfamiliar with the language in questionmight have difficulties working at the imple-mentation level.

For instance, the expression density=mass/volumein a chemical domain could bewritten in Ontolingua as shown in Figure 1.This example shows that unless you are veryfamiliar with the language, understandingexisting definitions and writing new defini-tions are almost impossible. If you are suc-cessful in this process,it will have taken abig effort. The problem is not understandingthat density is equal to mass divided by vol-ume at the knowledge level, but writing thisin a target language. Therefore, somethingthat is apparently very simple at the concep-tual level is extremely complicated whenexpressed at the implementation level, ifyou’re not familiar with the language.

This means that ontologies are built exclu-sively by developers who are perfectly ac-quainted with the languages in which theontologies will be implemented. Becausethese ontologists are not necessarily expertsin the domain for which the ontology is built,they spend a lot of time and resources onknowledge acquisition.

Methontology and ODE alleviate some ofthese problems. Methontology provides auser-friendly approach to knowledge acquisi-tion by non-knowledge engineers,6 and aneffective, generally applicable method fordomain-knowledge-model construction andvalidation. ODE supports this framework byletting ontologies be built at the knowledge

level and implemented automatically usingtranslators. So,ontologists don’t need to knowthe ontology’s implementation language.

Ontology development

Ontological engineering requires the def-inition and standardization of a life cycleranging from requirements specification tomaintenance, as well as methodologies andtechniques that drive ontology development.So,the Methontology framework includes

• the identification of the ontology devel-opment process;

• a life cycle based on evolving prototypes;and

• the methodology itself, which specifiesthe steps for performing each activity, thetechniques used, the products to be out-put, and how the ontologies are to beevaluated.

In developing Chemicals,our first step,asin any project,was to plan. Then,becausewe’re not experts in the chemicals domain,we acquired knowledge to put together a pre-liminary version of the requirements speci-fication. We then simultaneously acquiredand conceptualized more knowledge; con-ceptualization helped guide acquisition.

38 IEEE INTELLIGENT SYSTEMS

Methodologies for building ontologiesUntil now, few domain-independent methodologies for building

ontologies have been reported. Mike Uschold’s methodology,1 MichaelGrüninger and Mark Fox’s methodology,2 and Methontology3,4 are themost representative. These methodologies all start from the identifi-cation of the ontology’s purpose and the need for domain knowledgeacquisition. However, having acquired a significant amount of knowl-edge, Uschold’s methodology and Grüninger and Fox’s methodologypropose coding in a formal language and Methontology proposesexpressing the idea as a set of intermediate representations (see themain article). Methontology then uses translators to generate theontology.

These three methodologies also identify the need for ontology evalua-tion. Uschold’s methodology includes this activity but does not statehow to carry it out. Grüninger and Fox propose identifying a set of com-petency questions.2 Competency questions are the basis for a rigorouscharacterization of the knowledge that the ontology has to cover; theyspecify the problem and what constitutes a good solution. Once theontology has been expressed formally, it is compared against this set ofcompetency questions. Methontology proposes that evaluation occurthroughout ontology development. Most of the evaluation happens dur-ing conceptualization.

Several representation systems use a frame-based modeling ap-proach, a logic-based approach, or even both to formalize ontologies.They model the world using concepts,instances,relations,functions,and axioms. An ontology formalized using any of these approaches canthen be implemented, more or less straightforwardly, in different lan-guages such as Ontolingua,5 CycL,6 LOOM,7 and Flogic.8

References

1. M. Uschold and M. Grüninger, “ONTOLOGIES:Principles,Methods and Applications,” Knowledge Eng. Rev., Vol. 11,No. 2,June 1996.

2. M. Grüninger and M.S. Fox, “Methodology for the Design andEvaluation of Ontologies,” Proc. Int’l Joint Conf. AI Workshop onBasic Ontological Issues in Knowledge Sharing, 1995.

3. M. Fernández,A. Gómez-Pérez,and N. Juristo,“METHONTOL-OGY: From Ontological Art towards Ontological Engineering,”Proc. AAAI Spring Symp. Series, AAAI Press,Menlo Park, Calif.,1997,pp. 33–40.

4. A. Gómez-Pérez,“Knowledge Sharing and Reuse,” The Handbookof Applied Expert Systems,J. Liebowitz, ed., CRC Press,BocaRaton,Fla.,1998.

5. A. Farqhuar et al.,Collaborative Ontology Construction for Infor-mation Integration, Tech. Report KSL-95-69,Knowledge SystemsLaboratory, Stanford Univ., Stanford, Calif., 1995; http://ksl-web.stanford.edu/publications.

6. B.D. Lenat, “Steps to Sharing Knowledge,” Towards Very LargeKnowledge Bases, N.J.I. Mars,ed., IOS Press,Amsterdam,1995,pp.3–6.

7. Loom Users Guide Version 1.4, ISX Corp.,Westlake Village,Calif., 1991; http://www.isi.edu/isd/LOOM/documentation/LOOM-DOCS.html.

8. M. Kif er, G. Lausen,and J. Wu, “Logical Foundations of Object-Oriented and Frame-Based Languages,” J. ACM, Vol. 42,No. 4,July 1995,pp. 741–843.

.

Indeed, the conceptualization phase is likeassembling a jigsaw puzzle from the piecessupplied by acquisition,which is why mostknowledge acquisition is completed duringconceptualization. We then gave the ontol-ogy to the expert for examination. The expertevaluated the conceptualization by inter-preting the intermediate representations(which we’ll present in the next section),which are fairly intuitive. During both spec-if ication and conceptualization, we inte-grated in-house and external ontologies.Once the conceptualization was complete,we used ODE to automatically generate thecode in Ontolingua.

Our experience shows that the specifica-tion,conceptualization, integration,and im-plementation can be performed as often asrequired. Indeed, an ontology’s specificationfrequently changes throughout the ontologylif e cycle as its definitions are created, mod-if ied, and deleted. Figure 2 presents thedevelopment life cycle of the Chemicalsontology.

The Chemicals ontology (available athttp://www-ksl.stanford.edu:5915and http://www-ksl-svc-lia.dia.fi.upm.es:5915.)actually comprises two main ontologies:Chemical-Elements and Chemical-Crystals. Chemical-Elements has 16concepts, 103 instances,three functions,21 relations,and 27 axioms. Chemical-Crystals has 19 concepts,66 instances,eight relations,and 26 axioms. Chemicalsalso includes public Ontolingua ontologies,such as Standard-Units, Standard-

Dimensions, and KIF-Lists.

Specification. Ontology specification’s goalis to put together a document that covers theontology’s primary objective, purpose, gran-ularity level, and scope. The aim is to iden-tify the set of terms to be represented, theircharacteristics,and their granularity. Thisspecification should be as complete and con-

cise as possible.Figure 3 shows a short example of an ontol-

ogy requirements specification document inthe chemicals domain. We built this specifi-cation after acquiring domain knowledge.

Conceptualization. When most of theknowledge has been acquired, the ontologisthas a lot of unstructured knowledge that mustbe organized. Conceptualization organizesand structures the acquired knowledge usingexternal representations that are independentof the implementation languages and envi-ronments. Specifically, this phase organizesand converts an informally perceived viewof a domain into a semiformal specification,using a set of intermediate representationsthat the domain expert and ontologist canunderstand.6 These IRs bridge the gapbetween how people think about a domain

and the languages in which ontologies areformalized.

This set of IRs is based on those used inthe conceptualization phase of the Idealmethodology for knowledge-based systemsdevelopment.8 Figure 4 illustrates the orderwe follow for conceptualization.

First, we built a glossary of terms thatincludes all the terms (concepts,instances,attributes,verbs,and so on) of the chemicalsdomain and their descriptions (see Figure 5a).

When the glossary contained a sizable num-ber of terms,we built concept-classificationtreesusing relations such as subclass-of, sub-class-partition-of,and exhaustive-subclass-of.(Class C is a subclass of parent class P if andonly if every instance of C is also an instanceof P. A subclass partition of C is a set of sub-classes of C that are mutually disjoint. Aexhaustive subclass of C is a set of mutually-

JANUARY/FEBRUARY 1999 39

Figure 1. The expression density = mass/volume in a chemical domain written in Ontolingua.

(Define-Function Density(?Element):->?Density-At-20-C

“The density of an element is equal to its atomic weight divided by its atomic volume”

:Iff-Def

(And (Elements ?Element)

(Density-At-20-C ?Element?Density-At-20-C)

(Exists (?Atomic-Weight)

(Exists (?Atomic-Volume-At-20-C)

(And (Atomic-Weight?Element ?Atomic-Weight)

(Atomic-Volume-At-20-C?Element ?Atomic-Volume-At-20-C)

(>?Atomic-Volume-At-20-C 0)

(/?Atomic-Weight?Atomic-Volume-At-20-C))))))

Specification Conceptualization ImplementationPlanning

Part 1

Part 2

. . .

Knowledge acquisition

Evaluation

Documentation

Configuration management

Integration

Figure 2. Ontology development life cycle.

.

disjoint classes—a subclass partition—thatcovers C. Every instance of C is an instance ofexactly one of the subclasses in the partition.)So,we identified this domain’s taxonomies,and each taxonomy produced an ontology asprescribed by Methontology. The concept-clas-sification tree in Figure 5b outlines the taxon-omy of the Chemical-Elements ontology.

The next step was to build ad hoc binary-relations diagramsbetween concept classi-fication trees. These diagrams establish rela-tionships between concepts of the same ordifferent ontologies. They will set out theguidelines for integrating ontologies,becauseif a concept C1 is linked by a relation R to aconcept C2, the ontology containing C1includes the ontology containing C2,pro-vided that C1 and C2 are in different con-

40 IEEE INTELLIGENT SYSTEMS

Figure 3. Ontology requirements specification document for the Chemicals ontology.

Domain: ChemicalDate: May 15, 1996Developed by Asunción Gómez-Pérez and Mariano Fernández López

Purpose: Ontology about chemical substances to be used when information aboutchemical elements is required in teaching, manufacturing, analysis, and so on.

Level of formality: Semiformal.

Scope: List of 103 elements: lithium, sodium, chlorine, mercury, ….List of concepts: element, halogen, noble gas, semimetal, metal, third-transi-tion metal, ….Information about at least the following properties: atomic number, atomicweight, electronegativity, melting point, ….

Sources of knowledge:(a) Three interviews with the expert.(b) The following books:

[Handbook, 84–85] Handbook of Chemistry and Physics, 65th ed., CRC Press Inc., 1984–1985.

Has structure

Is in elementElement Crystalline

structure

Figure 5. Intermediate representations for the Chemicals ontology: (a) part of the glossary of terms; (b) a concept-classification tree; (c) a binary-relations diagram; (d) part of the concept dictionary; (e) a binary-relations table; (f) an instance-attribute table; (g) a logical-axioms table; (h) a formula table; (i) an attribute-classification tree; (j) part of an instance table.

(c)

Name DescriptionAtomic weight The relative mass of an atom of an element against the mass of the twelfth part of the carbon-12 isotope.

Crystalline structure A 3D skeleton containing the set of points or ionic positions of a crystal that have an identical environment.

Element A substance made up of atoms with the same number of protons.

Mercury (Planet Mercury), Hg (hydrargyrum, liquid silver); at. wt. 200.59 ± 3; at. no. 80; m.p. −38.842°C; b.p. 356.58°C; va-lence 1 or 2. The metal is obtained by heating cinnabar in a current of air and by condensing the vapor. It is a heavy,silvery-white metal; a rather poor conductor of heat, as compared with other metals; and a fair conductor of electricty.[Handbook, 84–85]

Third transition series The set of elements that belong to Ib, IIb, IIIb, IVb, Vb, VIb, Vllb, and VIII groups of the sixth period.(a)

ElementReactiveness

NonmetalHalogen

SemimetalMetal

Transition metalFirst transition seriesSecond transition seriesThird transition series

LanthanideActinide

Nontransition metalAlkalaiAlkalai terreum

(b)

Concept Synonyms Acronyms Instances Class Instance Relationsname attributes attributes

Element — Elm. — — Atomic number Has structureAtomic volume at 20°CAtomic weightChemical groupChemical periodDensity at 20°CElectronegativityMelting point…

Third Sixth-period 3TS. Gold — — —transition transition Hafniumseries series Mercury

OsmiumIridiumPlatinumRheniumTantalumWolfram

(d)

.

cept-classification trees. Figure 5c presentsa simplified diagram of the ad hoc binaryrelations in the Chemicals ontology. TheChemical-Elements ontology includes theChemical-Crystal ontology because thesource concept of the relations named Has-Structure is in the Chemical-Elementshierarchy. Similarly, if the relation Is-in-Element is defined as the inverse relation ofHas-Structure, the Chemical-Crystalontology can be said to include the Chemical-Elements ontology.

For each concept-classification tree gen-erated, we built these IRs:

The concept dictionary contains all thedomain concepts, instances of such con-cepts, class and instance attributes of theconcepts,and, optionally, concept synonyms

JANUARY/FEBRUARY 1999 41

Build theinstance-attribute

tables

Build thebinary-relation

tables

Build theconcept

dictionary

Build theinstancetables

Build theattribute-classification

trees

Build theformulatables

Startconceptualization

Conceptualize the ontology corresponding with each concept-classification tree

Build theglossary of

terms

Build theconcept-classification

trees

Build thebinary-relations

diagram

Build theclass-attribute

tables

Build thelogical-axioms

tables

Build theconstants

table

Figure 4. Conceptualization according to Methontology.

Density at 20°C

Atomic weightAtomic volumeat 20°C

Density formula

(i)

Relation name Has structureSource concept ElementSource cardinality (0, n)Target concept Crystalline structureTarget cardinality (0, n)Mathematic properties —Inverse relation Is in elementReferences [Cullity, 78]

(e)

Axiom name High electronegativity of nonmetalsDescription Electronegativity of nonmetals is higher than 2.1Concept NonmetalReferred attributes ElectronegativityVariables N, EExpression For all (X, Y) (Non-Metal(X) and Electronegativity(X, Y) => Y > 2.1)Relations —References [Janssen, 90]

(g)

Instance Attribute ValueMercury Atomic number 80

Atomic weight 200.59Density at 20 degrees Celsius 13.546Electronegativity 1.9Melting point –38.842

(j)

Instance attribute name Density-at-20°CValue type Density-QuantityUnit of measure Kilogram/meter3

Precision 0.001Range of values [0, 25]Default value —Cardinality (1, n)Inferred from instance attribute Atomic-Weight

Atomic-VolumeInferred from class attribute —Inferred from constants —Formula DensityTo infer —References —(f)

Formula name DensityInferred attribute Density-at-20-Degrees-CelsiusFormula Density-at-20-Degrees-Celsius = Atomic-

Weight/Atomic-Volume-at-20-Degrees-Celsius

Description An element’s density is equal to its atomicweight divided by its atomic volume

Basic instance attributes Atomic-WeightAtomic-Volume-at-20-Degrees-Celsius

Basic class attributes —Constants —Precision —Constraints Atomic-Volume-at-20-Degrees-Celsius > 0

(h)

.

and acronyms. Figure 5d gives a small partof the concept dictionary of Chemical-Elements.

A binary-relations table specifies thename, the names of the source and target con-cept, the inverse relation, and so on for eachad hoc relation whose source concept is in theconcept-classification tree (see Figure 5e).

An instance-attribute tabledescribes eachinstance attribute in the concept dictionary(see Figure 5f). Instance attributes are attri-butes that are defined in the concept but thattake values in its instances. For example, achemical element’s atomic weight is properto each instance. For each instance attribute,we included

• its name;• the value type;• the measurement unit for numerical

values;• the accuracy for numerical values;• the range of values;• the default values;• minimum and maximum cardinality;• the instance attributes,class attributes,

and constants that are used to infer thevalue of the attribute that is being defined;

• the attributes that can be inferred usingthis attribute;

• the formula or rule for inferring theattribute that is being defined; and

• the references used to fill in the attribute.

A class-attribute table describes con-cepts,not concept instances,for each classattribute in the concept dictionary. So,foreach class attribute, the table will give thename, possible value type, measurementunit for numerical values,value accuracy,attribute cardinality, instance attributes forwhich a value can be inferred using thevalue of this attribute, references,and so on.

A logical-axioms table defines the con-cepts by means of logical expressions thatare always true (see Figure 5g). Each definedaxiom includes its name, its natural-languagedescription, the concept to which the axiomrefers, the attributes used in the axiom,thelogical expression that formally describes theaxiom using FOPC (first-order predicate cal-culus),and references.

A constants tablespecifies each constant’sname, its natural-language description, itsvalue type (number, mass,and so on),its con-stant value, its measurement unit (for numer-ical constants),the attributes that can beinferred using the constant,and references.

A formula tabledescribes each formula inthe instance-attribute tables (see Figure 5h).We used these tables to infer numericalinstance-attribute values from the valuestaken by other instance attributes,class attri-butes,or even constants. Each table shouldspecify

• the formula’s name,• the attributes inferred with the formula,• the formula’s mathematical expression,• its natural-language description,• the instance and class attributes and con-

stants used in the calculation,• the accuracy with which the value will be

calculated,• the constraints under which using the for-

mula makes sense, and

• the references employed in filling in theformula table.

An attribute-classification treegraphicallyshows related attributes and constants in aroot attribute inference sequence, and thesequence of the formulas employed (see Fig-ure 5i). We used it to validate that all attri-butes used in the formula make sense and noattributes have been omitted.

An instance table lists the name, the attri-butes with known values in a instance,and thevalues of the above attributes,for each instancein the concept dictionary (see Figure 5j).

The process of building these IRs is notsequential in the sense of a waterfall life-cyclemodel,but it must follow some order so as toassure the consistency and completeness ofthe represented knowledge. Embedded in theconceptualization method are a series of con-trols for verifying that each IR is used cor-

rectly and that the knowledge represented isvalid—that is, that the semantics of the con-ceptualized knowledge is what it should be.Asunción Gómez-Pérez,Mariano FernándezLópez,and Antonio de Vicente have provideda detailed description of the IR evaluation.9

Our experience shows that domain expertsand human end users understand and validatemost of the Methontology IRs. In one set oftrials,two environmental and chemical expertsunderstood and validated 80% of the knowl-edge represented in the IRs. Also, we foundthat, from the knowledge-acquisition point ofview, experts can fill in many of the IRs.

Knowledge acquisition.This is an indepen-dent activity within ontology development.However, it coincides with other activities.For Chemicals,we acquired most knowledgeat the start of ontology development. Thelevel of knowledge acquisition fell as devel-opment progressed and we became morefamiliar with the application domain.

Knowledge acquisition occurred in threestages:

(1) We held preliminary meetings with theexpert to look for general,not detailed,knowledge. The depth of these meet-ings was minimal; we were looking forthe coarse grain—the overview.

(2) We studied the documentation. Weneeded to learn as much as possibleabout the domain of expertise (chem-istry), to save the time the expert wouldotherwise have spent on instructing usin the domain. That’s why having amethod with which experts can buildtheir own ontologies is very useful.

(3) Having obtained some basic knowledge,we initiated the expert-knowledge-acquisition cycle. We started by look-ing for more general knowledge andgradually moved down into the partic-ular details for configuring the fullontology.

During knowledge acquisition,we usedthe following set of KBS knowledge-acqui-sition techniques in an integrated manner:

• Nonstructured interviews with experts tobuild a preliminary draft of the require-ments-specification document. They out-put terms,definitions,a concept classifi-cation, and so on.

• Informal text analysisto study the mainconcepts in books and handbooks. This

42 IEEE INTELLIGENT SYSTEMS

THE PROCESS OF BUILDING

THESE IRS IS NOT SEQUEN-TIAL IN THE SENSE OF A

WATERFALL LIFE-CYCLE

MODEL, BUT IT MUST

FOLLOW SOME ORDER SO AS

TO ASSURE THE CONSISTENCY

AND COMPLETENESS OF THE

REPRESENTED KNOWLEDGE.

.

study enabled us to fill in IRs such as theconcept dictionary.

• Formal text analysis. We performed thismanually without using specialized envi-ronments for this purpose. First,we iden-tif ied the patterns to be located in the text.For example, for Chemicals,some of thestructures to be detected were “A is B,”“the highest value of A is attained in B,”and “A increases as B increases.” After-ward, we selected the instantiated struc-tures in the text that matched the patterns.Finally,we analyzed the marked sentencesto extract attributes,natural-language def-initions, rules,assignation of values toattributes,and so on.

• Structured interviews with the expert to getspecific and detailed knowledge about con-cepts,their properties,and their relation-ships with other concepts,and to evaluatethe conceptual model once the conceptu-alization activity is complete. For Chemi-cals,because the expert was familiar withthe IRs,we used structured interviews forvalidation purposes. We delivered the IRsto the expert, who proposed changes.

• Domain table analysis. This was very use-ful for ascertaining the values of the con-cept attributes and for identifying certaindata regularities. For example, we couldget electronegativity attribute values foreach element from the electronegativitiestable—for instance, checking that theelectronegativity of nonmetals is over2.1. However, this technique can be riskywhen data are taken from domain tableswhose sources differ, because they areprobably based on different criteria. Elec-tronegativity, for example, can be obtainedaccording to the criterion of Linus Paul-ing or Robert Mulliken.

• Domain-graph analysisto look for regu-larities. For example, using a graph thatrelated atomic numbers to volumes,weconcluded that the atomic volume of allthe lanthanides is similar. If we had haddomain graphs with exact data,we couldhave obtained information similar to thatoutput by domain-table analysis.

• Units-of-measurement analysisto deter-mine the attributes involved in formulasand to determine the quantities of theseattributes.

• Detailed reviews by the expert. Whenconceptualization was at an advancedstage, we submitted the IRs to the expertfor detailed inspection. After several daysworking on his own, he returned the

tables and trees with a series of sugges-tions and corrections.

• Formula analysisto check whether theformulas are correct and to determine theirattributes. For example, for Chemical-Elements, the expert originally ex-pressed the density formula as density=mass/volume. The expert recommendedthat masswas the Atomic-Weight; vol-ume, the Atomic-Volume at a given tem-perature (specifically, 20°C); and density,the element’s Density at that tempera-ture. Afterward, we checked the formulafor correctness,applying the formula toseveral cases in which the three data wereknown. We then analyzed the units ofmeasurement.

The expert was very important in all thesetechniques (although he was not alwaysdirectly involved),because he gave clues asto what we were to look for. For example,thanks to the expert, we knew that the Lan-thanides have properties very similar tothose of Lanthanum. Therefore, we alwayschecked in the tables and the graphs whetherit was possible to affirm in the ontology thatthe maximum and minimum value within thelanthanides was very close.

Integration. Throughout ontology devel-opment,we identified terms that could beincluded from other ontologies. For theChemicals ontologies,we found these pos-sibilities for reuse of ontologies stored in theOntology Server:KIF-Number supplied allthe mathematical operators (multiplication,sum,and so on). KIF-List contained thedefinitions for building lists. Standard-Dimensions10 included terms such asmass-quantity and length-quantity,which define an attribute that stores a value

that is a mass or length. Finally, StandardUnits defined the SI (Système Interna-tional) units of measurement. It providedsome, but not all,of the units of measure-ment identified in the conceptualization.

Having identified candidate ontologies forreuse, we checked that these ontologies hadbeen validated and verif ied. Because no soft-ware environment for validating ontologiesexists,we did this manually, following theguidelines given by Asunción Gómez-Pérez.11

Implementation. Finally, ODE automati-cally generated Ontolingua language codeusing a translator that transforms the con-ceptual model into an implemented model.We’ll describe this in the next section.

ODE

The Ontology Design Environment’s goal isto support the ontologist throughout ontologydevelopment,from requirements specifica-tion,through knowledge acquisition and con-ceptualization, to implementation, with asmuch integration and evaluation as possible.To achieve this goal,ODE seeks to automateeach ontology-development activity and auto-matically integrate the results of each phasewith the input of the following phase.

ODE capabilities. Because the conceptual-ization of a complete and consistent ontol-ogy involves the management of a hugeamount of information, we stored the entireontology in a relational database. This hasthe big advantage that the applications accessthe ontology using SQL (Structured QueryLanguage), which encourages the use ofontologies in real applications. ODE usesSQL directly on the IRs and not on the data-base internal structure. Therefore, the user orapplication that accesses the ontology onlyhas to know the IRs that are used for con-ceptualization and not how the conceptual-ization is stored in the database.

To maintain the consistency within eachIR and between IRs,we studied the con-straints in the fields of a conceptual table orbetween the fields belonging to different con-ceptual tables. This study, based on proposedrules of verification of the IRs,9 seeks to iden-tify any effects possibly caused by the oper-ations of editing an ontology at the concep-tual level and how the above operations areimplemented in the database.

Because user experience in ontology de-

JANUARY/FEBRUARY 1999 43

THE USER OR APPLICATION

THAT ACCESSES THE ONTOL-OGY ONLY HAS TO KNOW THE

IRS THAT ARE USED FOR CON-CEPTUALIZATION AND NOT

HOW THE CONCEPTUALIZATION

IS STORED IN THE DATABASE.

.

velopment varies,ODE provides optionalguided conceptualization that helps inexpe-rienced users learn about ontology develop-ment. This conceptualization is very usefulfor domain experts who want to build theirown ontologies.

ODE currently includes these functions:

• Managing ontologies (opening, closing,saving, saving as,integrating, printing,and so on);

• Managing ontologies in tabular notation(creating and removing tables,adding anddeleting table rows,printing tables,and

so on);• Managing IRs in graphic notation;• Automatically generating code in formal

languages;• Customizing the user interface;• Managing the development-environment

help; and• Managing conceptualization and user

interface errors.

We’ve designed ODE to be completelyindependent of other systems that manageontologies. For example, although ODE gen-erates Ontolingua code in ASCII, ODE does

not interact with Ontolingua.ODE requires a Pentium running Win-

dows 95 and Access 7. ODE has been pro-grammed in Visual Basic version 5.0. Its userinterface complies with Microsoft designstandards for the development of event-oriented applications.

The translator module. Because ODE del-egates implementation to fully automatedcode generators,nonexperts in the languagesin which ontologies are implemented canspecify ontologies using the IRs already pre-sented. To assure translation of the concep-tual model to as many languages as possible,we designed ODE’s translator to be modularand reusable. The translator module incor-porates these elements:

First, we use a grammar to declarativelyexpress the conceptual model. We use thisrules notation:

• A → B means A has the structure indi-cated in B;

• [A] means A is optional;• [A | B] means A or B;• {A} x

y means A is repeated a number oftimes that is between x and y;

• Terminal symbols are in bold and non-terminal symbols are in italics;

• — means the field is filled in with novalue.

Figure 6 shows how we express the datadictionary.

Second, we identified a series of transfor-mation rules containing the structures to begenerated in each language. We use the samenotation as for the IRs. For example, Figure7 shows the transformation rule for definingclasses in Ontolingua.

Third, for each type of valid definition inthe language, we built a table that relates theterms used in the transformation rules to theterms employed in the conceptual model (seeTable 1). So,the nonterminal symbols of thetransformation rules go in the left-hand col-umn; the fields of the IRs needed to get theinformation represented by the transforma-tion rule go in the right-hand column. Table1 shows that

• the name of the class in the implementa-tion matches a concept name in the con-cept dictionary;

• the documentation in the implementationis obtained from the description in theglossary of terms;

44 IEEE INTELLIGENT SYSTEMS

Figure 6. The expression of the data dictionary in the ODE rules notation.

data_dictionary → Concept name wordSynonyms [{word}1n | —]Acronyms [{word}1n | —]Instances [{word}1n | —]Class attributes [{word}1n | —]Instance attributes [{word}1n | —]Relations [{word}1n | —]

Figure 8. Ontolingua code generated by the ODE translator for the concept Element.

;;; Element

(Define-Class Element (?Element)

“A substance that is made up of atoms with the same number of

protons.”

:def

(and

(Has-One ?Element Atomic-Number)

(Has-Some ?Element Atomic-Volume-at-20-Degrees-Celsius)

(Has-One ?Element Atomic-Weight)

(Has-One ?Element Chemical-Group)

(Has-One ?Element Chemical-Period)

(Has-Some ?Element Density-at-20-Degrees-Celsius)

(Has-One ?Element Electronegativity)

(Has-Some ?Element Melting-Point)

…………)

:axiom-def

(Exhaustive-Subclass-Partition Element

(Setof Reactiveness Reactiveless)))

Figure 7. The transformation rule for defining classes in Ontolingua.

def_class → {;;; class(Define-Class class (?class)“documentation”[:def(and

{(superclass ?class)}[(Superclass-Of {subclass})][(Has-Instance ?class {instance})][{(Has-at-Most relation ?class max_cardinality)(Has-at-Least relation ?class min_cardinality) |(Has-One ?class relation) |(Has-Some ?class relation)]}0n)(

[:axiom-def (Exhaustive-Subclass-Partition class(Setof {subclass}1n))])}1n

.

• each superclass and subclass name is sup-plied by the concept-classification tree;

• the names of the instances are taken fromthe instance field defined in the conceptdictionary;

• the relation names are obtained from theinstance and class attributes and the rela-tions defined for the concept in questionin the concept dictionary; and

• the cardinalities appear in the instance- orclass-attribute tables and ad hoc binary-relation tables.

Figure 8 shows an example of the Ontolin-gua code generated for the Chemicals ontol-ogy. The generated code is error-free, whichdramatically cuts the time and effort involvedin implementation.

Furthermore, the translator’s architectureallows other translators to be developed inseries. By merely changing the rules thatidentify the transformation rules of the termsto be generated and changing the second col-umn of the table that relates the conceptual-ization to the implementation, we can builda new translator.

METHONTOLOGY’S TABULARand graphic-based notation is a user-friendlyapproach to knowledge acquisition by do-main experts who are not knowledge engi-neers. So,all the ontologies built using thisapproach are not hand-crafted; they rely onthe same conceptualization process; they

have been built independently of their enduse; and the final ontology code is generatedautomatically using ODE translators.

The Chemicals ontology is being used inseveral applications. Ontogeneration6 is aninformation-retrieval system that lets Span-ish users consult and access,in their ownlanguage, the knowledge contained in theChemicals ontology. The system uses adomain ontology (Chemicals) and a linguis-tic ontology (the Generalized Upper Mo-del12) to generate Spanish text descriptionsin response to the queries in the chemistrydomain.

The other application is Chemical Onto-Agent,13an ontology-based WWW broker inthe chemistry domain. It is a teaching brokerthat lets students learn chemistry in a verystraightforward manner, providing the nec-essary domain knowledge and helping stu-dents test their skills. To make the answersmore understandable to students,this systemcan interact with Ontogeneration.

We are building other ontologies accord-ing to the Methontology framework and usingODE: the (KA)2-Ontology, developed bythe Knowledge Annotation Initiative,14whichseeks to model the knowledge-acquisitioncommunity (its researchers,topics,products,and so on); the Reference-Ontology,13 adomain ontology about ontologies; and aMonatomic-Ions-Ontology, to beincluded in an Environmental-Pollu-tants-Ontology. These two ontologiesreuse the Chemicals ontology.

AcknowledgmentsThis work has been partially supported by the

program Ayudas de I&D para grupos potencial-mente competitivos of the Polytechnic Universityof Madrid (Reference A9706).

References1. M. Fernández,A. Gómez-Pérez, and N.

Juristo, “METHONTOLOGY: From Onto-logical Art towards Ontological Engineer-ing,” Proc. AAAI Spring Symp. Series,AAAIPress,Menlo Park, Calif., 1997,pp. 33–40.

2. A. Gómez-Pérez,“Knowledge Sharing andReuse,” The Handbook of Applied ExpertSystems, J. Liebowitz, ed., CRC Press,BocaRaton,Fla.,1998.

3. A. Newell, “The Knowledge Level,” Artifi-cial Intelligence, Vol. 18,No. 1,Jan. 1982,pp. 87–127.

4. M. Fernández,Chemicals:Ontología de Ele-mentos Químicos(Ontology of ChemicalElements),final-year project, Facultad deInformática de la Universidad Politécnica deMadrid, 1996.

5. T.R. Gruber, “Toward Principles for theDesign of Ontologies Used for KnowledgeSharing,” Proc. Int’l Workshop on FormalOntology, 1992. Also available as Tech.Report KSL-93-04,Knowledge Systems Lab-oratory,Stanford Univ.,Stanford,Calif.,1993;http://ksl-web.stanford.edu/publications.

6. G. Aguado et al.,“Ontogeneration: ReusingDomain and Linguistic Ontologies for Span-ish Text Generation,” Workshop on Applica-tions of Ontologies and Problem SolvingMethods(part of ECAI ’98: 1996 EuropeanConf. AI), European Coordinating Commit-tee for Artif icial Intelligence, 1998,pp. 1–10.

7. A. Farqhuar et al.,Collaborative OntologyConstruction for Information Integration,Tech. Report KSL-95-69,Knowledge Sys-tems Laboratory, Stanford Univ.,1995; http://ksl-web.stanford.edu/publications.

8. A. Gómez-Pérez et al., Ingeniería delConocimiento:Construcción de SistemasExperto (Knowledge Engineering:The Con-struction of Expert Systems),Editorial Cen-tro de Estudios Ramón Areces,Madrid, 1997.

9. A. Gómez-Pérez,M. Fernández,and A. DeVicente, “Towards a Method to ConceptualizeDomain Ontologies,” Workshop on Ontolog-ical Eng. (part of ECAI ’96: 1996 EuropeanConf. AI), European Coordinating Commit-tee for Artificial Intelligence,1996,pp. 41–52.

10. T. Gruber and G. Olsen,“An Ontology forEngineering Mathematics,” Proc. Fourth Int’lConf. Principles of Knowledge Representa-tion and Reasoning, Morgan-Kaufmann,SanFrancisco,1994. Also available as Tech.Report KSL-94-18, Knowledge SystemsLaboratory, Stanford Univ., 1994; http://ksl-web.stanford.edu/publications.

11. A. Gómez-Pérez,“Towards a Framework toVerify Knowledge Sharing Technology,”Expert Systems with Applications, Vol. 11,No. 4,1996,pp. 519–529.

JANUARY/FEBRUARY 1999 45

Table 1. The relationship between conceptualization and implementation for classes.

IMPLEMENTATION CONCEPTUALIZATION

Class “Concept name” appearing in the concept dictionaryDocumentation “Description” in the glossary of termsSuperclass Name of superclasses to which the class is related in the concept-classi-

fication treeSubclass Name of subclasses to which the class is related in the concept-classifi-

cation treeInstance Instances appearing in the concept dictionaryRelation Instance attributes, class attributes, or relations in the concept dictionaryMax cardinality Maximum cardinality expressed for the attribute in the Cardinality field of

its instance-attribute table or binary-relation tableMin cardinality Minimum cardinality expressed for the attribute in the Cardinality field of

its instance-attribute table or binary-relations table

.

12. J.A. Bateman, B. Magnini, and G. Fabris,“The Generalized Upper Model KnowledgeBase: Organization and Use,”Towards VeryLarge Knowledge Bases, IOS Press,Amster-dam, 1995, pp. 60–72.

13. J. Arpírez et al., “(ONTO)2Agent: An Ontol-ogy-Based WWW Broker to Select Ontolo-gies,”Workshop on Applications of Ontolo-gies and Problem Solving Methods (part ofECAI ’98: 1996 European Conf. AI), Euro-pean Coordinating Committee for ArtificialIntelligence, 1998, pp. 16–24.

14. V.R. Benjamins, D. Fensel, and A. Gómez-Pérez, “Ontology-Based Knowledge Man-agement in Networks,”Proc. Second Int’lConf. Practical Aspects of Knowledge Man-agement, 1998.

Mariano Fernández Lópezis a teaching assis-tant at the Centro de Estudios Universitarios and aninvited professor in the Universidad Pontificia deSalamanca. His research activities include method-ologies for building ontologies, ontological reengi-neering, and uses of ontologies in applications. Hereceived his BA in computer science from thePolytechnic University of Madrid. He received hisMSC in knowledge and software engineering fromthe Facultad de Informática de Madrid, and is aPhD student in computer science there. He belongs

to the Knowledge Reusing Group of the ArtificialIntelligence Laboratory at the Facultad de Infor-mática de Madrid. He has received the Gold Chip.Contact him at Laboratorio de Inteligencia Artifi-cial, Facultad de Informática, Univ. Politécnica deMadrid, Campus de Montegancedo sn., Boadilladel Monte, 28660 Madrid, Spain; mfernand@delicias.dia.fi.upm.es.

Asunción Gómez-Pérezis an associate professorat the Computer Science School at the PolytechnicUniversity of Madrid. She also is the executivedirector of the School’s Artificial Intelligence Lab-oratory. Her research activities include theoreticalontological foundations, methodologies for build-ing ontologies, ontological reengineering, evalu-ation of ontologies, uses of ontologies in applica-tions, and knowledge management on the Web.She received her BA in computer science, herMSC in knowledge engineering, and her PhD incomputer science, all from the Polytechnic Uni-versity of Madrid. She also has an MSC in busi-ness administration from the Universidad Pontif-icia de Comillas, Spain. Contact her at Laboratoriode Inteligencia Artificial, Facultad de Informática,Univ. Politécnica de Madrid, Campus de Monte-gancedo sn., Boadilla del Monte, 28660 Madrid,Spain; asun@delicias.dia.fi.upm.es or asun@fi.upm.es.

Alejandro Pazos Sierraleads the RNASA Lab(Neural Networks and Adaptative Systems Labo-

ratory), which he founded in 1995. He received hisMDr in Medicine from Santiago de CompostelaUniversity, his MS in knowledge engineering andhis PhD in computer science from the PolytechnicUniversity of Madrid, and his PhD in medicinefrom the Universidad Complutense de Madrid. Heis a member of the IEEE, ACM, InternationalNeural Network Society, IAKE (InternationalAssociation of Knowledge), American Associa-tion for the Advancement of Science, Genetic andEvolutionary Computation Conference (GECCO)Program Committee, and New York Academy ofScience. Contact him at Laboratorio de Redes deNeuronas,Artificiais e Sistemas Adaptativos, De-partamento de Computación, Facultad de Infor-mática, Univ. da Coruña, Campus de Elviña,15071 A Coruña, Spain; ciapazos@udc.es.

Juan Pazos Sierrais a professor of computer sci-ence at the Department of Artificial Intelligenceof the School of Computer Science in Madrid,where he set up the first Spanish AI laboratory. Heand his colleagues developed the domino program,Luciano, which was awarded a gold medal at the1989 Computer Olympics in London. He receivedthe first Spanish doctorate in computer sciencefrom the Polytechnic University of Madrid. Con-tact him at Laboratorio de Inteligencia Artificial,Facultad de Informática, Univ. Politécnica deMadrid, Campus de Montegancedo sn., Boadilladel Monte, 28660 Madrid, Spain; jpazos@delicias.dia.fi.upm.es.

46 IEEE INTELLIGENT SYSTEMS

MobilityFocusing on the idea of mobile people triggering system action and exploring difficultiesinherent in locating mobile users and locations.

Actors & AgentsRepresenting a cross section of current work involving actors and agents—autonomy,identity, interaction, communication, coordination, mobility, distribution, and parallelism.

Object-Oriented Technology Showcasing traditional and innovative uses of object-oriented languages, systems, and technologies.

WorkflowInvestigating distributed computing solutions that enable rapid and dependable provisioningof complex services involved in business processes.

Data MiningFocusing on system-level issues and mechanisms as well as the social implications of currentand planned data-mining applications.

Check us out at http://computer.org/concurrencyCheck us out at http://computer.org/concurrency

ConcurrencyConcurrencyIEEE

IEEE

http://computer.org

PARALL E L , D I S TR IBUTED & MOB I L E COMPUT ING / OCTOBER–DECEMBER 1998

DynamicallySchedulingReal-Time

Tasks

DynamicallySchedulingReal-Time

Tasks

User-extensible OO file systems

Mobile computing and smart spaces

Democratization of concurrent programming

Scalable multimedia servers

Also:Also:

Appearing in 1999Appearing in 1999ConcurrencyIEEE

.