웹 온톨로지 개발지침 연구 - ITFINDagent.itfind.or.kr/Datarpt/Web_R_13.pdfiii 요 약 문...

NCA Ⅳ- RER-04059 / 2004. 12

웹 온톨로지 개발지침 연구 A Research on Web Ontology Development Guideline

NCA Ⅳ- RER-04059 / 2004. 12

80

웹 온톨로지 개발 지침 연구

A Research on Web Ontology Development Guideline

제 출 문

정보통신부장관 귀하

본 보고서를 웹 응용기술 표준화 연구 사업 중 “웹 온톨로지 개발 지침 연구” 과

제의 최종 연구보고서로 제출합니다.

2004년 12월

연구책임자: 류광택 (정보화성과평가단 정보화기술기획팀 연구위원)

참여연구원: 이헌중 (정보화성과평가단 정보화기술기획팀 팀장)

이상학 (정보화성과평가단 정보화기술기획팀 선임연구원)

김은주 (정보화성과평가단 정보화기술기획팀 전임연구원)

이승한 (정보화성과평가단 정보화기술기획팀 전임연구원)

정현철 (정보화성과형가단 정보화기술기획팀 전임연구원)

김홍기 (단국대학교 경 정보학과 교수)

참여연구조원: 김학래 (단국대학교 경 정보학과 박사과정)

ii

서 문

오늘날 인터넷 전송속도 증가와 웹 기술 발전에 힘입어, 부가가치가 놓은 수많은

정보 및 데이터들이 인터넷을 통해 유통되고 있습니다. 이러한 정보자원들을 보다

효율적으로 관리하고 업무에 활용하고자 하는 움직임이 최근 활발이 진행되고 있습

니다. 이를 지원하는 대표적인 기술로 온톨로지 기술이 부상하고 있습니다. 온톨로

지는 어휘나 개념의 정의 또는 명세로, 컴퓨터 및 정보사용자들간 교환되는 용어

및 어휘를 동일한 의미로 인식되도록 하는 기술입니다.

온톨로지는 정보검색ᆞ의료정보 및 바이오 정보ᆞ인공지능 및 에이전트ᆞ전자상

거래ᆞ지능형인터넷 등 다양한 기술분야에 적용될 수 있으며, 실제 이러한 분야에

서 현재 활발히 연구가 진행되고 있습니다. 올해 국내에서는 조달청이 전자상거래

표준 온톨로지 시스템을 개발하여 국가종합전자조달시스템인 나라장터에 적용을 시

도하고 있고, 서울대학병원ᆞ경희대학병원ᆞ단국대학교 등을 중심으로 의료분야 온

톨로지를 구축하려는 움직임이 있습니다.

이처럼 온톨로지는 연구단계를 지나 실생활에 적용하는 시점에 접어들었습니다.

향후 온톨로지를 여러 분야에서 개발될 것으로 예상되며, 보다 사업이 활성화되기

이전에 온톨로지가 추구하는 정보공동활용을 극대화를 지원하기 위해서, 사전에 온

톨로지 구축에 필요한 개발절차 및 고려사항들을 제시하는 지침에 대한 선행 연구

가 필요하다고 하겠습니다.

이에, 본 보고서에서는 이러한 요구를 반영하여 온톨로지를 개발하고자 하는 개

인 또는 기업들이 실제 온톨로지 구축시 필요한 기획ᆞ설계ᆞ구현 등 단계에서 고

려해야 할 사항 및 절차를 제시하고 있습니다. 본 연구 결과가 온톨로지 관련 정책

을 수립하거나, 사업을 수행하거나, 표준을 개발하고자 하는 분들께 유용한 자료가

되길 바랍니다

2004년 12월 31일

한 국 전 산 원 장

서 삼

iii

요 약 문

1. 제목

온톨로지 개발 지침 연구

2. 연구 개발의 목적 및 중요성

시맨틱 웹은 일종의 차세대 웹을 위한 비전으로서 정보의 의미를 컴퓨터 프로그

램이 해석할 수 있도록 해주는 것을 목표로 하고 있다. 이로써 사람과 전산 시스템

간, 그리로 상이한 전산 시스템들간에 웹과 같은 분산적 환경에서 커뮤니케이션이

효과적으로 이루어질 수 있도록 해준다. 시맨틱 웹을 실현하기 위한 첫 단계이며

가장 중요한 과제가 바로 온톨로지를 제작하는 것이라 할 수 있다. 온톨로지는 에

이전트들간에 커뮤니케이션의 전제가 되고 실제 내용이 되는 용어들을 개념적(혹은

의미적) 수준에서 처리할 수 있도록 표현한 고차원의 데이터베이스라 할 수 있다.

본 연구는 온톨로지를 구축하기 위한 구체적 가이드라인을 제공하는데 목적이 있

다. 온톨로지의 구축은 소프트웨어 공학적인 관점, 논리, 철학적인 배경 지식을 요

구하는 복잡한 절차가 포함되어 있다. 온톨로지 공학에 대한 연구는 지난 수 년간

진행되어 왔다. 그러나 사용자가 원하는 기능을 제공하는 방법론은 극히 드문 상태

이다. 또 대부분의 방법론이 이론적 연구 수준에 머물러 있어 실제 활용하기 힘들

다. 본 연구는 이와 같은 문제점을 해결하기 위하여 다양한 개발 방법론을 분석하

여 국내에 적용 가능한 온톨로지 개발 방법론을 제안하는데 목적이 있다.

3. 연구 개발의 내용 및 범위

본 연구 보고서는 온톨로지를 개발하기 위한 통합적인 방법론을 제공하는 것을

목표로 한다. 이를 위해 온톨로지가 무엇인지 개념적으로 소개하고, 웹 표준 언어와

기존 방법론을 설명한다. 또한 온톨로지 개발을 위한 점진형 프로토타입 방식의 방

법론에 대해 기술한다.

4. 연구 개발 결과

iv

본 연구 보고서의 개발 결과는 본문에 자세히 설명되어 있다. 본 연구의 핵심은

온톨로지를 개발하는데 활용할 수 있는 EOE(Evolving Ontological Engineering)

방법론에 대한 내용이다. 본 연구 보고서를 구성하고 있는 각 장은 다음과 같은 세

부 연구 결과들을 포함하고 있다.

• 제 1 장: 본 연구 보고서의 목적 및 필요성을 기술한다.

• 제 2 장: 온톨로지의 정의, 응용 분야 및 표현 언어에 대해 기술한다.

• 제 3 장: 온톨로지 개발 방법론의 종류와 특성에 대해 살펴본다. 온톨로지 개

발 방법론에는 Cyc, Uschold & King의 방법론, Gruninger & Fox, KACTUS,

METHONTOLOGY, OTKM 등이 있다.

• 제 4 장: 협력적인 방법으로 온톨로지를 개발하는 방법론을 살펴본다.

• 제 5 장: 온톨로지 병합과 통합을 위한 방법론을 살펴본다.

• 제 6 장: 온톨로지 구축을 위한 EOE 방법론을 설명하고, 적용 사례를 설명한

다.

• 제 7 장: 본 연구 보고서의 내용을 요약하고 그 기대효과를 설명한다.

5. 활용에 대한 건의

본 연구 보고서는 온톨로지에 대한 이론적 설명과 관련 표준 언어를 이용해 온톨

로지를 구축하는 방법을 설명하고 있다. 따라서 온톨로지를 구축할 때, 본 연구보고

서를 참고할 수 있다. 본 보고서를 이용해 온톨로지를 구축할 때, Protégé 2, OilED

와 같은 저작 도구를 활용하기를 권고한다.

v

6. 기대 효과

본 연구 보고서를 활용함으로써 아래와 같은 기대 효과를 얻을 수 있다.

대용량 지식 베이스의 일관된 개발과 관리

체계적인 온톨로지 모델링 기법 및 구축 방법론 정립

모델링 표준화를 통한 온톨로지 개발의 시간 감축

시맨틱 웹 환경에 적용 가능한 온톨로지 개발

vi

SUMMARY

1. Title

A Research on Ontology Development Guideline

2. Research Purpose

The Semantic Web is a vision of a next generation Web of meaningful

information, which can be interpreted by computer programs. The Semantic

Web facilitates communications between heterogeneous systems on the Web.

The first step and the most important task to realize the Semantic Web is

building ontologies. An ontology is a sort of database representing meanings of

vocabularies that provide background knowledge and actual contents in a

domain for communications between agents.

The purpose of this document is to provide a practical guideline for ontology

building. Ontology Engineering is a discipline that requires quite complicated

knowledge adopted from different disciplines such as software engineering,

logics, and philosophy. Recently many methodologies have been suggested for

developing ontologies. However, most of them are too theoretical to explicate

practices for the actual users. Thus, we suggest a prototype methodology,

named EOE (Evolving Ontological Engineering) methodology that is useful for

Korean users..

3. Contents and Scope

The main goal of this research report is to suggest a prototype methodology

for ontology construction. Firstly, for this, we consider several important

existing methodologies. Then, we describe EOE methodology with templates

as step by step guidelines.

vii

4. Results

The main focus of the document is to suggest the EOE (Evolving Ontological

Engineering) methodology for the ontology construction. The summarized

results are described in the following.

• Part 1: The main purpose and necessities are provided in this part.

• Part 2: The basic concept of ontology, related tools, and representation

languages are described.

• Part 3: Kinds and characteristics of ontology methodologies are discussed

in this part. This includes Cyc, Uschold & King ’ s methodology,

Gruninger & Fox, KACTUS, METHONTOLOGY, OTKM etc.

• Part 4: This part introduces a collaborative methodology for developing

ontologies.

• Part 5: Methods for ontology merge and integration are discussed.

• Part 6: A case study of ontology construction using EOE methodology is

presented.

• Part 7: Part 7 includes conclusions and effects of this research.

5. Suggestions

This research report describes a theoretical introduction to ontology

engineering and provides a useful guideline for ontology construction. In

constructing an ontology based on this report, we suggest that special

ontology editors such as Protégé 2 and OilED be used.

viii

6. Benefits

We expect several benefits in the following when using this report.

Consistent management of a large-scale ontology construction

Systematic Mechanism for ontology modeling and methodology

Reduce the time of ontology development through modeling

standardization

ix

<Contents>

Chapter 1 Introduction........................................................................... 1

1. Purpose....................................................................................................... 1

2. Necessity of the Research.............오류! 책갈피가 정의되어 있지 않습니다.

Part 2 Introduction of Ontology .......................................2

1. Definiton...................................................................................................... 2

2. Kinds, Applications..................................................................................... 3

3. Web Ontology Languages .......................................................................... 5

Part 3 Ontology Building Methodologies ....................... 11

1. Cyc ............................................................................................................ 11

2. Uschold & King’s Methodology............................................................. 13

3. Gruninger & Fox’s Methodology........................................................... 15

4. KACTUS ................................................................................................... 16

5. METHONTOLOGY ................................................................................... 17

6. SENSUS.................................................................................................... 26

7. OTK Methodology .................................................................................... 28

Part 4 Collaborative Ontology Buidling Methdology ...... 31

1 Co4 ............................................................................................................. 31

2 (KA)2......................................................................................................... 33

Part 5 Merging and Integration for Ontology........................35

x

1 ONIONS ..................................................................................................... 37

2 PROMPT .................................................................................................... 46

Part 6 EOE Methodology....................................................................49

1 Overview.................................................................................................... 49

2 Principles of Flow ..................................................................................... 50

3 Implemetation ............................................................................................ 69

제7장 Conclusions........................................................... 78

Appendix A Concept Dictionary..................................... 79

Appendix B Class Dictionary.......................................... 80

Appendix C Class Relation Dictionary............................ 81

Appendix D Attribute Catalog ....................................... 82

Appendix E Symbol Catalog .......................................... 83

xi

<목 차>

제1장 서론...........................................................................1

제1절 개요 ....................................................................................................... 1

제2절 목적 ....................................................................................................... 1

제2장 온톨로지....................................................................2

제1절 온톨로지의 정의..................................................................................... 2

제2절 온톨로지의 종류, 응용 ........................................................................... 3

제3절 웹 온톨로지 언어의 개요....................................................................... 5

제3장 온톨로지 구축을 위한 방법론................................. 11

제1절 Cyc...................................................................................................... 11

제2절 Uschold & King의 방법론................................................................... 13

제3절 Gruninger & Fox 방법론 .................................................................... 15

제4절 KACTUS............................................................................................. 16

제5절 METHONTOLOGY............................................................................. 17

제6절 SENSUS.............................................................................................. 26

제7절 OTK Methodology.............................................................................. 28

제4장 협력적 온톨로지 구축을 위한 방법론......................31

제1절 Co4...................................................................................................... 31

제2절 (KA)2 ................................................................................................. 33

제5장 온톨로지 병합과 통합을 위한 방법론......................35

제1절 ONIONS .............................................................................................. 37

xii

제2절 PROMPT............................................................................................. 46

제6장 EOE 방법론 .......................................................... 49

제1절 EOE 방법론의 개요............................................................................. 49

제2절 단계별 개발 원칙................................................................................. 50

제3절 온톨로지의 구현................................................................................... 69

제7장 결론.........................................................................78

부록 A 개념사전............................................................... 79

부록 B 클래스 사전.......................................................... 80

부록 C 클래스 관계 사전.................................................. 81

부록 D 속성 목록.............................................................. 82

부록 E 심볼 목록.............................................................. 83

xiii

<그 림 목 차>

그림 2. 1 온톨로지의 분류........................................................................................3

그림 2. 2 온톨로지의 종류........................................................................................4

그림 2. 3 Sowa의 Top-Level 온톨로지..................................................................4

그림 2. 4 RDF, XML, 메타데이터의 관계.................................................................5

그림 2. 5 이용한 자원 기술의 예..............................................................................7

그림 2. 6 웹 온톨로지 언어의 발전 단계 .................................................................8

그림 2. 7 OWL 언어의 종류 .....................................................................................9

그림 3. 1 Cyc 방법론..............................................................................................12

그림 3. 2 OpenCyc .............................................................................................. 113

그림 3. 3 METHONTOLOGY 방법론의 프로세스..................................................18

그림 3. 4 명세화 문서의 예 ....................................................................................19

그림 3. 5 개념화 단계별 작업.................................................................................20

그림 3. 6 용어사전의 예 .........................................................................................21

그림 3. 7 항공기에 대한 개념 분류 트리 ...............................................................21

그림 3. 8 개념 사전 ................................................................................................22

그림 3. 9 클래스 속성 테이블.................................................................................23

그림 3. 10 인스턴스 속성 테이블 ...........................................................................23

그림 3. 11 공리 테이블...........................................................................................24

그림 3. 12 ODE를 통한 온톨로지 구현 ..................................................................25

그림 3. 13 SENSUS 온톨로지 구축 과정...............................................................26

그림 3. 14 SENSUS 기반의 온톨로지 구축 과정 ..................................................27

그림 3. 15 Ontosaurus를 이용한 검색의 예 ..........................................................28

그림 3. 16 OTK 방법론 ..........................................................................................29

그림 4. 1 사용자 제안의 제출과 승인.....................................................................32

그림 4. 2 ODE를 통한 온톨로지 구축.....................................................................34

그림 5. 1 동의어 관계.............................................................................................35

그림 5. 2 온톨로지의 병합......................................................................................36

그림 5. 3 온톨로지의 통합......................................................................................37

그림 5. 4 ONIONS 방법론의 통합 단계 .................................................................39

그림 5. 5 UMLS(Metathesaurus) 분류체계..........................................................40

그림 5. 6 분류체계를 위한UMLS 명세...................................................................41

그림 5. 7 ONIONS에서 사용하는 언어 비교 ..........................................................42

그림 5. 8 PROMPT 아키텍처...............................................................................46

xiv

그림 5. 9 PROMPT 알고리즘의 흐름도 ...............................................................47

그림 6. 1 EOE 방법론 프로세스 .............................................................................50

그림 6. 2 요구사항 분석의 프로세스 ......................................................................50

그림 6. 3 한국의 전통술에 대한 문서.....................................................................56

그림 6. 4 명사분석의 예 .........................................................................................56

그림 6. 5 클래스 사전.............................................................................................59

그림 6. 6 개념 관계의 의미 모델............................................................................61

그림 6. 7 순곡주류의 의미 모델 .............................................................................61

그림 6. 8 클래스 관계 사전 ....................................................................................62

그림 6. 9 OWL의 속성 형식 ...................................................................................64

그림 6. 10 RDF 스키마와 OWL의 속성의 차이 ...................................................65

그림 6. 11 속성 목록 ..............................................................................................66

그림 6. 12 제조소재지 속성의 제약 조건...............................................................67

그림 6. 13 심볼 목록의 예......................................................................................67

그림 6. 14 공리 목록서의 예..................................................................................68

그림 6. 15 인스턴스의 예-안동소주.......................................................................69

<표 목 차>

표 3.1 기업 온톨로지에 정의된 용어들.............................14

표 5.1 온톨로지 병합과 통합의 비교 ................................ 36

표 61 비전 및 범위 문서의 예........................................... 52

1

제1장. 서론

1. 개요

웹 환경과 관련되어 최근에 주목 받고 있는 것이 시맨틱 웹이다. 시맨틱 웹은 기

존의 웹이 사람 중심이었던 한계를 벗어나, 기계와 기계 사이에 의사소통이 자동적

으로 수행될 수 있는 차세대 웹 환경이다. 즉, 시맨틱 웹은 기계 스스로 개념화 과

정(conceptualization process)과 추론 과정(inference process)을 통해 사람이

원하는 정보를 찾아주는 환경이다. 그러나 기계가 이런 과정을 자동적으로 처리하

기 위해 실 세계의 지식을 기계가 처리 가능한 형태로 표현하는 것이 중요하다. 온

톨로지란 용어 사이의 관계를 정의하고 있는 일종의 사전과 같은 것이라 할 수 있

다. 시맨틱 웹을 실현하기 위한 첫 단계는 바로 온톨로지를 구현하는 것이라 할 수

있다. 온톨로지의 구현은 소프트웨어 공학적인 관점, 논리, 철학적인 배경 지식을

요구하는 복잡한 절차가 포함되어 있다. 온톨로지 공학에 대한 연구는 지난 수년간

진행되어 왔다. 그러나 사용자가 원하는 기능을 제공하는 방법론은 극히 드문 상태

이다. 또 대부분의 방법론이 이론적 연구 수준에 머물러 있어 실제 활용하기 힘들

다.

본 연구는 이와 같은 문제점을 해결하기 위하여 다양한 개발 방법론을 분석하여

국내에 적용 가능한 온톨로지 개발 방법론을 제안하고 있다.

2. 목적

본 연구의 목적은 온톨로지를 구축하기 위한 구체적 가이드라인을 제공하는데 목

적이 있다. 온톨로지 공학은 지식 베이스의 설계 목적, 핵심 개념화 뿐만 아니라 실

세계의 정보 모델 구축을 위해 지식을 축적하는 이론을 제공한다. 따라서 통합적

온톨로지 개발 방법론을 개발하는 것은 다음과 같은 목적을 위해 반드시 요구된다.

- 대용량 온톨로지 라이브러리의 일관된 개발과 관리

- 체계적인 온톨로지 모델링 기법 및 구축 방법론 정립

- 모델링 표준화를 통한 온톨로지 개발의 시간 감축

2

제2장. 온톨로지

온톨로지(ontology)란 원래 철학 용어이나, 지금은 철학 이외의 여러 다른 분야에

서도 널리 사용되고 있다. 그러므로 온톨로지의 개념을 정립하기 위해서는 먼저 이

것이 갖는 본래의 철학적 의미를 간단히 살펴볼 필요가 있다.

제 1 절 온톨로지의 정의

온톨로지는 철학의 매우 중요한 분야 중 하나로, 우리말로는 보통 ‘존재론’이라

고 하고, 때때로 ‘형이상학(metaphysics)’과 동의어로 취급하기도 한다. 이것은

세계를 구성하는 모든 종류의 대상들의 존재에 관한 탐구(study of existence)이다.

학문으로서의 온톨로지는 아리스토텔레스로부터 비롯되었다고 보는 것이 정설이지

만, ‘온톨로지’란 단어가 최초로 문헌에 등장한 것은 17세기 초반이다.

구아리노(Guarino, 1998)는 ‘Ontology’와 ‘ontology’를 구분하 는데, 이에

