A Tool-supported Methodology for Ontology-based Knowledge Management

Transcription

1 A Tool-supported Methodology for Ontology-based Knowledge Management York Sure Institute AIFB, University of Karlsruhe, D Karlsruhe, Germany tel , fax Abstract. A methodology for introducing an ontology-based KM solution into enterprises is described which extends and improves the CommonKADS methodology by introducing among others specific guidelines for developing and maintaining the respective ontology. Special emphasis is put on a stepwise construction and evaluation of the ontology. The methodology is supported by a tool, OntoKick, that supports ontology engineers in early stages, i.e. the kickoff phase of ontology development. Keywords. Knowledge Management, Methodology, Ontology 1 Introduction Knowledge Management (KM) has become an important success factor for enterprises in virtually all areas during the last decade to name but a few, one might think of human resource management, enterprise organization and enterprise culture. Information technology (IT) plays a crucial role in knowledge management, e.g. by operationalizing knowledge management processes in daily life. IT-supported KM solutions are built around some kind of organizational memory [6] that integrates informal, semi-formal and formal knowledge in order to facilitate its access, sharing and reuse by members of the organization(s) for solving their individual or collective tasks [3]. In such a context, knowledge has to be modeled, appropriately structured and interlinked for supporting its flexible integration and its personalized presentation to the consumer. Ontologies have shown to be the right answer to these structuring and modeling problems by providing a formal conceptualization of a particular domain that is shared by a group of people in an organization [9]. Ontologies aim at capturing domain knowledge in a generic way and provide a commonly agreed understanding of a domain, which may be reused and shared across applications and groups. Ontologies typically consist of definitions of concepts, relations and axioms. Until a few years ago the building of ontologies was done in a rather ad hoc fashion. Meanwhile there have been some few, but seminal proposals for guiding the ontology development process (cf. Section 4). One of the most prominent methodologies is CommonKADS that puts emphasis on an early feasibility study as well as on constructing several models that capture different kinds of knowledge needed for realizing a KM solution [10]. In this paper we first describe a methodology for introducing an ontology-based KM solution into enterprises which extends and improves the CommonKADS methodology by introducing among others specific guidelines for developing and maintaining the respective ontology. Special emphasis is put on a stepwise construction and evaluation of the ontology. Second, we present a tool ( OntoKick ) that supports ontology engineers in early stages of the methodology, i.e. the kickoff phase of ontology development. Before we conclude we present related work in that particular research area. 2 Methodology for Ontology-based Knowledge Management In contrast to well-known methodologies for ontology development (cf. Section 4), which mostly restrict their attention within the ontology itself, our approach focuses on the application-driven development of ontologies during the introduction of ontology based knowledge management systems. We cover aspects from the early stages of setting up a knowl-

