readholic.com

온톨로지에 대한 포스팅이 꽤나 지체되었다. 지난 포스팅에서는 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는 연관 정보의 표시에 주력하고 있는 만큼, 인간에게 의미 있는 정보를 판단할 수 있는 기회를 보다 많이 주고 있다고 할 수 있겠다.

온톨로지의 종류에 대한 포스팅이 아직 따끈따끈한 터라 다음 포스트가 좀 빠르다는 생각이 들기도 한다. 사실은 본 포스팅을 준비하다 온톨로지의 종류에 대해 이야기할 필요가 있을 것 같아 급하게 쓴 것이었다. 각설하고, 온톨로지가 지식을 표현하고 포착하기 위한 도구로써 많이 연구되고 개발되고 있다는 것을 알았으니 온톨로지가 어떻게 만들어지는지도 알아봐야 할 것이다.

비단 IT 분야뿐만 아니라 다양한 분야에서 온톨로지가 화두로 떠오르면서 온톨로지 자체가 하나의 시스템으로 오해하는 경향이 있는 것 같다. 온톨로지는 데이터 모델링, 그러니까 데이터를 의미적으로 다루기 위한 이상적 방법이지 구체적인 시스템을 구현하기 위한 기술이 아니다. 다시 말해 '온톨로지 ≠ 시스템'인 것이다. 그렇다면 온톨로지를 시스템화(다음부터는 '구현'이라 한다)하기 위해서는 어떤 것들이 필요할까? 결론만 말하자면 온톨로지 구현을 위한 개발언어를 사용하면 된다.

이러한 개발언어는 정보처리기사 자격증 시험을 준비한 사람들이라면 좀 알고 있는 코볼과 C에서부터 마크업랭귀지인 HTML, XML등이 있다. 온톨로지가 마냥 웹에서만 적용될 수 있는 것은 아니니 환경에 맞는 언어를 사용하면 될 것이다. 언제부터 그랬는지는 모르겠지만 블로그에서 온톨로지를 이야기 할 때 항상 웹의 영역에서 이야기를 하고 있었으므로(필자도 잘 몰랐던 사실이지만 ㅡㅡ;) 웹 측면에서 이야기를 풀어가도록 하겠다.

온톨로지 마크업 언어는 W3C에서 표준으로 채택한 RDF/OWL과 ISO에서 표준으로 채택한 TopicMaps가 있다. 따지고 들자면 RDF/OWL과 TopicMaps도 마크업언어를 사용하기 위한 데이터 모델이지 개발언어는 아니다. RDF/OWL은 그 자체로 마크업언어이면서 데이터 모델이고, TopicMaps는 XTM, LTM 등의 마크업언어를 사용하기 위한 데이터 모델이다. 이들의 공통점은 온톨로지의 구현을 위해서 XML을 기반 언어로 사용한다는 점이다. 이외에도 메타데이터, 표준식별체계 등 온톨로지 구현과 활용을 위한 체계(기술이라 하기엔 좀 개념적인 것들이다)가 필요하다. 이들은 좀 나중에 이야기 하도록 하겠다.

이번 포스팅에서는 W3C의 웹온톨로지언어 표준인 RDF/OWL에 대해 이야기 해보고자 한다. 개체간 관계를 선정의 하여 온톨로지에서 추구하는 추론을 가능하게 하는 이 마크업언어는 RDF > RDF schema > DAML/OIL > OWL 순서로 개발되었다. OWL은 RDF/RDFs의 표현력을 보강하고 구문체계를 활용해 정보를 추론하기 위한 기반을 제공한다. 뭐가 좀 어려운데 차근차근 풀어보자

RDF/RDFs

자원기술구조(Resource Description Framework: RDF)는 월드 와이드 웹(World Wide Web)에서 자원에 관한 정보를 표현하기 위한 언어로 특히 웹 자원에 관한 메타데이터를 표현하기 위한 것이다. 그러나 "웹 자원"이라는 개념을 일반화함으로써, 비록 웹에서 직접 검색되지는 않더라도 웹에서 식별되는 사물에 관한 정보를 표현하기 위해서도 RDF를 사용할 수 있다.

