METHONTOLOGY:From Ontological Art Towards Ontological Engineering

Mariano Ferndndez, Asunci6n G6mez-P~rez, Natalia JuristoLaboratorio de Inteligencia Artificial

Facultad de Inform~iticaUniversidad Polittcnica de Madrid

Campus de Montegancedo sn.Boadilla del Monte, 28660. Madrid, Spain.

Tel: (34-1) 336-74-39, Fax: (34-1) 336-7412Emaii: {mfernand, asun, natalia} @delicias.dia.fi.upm.es

AbstactThis paper does not pretend either to transformcompletely the ontological art in engineering or toenumerate exhaustively the complete set of works thathas been reported in this area. Its goal is to clarify toreaders interested in building ontologies from scratch,the activities they should perform and in which order,as well as the set of techniques to be used in eachphase of the methodology. This paper only presents aset of activities that conform the ontologydevelopment process, a life cycle to build ontologiesbased in evolving prototypes, andMETHONTOLOGY, a well-structured methodologyused to build ontologies from scratch. This papergathers the experience of the authors on building anontology in the domain of chemicals.

1. IntroductionUntil now, a big quantity of ontologies have beendeveloped by different groups, under different approaches,and using different methods and techniques. However a fewworks have been published about how to proceed, showingthe practices, design criteria, activities, methodologies, andtools used to build them. The consequence is clear, theabsences of standardized activities, life cycles, andsystematic methodologies as well as a set of well-defineddesign criteria, techniques and tools make the ontologiesdevelopment a craft rather than an engineering activity. So,the art will became engineering when there exist adefinition and standardization of a life cycle that goes fromrequirements definition to maintenance of the finishedproduct, as well as methodologies and techniques that drivetheir development.

One of the main problems that Knowledge Engineers(KEs) have when building expert systems is the difficultyof getting a set of requirements for the system.Requirements specify how the system will behave. Since

experts are not usually able to describe in a concrete andcomplete way how they behave in the application domain,it is hard for KEs to specify the future behavior of theKnowledge-Based Systems (KBS). So, KBS are usuallybuilt incrementally using evolving prototypes in which thedeficiencies of the final product of each cycle can be used asthe specification of the next prototype. In ontologies do notoccur the same. Ontologies are built to be reused or sharedanytime, anywhere, and independently of the behavior anddomain of the application that uses them. So, ontologistsshould be able to specify, at least partially, a big portion ofthe needed vocabulary that the ontology will cover for agiven domain. This is the main difference betweenontologies and K.BS development processes. Consequently,methodologies used to build KBSs can not completely beapplied to build ontologies.