2 edge management project to the final roll out of the ontology-based knowledge management system. The steps of our methodology are sketched in Figure 1, we will now describe each step in detail. Feasibility study. Any knowledge management system may only function satisfactorily if it is properly integrated into the organization in which it is operational. Many factors other than technology determine success or failure of such a system. To analyze these factors, one must initially perform a feasibility study to first identify problem/opportunity areas and potential solutions, and second, to put them into a wider organizational perspective. The feasibility study serves as a decision support for economical and technical project feasibility, in order to select the most promising focus area, i.e. the domain for the ontology based system to be developed. We rely on the approach for carrying out a feasibility study that is described by the CommonKADS methodology [10]. It should be carried out before actually developing ontologies and serves as a basis for the kickoff phase. Besides the domain of the system it helps to identify the people involved in setting up and using the system, viz. the domain experts, users and supporters of a system). Kickoff phase. The first step to engineer ontologies is to capture requirements in an ontology requirements specification document ( ORSD ) describing what an ontology should support and sketching the planned area of the ontology application. It should guide an ontology engineer to decide about inclusion, exclusion and the hierarchical structure of concepts in the ontology. In this early stage one should look for already developed and potentially reusable ontologies. In summary, it should clearly describe the information shown in Table 1. ORSD1. Domain and goal of the ontology ORSD2. Design guidelines to ensure a consistent development (e.g. naming conventions) ORSD3. Available knowledge sources (e.g. domain experts, reusable ontologies, organization charts, business plans, dictionaries, index lists, dbschemas etc.) ORSD4. Potential users and use cases ORSD5. Applications supported by the ontology Table 1 Content of the ORSD Through analysis of the available knowledge sources a baseline ontology is gathered, i.e. a draft version containing few but seminal elements of an ontology. Typically the most important concepts and relations are identified. A very important knowledge source (also for the later phases) are domain experts. There exist several possibilities to capture knowledge from domain experts, we focus on the usage of informal competency questionnaires as proposed by [14]. They consist of possible queries ( competency questions ) to the system, indicating the scope and content of the ontology. In Section 3 we will present a more detailed view on competency questionnaires and how we provide tool support based on their analysis. Refinement phase. The goal of the refinement phase is to produce a mature and application-oriented target ontology according to the specification given by the kickoff phase. This phase is divided into different subphases shown in Table 2. R1. A knowledge elicitation process with domain experts based on the initial input from the kickoff phase. This serves as input for further expansion and refinement of the baseline ontology. Typically axioms are identified and modeled in this phase. This is closely linked to the next step, because the effects of axioms might depend on the selection of the representation language. R2. A formalization phase to transfer the ontology into the target ontology expressed in formal representation languages like DAML+OIL [2]. The representation language is chosen according to the specific requirements of the envisaged application. Table 2 Two subphases of the refinement phase This phase is closely linked to the evaluation phase. If the analysis of the ontology in the evaluation phase shows gaps or misconceptions, the ontology engineer takes these results as an input for the refinement phase. It might be necessary to perform several iterative steps. Evaluation phase. The evaluation phase serves as a proof for the usefulness of developed ontologies and their associated software environment. In a first step, the ontology engineer checks, whether the target ontology fulfills the ontology requirements specification document and whether the ontology supports or answers the competency questions analyzed in the kickoff phase of the project. In a second step, the ontology is tested in the target application environment. Feedback from beta users may be a valuable input for further refinement of the ontology. A valuable input may be as well the usage patterns of the ontology. The prototype system has to track the ways users navigate or search for concepts and rela-

3 Baseline ontology Target ontology O~ based Application ONTOLOGY Feasibility study Ontology Kickoff Refinement Evaluation Maintenance GO / No GO decision Focus domain for ontology Identify people involved Requirement specification Analyze knowledge sources Knowledge elicitation with domain experts Formalize Check requirements Test in target application Analyze usage patterns Manage organizational maintenance process (Who is responsible? How is it done?) Figure 1 Steps of the methodology tions. With such an ontology log file analysis we may trace what areas of the ontology are often used and others which were not navigated. This phase is closely linked to the refinement phase and an ontology engineer may need to perform several cycles until the target ontology reaches the envisaged level the roll out of the target ontology finishes the evaluation phase. Maintenance phase. In the real world things are changing and so do the specifications for ontologies. To reflect these changes ontologies have to be maintained frequently like other parts of software, too. We stress that the maintenance of ontologies is primarily an organizational process. There must be strict rules for the update-delete-insert processes within ontologies. Most important is to clarify who is responsible for maintenance and how it is performed. E.g. is a single person or a consortium responsible for the maintenance process? In which time intervals is the ontology maintained? We recommend that the ontology engineer gathers changes to the ontology and initiates the switch-over to a new version of the ontology after thoroughly testing possible effects to the application, viz. performing additional cyclic refinement and evaluation phases. Similar to the refinement phase, feedback from users may be a valuable input for identifying the changes needed. Maintenance should accompany ontologies as long as they are on duty. 3 Tool Support for the Kick-off Phase Effectiveness and efficiency during the application of methodologies for system development increase significantly through tool support. Our tool OntoKick supports ontology engineers in the early stages of our methodology, viz. the kickoff phase of the ontology development. Tasks from the methodology are operationalized to enable e.g. up-to-date consistency checks and traceability of modeled objects like concepts and relations. Speaking on a technical level, OntoKick is implemented as a plug-in [5] for the preexisting ontology development environment OntoEdit [8], which allows for graphically oriented modeling of ontologies on a conceptual level (i.e. concepts, relations and to some extend also axioms are modeled independently from specific representation languages). The plug-in structure of OntoEdit enables flexible extensibility. Plugins can be uploaded during runtime and extend the range of OntoEdit s functionalities. OntoKick captures stepwise the content of the Ontology Requirements Specification Document (ORSD) and builds a platform to integrate various elements. One might perform the steps ORSD1 to ORSD5 from Table 1 (cf. Number 1 in Figure 2) in the proposed order and perform cycles (Number 2). We now describe each step in detail. Domain & goal are specified by ontology engineers at the very beginning of the development. To support

