Overview Of Methodologies For Building Ontologies Fernández López, M. Laboratorio de Inteligencia Artificial Facultad de Informática Universidad Politécnica de Madrid Campus de Montegancedo sn. Boadilla del Monte, 28660. Madrid, Spain. Tel: (34-91) 336-74-39, Fax: (34-91) 336-7412 Email: {mfernand}@delicias.dia.fi.upm.es does not. Software Engineering, for example, can be said to have reached adulthood, because it has widely accepted methodologies; indeed, although different development methodologies are used in the United Abstract Kingdom and Spain -SSADM [Dow98] and Métrica 2 [MAP90] respectively-, both adopt the same principles A few research groups are now proposing a and viewpoints and provide similar activities and series of steps and methodologies for techniques. At the Knowledge Engineering field, also developing ontologies. However, mainly due to exist methodologies: Common Kads [Wie92], the fact that Ontological Engineering is still a Waterman’s methodology [Wat86], IDEAL [Góm97], relatively immature discipline, each work etc. With regard to Ontological Engineering, we believe group employs its own methodology. Our goal that it is important to know both the state of the art of is to present the most representative methodologies for ontology development and what methodologies used in ontology development problems need to be solved before the methodologies and to perform an analysis of such can be considered mature and can be applied with methodologies against the same framework of satisfactory prospects of success. We, therefore, reference. So, the goal of this paper is not to consider that there is a need to diagnose the state of the provide new insights about methodologies, but art of methodologies for ontology development, and we to put it all in one place and help people to will present and analyse the best known methodologies select which methodology to use. today against the IEEE Standard for Developing Software Life Cycle Processes, 1074-1995 [IEE96]. 1 Introduction Our study will be structured as follows: One important difference between a technical field that • Section 2. IEEE Standard 1074-1995. The standard is in its "infancy" and another that has reached document will be briefly described and we will "adulthood" is that the mature field has widely accepted discuss to what extent any ontology development methodologies, while the emerging discipline usually methodology should comply with the provisions of this document. The copyright of this paper belongs to the papers authors. Permission • Section 3. Brief history of methodologies. We will to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial discuss, chronologically, how a series of advantage. methodologies have evolved from 1995 to the present day. Proceedings of the IJCAI-99 workshop on Ontologies and Problem-Solving Methods (KRR5) Stockholm, Sweden, August 2, 1999 • Section 4. Criteria for analysing methodologies. We will describe the generic characteristics that will (V.R. Benjamins, B. Chandrasekaran, A. Gomez-Perez, N. Guarino, be taken as a reference point for conducting the M. comparative study of the methodologies. Uschold, eds.) http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-18/ • Sections 5 to 9. Analysis of each methodology. We will examine the above methodologies by means of: a discussion of each methodology, an analysis of Mariano Fernández López 4-1 each methodology according to the criteria − Design process: its goal is to develop a established in section 4 and a summary. The coherent and well-organized representation methodologies to be studied will be Uschold's of the software system that meets the methodology [Usc95], [Usc96], [UsG96], requirements specification. Grüninger’s methodology [Grü95], [Usc96], [UsG96], the proposal by Bernaras et al. [Ber96], − Implementation process: Transforms the METHONTOLOGY [Góm96], [Fer97], [Góm98], design representation of a software product [Fer99] and the methodology used in SENSUS into a programming language realization. [Swa97]. 3.3. Post-development processes: are related to • Section 10. Conclusions: summary of the the installation, operation, support, methodology analysis. A series of general maintenance and retirement of a software conclusions will be drawn from the analysis. product. They are performed after software construction. 2 IEEE Standard 1074-1995 4. Integral processes: are needed to successfully complete software project activities. They ensure the 2.1 Description completion and quality of project functions. They are carried out at the same time as software The IEEE 1074-1995 standard [IEE96] describes the development-oriented processes and include software development process, the activities to be activities that do not output software, but are carried out, and the techniques that can be used for absolutely necessary to obtain a successful system. developing software. The activities are not presented in They cover the processes of verification and time order, since the standard recommends that they be validation, software configuration management, incorporated into a software life cycle, which is selected documentation development and training. and established by the user for the project under development. The standard does not define a particular 2.2 Why and How Can the IEEE Standard Be life cycle. These activities are part of what is called the Applied To Ontology Development software process, which is further broken down into four main processes. These processes are: According to the IEEE definition [IEE90], software is “computer programs, procedures, and possibly 1. Software life cycle model process: includes the associated documentation and data pertaining to the activities of identifying and selecting a software life operation of a computer system”; ontologies are part cycle, which establishes the order in which the (sometimes only potentially) of software products. different activities involved in the process should be Therefore, ontologies should be developed according to performed. the standards proposed for software generally, which should be adapted to the special characteristics of 2. Project management processes: create the ontologies. Below, we describe to what extent the IEEE framework for the project and ensure the right level standard processes should be applied in an ontology of management throughout the entire product life development methodology: cycle. Activities related to project initiation, project monitoring and control, and software quality 1. Software life cycle model process. The management belong to this group of processes. methodology should recommend one or more life cycles from which the developer can select one. 3. Software development-oriented processes: produce, install, operate and maintain the software 2. Project management processes. The activities and retire it from use. They are divided into the proposed by the standard for these processes are groups below: applicable to any software product and it is, therefore, recommendable that they be applied in 3.1. Pre-development processes: are performed ontology development. before starting software development proper. They involve activities related to studying the 3. Software development-oriented processes. environment in which the software is to Ordered according to process types, there are: operate and conducting feasibility studies. 3.1. Pre-development processes. Apart from 3.2. Development processes: are processes that studying the environment in which the must be performed to build the software ontology is to be installed, the possibilities of product. These processes include: integrating the ontology into other systems also have to be reviewed. The feasibility study is − Requirements process: includes iterative applicable to any software type, although it activities directed towards developing the will vary from one type to another. software requirements specification. Mariano Fernández López 4-2 3.2. Development processes. By process types, it question. can be said that: C2. Detail of the methodology. Consideration of − Requirements process. As shown in whether the activities and techniques proposed by [Góm98], ontologists are able to specify, the methodology are exactly specified. at least partially, what is expected of the ontology. C3. Recommendations for knowledge formali- zation. Consideration of the formalism or − Design process. Ontologies also have to formalisms proposed for representing knowledge be designed, albeit differently from other (logic, frames, etc.). types of software. According to the philosophy of the standard, it is not C4. Strategy for building ontologies. Discussion of recommendable to go directly from which of the following strategies are used to requirements specification to coding. develop ontologies: a. Application-dependent: the ontology is built − Implementation process. Obviously, if on the basis of an application knowledge base, ontologies are to be used by computers, by means of a process of abstraction. they have to be implemented. b. Application-semidependent: possible sce- 3.3. Post-development processes. Are activities narios of ontology use are identified in the that are common to any type of software. specification stage. 4. Integral processes. The activities proposed by the c. Application-independent: the process is standard for these processes can be applied to any totally independent of the uses to which the type of software. This includes training, since the ontology will be put in knowledge-based personnel responsible for maintaining the systems, agents, etc. ontologies, for example, need instruction. C5. Strategy for identifying concepts. The possible 3 Brief History Of The Methodologies strategies are [UsG96]: from the most concrete to the most abstract (bottom-up), from the most On the basis of the experience gathered in developing abstract to the most concrete (top-down), or from the Enterprise Ontology [Usc95] and the TOVE the most relevant to the most abstract and most (TOronto Virtual Enterprise) project ontology [Grü95] concrete (middle-out). (both in the domain of enterprise modelling), the first methodological outlines were proposed in 1995 and C6. Recommended life cycle. Analysis of whether the later refined in [Usc96] and [UsG96]. At the 12th methodology implicitly or explicitly proposes a European Conference for Artificial Intelligence life cycle. (ECAI’96) held in 1996, Bernaras et al. [Ber96] C7. Differences between the methodology and IEEE presented a method used to build an ontology in the 1074-1995. Discussion of which of the processes domain of electrical networks as part of the Esprit and activities proposed by the IEEE standard KACTUS project. METHONTOLOGY [Góm96] 1074-1995 are not mentioned in the methodology. appeared at the same time and was extended in later papers [Fer97], [Góm98], [Fer99]. In 1997, that is, one C8. Recommended techniques. Specification of year later, a methodology was proposed for building whether particular techniques are proposed for ontologies based on the SENSUS ontology [Swa97]. performing the different activities of which the methodology is composed. The methodology proposed by Uschold will be described in section 5; Grüninger's methodology will be C9. What ontologies have been developed using the discussed in section 6, the methodology proposed by methodology and what systems have been built Bernaras et al. in section 7, METHONTOLOGY in using these ontologies. The ontologies and section 8, and finally, the SENSUS methodology in systems developed will be listed and briefly section 9. described. Criteria C1, C2, C3, C4 and C5 will show general 4 Criteria For Analysing Methodologies points of the methodologies. The other criteria will The criteria that we have established for analysing each show the maturity of each methodology. Another methodology are: interesting criterion for analysis would be collaborative and distributive construction, that is, to what extent the C1. Inheritance from Knowledge Engineering. methodologies permit different groups at different sites Consideration of the influence of traditional to work together to build ontologies; however, none of Knowledge Engineering on the methodology in the publications to date mention what each one Mariano Fernández López 4-3 contributes in this respect. 4. Documentation recommends that guidelines be established for documenting ontologies, possibly differing according to the type and purpose of the 5 Methodology By Uschold And King ontology. 5.1 Description 5.2 Ontologies Developed Using This This methodology is based on the experience of Methodology developing the Enterprise Ontology, an ontology for The most important project developed using this enterprise modelling processes [Usc95]. This methodology is the Enterprise Ontology, which is a methodology provides guidelines for developing collection of terms and definitions relevant to business ontologies, which are: enterprises. The ontology was developed under the Enterprise Project by the Artificial Intelligence Applications Institute at the University of Edinburgh 1. Identify purpose. It is important to be clear why the with its partners: IBM, Lloyd's Register, Logica UK ontology is being built and what its intended uses Limited, and Unilever. (See are. http://www.aiai.ed.ac.uk/project/enterprise/enterprise/o ntology.html) 2. Building the ontology, which is broken down into three steps: 5.3 Systems Built Using Ontologies Developed 2.1. Ontology capture, which means: With This Methodology − Identification of the key concepts and The most important tool developed using the Enterprise relationships in the domain of interest, that Ontology is the Enterprise Toolset. It uses an agent- is, scoping. It is important to centre on the based architecture to integrate off-the-shelf tools in a concepts as such, rather than the words plug-and-play style. The components of the Enterprise representing them. Toolset are: a Procedure Builder for capturing process models, an Agent Toolkit for supporting the − Production of precise unambiguous text development of agents, a Task Manager for integration, definitions for such concepts and visualization, and support for process enactment, and an relationships. Enterprise Ontology for communication. (See http://www.aiai.ed.ac.uk/project/enterprise for more − Identification of terms to refer to such information). concepts and relationships. 5.4 Analysis Of The Methodology Agreeing on all of the above. According to the criteria established in section 4, the The authors use a middle-out approach to following can be said: perform this step and recommend that rather than looking for the most general or the most C1. Inheritance from Knowledge Engineering. This particular concepts as key concepts, the most methodology recalls knowledge-based systems important concepts be identified, which will development in the sense that it clearly identifies then be used to obtain the remainder of the an acquisition, coding and evaluation stage. hierarchy by generalization and specialization. However, it proposes neither a feasibility study nor prototyping, thereby differentiating it from 2.2. Coding. Involves explicitly representing the knowledge-based systems development. knowledge acquired in step 2.1 in a formal language. C2. Detail of the methodology. Little, it does not precisely describe the techniques and activities. 2.3. Integrating existing ontologies. During either or both of the capture and coding processes, C3. Recommendations for knowledge there is the question of how and whether to use formalization. None in particular. ontologies that already exist. C4. Strategy for building applications. The process 3. Evaluation, where the authors adopt the definition is totally independent of the uses to which the of [Góm95]: “to make a technical judgement of the ontology will be put and is, therefore, application- ontologies, their associated software environment, independent and documentation with respect to a frame of reference ... The frame of reference may be C5. Strategy for identifying concepts. The key requirements specifications, competency questions, concepts are established by searching first for the and/or the real world”. most important, rather than the most general or Mariano Fernández López 4-4 most particular concepts; the others are obtained the ontology. by generalization and by specialization. Therefore, a middle-out strategy can be said to be used for Any proposal for a new ontology or extension to identifying concepts. an ontology should describe one or more motivating scenarios, and the set of intended solutions of C6. Recommended life cycle. This methodology does problems presented in the scenarios. not propose a life cycle. 2. Formulation of informal competency questions. C7. Differences between the methodology and IEEE These are based on the scenarios obtained in the 1074-1995. As shown in table 1, it does not preceding step and can be considered as mention management, pre-development and post- expressiveness requirements that are in form of development, nor does it propose a design process. questions. An ontology must be able to represent Some activities are missing in the processes it these questions using its terminology, and be able to does propose (requirements, implementation and characterize the answers to these questions using the integral processes), particularly: environment axioms and definitions. These are the informal study, feasibility study, training and configuration competency questions, since they are not yet management. expressed in the formal language of the ontology. C8. Recommended techniques. Techniques for The competency questions are stratified and the performing the different activities are not given in response to one question can be used to answer detail. For example, the methodology recommends more general questions from the same or another that the key concepts and relationships in the ontology by means of composition and domain under study be identified during decomposition operations. This is a means of acquisition; however, no details are given about identifying knowledge already represented for reuse how this should be done, and only a very vague and integrating ontologies. guideline, involving the use of brainstorming techniques, is given. The questions serve as constraints on what the ontology can be, rather than determining a particular C9. What ontologies have been developed using the design with its corresponding ontological methodology and what systems have been built commitments. There is no single ontology using these ontologies. Complex projects have associated with a set of competency questions. been developed on business domains, which have Instead, the competency questions are used to served to validate the feasibility of the evaluate the ontological commitments that have methodology. been made to see whether the ontology meets the requirements. 6 Methodology By Grüninger And Fox 3. Specification of the terminology of the ontology within a formal language. The following steps will 6.1 Description be taken: This methodology is based on the experience in 3.1. Getting informal terminology. Once the developing the TOVE project ontology [Grü95] within informal competency questions are available, the domain of business processes and activities the set of terms used can be extracted from the modelling. questions. These terms will serve as a basis for specifying the terminology in a formal Essentially, it involves building a logical model of language. the knowledge that is to be specified by means of the ontology. This model is not constructed directly. First, 3.2. Specification of formal terminology. Once an informal description is made of the specifications to informal competency questions have been be met by the ontology and then this description is posed for the proposed new or extended formalized. The steps proposed are as follows: ontology, the terminology of the ontology is specified using a formalism such as KIF 1. Capture of motivating scenarios. According to [Gen92]. These terms will allow the definitions Grüninger and Fox, the development of ontologies is motivated by scenarios that arise in the and constraints to be later (step 5) expressed by application. The motivating scenarios are story means of axioms. problems or examples which are not adequately addressed by existing ontologies. A motivating 4. Formulation of formal competency questions scenario also provides a set of intuitively possible using the terminology of the ontology. Once the solutions to the scenario problems. These solutions competency questions have been posed informally provide an informal intended semantics for the and the terminology of the ontology has been objects and relations that will later be included in defined, the competency questions are defined Mariano Fernández López 4-5 formally. The TOVE virtual enterprise provides the unified testbed used by the agents they built for the major 5. Specification of axioms and definitions for the supply chain functions: logistic, transportation, terms in the ontology within the formal language. management, etc. The axioms in the ontology specify the definitions of terms in the ontology and constraints on their The applications described in this section are still under interpretation; they are defined as first-order development. For further information, see sentences using axioms to define the terms and http://www.ie.utoronto.ca/EIL. constraints for objects in the ontology. Simply proposing a set of objects alone, or proposing a set 6.4 Analysis Of The Methodology of ground terms in first-order logic, does not constitute an ontology. Axioms must be provided to According to the criteria in section 4, the following can define the semantics, or meaning, of these terms. be said: If the proposed axioms are insufficient to C1. Inheritance from Knowledge Engineering. As is represent the formal competency questions and usual practice in knowledge-based systems characterize the solutions to the questions, then development, this methodology identifies additional objects or axioms must be added to the questions, which, in this case, the ontology must ontology until it is sufficient. This development of be capable of answering; however, there is no axioms for the ontology with respect to the clear-cut division into the stages involved in competency questions is therefore an iterative knowledge-based systems development. process. C2. Detail of the methodology. Neither the activities 6. Establish conditions for characterizing the nor the techniques are described in detail. completeness of the ontology. Once the competency questions have been formally stated, we C3. Recommendations for knowledge must define the conditions under which the solutions formalization. Clearly opts for logic. to the questions are complete. C4. Strategy for building applications. Ontology use scenarios are identified in the specification stage, 6.2 Ontologies Developed Using This so it is a application-semidependent strategy. Methodology C5. Strategy for identifying concepts. It adopts a This methodology was used to build the TOVE middle-out strategy. (Toronto Virtual Enterprise) project ontologies at the University of Toronto Enterprise Integration C6. Recommended life cycle. No life cycle model Laboratory. These ontologies constitute an integrated selection process is identified, nor is any explicit model formalized using first-order logic. The TOVE reference made to there being any preference for ontologies include: Enterprise Design Ontology, Project one model over another; however, the order in Ontology, Scheduling Ontology, or Service Ontology. which the development activities are performed is For more information, see established, and provision is also made for http://www.ie.utoronto.ca/EIL. extending an ontology that has already been built, starting again with getting scenarios. Nevertheless, 6.3 Applications Using Ontologies Developed there is no statement concerning whether or not With This Methodology the definitions it already contains can be modified when extending an ontology. Accordingly, it is The ontologies built according to this methodology impossible to ascertain whether the methodology have been used in the applications listed below: admits development by means of evolving prototypes or only an incremental life cycle. 1. Enterprise Design Workbench. It is a design environment that allows the user to explore a variety C7. Differences between the methodology and IEEE of enterprise designs. The process of exploration is 1074-1995. As shown in table 1, neither design one of design, analysis and re-design, where the nor management, pre-development and post- workbench provides a comparative analysis of development processes are proposed and, for the enterprise design alternatives, and guidance to the processes that are mentioned (requirements, designer. implementation and integral processes), no reference is made to the activities concerning: 2. Integrated Supply Chain Management Project training and configuration management. agents. The goal is to organize the supply chain as a network of cooperating, intelligent agents, each C8. Recommended techniques. There is no detailed performing one or more supply chain functions, and description of techniques, for example, the each coordinating their actions with other agents. techniques for formulating the competency Mariano Fernández López 4-6 questions are not mentioned. 7.3 Analysis Of The Methodology C9. What ontologies have been developed using the According to the criteria set out in section 4, the methodology and what systems have been built following can be said: using these ontologies. Complex projects have been developed; albeit all in the same domain. C1. Inheritance from Knowledge Engineering. This method follows in the tradition of knowledge engineering. Indeed, it considers the construction 7 The approach of Amaya Berneras et al. of ontologies at the same time as knowledge-based system development. 7.1 Description C2. Detail of the methodology. Very little. The work of Bernaras et al. is set within the Esprit KACTUS project [KAC96]. One of the objectives of C3. Recommendations for knowledge the KACTUS project is to investigate the feasibility of formalization. None. knowledge reuse in complex technical systems and the C4. Strategy for building applications. The role of ontologies to support it [Sch95]. construction of ontologies is based on the This approach to developing ontologies is construction of particular applications. As more conditioned by applications development. So, every applications are built, the ontology becomes more time an application is built, the ontology that represents general, and, therefore, moves further away from the knowledge required for the application is built. This what would be a traditional knowledge base. So, ontology can be developed by reusing others and can this methodology can be said to follow an also be integrated into the ontologies of later application-dependent strategy in this respect. applications. Therefore, every time an application is C5. Strategy for identifying concepts. Top-down. developed, the following steps are taken: C6. Recommended life cycle. It simply seems to 1. Specification of the application, which provides an assume that the life cycle should be the same as is application context and a view of the components used in the development of the application that the application tries to model. associated with the ontology. 2. Preliminary design based on relevant top-level C7. Differences between the methodology and IEEE ontological categories, where the list of terms and 1074-1995. The management, pre-development tasks developed during the previous phase is used as and post-development processes are missing. Also, input for obtaining several views of the global for the integral processes, training, documentation, model in accordance with the top-level ontological configuration management, verification and categories determined. validation are missing. This design process involves searching C8. Recommended techniques. No particular ontologies developed for other applications, which techniques are described. are refined and extended for use in the new application. C9. What ontologies have been developed using the methodology and what systems have been built 3. Ontology refinement and structuring in order to using these ontologies. The methodology has arrive at a definitive design. The principles of been used in the domain of electrical networks. minimum coupling can be used to assure that the modules are not very dependent on each other and are as coherent as possible, looking to get maximum 8 METHONTOLOGY homogeneity within each module. This methodology was developed within the Laboratory of Artificial Intelligence at the Polytechnic University 7.2 Ontologies And Applications Developed With of Madrid. The METHONTOLOGY framework This Methodology [Fer97], [Góm98], [Fer99] enables the construction of As experience based on this approach, the authors ontologies at the knowledge level and includes present the development of three ontologies as a result [Bláz98]: the identification of the ontology of the development of the same number of applications. development process, a life cycle based on evolving The purpose of the first application is to diagnose faults prototypes, and particular techniques for carrying out in an electrical network, the second concerns scheduling each activity. The METHONTOLOGY framework is service resumption after a fault in the electrical network supported by ODE [Bláz98], [Fer99]. and the third controls the electrical network on the basis of the above two applications. Mariano Fernández López 4-7 8.1 Ontology Development Process Evaluation, Integration and Configuration Management is discussed in [Roj98], where the documentation The ontology development process [Fer97] refers to outputted is discussed as part of the description of each which activities are carried out when building activity. ontologies. It is crucial to identify these activities if agreement is to be reached on ontologies that are to be 8.2 Ontology Life Cycle built by geographically distant co-operative teams with some assurance of correctness and completeness. If this It identifies the set of stages through which the ontology is the case, it is advisable to perform the three moves during its life time, describes what activities are categories of activities presented below and steer clear to be performed in each stage and how the stages are of anarchic constructions. related (relation of precedence, return, etc.). In [Fer97], a justification is given of why the ontology life cycle Project Management Activities include planning, should be based on evolving prototypes. control and quality assurance. Planning, identifies which tasks are to be performed, how they will be arranged, how much time and what resources are 8.3 Ontologies Developed With This Methodology needed for their completion. This activity is essential for ontologies that need to use ontologies which have The most important ontologies built according to already been built or ontologies that require levels of METHONTOLOGY are: abstraction and generality. Control, guarantees that 1. CHEMICALS [Fer96], [Góm96], [Fer99], which planned tasks are completed in the manner that they contains knowledge within the domain of chemical were intended to be performed. Finally, Quality elements and crystalline structures. Assurance, assures that the quality of each and every product outputted (ontology, software and 2. Environmental pollutants ontologies [Roj98] documentation) is satisfactory. [Roj98] describes how [GóR99]. They represent the methods of detecting these activities are performed. the different pollutant components of various media: water, air, soil, etc., and the maximum permitted Development-Oriented Activities include concentrations of these components, taking into specification, conceptualization, formalization and account all the legislation in force (European Union, implementation. Specification states why the ontology Spanish, German, US regulations, etc.). is being built and what are its intended uses and who are the end-users. Conceptualization structures the 3. The Reference-Ontology [Arp98], an ontology in domain knowledge as meaningful models at the the domain of ontologies that plays the role of a knowledge level. Formalization transforms the kind of yellow pages of ontologies. It gathers, conceptual model into a formal or semi-computable describes and has links to existing ontologies, using model. Implementation builds computable models in a a common logical organization. computational language. Finally, Maintenance updates and corrects the ontology. [Fer99] gives details of how 4. The restructured version of the (KA)2 ontology all the development activities, except Formalization and [Bláz98], which contains knowledge about the Maintenance, are performed. scientific community in the field of Knowledge Acquisition, particularly: scientists, research topics, Support Activities include a series of activities, projects, universities, etc. performed at the same time as development-oriented activities, without which the ontology could not be This methodology has been proposed for ontology built. They include knowledge acquisition, evaluation, construction by the Foundation for Intelligent Physical integration, documentation and configuration Agents (FIPA), which promotes inter-operability across management. Knowledge Acquisition acquires agent-based applications (http://www.fipa.org). knowledge of a given domain. Evaluation makes a technical judgment of the ontologies, their associated 8.4 Applications Using Ontologies Developed software environments and documentation with respect With This Methodology to a frame of reference during each phase and between phases of their life cycle [Góm95]. Integration of The most important applications are shown below: ontologies is required when building a new ontology reusing other ontologies that are already available. 1. (Onto)2Agent [Arp98]. An ontology-based WWW Documentation details, clearly and exhaustively, each broker about ontologies that uses the Reference- and every one of the phases completed and products Ontology as a source of its knowledge and retrieves generated. Configuration Management records all the descriptions of ontologies that satisfy a given set of versions of the documentation, software and ontology constraints. It is available at code to control the changes. In [Fer99], [GóR99], a (http://delicias.dia.fi.upm.es/ OntoAgent). description is given of how Knowledge Acquisition was performed in the CHEMICALS ontology, and 2. Chemical OntoAgent [Arp98]. An ontology-based WWW Chemistry teaching broker that allows Mariano Fernández López 4-8 students to learn chemistry and to test their skills on 9 SENSUS-Based Methodology this domain. It uses CHEMICALS as a source of its knowledge. 9.1 The SENSUS Ontology 3. Ontogeneration [Agu98]. It is a system that uses a This is an ontology for use in natural language domain ontology (CHEMICALS) and a linguistic processing and was developed at the ISI (Information ontology (GUM [Bat95]) to generate Spanish text Sciences Institute) natural language group to provide a descriptions in response to the queries of students in broad-based conceptual structure for developing the domain of chemistry. machine translators [Kni94] [Kni95]. Its current content was obtained by extracting and merging information 8.5 Analysis Of The Methodology from various electronic sources of knowledge. This process began by merging the PENMAN Upper Model According to the criteria set out in section 4, the [Bat89] and ONTOS (two, very high level following can be said: linguistically-based ontologies) and the semantic C1. Inheritance from Knowledge Engineering. It categories from a dictionary by hand to produce an has its roots in a methodology for developing ontology base. WordNet was then merged (again by Knowledge-Based Systems (IDEAL [Góm97]). hand) with the ontology base. A merging tool was then used to merge WordNet with an English dictionary. C2. Detail of the methodology. A sizable part of the After, to support machine translation, the result of this methodology is very detailed; the remainder will merge was then augmented by Spanish and Japanese be specified in more detail in the future. lexical entries from the Collins Spanish/English dictionary and the Kenkyusha Japanese/English C3. Recommendations for knowledge dictionary [Swa97]. formalization. METHONTOLOGY gives freedom of choice with regard to formalization. If SENSUS has more than 50,000 concepts organized the ODE tool is used it is not even necessary, in a hierarchy, according to their level of abstraction. It because ODE generates target codes from the includes terms with both a high and a medium level of ontology definition at the knowledge level. abstraction, but, generally speaking, does not cover terms from specific domains. The domain terms are C4. Strategy for building applications. Application- linked with SENSUS in order to build ontologies for independent. particular domains, and any irrelevant terms are pruned in SENSUS. C5. Strategy for identifying concepts. The most relevant concepts are identified first, so it adopts a middle-out strategy. 9.2 The Methodology According To The SENSUS Approach C6. Recommended life cycle. Evolving prototypes. When an ontology is to be built in a particular domain, C7. Differences between the methodology and IEEE the following steps are taken [Swa97]: 1074-1995. The process groups that are missing are: software life cycle model process, although an 1. A series of terms are taken as seed. evolving prototype-based life cycle is proposed for 2. These seed terms are linked by hand to SENSUS. any ontology developed, and pre-development processes. For the other processes (project 3. All the concepts in the path from the seed terms to management processes, development-oriented the root of SENSUS are included. processes and integral processes), the following proposals are missing: project initiation, 4. Terms that could be relevant within the domain and installation, support, retirement and training. have not yet appeared are added. The similarity between METHONTOLOGY and 5. Finally, for those nodes that have a large number of the IEEE standard is due to the fact that the paths through them, the entire subtree under the skeleton of METHONTOLOGY was developed node is sometimes added, based on the idea that if taking this document as a starting point. many of the nodes in a subtree have been found to be relevant, then the other nodes in the subtree are C8. Recommended techniques. Techniques for the likely to be relevant as well. This step is done Control activity remain to be specified. manually, since it seems to require some understanding of the domain to make the decision. C9. What ontologies have been developed using the Obviously, very high level nodes in the ontology methodology and what systems have been built will always have many paths through them, but it is using these ontologies. It has been used to hardly ever appropriate to include the entire subtrees develop ontologies and applications in different under these nodes. domains. Mariano Fernández López 4-9 9.3 Ontologies Developed Using This methodology and what systems have been built Methodology using these ontologies. Both the ontologies and the applications centre on the military campaigns An ontology for military air campaign planning has domain. been built using SENSUS. It contains an overview of the basic elements that characterize air campaign plans, such as campaign, scenario, participants, commanders, 10 Conclusions: Summary Of The etc. [Val99]. This ontology includes ontologies on Analysis Of Methodologies weapons, systems in general, fuel, etc. According to the above analysis, recapitulated in table 2, we arrived at the following conclusions: 9.4 Applications Using Ontologies Developed With This Methodology 1. None of the methodologies are fully mature if we compare them with the IEEE standard; although On the basis of SENSUS, knowledge-based the following scale can be established: applications for the air campaign planning domain have been developed at ISI in conjunction first with the i. METHONTOLOGY is the most mature; ARPA Rome Planning Institute program and later with however, recommendations for the pre- the DARPA Joint Forces Air Component Commander development processes are needed, and some program. These include the Strategy Development activities and techniques should be specified in Assistant [Val99], a tool that provides support for more detail. Additionally, it is recommended by intelligent and guided plan development. the FIPA. 9.5 Analysis Of The Methodology ii. Grüninger and Fox’s methodology, which includes neither the processes described in The following can be said: section 4, nor activities and techniques for performing such activities. Neither is the life C1. Inheritance from Knowledge Engineering. It cycle specified. Furthermore, although completely breaks with the tradition, as it is based ontologies have been developed with this on adding terms to an existing ontology methodology, and there are also applications that (SENSUS), which is then pruned. use these ontologies, the domain is confined to business. C2. Detail of the methodology. It is not very detailed. iii. Uschold and King’s methodology has the same C3. Recommendations for knowledge omissions as the above methodology and is less formalization. Semantic networks. detailed. C4. Strategy for building applications. Application- iv. SENSUS-based methodology, which, apart from semidependent, as the seed terms are obtained the shortcomings of the above methodologies, with an application in mind. does not mention the life cycle. C5. Strategy for identifying concepts. It is bottom- v. Bernaras et al.’s methodology, which, apart from up, as first the most specific concepts required for the above omissions, has not been used to build the application are sought and, then, the search- many ontologies and applications. and-prune method is applied to enter more abstract concepts. 2. The proposals are not unified. At present each group applies its own methodology. This is C6. Recommended life cycle. No preference for a exacerbated by the fact that none have reached particular model is stated, since nothing is said maturity. Therefore, efforts are required along the about how to develop versions other than the first. lines of unifying methodologies to arrive at a situation resembling Knowledge and Software C7. Differences between the methodology and IEEE Engineering. 1074-1995. The design process and the management, pre-development and post- A preliminary attempt to unify two development processes are missing. For the methodologies was described in [Usc96], cited in integral processes, the activities related to training, section 3. Its disadvantage was that the new documentation, configuration management, synthesized methodology was not an actual verification and validation are missing. methodology, it was a conception of a potential methodology. C8. Recommended techniques. No particular techniques are detailed. 3. There is one aproach that is completely different from the others: SENSUS. This may mean that the C9. What ontologies have been developed using the best we can do is to have several widely accepted Mariano Fernández López 4-10 methodologies rather than just one standarized [Bern96] Bernaras, A.; Laresgoiti, I.; Corera, J. methodology. Building and Reusing Ontologies for Electrical Network Applications 4. It is allowed interoperatibilty between systems. Proceedings of the European Conference on Domain ontologies built using SENSUS approach Artificial Intelligence (ECAI’96). ECAI 96. share the same high level concepts (or skeleton). So, 1996. systems that use such ontologies will share a common structure of the world, and it would be [Bláz98] Blázquez, M.; Fernández-López, M.; García- aesier for them to communicate because the share Pinar, J.M.; Gómez-Pérez, A. Building the same underlying structure. Ontologies at the Knowledge Level using the Ontology Design Environment. 5. There is a starting point for solving the above Knowledge Acquisition of Knowledge-Based problems. We have a series of methodologies that Systems Workshop (KAW). 1998. can be used as a reference point for developing one or several standardized methodologies adaptable to [Dow98] Downs, E.; Clare, P.; Coe, I. Structured different ontology types in different settings. In this Analysis and Design Method (SSADM). respect, this paper may be useful as preliminary Prentice Hall. 1998. guide for ascertaining what are the shortcoming of existing methodologies that should be overcome by [Fer99] Fernández-López, M.; Gómez-Pérez, A.; futur methodologies. Additionally, as in the case of Pazos-Sierra, A.; Pazos-Sierra, J. Building a methodology, existing standards for traditional Chemical Ontology Using Methontology software development can be used as guidelines. and the Ontology Design Environment. IEEE Intelligent Systems & their Acknowledgements applications. January/February 1999. PP. 37- 46. I would like to thank Asunción Gómez Pérez for her help on this paper. [Fern97] Fernández, M.; Gómez-Pérez, A.; Juristo, N. METHONTOLOGY: From Ontological References Art Towards Ontological Engineering. Symposium on Ontological Engineering of [Agu98] Aguado, G.; Bañón, A.; Bateman, J.; AAAI. Stanford (California). March 1997. Bernardos, S.; Fernández, M.; Gómez-Pérez, A. Nieto, E.; Olalla, A.; Plaza, R.; Sáchez, A. [Fer96] Fernández, M. CHEMICALS: ontología de ONTOGENERATION: Reusing domain elementos químicos. Final-Year Project. and linguistic ontologies for Spanish text Facultad de Informática de la Universidad generation. Workshop on Applications of Politécnica de Madrid. 1996. Ontologies and Problem-Solving Methods. European Conference on Artificial [GóR99] Gómez-Pérez, A; Rojas, M. D. Ontological Intelligence (ECAI’98). Brighton (United Reengineering and Reuse. European Kingdom). 1998. Knowledge Acquisition Workshop (EKAW). 1999. [Arp98] Arpírez, J. C.; Gómez-Pérez, A.; Lozano, A. Pinto, H. S. Reference Ontology and [Góm98] Gómez Pérez, A. Knowledge Sharing and (ONTO)2Agent: The ontology yellow Reuse. In J. Liebowitz (Editor) Handbook of pages. Workshop on Applications of Expert Systems. CRC. 1998. Ontologies and Problem-Solving Methods. [Góm97] Gómez-Pérez, A.; Juristo, N.; Montes, C.; European Conference on Artificial Pazos, J. Ingeniería del Conocimiento. Intelligence (ECAI’98). Brighton (United Kingdom). 1998. Ceura 1997. [Bat95] Bateman, J.; Magnini, B.; Fabris, B. The [Góm96] Gómez-Pérez, A. A Framework to Verify Knowledge Sharing Technology. Expert Generalized Upper Model Knowledge Systems with Application. Vol. 11, No. 4. pp. Base: Organization and Use. In N. Mars 519-529. 1996. (Editor). Towards Very Large Knowledge Bases. IOS Press. 1995. pp. 60-72. [Góm95] Gómez-Pérez, A.; Juristo, N.; Pazos, J. [Bat89] Bateman, J. A.; Kasper, R. T.; Moore, J. D.; Evaluation and assessment of knowledge Whitney, R. A. A General Organization of sharing technology. In N. J. Mars (editor), Towards Very Large Knowledge Bases. Knowledge for Natural Language KBKS 95. IOS Press, Amsterdam, 1995. pp., Processing: The Penman Upper Model. 289-296. USC/Information Sciences Institute. Marina del Rey. 1989. [Grün94] Grüninger, M.; Fox, M. S. The Role of Mariano Fernández López 4-11 Competency Questions in Enterprise [Usc95] Uschold, M. King, M. Towards a Engineering. IFIP WG 5.7 Workshop on Methodology for Building Ontologies. Benchmarking. Theory and Practice. Workshop on Basic Ontological Issues in Trondheim, Norway. 1994. Knowledge Sharing. 1995. [Gen92] Genesereth, M. R.; Fikes, R. E. Knowledge [UsG96] Uschold, M.; Grüninger, M. Ontologies: Interchange Format. Version 3.0. Principles Methods and Applications. Reference Manual. Computer Science Knowledge Sharing and Review. Vol. 2. Department. Stanford University. Stanford, 1996. California. 1992. [Val99] Valente, A.; Russ, T.; McGregor, R.; [IEE96] IEEE Standard for Developing Software Swartout, W. Building and (Re)Using an Life Cycle Processes. IEEE Computer Ontology of Air Campaign Planning. IEEE Society. New York (USA). April 26, 1996. Intelligent Systems & their applications. January/February 1999. [IEE90] IEEE Standard Glossary of Software Engineering Terminology. IEEE Computer [Wat86] Waterman, D. A. A Guide to Expert Society. New York (USA). 1990. Systems. Addison-Wesley. Masachusets (USA). 1986. [KAC96] The KACTUS Booklet version 1.0. Esprit Project 8145. September, 1996. [Wie92] Wielinga, B. J.; Schreiber, A. T.; Breuker, J. (http://www.swi.psy.uva.nl/prjects/ A. KADS: a modeling approach to NewKACTUS/Reports.html) knowledge engineering. Knowledge Acquisition (4). PP. 5-53. 1992. [Kni95] Knight, K.; Chancer, I.; Haines, M.; Hatzivassiloglou. V.; Hovy, E. H.; Iida M.; Luk, S.K.; Whitney, R.A.; Yamada, K. Filling Knowledge Gaps in a Broad- Coverage MT System. Proceedings of the 14th IJCAI Conference. Montreal (Canada). 1995. [Kni94] Knight, K.; Luck S. Building an Large Knowledge Base for Machine Translation. Proceedings of the American Association of Artificial Intelligence Conference (AAAI- 94). Seattle (USA). 1994. [MAP90] Metodología de Planificación y Desarrollo de Sistemas de Información. Métrica versión 2. Ministerio para las Administraciones Públicas (MAP). 1990. [Roj98] Rojas, M. D. Ontologías de iones monoatómicos en variables físicos del medio ambiente. Final-Year Project. Facultad de Informática de la Universidad Politécnica de Madrid. 1998. [Sch95] Schreiber, G.; Wielinga, B.; Jansweijer W. The KACTUS View on the ‘O’ World. In Proceedings of the National Dutch AI Conference. NAIC’95. 1995. [Swa97] Swartout, B.; Ramesh P.; Knight, K.; Russ, T. Toward Distributed Use of Large-Scale Ontologies. Symposium on Ontological Engineering of AAAI. Stanford (California). Mars, 1997. [Usc96] Uschold, M. Building Ontologies: Towards A Unified Methodology. Expert Systems 96. Cambridge. 1996. Mariano Fernández López 4-12 Table 1. Methodology Compliance With IEEE 1074-1995 Project management Project development-oriented processes Integral processes processes Pre-development Development process Post-development processes Processes Requirements Design process Implementation process process Uschold and King Not proposed Not proposed Proposed Not proposed Proposed Not proposed Activities not identified for: training, environment study, and configuration management Grüninger and Fox Not proposed Not proposed Proposed Proposed Proposed Not proposed Activities not identified for: training, environment study, and configuration management Bernaras Not proposed Not proposed Proposed Proposed Proposed Not proposed Not proposed METHONTOLOGY Establish project Not proposed Proposed Proposed Proposed Activities not identified for: Activities not identified for training and environment activity is not installation, operation, support, environment study. identified retirement, and training SENSUS Not proposed Not proposed Proposed Not proposed Proposed Not proposed Not proposed Table 2. Summary of methodologies Inheritance Detail of the Recommendations Strategy for building Strategy for Recommend Differences from Recommended Ontologies Collaborative from methodology for formalization applications identifying ed life cycle IEEE 1074-1995 techniques and and Knowledge concepts applications distributive Engineering construction Uschold y King Partial Very little None in particular Application-independent Middle-out None - Processes missing Not known One domain Not - Activities missing only documented Grüninger y Fox Small Little Logic Application- Middle-out To be detailed - Processes missing Not known One domain Not semidependent - Activities missing only documented Bernaras Big Very little None Application-dependent Top-down None - Processes missing Not known One domain Not - Activities missing only documented METHONTOLOGY Big A lot None Application-independent Middle-out Evolving -Pre-development Some activities Several Not prototypes process missing missing domains documented - Activities missing SENSUS None Medium Semantic networks Application- Not specified To be detailed - Processes missing Not known Several Not semidependent - Activities missing domains documented Mariano Fernández López 4-13