In the following sections, this paper presents a set ofactivities that conforms the ontology development process(section #2), a life cycle of ontologies (section #3) METHONTOLOGY (section #4), a method to buildontoiogies from scratch.

2. Ontology Development Process

The ontology development process refers to what activitiesyou need to carry out when building your ontologies:However, the ontology development process does notimply an order of execution of such activities. Its goal is toidentify the list of activities to be completed. Usually verbsare used to refer to such activities. The ontologydevelopment process is composed of the following:* Before building your ontology, you should plan the

main tasks to be done, how they will be arranged,how much time you need to perform them and withwhich resources (people, software and hardware).

* As you do not plan a trip without knowing yourdestination (your goal), you should not start the

33

From: AAAI Technical Report SS-97-06. Compilation copyright 1997, AAAI (www.aaai.org). All rights reserved.

development of your ontology without knowing itspurpose and scope. So, try to answer the questions:why this ontology is being built and what are itsintended uses and end-users. Then, specify or writethe answers in an ontology requirementsspecification document. As an example of aninformal and formal specification of two independentontoiogies in the domain of modeling enterprise, tocite the Enterprise ontology (by Uschold) and theTOVE ontology (by Gruninger). Although theiroutputs are almost the same (a set of terms), thedegree of formality in writing their requirementsspecification documents are different. The Enterpriseontology has been specified in natural language andthe TOVE ontology using a set of competencequestions (Uschold & Gruninger 1996).Unless you wish to build a toy ontology or unlessyou are an expert in the domain, you will elicitknowledge using KBSs knowledge elicitationtechniques. As a result, you should be able to listthe sources of knowledge and give, a roughdescription of how you carried out the processes, andof the techniques you used. The most extensivework on capturing knowledge was reported byUschold and Gruninger (Uschoid & Gruninger1996).Once you have acquired enough knowledge youconceptualize it in a conceptual model thatdescribes the problem and its solution. A set ofintermediate representations for conceptualizing adomain ontology of objects were presented byG6mez-P6rez and colleagues at (G6mez-P6rez,Fern~indez, & De Vicente 1996).To transform the conceptual model into a formal orsemi-compatible model, you need to formalize itusing frame-oriented or description logicrepresentation systems.Ontoiogies are built to be reused. In this way,duplication of work in building ontologies has lesssense than its duplication when you build atraditional Knowledge Base. So, you should reuseexisting ontologies. Try to integrate as much aspossible existing ontologies in your ontology. Amethod to integrate ontoiogically heterogeneoustaxonomic knowledge and its application to themedical domain was presented by Gangemi andcolleagues in (Gangemi, Steve, & Giacomelli1996). Farquhar and colleagues (Farquar et al. 1995)have identified four kind of relationships betweenontologies that have been integrated: inclusion,polymorphic refinement, circular dependencies andrestrictions. Their ontology server provides asemantic model for ontology inclusion in order toavoid conflict between symbols.To make your ontology computable, you need toimplement it in a formal language. As a reference

framework for selecting target languages, we wouldcite the comparative study performed by Speel andcolleagues at (Speel et al. 1995) as part of Pliniusproject (Vet, Speel, & Mars 1995).

* What do you think that it will happen if you use ameta-ontology or ontologies already built withwrong definitions? Probably, your ontology will bewrong too. Before making your ontology availableto others, evaluate it, that is, make a technicaljudgment with respect to a frame of reference. Aframework for evaluating ontologies was providedby G6mez-P6rez and colleagues at (G6mez-P&ez,Juristo, & Pazos 1995).

* Have you ever try to modify or reuse a programwithout having a good documentation? Sure, youhave. The absence of a sound documentation is alsoan important obstacle when you reuse/shareontologies already built. So, if you wish yourontology to be reused/shared by others try todocument it as best you can. No work has beenpublished on this field.

* Anytime, anywhere, someone could ask forincluding or modifying definitions in the ontology.To maintain the ontology is an important activityto be done carefully. Guidelines for maintainingontologies are also needed.

We remark that the ontology development process doesnot imply an order on the execution of such tasks. Its goalis only to identify the list of activities to be done.

3. Ontology Life Cycle"Dont build your house starting by the roof", says aSpanish proverb to advice that activities require an order andthat they should be divided and carry out step by step in aplanned way, in order to succeed. In the previous section,we divided the ontology development process in a set ofactivities. However, we did not indicate the order and depthin which such activities should be done. It is obvious thatplanification and maintenance are the first and the last, butit is not clear whether or not knowledge acquisition istotally or partially simultaneous with the specification andconceptualization activities, if conceptualization precedes tothe integration and this one goes before theimplementation, if the evaluation and documentation aresequential to the implementation or if they should be doneas all the activities move forward, and if you should carryout an activity totally or partially before starting thefollowing.

First, the ontology life cycle answers the previousquestions identifying the set of stages though which theontology moves during its life. Making an analogy, wecould say that the ontology development process is similarto the production chains in a manufacturing domain as theontology is to the final product that such production chain

34

Activity States

Planification

L~ Activities

Acquiring KnowledgeDocumenting

Evaluating

Figure 1. States and activities

creates. Just as the life cycle of human beings movesforward sequentially and irreversibly through the followingstates: childhood, adolescence, youth, maturity and old age,the ontology life cycle moves forward through thefollowing states: specification, conceptualization,formalization, integration, implementation andmaintenance. So, the ontology development processtransforms the initial product (the need you have to buildthe ontology) into a final product (the evaluated,documented ontology, codified in a formal language). Theprevious states through which the ontology pass conformsits life cycle, as it is shown in figure 1. KnowledgeAcquisition, evaluation of ontologies and documentationarc tasks that are carried out during the whole life of theontology as figure 1 shows. In fact, unless the ontologistis an expert in the application domain, most of theacquisition is done simultaneously with the requirementsspecification phase and decreases as the ontologydevelopment process moves forward. In order to preventerror propagation, most of evaluation should be done duringthe earliest stages of the ontology development process.Finally, you should produce detailed documentation.

Second, the ontology life cycle shows when youshould perform the activities to move from a given state tothe next and in how much depth. Some life cycle modelshave been described in Software Engineering and transferredto Knowledge Engineering (Aionso et ai. 1996). As we saidbefore, the main problem facing KE when (s)be begins new KBS is to build a requirements specification document.Unlike, an ontologist must be able to partially specify a setof requirements before building an ontology, which willconstitute the initial core of the ontology. So, the ontology

life cycle is closer to a classic software life cycle than it isto a KBS life cycle.

The waterfall life cycle defined by Royce (Royce 1987)is the traditional life cycle model in Software Engineering.In this model, activities are sequential in the sense thatyou cannot move onto the next activity until you havecompletely finished the previous one. This model forces theontologist to identify all the terms at the beginning, andthe implementation must be a mirror of the specification,that is, it must satisfy the complete requirementsspecification document. Its main inconvenient is that theontology is static, you cannot include, remove or modifyterms in it. Obviously the use of a waterfall life cyclemodel is not adequate due to the absence of a completerequirements specification at the earliest stages of thedevelopment process and due to the evolution of theontologies definitions over time. Figure 2.a shows how thesystem grows under this approach. The incremental lifecycle (McCracken & Jackson 1982) solves some problems,allowing the partial specification of the requirements.According to this approach, the ontology would grow bylayers, allowing the inclusion of new definitions only whena new version is planned. This model prevents theinclusion of new definitions if they are not planned, but itdoes permit an incremental development. Figure 2.b showshow the ontology grows according this approach. Finally,the evolving prototype life cycle solves the previousproblems since the ontology grows depending on the needs.Indeed, this model lets you to modify, add, and removedefinitions in the ontology at any time. So, we think thatthe evolving prototypes are appropriate life cycle forbuilding ontologies.

35

Oa) Traditional b) Incremental c~ Evolving