따르면’Ontology’는 지금까지 이야기한, 철학의 특정한 분야를 지칭한다. 반면

‘ontology’는 Ontology의 산물로서, 세계를 보는 어떤 시각이 반 되어 있는 특

정한 분류 체계를 가리킨다. 예컨대, ‘Aristotle’s ontology’와 같은 방식으로

사용이 가능하다.

전산학, 혹은 인공지능 분야에서는 ‘온톨로지’란 용어가 1970년대 후반 내지

1980년대 초반부터 사용되기 시작했다. 맥카시(J.McCarthy)는 AI 시스템의 논리

적 이론들을 구축하는 활동과 철학적 온톨로지에서 이루어졌던 작업 사이에 공통되

는 부분이 있다는 사실을 최초로 인지한 사람으로 평가된다. 이러한 그의 관점은

철학자인 콰인(W. Quine)으로부터 향을 받은 바 크다. 콰인은 “존재하는 것은

무엇인가(What is there)”라는 존재론의 전통적인 질문에 “존재하는 것은 양화된

변항의 값(value of quantified variable)이다 ” 라는 하나의 기준(Qunie ’ s

criterion)을 제시하 는데, 이것에 따르면 결국 온톨로지란 특정한 언어 L을 사용

하는 사람이 어떤 역 D에 관해 이야기할 때 (암묵적으로) D에 존재한다고 그가

가정하고 있는 대상들의 종류의 목록이라는 귀결이 가능하다. 여기서 한 가지 유의

할 점은 이렇게 되면 온톨로지는 이제 언어 의존적(language-dependent)이 된다

는 사실이다. 맥카시 외에 해이즈(Hayes), 소와(J. Sowa) 등이 비교적 초창기에

콰인의 의미에 충실하게 ‘온톨로지’란 용어를 사용하 다.

그러나 그 후 ‘온톨로지’란 용어가 점차 전산학 분야에서 유행하기 시작하면서,

사람마다 이것을 조금씩 다르게 사용하 고, 그 결과 온톨로지의 개념에 관한 혼란

이 극심해졌다. 이에 그루버(Gruber, 1993)는 온톨로지를 “ An ontology is a

specification of a conceptualization)”라 정의했고, 이 정의는 비교적 널리 받아

3

들여진다. 여기서 conceptualization은 온톨로지와 달리 언어 독립적(language-

independent)인 개념이다. 따라서 두 개의 다른 온톨로지가 하나의 동일한

conceptualization을 공유하는 일도 생길 수 있다. 그럼에도 불구하고 문제는 이번

에는 “specification’과 ‘conceptualization’을 모든 사람들이 동일한 의미로

사용하지 않는다는 점이다.

이런 혼란의 해소하기 위해 구아리노는 ‘ 온톨로지 ’ , ‘ ontological

commitment’, ‘conceptualization’에 관해 다시 매우 엄밀한 형식적 정의를 제

시한 바 있지만, 웰티(C. Welty) 등의 보고에 의하면 소위 ‘온톨로지’로 분류되

는 많은 것들이 <그림 2.1>과 같이 매우 넓은 스펙트럼 내에 병존하고 있다고 한

다.

<그림 2. 1> 온톨로지의 분류

제2 절 온톨로지의 종류, 응용

지금까지 살펴본 바와 같이 ‘온톨로지’라는 용어에 관해서는 여전히 혼란이 계

속되고 있지만, 그럼에도 불구하고 지금까지의 논의는 온톨로지 개념을 정립하기

위한 기초적인 자료들을 적절한 수준에서 제공하고 있다고 본다. 전산학, 혹은 인공

지능의 관점에서 볼 때, 온톨로지는 어쨌든 공학적인 구조물이라는 점을 먼저 이야

기할 수 있다. 그리고 이 구조물은 어떤 실체(certain reality)를 기술하기 위한 특

정한 어휘들로 구성되어 있으며, 여기에 그러한 어휘들이 갖는 의도된 의미

(intended meaning)에 관한 명시적인 가정들의 집합이 추가된다. 흔히 이 가정들

의 집합은 어떤 일차-술어 논리 이론의 형태로, 어휘들은 1항 혹은 2항 술어로 주

어진다. 가장 간단한 경우의 온톨로지는 포함(subsumption) 관계로 연결된 개념들

4

의 어떤 위계 구조를 기술하며, 보다 복잡한 경우에는 여기에 기타 다른 관계나 제

약을 표현하기 위한 공리들이 더해진다. 이상은 온톨로지 개념에 관한 구아리노

(Guarino, 1998)의 설명을 요약한 것이다.

<그림 2. 2> 온톨로지의 종류

온톨로지는 포함하고 있는 개념들의 일반성의 수준에 따라 다음 페이지의 <그림

2.2>와 같이 보통 3 가지로 나뉘어진다. Top-level 온톨로지는 시간, 공간, 물질,

대상, 사건 등 구체적인 문제나 특정 도메인과 무관한, 매우 일반적인 개념들을 기

술한다. 이에 반해 도메인 온톨로지, 응용 온톨로지는 보다 한정된 역으로 관심의

폭을 좁힌다. <그림 2.3>은 소와(Sowa)가 제안한 top-level 온톨로지를 나타내고

있다.

온톨로지의 주요 응용 분야로는 시맨틱 웹, NLP에서의 의미론 처리, 지식 경 ,

e-비즈니스 등이 있다. 이 외에 전자도서관, Multi-Db 시스템, 정보 추출, 정보 통

합, 지능적 에이전트, 기계 학습, 데이터/텍스트 마이닝, HCI 등에서도 연구가 진행

되고 있다.

<그림 2. 3> Sowa 의 Top-Level 온톨로지

5

제 3 절 웹 온톨로지 언어의 개요

1. RDF(Resource Description Framework)

RDF는 W3C에서 발표한 메타데이터의 기술과 교환을 위한 표준이다. RDF는

다양한 메타데이터간의 상호운용을 위해 의미(semantics), 구조(structure) 및

구문(syntax)에 대한 공통적인 규칙을 제공한다. RDF의 출현은 사람들에게 많은

의문을 던져주고 있다. RDF가 왜 필요하고, 어떻게 사용할 수 있을까? 이에

대한 답은 상호운용이란 말부터 실마리를 풀 수 있다. 굳이 시맨틱 웹이나

온톨로지 분야를 언급하지 않아도 이 말은 매우 폭넓게 사용되고 있다.

상호운용은 서로 다른 객체 사이에서 특별한 노력 없이 동작할 수 있는 것을

말한다. IT 환경에서 상호운용에 대한 관심은 역시 월드와이드웹에서 원인을 찾을

수 있다. 월드와이드웹의 폭발적 성장은 데이터의 양적 증가도 불러 일으켰다.

이런 환경에서 사람들은 끊임없이 데이터를 공유하기 위해 힘써왔는데, 그 노력의

일환이 메타데이터이다. 메타데이터는 자원의 내용을 일정한 규칙에

따라(표준화된 방법으로) 기술할 수 있는 틀이 될 수 있다. 그러나 목적에 따라

다른 메타데이터 구문과 스키마 정의 언어가 달라 이 또한 효과를 장담할 수

없었다. 즉 개발단체 사이의 합의가 존재하지 않는 한 상호운용성을 보장할 수

없다. RDF는 이러한 문제를 해결하는데 주된 목적을 갖고 있다. RDF는 데이터

모형을 이용하여 메타데이터 스키마를 일관된 방법으로 표현한다. 다시 말해,

다양한 특성을 갖는 메타데이터 스키마가 있을 때, RDF는 이것들을 표현할 수

있는 추상적 모형을 제공하고, 컴퓨터가 처리 가능하도록 XML을 이용하여

구현한다(그림 2.4 참고).

<그림 2. 4> RDF, XML, 메타데이터의 관계

본 장에서는 RDF에 대한 소개와 활용 방법을 설명한다. 먼저 RDF의 데이터

모형이 무엇인지 살펴보고, 구체적인 문법을 소개한다.

ᄋ RDF 데이터 모형

RDF는 자원을 기술하기 위한 모형을 제공한다. RDF 데이터 모형은 기술하는

6

자원의 속성과 자원간의 관계를 표현한다. 데이터 모형에 기술되는 내용들은

문법적으로 다를 수 있지만, RDF 파서(parser)에 의해 동일한 의미로 처리된다.

즉 문법에 중립적이다. RDF 데이터 모형은 자원(resource), 속성타입(property

type), 진술문(statements)으로 구성된다.

- 자원 : URI1(Universal Resource Identifier)로 기술되는 모든 객체를 말한다.

URI는 어떤 객체를 인식하기 위한 수단인데, 대상이 웹 자원에 한정되지

않는다. 즉 URI는 특정한 웹 페이지가 될 수도 있지만, 오프라인에 있는

책상이 될 수도 있다. 우리가 알고 있는 URL(Uniform Resource Location)은

URI의 부분집합이라 할 수 있다. 다시 말해, 자원의 범위는 웹 자원(URL로

표현되는)에 한정되지 않는다. 실 세계에 존재하는 모든 객체는 자원으로

표현할 수 있다. 하나의 자원은 여러 개의 속성 유형과 속성값을 포함할 수

있다. 예컨대 ‘http://www.ontology.or.kr/default.html’은 URL로 표현된

자원이라 할 수 있다.

- 속성 유형 : 자원의 속성명을 의미한다. 속성명은 ‘저자명’ 또는 ‘파일

형식’ 등과 같이 특정 자원의 속성에 대해 적절한 이름을 부여하는 것이다.

RDF에서 기술(description)은 동일한 자원을 참조하는 속성들의 집합을

말한다. 속성값은 다른 자원 혹은 문자열이나 숫자와 같은 원자형(atomic)일

수 있다.

- 진술문 : 특정 자원을 기술하기 위해 지정된 속성과 속성값을 의미한다. 이

진술문은 주어(subject), 서술어(predicate), 목적어(object)로 구성된다.

진술문의 목적어는 어떤 자원이나 리터럴이 되기도 한다.

RDF 데이터 모형은 트리플(triples), 그래프, XML을 이용하여 표현할 수 있다. 이

들 표현 방식은 대등한 의미를 갖는다. 간단한 예를 생각해 보자. 이 예는 RDF를

소개할 때 사용되는 가장 기본적인 것이다.

자원 http://www.ontology.or.kr의 작성자는 홍길동이다.

위 진술문은 다음과 같은 요소로 구성되고

1 ftp://ftp.isi.edu/in-notes/rfc1630.txt

7

