1. A Methodology for Ontology-based Knowledge Management - York Sure and Rudi Studer - 세미나명 : AI-Lab 겨울세미나 발표자 : 정영임 발표일자 : 1 월 13 일 ( 목 )

2. 2 Table of Contents ⊙ Introduction ⊙ Feasibility Study ⊙ Kick Off Phase ⊙ Refinement Phase ⊙ Evaluation Phase ⊙ Maintenance and Evolution Phase ⊙ Related Work ⊙ Conclusion

3. 3 Introduction ⊙ Ontology  Core element of the knowledge management architecture ⊙ In this paper,  Description of a methodology for application driven ontology development  Description of existing methodologies In common, they start from the identification of the purpose of the ontology and domain knowledge acquisition They differ in their foci and following procedures to be taken

4. 4 Introduction ⊙ Steps of the on-to-knowledge (OTK) methodology

5. 5 Feasibility Study ⊙ Users and use cases of on-to-knowledge  Stakeholders Users of the system (knowledge worker) Supporters of the system ( knowledge engineer, knowledge provider, management)  User driven use cases Push services, community of knowledge sharing, navigating/browsing/ querying/seeking a knowledge base  Supporting use cases Ontology development, maintenance, annotation, fill knowledge base

6. 6 Feasibility Study ⊙ Users and use cases of on-to-knowledge

7. 7 Feasibility Study ⊙ CommonKADS methodology  Leading methodology to support structured knowledge engineering  Three models Organization model (OM), task model (TM) and agent model (AM)  Process of building these 3 models Carry out a scoping and problem analysis study –Identifying problem/opportunity areas and potential solutions, and putting them into a wider organizational prospective –Deciding about economic, technical and project feasibility Carry out an impacts and improvement study –Gathering insights into the interrelationships between the business task, actors involved, and use of knowledge for successful performance, and what improvements may be achieved here –Deciding about organizational measures and task changes

8. 8 Feasibility Study ⊙ Modified CommonKADS  Task analysis (TM-1)  Knowledge item analysis (TM-2)  Agent model (AM-1) AM-1 worksheet agent model People involved GUI Focus domain for ontology development Tool Selection TM-2 worksheet knowledge item analysis TM-1 worksheet task analysis

9. 9 Kick Off Phase (1/6) ⊙ Ontology Requirements Specification Document (ORSD)  In general, Goal Describes what an ontology should support Contains a set of relevant structures of the domain Guides an ontology engineer in deciding about inclusion and exclusion of concepts/relations and hierarchical structure  In detail, Subphases Contains the following information: –Domain and goal of the ontology –Design guidelines –Knowledge sources –(Potential) users and usage scenarios –Competency questions –Applications supported by the ontology

10. 10 Kick Off Phase (2/6) ⊙ Domain and goal of the ontology  Specification of a particular and interesting domain in use  Outcomes of the task analysis to describe the goal of the ontology E.g. ‘The ontology serves as a means to structure the xy domain ‘The ontology serves as a guideline for the knowledge distribution between department A and department B’ ⊙ Design guidelines  Guidelines for users who are not familiar with modeling ontologies  Estimation of the number of concepts and the level of granularity of the planned model E.g. Requirement analysis : 100 concepts Built in ontology : 1000 concepts Solutions: To modify the ontology or to update the requirement specification

11. 11 Kick Off Phase (3/6) ⊙ Knowledge sources  Knowledge item analysis from feasibility study serves as knowledge source  Partial list of knowledge sources TM1 Domain experts (interviews, competency questionnaires) (re-useable) ontologies Dictionaries Product and project descriptions Technology white papers Business plans  Knowledge sources based on their availability and reliability should be considered ⊙ Users and usage scenarios  Lists of potential users or user groups and description of each usage scenario  Description of hindering blocks as important hints for designing ontology based system.

12. 12 Kick Off Phase (4/6) ⊙ Competency questions  Transformation of the usage scenarios  Overview of possible queries to the system, indicating the scope and content of the domain ontology ⊙ Application supported by the ontology  Design of a draft for the ontology based knowledge management application and its system Draft must deliver a clear picture about the ontology interface E.g.) What parts of the ontology, namely concepts and relations, are visible to the users and how does he use them?  Task analysis from the feasibility study as an input source to describe the proposed system and analyze the role of the ontology  Track of running application on different hosts or different locations might be kept to enable separate update processes in the maintenance phase

13. 13 Kick Off Phase (5/6) ⊙ Two approaches to modeling  Top-down approach One starts by modeling concepts on a very generic level and then refines them Usage scenario, competency question method follows a top-down approach in modeling the domain In practice, it seems to be more like a middle-out approach This approach is typically done manually and leads to a high-quality engineered ontology It supports the fine tuning of the ontology It is not likely to be complete and might not focus on the documents available