Figure 2. How the ontology grows?

4. METHONTOLOGY: A Methodology toBuild Ontologies from Scratch

In general, methodologies give you a set of guidelines ofhow you should carry out the activities identified in theontology development process, what kinds of techniques arethe most appropriate in each activity and what productseach one produces. Until now, methodological approachesin building ontologies have been reported by Uschold in theEnterprise ontology, Gruninger in the TOVE project, bothin the domain of enterprise modeling (Uschold & Gruninger1996), and G6mez-P~rez and colleagues in the domain ofchemicals (G6mez-P~rez, Fem~dez, & De Vicente 1996).Figure 3 summarizes the activities proposed and what areequivalent.

Obviously, it is almost impossible to take the threeabove contributions to propose a general method forbuilding any kind of ontology or meta-ontology. Thissection presents METHONTOLOGY, a structured methodto build ontologies. It is based on the experience acquired indeveloping an ontology in the domain of chemicals.

4.1 SpecificationThe goal of the specification phase is to produce either aninformal, semi-formal or formal ontology specificationdocument written in natural language, using a set ofintermediate representations or using competency questions,respectively. METHONTOLOGY proposes that at least thefollowing information be included:a) The purpose of the ontology, including its intended

uses, scenarios of use, end-users, etc.b) Level of formality of the implemented ontology,

depending on the formality that will be use to codifythe terms and their meaning. Uschold (Uschold Gruninger 1996) classifies the degree or level offormality in a range of: highly informal, semi-informal, semi-formal or rigorously formalontologies, depending on whether terms and theirmeanings are codified in a language between naturallanguage and a rigorous formal language.

c) Scope, which includes the set of terms to berepresented, its characteristics and granularity.

1. Identify purpose and scope 1. Acquire knowledge2. Building the ontology ~ ,,1

