<Towards the Semantic Web> A Methodology for Ontology-based Knowledge Management - York Sure and Rudi Studer -

1
ltTowards the Semantic Webgt A Methodology for
Ontology-based Knowledge Management- York Sure
and Rudi Studer -

• ???? AI-Lab?????
• ??? ???
• ???? 1? 13? (?)

2
Table of Contents

• Introduction
• Feasibility Study
• Kick Off Phase
• Refinement Phase
• Evaluation Phase
• Maintenance and Evolution Phase
• Related Work
• Conclusion

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
Introduction

• Steps of the on-to-knowledge (OTK) methodology

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
Feasibility Study

• Users and use cases of on-to-knowledge

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
Feasibility Study

• Modified CommonKADS
• Task analysis (TM-1)
• Knowledge item analysis (TM-2)
• Agent model (AM-1)

TM-1 worksheet task analysis
Tool Selection
Focus domain for ontology development
TM-2 worksheet knowledge item analysis
People involved GUI
AM-1 worksheet agent model
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
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
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
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
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
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
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,
  DAMLOIL
• 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
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
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
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
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
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
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
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
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
CommonKADS