14. 14 Kick Off Phase (6/6) ⊙ Two approaches to modeling  Bottom-up approach Relevant lexical entries are extracted semi-automatically from available documents Based on the assumption that most concepts, conceptual structures and terminologies of the domain are described in document, knowledge acquisition from text seems to be promising This approach is used for merging ontologies OntoExtract from CognIT provides support for semi-automatic extraction of relevant conceptions and relations between ontologies It is usually not able to produce high-quality It offers a more complete list of relevant concepts ⊙ Hybrid approach  Combination of the top-down and the bottom-up approach

15. 15 Refinement Phase ⊙ Goal  To produce a mature and application-oriented target ontology according to the specification ⊙ Subphases  Knowledge elicitation process with domain experts based on the initial input is performed  Initial draft of the ontology is modified or extended  Target ontology is created by formalizing the semi-formal description of the ontology in OIL, DAML+OIL  Formal representation languages typically differ in their expressive power and tool support for reasoning. Thus appropriate languages for the application and, their advantages and limitations should be considered. ⊙ Iterative procedure  Closely linked to the evaluation phase  If the analysis of the ontology in the evaluation phase shows gaps and misconceptions, these results are taken as an input for the refinement phase.

16. 16 Evaluation Phase ⊙ Goal  To make a technical judgment of ontologies (Gomez-Perez, 1996) ⊙ Subphases  Checking whether the target ontology itself suffices the ORSD, and whether the ontology based application supports or answers the competency questions  Testing the ontology in the target application environment  Obtaining feedback from beta users of the prototype as an input for further refinement of the ontology Usage patterns of the ontology is a valuable input for refinement Parts of the ontology used with high frequency might need to be expanded

17. 17 Maintenance and Evolution Phase ⊙ Goal  To manage organizational maintenance process ⊙ Subphases  Setting strict rules to the update/insert/delete processes of ontologies  Gathering changes to the ontology  Switching over to a new version of the ontology after thoroughly testing all possible effects on the application  Clarifying 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 interval is the ontology maintained?

18. 18 Related Work ⊙ Drift  Each research group employed its own methodology  Some methodologies guiding the ontology development process have been proposed Skeletal methodology was the first methodological outline proposed on the basis of the experience developing the Enterprise Ontology (Ushold and King, 1995) As part of Esprit KACTUS project, a method to build an ontology in the domain of electrical networks was presented (Bernaras et al., 1996) Methontology developed and extended (Gomez-Perez, 1996)  Philosophical discipline of ontology is evolving towards an engineering discipline Guarino and Welty (2000) demonstrate how some methodology efforts founded on analytic notions that have been drawn from philosophy can be used as formal tools of ontological analysis

19. 19 Skeletal Methodology ⊙ Guidelines  Identify purpose  Building the ontology Ontology capture Coding Integrate  Evaluation  Documentation ⊙ Disadvantages  It does not precisely describe the techniques for performing the different activities E.g. It remains unclear how the key concepts and relationships should be acquired, it only involves the use of brainstorming techniques  Recommendation for a life cycle and guidelines about the maintenance of evolving ontologies have not been suggested

20. 20 KACTUS ⊙ Three steps for assembling an ontology-based application  Specification of the application  Preliminary design  Ontology refinement and structuring ⊙ Disadvantages  It offers very little detail and does not recommend particular techniques to support the development steps  Documentation, evaluation and maintenance processes are missing

21. 21 Methontology ⊙ Methontology framework  The identification of the ontology development process Which tasks (planning, control, specification, knowledge acquisition, conceptualization, integration, implementation, evaluation, documentation, configuration management) one should carry out, when building ontologies  The identification of stages through which an ontology passes during its lifetime  The steps to be taken to perform each activity, supporting techniques and evaluation steps  Setting up an ORSD to capture requirements for an ontology similar to a software specification

22. 22 Formal Tools of Ontological Analysis ⊙ Formal ontology of unary properties  This formal ontology is based on four fundamental philosophical notions (identity, unity, rigidity and dependence) which impose constraints for modeling a domain  Semantic constraints imposed on is-a relation clarify misconceptions about taxonomies and give support to bring substantial order to ontologies

23. 23 Conclusion ⊙ In this paper,  Comprehensive methodology that guides the development of ontologies for knowledge management application has been presented  Five major steps – a feasibility study, kick off phase, refinement phase, evaluation phase and maintenance & evolution phase – are performed to build an ontology-based application ⊙ In the future,  Expanded support for the maintenance and evolutionary aspects of ontologies will be investigated

24. 24 CommonKADS