4 Figure 2 Management of different knowledge sources reusability through the classification of ontologies we integrated standardized industry claasifications 1. Design guidelines include predefined guidelines for the size and the structure of ontologies like the estimated number of concepts per ontology, the estimated maximum depth of the concepts hierarchy and a free form for additional guidelines (like naming conventions). They all remain linked to ontologies and the predefines guidelines are constantly checked during the development. Whenever the ontology exceeds predefined constraints, users are prompted e.g. if the envisioned maximum number of concepts or the maximum depth of the hierarchy branch is exceeded. One might think of two possible reactions. Either one needs to check the ontology itself to keep it within the boundaries. Or the guidelines, i.e. the requirements might need to be changed to reflect that they changed themselves (it seems natural that requirements might change over the time). So, the ontology is always within the range of specifications who constantly reflect the actually valuable requirements. Knowledge sources include all kinds of valuable knowledge sources for ontology development. Onto- Kick allows to manage different kinds of knowledge sources (see Number 3 in Figure 2) to keep the refer- 1 We used two standardized industry classification for the implementation: (1) Industry Classifactions & Eligibility Requirements from Commercial News USA, and (2) Hoover s Industry Sectors, ences to knowledge sources used during the development. For the analysis of the knowledge sources we currently focus on the capture of knowledge from domain experts with competency questionnaires, which will be described at the end of this section. Users and use cases are specified similar to the knowledge sources, i.e. links to existing documents are stored to keep track of the used documents. Finally, the deployment of ontologies to different applications is handled, i.e. each supported application might be characterized (e.g. the needed representation language for export of the ontology) and the path to store the productive version of the ontology might be specified. Knowledge sources provide useful hints for the development of ontologies. Especially during the kickoff phase one needs support in finding relevant concepts and relations for the specified domain to gather a baseline ontology. They might be retrieved through analysis of knowledge sources. We identified competency questionnaires as one of the most important knowledge sources. Therefore we initially implemented a semi-automatic extraction of concepts and relations from competency questions (see Figure 3). For the future we plan to expand OntoKick to support the analysis of various kinds of knowledge sources like e.g. business documents, UML diagrams and mind maps. An explorer-like tree shows the is-a concept hierarchy of the actual ontology (Number 1 of Figure 3). As basic functionality from OntoEdit, concepts and their