RDF는 자원, 속성, 속성값을 하나의 단위로 취급하는 Triple의 개념을 적용하고 있다. 여기서 자원은 데이터를 의미하고 속성은 데이터와 속성값의 관계, 그리고 속성값은 그 관계의 값이다. 써놓고 나니 좀 모호한 감이 있는데 조금 쉽게 풀면, 데이터(자원)에 대한 어떤(속성) 정보(속성값)을 말해주는 것이다. 역시 어려우니 예를 하나 들어보자. 본 블로그의 포스트 중 하나인 "온톨로지를 이해해보기: 기본 요소"는 본인이 저자이다. 이 포스트를 자원이라 하고 자원을 설명하는 다음과 같은 문장을 만들 수 있다.

"온톨로지를 이해해보기: 기본 요소"의 저자는 readholic이다.

이 문장에서 속성은 포스트에 대한 하나의 정보인 저자이고 그 값은 readholic이다. RDF는 이러한 정보와 그 정보의 속성, 즉 종류를 기계가 처리할 수 있도록 하는 체계인 것이다. 이러한 데이터와 데이터에 대한 정보를 기계가 처리하기 위해서는 데이터를 분명하게 구별할 수 있어야 한다. "온톨로지를 이해해보기: 기본 요소"라는 제목으로 무수히 많은 포스트가 있을 수 있지만 저자가 readholic인 포스트는 그 중 하나이다. 따라서 앞의 문장이 참이 되기 위해서는 자원을 분명히 구별하고 그 저자도 분명히 구별해야 한다. 이 구별을 위해서 URI(Uniform Resource Identifier)와 같은 표준 식별체계를 사용하고 있다.

RDF는 기존의 메타데이터, 즉 정보에 대한 정보만을 표현한다. 그렇기 때문에 RDF에서는 속성, 즉 데이터와 데이터의 정보 간의 관계에 대한 설명을 마음대로 만들 수 없다. RDF Schema(RDFs)는 이러한 속성을 필요에 따라 재정의 할 수 있도록 하는 체계를 제공한다. 즉, RDF를 도와 보다 자세한 구조를 짜고 관계를 설명할 수 있는 규칙을 제공하는 것이다.

RDFs에서는 개념을 클래스로 정의하고 있으며 이 클래스는 상하관계를 갖는다. 속성은 표현하고자 하는 관계를 정의할 수 있으며 상하관계를 갖는다. 즉, 자원의 종류를 표시하고 그 관계를 정의하는 일이 RDFs의 역할인 것이다. RDFs에는 클래스와 속성의 유형과 활용에 대해 미리 정해진 몇 개의 어휘들이 있고 이를 통해 RDF 구문에 쓰이는 어휘 사이의 관계를 의미적으로 정의하게 된다.

OWL (Web Ontology Language)

DAML+OIL은 주요 관계를 지원하는 표현력이 결여된 RDF와 RDF 스키마의 모델링 요소를 확장, 강화한 언어이다. OWL은 이 DAML+OIL에 기반을 둔 온톨로지 구축 경험을 토대로 개념의 일관성을 확보하여 클래스와 속성의 개념 및 그들 사이의 관계가 보다 명료하게 정의되도록 정리한 온톨로지 언어이다. OWL은 W3C에서 표준화하고, 2004년 2월에 권고로 발표된 온톨로지 마크업 언어이다. OWL은 완전히 새로운 언어로서의 의미보다는, XML, RDF, RDFS와 같은 기존의 마크업 표준으로부터 시맨틱 웹으로의 진행을 위해 필요한 사항을 추가적으로 정의한 언어로 생각할 수 있다^[각주:1].