captur_~v ,,~. Build a requirements specification2.1Ontology~ document

2.2 Ontology coding2.3 Integrating existin~

ontologie~,... .--. ,~3. Conceptualize the ontology

3. Evaluation-~" Implement the ontology

4. Guideliness for each phase b~5. Evaluation during each phase

6. Documentation after each phase

a) Uschold and Oruninger b) Gomez-Perez and colleagues

Figure 3.Relationship between phases of twomethodologies

The formality of the ontology specification documentvaries on its degree of formality depending on if you usenatt, ral language, competency questions or a middle-outapproach. For example, in a middle-out approach, in thescoping activity, you can use a glossary of terms to gatherthe set of terms that must be included in the ontology,whether or not you know their meaning at this stage of theontology development process. It is also advisable to groupconcepts in concepts classifications trees (G6mez-P&ez,Fernandez, & De Vicente). The use of these intermediaterepresentations will allow you not only to verify, at theearliest possible stage, relevant terms missed and to includethem in the specification document, but also to removeterms that are synonyms and not relevant in your ontologyanymore. The goal of these checks is to guarantee theconciseness and completeness of the ontology specificationdocument. Figure 4 shows a short example of an ontologyrequirements specification document in the domain ofchemicals.

Uschold (Uschoid & Gruninger 1996) gives excellent argument on the use of a middle-out as opposedthe classic bottom-up and top-down approach in identifyingthe main terms of your glossary. The main advantage of themiddle-out approach is that it allows you to identify theprimary concepts of the ontology you are starting on. Afterreaching agreement on such terms and their definition youcan move on to specialize or generalize them, only if theyare necessary. As a result, the terms that you use are morestable, and less re-work and overall effort are required.Since you can not prove the total completeness of yourontology specification document (any time, anywhere,someone may find a new relevant term to be included), youmust guarantee in a good ontology specification documentmust have the following properties:* Concision, that is, each and every term is relevant,

and there are no duplicated or irrelevant terms.

36

ONTOLOGY REQUIREMENT SPECIFICATION DOCUMENTDomain: ChemicalsDate: May, 15th 1996Conceptualized-by: Asunci6n G6mez-P,~rezImplemented-by: Muriano Fernandez-L6pez

Purpoee:Ontology about chemical substances to be used when informationabout chemical elements is required in teaching, manufacturing.analysis, etc. This ontology coul be used to ascertain, e.g..theatomic weight of the element Sodium.

Level of Formality: Semi-formal.

Scope: List of 103 elements of substances: Lithium, Sodium, Chlorine ....List of concepts: Halogen.~, noble-gases, semi.metal, metal .....At least information about the following properties: atomic-number.atomic-weight, atomic.wdume.at-20-degrees-celsiu.~, boiling-point,densi~...at-20-degree.~-celsi~, electronegativi~., electron-a1~mity,and .~3"mbol.

Sources of Knowledge: Handbook of Chemisto~ and Physics. 65th edition.CRC-Press, Inc. 1984-1985.

Figure 4. Ontology requirements specification in thedomain of chemicals.

Partial completeness, which is related with thecoverage of the terms, the stopover problem andlevel of granularity of each and every term.Consistency, which refers to all terms and theirmeanings making sense in the domain.

4.2. Knowledge AcquisitionIt is important to bear in mind that knowledge acquisitionis an independent activity in the ontology developmentprocess. However, it is coincident with other activities. Aswe told before, most of the acquisition is donesimultaneously with the requirements specification phase,and decreases as the ontology development process movesforward.

Experts, books, handbooks, figures, tables and evenother ontologies are sources of knowledge from which theknowledge can he elucidated using in conjunctiontechniques such us: brainstorming, interviews, formal andinformal analysis of texts, and knowledge acquisition tools.For example, if you have no a clear idea of the purpose ofyour ontology, brainstorming technique, informalinterviews with experts, and inspecting similar ontologieswill allow you to elaborate a first glossary with termspotentially relevant. To refine the list of terms and theirmeaning, formal and informal analysis of text techniques inbooks and handbooks in conjunction with structured andnon-structured interviews with experts might be used toinclude or remove terms in the glossary. Interviews toexpert might help you to build concepts classificationstrees and to contrast them against figures given in books.