5 Figure 3 Competency Questionnaire relations 2 can be added, deleted, renamed and restructured. Competency questions like Welches Luxushotel liegt in Mecklenburg-Vorpommern (Number 2), which means in English Which luxury hotel is located in Mecklenburg-Vorpommern?, can be inserted and are stored in an enumeration of competency questions (Number 4) which altogether form a competency questionnaire filled in by a knowledge engineer and a domain expert. From each competency question one may select elements (i.e. words) in order to define concepts, relations or instances 3 of concepts 4. By default elements are inserted into the ontology as subconcepts of root (the uppermost element in the hierarchy), relations of root or instances of root. If a concept of the hierarchy is preselected, elements are added as subconcepts or instances of the marked concept and relations are attached to it. During the development ontologies may grow big and finding relevant superconcepts gets time consuming. Therefore we implemented a simple pattern matching assuming that in some cases the subconcept contains the name of it s superconcept or at least parts of the name (Number 4). The ontology engineer specifies the 2 Please note that we have a frame-oriented view on ontologies where relations are explicitly attached to their concepts. 3 Instances seem to be less important during the kickoff phase. In later stages one might want to have an initial set of instances to test and evaluate the ontology. 4 If a domain lexicon is available in OntoEdit, one might also add an element as a synonym for specific lexical entries from that lexicon. number of letters that should match (four letters in our example). All elements of the competency question that have parts of the specified size (four in our example) that match to parts of that size of already modeled concepts are underlined. E.g. in Figure 3 the words Welches, Luxushotel, liegt and Mecklenburg- Vorpommern are recognized by the system by using four letters for the pattern matching and, therefore, underlined. A right click with a mouse offers a context menu to add the element to the ontology or to show similar concepts, i.e. the concepts matching. In our example four letters of Luxushotel matched to four letters of Hotel either hote or otel. For this example choosing five letters would have done the job even better. In the figure shown we already included the element as a subconcept of Hotel (and it is therefore shown in the hierarchy). Finally we implemented an algorithm for word stemming (Porter Stemming Algorithm 5 ) that can be activated by a check-box (works only for English words). In combination with pattern matching it might help to decrease the number of words that match but are not helpful in finding relevant concepts. While browsing with OntoEdit through the ontology, one may always get the reference to the competency question that resulted in a specific concept (or relation etc.). This traceability helps to clarify the meaning of concepts, especially if more than one person are in- 5 The Porter Stemming Algorithm is available in Java at

6 volved in the modeling of the ontology or if the ontology is reused by other persons than the creator. 4 Related Work We here give an overview of existing methodologies for ontology development and show which of their ideas are adopted and expanded in our methodology. Skeletal Methodology. This methodology is based on the experience of building the Enterprise Ontology (cf. [14]), which includes a set of ontologies for enterprise modeling. The guidelines for developing ontologies start with identifying the purpose of an ontology and then concentrate on the building of ontologies which is broken down into the steps ontology capture, coding, evaluation and documentation. A disadvantage of this methodology is that it does not precisely describe the techniques for performing the different activities. For example, it remains unclear, how the key concepts and relationships should be acquired. Only a very vague guideline is given. We catch up the idea of competency questions and expand their usage. We not only propose to use them for evaluation of the system, but also for finding relevant lexical entries like concepts, relations etc.. KACTUS. The approach of [1] was developed within the Esprit KACTUS project. One of the objectives of this project was to investigate the feasibility of knowledge reuse in complex technical systems and the role of ontologies to support it. The methodology recommends an application driven development of ontologies. So, every time an application is assembled, the ontology that represents the knowledge required for the application is built. Three steps have to be taken every time an ontology-based application is assembled: 1. Specification of the application. Provide an application context and a view of the components that the application tries to model. 2. Preliminary design. Based on relevant top-level ontological categories create a first draft where the list of terms and application specific tasks developed during the previous phase is used as input for obtaining several views of the global model in accordance with the top-level ontological categories determined. Search for existing ontologies which may be refined and extended for use in the new application. 3. Ontology refinement and structuring. Structure and refine the model in order to arrive at a definitive design. The methodology offers very little detail and does not recommend particular techniques to support the development steps. Also, documentation, evaluation and maintenance processes are missing [7]. In general we agree with the general idea of application driven ontology development and in particular with refinement and structuring, which is reflected by our proposal of the ontology development process. Methontology. [4] includes: The Methontology framework from 1. The identification of the ontology development process, which refers to which tasks (planning, control, specification, knowledge acquisition, conceptualization, integration, implementation, evaluation, documentation, configuration management) one should carry out, when building ontologies. 2. The identification of stages through which an ontology passes during its lifetime. 3. The steps to be taken to perform each activity, supporting techniques and evaluation steps. 4. Setting up an ontology requirements specification document (ORSD) to capture requirements for an ontology similar to a software specification. The methodology offers detailed support in development-oriented activities except formalization and maintenance and describes project management activities. We adopted the general idea of an ontology requirements specification document (ORSD), but modified and extended the presented version by our own needs. 5 Conclusion We presented a methodology for introducing ontology based knowledge management into enterprises. Our methodology covers steps from early stages in knowledge management projects to the deployment and maintenance of an ontology based knowledge management system. The methodology already has been applied to case studies ranging from the implementation of the knowledge portal of our own institute [12] to several industrial case studies ([11], [13]). Experiences gained while applying the methodology in further case studies will be integrated in future versions of our methodology. Effectiveness and efficiency while performing steps of methodologies for system development increase through tool support. We presented tool support for