• 왜 OWL인가
기계가 정보를 처리할 수 있도록 하는 것이 온톨로지의 목표라 할 수 있다. 기계가 정보를 처리 할 수 있자면 기계가 정보를 읽고(machine readable) 이해(machine understandable) 할 수 있어야 한다. 온톨로지가 이를 위한 방법이라면 OWL은 이를 위한 도구이다. 기계가 정보를 읽고 이해할 수 있는 환경은 사용자 정의 태그 스키마를 정의할 수 있는 XML과 유연하게 데이터를 표현할 수 있는 RDF를 바탕으로 구축된다. 그런데 XML과 RDF는 조금 한계가 있다.

XML은 문서를 구조적으로 표현할 수 있는 문법을 제공하지만 의미를 표현하는 방법은 제공하지 않는다. RDF는 정보(문서)와 정보 사이의 관계를 표현하는 데이터 모델로 정보의 간단한 의미를 표현하는 방법을 제공하지만 말 그대로 간단하다. 인간이 고개를 끄덕일 정도로 정보를 이해하지는 못한다는 말이다. 그래서 RDFs를 통해 정보의 속성과 클래스를 표현하여 의미 표현의 정도를 확장하고자 했지만 제약사항이 많다. 그래서 기계를 이용하여 웹 문서를 대상으로 유용한 추론 기능을 수행하려면 RDFs가 제공하는 기초적인 의미 표현력을 뛰어넘는 언어가 필요하게 되었고 OWL의 개발에 이르게 된 것이다. OWL은 속성과 클래스에 대하여 기술할 수 있는 더 많은 어휘를 제공한다

• OWL의 종류
OWL에는 표현력의 정도에 따라 Lite, DL, Full의 세 가지 하위 언어가 있다. 이름에서도 느껴지듯이 OWL Lite가 가장 낮은 표현력을 가지고 있는 것으로, 클래스 표현을 위한 규칙인 DL(Description Logic)(OWL의 형식적 기반이 된 논리학의 한 분야 )을 사용하지 못한다. OWL Lite는 계층적인 개념을 구조화하고 특정한 관계를 정의하는 수준이다. RDFs와 비슷하다고 할까? 따라서 OWL Lite는 이론적 복잡도가 낮기 때문에 유의어 사전이나 간단한 분류 체계 그리고 시소러스를 빠르고 손쉽게 OWL화하기 위한 용도로만 적합하다

OWL DL은 OWL 내에 포함되어 있는 DL을 모두 사용할 수 있다. 그렇기 때문에OWL DL은 훨씬 정교하게 개념의 형식적 정의를 수행할 수 있다. OWL DL은 OWL에서 정의한 모든 어휘를 포함하고 있으나 어휘를 사용할 때에는 사전에 정해진 제약 사항을 준수해야 한다. OWL DL은 계산적 완전성(Computational Completeness)^[각주:2]과 결정 가능성(Decidability)^[각주:3]을 유지하면서 최대의 표현력을 제공한다.

OWL Full은 OWL DL에서 정의된 모든 어휘를 활용할 수 있는 동시에, RDF를 통한 어휘의 확장 및, 자유로운 구문의 활용이 가능하다. OWL DL과 Lite에서는 미리 정의된 모든 어휘에 대해 일정한 조건에서만 활용을 할 수 있도록 규정하고 있지만 OWL Full은 이와 같은 제약이 없다. 쉽게 말하면, 필요에 따라 자유롭게 표현 어휘를 정의하여 활용할 수 있는 것이다. 하지만 추론의 완전성과 결정성을 보증할 수 없다는 단점을 가지고 있다. 사람도 즉흥적으로 이야기 할 때 불완전하고 시간이 걸리 듯이 컴퓨터가 미리 정해 놓은 규칙을 벗어나 새로운 규칙을 정하고 이를 처리하게 하기 때문이다. 

참고 문서 

RDF Primer- W3C의 RDF 공식 문서, 간단한 소개와 활용 방법을 담음. 간단히..
OWL overview – 역시 W3C의 공식 문서로 간단한 소개와 활용 방법을 담음. 간단히..
한글판 RDF Primer, OWL overview(IE에서 깨짐)