The techniques we used in the knowledge acquisition phaseof the chemical ontology were:* Non-structured interviews with experts, to build a

preliminary draft of the requirements specificationdocument.

* Informal text analysis, to study the main conceptsgiven in books and handbooks. This study enablesyou to fill in the set of intermediate representationsof the conceptualization.

* Formal text analysis. The first thing to do is toidentify the structures to be detected (definition,affirmation, etc.) and the kind of knowledgecontributed by each one (concepts, attributes, values,and relationships).

* Structured interviews with experts to get specific anddetailed knowledge about concepts, their propertiesand their relationships, to evaluate the conceptualmodel once the conceptualization activity has beenfinished, and to evaluate implementation.

4.3. ConceptualizationIn this activity, you will structure the domain knowledge ina conceptual model that describes the problem and itssolution in terms of the domain vocabulary identified in theontology specification activity. The first thing to do is tobuild a complete Glossary of Terms (GT). Terms includeconcepts, instances, verbs and properties. So, the GTidentifies and gathers all the useful and potentially usabledomain knowledge and its meanings. Note that you do notstart from scratch when you develop your GT. If you madea good specification document, many terms will have beenidentified in that document. Other will be identified as theontology construction process advances. Then, these newterms must be included in the GT.

Once you have almost completed the GT, you mustgroup terms as concepts and verbs. Each set ofconcepts/verbs would include concepts/verbs that areclosely related to other concepts/verbs inside the samegroup as opposed to other groups. Indeed, for each set ofrelated concepts and related verbs, a concepts classificationtree and a verbs diagram is built. After they have beenbuilt, you can split your ontology development processinto different, but related, teams. Those related withconcepts, should follow the guidelines presented by G6mez-Ptrez and colleagues in (G6mez-Ptrez, Fern;indez, & DeVicente 1996), and those encharged of conceptualizingverbs are presented at (Vicente 1997). Figure 5 graphicallysummarizes the intermediate representations used in theconceptualization phase.

Concepts will be described using (G6mez-Ptrez,Fern;tndez, & De Vicente 1996): Data Dictionary, whichdescribes and gathers all the useful and potentially usabledomain concepts, their meanings, attributes, instances, etc.;tables of instance attributes, which provide informationabout the attribute or about its values at the instance; tables

37

of class attributes, to describe the concept itselL not itsinstances; tables of constants, used to specify informationrelated to the domain of knowledge that always take thesame value; tables of instances, which define instances; andattributes classification trees, to graphically displayattributes and constants related in the inference sequence ofthe root attributes, as well as the sequence of formulas orrules to be executed to infer such attributes.

Verbs represent actions in the domain. They could bedescribed using (Vicente 1997): Verbs Di ctionary, toexpress the meaning of verbs in a declarative way; tables ofconditions, which specify a set of conditions to be satisfiedbefore executing an action, or a set of conditions to beguaranteed after the execution of an action. Finally, to saythat tables of formulas and tables of rules gatherknowledge about formulas and rules. Note that bothbranches use these two intermediate representations.

