온톨로지에 대한 포스팅이 꽤나 지체되었다. 지난 포스팅에서는 W3C의 RDF/OWL에 대해서 간략하게 이야기 해 보았다. 지금에서야 RDF/OWL은 이렇다, 라고 정리하는 내용이 없다는 사실을 알았지만 아직도 발전하고 변화되고 있는 상황에서 딱히 결론 내릴 수도 없는 노릇이라 나중에 기회가 된다면 포스팅 하도록 하겠다.
이번 포스팅에서는 ISO의 TopicMaps에 대해 이야기 해보고자 한다. RDF와 TopicMaps의 차이는 많지만(생각하기 나름이지만, 개인적으로 차이가 많다고 생각한다.) 가장 특징적인 차이는 RDF가 추론을 위한 체계라면 TopicMaps는 관계를 표현하기 위한 체계이다. RDF도 관계를 표현한다고 해놓고선 이건 무슨 소린가! 하실 분들이 있다면 공부 좀 하신 분이라 생각한다. 짝짝짝~. RDF는 관계를 표현한다. 맞다. 그런데 좀 틀리기도 하다. RDF가 표현하는 관계는 기계가 먼저 본다. 즉, RDF에서 정의한 관계들을 바탕으로 새로운 관계를 기계가 판단하여 인간에게 보여준다는 것이다. TopicMaps는 기계가 추론하도록 놔두지 않는다. 즉, TopicMaps에서 정의된 관계들은 기계가 보기 좋게 정리하여 인간에게 보여 준 뒤 인간이 관계를 통해 추론하고 판단할 수 있도록 한다는 것이다.
|
TopicMaps의 시작 |
TopicMaps는 책의 색인과 같은 개념으로 구성되었다. 두꺼운 책의 맨 뒤에 있는 색인은 어떤 용어에 대한 내용이 몇 페이지에 있는지 지시하며 경우에 따라서는 철자에 따라, 분야에 따라, 장르에 따라 다양하게 분류되어 있다. TopicMaps는 이런 개념에 대한 구체적인 정보를 지시하는 색인과 같은 역할을 전자적으로 수행하는 것이다.
TopicMaps에서는 지식을 지식층과 정보층으로 나누고 있다. 지식층은 개념과 개념 간의 관계를 표현하고 정보층은 개념에 대한 구체적인 정보를 담고 있다. 정보층이 정보 간에 의미적인 관계를 맺고 있지 못한 웹이라고 한다면 지식층은 개념을 정의하고 관계를 정의한 온톨로지라고 할 수 있다.
TopicMaps는 개념을 정의하고 그 개념에 대한 구체적인 정보를 담기도 하지만 이 정보의 위치를 지시하여(URL 따위로) 정보 검색의 바탕을 마련한다. TopicMaps가 온톨로지라고 할 수 있는 것은 이 정의된 개념을 연결하는 방법을 제공하기 때문이다. 또한 이 연결의 방법은 미리 만들어 두었지만 그 표현의 방법은 자유롭게 하여 다양한 관계의 표현이 가능하기 때문에 보다 의미를 담아 관계를 표현할 수 있다는 점에서 RDF와 차이가 있다고 할 수 있다. 단점이라고 한다면 그 관계를 바탕으로 인간이 선택을 해야 한다는, 즉 자동추론은 어렵다는 단점이 있지만 기계가 정확한 추론이 가능하기 전까지는 큰 단점이라 하기는 어렵지 않을까 한다.
|
TopicMaps의 TAO |
TopicMaps의 선구자라 할 수 있는 Steve Pepper(이분 한국에서는 자기를 후추씨라고 소개한다 ㅎㅎ)는 TopicMaps의 개념을 설명할 때 TAO라는 말을 잘 사용한다. TAO 즉 topics, associations, occurrences(이하 토픽, 연계, 어커런스)는 TopicMaps 기본 개념으로 정보 자원들의 구조와 관련 정보를 정의하고 정보를 제공하는데 사용된다. 이 TAO를 간략하게 설명하면 다음과 같다.
|
기본 개념 |
설명 |
|
토픽(Topic) |
실세계의 주제를 기계가독형으로 변환한 개념적 주제 |
|
연계(Association) |
다른 토픽과의 연관관계 |
|
어커런스(Occurrence) |
토픽과 관련된 정보 자원 또는 그 링크 |
실세계니 기계가독형이니 말이 좀 어려우니 풀어보자. 토픽은 쉽게 말해 내가 이야기 하고 싶은 것, 그 '것(thing)'의 이름이다. 연계는 그 '것'들 간의 관계를 설명하는 것이고 어커런스는 그 '것'에 대한 구체적인 정보이다. RDF와 비교하자면 토픽은 클래스, 연계는 속성(property)이라고 할 수 있다. 완전히 같은 것이라고는 말하기 힘들다. 특별히 어커런스와 인스턴스는 같은 것이라고 할 수도 있지만 아주 적은 공통점만 가질 뿐이다.
토픽, 연계, 어커런스는 타입이라는 조금 까다로우면서 복잡한 개념이 적용된다. 이 타입은 '묶음'이라고 생각하면 조금 편하다. TAO를 설명하면서 이 타입에 대해 함께 알아보도록 하겠다.
토픽은 우리 주변의 사물과 개념을 모두 표현할 수 있는데, 프로그래머, 디자이너, 승용차, SUV가 그것이다. 이 프로그래머와 디자이너는 직원이라는 개념으로 묶이고 승용자와 SUV는 차종이라는 개념으로 묶인다. 이러한 묶음을 타입이라 하며 구체적으로는 토픽타입이다.
연계는 토픽 간의 관계를 표현한다. 이 관계는 양방향으로 표현하는 것을 원칙으로 한다. '철수의 아버지는 영철씨다'라는 문장에서 '의 아버지는'이 연계인데 좀 더 TopicMaps에 맞게 고치자면 '1촌'이나 '혈육' 정도로 쓸 수 있겠다. 여기서 철수와 영철씨 사이에만 사용된 '혈육'이라는 관계 표현이 연계이고 철수와 영철씨 사이뿐만 아니라 영희와 영숙씨 사이에도 사용되면 연계타입이 된다. 연계는 대부분 연계타입이 된다고 편하게 생각해도 되겠다.
어커런스는 개념에 대한 정보를 말한다. 철수의 나이인 19세, 성별인 남자, 신장인 170cm 등이 그 것인데 여기서 나이, 성별, 신장이 어커런스타입이다
TopicMaps가 어려워지는 부분은 이 타입에 있다. 토픽의 '직원'과 어커런스의 '신장'이 개념 수준에서 무슨 차이가 있을까? 답은 '없다'이다. 직원이나 신장이나 사용의 차이만 있지 개념 수준에서는 어쨌거나 같은 개념이지 다를 건 뭔가. 하지만 TopicMaps에서는 이들의 차이가 있다. 필요의 차이이다. '신장'이라는 정보가 모아져서 따로 관리되어야 한다면 토픽타입이 되어야 한다. 회사의 데이터베이스에서는 직원의 신장 따위 중요하지 않으니 그저 확인하는 정도로 그치면 그만인 정보이지만 신사복 매장의 데이터베이스에서는 고객의 신장은 매우 중요한 정보이니 따로 관리해야 할 것이다.
조금 더 어려운 이야기. 지금까지 살펴본 토픽, 연계, 어커런스는 타입의 수준에서는 모두 토픽이 된다. 흠.. 이건 또 뭔가 ㅡㅡ; 앞에서 말했듯이 토픽은 모든 사물과 개념을 표현한다. 연계타입의 '혈육'은 개념, 어커런스타입의 '신장' 또한 개념이다. 따라서 토픽이 될 수 있다. ㅎㅎ 이것참…
|
TopicMaps의 식별과 제한 |
TopicMaps에는 TAO외에 주제식별자, 주제지시자, 공용주제지시자, Scope, Role이 있다.
주제식별자(Subject Identifier)는 기계적으로 TAO를 구별하고 알아보기 위한 고유한 식별자로 사람으로 치면 주민등록번호 정도 되겠다. 주제지시자(Subject Indicator)는 TAO를 사람이 알아보고 이해할 수 있도록 이 식별자로 연결된, TAO를 설명하는 문서이다. 한 조직 내에서, 그러니까 회사 내에서 사용되는 데이터베이스에서는 이런 주제식별자와 주제지시자를 직원들 끼리 합의한 내용으로 사용할 수 있지만 그 범위가 넓어지면 좀체 합의하기는 어렵다. 공용주제지시자(Published SubjectIndicator)는 이런 경우에 활용할 수 있는 식별자이다. 모든 사람들이 접근할 수 있는 장소에 개념을 정의하고 정의된 개념을 여러 사람들이 공유하는 것이다. 이런 주제식별자, 주제지시자, 공용주제지시자는 토픽과 연계, 어커런스를 확실하게 구별하여 지시하는 정보를 여러 번 사용할 수 있게 한다.
Scope는 타입과는 다른 의미에서의 묶음인데 예를 들어 언어, 연대와 같은 우리가 흔히 범주라고 이야기 하는 것들로 정보의 탐색 범위를 제한하는 것과 같은 역할을 한다. Role은 연계에 있어서 각 토픽의 역할은 무엇인가를 표현하는 것으로, 직원으로써 영철씨는 '과장'이지만 혈육 관계에서는 '아버지'로 표현할 수 있도록 한다. Role역시 제한하는 기능을 하여 Scope와 함께 검색 과정에서 필터링할 수 있는 바탕이 된다.
|
TopicMaps의 특징 |
RDF/OWL은 자동추론이 가능하다(그렇다고 하는데 아직 보지는 못했다 ㅡㅡ;). 클래스 간의 관계를 바탕으로 인스턴스, 즉 정보 간의 관계를 추론하는 것이다. 이 자동추론을 위해서는 SPAQL과 같은 고급 쿼리 언어가 필요하다. 일반인이 이 쿼리를 작성하기는 너무나 어려운 일인데다 자연어를 분석해서 쿼리를 기계가 작성하는 것도 아직은 어렵다. 이에 반해 TopicMaps는 하나의 토픽에 대해 연결된 다양한 정보를 관계를 바탕으로 정리하여 보여준다. 어떤 면에서는 온톨로지라고 하기엔 민망한 점이 있다. 추론을 하지 않으니… 그 때문에 일각에서는 TopicMaps는 온톨로지가 아니라고 하는 의견도 있다.
하나의 정보(토픽)에 대해 관련된 정보만을 정리해서 보여주는 TopicMaps는 내가 찾고자 하는 것이 확실하지 않을 때 유용하다. 다양한 정보를, 그것도 연관된 정보만을 어떤 관계가 있는지 정리하여 보여주기 때문에 내가 미처 알지 못했던 정보를 발견 할 수 있는 기회를 얻게 되는 것이다. RDF가 그런 기회를 박탈한다는 것은 아니지만(사실 그런지도 모르겠다) TopicMaps는 연관 정보의 표시에 주력하고 있는 만큼, 인간에게 의미 있는 정보를 판단할 수 있는 기회를 보다 많이 주고 있다고 할 수 있겠다.
'ontoBox' 카테고리의 다른 글
| 정보 그리고 온톨로지 : 목록에 대하여 (0) | 2009/11/22 |
|---|---|
| 정보 그리고 온톨로지 : 온톨로지의 밑바닥에 대하여 (2) | 2009/07/01 |
| 온톨로지를 이해하기: 온톨로지 언어 Part 2 (0) | 2009/04/04 |
| 온톨로지를 이해하기: 온톨로지 언어 Part 1 (0) | 2009/01/31 |
| 온톨로지를 이해하기: 온톨로지의 종류 (0) | 2009/01/30 |
| 온톨로지를 이해해보기: 기본 요소 (0) | 2008/08/02 |