7 early stages of our methodology, viz. the kickoff phase of ontology development, by our tool Onto- Kick. To main aspects are covered: the capture of general requirement specifications for an ontology and the analysis of a specific requirement specification, viz. competency questionnaires. They serve as knowledge sources for the development of a baseline ontology. OntoKick enables semi-automatic extraction of concepts, relations and instances out of the competency questions. Traceability ensures that the context of extracted concepts, relations and instances is persistent. For the future we plan to expand the analysis of knowledge sources (i.e. analysis of documents other than competency questionnaires like e.g. mind maps). A promising area for expansion seems to be the tighter integration of use cases (e.g. UML diagrams). Furthermore we will expand the support in general for further steps of our methodology. E.g. we plan to explore the possibility of supporting the usage of the captured and analyzed competency questions for the evaluation phase. The final goal is to have a full fledged tool support (as far as possible) for the methodology for ontology based knowledge management. Acknowledgements. We thank our colleagues and students at the Institute AIFB, University of Karlsruhe, without whom the research would not have been possible especially Hans-Peter Schnurr (now ontoprise GmbH), Siggi Handschuh (AIFB) and Claus Boyens (AIFB). The research presented in this paper has been partially funded by EU in the IST project On-To-Knowledge. 7. F. López. Overview of methodologies for building ontologies. In Proceedings of the IJCAI-99 Workshop on Ontologies and Problem-Solving Methods: Lessons Learned and Future Trends. CEUR Publications, A. Maedche, H.-P. Schnurr, S. Staab, and R. Studer. Representation language-neutral modeling of ontologies. In Proceedings of the German Workshop Modellierung, Koblenz, Germany, April, D. O Leary. Using AI in knowledge management: Knowledge bases and ontologies. IEEE Intelligent Systems, 13(3):34 39, May/June G. Schreiber, H. Akkermans, A. Anjewierden, R. de Hoog, N. Shadbolt, W. Van de Velde, and B. Wielinga. Knowledge Engineering and Management The CommonKADS Methodology. The MIT Press, Cambridge, Massachusetts; London, England, S. Staab, H.-P. Schnurr, R. Studer, and Y. Sure. Knowledge processes and ontologies. IEEE Intelligent Systems, 16(1):26 34, N. Stojanovic, A. Maedche, S. Staab, R. Studer, and Y. Sure. SEAL A Framework for Developing SEmantic PortALs. In K-Cap First International Conference on Knowledge Capture, Oct , 2001, Victoria, B.C., Canada, to appear. 13. Y. Sure and R. Studer. On-To-Knowledge Methodology Evaluated and Employed Version. On-To- Knowledge deliverable D-16, Institute AIFB, University of Karlsruhe, M. Uschold and M. King. Towards a Methodology for Building Ontologies. In Workshop on Basic Ontological Issues in Knowledge Sharing, held in conjunction with IJCAI-95, Montreal, Canada, References 1. A. Bernaras, I. Laresgoiti, and J. Corera. Building and Reusing Ontologies for Electrical Network Applications. In Proceedings of the European Conference on Artificial Intelligence ECAI-96, DAML+OIL R. Dieng, O. Corby, A. Giboin, and M. Ribiere. Methods and tools for corporate knowledge management. Int. Journal of Human-Computer Studies, 51(3): , A. Gomez-Perez. A Framework to Verify Knowledge Sharing Technology. Expert Systems with Application, 11(4): , S. Handschuh, S. Staab, and A. Maedche. CREAM Creating relational metadata with a component-based, ontology-driven annotation framework. In K-Cap First International Conference on Knowledge Capture, Oct , 2001, Victoria, B.C., Canada, to appear. 6. O. Kuehn and A. Abecker. Corporate memories for knowledge memories in industrial practice: Prospects and challenges. Journal of Universal Computer Science, 3(8), August 1997.