4IData DictionariesITables of Instance AttributesITables of Class AttributesITables of Constants[Tables of Instances[Attributes Classification Trees

Meta-Ontoi%7 The frame-ontoio~), in Ontolin| uaTerm in your Ontology to be reused Name of theConceptualization term in the

ontologyKilometer Standard-Units in Ontolin~ua KilometerCentimeter Standard-Units in Ontolin~:ua UndefinedExponent KIF-Numbers in Ontolin~ua Expt

Glossary of Terms [

Verbs DictionaryTable of Conditions

Table of FormulasTable of Rules

Figure 5. Set of Intermediate Representations in theconceptualization phase.

In sum, METHONTOLOGY produces in this phase aconceptual model expressed as a set of well-defineddeliverables that will allow to the final users: (a) ascertain whether or not an ontology is useful and usablefor a given application without inspecting its source code;and (b) to compare the scope and completeness of severalontologies, their reusability, and shareability by analyzingthe knowledge expressed in each IR.

4.4. IntegrationWith the goal of speeding up the construction of yourontology, you might consider reuse of definitions alreadybuilt into other ontologies instead of starting from scratch.In this case, we propose the following:I. Inspect meta-ontologies (i.e., in Cyc, in

Ontolingua .... ) to select those that better fit your

conceptualization. The goal is to guarantee that thesets of new and reused definitions are based upon thesame set of basic terms. If existing meta-ontologiesare not appropriate for your ontology, you shouldstart the definition and implementation of a newmeta-ontoiogy in a formal language.

2. Whether or not you reuse existing meta-ontologies,the next step is to find out which libraries ofontologies provide definitions of terms whosesemantic and implementation is coherent with theterms identified in your conceptualization. Once youhave chosen the most appropriate terms, if the meta-ontology upon which those terms have been built isdifferent of the meta-ontology used to build theyours, you should check the existence of translatorsto transform definitions into your target language.

Sometimes it might occur that a term in yourconceptualization (e.g., centimeter), that should be includedin a given ontology (e.g., Standard Units in Ontolingua) not provided by the ontology server. In this case, youshould justify the need to include the missed definitions aswell as the benefits of such inclusion to the ontolc, gymaintainer.

As a result of this activity, METHONTOLOGYproposes the development of an integration document,summarizing: the meta-ontology you will use and, for eachand every term whose definition is going to be used: thename of the term in the conceptual model, the name of theontology from which you will take its definition, the nameof the definition and its arguments in the ontology, asshown in figure 6.

Figure 6. An example of an integration document

4.5. ImplementationOntologies implementation requires the use of anenvironment that supports the meta-ontology andontoiogies selected at the integration phase. The result ofthis phase is the ontology codified in a formal languagesuch us: CLASSIC, BACK, LOOM, Ontolingua, Prolog,C++ or in your favorite language.

Any ontology development environment shouldprovide, at least: a iexical and syntactic analyzer toguarantee the absence of lexical and syntactic errors;translators, to guarantee the portability of the definitionsinto other target languages; an editor, to add, remove ormodify definitions; a browser, to inspect the library of

38

ontologies and their definitions; a searcher, to look for themost appropriate definitions; evaluators, to detectincompleteness, inconsistencies and redundant knowledge:an automatic maintainer, to manage the inclusion, removalor modification of existing definitions, and so on.

4.6. EvaluationA framework for evaluating knowledge sharing technology(software, ontologies and documentation) has beenpresented by G6mez P&ez and colleagues in (G6mez-Ptrez,Juristo, & Pazos 1995). Evaluation means to carry out atechnical judgment of the ontologies, their softwareenvironment and documentation with respect to a frame ofreference (in our case the requirements specificationdocument) during each phase and between phases of theirlife cycle. Evaluation subsumes the terms Verification andValidation. Verification refers to the technical process thatguarantees the correctness of an ontology, its associatedsoftware environments, and documentation with respect to aframe of reference during each phase and between phases oftheir life cycle. Validation guarantees that the ontologies,the software environment and documentation correspond tothe system that they are supposed to represent. Based on theexperience of verifying Ontolingua ontologies, a set ofguidelines and how to look for incompleteness,inconsistencies and redundancies have been presented in(Gtmez-Ptrez 1997).

The output proposed by METHONTOLOGY for thisactivity is many evaluation document in which theontologist will describe how the ontology has beenevaluated, the techniques used, the kind of errors found ineach activity, and the sources of knowledge used in theevaluation.

4.7. DocumentationThere are not consensuated guidelines on how to documentontologies. In many cases, the only documentationavailable is in the code of the ontology, the naturallanguage text attached to formal definitions, and paperspublished in conference proceedings and journals settingsout important questions of the ontology already build. Thisproblem is the result of a vicious circle: almost anyonedocuments ontologies due to there are no guidelines toperform it, there are no guidelines to document ontologiesbecause of the absence of methodologies to buildontoiogies, and there are no standard methodologies to buildontologies due to ontologist do not write, during the wholeontology development process, the steps they follow tobuild ontoiogies.

METHONTOLOGY pretends to break this circleincluding the documentation as an activity to be doneduring the whole ontology development process. In fact,after the specification phase, you get a requirementsspecification document; after the knowledge acquisitionphase, a knowledge acquisition document; after theconceptualization, a conceptual model document that

includes a set of intermediate representations that describethe application domain; after the formalization, aformalization document; after the integration, an integrationdocument; after the implementation, the implementationdocument; and during the evaluation, an evaluationdocument.

5. ConclusionIn this paper we have reduced the existing gap betweenontological art and ontological engineering by:i. Identifying a set of activities to be done during the

ontology development process. They are: planify,specify, acquire knowledge, conceptualize, formalize,integrate, implement, evaluate, document, andmaintain.

2. Proposing the evolving prototype as the life cyclethat better fits with the ontology life cycle. The lifeof an ontology moves on through the followingstates: specification, conceptualization,formalization, integration, implementation, andmaintenance. The evolving prototype life cycleallows the ontologist to go back from any state toother if some definition is missed or wrong. So, thislife cycle permits the inclusion, removal ormodification of definitions anytime of the ontologylife cycle. Knowledge acquisition, documentationand evaluation are support activities that are carriedout during the majority of these states.

3. Defining METHONTOLOGY, a well structuredmethodology to build ontologies from scratch. Themethodologies includes a set of activities, techniquesto carry out each one, and deliverables to be producedafter the execution of such activities using itsattached techniques. METHONTOLOGY highlyrecommend the reuse of existing ontologies

ReferencesAlonso, F.; Juristo, N.; Mat6, J.L.; Pazos, J. SoftwareEngineering and Knowledge Engineering: Towards aCommon Life-Cycle. Journal of Systems andSoftware. N* 33. 1996. Pags 65-79.Farquhar, A. Fikes, R.; Pratt, W.; Rice, J. CollaborativeOntology Construction for Information Integration. KSL-95-63. Technical Report Knowledge Systems Laboratory.Stanford University. Ca. August 1995.Gangemi, A.; Steve, G.; Giacomelli, F; ONIONS: anontological methodology for taxonomic knowledgeintegration. Working notes of the workshopOntological Engineering. ECAI96. Pags. 29-40.G6mez-P6rez, A.; Juristo, N.; Pazos, J. Evaluation andAssessment of Knowledge Sharing Technology. Towards

39

Very Large Knowledge Bases. Ed. by N. Mars. IOSPress. Amsterdam. 1995. Pags. 289-296.G6mez-P6rez, A.; Ferndndez, M; De Vicente, A.; Towardsa Method to Conceptualize Domain Ontologies. Workingnotes of the wokshop Ontological Engineering,ECAI96, Pags. 41-52.G6mez-P~rez, A. A framework to Verify KnowledgeSharing Technology. Expert Systems withApplication. To be publishedMcCracken; M. A. Jackson. Life Cycle ConceptConsidered Harmful. ACM Software Engineeringnotes. April 1982. Pags 29-32.Royce W. M. Managing the Development of LargeSoftware Systems. Proc. 9th InternationalConference Software Engineering. IEEE.Computer Society. 1987. Pags. 328-338Speel, H.; Raalte, F; Vet, P.; Mars, N. Scalability of thePerformance of Knowledge Represenation Systems.Towards Very Large Knowledge Bases. Ed. by N.Mars. IOS Press. Amsterdam. 1995. Pags. 173-184.

Uschold, M., Gruninger, M. ONTOLOGIES: Principles,Methods and Applications. Knowledge EngineeringReview. Vol. II; N. 2; June 1996.

Vet, P.; Sped, P.; Mars, N. Ontologies for Very LargeKnowledge Bases in Material Science: a Case Study.Towards Very Large Knowledge Bases. Ed. by N.Mars. IOS Press. Amsterdam. 1995. Pags. 73-83.

Vicente, A; Concepualizacion de verbos enontologlas de domlnlo. T~sis de Master en Ingenierfadel Conocimiento. Facultad de Informatica. UniversidadPolit6cnica de Madrid. 1997. To be published.

4O