주어(subject) [http://www.ontology.or.kr]

서술어

(predicate)

작성자

목적어(object) 홍길동

트리플을 이용하여 다음과 같이 표현한다.

{작성자, [http://www.ontology.or.kr], “홍길동”}

여기서 기호 [/]는 URI에 의해 식별되는 자원을 의미하고, 인용부호는 리터럴을 의

미한다. 또, RDF는 유향 그래프(directed graph, digraph)를 기반으로 자원을 기술

할 수 있다(<그림 2.5> 참조)

<그림 2. 5> 이용한 자원 기술의 예

그래프란 두 개의 유한 집합, 즉 정점(vertex)들의 집합과 간선(edge)들의 집합으

로 이루어진 구조를 말한다. 예컨대, 간선 ei는 정점 vj로부터 정점 vk로의 간선이

된다.

ei=(vj, vk)

이 때, vj를 간선의 시작점(initial vertex), 정점 vk를 종착점(terminal vertex)이라

고 부른다. 이와 같은 구조는 간선에 방향을 지정하기 때문에 이를 유향그래프라고

한다. 또 그래프를 구성하는 요소인, 정점과 간선에 라벨(label)을 붙일 수 있는데,

이러한 그래프를 라벨(labeled graph)라 한다. 그래프는 다이어그램으로 편리하게

도식화할 수 있다. 여기서 정점은 원으로, 리터럴은 사각형으로, 그리고 간선은 두

정점들을 잇는 화살표로 표현된다. 주의할 점은 화살표의 방향이다. 그래프에서 화

살표는 항상 주어에서 시작하여 목적어를 지시해야 한다. 따라서 <그림 2.5>는 다

음과 같이 해석할 수 있다.

- 홍길동은 자원 http://www.ontology.or.kr의 값이다.

- 자원 http://www.ontology.or.kr는 홍길동과 같은 값을 가진 속성 작성자를

갖고 있다.

8

2. OWL

웹 온톨로지 언어(OWL2: Web Ontology Language)는 웹에서 정보를 표현하고 애

플리케이션이 직접 내용을 처리할 수 있도록 설계된 언어이다. OWL은 기계 또는

에이전트가 처리할 수 있는 풍부한 어휘(vocabulary)와 형식적 의미(formal

semantics)를 제공한다. 따라서 어떤 용어의 의미와 용어 사이의 관계를 명시적으

로 표현할 수 있다. OWL은 XML, RDF, RDF 스키마보다 풍부한 의미 표현이 가능

하기 때문에 웹에서 기계가 컨텐츠를 해석하기가 용이하다. OWL은 RDF와 DAML,

OIL의 향을 받았으며, DAML+OIL로부터 파생되었다.

<그림 2. 6> 웹 온톨로지 언어의 발전 단계

ᄋ 웹 온톨로지 언어의 종류

OWL은 표현력이 서로 다른 세 개의 하위 언어로 구성된다.

OWL Lite는 클래스의 계층과 간단한 제약 사항만을 제공하고 있다. 따라서 다른

하위 언어보다 표현력의 제한이 많다. 예컨대 관계차수 제약이 가능하지만, 차수의

값은 0 또는 1만을 사용할 수 있다. OWL Lite는 이론적 복잡도가 낮기 때문에 다

른 분류체계나 시소러스를 빠르게 OWL로 변화하는데 적합하다.

OWL DL은 기술논리(Description Logic)에 기반한 언어이다. 기술논리는 OWL의

형식적 기반이 된 논리학의 한 분야이다. OWL DL은 계산적 완전성과 결정 가능성

2 웹 온톨로지 언어의 정식 명칭은 WOL이 될 수 있었으나, 개발에 참여한 사람들에 의해

OWL(아울)로 표기하기로 결정하였음.

9

을 유지하면서 최대의 표현력을 제공한다. 계산적 완전성은 모든 결론이 계산될 수

있다는 특성이고, 결정 가능성은 모든 계산이 유한한 시간내에 끝난다는 것을 말한

다. OWL DL은 OWL에서 정의한 모든 어휘를 포함하고 있다. 그러나 어휘를 사용

할 때 정해진 제약 사항에 따라야 한다. 예컨대 클래스는 다른 클래스의 하위클래

스로 선언할 수 있지만, 다른 클래스의 인스턴스로 선언할 수 없다.

OWL

Full OWL DL OWL Lite

명세서에

포함된 모

든 기능

지원

　 사용이 제한된 속성

- FunctionalProperty

- InverseFunctionalProperty

- owl:cardinality

　 메타클래스 사용 불가

　 OWL Full 온톨로지의 import 불가

　 사용이 제한된 속성

- owl:minCardinality

- owl:maxCardinality

- owl:cardinality는 0과 1만 사용 가능

- owl:hasValue

- owl:disjointWith

- owl:oneOf

- owl:complementOf

- owl:unionOf

OWL Full은 RDF의 모든 문법을 사용할 수 있으며 최대의 표현력을 제공한다. 단,

계산적 보장은 하지 않는다. OWL Full은 DL과 Lite의 모든 기능을 포함하는 관계

이며[<그림 2.7> 참고], 유효성과 호환성은 하위 언어중에 가장 완벽하다. 그러나

OWL Full을 지원하는 추론엔진을 개발하는 것은 쉽지 않다.

<그림 2. 7> OWL 언어의 종류

10

OWL 하위 언어들은 그림과 같은 포함 관계를 갖는다. 즉 OWL DL은 OWL Lite의

확장이고, OWL Full은 OWL DL의 확장 언어이다. 각 하위 언어 사이에는 다음과

같은 관계가 성립한다. 반면 그 역은 성립하지 않는다.

- 모두 올바른 OWL Lite 온톨로지는 올바른 OWL DL 온톨로지이다.

- 모두 올바른 OWL DL 온톨로지는 올바른 OWL Full 온톨로지이다.

- 모두 타당한 OWL Lite 의 결론은 타당한 OWL DL 결론이다.

- 모두 타당한 OWL Dl 의 결론은 타당한 OWL Full 결론이다.

OWL을 이용하려면 먼저 어떤 OWL 하위 언어가 주어진 요구 사항에 최적인지 결

정해야 한다. OWL Lite와 OWL DL 중 어떤 언어를 사용할 지 판단하는 기준은

OWL Lite보다 풍부한 OWL DL의 표현력을 필요로 하는가의 여부이다. OWL DL과

OWL Full 사이의 판단 기준은 RDF 스키마가 제공하는 메타 모델 구축 기능(예를

들어, 클래스의 클래스를 정의하거나 클래스에 속성을 매다는 등)을 필요로 하는가

의 여부이다. OWL Full을 이용하면 (OWL DL과 달리) 추론 기능 지원을 보장 받

을 수 없다. 아직까지 OWL Full을 완전하게 지원하는 추론 시스템은 구현된 바가

없기 때문이다.

11

제 3장. 온톨로지 구축을 위한 방법론

온톨로지를 개발하는 것은 쉬운 일이 아니다. 일반적인 데이터 모델링과 같이, 온

톨로지 모델링도 풍부한 경험과 폭 넓은 지식을 요구한다. 어떤 사람은 온톨로지

모델링의 어려움을 표현하기 위해 이것이 기술(technology)이라기 보다 예술(art)

적 차원이라고 한다. 이런 이유는 모델링의 난이도가 높고, 동시에 이를 위한 어떤

방법이 정립되어 있지 않기 때문이다. 온톨로지 개발에 관련된 기술은 실용적 목적

에서 볼 때 충분히 성숙되어 있지 않다. 그러나 이와 관련된 선행 연구는 찾아볼

수 있다. 예컨대, Cyc나 Uschold이 제안한 방법은 밑그림을 그려가며 순서적으로

온톨로지를 구축하는 방법을 제공한다. Methontology나 OTKM은 단계적 접근 방

법에 기반하여 통합 개발 환경을 제공한다. 반면 다른 온톨로지를 변환하여 구성하

는 방법이 있다. 이러한 방법에는 온톨로지 재공학(reengineering)이나 온톨로지

병합(merging)과 같은 방법이 사용된다. 온톨로지 구축 과정에는 다양한 세부 활

동을 포함하게 된다. 방법론은 이러한 요구사항을 포괄적이고 통합된 형태로 구성

한 것이다.

이번 장은 위에 설명한 것 중에 밑그림이나 재사용을 통한 온톨로지 구축 방법을

설명한다. 현존하는 방법론은 대부분 응용 프로그램을 활용하는데, 응용 프로그램에

대한 소개는 다른 장에서 설명하도록 한다.

제 1절 Cyc

Cyc 프로젝트는 Lenat를 중심으로 Cyc 지식 베이스 개발의 경험에서 기인했다.

Lenat가 설립한Cycorp 사는 MCC 연구 컨소시엄의 지원을 받아 최근까지 50만

개의 공리를 지식베이스에 저장하고 있다. Cyc 지식 베이스는 지식 베이스 구축 분

야에서 상징적인 의미를 갖고 있다. 이것은 코드화된 상당한 양의 지식을 포함하고

있다. Cyc 지식 베이스에 정의된 지식은 복잡하지 않은 상식에 관련된 것들이다.

예컨대, 지식의 형태는 "첫 데이트" 혹은 "사람들은 보통 첫 데이트 때에는 점잖은

태도를 보인다"와 같은 것들이다.

이 지식 베이스는 3백만 개의 기초 규칙과 30만개의 개념이 저장되어 있다. 이를

이용하면 다음과 같은 추론이 가능하다. “어떤 사람이 목이 마르다.”는 사실이 있

으면 “물을 제공할 것”이라는 규칙을 찾아낸다. Cyc 온톨로지를 개발하는 것은 3

단계로 구분된다. <그림 3.1>은 온톨로지 개발 단계를 간략하게 표현하고 있다.

1 단계는 지식의 표현 또는 코드화를 수행한다. 온톨로지 공학자는 명시적 또는

암묵적 지식을 수작업으로 표현하게 된다. 지식은 전문가, 사전, 명세서와 같은 다

양한 자료원에서 추출될 수 있다. 2 단계는 지식을 성문화((knowledge

12

codification )하는 단계이다. 지식의 재활용이 가능할 때, 지식의 정보적 표현은 코

드화(code)라고 말하며, 이러한 표현의 과정은 지식 성문화(knowledge

codification)라고 한다. 이 단계에서 Cyc 지식 베이스에 지식을 저장하며, 이때 응

용 프로그램을 이용하여 지식을 성문화한다. 마지막 단계는 응용 프로그램을 통한

지식의 추천을 수행한다. 사용자가 특정한 지식을 요구했을 때, 지식 베이스에서 적

합한 지식을 추천하게 된다.

<그림 3. 1> Cyc 방법론

Cyc는 실험 기간 동안 HPKB(High Performance Knowledge Bases)에서 사용

되었다. 이것은 컴퓨터가 어떻게 지식을 획득하고, 표현하며, 조작할 수 있는 기술

을 향상시키기 위한 목적의 연구 프로그램이다. 최근까지 이 방법론은 Cyc 지식

베이스를 구축하는데 활용되고 있다.

현재 Cycorp는 오픈 싸이크 프로젝트(www.opencyc.org)를 통해 지식 베이스

를 공개하고 있다. 이 프로젝트는 Cyc 기술의 공개 버전으로, 6000개 이상의 개념

과 이와 관련된 60000개 이상의 명제들을 포함하고 있다. 또한 온톨로지를 개발하

는데 유용한 다양한 도구를 제공하고 있다. 현재 발표된 버전에 포함된 내용은 다

음과 같다.

- Cyc 추론 엔진과 Cyc 지식 베이스 브라우저

- 도메인 전문가로부터 지식을 추출하기 위한 RKF 도구들

- CycL 명세서와 Cyc API

13

<그림 3. 2> OpenCyc

제 2절 Uschold & King의 방법론

Mike Uschold와 Edinburgh 대학의 AIAI(Artificial Intelligence Application

Institute)에서 개발한 이 방법은 기업의 모델링 프로세스를 위한 온톨로지인 기업

온톨로지(Enterprise Ontology)를 구축하는데 목적을 갖고 있었다. 기업 온톨로지

는 비즈니스 기업과 관련된 용어(terms)와 정의들(definitions)의 집합이다. 이것

은 온톨로지를 실제 활용할 수 있는 형태로 구축한 정교한 방법론으로 평가 받고

있다. 기업 온톨로지의 목적은 다음과 같이 요약할 수 있다.

- 통합된 어휘를 이용한 원활한 의사교환 보장 : 비즈니스 당사자 사이에

서 기업 모형(enterprise model)에 대한 통합된 이해를 위한 어휘 제공

- 안정된 인프라 제공 : 기업 모형의 요구사항에 대한 변경의 최적화

- 정보 교환의 매개체 역할 : 기업 모형을 이용하는 다양한 응용 프로그램

의 상호운용성 증대

개념적으로 기업 온톨로지는 여러 개의 주요 부분으로 구분된다. <표 3.1>는 기업

온톨로지에 포함된 일반적 개념을 보여주고 있다.

14

활동

(Activity)

Activity Specification, Execute, Executed Activity

Specification, T-Begin, T-End, Pre-Conditions, Effect, Doer,

Sub-Activity, Authority, Activity Owner, Event, Plan, Sub-

Plan, Planning, Process Specification, Capability, Skill,

Resource, Resource Allocation, Resource Substitute.

조직

(organization)

Person, Machine, Corporation, Partnership, Partner, Legal

Entity, Organisational Unit, Manage, Delegate, Management

Link, Legal Ownership, Non-Legal Ownership, Ownership,

Owner, Asset, Stakeholder, Employment Contract, Share,

Share Holder.

전략

(strategy)

Purpose, Hold Purpose, Intended Purpose, Strategic Purpose,

Objective, vision, Mission, Goal, Help Achieve, Strategy,

Strategic Planning, Strategic Action, Decision, Assumption,

Critical Assumption, Non-Critical Assumption, Influence

Factor, Critical Influence Factor, Non-Critical Influence

Factor, Critical Success Factor, Risk.

마케팅

(marketing)

Sale, Potential Sale, For Sale, Sale Offer, Vendor, Actual

Customer, Potential Customer, Customer, Reseller, Product,

Asking Price, Sale Price, Market, Segmentation Variable,

Market Segment, Market Research, Brand Image, Feature,

Need, Market Need, Promotion, Competitor.

시간(time) Time Line, Time Interval, Time Point.

<표 3.1> 기업 온톨로지에 정의된 용어들

기업 온톨로지 방법론은 온톨로지를 개발하기 위해 다음과 같은 안내 지침을 제공

한다.

① 목표의 구체화 : 온톨로지를 개발하려는 목표와 사용 목적에 대한 명확한 정의

② 온톨로지 구축 : 이 단계는 다음의 3 가지 하위 프로세스로 구분

- 온톨로지 획득 : 범위 설정, 도메인의 핵심 개념과 관계 추출

- 코딩 : 전 단계에서 얻은 지식을 형식 언어를 이용하여 명시적으로 표현

- 기존의 온톨로지와 통합 : 온톨로지 획득과 코딩 단계에서 기존에 존재

하는 온톨로지의 사용 방안 결정

③ 평가 : 온톨로지의 기술적 판단을 위한 정의 선택

④ 문서화 : 온톨로지 사용을 위한 안내 지침 작성

15

엔터프라이즈 툴셋(Enterprise Toolset)은 기업 온톨로지를 이용하기 위해 개발된

응용 프로그램이다. 이것은 기존에 개발된 프로그램에 플러그&플래그 형태로 통합

시키기 위해 에이전트 기반의 아키텍처를 사용한다. 엔터프라이즈 툴셋은 다음과

같은 구성 요소를 갖는다.

- 프로세스 빌더(Process Builder) : 프로세스 모델의 획득

- 에이전트 툴킷(Agent Toolkit) : 에이전트 개발 지원

- 작업 관리자(Task Manager) : 프로세스의 통합과 시각화, 프로세스 제정 지원

- 기업 온톨로지(Enterprise Ontology) : 기업 모형의 원활한 의사교환

제 3절 Gruninger & Fox 방법론

1. 개요

이 방법론은 TOVE 프로젝트 온톨로지를 개발하는 경험에서 기인했다.

TOVE(Toronto Virtual Enterprise) 프로젝트의 목표는 비즈니스 환경에서 기업의

다양한 기능을 지원하는데 있다. 구체적인 목표를 요약하면 다음과 같다.

- 공유 가능한 용어 제공 : 에이전트가 서로 사용하고 이해 가능한 용어 또는

어휘집

- 용어에 대한 의미 정의 : 용어에 대한 정확한 의미와 사용 방법

- 도식화된 문맥에서 개념이나 용어를 나타내는 기호론(symbology) 정의

TOVE는 연구 프로젝트인 동시에 시범운 의 성격을 갖고 있다. 이를 위해 가상

기업(virtual company)을 구현하여 활용하고 있다. 이것은 기업 통합과 관련된 연

구를 수행하기 위한 시범운 을 제공하는데 목적이 있다. TOVE는 카네기 그룹

(Carnegie Group)에서 지식 표현 도구인 ROCK@+[TM]을 이용하여 C++로 구

현되었다.

TOVE 시스템의 핵심은 상식적인 지식을 표현한 기업 모형에 있다. 이것은 기업

지식을 재사용 가능한 형태의 집합으로 제공한다. 일반적으로 기업 모형은 프로세

스, 활동, 시간, 인과관계, 자원, 품질, 비용에 대한 지식 표현을 포함하고 있다. 또

한 기업 모형은 기업에 존재하는 다양한 관점들과의 관계도 제대로 정의하고 있어

야 한다. 따라서 기업 시스템은 기업 모형을 포함하여 구축되고, 시스템의 모든 구

성요소들은 기업 모형을 통해 용어와 제약조건을 공유하게 된다. TOVE는 이를 위

한 효율성, 품질, 비용 측면을 기업 모형에서 고려하고 있다.

프로젝트가 진행되는 동안 기업 모형과 관련된 많은 결과가 도출되었다. 예컨대

조직의 행위에 관련된 활동, 상태, 인과 관계, 시간에 대한 온톨로지를 구축하 다.

또 구체적인 사물에 대한 지식 표현도 함께 수행되어 자원, 재고, 주문, 제품에 대

16

한 온톨로지가 구축되었다.

2. 방법론

TOVE 방법론은 다음과 같은 절차에 의해 수행된다.

2.1 시나리오 작성 : Gruninger와 Fox에 따르면, 온톨로지 개발은 응용 역에

서 제기된 시나리오를 통해 진행된다.

2.2 비정형적 적격 질의를 위한 공식화

2.3 형식언어로 온톨로지 어휘의 명세화

2.4 온톨로지 어휘를 이용한 정형적 적격질의의 공식화

2.5 형식언어로 온톨로지 어휘와 공리를 명세화

2.6 온톨로지의 완전성을 구체화하기 위한 조건 추가

제 4절 KACTUS

1. 개요

Bernaras와 팀원들이 개발한 이 방법은 Esprit 8145 KACTUS(modeling

Knowledge About Complex Technical systems for multiple USe) 프로젝트를 수

행한 경험에 기초하고 있다. Esprit 8145 KACTUS의 목표는 복잡한 시스템에서

지식 재사용성에 대한 타당성을 연구하고, 이를 위한 온톨로지의 역할이 무엇인지

찾는데 있다.

이 방법에서 온톨로지 개발은 애플리케이션 개발에 달려 있다. 즉, 언제나 애플

리케이션이 구축된 후, 애플리케이션에서 요구하는 지식을 표현한 온톨로지가 수정

된다. 이 온톨로지는 다른 온톨로지를 재사용하여 개발될 수 있고, 다른 애플리케이

션의 온톨로지와 통합될 수도 있다. 따라서 언제나 애플리케이션이 개발되고, 그 후

단계로 온톨로지를 개발하게 된다.

2. 방법론

KACTUS 방법에 의한 온톨로지 개발은 다음의 절차를 따른다.

2.1 애플리케이션의 명세화

이 단계는 애플리케이션이 수행한 업무와 모형화시킬 요소들을 정의한다.

2.2 최상위 온톨로지 분류에 근거한 예비 설계

2.3 온톨로지 정제와 구조화

온톨로지 정제와 구조화는 모듈화(modularization)와 계층적 조직화

(hierarchical organization) 원칙에 따라 최종적인 설계(definitive)를 하기 위한

17

과정이다.

제 5절 METHONTOLOGY

1. 개요

이 방법론은 AIU(Artificial Intelligence at Universidad Politecnice)의 연구실

에서 개발했다. METHONTOLOGY는 소프트웨어 공학과 지식 공학 분야의 방법론

에서 많은 향을 받아, 온톨로지 개발에 있어서도 포괄적인 방법론을 제공한다. 여

기서 “포괄적”이란 말은 온톨로지 개발의 모든 단계에 필요한 요소 기술을 제공

함을 말한다. METHONTOLOGY는 온톨로지 개발을 위한 프로세스, 점진적

(evolving) 프로토타입 기반의 생명주기, 각 단계에 필요한 특정 기술 등을 포함하

고 있다. 아울러 WebODE와 ODE를 이용한 개발이 가능하다.

METHONTOLOGY는 온톨로지 개발 환경을 위한 생명주기(lifecycle) 모형을

지향하고 있다. 생명주기 모형은 개발 과정에서 반드시 수행해야 하는 활동들의 순

서 집합이라 할 수 있다. 일반적으로 소프트웨어 공학에서 생명주기 모형은 계획,

분석, 설계, 구현, 검사, 운용 및 유지보수 등의 단계로 구분된다.

METHONTOLOGY는 이를 바탕으로 온톨로지 구축 절차를 다음과 같이 정의하고

있다: 명세화(specification), 개념화(conceptualization), 형식화(formalization),

통합화(integration), 구현(implementation), 관리(maintenance). 이에 대한 구체

적인 설명은 다음 절에서 한다.

앞서 언급한 대로 METHONTOLOGY는 온톨로지 개발에 있어 프로토타이핑 기

법을 사용한다. 프로토타이핑이란 점진적 접근법이라 할 수 있는데, 제한된 범위에

서 시행착오를 반복하여 온톨로지를 만들어 가는 과정이다. 이를 통해 온톨로지 개

발자는 요구사항을 단순화하여 온톨로지를 구축할 수 있다. 프로토타입 기법은 구

현 방식에 따라 수평적(horizontal) 프로토타입과 수평적(vertical) 프로토타입으로

구분된다. 전자는 모든 업무 기능에 대해 부분적으로 구현하는 것을 말하고, 후자는

업무를 부분적으로 구분하여 한 개 또는 일부를 모두 구현하는 것을 말한다. 일반

적으로 이런 것들은 요구사항을 수렴한 후 폐기하지만, 이 방법론에서는 프로토타

입을 연결하여 온톨로지를 완성하는 방식을 사용한다. <그림 3.3>은

METHONTOLOGY의 개발 과정과 전체 생명주기를 설명하고 있다. 개발 과정은

크게 유지관리 활동, 개발 활동, 지원 활동으로 구분된다. 이 방법론은 전체 개발

과정을 수평적 프로토타입으로 기법을 이용하고 있다. 반면 온톨로지 개발 과정은

수직적 프로토타입 기법을 이용한다. 즉 명세화부터 유지관리까지의 절차는 다른

활동과 유기적인 관계를 맺어 진행되지만, 각 단계는 단계별 요구사항에 맞는 결과

를 산출하게 된다.

18

<그림 3. 3> METHONTOLOGY 방법론의 프로세스

2. 방법론

METHONTOLOGY는 온톨로지 개발 단계를 명세화(specification), 개념화

(conceptualization), 형식화(formalization), 통합화(integration), 구현

(implementation), 관리(maintenance) 등으로 구분하고 있다. 이제 각 단계에서

정의하고 있는 것들을 상세히 살펴보자.

2.1 명세화(specification)

이 단계는 온톨로지를 개발하기 위한 사전 단계라 할 수 있다. 이 때 고객이 무

엇을 원하는지, 온톨로지 설계를 위한 기초적인 질의는 어떻게 구성하는지, 마지막

으로 구축되었을 때 검증해야 할 요구사항에 무엇을 포함시킬지를 정의하게 된다.

명세화 단계는 다음과 같은 내용을 포함하고 있다.

- 온톨로지의 사용 목적

- 온톨로지의 구축 범위

- 온톨로지의 정형성 단계

- 잠재 사용자

이 단계는 지식 획득 활동과 병행하여 진행된다. 지식 획득은 온톨로지 개발을

위해 요구되는 지식을 뽑아 내기 위해 필요한데, 다양한 지식 원천으로부터 얻을

수 있다. 예컨대, 전문가 그룹, 편람, 다른 온톨로지는 요구 목적을 얻기 위한 기본

적인 자료원이 될 수 있다. 이를 위해 브레인스토밍, 인터뷰, 질문지와 같은 방법을

사용할 수 있고, 지식 획득 도구나 텍스트 분석 도구를 이용한 반자동적인 방법을

19

활용할 수 있다.

명세화 단계에서 진행되는 작업은 <그림 3.4>와 같은 명세화 문서를 통해 요약

된다.

<그림 3. 4> 명세화 문서의 예

2.2 개념화(conceptualization)

개념(concept)이란 무엇인가? 아마도 군대 경험이 있는 남자라면 한 번쯤 “너,

참 개념 없다”라는 말을 들어 봤을 것이다. 그 말을 들었을 때 기분은 아마도 다

시 생각하고 싶지 않을 것이다. 여기서 개념이란 사전적으로 어떤 사물에 대한 일

반적이고 본질적인 지식이나 관념을 말한다. 즉 사물이나 현상에 대한 일반적 지식

을 말하는데, “개념 없다” 라는 말은 그것에 대한 지식이 없음을 의미한다. 예컨

대, “한국은 월드컵에서 4강에 올랐다”라는 것부터 “한국의 축구 실력은 뛰어나

다”로 일반화할 수 있다. 일반화는 현상에 대한 원리를 추출하기 위한 과정이고,

먼저 그 개념의 특성을 이해해야 한다. 즉, “축구 실력이 뛰어나다”라고 일반화하

기 위해 “월드컵”, “4강”이라는 개념을 먼저 이해해야 한다. 이를 위해 개념화

가 필요하다.

개념화란 일정한 현상이나 사물이 갖고 있는 공통적인 속성을 추출해 그것들을

대표할 수 있는 포괄적인 개념을 이끌어 내는 것이다. 달리기, 윗몸 일으키기, 매달

리기와 같은 개념에서 공통적인 속성으로 운동이란 특징을 추출해 내고, 이로부터

이것들을 “운동”이라고 개념화한다. 즉 앞서 열거한 개념들은 “운동”이라는 개

념에 포섭되는 종개념들이다.

개념화는 특정 단계의 산물(product)이라기 보다 과정(process)이라고 말할 수

있다. 온톨로지 개발에 있어 개념화도 이와 같은 맥락을 유지한다.

METHONTOLOGY에서 개념화를 위한 절차는 <그림 3.5>와 같다.

20

<그림 3. 5> 개념화 단계별 작업

먼저 1단계는 용어들의 사전을 만든다. 이 때 용어 사전에는 도메인에 속하는 모

든 형태가 포함될 수 있다. 즉 개념, 인스턴스, 속성, 동사 등 어떤 형태도 용어 사

전에 포함할 수 있다. <그림 3.6>은 용어 사전의 간단한 예이다.

다음 단계에서는 용어 사전에 정리된 용어들을 이용하여 개념 분류 트리

(Concept Classification Tree)를 작성한다. 개념 분류 트리는 용어 사전에 포함된

것들의 임시적인 관계를 정의하기 위한 것으로, 서브클래스 관계, 서로소 관계 등을

이용하여 개념 사이의 관계를 표현한다. <그림 3.7>은 개념 분류 트리를 이용하여

항공기에 대한 용어를 구분한 것이다.

21

<그림 3. 6> 용어사전의 예

<그림 3. 7> 항공기에 대한 개념 분류 트리

22

개념 분류 트리는 동일하거나 서로 다른 온톨로지에 있는 개념 사이에 관계를 표

현하는데 목적을 갖고 있다. <그림 3.7>은 항공기에 대한 서브 클래스 관계, 분할

관계, 여행 패키지에 대한 구분 정보를 표현하고 있다. 개념화의 나머지 작업들은

위에 있는 다이어그램과 용어 사전을 기반으로 진행되게 된다. METHONTOLOGY

에서 정의하고 있는 단계별 산출물은 다음과 같다.

- 개념 사전(Concept Dictionary)

- 이진 관계 테이블(table of binary relations)

- 인스턴스 속성 테이블(Instance Attribute Table)

- 클래스 속성 테이블(Class Attribute Table)

- 논리적 공리 테이블(Logical Axioms Table)

- 상수 테이블(Constants Table)

- 속성 분류 트리(Attribute Classification Trees)

- 인스턴스 테이블(Instance Table)

위에 열거한 산출물은 순서를 갖거나 반드시 작성해야 할 요소는 아니다. 온톨로

지 구축자는 요구 사항에 맞는 필요한 형식을 선택하여 사용하면 된다.

METHONTOLOGY에서 권장하는 형식은 개념 사전, 인스턴스 속성 테이블, 클래

스 속성 테이블, 논리적 공리 테이블이 있다. 먼저 개념 사전은 구축하려는 도메인

에 포함되는 모든 개념을 표현하는데 목적이 있다. 이 형식에는 개념의 인스턴스,

개념의 클래스/인스턴스 속성, 개념 사이의 관계, 동의어, 유의어 등이 포함되게 된

다. <그림 3.8>은 개념 사전의 예이다.

<그림 3. 8> 개념 사전

23

클래스 속성 테이블은 개념 사전에 표현한 클래스 속성을 구체적으로 기술한다.

클래스 속성은 개념의 인스턴스가 아닌 개념 자체를 기술한다. 따라서 이 형식은

개념명, 가능한 값 형식, 숫자형 값의 측정 단위, 값의 정확성과 같은 정보가 포함

된다.

<그림 3. 9> 클래스 속성 테이블

인스턴스 속성 테이블은 개념 사전에 표현한 인스턴스 속성을 좀 더 구체적으로

기술하기 위한 형식이다. 이 테이블에 표현한 인스턴스 속성은 개념에 대한 속성임

과 동시에 인스턴스의 속성으로 선언된다. 아울러 속성의 값을 함께 정의한다. <그

림 3.9>는 인스턴스 속성 테이블의 예이다. 예컨대, 인스턴스 속성명인 “size”는

개념명이 “ Location ” 이다. 이것은 개념 사전에 이미 정의되어 있다. 반면

“size”의 값 형식이 “Integer”이고, 측정 단위가 “Square Meters”로 정의되

어 있다. 즉 속성의 구체적인 값을 정의하고 있다.

<그림 3. 10> 인스턴스 속성 테이블

24

논리적 공리 테이블은 논리적 표현식으로 개념을 정의하기 위해 사용된다. 각각

의 공리는 공리 이름, 자연어 표현, 공리를 참조하고 있는 개념, 공리에서 사용하는

속성에 대한 정보를 포함하고 있다. <그림 3.11>은 공리 테이블의 예이다.

<그림 3. 11> 공리 테이블

앞서 언급한 대로, 온톨로지 구축 과정이 전통적인 폭포수 모델과 같이 시간적인

측면을 갖고 있지 않다. 개념화 단계에서 어떤 작업은 순서에 관계없이 진행될 수

있다. 그러나 일반적으로 용어 사전을 만들고, 그 후 개념 분류 트리와 이진 관계

다이어그램을 만드는 것이 권장된다.

2.3 형식화(formalization)와 구현(implementation)

개념화 모델은 ODE(Ontology Design Environment)나 WebODE를 통해 자동

적으로 온톨로지 언어로 생성된다. ODE는 METHONTOLOGY에서 제공하는 소프

트웨어 개발 환경이다. 이 도구의 목적은 요구사항부터 완성된 온톨로지를 평가하

는 온톨로지 개발 전(entire) 단계에 이르는 모든 생명주기 동안 온톨로지 구축자

를 지원하는데 있다. WebODE는 ODE의 웹 버전으로 ODE와 같은 기능을 제공한

다. WebODE에 대한 설명은 온톨로지 구축 환경에서 언급하기로 한다.

ODE의 가장 큰 장점은 지식 수준에서 작성한 개념화 모델을 코드 생성기를 통

해 자동적으로 온톨로지 언어로 구현해 주는 것이다. 따라서 특정 언어에 익숙하지

않은 비전문가라도 이 도구를 이용하면 온톨로지를 구체화하여 언어로 구현할 수

있다.

<그림 3.12>는 ODE를 이용한 온톨로지 구현의 예이다. 개념화 모델에서 정의한

“Elements”는 온톨링구아(Ontolingua) 정의에 의해 실제 표현 언어로 정의된다.

25

이런 과정은 모두 자동적으로 이루어진다.

<그림 3. 12> ODE 를 통한 온톨로지 구현

실제 온톨로지 언어를 표현하는 방법은 상당히 많은 진전이 있어 왔다.

METHONTOLOGY 방법론에서도 WebODE를 개발하여 웹 기반에서도 온톨로지를

구축할 수 있는 환경을 제공한다. WebODE는 개념화 모델을 RDF, OWL과 같은

웹 온톨로지 언어로 표현할 수 있다.

2.4 유지보수(maintenance)

이 단계는 온톨로지 생명 주기로 볼 때 가장 유용하게 활용되는 기간이라 할 수

있다. 소프트웨어 공학 측면에서 유지 보수는 소프트웨어를 인도한 후 일어나는 모

든 공학적 작업을 말한다. 보통 유지 보수에 대한 활동은 상당히 많은 시간을 요하

게 된다. 온톨로지도 소프트웨어와 유사한 특징을 갖고 있다. 온톨로지 구축에 소요

되는 시간이 비록 단기간에 끝마쳐져도, 유지보수는 단기간에 끝낼 수 없는 경우가

대부분이다. 예컨대, 온톨로지가 사용될수록 계속적으로 개선되고 변경될 수 있다.

유지보수에는 정정(correction), 개정(adaption), 기능보강(enhancement) 등이 있

다. 온톨로지를 사용 중에 논리적 오류가 있거나 틀린 부분이 있을 경우, 이를 수정

해야 하는데 이 경우가 정정에 해당된다. 반면 개정은 환경에 변화 요인에 의해 변

경되는 것을 말한다. 마지막으로 기능 보강은 온톨로지 개발시에 고려하지 못했던

개념이나 기능을 추가하는 것을 말한다.

METHONOTOLOGY를 이용해 구축된 온톨로지는 다음과 같은 것들이 있다.

- CHEMICALS 온톨로지 : 화학 성분과 결정 구조에 대한 도메인 지식

26

- Monatomic ions 온톨로지 : 원자 이온에 대한 정보

- Environmental pollutants 온톨로지 : 다양한 요인에 의한 환경 오염에

대한 지식 표현

- Reference 온톨로지 : 온톨로지에 대한 옐로우 페이지

- OntoRoadMap 온톨로지 : 온톨로지, 온톨로지 개발 방법론, 온톨로지

개발 도구, 온톨로지 이벤트에 대한 지식 표현

제 6절 SENSUS

1. 개요

이 방법론은 응용 프로그램에서 사용할 수 있는 온톨로지나 지식베이스를 구축하

는데 목적이 있다. SENSUS는 자연어 처리에 사용하는 온톨로지이다. 이것은 기계

변환기 개발에 필요한 광범위한 개념 구조를 제공하는 연구를 수행했던

ISI(Information Sciences Institute) 자연어 그룹에 의해 개발되었다. SENSUS 온

톨로지는 다양한 전자 매체에 있는 지식에서 정보를 추출하거나 병합하여 얻게 된

다. 이 과정은 <그림 3.13>과 같이 이루어진다.

<그림 3. 13> SENSUS 온톨로지 구축 과정

첫번째 단계는 온톨로지 베이스를 만드는 것이다. 이것은 PENMAN 상위 모

델,ONTOS, 의미적 분류의 정보를 수작업으로 병합하여 진행되고, 이를 통해 얻은

산출물이 온톨로지 베이스이다. 온톨로지 베이스는 WordNet과 병합될 수 있다. 이

과정도 수작으로 진행될 수 있다. 이 후 병합 도구는 어 사전을 이용하여

27

WordNet과 병합하는데 사용된다. 병합의 결과는 콜린스 스페인/ 어 사전과

Kenkyusha 일 사전에서 어휘 목록을 보강하게 된다. 이 때 작업은 기계 번역기

를 이용한다.

SENSUS는 추상화 단계에 따라 계층 구조로 만들어진 5만개 이상의 개념을 갖

고 있다.

2. 방법론

SENSUS에 기반해 도메인 온톨로지를 구축하는 과정은 다음과 같다.

① 단어들의 집합을 제공

② 제공된 단어들을 수작업으로 SENSUS에 연결

③ 새로운 단어로 나온 모든 개념들의 경로를 SENSUS의 뿌리에 포함

④ 도메인에 관련될 수 있거나 나타나지 않았던 용어 추가

⑤ 새로운 도메인 용어는 전 단계에서 얻었던 베이스에 추가

<그림 3. 14> SENSUS 기반의 온톨로지 구축 과정

이 방법론은 모델의 공유성(shareability)을 증진시킬 수 있다. 즉, 실제 도메인

온톨로지를 구축할 때, 온톨로지 구축자는 동일한 기준 온톨로지를 사용할 수 있다.

군 항공작전 계획(air campaign planning)을 위한 온톨로지가 SENSUS를 이용

하여 구축되었다. 이 온톨로지는 작전, 시나리오, 참가자, 지휘관 등과 같은 항공

작전 계획에 관련된 개념과 일반적인 무기, 시스템, 연료 등에 대한 기본 요소들이

포함되어 있다.

SENSUS 방법론은 온톨로지를 구축하기 위한 도구로 Ontosaurus를 제공하고

28

있다. Ontosaurus는 ISI의 의해 개발되었고, LOOM 지식 베이스를 위한 웹 브라우

저 이다. 이 도구는 여러 개의 지식 베이스 사이에 시각화된 하이퍼링크된 인터페

이스를 제공한다.

<그림 3.15>는 Ontosaurus를 이용하여 “AIRCRAFT”에 대한 정보를 검색한

것이다.

<그림 3. 15> Ontosaurus 를 이용한 검색의 예

제 7절 OTKM

1. 개요

OTK 방법론은 EU IST-1999-10132 프로젝트인 On-To-Knowledge에 의해

개발되었다. On-To-Knowledge는 온토롤지 기반의 지식 관리 프레임워크에 관련

된 연구를 수행하 다. OTKM은 이 프로젝트의 산출물이며, 다수의 기업들이 이

방법론을 이용해 지식 관리 프레임워크를 적용하 다.

OTKM은 지식 프로세스(knowledge process)와 지식 메타 프로세스(knowledge

29

meta process) 중심으로 지식을 개발하고 관리한다. 지식 프로세스는 지식의 항목

들과 관련된 것으로 지식 관리와 유사한 의미를 갖는다. Davenport는 지식관리를

“ 지식을 획득(Caputuring)하여 저장(Storing)하며 공유(Sharing)하고 활용

(Using)하는 프로세스”로 정의한 바 있다. 반면 지식 메타 프로세스는 새로운 지

식관리 솔루션을 도입하고 관리하는 모든 과정을 의미한다. 이것은 지식관리 시스

템을 개발하기 위한 과정에 중점을 두고 있다. 따라서 OTKM은 지식 메타 프로세

스를 위한 방법론이라 할 수 있다. OTKM의 이론적 배경은 CommonKADS 방법론

에서 찾을 수 있다. CommonKADS는 10년 이상 지식관리 시스템을 개발하기 위한

대표적 방법론으로 인식되고 있다. 이 방법론은 1990년대 초부터 연구를 진행되었

으며, 지식의 공유와 재사용을 위한 방법론을 개발하는데 주목적을 두고 있었다. 그

러나 온톨로지 개발과 온톨로지 기반의 시스템에 그대로 적용하는데 한계가 있다.

OTK 방법론은 이러한 CommonKADS의 단점을 보완하고 있다.

2. 방법론

지식 메타 프로세스는 5 개로 구성되며, 각 단계는 핵심적인 결정을 위해 필요한

세부 단계들로 구분될 수 있다. 각 단계의 산출물은 의사 결정이 완료된 것으로 생

각할 수 있다. 5 단계는 “타당성 연구(Feasibility study)”, “개시(Kickoff)”,

“ 정제(Refinement) ” , “ 평가(Evalutation) ” , “ 적용(Application) 및 진화

(Evolution)” 등이다. “정제”-“평가”-“적용 및 진화” 단계는 필요시 반복

적으로 수행될 수 있다.

<그림 3.16>은 지식 메타 프로세스 과정을 설명하고 있다.

<그림 3. 16> OTK 방법론

30

다. Refinement

• ORSD에 정의된 내용을 이용하여 목표 온톨로지(target ontology) 개발

• 지식 도출 단계(seed ontology 개발)와 정형화 단계(지식표현언어로 표현)

로 구분

• 개시 단계에서 생성된 자료를 기초로 활용

• 공리(Axioms)을 정의

라. Evaluation

• 기술중심의 평가 : 특정언어로 표현된 온톨로지 구문의 적절성, 상호운용성,

산출물의 일관성 등

• 사용자 중심의 평가 : ORSD에 기술된 목표 온톨로지의 적합성, 쓰임새 패턴

등

마. Maintenance

• 온톨로지의 수정-삭제-삽입-갱신을 위한 프로세스 진행

• 집중화 전략/분산화 전략

31

제4 장. 협력적 온톨로지 구축을 위한 방법론

온톨로지는 어떤 도메인에 대해 상식적이고 공유된 이해라 할 수 있다. 중요한 것

은 온톨로지에 포함되는 내용에 합의를 이끌어야 한다. 이런 측면에서 다양한 집단

이 온톨로지에서 제공하는 개념, 관계, 속성, 공리에 대한 형식적 명세에 대한 동의

해야 한다. 그러나 현실적으로 어떻게 다양한 집단이 동의할 수 있는 온톨로지를

함께 구축할 것인지, 어떻게 분산된 환경에서 온톨로지를 구축할 것인지에 대한 문

제는 해결하기 매우 힘들다. 다시 말해, 다수의 사람들이 공동으로 온톨로지 개발을

하는 것은 쉽지 않다. Euzenat는 이러한 문제를 몇 가지로 구분하고 있다: 개발자

사이의 언어 소통과 상호작용에 대한 관리, 데이터 접근 통제, 지식에 대한 도덕적

권리에 관계된 인지, 오류에 대한 탐색과 관리, 동시적 관리, 데이터의 수정. 이러

한 문제를 해결하기 위한 방법을 제안한 경우는 종종 있어 왔다. 최근 몇 년간 제

안된 방법에서 대표적인 것이 CO4와 (KA)2이다.

제 1 절 CO4

1. 개요

CO4(Collaborative Construction of Consensual Knowledge)는 몇 개의 지식

베이스 사이에서 공통된 합의를 이끌어 내기 위한 협약(protocol)이다. 이것의 목

표는 지식베이스에 있는 지식을 관계된 사람이 토의하여 동의를 얻어내는데 있다.

지식베이스는 구성원들이 합의한 지식을 바탕으로 공유되어 구축되므로 이런 의미

에서 온톨로지라 할 수 있다.

Euzenat가 제안에 따르면, 지식베이스는 트리 형식으로 조직화된다. 트리에서 최

종 노드들은 사용자 KB, 중간의 노드들은 그룹 KB라 한다. 이 때 사용자 KB는 반

드시 합의된 지식이 아니어도 되지만, 개별 KB는 반드시 하나의 그룹에 포함될 수

있다. KB의 사용자가 정의한 지식에 대해 충분한 확신이 있다면, 나머지 사용자와

합의를 도출할 수 있다. 이 과정은 <그림 4.1>과 같은 단계에 따라 수행된다.

① KB 사용자는 KB 그룹 노드에 메시지를 보낸다. KB 그룹 노드는 모든 서명자

(subscriber) 노드에게 의견을 구하는 요청을 보낸다. 이 때 서명자는 직계 자손

노드만 포함된다. KB 그룹내의 합의된 지식과 제안된 지식 사이에 일관성을 평가하

기 위한 프로그램이 실행된다. 다른 프로그램은 어떻게 KB 그룹 노드에 제안된 지

식을 추가할 것인지 보여줄 수 있다. 이런 작업은 제안된 지식을 채택할 것인지 아

닌지 결정하는데 도움을 줄 수 있다.

32

<그림 4. 1> 사용자 제안의 제출과 승인

② 만약 서명자 노드가 KB 그룹이라면, 이 노드에서 직계 자손 노드의 모든 서

명자에게 의견을 구하는 요청을 보낸다. 이 과정은 트리의 말단 노드에 도착할 때

까지, 재귀적으로 수행된다.

③ 제안서가 말단 노드에 도착한 후, 개별 서명자는 제안된 지식에 대해 채택 혹

은 거부 메시지를 KB 그룹에게 보낸다.

④ KB 그룹이 모든 자손 노드에서 응답을 받은 후, 제안된 지식의 채택 여부를

결정한다. 결정을 위한 경우는 다음과 같다.

i) 모든 서명자가 변경에 동의했을 때, 제안은 채택된다.

ii) 변경에 대해 일부 서명자가 반대할 경우, KB 그룹 노드에서 채택되

지 않는다. 이 때는 거부된 의견을 제안자에게 보낸다

iii) 선택가능한 제안을 다시 서명자에게 보내고, 제안의 채택 여부를 다

시 요청한다.

⑤ 제안된 지식이 채택되면 결과를 KB 그룹 노드에 통보한다.

단계 2,3,4,5는 모든 사용자가 제안을 수락하거나, 명확하게 거부할 때까지 반복

적으로 수행된다.

33

제 2 절 (KA)2

(KA)2(Knowledge Annotation Initiative of the Knowledge Acquisition) 이니셔

티브의 목표는 온톨로지를 이용하여 지식획득을 위한 모형을 개발하는 것이다. 이

때 온톨로지는 동일한 템플릿과 언어를 사용하여 다른 위치에 있는 사람들과 공동

작업으로 개발하게 된다. 현재 (KA)2 온톨로지의 개념적 모형은 7개의 온톨로지로

구성되어 있다: 조직(organization) 온톨로지, 프로젝트(project) 온톨로지, 개인

(personal) 온톨로지, 출판(publication) 온톨로지, 이벤트(event) 온톨로지, 연구

주제(research-topic) 온톨로지, 연구 산출물(research-product) 온톨로지.

온톨로지를 구축하기 위해 사용되는 협력적이고 분산된 과정에는 두 개의 업무를

담당하는 사람이 포함된다. (KA)2는 이것을 각각 온토픽 에이전트(ontopic

agents)와 온톨로지 조정 에이전트(ontology coordinating agents)라고 한다. 온토

픽 에이전트는 관심 분야에 깊은 지식을 보유하고 있는 연구자들의 모임을 말한다.

다시 말해 도메인의 전문가 그룹이라 할 수 있다. 온토픽 에이전트에는 15개의 모

임이 있으며, 개별 모임은 (KA)2 온톨로지의 특정 주제에 관련된 연구를 진행한다.

개별 모임의 목표는 KA 공동체의 합의된 온톨로지를 설계하는데 있다.

(KA)2 온톨로지의 대부분은 온톨로지 조정 에이전트에 의해 직접 개발된다. 이들

은 온톨로지를 개발하기 위해 개념적인 구조를 만들고, 핵심 개념, 어휘, 관계, 기

능, 속성, 공리를 구체화한다.

그러나 연구주제 온톨로지는 온토픽 에이전트와 온톨로지 조정 에이전트가 공동 작

업으로 개발하 다. 온톨로지 개발을 쉽게 하기 위해, 온톨로지 조정 에이전트는 온

토픽 에이전트에게 템플릿을 배포해 이를 통해 지식을 수집한다[그림 참고]. 온토

픽 에이전트에게 모든 템플릿을 받으면, 온톨로지 조정 에이전트는 이를 통합하게

된다. 이 때 통합 과정은 동일한 템플릿을 사용했기 때문에 쉽게 진행될 수 있다.

(KA)2 온톨로지의 첫번째 배포판은 Ontobroker에서 사용되는 언어인 FLogic으로

표현된다. 그리고 Ontolingua에 전체 온톨로지를 변환하여 최종본을 만든다.

Ontolingua 서버는 모든 공동체가 접근 가능하기 때문에, 구축된 온톨로지의 공유

를 쉽게 할 수 있다. FLogic과 Ontolingua 사이의 변환은 ODE에서 담당하는데, 이

작업은 변환기에 의해 자동적으로 수행된다.

34

<그림 4. 2> ODE 를 통한 온톨로지 구축

35

제 5장. 온톨로지 병합과 통합을 위한 방법론

일반적으로 ‘통합(integration)’이란 관계를 지어 하나의 모임을 만드는 것이다.

온톨로지와 관련된 분야에서 통합에 대한 개념은 다양한 스펙트럼을 포함하고 있다.

예컨대, ‘integration’, ‘merge’, ‘use’, ‘mapping’, ‘alignment’,

‘approximation’, ‘unification’은 때로 통합이란 의미로 받아들여지기도 하고,

그렇지 않은 경우도 있다. 즉 동의어(synonym)인 동시에 동음어(homonym)로 사

용된다. 본 장을 시작하기에 앞서 무엇이 통합인지 구분해 보자.

연구자마다 통합에 대한 정의를 다양하게 하고 있다. 그러나 일반적으로 ‘통합’

은 다른 개념을 포괄하는 광의의 개념으로 사용된다. 따라서 일반적으로 온톨로지

통합이라 하면 위에 언급된 모든 개념들을 포함하고 있는 것으로 이해할 수 있다.

그렇다면 어떤 차이가 있는지 좀 더 구체적으로 살펴 보자. 우선 사상(mapping)은

서로 상이한 온톨로지에서 유사한 개념이나 관계를 느슨한 형태로 연결하는 것이다.

따라서 프로세스가 완료된 후에도 각각의 온톨로지의 구조는 변하지 않는다. 엄격

히 말하면, 사상은 온톨로지 통합이라 할 수 없다. 정렬(alignment)은 부분적 순서

(ordering)와 동의어의 보존을 기초해서 다수의 온톨로지 사이에서 개념과 관계를

연결하는 것이다. <그림 5.1>은 두 개의 온톨로지 사이의 정렬 관계를 도식화하고

있다. <그림 5.1>에서 O1과 O2의 특정 개념은 서로 동의어 관계로 연결할 수 있고,

O1의 특정 개념은 O2의 개념을 포함할 수 있다.

<그림 5. 1> 동의어 관계

정렬은 통합의 형태에서 가장 약한 형태이다. 정렬은 정보 검색이나 분류를 위한

목적에 적합할 수 있다. 그러나 이것은 복잡한 추론을 요하는 도메인에 적용하기

힘들다. 사상과 정렬은 모두 온톨로지의 구조를 변경시키지 않는 공통점이 있다. 반

면 병합(merge)와 통합은 앞서 언급한 두 개의 개념과 상당히 다르다. 병합은 동

일한 도메인 또는 주제를 갖고 있는 서로 다른 온톨로지가 존재할 때, 이를 통해

36

새로운 온톨로지를 만드는 것이다.

<그림 5. 2> 온톨로지의 병합

<그림 5.2>에서 O1과 O2는 비록 다른 구조이지만, 동일한 도메인 D를 표현하고

있다. 병합은 O1과 O2에서 새로운 온톨로지 O를 만들어내게 된다. 이 때 온톨로지

O는 O1과 O2가 갖고 있는 구조와 다른 온톨로지 구조를 갖는다.

마지막으로 통합은 기존 온톨로지의 재사용을 통해 새로운 온톨로지를 만든다. 그

림 5.2는 통합의 과정과 결과를 보여주고 있다. 우선 서로 다른 온톨로지 O1, O2

는 표현한 도메인(D’’, D’’’)도 서로 상이하다. 이와 같은 환경에서 통합된

새로운 온톨로지 O는 D’라는 도메인 정보를 표현하고 있다. 즉 통합은 여러 개의

온톨로지를 재사용하지만, 그것이 구축하려는 도메인과 항상 일치할 필요는 없다.

또한 통합된 온톨로지는 재료 온톨로지의 구조를 재사용함과 동시에 필요하다면 특

정한 개념을 추가할 수 있다.

앞서 언급한 통합과 관련된 개념을 요약하면 <표 5.1>와 같다.

도메인의 동일성 구조 변경 여부 새로운 온톨로지 생성

사상 관계 없음 변경 없음 X

정렬 관계 없음 변경 없음(미약) X

병합 동일함 변경됨 생성

통합 상이함 변경됨 생성

<표 5.1> 온톨로지 병합과 통합의 비교

37

<그림 5. 3> 온톨로지의 통합

온톨로지 통합에 대한 개념적 이해가 되었다면, 이제 구체적인 내용을 살펴보도

록 하자. 온톨로지 통합에 관련된 연구는 최근 들어 상당히 활발해 지고 있다. 특히

레거시(legacy) 시스템을 통합할 때 온톨로지의 필요성이 부각되고 있다. 본 장에

서는 ONIONS와 PROMPT를 중심으로 설명한다.

제 1 절 ONIONS

1. 개요

ONIONS(Ontological Integration Of Naïve Sources) 프로젝트는 의료 분야의 전

문용어 시스템에서 사용할 수 있는 전문용어 온톨로지의 개발에 연구 목적이 있었

다. 우선 두 가지 개념을 정의해 보자. 첫째, 전문용어란 무엇일까? 이것은 특정 분

야에서 사용되는 개념적 정보와 표현의 총체를 용어, 코드, 그래픽 또는 비언어적

기호 등을 이용해 서술적으로 표현한 것이다. 일반적으로 전문용어는 일상 용어와

구별되어 설명된다. 때에 따라 전문용어가 일상용어로 변화하는 경우도 찾아볼 수

있다. 그러나 의료 분야의 경우는 적어도 현재까지 전문용어로 인식된다. 둘째, 전

문용어 온톨로지는 무엇인가? 일반적으로 “어휘들의 명시적인 개념화”라고 정의

하는데, 공리나 정의가 완전할 필요는 없다. 전문용어 온톨로지의 대표적인 예가

WordNet이다. WordNet의 범주는 상위-하위형식 또는 부분-전체와 같은 일부분

의 관계로 정의된다.

ONIONS 방법론은 GALEN 프로젝트의 경험을 통해 만들어졌으며, 이를 통해 의료

38

분야의 전문용어 서버의 핵심 모델을 구축할 수 있다. ONIONS은 다섯 개의 전문

용어 시스템에서 대표적인 개념의 통합을 이끌어낸다.

- UMLS-SN : 약 170 개의 의미적 형식과 관계, 이것들을 조합한 890 개의

정의

- SNOMED-III : 약 600 개의 대표적인 개념들

- GMN : 약 700 개의 대표적인 개념들

- ICD10 : 약 250 개의 대표적인 개념들

- GCM-5g : 약 2000 개의 항목들

ONIONS를 이용한 전문용어 시스템의 통합 결과는

Ontolingua(http://www.ksl.stanford.edu/software/ontolingua/)와 Loom의 형식

화를 통해 표현된다.

2. ONIONS 방법론

<그림 5.4>는 ONIONS 방법론을 도식화된 방법으로 설명하고 있다. ONIONS 방법

론은 6개로 구분된 단계별 개발 전략을 갖고 있다. 서로 다른 개발 상태(states)에

따라 입출력이 달라지고 이에 따른 전문용어 시스템의 속성도 달라진다. 각 단계는

구조적 속성과 온톨로지적(ontological) 속성의 집합을 포함하고 있다. “온톨로지

적” 속성은 개념적 시스템의 원칙(principles)에 관계된 것을 말한다.

단계 Mi는 상태 Si에서 Si+1로 단계별로 발전해가는 전문용어 시스템을 구성한다.

Pi와 Oi는 각각 Si 시스템의 구조적 속성과 온톨로지적 속성이다. 따라서 각각의

속성에 따라 현재 존재하는 시스템의 범주가 결정된다.

이제 단계별로 수행되는 작업과 요구사항을 살펴보도록 하자.

S0* : 이 상태에서 도메인 지식은 형식적으로 구조화 되지 않고(Po), 온톨로지적

으로 뚜렷한 특징이 없다. 즉 Oo는 명시적으로 개념화된 것이 존재하지 않는다.

M0+ : 방법론적 단계인 Mo는 도메인에서 유효한 전문용어 말뭉치(corpus)를 수

집한다. 의료 용어의 경우, 앞서 언급한 5개의 전문용어 시스템을 이용하여 말뭉

치를 수집한다.

39

<그림 5. 4> ONIONS 방법론의 통합 단계

S1* : 도메인 지식은 개념적으로 그럴듯한(O1) 적절한 표현(P1)을 갖는 목록으로

기술된다. 용어 목록들은 전문가, 비정형 텍스트에서 추출할 수 있다. 예를 들어,

SNOMED-II의 바이러스간염(viral hepatitis)은 코드 번호 D-0521을 갖는다. 이

를 S1 단계에서 다음과 같이 표현할 수 있다.

Code 070.1 for viral hepatitis type A

용어 목록에 있는 항목들은 SNOMED나 ICD와 같은 구조화된 용어 시스템의 코

드를 검색하여 추가할 수 있다. 다음의 예는 Ontolingua에서 감염질환(infectious-

deseases)이라는 새로운 이론을 생성하는 것이다.

(define-theory infectious-diseases ())

(define-class viral-hepatitis-a (?vh)

40

:issues ((:see-also "in SNOMED, the code is D-0521" "in ICD9-CM

the code is 070.1")))

이때, 감염질환(infectious-deseases)과 viral-hepatitis type A는 M0단계에서

추출된 것이고, issues에 대한 설명은 다른 용어 시스템의 정보를 이용하여 표현할

수 있다.

M1+ : 이 단계에서는 전문용어 목록에 존재하는 핵심적인 분류체계를 찾아내야

만 한다. <그림 5.5>에서 보듯이 바이러스 간염 A형은 용어 시스템마다 서로 다른

계층구조로 정의되어 있다. 이 단계의 결과는 S2 시스템이 된다. 다수의 ‘전통적

인’ 전문용어 시스템이 S2 시스템으로 분류될 수 있다(예, ICD10등).

<그림 5. 5> UMLS(Metathesaurus) 분류체계

S2* : 모든 목록들은 반드시 IS-A 포함 관계에서 유도된 순서를 갖고 있어야 한

다. 다시 말해 목록들은 최소한 단일 혹은 복합 계층 분류(P2)에 포함되어 있어야

한다. 또한 온톨로지적 관점에서 어떤 메타클래스를 분류체계에 포함시킬 것인지

고려해야 한다(O2). 예컨대, A 형 간염은 간염, 질병, 바이러스 간염 혹은 진단과

같은 개념을 IS-A 관계로 가질 수 있다.

(define-class viral-hepatitis-a (?vh) (3)

:axiom-def (subclass-of viral-hepatitis-a inflammation)


41


여기서 A형 간염은 염증과 IS_A 관계를 갖는 하위클래스로 정의하고 있다. 물론

염증(inflammation)에 대한 클래스는 다른 곳에서 정의되어야 한다.

M2+ : M2 단계는 S2 상태의 분류체계에 있는 용어들이 왜 IS_A 관계를 갖는지,

어떤 용어가 가장 가까운 개념인지 구체화한다. 예컨대, “바이러스 간염”과 “간

염”을 구분하는 것이 무엇이고, 왜 이들 사이에 IS_A 관계가 성립되는지 찾아내야

한다. 이 단계는 S3 상태를 이끌어 낸다.

S3* : 분류체계의 항목들은 용어에 대한 비정형텍스트 명세를 포함하고(P3), 항목

들간의 종차(種差:differentia specifica)를 명확히 정의한다(O3). 비정형 텍스트 명

세는 자연어를 이용하여 항목을 설명하는 것이다. 예컨대, A형 간염은 “A형 간염

바이러스가 주로 간을 침범하는 감염증이며, 3주의 잠복기를 갖는다”라고 설명할

수 있다. 종차는 하나의 상위 개념 속의 어떤 하위 개념이 다른 것들과 구별되는

요소를 말한다. 동물에 대한 하위 개념으로 새와 코끼리가 있을 때, “날개가 있으

면 날 수 있다”라는 성질이 종차라고 할 수 있다. 따라서 동일한 계층구조를 갖는

항목들은 종차를 이용하여 개념적으로 명확히 구분할 수 있다. 그림 5.6은 M2 단

계에 정의한 분류체계 항목들의 명세를 포함하고 있다. 의료분야의 대다수 사전과

어휘 사전이 S3 시스템으로 구분된다.

M3+ : 항목들의 형식화와 S3 명세의 제약조건으로 구성된다. 이 단계의 목표는

S4 시스템을 얻는 것이다.

<그림 5. 6> 분류체계를 위한 UMLS 명세

42

S4* : M2 단계에서 생성된 요소들의 뼈대(frame)를 만든다. 명세에 사용된 요소

들(속성값)은 설명된 용어(클래스 혹은 프레임)와 명시적인 관계(슬롯 혹은 역할)

를 갖는다. 논리적 용어 측면에서, 프레임은 어떤 지식에 적용할 수 있는 관계의 정

의역과 공역을 제공한다. 이러한 제약조건을 개념적 원칙이라 할 수 있다. 개념적

원칙은 부분-전체(part-whole), 프로세스의 목적론(teleology), 객체의 기하학

(topology), 물리적 특성 등을 고려할 수 있다. 이 단계의 프레임 제약조건은 형식

적 의미론을 갖지 않는다. UMLS 시맨틱 망, GRAIL 모형이 P4 특성을 갖는 시스

템이다. GRAIL 문법을 이용해 A형 간염을 정의하면 다음과 같다.

[Inflammation which

< affects-Liver

isCausedBy-VirusA

hasIncubation-15To50Days

isAccompaniedBy-Jaundice >] name ViralHepatitisA

“which” 연산자는 논리곱(AND)을 의미하고, “name” 연산자는 논리적 동치

를 의미한다. 따라서 클래스 염증(inflammation)은 ViralHepatitisA 클래스와 동치

관계를 갖는다. 좀 더 자세히 살펴보면, 염증 클래스는 “ affects ” 의 공역으로

“ Liver ” , “ isCausedBy ” 의 공역으로 “ VirusA ” 를 갖는다. 또

“hasIncubation”의 값으로 “15To50Days”를 갖는다.

위에 기술된 일반적 프레임 구문은 Ontolingua를 이용하여 자동적으로 변환된다.

Ontolingua를 이용한 A형 간염의 정의는 다음과 같다.

(define-class viral-hepatitis-a (?vh) (6)

"the inflammation of liver caused by virus A; it has an incubation of 15

to 50 days and is accompanied by jaundice"

:class-slots ((subclass-of viral-hepatitis-a inflammation))

:instance-slots ((has-incubation viral-hepatitis-a 15-to-50-days)

(affects viral-hepatitis-a liver)

(caused-by viral-hepatitis-a virus-a)

(is-accompanied-by viral-hepatitis-a jaundice))



물론 define-class 형식인 liver, virus A, jaundice와 define-relation 형식인

affects, caused by, has incubation, isaccompaniedby등은 반드시 정의해야 한다.

현재 의료 분야의 어떠한 용어 시스템도 O4를 만족시키는 것이 없다. 그렇다면

43

어떻게 O4를 만족시킬 수 있을까? ONIONS은 이를 위한 해결 방법으로 일반적 온

톨로지(generic ontology) 라이브러리를 제공한다. S4 단계는 이를 위해 조작적인

방법을 취하고 있다. Ontolingua에서 “:issues” 필드를 이용해 O4에 맞는 명시적

인 개념적 원칙을 구성할 수 있다.

(define-class viral-hepatitis-a (?vh)

"the inflammation of liver caused by virus A; it has an incubation of 15

to 50 days and is accompanied by jaundice"

:class-slots ((subclass-of viral-hepatitis-a inflammation))

:instance-slots ((has-incubation viral-hepatitis-a 15-to-50-days)

(affects viral-hepatitis-a liver)

(caused-by viral-hepatitis-a virus-a)

(is-accompanied-by viral-hepatitis-a jaundice))


the code is 070.1")

(:generic-theories "inflammation requires a multiple account within a

theory of biologic functions and a theory of biologic morphologies"

"affects requires a theory of actants and a theory of functions"

"caused-by requires a theory of causality" "the patient status is not

mentioned" "anatomy is not mentioned: at least, a part-whole theory is

required")))

비록 “:generic-theories”를 이용한 방법이 형식적이지 못하지만, 일반적 온톨

로지에 있는 방대한 라이브러리는 특정한 웹 사이트를 개발하는데 응용할 수 있다.

M4+ : 이 단계는 S4에서 사용한 (:issues(:generic-theories)) 요구사항을 설

명하기 위한 일반적 온톨로지 라이브러리의 구축을 포함한다. 이것은 상위 수준

(top-level) 온톨로지를 구축하는 것과 동일하다.

S5* : 모든 정의들은 공리화된다(P5). 온톨로지 관점에서 정의들은 상위 수준 개

념과 메타 수준(meta-level) 범주(categories)의 명시적 의미론을 갖고 있다. 상

위 수준 개념은 일반적 온톨로지에서 제공하는 개념을 말하고, 메타 수준의 범주는

표현 온톨로지(representation ontology)에 의해 제공되는 개념을 말한다. 앞서 언

급한 대로, 전통적인 전문용어 시스템은 S5 특성을 갖고 있지 않다. S5의 정의는

이전 단계의 것보다 좀 더 구체적이다.

A형 간염에 대한 S5 단계의 정의는 다음과 같다.

44

M5+ : 자동적인 분류가 가능한 시스템에서 도메인 온톨로지를 구현한다.

S6* : 도메인 온톨로지는 자동적인 식별자에서 구현된다(P6). GALEN의 핵심 모

형의 경우, 현재 자동적인 식별자를 통해 온톨로지를 구성한다. ONIONS는

Ontolingua 형식에서 Loom으로 온톨로지의 라이브러리를 내보낼 수 있다. <그림

5.7>은 ONIONS에서 사용하는 언어의 연산자들에 대한 의미적 비교를 보여주고

있다.

<그림 5. 7> ONIONS 에서 사용하는 언어 비교

45

3. 통합과 관련된 문제

ONIONS에서 전문 용어의 온톨로지적 분석과 병합은 온톨로지 구축 자료의 재공학

과 온톨로지 병합의 두 단계로 구분된다. 재공학 단계는 관련된 자료의 추출

(extraction), 체계화(formatting), 분석(analysis), 형식화(formalization)하는 세

부 단계로 나뉜다. 추출과 체계화는 데이터 형식의 예비 평가 후, 관련된 데이터를

포장해 놓는다. 분석은 언어학적/개념적 기술이 요구되며, 관련된 데이터가 의도하

는 의미를 명시화한다. 분석된 데이터는 논리적 언어로 표현된다. 재공학 프로세스

를 통해 얻어진 도메인 온톨로지가 차이가 있다면, 통합 혹은 병합된다.

ONIONS에서 온톨로지 통합은 다음의 절차에 따라 수행된다.

① 재료 온톨로지의 모든 개념, 관계, 템플릿, 규칙, 공리는 ONIONS 형식에

맞게 표현한다. ONIONS 는 현재 LOOM 을 이용하여 표현한다.

② 이와 같은 중간 생성물은 일반적 온톨로지 집합에 의해 통합된다. 이것은

ONIONS 에서 가장 독특한 특징이 있는 작업이다. 이 단계는 세부적인 다양

한 작업이 함께 병행된다.

- 형제(sibling) 관계가 있는 집합에서, 개념적 차이는 추론되며, 그 차이

는 공리를 이용하여 형식화된다. 또 라이브러리에 이미 개념과 관계가

기술되어 있다면 재사용이 가능하다. 차이점을 표현할 어떤 개념도 존재

하지 않는다면, 새로운 개념이 라이브러리에 추가된다.

- 용어가 다의적(polysemous)인 특성을 갖는 경우, 상이한 개념은 도메

인과 허용 가능한 모듈에 따라 라이브러리에 위치하게 된다. 다의성은

한 낱말에 두 가지 이상의 뜻이 들어있는 현상이나 특성을 말한다.

- 종종, 낱말이 다의적 특성은 환유적인 것과 관련이 있다. 어휘적 의미론

에서는 이를 교번(alternation)이라 한다. 환유란 한 사물을 나타내던

말이 그 사물과 시간적, 공간적으로 가까운 다른 사물을 가리키게 되는

낱말 비유의 한가지 이다. 예컨대, 머리카락에 대한 의미를 ‘머리’ 또

는 ‘머리털’과 같이 사용할 때 환유되었다고 말한다.

③ 새로운 개념을 기술할 때, 이미 정의된 개념과 새로운 개념 사이에 링크가

생성된다. 이것은 이미 정의된 개념에 일관성을 유지하기 위해 필요하다. 만

약 존재하는 낱말과 충돌이 발생할 경우, 좀더 일반적인 낱말을 찾게 된다.

그러나 불가능할 경우, 대안 이론을 생성한다.

46

제 2 절 PROMPT

1. 개요

PROMPT는 온톨로지 병합과 정렬을 위한 알고리즘이다. 이 알고리즘은 언어에

독립적인 특징을 갖고 있기 때문에 다양한 플랫폼에 적용할 수 있다. 병합 과정은

자동적으로 수행될 수 있다. 그러나 자동적 의사결정이 힘든 경우, 사용자가 개입하

여 제안을 선택할 수 있도록 하고 있다.

PROMPT suite는 다양한 온톨로지 관리를 위한 도구의 집합으로 Protégé 개발

환경을 확장하고 있다. 즉 Protégé-2000의 플러그인(plug-in)으로 개발되었다.

PROMPT suite의 주된 기능은 상호작용 가능한 온톨로지 병합, 그래픽 기반의 사

상(mapping), 온톨로지 버전 관리, 온톨로지 라이브러리 관리 등으로 요약할 수 있

다. PROMPT suite는 여러 개의 도구로 구성이 된다. <그림 5.8>은 아키텍처와 도

구들 사이의 관계를 보여주고 있다. 아키텍처안의 도구들은 사용자 인터페이스, 데

이터구조, 알고리즘 등을 공유하고 있다. 기본적으로 Protégé 프로젝트 브라우저는

PROMPT suite를 위한 모든 인프라를 제공한다.

- iPROMPT : 상호작용 가능한 온톨로지 병합 도구

- Anchor PROMPT : 온톨로지 사이에서 유사점(similarity)을 찾기 위한 그

래프 기반의 도구

- PROMPT Factor : 어떤 온톨로지에서 일부분을 추출하는 도구

- PROMPTDiff : 동일한 온톨로지에서 서로 다른 버전 사이의 차이점을 찾기

위한 도구

<그림 5. 8> PROMPT 아키텍처

47

2. PROMPT 알고리즘

PROMPT는 두 개의 온톨로지와 사용자의 의견을 입력 받아 하나의 새로운 온톨

로지를 생성한다. 이 과정은 단계적으로 수행되며, 사용자 의견을 받는 과정을 제외

하면 자동적으로 이루어진다. <그림 5.9>는 PROMPT 알고리즘의 흐름도를 보여준

다.

<그림 5. 9> PROMPT 알고리즘의 흐름도

병합할 온톨로지를 선택하면, 모든 병합 과정은 <그림 5.9>와 같은 순서에 의해

진행된다. 첫번째 단계는 클래스명을 기준으로 대등한 것들(matches)의 목록을 뽑

아낸다. 그 다음 적절한 연산을 통해 최적의 대안을 찾게 된다. 이 과정은 순환적으

로 이루어지는데, 다음과 같이 구분할 수 있다.

- 첫 단계에서 생성된 목록에서 사용자가 PROMPT의 제안들 중에 하나를 선택

- 자동 연산을 통해 선택사항 반

- 사용자에게 새로운 병합 제안들을 보여줌

- 병합된 온톨로지에서 발생할 수 있는 충돌 요소 검색과 해결

사용자가 연산을 요청하면, PROMPT는 위에 열거한 과정을 통해 새로운 온톨로지

를 생성하게 된다. 다음 절에서 PROMPT의 병합 과정에 쓰이는 연산들에 대해 자

세히 설명한다.

3. PROMPT의 연산

온톨로지 병합에 쓰이는 연산 집합은 두 가지로 구분할 수 있다. 하나는 전통적인

48

온톨로지 편집과 같은 연산을 말하고, 다른 하나는 병합과 정렬에 관련된 특정 연

산을 말한다. PROMPT는 병합을 위해 다음과 같은 연산을 제공한다.

- 클래스/슬롯의 병합 : 프레임이 유사한 이름과 동일한 타입을 갖고 있다면, 병

합시킬 수 있다.

- 클래스와 슬롯 사이의 결합(merge bindings) : 서로 다른 온톨로지에서 두 개

의 슬롯이 병합된 클래스에 추가될 수 있다.

두 개의 온톨로지를 병합하는 과정에서 매우 많은 문제가 발생할 수 있다.

PROMPT는 다음과 같은 문제 요소를 뽑아내어 이에 대한 해결 방안을 제안해 준

다.

- 이름 충돌

- 잘못된 참조의 추가

- 클래스 계층의 중복성

- 클래스 상속을 위반하는 슬롯값의 제약

49

제 6장. EOE 방법론

제 1 절 EOV(Evolving Ontology Engineering) 방법론의 개요

일반적으로 온톨로지를 구축하는 것은 단계적으로 진행된다. 본 장에서 소개하는

구축 방법론은 앞서 언급한 여러 방법론과 절차상으로 유사한 측면이 있다. 그러나

각 단계별로 구체적인 기준을 제시함으로써 쉽고 일관성 있게 온톨로지를 구축할

수 있다.

EOE(Evolving Ontology Engineering) 방법론은 진화형 프로토타입(evolving

prototype)을 바탕으로 하고 있다. 진화형 프로토타입은 시간 경과에 따라 요구사

항이 분명해지면서 온톨로지를 점진적으로 구축할 수 있는 견고한 아키텍처를 제공

한다. 진화형 프로토타입은 일회용 프로토타입보다 더 많은 시간이 소요되지만, 신

뢰성 있고 쉽게 확장할 수 있기 때문에 온톨로지를 구축하는데 적합하다. 또 요구

사항의 불확실성을 제거하기 위해 문서 프로토타입을 사용한다. 이것은 모든 요구

사항을 문서화함으로써 사용자와 온톨로지 개발자가 요구 사항에 대해 공감하고 있

는지 테스트할 수 있어 최종 산출물(온톨로지)의 위험을 낮출 수 있다. 문서 프로

토타입은 상용화 도구를 이용하여 전자 프로토타입으로 만들 수 있다. 즉, EOE 방

법론은 프로토타입 기법을 기반하여 온톨로지를 구축하기 때문에 온톨로지 개발자

와 사용자 사이의 상호이해와 지식 교환을 수월하게 할 수 있다.

EOE 방법론은 <그림 6.1>과 같은 프로세스로 진행된다. 온톨로지 기획 단계는

최고 책임자의 위임을 얻어 실행 계획을 작성하게 된다. 요구사항 분석, 개념적 설

계, 구현 단계는 온톨로지를 실제 개발하기 위한 핵심적인 절차이다. 온톨로지를 구

축하는 전 생명주기 동안 문서화, 지식 획득 작업은 공통적으로 수행된다. EOE 방

법론은 각 단계마다 순환적인 프로세스를 진행할 뿐만 아니라, 각 단계가 마무리

되기 전에 점검을 하여 미흡한 부분에 대한 반복적인 작업을 수행하게 한다.

50

<그림 6. 1> EOE 방법론 프로세스

제 2 절 단계별 개발 원칙

1. 요구사항 분석 및 정의(RAD: Requirement Analysis & Definition)

요구사항 분석 및 정의는 프로젝트의 목적과 궁극적인 지향점이 무엇인지 구체화하

는 단계이다. 요구사항은 구현되어야 하는 것에 대한 명세로 온톨로지가 어떻게 구

성돼야 하는지 또는 온톨로지의 특성이 무엇인지를 정의하게 된다. 요구사항에 대

한 내용은 일반적으로 요구사항 명세서(specification)로 요약된다. 그러나 요구사

항에 대한 분석과 정의가 단순히 문서화의 의미만 갖는 아니다. 이 단계는 온톨로

지 개발에 대한 전체 계획을 수립하고 정의하기 때문에 정확성이 무엇보다 강조된

다. 요구사항을 개발하는 것은 <그림 6.2>와 같이 순환적인 프로세스를 따른다.

<그림 6. 2> 요구사항 분석의 프로세스

51

즉 요구사항을 개발하는 것은 순차적으로 진행될 뿐만 아니라 점진적이고 순환적으

로 이루어진다.

1.1 RAD S1 요구사항 유도

요구사항 유도는 소프트웨어 공학과 마찬가지로 가장 어렵지만 중요한 단계이다.

이 단계는 의사소통이 주된 도구로 활용되기 때문에 에러 발생이 특히 높다. 따라

서 요구사항을 정확히 도출하기 위해 고객, 도메인 전문가, 온톨로지 개발자 사이의

긴밀한 협업 관계가 요구된다. 요구사항 유도를 위해 다음과 같은 규칙들을 고려할

수 있다.

규칙 내용 설명

RAD

R1.1

요구사항 개발

프로세스를 정

의

- 요구사항을 유도하고 분석하여 주요 단계들을 어떻

게 진행하는지에 대한 가이드를 제공

- 이를 기반으로 온톨로지 개발자들은 일관성 있는

작업을 수행

RAD

R1.2

비전과 범위를

정의

- 모든 관련자들이 온톨로지 구축의 목표를 이해할

수 있게 함

- 범위는 제안된 요구사항이 포함해야 하는 경계를

구체화함

RAD

R1.3

사용자 계층과

특성을 정의

- 사용자 커뮤니티의 특성 파악

- 구축할 온톨로지의 사용빈도, 사용 기능에 대한 특

성 파악

RAD

R1.4

사용자 대표와

협력하여 유스

케이스를 파악

- 사용자와 구축하려는 온톨로지에 대한 유스케이스

를 개발

- 표준 템플릿 개발

1) 비전과 범위 문서의 내용

비전과 범위는 요구사항을 하나의 문서로 작성해서 이후의 개발 작업의 각 단계에

서 활용할 수 있다. 이 문서에 대한 입력 정보는 요구사항에 대한 일반 정보, 비전,

범위, 프로젝트 환경 등이 포함될 수 있다.

52

구분 세부항목 설명

배경 온톨로지 개발의 합리적인 이유와 환경을 요약

기회 비즈니스 문제, 개선될 비즈니스 프로세스, 시스템에 사용

될 환경, 잠재적 활용 가능성

요구

사항

개요

목표와 성공기

준

계량적이고 측정 가능한 방식으로 목표가 충족되었는지

평가할 수 있는 기준 명시

비전 선언 장기적인 목적과 의도를 요약

주요 특징 개발하려는 온톨로지의 주요 기능 명시

비전

가정과 종속 관

계

온톨로지 개발과 관련된 모든 가정들을 기록

문서에 기록된 가정들은 기본가정으로 인식

초기 버전의 범

위

초기 버전에 포함될 범위 명시

향후 원하는 기능을 포함하지 않음

후속 버전의 범

위

향후 기능을 추가할 요소 명시

범위

와

제약

제약과 제외 범위에 따라 포함되지 않는 기능 혹은 도메인 정보 명시

관련자 프로필 온톨로지 개발에 참여하는 모든 사람들의 프로필 환경

프로젝트 우선

순위

효과적인 의사결정이 이루어질 수 있도록 기능, 범위, 품

질, 일정, 비용, 스태프에 대한 우선순위 명시

<표 6.1> 비전 및 범위 문서의 예

1.2 RAD S2 요구사항 분석

요구사항 분석은 온톨로지 개발에 참여하는 모든 사람들이 요구사항을 이해하고,

발생하는 모든 문제들을 검토할 수 있도록 요구사항을 정의하는 것이다. 요구사항

분석의 목적은 현실적으로 수행 가능한 프로젝트인지 예측하고, 이를 통해 설계, 구

성과 테스트 작업을 진행할 수 있도록 하는데 있다. 종종 요구 사항 중에 일부를

텍스트와 그래픽 형태로 표현하는 것이 도움이 된다.


RAD

R2.1

컨텍스트 다이

어그램 작성


를 개발


RAD

R2.2

프로토타입

작성

- 사용자, 도메인 전문가, 온톨로지 개발자가 요구사

항에 대한 확신이 없을 경우 프로토타입을 만들어

53

구체화

RAD

R2.3

요구사항의 타

당성을 분석

- 예상되는 운 환경에서 적절한 시간, 비용, 성능을

만족시킬 수 있는지에 대한 타당성 분석

1.3 RAD S3 요구사항 명세

전 단계에서 분석한 요구사항은 일관성 있고 쉽게 사용 또는 검토할 수 있는 방식

으로 문서화해야 한다. 요구사항 명세는 프로젝트에 따라 다양할 수 있으며 그 형

식이 고정되어 있는 것은 아니다. 흔히 요구사항 명세서는 이전 단계에서 언급한

비전과 범위 문서를 확장한 형태를 띤다.


RAD

R3.1

요구사항을 문

서로 만들 수

있는 표준 템

플릿을 정의


를 개발


요구사항 명세는 앞서 언급한 바와 같이, 요구사항 명세서(specification)로 요약된

다. 이것은 비전 및 범위 문서를 확장한 형태로 작성하게 된다. 즉, 비전과 범위 문

서가 온톨로지 구축 프로젝트의 일반적 목적과 비전을 담은 문서의 성격을 갖는 반

면, 요구사항 명세서는 개발하려는 온톨로지 자체에 대한 요구사항을 정의하게 된

다. 명세서에 포함되는 항목들은 다음과 같다.

　 개발 도메인의 일반적 정의

　 온톨로지 구축 개발자

　 형식화 수준

　 표현 언어

　 개발 도구

　 최종 온톨로지의 클래스, 속성, 인스턴스 수

　 도메인 지식을 얻기 위한 지식 소스

　 최종 온톨로지의 평가 기준

　 적격 질의(competency questions) 정의

54

1.4 RAD S4 요구사항 검증

검증은 요구사항 설명이 적절한지를 검토하고, 바람직한 품질 특징을 알려주고 고

객의 요구를 충족시키기 위해 필요하다.


RAD

R4.1

요구사항 문서

를 감사


를 개발


RAD

R4.2

문서의 테스트 - 작성된 문서가 요구사항을 제대로 반 했는지 점검

2. 온톨로지의 개념적 설계(COM: Conceptual Ontology Model)

2.1 COM S1 용어 사전 작성

개념적 모델링의 첫 번째 과제는 필요한 클래스를 결정하는 것으로 시작한다. 그러

나 클래스를 찾는 과정은 다소 불명확하다. 이 과정은 도메인 전문가의 직관과 모

델링 경험, 도메인에 대한 친숙도 등에 강하게 의존하고 있다. 만약 기존에 만들어

진 분류체계나 온톨로지가 있다면 이를 재사용할 수 있지만, 그렇지 않을 경우 온

톨로지 개발은 밑그림을 그리는 단계부터 시작해야 한다. EOE 방법론은 이 과정을

위해 2가지 방법을 제안하고 있다.

　 명사/명사절의 목록 수집

　 어절 분석기와 같은 자동화 도구를 이용한 수집

규칙 내용

COM

R1.1

도메인과 관련이 있는 주요 용어의 이름을 수집한다.

COM

R1.2

수집된 용어를 자료사전이나 설계문서 양식에 기록한다.

55

1) 명사 분석 기법

이 분석 방법은 온톨로지 개발에 사용된 모든 문서에서 명사 혹은 명사절을 수집한

후, 적절한 클래스들의 집합을 만들어내는 것이다. 이 기법을 위해 특정한 도구가

필요한 것은 아니다. 초기 작업에는 간단한 스프레드시트가 이상적인 도구로 쓰일

수 있다. 명사 분석은 다음과 같은 과정을 통해 수행된다.

　 원본 문서 선택

- 원본 문서의 요구사항이 방대한 경우 요약본을 작성

- 도메인에서 사용되는 용어들을 수집

- WordNet이나 기타 디렉토리를 이용한 수집 방법

- 유스케이스 문서, 시나리오, 요구사항 분석서, 전문가 인터뷰 자료 활용

　 명사/명사구를 스프레드시트에 입력

- 이 때 중복 혹은 동의어를 고려하지 않고 작업

　 스프레드시트를 정렬하고 중복되는 부분을 삭제

- 단일한 의미의 중복된 형태 삭제(예: 학생과 학생들 학생으로 통일)

- 해당 도메인에 자체에 대한 용어

- 클래스 정의에 적당하지 않은 다른 잡다한 단어(예:중국, 당나라, 방언, 한

국 등)

　 동의어들을 그룹화

- 클래스 이름으로 사용하기 적합한 그룹들을 대표하는 명칭을 선택

예컨대, <그림 6.3>은 한국의 전통술을 정리한 문서의 예이다. 이 문서를 분석하

여 “전통민속주” 온톨로지를 구축하기 위한 클래스 목록을 추출할 수 있다.

위에 언급한 바와 같이 명사를 분석하여 그림 6.4와 같이 정리할 수 있다. <그림

6.4>의 명사 분석 워크시트는 <그림 6.3>의 문서에서 모든 명사를 뽑아내어 정리

한 것이다. 이후 중복되거나 적합하지 않은 단어를 제거한 후 명사 분석 요약 워크

시트와 같은 결과를 얻게 된다. 명사분석 요약 워크시트에서 진한 글씨로 표현된

단어는 클래스로 쓸 수 있는 후보 단어이다. 그리고 동의어는 클래스 후보 단어와

같은 의미로 사용되는 단어들을 말한다. 이것들은 클래스 이름을 정할 때 사용된다.

용어 수집단계에서 정한 클래스 후보 단어가 반드시 클래스 이름으로 결정되는 것

은 아니다.

56

<그림 6. 3> 한국의 전통술에 대한 문서

<그림 6. 4> 명사분석의 예

57

2.2 COM S2 클래스 이름 정의 및 클래스 계층 구조 정의

클래스 이름을 정의하는 것은 온톨로지 모델링에 있어 매우 중요한 일이다. 그러나

온톨로지를 구축할 때 클래스 이름은 대부분 직관에 의존해 정해 진다. 만약 어떤

클래스 이름이 정확하지 않다면 그에 따른 속성이나 다른 클래스와의 관계를 만드

는 것은 불가능하다. 클래스 이름을 정의하고 계층 구조를 만들 때 고려할 규칙은

다음과 같다.

규칙 내용

COM

R2.1

유사어는 통합하여 하나의 클래스로 정의한다.

COM

R2.2

클래스 이름을 명확하게 정의한다.

COM

R2.3

클래스 이름에 대한 다국어 표현을 고려한다.

COM

R2.4

클래스 관계를 순환적으로 정의하지 않는다.

COM

R2.5

단수형을 복수형의 IS-A관계로 정의하지 않는다.

COM

R2.6

계층 구조는 전이적 특성을 갖는다.

COM

R2.7

형제(sibling) 관계는 같은 단계로 정의한다.

COM

R2.8

클래스의 서브클래스가 12개 이상일 경우, 새로운 카테고리를 추가한

다.

COM

R2.9

다중 상속을 고려한다.

COM

R2.10

구축작업의 단순화를 위해 복잡한 관계는 새로운 클래스로 표현하고,

이 클래스와 기존 클래스의 관계를 정의한다.

1) 클래스 이름의 정의

클래스 이름을 정의하기 위한 가장 좋은 방법은 그 정의에서 찾을 수 있다.

“우리가 사용하려 하는 두 개 이상의 속성과 두 개 이상의 개

체를 지닌 동질성의 의미를 가진 독립적인 집합”

58

　 “우리가 사용하려 하는”: 구축하고자 하는 분야의 목적과 범위, 전략에 따라

모든 결정에 향을 주는 요인

　 “두 개 이상의 속성과 두 개 이상의 개체”: 단순한 점이 아닌 집합의 특성이

있음

　 “동질성을 가진 집합”: 집합의 의미부여에 있어 동질성을 갖고 있어야 함

　 “독립적인 집합”: 어떤 다른 집합과는 본질적으로 다른 자기 혼자만의 고유한

집합

위에 열거한 특징들은 어떤 집합이 클래스인지 아닌지 판단할 수 있는지 중요한 기

준이 된다. 예를 들어, “A 회사”를 클래스로 정의했다고 생각해 보자. 이 클래스

의 속성은 회사명, 창립일, 사업자등록번호 등 두 개 이상을 정의할 수 있지만, 개

체가 하나뿐이기 때문에 이것은 클래스로 정의할 수 없다(두 개 이상의 속성과 두

개 이상의 개체). 만약 A 회사가 B, C, D 회사와 같이 계열사를 갖고 있다면 당연

히 클래스일 수 있다. 또 ‘고객’ 이나 ‘회사’라는 클래스가 이미 존재하여 A

회사도 이 클래스의 부분집합으로 정의할 수 있다면 이때도 클래스로 정의하지 않

는다(독립적인 집합).

그러나 집합이라고 해서 모두 클래스가 되는 것은 아니다. 예컨대 ‘직원’ 클래스

가 회사에서 일하는 모든 사원이나 임원들이 모든 집합이라고 하면, ‘정규직’ 이

나 ‘계약직’은 비록 두 개 이상의 속성과 개체를 갖고 있어도 이를 동일 수준의

클래스로 선언하지 않는다. 이 경우는 서브 타입(subtype)으로 정의한다.

또 집합이 클래스가 되기 위해 동질성을 가진 본질적인 집합이 되어야 한다. 예를

들어 ‘직원’을 ‘정규직’만 의미하도록 정의했다면, 계약직이나 협력업체 직원

등은 동질성을 잃게 된다. 반면 회사에서 일하는 모든 사람들이라 하면 이들은 모

두 동질성을 갖게 된다.

“전통민속주” 온톨로지를 구축하는 과정에도 이 기준을 적용할 수 있다. 예컨대,

“순곡주류”는 제조방법, 알코도수, 생산지 등과 같은 두 개 이상의 속성을 갖고

있고, 탁주, 청주, 일반주와 같은 개체를 갖고 있기 때문에 클래스로 정의할 수 있

다. 이 때 순곡주류는 곡물을 사용하여 만드는 술로 정의하여 곡물을 빚어 만드는

다른 종류의 술과 동질성을 갖고, 증류주들과 차별적인 독립성을 갖는다. EOE 방법

론에서는 체계적인 클래스 이름 관리를 위해 <그림 6.5>와 같은 클래스 사전을 제

공하고 있다. 클래스 사전은 명사 분석 요약서나 기존 온톨로지에서 추출한 클래스

이름을 정의한 문서이다.

59

<그림 6. 5> 클래스 사전

2) 클래스 계층의 구분과 계층 구조의 정의

일단 클래스 후보 목록을 찾았다면 다음에 할 일은 이런 클래스들이 서로 어떤 관

계가 있는지 결정하는 것이다. 온톨로지를 구축할 때 클래스는 다음의 세 가지 단

계로 분류할 수 있다.

　 최상위 클래스(first class) : 자신의 부모를 갖지 않는 클래스

　 핵심 클래스(main class) : 최상위 클래스에 의해 탄생된 자식 클래스

분야에 있는 많은 클래스들의 조상에 해당하는 클래스

　 행위 클래스(action class) : 실세계에서 지속적으로 데이터가 생성되는 내용을

갖는 클래스

최상위 클래스는 부모를 갖고 있지 않으므로 제일 상위에 위치하게 된다. 일반적으

로 온톨로지를 모델링할 때, 최상위 클래스는 많지 않다. 그러나 최상위 클래스는

모든 클래스의 주어가 되기 때문에 명확히 정의해야 한다. 최상위 클래스는 온톨로

지를 구축하기 위한 비전과 범위를 정할 때 도출할 수 있다.

핵심 클래스란 부모를 가진 클래스이며 해당 분류의 조상에 위치하는 클래스를 의

미한다. 핵심 클래스는 ‘시조’로 비유할 수 있다. 예컨대, 김씨, 이씨, 박씨는 해

당 씨족의 최상위 조상이 된다. 또 김씨 중에는 ‘안동 김씨’, ‘의성 김씨’ 등으

로 구분되고 이들 또한 해당 본관에서는 최초의 조상이 된다. 즉 핵심 클래스는 관

60

점에 따라 조금씩 달라 질 수 있다. 그러나 해당 분류에서 최상위 조상은 핵심클래

스로 정의한다. 온톨로지 모델링을 할 때 핵심클래스는 2단계 혹은 3단계 수준에

위치하게 된다.

마지막으로 행위 클래스는 ‘자손’에 비유되는데 구분 기준은 매우 간단하다. 최

상위 클래스와 핵심 클래스가 아닌 것은 모두 행위 클래스이다. 행위 클래스는 최

상위와 핵심 클래스에 적용된 집합의 특성에 따라 크게 향을 받는다. 행위 클래

스는 하위 클래스를 많이 갖지 않는다. 만약 하위 클래스가 많아질 경우(보통 12개

이상), 이를 핵심 클래스로 승격시키게 된다.

이러한 구분 기준을 적용하면, “전통민속주” 온톨로지의 클래스는 다음과 같이

분류된다.

최상위 클래스 핵심 클래스 행위클래스

전통민속주 순곡주류

혼양곡주류

순곡증류주

약용증류주

탁주

청주

일반주

이양주

약용곡주류

가향곡주류

단양증류주

이양증류주

삼양증류주

소주-약용증류주

곡물-약용증류주

클래스 분류는 클래스 간의 관계를 설정하는데 기초가 될 수 있다. 클래스 간의 가

장 기본적인 관계는 포함 관계, 즉 IS-A 관계이다. 예컨대, 순곡주류는 전통민속주

의 하위 개념이고, 탁주는 다시 순곡주류의 하위 개념으로 정의할 수 있다. 이와 같

은 관계를 그림 6.6과 같은 개념 관계의 의미 모델로 표현할 수 있다. 여기서 개념

은 클래스와 동일한 의미이며, 특정 개념에 대한 유개념 혹은 종개념의 관계를 갖

고 있다. 또 관련된 개념과의 관계성도 함께 표현할 수 있다.

61

<그림 6. 6> 개념 관계의 의미 모델

　 상위 개념(Super-type): 포섭 관계의 유개념, 다른 개념을 포섭하는 것

　 하위 개념(Sub-type):포섭 관계의 종개념, 다른 개념에 포섭되는 것

　 상위 관련 개념(super-Related) : 상위 개념과 유사하나 개념이 다름

　 하위 관련 개념(Sub-Related) : 상위 개념과 유사하나 개념이 다름

　 관련 개념(Associated) : 참조 가능한 개념

개념관계의 의미 모델은 실제 온톨로지를 구축하기 이전에 개념들의 관계를 도식화

하여 보여준다. <그림 6.7>은 ‘순곡주류’클래스에 대한 의미 모델을 표현하고 있

다.

<그림 6. 7> 순곡주류의 의미 모델

62

그러나 개념 관계의 의미 모델은 개념간의 관계를 도식화하여 직관적으로 보여줄

수 있지만, 시각화에 한계가 있기 때문에 클래스 후보의 모든 것을 표현하는데 한

계가 있다. 이를 보완하기 위해 클래스 사전을 확장한 클래스 관계 사전을 이용할

수 있다(<그림 6.8> 참조).

<그림 6. 8> 클래스 관계 사전

63

2.3 COM S3 속성 목록 정의

각각의 클래스들에 어떤 속성들이 있을 수 있는지를 결정하기 위해 요구사항 명세

나 기타 문서를 살펴볼 수 있다. 또 이미 구축된 시스템이 있다면 관계형 데이터베

이스의 테이블 구조를 분석하여 테이블의 컬럼을 속성으로 선택할 수도 있다.

규칙 내용

COM

R2.1

해당 도메인에서 일반적으로 통용되지 않는 것은 속성으로 정의하지

않는다.

COM

R2.2

수퍼 클래스에 공통적인 속성은 서브 클래스보다 수퍼 클래스에 정의

한다.

COM

R2.3

속성값이 더 이상 분해할 수 없는 특징일 경우 속성으로 정의한다.

COM

R2.4

속성값이 분해할 수 있다면 클래스로 정의하고, 이를 속성 제약으로 정

의한다.

1) 속성과 클래스의 비교

가끔 특정 자료 항목은 사용자의 관점에 따라 속성 또는 클래스로 보일 수 있다.

예컨대, 색상은 술의 색깔이 될 수 있으나 그 자체가 클래스일 수 있다. 클래스로서

색상은 화학적 구성요소나 제조기술 등과 같은 보다 서술적인 속성을 포함하고 있

을 것이다. 그러나 전통민속주에서 술의 색깔은 단순히 전통주가 갖고 있는 한가지

혹은 두 가지의 단편적 색깔만을 나타내면 된다. 즉 전통민속주에서 술의 색깔은

더 이상 분해할 수 없는 정보이기 때문에 속성으로 정의한다.

2.4 COM S4 속성의 제약 조건 정의

규칙 내용

COM

R4.1

요구사항 분석에서 정의한 표현 언어의 특성을 고려한다.

COM

R4.2

각 속성의 정의역, 공역을 정의한다.

COM

R4.3

각 속성의 제약조건은 널(null)을 허용하지 않게 정의한다.

64

COM

R4.4

각 속성의 제약조건은 기본값(default value)을 수용할 수 있다.

COM

R4.5

각 속성의 제약조건은 XML 스키마 형식과 객체 형식으로 구분하여 정

의한다.

COM

R4.6

속성의 제약 조건을 속성 목록에 기록한다.

1) 속성의 형식 정의

웹 온톨로지 언어는 언어의 특성에 따라 속성을 여러 가지로 표현할 수 있다. 예를

들어 RDF는 모든 속성을 rdf:Property로 표현하지만, 속성을 개체 속성(Object

properties)과 데이터형식 속성(Datatype properties)으로 구분하고 있다. 두 가지

속성은 모두 rdf:Property의 하위 클래스이다. 따라서 구축하려는 도메인의 성격과

구현할 언어의 특성을 고려해 속성을 선언해야 한다.

<그림 6. 9> OWL 의 속성 형식

예를 들어, 수강하다(courses)라는 속성을 RDF와 OWL로 정의하면 그림과 같다.

RDF 스키마에서 선언한 속성과 OWL의 그것이 갖고 있는 차이가 있는 것을 볼 수

있다.

OWL의 속성 형식은 두 가지로 구분된다.

　 ObjectProperty : 속성의 값이 클래스나 인스턴스일 때

　 DatatypeProperty : 속성의 값이 XML 스키마 형식이나 리터럴일 때

65

<그림 6. 10> RDF 스키마와 OWL 의 속성의 차이

2) 제약조건의 정의

속성을 제약하는 것은 온톨로지를 구축할 때 발생하는 오류를 최소화 시킬 수 있을

뿐만 아니라 향후 추론 규칙을 구성하는데 많은 향을 미친다.

요소명 의미

owl:allValuesFrom 클래스의 모든 인스턴스에 대해 속성의 모든 값이 제약을

만족하는 것을 나타낸다. 술어논리의 ∀(universal

quantifier)와 같은 의미이다.

owl:someValuesFrom 적어도 하나의 값은 주어진 클래스에 선언돼야 하는 것을

말한다. 술어논리의 ∃(existential quantifier)와 같은 의

미이다.

owl:hasValue 속성의 값을 특정한 개체로 제한할 때 사용한다.

owl:maxCardinality 속성값의 최대 출현 회수

owl:minCardinality 속성값의 최소 출현 회수

owl:cardinality 지정된 회수만 출현 가능

66

예컨대, 일반 탁주의 속성인 “제조소재지” 속성을 생각해 보자. 이 속성은 전통주

를 생산하는 곳을 값으로 갖는다. 이 때 속성의 정의역은 전통민속주 클래스 타입

이어야 하고, 공역은 지역에 대한 값으로 한정할 수 있다. 그리고 속성값은 반드시

1개 이상을 갖고 있어야 한다. 이를 요약하면 다음과 같이 표현할 수 있다.

　 정의역 : 전통민속주의 타입

　 공역 : 지역의 타입

　 minCardinality : 1

　 maxCardinality : 10

EOE 방법론은 위와 같은 속성에 대한 제약조건을 문서화하는 속성 목록서를 제공

한다. 그림은 속성 목록을 이용하여 속성들을 표현한 것이다.

<그림 6. 11> 속성 목록

위에 설명한 예를 Protégé 2를 이용하여 만들면 <그림 6.12>와 같다.

67

<그림 6. 12> 제조소재지 속성의 제약 조건

속성의 제약조건은 특성에 따라 다양할 수 있다. 특히 DatatypeProperty의 경우,

속성값을 Symbol 형식으로 정의할 수 있다. <그림 6.11>에서 주원료, 색상과 같은

속성이 그 예이다. EOE 방법론에서는 심볼 형식의 값을 정리하여 관리할 수 있는

심볼 목록을 사용할 수 있다. <그림 6.13>은 심볼 목록의 예이다.

<그림 6. 13> 심볼 목록의 예

68

2.5 COM S5 공리(axiom)의 선언

공리란 선언적이고 동시에 엄밀하게 표현된 지식으로 그 옳음을 증명하지 않고도

받아들여야 하는 것을 말한다. 논리학에서 공리는 추론의 전제가 되는 지식을 나타

내는데 본질적인 의미가 있다. 온톨로지 구축시 공리는 다음 두 가지 역할을 할 수

있다.

　 어휘/개념의 의미 정의를 엄밀하게 표현하는 것

　 온톨로지에 포함된 어휘/개념을 사용하여 기술된 것이 가진 능력, 즉 온톨로지

의 능력에 관한 질문에 대해 추론하는 것

예컨대, 클래스를 구성하는 개체들을 모두 열거하여 클래스를 정의할 때 사용할 수

있다. 클래스의 구성 개체들은 정확히 열거된 개체들의 집합과 일치한다. 요일을 클

래스로 정의할 때, 개체들-월, 화, 수, 목, 금, 토, 일-을 나열하여 요일

(daysofTheWeek) 클래스를 정의할 있다. 만약 요일 클래스의 어떤 속성이

allValuesFrom 제약의 공역으로 선언되어 있다면, 추론 엔진을 이용하여 그 속성

의 maxCardinality가 7임을 유추할 수 있다. EOE 방법론에서는 공리를 정의하기

위해 <그림 6.14>와 같은 공리 목록서를 제공한다.

<그림 6. 14> 공리 목록서의 예

2.6 COM S6 인스턴스 생성

클래스와 속성을 모두 정의한 후 인스턴스를 정의하게 된다. 인스턴스를 만드는 것

69

은 도구를 이용하는 것이 일반적이다. 현재 온톨로지를 개발하는 도구는 protégé 2

나 WebODE, OntoEdit 등이 대표적이라 할 수 있다. <그림 6.14>는 Protégé 2를

이용하여 순곡증류주의 인스턴스인 안동소주를 그림과 같이 생성할 수 있다.

<그림 6. 15> 인스턴스의 예-안동소주

제 3절 온톨로지의 구현(POI: Physical Ontology Implementation)

이 단계는 개념적 설계를 통해 작성된 온톨로지를 구체적인 표현 언어를 이용해 구

현한다. 온톨로지 언어는 RDF와 OWL을 고려할 수 있다. 구현된 온톨로지

(implemented ontology)에 적용할 언어의 특징은 요구분석 단계에서 결정하게 된

다. 그리고 개념적 설계 단계에서 특정 온톨로지 개발 도구를 이용하여 온톨로지를

개발하게 된다.

“전통민속주” 온톨로지를 개발할 때 사용한 도구는 Protégé 2이다. Protégé 2는

웹 온톨로지 언어, CLIPS, 관계형 데이터베이스 형식으로 온톨로지를 표현할 수 있

다.

다음의 코드는 Protégé 2를 이용하여 구현한 전통민속주 온톨로지의 일부 코드이다.

70

<?xml version="1.0"?>

<rdf:RDF

xmlns:protege="http://protege.stanford.edu/plugins/owl/protege#"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

xmlns:owl="http://www.w3.org/2002/07/owl#"

xmlns="http://www.owl-ontologies.com/unnamed.owl#"

xml:base="http://www.owl-ontologies.com/unnamed.owl">

<owl:Ontology rdf:about="">

<owl:imports rdf:resource="http://protege.stanford.edu/plugins/owl/protege"/>

</owl:Ontology>

<owl:Class rdf:ID="전남">

<rdfs:subClassOf>

<owl:Class rdf:ID="지역"/>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:ID="양조곡주">

<rdfs:subClassOf>

<owl:Class rdf:ID="전통민속주"/>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:ID="Frame0.9494101877258622">

<rdfs:subClassOf>

<owl:Class rdf:ID="순곡증류주"/>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:ID="가향곡주류">

<rdfs:subClassOf>

<owl:Class rdf:ID="혼양곡주류"/>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:ID="서울">

<rdfs:subClassOf rdf:resource="#지역"/>

</owl:Class>

71

<owl:Class rdf:about="#전통민속주">

<rdfs:subClassOf>

<owl:Restriction>

<owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"

>10</owl:maxCardinality>

<owl:onProperty>

<owl:ObjectProperty rdf:ID="제조소재지"/>

</owl:onProperty>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"

>1</owl:minCardinality>

<owl:onProperty>

<owl:ObjectProperty rdf:about="#제조소재지"/>

</owl:onProperty>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:allValuesFrom rdf:resource="#지역"/>

<owl:onProperty>

<owl:ObjectProperty rdf:about="#제조소재지"/>

</owl:onProperty>

</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:ID="경남">


</owl:Class>

<owl:Class rdf:ID="삼양주">

<rdfs:subClassOf>

<owl:Class rdf:ID="일반주"/>

</rdfs:subClassOf>

</owl:Class>

72

<owl:Class rdf:ID="전북">


</owl:Class>

<owl:Class rdf:ID="충남">


</owl:Class>

<owl:Class rdf:ID="약용곡주류">

<rdfs:subClassOf>

<owl:Class rdf:about="#혼양곡주류"/>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:ID="증류주">

<rdfs:subClassOf rdf:resource="#전통민속주"/>

</owl:Class>

<owl:Class rdf:ID="단양약용주">

<rdfs:subClassOf rdf:resource="#약용곡주류"/>

</owl:Class>

<owl:Class rdf:ID="청주">

<rdfs:subClassOf>

<owl:Class rdf:ID="순곡주류"/>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:ID="단양주">

<rdfs:subClassOf>

<owl:Class rdf:about="#일반주"/>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:ID="탁주">

<rdfs:subClassOf>

<owl:Class rdf:about="#순곡주류"/>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Restriction>

<owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"

>3</owl:minCardinality>

<owl:onProperty>

73

<owl:DatatypeProperty rdf:ID="생산지"/>

</owl:onProperty>

</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:ID="특별탁주">

<rdfs:subClassOf rdf:resource="#탁주"/>

</owl:Class>

<owl:Class rdf:ID="이양약용주">

<rdfs:subClassOf rdf:resource="#약용곡주류"/>

</owl:Class>

<owl:Class rdf:ID="경북">


</owl:Class>

<owl:Class rdf:ID="약용증류주">

<rdfs:subClassOf rdf:resource="#증류주"/>

</owl:Class>

<owl:Class rdf:about="#순곡증류주">

<rdfs:subClassOf rdf:resource="#증류주"/>

</owl:Class>

<owl:Class rdf:ID="충북">


</owl:Class>

<owl:Class rdf:ID="경기">


</owl:Class>

<owl:Class rdf:about="#순곡주류">

<rdfs:subClassOf rdf:resource="#양조곡주"/>

</owl:Class>

<owl:Class rdf:ID="이양주">

<rdfs:subClassOf rdf:resource="#순곡주류"/>

</owl:Class>

<owl:Class rdf:about="#혼양곡주류">

<rdfs:subClassOf rdf:resource="#양조곡주"/>

</owl:Class>

<owl:Class rdf:ID="일반탁주">

74

<rdfs:subClassOf rdf:resource="#탁주"/>

</owl:Class>

<owl:Class rdf:about="#일반주">

<rdfs:subClassOf rdf:resource="#순곡주류"/>

</owl:Class>

<owl:ObjectProperty rdf:ID="korea_Slot_5"/>

<owl:ObjectProperty rdf:about="#제조소재지">

<protege:allowedParent rdf:resource="#지역"/>

<protege:allowedParent rdf:resource="http://www.w3.org/2002/07/owl#Thing"/>

<rdfs:domain rdf:resource="#전통민속주"/>

<rdfs:range rdf:resource="http://www.w3.org/2002/07/owl#Class"/>

</owl:ObjectProperty>

<owl:DatatypeProperty rdf:ID="전화번호">


<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>

</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="korea_Slot_4">



<owl:DatatypeProperty rdf:ID="추천부서">




<owl:DatatypeProperty rdf:ID="무형문화재지정">




<owl:DatatypeProperty rdf:ID="판매상호">




<owl:DatatypeProperty rdf:ID="생산자형태">




<owl:DatatypeProperty rdf:ID="vksao">

75



<owl:DatatypeProperty rdf:ID="색상">

<rdfs:range>

<owl:DataRange>

<owl:oneOf rdf:parseType="Resource">

<rdf:rest rdf:parseType="Resource">

<rdf:first rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>투명</rdf:first>

<rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-

ns#nil"/>

</rdf:rest>


>빨강</rdf:first>

</owl:oneOf>

</owl:DataRange>

</rdfs:range>






<owl:DatatypeProperty rdf:ID="민속주이름">




<owl:DatatypeProperty rdf:ID="알콜도수">

<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/>



<owl:DatatypeProperty rdf:ID="주원료">


<rdfs:range>

<owl:DataRange>

<owl:oneOf rdf:parseType="Resource">

<rdf:rest rdf:parseType="Resource">

76

<rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-

ns#nil"/>


>찹쌀</rdf:first>

</rdf:rest>


>누룩</rdf:first>

</owl:oneOf>

</owl:DataRange>

</rdfs:range>


<owl:DatatypeProperty rdf:ID="주소">




<owl:DatatypeProperty rdf:about="#생산지">

<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/>


<owl:DatatypeProperty rdf:ID="자원보유자">







<순곡증류주 rdf:ID="korea_Individual_53"/>

<순곡증류주 rdf:ID="안동소주">

<색상 rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>투명</색상>

<무형문화재지정 rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>박재서(농림부지정 명인6호)</무형문화재지정>

<생산자형태 rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>개인</생산자형태>

<추천부서 rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>문화관광부</추천부서>

<owl:versionInfo rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

77

>1.0</owl:versionInfo>

<판매상호 rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>안동소주(安東燒酒)</판매상호>

<자원보유자 rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>조옥화</자원보유자>

<주원료 rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>누룩</주원료>

<제조소재지 rdf:resource="#경북"/>

<무형문화재지정 rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>조옥화(경북 무형문화재 12호)</무형문화재지정>

<자원보유자 rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>박재서</자원보유자>

<rdfs:seeAlso>

<순곡증류주 rdf:ID="한산소곡주"/>

</rdfs:seeAlso>

<민속주이름 rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>안동소주</민속주이름>

<전화번호 rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>054-858-4541</전화번호>

<주소 rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>경북 안동시 수상동 280번지</주소>

</순곡증류주>

</rdf:RDF>



78

제7장. 결론

본 연구에서는 온톨로지를 구축하기 위해 적용될 수 있는 개발방법론에 대해 살

펴보았다. 특정한 목적에 맞는 온톨로지를 개발하는 것은 사용자의 목적을 정확하

게 파악하는 것과 동시에 도메인 전문가, 온톨로지 개발자의 협력적인 작업이 필요

하다. 그동안 연구되거나 발표된 온톨로지 개발방법론은 여러 프로젝트에서 이미

검증되었다고 하나 실제 프로젝트에 적용하는데 한계가 있다. 본 연구에서 소개한

EOE 방법론은 실제 활용 가능한 개발방법론을 제시하고 있다. EOE 방법론의 특징

은 다음과 같다. 첫째, 진화형 프로토타입을 기반으로 온톨로지를 순환적으로 개발

할 수 있다. 둘째, 각 단계가 마무리되기 전에 점검 포인트를 두어 불완전한 요구사

항을 수정할 수 있다. 셋째, 각 단계의 작업을 모두 문서화함으로써 향후 프로젝트

에 재사용할 수 있다. 넷째, 각 단계에서 실행해야 하는 작업의 기준(criteria)을 제

공하여 온톨로지 개발을 쉽게 할 수 있다.

EOE 방법론은 선행 연구결과들을 이용하여 이론적 토대를 제공한 반면, 개발에

활용할 수 있는 애플리케이션을 제공하지 못하고 있다. 현재 온톨로지 개발에 사용

할 수 있는 애플리케이션은 Protégé 2, WebODE, OntoEdit 등과 같은 제품에 한정

된다. 그러나 이것들은 한글 지원이 미흡에 우리나라에서 바로 활용하는데 한계가

있다. 따라서 온톨로지 개발방법론과 더불어 활용 가능한 애플리케이션의 개발도

요구된다.

EOE 방법론은 온톨로지 개발에 있어 필요한 단계에 따라 일정한 기준을 제공했

다는 점에서 연구의 의의를 찾을 수 있다. 그러나 본 방법론에서 제공한 기준들은

견해의 차이가 있을 수 있고, 수용하기 힘든 기준들도 있을 수 있다. 이런 부분들은

진지한 토론과 연구를 통해 해결할 수 있을 것으로 본다.

79

부록 A. 개념 사전

개념이름 문명 설명 동의어 약어 형식

민속주 Korea Liquor

주로 쌀과 기타의 곡류, 식물약재 및 누룩등을 사용하여 제조하며 약주류, 탁주류, 소주류, 약용주류(가향주류) 등으로 분류할 수 있음

전통술, 전통주, 토속주 민속전통주, 대중주

클래스

순곡주류 곡물(멥쌀, 찹쌀, 보리, 밀가루, 콩, 기장, 수수, 메기장, 촉)에 누룩과 물을 넣고 빚은 술

순곡주 클래스

일반주 누룩, 물을 넣어 빚어서 술항아리에 담아 발효시킨 술 클래스

한산소곡주

멥쌀, 찹쌀, 엿기름, 고추, 들국화 및 누룩을 원료로 하여 2 단담금으로 100 일간 발효 숙성시켜 여과한 알콜분 18 도의 약주로 엑스분 함량이 높고 일반적으로 주류 제조에 사용하지 않는 고추를 사용하는 것이 특이하며 산림경제, 증보산림경제, 동국세시기 등의 문헌에 수록

소곡주, 앉은뱅이 술 인스턴스

삼해주 멥쌀,찹쌀 및 누룩을 원료로하여 3 단담금으로 발효시켜 여과한 알콜분 11 도의 약주로 음식지미방, 지봉유설, 산림경제, 증보산림경제, 임원십육지, 양주방, 동 국세시기 및 주방분 등의 문헌에 수록

백일주, 삼해약주 인스턴스

면천두견주 찹쌀, 진달래꽃 및 누룩을 원료로 하여 2 단담금으로 발효시켜 여과한 알콜분 19 도의 약주로 급수비율이 낮아 엑스분 함량이 높으며 산림경제, 규합총서, 동국세 시기 등의 문헌에 수록

진달래 꽃술 두견주 인스턴스

이양주 술 처방대로 재료를 혼합해서 비스듬히 누운 소나무를 파거나, 살아있는 대나무 마디사이에 구멍을 내거나 하여 빚은 술

클래스

국화주 찹쌀, 국화, 생지황, 구기자근피 및 누룩을 원료로 하여 1 단담금으로 발효시켜 여과한 알콜분 16 도의 약주로 임원십육지, 동의보감 등의 문헌에 수록

연명주, 불로장생주 인스턴스

80

부록 B. 클래스 사전

클래스명 한자 혹은

문 설명 속성 상위클래스 하위클래스

민속주 民俗酒 주로 쌀과 기타의 곡류, 식물약재 및 누룩 등을 사용하여 제조하며 약주류, 탁주류, 소주류, 약용주류(가향주류) 등으로 분류할 수 있음

- 순곡주류, 혼양곡주류, 증류주

순곡주류 純穀酒類 곡물(멥쌀,찹쌀, 보리, 밀가루, 콩, 기장, 수수, 메기장, 촉)에 누룩과 물을 넣고 빚은 술

민속주 탁주, 청주 일반주, 이양주

혼양곡주류 混釀穀酒類 향약재, 꽃, 과실 등을 술에 첨가하거나 처음부터 함께 빚어 만든 술 약용곡주(藥用穀酒), 가향곡주(加香穀酒), 과실주(果實酒)가 있으며, 곡물에 소주를 넣어 빚은 혼성주(混成酒)도 여기에 포함

민속주 약용곡주류 가향곡주류

증류주 蒸溜酒 알코올 발효가 끝난 술을 가열시켜 증류한 것 민속주 순곡증류주 약용증류주

순곡증류주 純穀蒸溜酒 순곡주를 증류시킨 술 증류주 단양증류주 이양증류주 삼양증류주

약용증류주 藥用蒸溜酒 약재를 넣어 만든 증류주 증류주 소주-증류주 곡물-증류주

탁주 濁酒 체에 걸러 뿌옇고 텁텁하게 만든 술 순곡주류 일반탁주 특별탁주

청주 淸酒 용수를 박아 떠낸 맑은 술 순곡주류 -

일반주 一般酒 곡물, 누룩과 물을 독에 넣어 발효시킨 보통의 술 순곡주류 단양주,이양주, 삼양주, 사양주

81

부록 C. 클래스 관계 사전

클래스명 한자 혹은

문 설명 상위클래스 하위클래스 상위관련개념 하위관련개념

민속주 民俗酒 주로 쌀과 기타의 곡류, 식물약재 및 누룩 등을 사용하여 제조하며 약주류, 탁주류, 소주류, 약용주류(가향주류) 등으로 분류할 수 있음

- 순곡주류, 혼양곡주류, 증류주

순곡주류 純穀酒類 곡물(멥쌀,찹쌀, 보리, 밀가루, 콩, 기장, 수수, 메기장, 촉)에 누룩과 물을 넣고 빚은 술

민속주 탁주, 청주 일반주, 이양주

혼양곡주류 混釀穀酒類

향약재, 꽃, 과실 등을 술에 첨가하거나 처음부터 함께 빚어 만든 술 약용곡주(藥用穀酒), 가향곡주(加香穀酒), 과실주(果實酒)가 있으며, 곡물에 소주를 넣어 빚은 혼성주(混成酒)도 여기에 포함

민속주 약용곡주류 가향곡주류

증류주 蒸溜酒 알코올 발효가 끝난 술을 가열시켜 증류한 것 민속주 순곡증류주 약용증류주

순곡증류주 純穀蒸溜酒 순곡주를 증류시킨 술 증류주 단양증류주 이양증류주 삼양증류주

약용증류주 藥用蒸溜酒 약재를 넣어 만든 증류주 증류주 소주-증류주 곡물-증류주

탁주 濁酒 체에 걸러 뿌옇고 텁텁하게 만든 술 순곡주류 일반탁주 특별탁주

청주 淸酒 용수를 박아 떠낸 맑은 술 순곡주류 -

일반주 一般酒 곡물, 누룩과 물을 독에 넣어 발효시킨 보통의 술 순곡주류 단양주,이양주, 삼양주, 사양주

82

부록 D. 속성 목록

속성명 설명 속성형식 속성 형식 값형식 범위 차수 정의역 공역

민속주 이름 해당 민속주의 고유 명칭 DataTypeProperty 클래스 String XSD

Type 1

제조소재지 생산지(시 또는 군 단위) ObjectProperty 클래스 Class 지정값 (1, 10)

주원료 민속주를 만드는데 쓰이는 재료 DataTypeProperty 클래스 Symbol 지정값 (1, n)

추천부서 민속주 허가를 인가한 곳 DataTypeProperty 인스턴스 String XSD

Type (1, 1)

제조방법 민속주를 만드는 방법 DataTypeProperty 인스턴스 String XSD

Type (null, n)

무형문화재지정 무형문화재 지정 여부 DataTypeProperty 인스턴스 String XSD

Type (1, n)

자원보유자 지적재산권 보유자 DataTypeProperty 인스턴스 String XSD

Type (1,1)

판매점수 전국의 유통업체수 DataTypeProperty 인스턴스 String XSD

Type (1, n)

향토지적재산생산자

현재 민속주를 생산하는 자 DataTypeProperty 인스턴스 String XSD

Type (1, n)

색상 민속주의 색 DataTypeProperty 클래스 Symbol 지정값 (1, n) 알코올도수 알코올도수 DataTypeProperty 클래스 Integer 1~100 (1, 1)

상호 제조업체의 상호 DataTypeProperty 인스턴스 String XSD

Type (1, n)

전화번호 제조업체의 전화번호 DataTypeProperty 인스턴스 String XSD

Type (null, n)

주소 제조업체의 주소 DataTypeProperty 인스턴스 String XSD

Type (null, n)

포장용기 용기의 종류 DataTypeProperty 인스턴스 Symbol 지정값 (1, n)

생산자형태 민속주 생산의 형태 DataTypeProperty 인스턴스 Symbol 지정값 (null, n)

이메일 제조업체의 이메일 DataTypeProperty 인스턴스 String XSD

Type (null, n)

83

부록 E. 심볼 목록

심볼명 설명 적용 속성 값형식 범위 차수 비고

맵쌀 쪄서 약간 말린 다음에 찧어서 껍질을 벗긴 메밀

주원료 String XSD Type

(null, 1)

누룩 밀을 굵게 갈아 반죽하여 띄운 것 주원료 String XSD Type (null, 1)

옥수수 볏과의 일년초 주원료 String XSD Type (null, 1)

조청 묽게 곤 엿, 물엿 주원료 String XSD Type

(null, 1)

계피 계수나무의 껍질’을 약재로 이르는 말 주원료 String XSD Type (null, 1)

찹쌀 찰벼를 찧은 쌀 주원료 String XSD Type (null, 1)

현미 왕겨만 벗기고 쓿지 않은 쌀 주원료 String XSD Type (null, 1)

구기자 구기자나무의 열매 주원료 String XSD Type (null, 1)

엿기름 보리에 물을 부어 싹을 내어서 말린 것 주원료 String XSD Type (null, 1)

사삼 말린 더덕의 뿌리’를 약재로 이르는 말 주원료 String XSD Type (null, 1)

생지황 한방에서, ‘지황 뿌리의 날것’을 이르는 말

주원료 String XSD Type

(null, 1)

솔잎 소나무의 잎 주원료 String XSD Type (null, 1)

연엽 연의 잎. 하엽(荷葉) 주원료 String XSD Type (null, 1)

자초 지치의 뿌리 주원료 String XSD Type (null, 1)

문화관광부 추천부서 String XSD Type (null, 1)

건설교통부 추천부서 String XSD Type

(null, 1)

농림부 추천부서 String XSD Type

(null, 1)

84

참고 문헌

1. Farquhar, A., Fikes, R., Rice, J.1997. “The Ontolingua Server: A tool for collaborative ontology construction”, International Journal of Human-Computer Studies, 46(6): pp.707　727

2. Fikes, R., Farquhar, A., 1999. "Distributed repositories of highly expressive reusable ontologies", IEEE Intelligent Systems & Their Applications, 14(2) Mar-Apr, pp. 73-79.

3. Gruber, T.R. 1993. “A translation approach to portable ontologies”, Knowledge Acquisition, 5(2), pp. 199-220.

4. Guarino, N. 1995. “Formal Ontology, Conceptual Analysis and Knowledge Representation”, International Journal of Human and Computer Studies, 43(5/6), pp. 625-640.

5. Sowa, J. 2000. “Ontology, Metadata, and Semiotics”, International Conference on Conceptual Structures, ICCS'2000, pp. 4-18 August 2000, Darmstadt, Germany

6. Uschold, M., Grüninger M., 1996. "ONTOLOGIES: Principles, Methods and Applications" Knowledge Engineering review 11(2), pp. 93-155.

7. van Heijst, G, Falasconi, S., Abu-Hanna, A, Schraber, G., Stefanelli, M. 1995. “A Case Study in Ontology Library Construction”. Artificial Intelligence in Medicine 7, pp. 227-255.

8. Sowa, J. F. 2000. “Knowledge representation Logical, Philosophical, and Computational Foundations”. Brooks/Cole, Pacific Groove, CA, USA

9. Staab, S., Schnurr, H. P., Studer, R., Sure Y. 2001. "Knowledge Processes and Ontologies." IEEE Intelligent Systems. 16(1) pp. 26-34.

10. Guarino, N. 1998. “Formal Ontology and Information systems”. Proceedings of FOIS'98, Amsterdam, IOS Press.

11. Vasconcelos, J. Gouveia, F. Kimble C. 2002. “An Organizational Memory Information System using Ontologies”. Proceedings of the 3rd Conference of the Associação Portuguesa de Sistemas de Informação. University of Coimbra, Portugal, November

12. Fonseca, F.T., Egenhofer, M.J., Davis, C., Camara, G. 2002. “Semantic granularity on ontology-driven geographic information systems”, Annals of Mathematics and Artificial Intelligence. 36(1):121-134

13. Jennings, N.R, Wooldridge M. 1995 “Applying Agent

Technology, Applied Artificial Intelligence”, An International Journal, Taylor & Francis London, 9 (4) pp.51-361

85

14. Wooldridge, M., Jennings, N. R. 1995. "Intelligent Agents: Theory and Practice." Knowledge Engineering Review 10(2) pp.115-161.

15. Zambonelli, F., Jennings, N. R., Omicini, A., Wooldridge, M. 2000. “Coordination of Internet Agents: Models”, Technologies and Applications. Springer.

16. Cabri G., Leonardi, L. Zambonelli F. 2000. "Mobile-agent Coordination Models for Internet Applications", IEEE Computer Magazine, Vol. 33, No. 2, Feb.

17. Barbuceanu, M. and Fox, M.S., 1994 “The Information Agent: An infrastructure agent supporting collaborative enterprise architectures”, In Third Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises,

18. Jennings, R. J. 2000. On agent-based software engineering. Artificial Intelligence 117: 277　296

19. Ding, Y. 2001. “A review of ontologies with the Semantic Web in view”, Journal of Information Science, 27(6): p. 377-388.

20. Fensel, D., Harmelen, F., Horrocks, I., McGuinness, D. L., Patel-Schnaider, P. F. 2001. “OIL: An Ontology Infructructure for Semantic Web”, IEEE Intelligent systems, March/April. pp. 38-45.

21. Guarino, N., Masolo, C., Vetere, G. 1999. "OntoSeek: Content-Based Access to the Web." IEEE Intelligent Systems & Their Applications 14(3): 70-80.

22. Harmelen, F. 2002. “How the Semantic Web will change KR: challenges and opportunities for a new research agenda”. The Knowledge Engineering Review, 2002. 17(1).

23. Staab, S., Maedche, A. 2001. “Knowledge portals --- ontologies at work”, AI Magazine, 2001. 21(2).

24. Ding, Y., Fensel, D., Klein, M.,Omelayenko, b. 2002. “The Semantic Web: Yet Another Hip?” - to appear in Data and Knowledge Engineering, 2002, 18.12.01

25. Staab, S., Maedche, A., Handschuh, S. 2001. An annotation framework for the semantic web. In Proceedings of the First Workshop on Multimedia Annotation, Tokyo, Japan.

26. Stojanovic, N., Maedche, A., Staab, S., Studer, R., Sure, Y. 2001. SEAL: a framework for developing SEmantic PortALs. In Proceedings of K-CAP 2001.

27. Fox, M. S., Gruninger, M. 1999. "Ontologies for Enterprise Integration". Department of Industrial Engineering,, University of Ontario.

86

28. Malone, T. W., Crowston, K., Lee, J., Pentland, B., Dellarocas, C., Wyner, G., Quimby, J., Osborn, C. S., Bernstain, A., Hermen, G., Klein, M., O’Donnel, E. 1999. “Tools for Inventing organizations: Towards a Handbook of Organizational Processes”, Management Science, 45(3), pp. 425-443

29. Ushold, M., King, M., Moralee, S., Zorgios, Y. 1998. "The Enterprise Ontology." The Knowledge Engineering Review, 13 (Special Issue on Putting Ontologies to Use).

30. Gruninger, M., Fox, M. S. 1996. The Logic of Enterprise Modelling. In Modelling and Methodologies for Enterprise Integration, pages 140　157.

31. Gruninger, M., Atefi, K., Fox, M. S., 2000. “Ontologies to Support Process Integration in Enterprise Engineering”, Computational & Mathematical Organization Theory 6, 381　394, 2000.

32. Kim, H. M., Fox, M. S., Grüninger, M. 2001. "Construction of Ontology Based Enterprise Models for E-Commerce", Work Report, Schulich School of Business, York University, 4700 Keele St., Toronto, Ontario Canada, M3J 1P3.

33. Fox, M., Barbuceanu, M., Teigen, R. 2000. “Agent-Oriented Supply-Chain Management”, The International Journal of Flexible Manufacturing Systems, 12, pp. 165　188.

34. Swaminathan, J. M., Smith, S. F., Sadeh, N. M. 1998. “Modeling Supply Chain Dynamics:A Multiagent Approach” Decision Sciences, 29 (3), Summer.

35. Norman, T. J., Preece, A., Chalmers, S., Jennings, N. R., Luck, M., Dang, V. D., Nguyen, T. D., Deora, V., Shao, J., Gray, A. and Fiddian, N. (2004) Agent-based formation of virtual organisations. Int. J. Knowledge Based Systems.

87

연구책임자 : 류광택 연구위원

(한국전산원 정보화기술기획팀, 02-2131-0440, [email protected])

웹 온톨로지 개발 지침 연구

2004년 12월 인쇄

2004년 12월 발행

● 발행인 : 서 삼 영

● 발행처 : 한국전산원

경기도 용인시 수지읍 죽전리 168

TEL : 031-260-2114

● 인 쇄 :

TEL :

<비매품>

1. 본 연구보고서는 정보통신부의 출연금으로 수행한 정보통신연구개발사업의 연구결과입니

다.

2. 본 연구보고서의 내용을 발표할 때에는 반드시 정보통신부 정보통신연구개발사업의 연구

결과임을 밝혀야 합니다.

Date post:	03-Mar-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

웹 온톨로지 개발지침 연구 - ITFINDagent.itfind.or.kr/Datarpt/Web_R_13.pdfiii 요 약 문...

Documents