<Towards the Semantic Web> A Methodology for Ontology-based Knowledge Manageme

nt- 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 int

o 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 inv

olved, 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)

AM-1worksheetagent model

People involved GUI

Focus domain for ontologydevelopment

Tool Selection

TM-2worksheetknowledge

item analysis

TM-1worksheettask analysis

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 conc

epts/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 pl

anned model• E.g. Requirement analysis : 100 concepts

Built in ontology : 1000 conceptsSolutions : To modify the ontology or to update the require

ment specification

11

Kick Off Phase (3/6)

⊙ Knowledge sources Knowledge item analysis from feasibility study serves as knowledge sourc

e 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 sce

nario 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 rele

vant 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 th

e 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 mi

sconceptions, 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 wheth

er 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 furth

er 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 bee

n proposed• Skeletal methodology was the first methodological outline proposed on the ba

sis 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 dis

cipline• Guarino and Welty (2000) demonstrate how some methodology efforts founde

d 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 acq

uired, 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, conceptu

alization, 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 f

or knowledge management application has been presented Five major steps – a feasibility study, kick off phase, refinement phase, e

valuation 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 ontolo

gies will be investigated

24

CommonKADS