ontoBox2010/03/10 19:30

그 동안 포스팅을 통해 온톨로지에 대한 이야기를 해왔다. 참으로 유용한 체계임은 분명하다. 기계가 정보를 이해해서 사람의 수고를 덜어 준다니, 참으로 유용하지 않은가. 하지만 ‘가능할까?’의 문제는 아직도 격하게 논의되고 있다.

얼마 전 ‘다음’에서 면접을 보고 왔는데 – 시원하게 떨어졌다. 움홧홧 – 면접관 한분이 온톨로지의 발전에 대해 물었다. 본인의 대답은 이랬다.

온톨로지에 더 이상의 발전은 없습니다. 하지만 온톨로지를 바탕으로 다양한 새로운 생각들이 나올 것입니다.


당시의 답변이 잘 기억나지 않아 조금 미화된 측면이 있지만 비슷한 맥락이었다. 좀 더 짧게 말하자면,

온톨로지에 발전은 없다. 다만 미래가 있을 뿐이다.


뭔가 모순되면서도 거창한 말이다.

사실 온톨로지는 불가능하다. 지식은 끊임없이 성장하고 있고, 개념은 보다 복잡해지고 있다. 게다 온톨로지는 정보처리의 이상향이다. 기계가 정보를 이해한다는 것은 인공지능의 개발에서부터 시작되었지만 십수년이 지난 지금까지도 인공지능은 공상과학소설의 이야기로만 남고 있다는 점에서 – 논란의 여지가 있을 것으로 생각되지만 – 온톨로지가 추구하는 목적은 이상향이다. ontopia 정도?

그렇다. 본인은 온톨로지에 회의적인 입장이다. 온톨로지의 실질적 활용을 위해 많은 기술들이 연구·개발되고 있지만 아직 널리 사용되지 못하고 있다. 물론 그 기술들은 뛰어나다. 한정된 범위와 분야에서는 훌륭한 성과를 보이고 있다. 하지만 아직 넓은 범위에서의 적용은 어렵다는 생각이 많다.

다시 논점으로 돌아와서, 온톨로지의 이상향은 실현 가능한가? 가능성은 있다고 본다. 시맨틱 웹의 개념이 처음 등장한 것은 1998년의 일이다. 월드와이드웹의 창시자 팀 버너스리는 1998년 시맨틱 웹의 개념을 소개했다. 다음에 보이는 그림은 시맨틱 웹의 설명을 위해 자주 사용되는 그림이다. 데이터를 정확하게 찾을 수 있는 바탕(식별자), 데이터를 이해할 수 있는 바탕(온톨로지), 데이터를 의미적으로 처리할 수 있는 바탕(논리 구조), 의미적으로 처리된 정보의 제공(Trust). 그가 생각한 시맨틱 웹의 구조는 이렇다. 온톨로지가 실현 될 수 있는 구조라 할 수 있겠다.


출처: W3C Semantic Web Activity


다시 한번, 온톨로지의 이상향은 실현 가능한가? 유토피아는 실현되기 위한 목표점이다. 시맨틱 웹, Social Network, Linked Data. 웹이 온톨로지의 이상향을 닮아가는 진보의 한 모습이다. 이러한 노력들이 – 개념적으로는 – 온톨로지를 현실화 하는 원동력이 된다고 생각한다.

그 가능성들에 대해 차근차근 알아보자.


지난번 포스팅에서 온톨로지와 관련된 용어들을 살펴본다 하였으나, 이야기를 하는 동안 알쏭달쏭한 용어들이 나올 때 따로 정리하는 것이 더 유용하겠다 싶어 따로 섹션을 마련하도록 하겠다.

Posted by readholic
ontoBox2010/02/14 22:15

게으른 블로깅의 반성으로 메타데이터에 대해 이야기하고 바로 식별자에 대해 이야기 해보고자 한다. 식별자는 메타데이터와 더불어 온톨로지의 구현을 위한 중요한 바탕이라고 생각한다. 개인적인 생각이기도 하지만 많은 연구자들이 동의하고 있는 바이기도 하다. 각설하고 식별자에 대해 살펴보도록 하겠다.

 

1. 식별자는 단순하다

언제나 단순하다고(메타데이터를 빼고는) 운을 떼고 있다. 식별자는 우리 주변에, 우리 생활에 너무 많이 존재하고 있기에 확실히 개념을 이해하기에는 쉽다.

대한민국 사람이라면 누구나 주민등록번호를 갖고 있다. 완전히 똑같은 주민등록번호는 없다. 자동차에는 앞뒤로 번호판이 달린다. 자동차의 등록번호 역시 완전히 똑같은 번호는 없다. 휴대전화는 그 기계만의 번호를 갖는다. 하나의 휴대전화 번호는 하나의 기계로만 전화가 걸린다. 이런 번호들이 가장 기초적인 식별자라 할 수 있겠다. 완전 단순하다.

식별자는 쓰임에 따라 더 복잡한 모습을 할 수 있는데, 예를 들면 제품의 시리얼넘버(일반적으로 전자제품에서 쉽게 확인할 수 있다)가 있다. 시리얼넘버는 제품이 생산된 순서대로 번호를 붙일 수 도 있지만 굉장히 많이 생산되는 경우에 문자와 함께 번호가 붙을 수도 있다. 이들 문자는 어떤 의미를 가질 수도 있고 그렇지 않을 수도 있다. 의미를 갖는다는 것은 어떻든 구분을 짓겠다는 의미이다. 예를 들어 파주에 있는 공장에서 생산됐다면 ‘PJ’로 시작한다던가 하는 것이다.

의미를 가지건 그렇지 않건 식별자는 무언가를 모호하지 않게 구별하기 위한 것이 그 궁극적인 목적이다. 어떤 측면에서는 식별자를 메타데이터 요소의 하나로 볼 수 있다. 정보의 분명한 구별을 위한 정보가 되는 것이다.

 

2. 식별자는 왜 필요한가?

그렇다면 식별자는 어떤 역할을 할까? 앞서 예로 들었던 많은 번호들은 사람, 자동차, 휴대전화를 구별하고 찾아낼 수 있도록 한다. 주민등록번호를 통해 100명의 김철수 각각을 구별할 수 있고 자동차 등록번호를 통해 1,000 대의 소나타를 구별할 수 있다. 그리고 그렇게 구별된 각각, 주민등록번호가 ‘123456-1234567’인 김철수씨를 찾아 낼 수 있고 00조 9999인 소나타를 찾아 낼 수 있다. 조금 다르게 말하면 정보를 구별하고 위치를 지시하기 위해서 식별자를 사용하는 것이다.

웹에서는 이런 역할을 누가 하고 있을까? 이 포스팅은 웹 브라우저의 인터넷 주소창에서 ‘http://readholic.com/entry/정보-그리고-온톨로지-식별자에-대하여’라고 써 있는 것을 볼 수 있을 것이다. URL(Uniform Resource Location)이라는 이름으로 잘 알려진 인터넷 주소가 그 역할을 하고 있다. 대개 URL은 우리가 사용하는 주소에 견주어 설명된다. 우리가 한곳에만 머물러 살지 않듯이 웹상의 많은 자료들 또한 위치를 바꾸는 경우가 있다. 이유야 어떻든 어떤 자료에 대한 URL은 바뀔 수도 있고 아예 없어질 수도 있다. 그렇다고 해서 불편을 느끼는 사용자는 없을 것이다. 검색엔진을 통해 옮긴 곳의 주소를 찾을 수도 있고 비슷한 다른 자료를 찾으면 그만이니 말이다. 하지만 컴퓨터에게는 여간 곤란한 일이 아닐 수 없다. 기껏 찾아서 잘 적어놓았더니 거기 없으니 말이다.

이런 곤혹스러운 상황을 피하기 위해 URN(Uniform Resource Number)이라는 체계가 태어났다. 단지 주소만 표시하는 것이 아니라 변하지 않는 고유한 식별 번호, 즉 그 정보만이 갖는 주민등록번호를 만들어 주자는 것이다. 이런 URN은 웹 이용자가 활용할 수 있도록 URL로 변환하는 것이 필요한 단점을 갖고 있지만 범용적으로 활용 할 수 있는 식별체계이다.

 

3. 식별자는 어떻게 만들어지나?

앞서 간략하게 말했지만 좀 더 구체적으로 설명하자면, 식별자는 크게 의미 있는 문자와 숫자의 나열로 구성된 구조화된 형태와 무의미한 나열로 구성된 더미(Dummy) 형태가 있다.

구조화된 형태에서 문자와 숫자 나열의 의미는 식별자마다 다르다. 더미 형태는 단순한 일련번호일 수도 있고 무작위로 선정된 문자와 숫자일 수도 있다. 어떤 것이 더 좋은가에 대한 구체적인 연구는 없지만 어딘가에 식별자를 기록해 두고 사용한다는 점은 두 형태 모두 공통적이므로 기계적인 측면에서는 큰 효율성의 차이는 없다고 생각된다. 아, 개인적인 의견이다.

식별자는 아주 작은 규모, 필요에 따라서는 개인도 사용할 수 있겠지만 – 예를 들자면 DVD 대여점에서 DVD 하나하나에 번호를 붙이는 것과 같은 경우 – 웹상에서 사용되는 식별자는 엄청난 규모의 정보를 대상으로 하고 있으므로 체계적인 운영기관에서 관리하고 있다. 우리나라에서는 UCI라는 이름의 국가식별체계가 있어서 다양한 매체에 식별자를 부여하고 관리하고 있다[UCI 홈페이지 바로 가기].

 

4. 온톨로지와는 무슨 상관이지?

메타데이터가 정보를 찾기 위한 실마리라면 식별자는 정보를 찾아가기 위한 확실한 길이다.

정보를 찾지 못하는 일이 온톨로지 환경에서 벌어진다면 꽤나 곤혹스럽다. 공들여 정의한 개념을 찾을 수 없다면(이런 작업들은 대부분 문서로 작성되어서 컴퓨터가 사용할 수 있도록 하고 있으니) 정의된 관계도 사용하기 어렵다. 또한 정의된 개념과 관계를 통해 찾아낸 정보를 보여주려는데 찾을 수 없다면 아무 소용 없지 않은가.

온톨로지 환경에서 식별자가 중요한 이유는 정보의 위치를 확인한다는 기본적인 이유 때문만은 아니다. 의미 있는 정보 간의 연결이 온톨로지 구현의 핵심이라는 전제에서 식별자가 없다면 정보 간의 연결 자체가 어렵게 될 것이다.

 

온톨로지에 다다르기까지의 기본적인 개념들에 대해 간략하게 살펴 보았다. 다음 포스팅부터는 온톨로지와 관련된 용어들에 대해 살펴 보고자 한다

Posted by readholic
ontoBox2010/02/13 18:28

지난 포스팅에서 분류에 대해서까지 살펴보았다. 이제 정보를 활용하기 위한 노력이 온톨로지에 거의 근접해 왔다. 개인적으로 메타데이터는 온톨로지의 구체화, 시맨틱 웹의 구현을 위한 가장 핵심적인 요소라고 생각한다. 한 번의 포스팅으로 메타데이터에 대해 설명하기는 어렵다(목록과 분류도 한 번의 포스팅으로 설명하기 어려운 것은 마찬가지이지만 ㅡㅡ;). 자세한 설명은 잠시 접어 두고 개괄적인 이야기를 해보자.

1. 메타데이터는 복잡하다

메타데이터는 복잡하다. 결코 단순하지 않다. 하지만 단순하게 접근해보고자 한다.

흔히들 메타데이터는 ‘데이터의 데이터(A data of the data)’라고 알려져 있다. 알려져 있다는 것은 대개 그렇게 설명된다는 의미인데, 말이 좀 모순적이라고 느껴질 수 있다. 데이터의 데이터라, 이를 테면 덩치가 큰 정보나 데이터의 작은 정보, 또는 데이터라는 말이다. 덩치가 큰 정보나 데이터, 그러니까 인사과에서의 ‘직원 명부’가 그것이 될 수 있겠다. 직원 명부에는 그 회사의 임직원에 대한 목록이라 할 수 있다. 이 명부 내의 임직원들 각각은 정보, 데이터이다. 이 명부는 제법 잘 만들어져서 임직원에 대한 많은 정보들을 기록하고 있다고 하자. 그렇다면 이 임직원, 즉 정보는 사번, 부서 등과 같이 임직원과 관련된 작은 정보들을 또 갖고 있는 것이다. 이 작은 정보들, 이 정보들이 데이터의 데이터, 정보의 정보, 즉 메타데이터가 되는 것이다.


<그림1> 메타데이터의 개념

설명해 놓고 보니 쉽다. 뭐 하나도 안 복잡하구만. 하지만 자세히 보면 메타데이터는 단순히 작은 데이터로 끝나지 않는다는 것을 알 수 있다. 메타데이터의 핵심은 그 목적에 있다. 위의 예에서 메타데이터는 정보를 관리하기 위한 정보이다. 즉, 관리를 그 목적으로 하고 있는 것이다. 또한 메타데이터는 많은 데이터에 대한 각각의 정보를 일정한 범주로 나누어 기록하고 있다는 것을 알 수 있다. 즉, 목록에 대해 분류된 정보를 기록하고 있는 것이다.

설명의 편의를 위해 <그림 1>과 같이 개념을 풀어 놓았지만, 사실 메타데이터는 구조를 갖고 있다. 각각의 정보를 범주화한 것을 메타데이터 요소라고 한다. <그림 1>에서 이름, 사번 따위의 정보를 범주화한 것이 요소이고 그것을 사람들이 이해할 수 있도록 이름 붙인 것이 요소명이다. 이러한 요소에 어떠한 내용을 어떻게 넣어야 하는지에 대해 설명하는 것이 메타데이터 스킴이다. 메타데이터는 확실히 복잡하다.

 

2. 메타데이터는 왜 만드나?

메타데이터는 덩치가 큰 데이터를 설명하는 역할을 한다. <그림 1>에서 ‘김말자’에 대한 정보들, 즉 부서나 사내번호 등과 같은 정보들은 회사 내에서의 김말자씨에 대한 설명이다. 어느 부서에서 일하며 몇 번으로 전화해야 통화가 가능한지 설명해주고 있는 것이다.

메타데이터는 목적에 따라 일반적으로 기술적(Description), 관리적(Administration), 구조적(Structure) 메타데이터로 나누고 있다. 이렇게 나누어진 메타데이터의 역할은 다음과 같이 간략하게 설명할 수 있다.

  1. 기술적 메타데이터는 데이터의 내용에 대한 정보를 설명함으로써 다른 자료와 구별하고 효과적으로 찾을 수 있도록 도와준다.
  2. 관리적 메타데이터는 데이터와 관련된 부가적인 정보들을 알려줌으로써 잘 정리하고, 이용하고, 활용할 수 있도록 도와준다.
  3. 구조적 메타데이터는 데이터의 논리적인 구성에 대한 정보들을 기록하여 기계적으로 처리가 가능하도록 도와준다.

메타데이터의 궁극적인 목적은 기계, 즉 컴퓨터가 데이터를 보다 쉽게 찾도록 도와주는 것이다. 이를 위해서 잘 정리하고(조직하고), 잘 설명하기 위한 정보들을 체계적으로 나누고 기록하는 것이다.

 

3. 메타데이터는 어떻게 만드나?

메타데이터는 다양한 방법으로 만들 수 있겠지만 크게(아주 크게) 두 가지 방법으로 만들 수 있다. 첫 번째는 필요한 정보를 분류하여 범주화하는 방법이 되겠다. 데이터를 모으는 목적과 활용하는 목적에 따라 정보를 체계적으로 정리하는 것이다. 두 번째 방법은 이미 개발된 메타데이터를 그대로 사용하거나 필요한 범주를 활용하는 방법이다.

첫 번째 방법은 좀 더 쉽게 말해, 메타데이터를 새로 만드는 것이라고 할 수 있다. 완전히 새로 만들 수도 있겠고 만들어진 메타데이터의 요소들을 참고해서 필요에 맞게 만들 수도 있다. 국제표준기구인 ISO에서는 ISO/IEC 11179라는 이름의 메타데이터 작성 지침서를 제공하고 있다. 이러한 지침서는 다른 사람들이나 기관과 함께 사용하고자 할 때, 즉 상호호환성을 갖춘 메타데이터를 만들고자 할 때 좋은 안내가 된다. 이 방법은 메타데이터를 새로 만들어야 한다는 점과 작성된 메타데이터의 공유가 어렵다는 단점이 있지만 목적에 최적화되어 효율적으로 활용할 수 있다는 장점이 있다.
두 번째 방법은 전문적으로 많이 활용되고 있으며 공유를 고려한 방법으로 이미 널리 사용되고 있는 메타데이터를 활용하여 상호호환성을 기본적으로 갖추어 데이터에 대한 정보를 생성하는 방법이다. 이 방법은 목적에 꼭 맞지 않을 수 있어 비효율적일 수도 있다는 단점이 있지만 활용이 쉽고 간편하다는 장점이 있다.

앞서 설명한 메타데이터를 만드는 두 가지 방법은 정말이지 큰 관점에서 나눈 것이다. 많은 연구를 통해 메타데이터를 만드는 다양한 방법들이 개발되었다. 다음 포스팅들을 통해 차차 알아보도록 하겠다.

 

4. 온톨로지와는 무슨 상관이지?

개인적으로, 정말 개인적으로 메타데이터는 온톨로지 구현을 위한 바탕이 된다고 생각한다. 기계가 정보를 이해하기 위해서는 개념을 정의하고 그 관계를 정의하는 것만으로는 부족하다. 정의된 개념에 대한 실제 정보가 필요하다. 정보가 포함하고 있는 내용이 어떤 개념에 속하는지, 정보가 의미하는 것은 어떤 개념에 해당하는지 메타데이터가 있다면 보다 손쉽게 알 수 있을 것이다.

온톨로지가 개념 간의 관계를 통해 의미적인 정보를 찾아내는 바탕을 만들어 주는 것이라면 메타데이터는 정보의 숨은 의미를 설명하여 온톨로지 환경에서 정확한 정보를 찾아낼 수 있는 실마리와 단서를 제공할 수 있는 바탕을 만들어 주는 것이라 할 수 있겠다.

다음 포스팅에서는 정확한 정보를 확실하게 구별하고 찾아갈 수 있는 식별자에 대해 알아보도록 하겠다.

Posted by readholic
ontoBox2009/12/07 22:25

저번 포스팅에서는 다음 포스팅의 주제로 마치 메타데이터에 대해  쓸 것처럼 마무리 되었으나(사실 그럴 생각이었으나) 그전에 분류에 대해 알아보고 넘어가는 것이 좋을 것 같다. 이전 포스팅에서 아주 간략하게 분류에 대한 내용을 다루었지만 어쩐지, 궁금하면 그냥 보쇼, 라는 건방진 느낌이라 다시 한번 다뤄보고자 한다.


1. 분류도 단순한가?

목록은 단순하다고 지난 포스팅에서 줄기차게 이야기 해 대었다. 분류도 단순한가? 어쩐지 뜬금 없는 이야기지만, 요즘 세상사는 참으로 단순하다는 것을 느낀다. 배고프니까 밥을 먹는다. 밥 사먹으려고 돈을 번다. 돈을 벌려니 일을 한다. 일을 하니 배고프다. 배고프니까 밥을 먹는다. 참으로 단순한 라이프 사이클이 아닌가. 분류도 그렇다. 많으니까 나눈다. 나누려니까 공통점을 찾는다. 공통점으로 한데 모으니 많다. 많으니까 나눈다. 단순하다.
그런데 왜 다들 세상살이가 어렵다고 할까? 밥을 뭘 먹을까 고민하고, 어떻게 하면 돈을 많이 벌까 고민하고, 일을 어떻게 쉽게 할까 고민하고. 이렇게 고민하고 저렇게 고민하니 어렵기도 할 테다. 분류도 그렇다. 어떻게 나눌까 고민하고, 많은 것을 잘 나누려고 고민하고, 어떤 것에서 공통점을 찾을까 고민하고. 이렇게 고민하고 저렇게 고민하다 보면 분류도 어려워진다.

다양한 분야에서 분류가 사용되고 있다. 우리 주변에서 가장 쉽게 찾아 볼 수 있는 분류는 포털 사이트의 디렉토리 서비스가 될 것 같다.

그림1 네이버의 디렉토리 서비스

<그림1>은 네이버의 인물, 사람들 카테고리 안의 홈페이지들 인데 홈페이지를 직업에 따라 나누고 있는 것이 보인다. 개인 홈페이지는 가족, 부부, 외국인 등 홈페이지가 나타내는 특성에 따라 나누고 있는 것으로 볼 수 있겠다. 쉽지 않은가! 분류는 쉽다.

2. 분류는 정말 단순한가?

분류가 단순하고 쉽기는 하지만, 온톨로지의 영역으로 가고자 한다면 역시 조금은 어려워진다. 예컨대 어디까지 나누고 묶을 수 있는가의 문제이다. 조금 어렵게 느껴지는데, 세상의 지식을 전부 일정한 규칙에 따라 나눌 수 있는가, 라는 질문이라면 좀 더 확실할까?

많은 분야에서 분류가 연구되고 있고 활용되고 있다. 중학교 때쯤인 것으로 기억하는데, 생물 시간에 종, 목, 강 따위로 지구상의 생명체를 나누는 것을 공부한 적이 있었다. 생물분류는 자연적 분류라 할 수 있다. 자연적 분류란 나누려는 대상이 원래 가지고 있는 특성을 나눔의 기준으로 삼는 것을 의미한다. 사람을 나눌 때 어린이, 어른으로 나눈다거나 남자, 여자로 나눈다거나 하는 것이다. <그림 1>에서의 분류는 자연적이라 할 수 없다. 가족, 부부, 건축가는 자연적인 것이 아니다. 인간이 사회를 구성하고 영위하며 발생된 인위적인 것이다. 이러한 기준, 즉 인위적으로 발생한 특성에 따라 나누는 것을 인위적 분류라 할 수 있다. 자연적 분류는 객관적 성질을 기준으로 분류하는 것이고, 인위적 분류는 유사성에 따라 분류하는 것이라 할 수 있다.

그렇다면 이 세상의 모든 지식을(우리는 온톨로지, 즉 정보에 대해서 이야기하고 있으니까) 자연적, 인위적 분류를 통해 나눌 수 있을까? 라는 질문에 봉착하게 된다. 결론을 이야기 하자면 “가능하지만 불가능하다” 이다.
가능하다는 측면에서 이야기 해보자. 가능하다. 왜 안돼? 된다. 세상의 지식은 철학, 문학, 종교 등의 커다란 범위에서 그 공통점이 있다. 철학에 대해 이야기하는 책, 문학 작품으로 나눌 수 있다. 또 문화, 생활, 경제 등으로 나눌 수 있다. 커다란 범위에서 묶인 지식들은 또 다시 나뉠 수 있다. 문화에서는 영화, 음악, 연극 등으로 나눌 수 있고 영화는  예술영화, 오락영화, 가족영화 등으로 나눌 수 있다. 예술영화도 장르, 감독, 국가 등으로 나눌 수 있다. 큰 범위는 자연적 분류, 즉 문화라는 객관적 성질(객관적 성질이라 하기엔 다소 무리가 있는 듯 하지만 ㅡㅡ;)을 기준으로 나눈 것이고 작은 범위는 인위적 분류, 즉 같은 국가라는 유사성을 기준으로 나눈 것이다. 잘 나눠진다.
불가능하다는 측면에서 이야기 해보자. 생활과 경제는 따로 떼어 놓을 수 있을까? 종교와 문학, 종교와 철학은 따로 떼어 놓을 수 있을까? 물론 기준을 만드는 관점에 따라서 다를 수 있겠지만 지식은 단 하나의 분야로 정의하기 어렵다. 다양한 지식이 융화되어 또 다른 지식으로 발전하는 것이 더 급속하게 진행되고 있는 요즘에는 더더욱 그렇다. 분류라는 것이 어려워지기 시작한다.

3. 세상의 지식을 나누기는 정말 어려운가?

온톨로지는 개념의 명세화라는 정의를 기억하고 계시는가? 온톨로지의 궁극적인 목표는 생각하는 컴퓨터이다. 정보에 의미를 부여하고 관계를 맺어주어 컴퓨터가 이해할 수 있는 정보를 통해 컴퓨터가 자동적으로 지식을 제공할 수 있도록 하는 것이 온톨로지의 목표라 생각한다. 그러자면 이 세상의 지식을 명확하게 나누어 주어야 한다. 아주 이상적으로는 그렇다. 하지만 앞서 말했듯이 자연적 기준과 인위적 기준으로 세상의 모든 지식을 똑 부러지게 나누기는 어렵다. 어려우니까 관둘까… 아니다 포기하기는 이르다. 어려우면 어려운 대로 다른 방법을 찾을 수 있을 것이다.

분류는 Classification과 Taxonomy로 나눌 수 있겠다. 형식적으로는 큰 차이가 없지만 그 방법에는 조금 차이가 있다. Classification은 유사성을 기준으로 한다면 Taxonomy는 객관적 성질을 기준으로 한다. 그렇다 인위적 분류와 자연적 분류의 차이이다! 앞에서 가능하다는 측면에서 이야기한 것처럼 큰 범위는 자연적 분류로, 작은 범위는 인위적 분류로 나누는 것도 한 방법이 되겠다. 즉, Taxonomy를 통해 큰 틀을 잡고 세세한 것은 Classification을 통해 채워 나가는 것이다.
하지만, 문제는 여전히 존재한다. 두 가지 이상의 지식이 포함된 것은 어떻게 나눌 것인가! 필자의 지식이 부족한 탓인지 아직 이에 대해 무릎이 탁! 쳐지는 명쾌한 방법은 알지 못하고 있다. 문헌정보학 분야에서 분석합성식 분류법이라 방법을 통해 시도가 되었지만 그 방법이 난해하여 잘 활용되지 못하고 있다.

이 부분에 대해서는 추후 시맨틱 관점에서 다루어 보고자 한다.o

4. 분류와 온톨로지는?

온톨로지의 기반, 기반이라 하기엔 무리가 있으려나…, 개념의 명세화를 위해서는 분류를 이해하고 개념들을 정의하는 것이 필요하다. 클래스 단위의 용어들을 정의하고 그들의 관계를 정의하기 위해서 분류는 매우 중요하다고 할 수 있다. 상위 클래스와 하위 클래스를 정의하는 것은 Taxonomy를 통한 정의가 필요하다. 때로는, 분야에 따라서는 유사성에 따른 분류가 필요할 수도 있다. 무엇보다도, 이후 다루게 될 메타데이터에서 요소를 도출하고 정의하기 위한 기본으로써 분류는 매우 중요하다.
온톨로지를 잘 만들기 위해서는 그 바탕을 잘 닦는 것이 중요하다. 이를테면 설계에서의 모델링의 과정이라 할 텐데, 그 모델링의 기초가 되는 것이 분류가 아닐까 조심스럽게 이야기 해본다.

이번 포스팅은 참으로 부족한 점이 많다. 쉽게 풀어 쓰자니 아는 것이 많아야 하는데 전문 분야가 아니라 ㅎ 아… 미련한 핑계 ^^;

Posted by readholic
ontoBox2009/11/22 20:16

굉장히 게을렀다. 사실 짬을 내면 쓸 수 있는 시간이 있었다고 생각하지만 누군가의 말처럼 눈 코가 어디 달렸는지 조차도 알지 못할 정도로 바빴기 때문에… 아 비굴한 핑계… ㅋ 각설하고.. 지난번 포스팅을 통해 온톨로지의 대상이 되는 정보와 지식에 대해 살펴보았다. 두서 없이 쓴 내용이라 논란의 여지가 많겠지만, 이제부터의 포스팅을 통해 조금씩 온톨로지의 배경에 접근해 보려 한다.

 

1. 목록은 단순하다

목록은 단순하다. 그렇다 참으로 단순하다. 목록은 실제로 우리 생활에 자주 등장한다. 장을 보러 간다. 뭘 살까? 고민해서 꼼꼼하게 살 것을 정연하게 적어가는 알뜰한 장보기, 이 때 정연하게 적어가는 그것, 그것은 목록이다. 저녁을 먹으러 중화요리집엘 갔다. 식사거리, 요리 종류 등 다양한 음식이 나열된 메뉴판에서 우육탕을 골랐다. 메뉴판(흠.. 표준어는 차림표 입니다) 그것은 목록이다.

쉽다, 목록은 쉽다. 국어사전에는 “품목과 내용을 일목요연하게 기록한 것” 이라고 정의하고 있다. 생각해 봐야 할 것은 이 목록을 왜 만드는 가, 이다. 왜 만들까?

최초의 목록은 알렉산드리아 도서관의 관장을 맡았던 칼리마쿠스의 피나케스(pinakes)목록으로 알려져 있다(문헌정보학의 이해 편찬위원회. 2004. 문헌정보학의 이해. 서울. 한국문헌정보학회. pp164). 당시 알렉산드라아 도서관에는 70여만 파피루스가 있었는데 이 방대한 자료를 효율적으로 관리하기 위해 관장님은 목록을 만드셨다.
그렇다, 목록을 만드는 이유는 효율적인 관리, 그러니까 많은 정보를 효율적으로 정리하고 편리하게 찾아 볼 수 있도록 하기 위해서이다. 장보기 목록과 음식점 메뉴판도 같은 목적이라고 생각한다. 잘 기억나지 않으니까 미리 정리해서 적어 놓은 것이고 우리는 이런 것이 있습니다, 라고 매번 말 할 수 없으니까 미리 정리해서 적어 놓은 것이다. 그 적어 놓은 것, 목록을 통해 알뜰한 장보기를 할 수 있고 어떤 음식들이 있는지 찾아 볼 수 있는 것이다.

 

2. 아무거나 목록이 될 수 있나?

그렇다면 아무거나 쭉 적어 놓으면 목록이 될 수 있을까? 될 수 있지 왜 없나. 후후. 하지만 중요한 것은 목적이다. 아무런 목적이 없다면 적어 놓아 봤자 쓸모가 없다. 오히려 혼란스럽기만 하다.
정보라는 것과 목록을 같이 보자. 광고를 하는 건 아니지만 본인은 아이튠즈를 사용해 음악을 정리하고 있다. 단 한 순간도 쉬지 않고 들을 때 6.2일이 걸려 소장한 모든 음악을 들을 수 있다. 현재 1990곡을 소장하고 있다. 아이튠즈에 음악을 넣을 때(맞는 표현인가 ㅡㅡ;) 처음 하는 일은 제목과 가수, 앨범 등 그 곡에 대한 정보를 입력하는 것이다. 만약 제목을 잘못 입력하면 어떻게 될까? 못 찾지는 않을 것이다. 인간은 위대하니까. 하지만 고생은 할 것이다. 마찬가지로 목록에 쓸데 없는 정보나 잘못된 정보를 넣게 되면 목록을 이용해서 정보를 찾을 때 꽤나 고생을 하게 될 것이다.
장보기 목록이나 메뉴판을 비교해 보자. 장보기 목록은 단순하게 살 물건의 이름이 적혀 있다. 알뜰한 주부님들은 몇 개를 살 것인지 적어 놓을 수도 있겠다. 메뉴판은(레스토랑 정도의 음식점이 그러한데) 음식의 종류에 따라 음식이나 요리의 이름과 가격이 나열되고 어떤 때는 그 음식에 대한 짤막한 설명도 함께 적혀 있다. 어떤 차이가 있는가. 메뉴판은 목록에 나열된 정보에 대해 무언가를 더 알려 준다. 가격은 얼마인지, 원재료는 어디 것인지, 어떤 재료가 들어가는지… 둘 모두 목록이지만 메뉴판이 좀 더 높은 수준의 목록이라 할 수 있을 것이다.
다시 장보기 목록과 메뉴판을 비교해 보자. 두 목록의 목적은 같지 않다. 그리고 그 목적의 수준 또한 다르다. 장보기는 나만 알면 그만인 것이다. 혹 아버지가 장을 보러 가신다면 어머니는 꽤나 자세하게 장보기 목록을 만들어 주실 것이다. 목록은 누군가가 그것을 통해 무언가를 찾을 수 있게 해주는 것이다.

그렇다면, 목록은!

목적에 따라, 찾고자 하는 것을, 그것을 설명하는 정보와 함께 나열한 것. 이라고 말할 수 있을 것이다.

 

3. 목록은 어떻게 만드나?

목록을 만드는데 공통적인 규칙은 없을 것이다. 하지만 목록을 만드는 곳, 다시 말해서 정리된 자료나 정보를 찾고자 목록을 사용하는 곳에서는 일정한 규칙을 갖고 있을 것이다. 회사나 개인에게도 규칙이 있을 것이다. 그렇지만 가장 대표적인 ‘곳’은 도서관이라고 생각한다.
도서관에는 참으로 많은 책들이 있다. 내가 다니던 대학의 도서관에는 100만권이 넘는 책이 있었다. 지금은 아마 170만권은 넘을 것 같다. 도서관에서는 이 방대한 양의 책을 찾기 쉽고 보관하기 쉽고 정리하기 쉽게 하는 방법을 잘 알고 있다. 오래 전에는, 그건 아마도 6,70년대 일 텐데.. 흠.. 80년대에도 보긴 했지만… 작은 카드에 도서관이 보관하고 있는 모든 책에 대한 정보를 하나하나 적어서 작은 함에 보관해 두었었다. 지금도 어딘가의 공공도서관에 가보면 있을지도 모르겠다. 이 카드에는 책의 제목, 지은이, 출판사, 장수, 책 크기 등 책에 대해 알 수 있는 것을 최대한 많이 적어 놓는다. 그리고 중요한 것, 어디에 그 책이 있는지 적어 둔다.
지금은 도서관에서 카드로 책을 찾지 않는다. 검색 시스템에서 제목이나 저자의 이름을 입력해서, 혹은 키워드를 입력해서 나온 결과를 통해 책을 찾을 수 있다. 이렇게 시스템, 그러니까 컴퓨터를 통해서 책(자료, 정보 등등)을 찾을 수 있는 것은 그 책에 대한 정보를 한 곳에 모아 잘 정리해 두었기 때문이다(목록으로!).
앞에서도 말했듯이 책에 대한 정보를 아무거나 아무렇게나 정리해서는 목록을 사용하는 사람이 짜증만 날 뿐이다. 일정한 규칙, 그러니까 책에 대한 정보는 제목, 저자, 출판사, 출판한 년도와 날짜를 넣는다; 책에 대한 정보는 책에 쓰여진 대로 넣는다; 키워드는 미리 정해 놓은 것들만 넣는다 와 같은 규칙들을 정해서 일정한 정보를 보여줄 수 있도록 해야 한다.

 

4. 온톨로지와는 무슨 상관이지?

목록 온톨로지의 시작이라 할 수 있다. 온톨로지는 정보 간의 관계를 통해 기계가 정보를 이해할 수 있도록 하고 이를 바탕으로 정보를 지식의 형태로 인간에게 전달 할 수 있도록 하는 것이라고 할 때, 목록은 정보가 서로 관계를 맺을 수 있는 바탕을 만들어 준다고 할 수 있다. 목록이 직접적으로 온톨로지에 이어지는 것은 아니다. 목록을 이해한다면 온톨로지를 이해하기 좀 더 쉬워질 수 있다는 것이다(개인적인 생각이다). 목록은 메타데이터의 시발점이 되었다. 목록은 정보와 정보의 정보(메타데이터)의 집합이다. 메타데이터는 온톨로지의 기초가 된다.
사실 목록은 단순하다. 목록이니까. 영어로 하면 리스트. 학문적으로는 카탈로깅, 특별히 Library Catalog라고 하지만 단순하게 목록이다. 어느 것이나 그러하겠지만 목적과 이유가 그 수준을 달리하는 것이다. 음… 그러니까 사실은 조금 어렵다 ^^;

저작자 표시 비영리 동일 조건 변경 허락
Posted by readholic
ontoBox2009/07/01 19:48

그 동안 온톨로지에 대해 꽤나 지루한 이야기를 해왔다. 온톨로지에 대한 관심이 대단치도 않은 이 때에 과연 필요한 일인가 생각해 보지만, 현재로써는 최고의 대안이라 생각하기에 계속해서 이어나가 보기로 한다.

온톨로지는 정보를 보다 쉽게, 편리하게 찾고자 하는 노력이다. 실로 그 내용은 복잡하기 그지 없지만, 궁극적인 목적은 하나다. 손쉬운 정보의 탐색. 그 동안은 이 손쉬운 정보의 탐색을 위한 온톨로지는 어떤 녀석인가를 알아보았다. 온톨로지를 보다 확실히 이해하기 위해서는 이 온톨로지가 어떤 바탕을 갖고 있는지 알아볼 필요가 있겠다.


1. 사실에서 지식에 이르기까지

우리는 살아가는 동안 많은 판단과 결정의 순간에 놓이게 된다. 자장면을 먹을까 짬뽕을 먹을까 고민하는 그 순간이 참으로 어렵고도 힘든 판단과 결정의 순간이 아닌가! 우리는 대부분 자연스럽게 판단하고 결정하게 되지만 고도화되고 복잡해진 현대 사회에서는 이런 판단과 결정이 어려워지게 되었다. 얼마 전까지만 해도 판단과 결정에 대한 지침서 따위가 많이 나왔었다. 이른바 Decision making에 대한 훌륭한 가이드 라인들이었다. 많은 가이드 라인들은 의사결정을 위한 기초작업으로 정보의 수집을 꼽고 있다. 그리고 또한 성공요인으로는 노하우를 이야기 한다. 또 어떤 책에서는 객관적인 사실과 데이터에 근거한 결정이 현명하다고 말한다. 도대체 정보와 노하우, 사실과 데이터는 뭐가 뭐고 어떤 차이가 있을까?

정보체계는 대개 ‘사실(fact) < 데이터(data) < 정보(information) < 지식(knowledge)’ 으로 나누어진다. 사전적으로 “실제로 있었던 일이나 현재에 있는 일”로 정의되는 사실은, 사과가 땅에 떨어졌다와 같이 그저 있는 그대로의 것이다. 그 자체로는 아무런 쓸모가 없다. 사실이 어떤 식으로든 쓸모가 있어지는 것, 즉 유용성을 부여 받거나 갖게 될 때 데이터가 된다. 사과가 땅에 떨어지는 것을 보고 왜 그럴까? 라는 고민을 같는 순간 사실은 데이터가 된다. 다시 말해 데이터는 유용성을 내포한 사실이다. 여기서 중요한 것은 사실과 데이터 모두 주관이 배제되어야 한다는 것이다. 철저하게 객관적이어야 한다.

객관적인 데이터의 집합은 새로운 데이터를 생산하게 된다. 초콜릿은 심박수를 빠르게 한다는 사실은 심장의 활발한 운동은 신진대사를 활발하게 한다는 사실과 만나 초콜릿은 신진대사를 활발하게 한다는 데이터가 생산되고 이 생산된 데이터는 정보가 된다. 정보와 정보가 만나면 보다 복잡한 사실, 즉 지식이 된다. 객관적 사실들에서 생산된 정보가 오랜 시간 축적되어 많은 사람들에게 공감을 얻고 비로소 보편적인 진리로 인정된 것을 지식이라 한다. 물론 개인적인 경험과 외부의 정보를 얻어 축적된 개인적인 지식, 즉 노하우(knowhow)의 경우도 있다. 정보와 지식 모두 복잡한 사실관계를 갖고 있지만 오랜 시간 그 사실성을 유지하여 보편적 진리로 인정을 받는가에 따라 정보와 지식으로 구별될 수 있다.


2. 정보와 온톨로지

그렇다면 도대체 정보체계와 온톨로지는 무슨 상관이란 말인가.

지금까지 살펴본 사실에서 지식에 이르는 정보체계에서 사실과 데이터만을 포함하여 제공한 시스템이 웹이라면 온톨로지는 데이터를 넘어 정보를 제공하는 시스템이라 할 수 있다. 지식은 인간의 영역이다. 일각에서는 지식의 영역까지 자동적으로 추론하여 제공할 수 있도록 하는 것이 온톨로지가 가야 할 길이라고 말하고 있지만 개인적으로 지식은 인간만이 다룰 수 있는 영역이라 생각한다. 각설하고, 사실, 데이터, 정보가 온톨로지에서 어떻게 다루어지는지 생각해보자. 아니, 그 전에 온라인에서 이들이 어떻게 다루어지는지 살펴보아야 할 것이다.

사실(fact)은 실제 온라인에서 중요한 것이 아니다. 그보다는 데이터가 보다 중요한 것이라 하겠다. 웹상에서의 다양한 수치, 단어들은 이러한 데이터에 속한다 할 수 있겠다. 웹에서는 정보를 다룰 수 없었다. 아니 기계는 그렇지 못했다. 기계는 단순히 입력이 있으면 그에 대한 출력만 할 뿐이었다. 어찌 보면 이 입력들이 사실이라 할 수도 있겠다. 즉, 어떤 책, 예를 들어 국내에서 출판된 햄릿에 대한 사실은 저자가 William Shakespeare 이고 한글로는 셰익스피어로 읽으며 260페이지에 두꺼운 커버를 갖고 있으며 2004년에 출판된 책이라는 것이다. 이러한 각각의 사실은 이 사실이 필요한 사람에게 데이터가 된다. 기존의 웹은 이 데이터를 단순히 나열하고 보여주기만 할 뿐이다. 좀 불편하다, 고 생각한 사람들이 이리저리 고민하다 보니 데이터를 오밀조밀 모아보자고 생각했다. 기계가 정보를 주지 못할지언정 흉내라도 내보자는 것이다.

데이터를 접하는 인간의 입장에서는 이 데이터들, 나열된 데이터들은 인간의 머릿속에서 정보가 된다. 책에 대해 이것저것을 알 수 있다. 웹에는 이 데이터들이 가득하나 그 실마리를 알지 못하면, 즉 햄릿이라는 단어를 알지 못하면, 데이터를 찾기 힘들다. 이 데이터가 적어도 인간의 머릿속에서 정보가 될 수 있도록 편의를 고려한 것이 검색이다. 그런데 또 문제가 있다. 검색을 위해서는 조건이 필요한 것이다.

초기 검색은 단순히 단어를 포함한 것, 즉 그 키워드만을 가진 것, 그 키워드 앞뒤에 다른 단어가 혹은 글자가 있어도 무방한 것, 그것을 찾을 수 있도록 했었다. 사실로써 데이터를 찾겠다는 것이다. 그런데 또 문제가 생겼다. 데이터가 늘어나니 결과로 나온 데이터 중에 원하는 데이터를 찾기가 힘들어 진 것이다. 전문가들은 조건을 다양하게 선택할 수 있도록 했다. 온라인 상의 정보, 웹 상의 정보가 어떻게 구성되어 있는지 분석했다. 대개 제목이 있고 본문이 있고 가끔은 글쓴이도 있다. 뭔가 특징이 있었다. 그 특징을 일반화하자, 전문가들의 생각은 그랬다. 제목에 키워드가 포함된 것, 내용에 키워드가 포함된 것, 글쓴이의 이름이 키워드와 같은 것, 그 것을 찾아라. 하지만 데이터가 늘어날 수록 특징도 다양해졌다. 문제는 계속 발생했다. 하지만 그 해결책은 쉽게 나왔다. 특징이 다양하다면 특징을 구분하고 특징에 따라 실마리를 달자. 분야나 장르에 따라 구별하고 거기에 맞는 데이터를 미리 넣어두자는 생각에서 디렉토리 검색이 고안되었다. 데이터가 이야기 하고자 하는 것을 단어로 표현해서 꼬리표를 달자는 생각에서 메타태그가 고안되었다. 웹에서 온톨로지, 현실적으로는 시맨틱으로 옮겨 갈 수록 사실은 꼬리표가 되었다.

온톨로지에서는 사실을 관계로 나타냈다. A는 B의 상위 개념이고 B가 C의 상위 개념이라면 A는 C의 상위 개념이다. A, B, C가 특징이라면 해당되는 데이터간의 관계를 추론해 볼 수 있다. 관계는 그저 있는 그대로이다. 객관적인 데이터가 객관적인 관계를 갖고 있다면 객관적인 정보가 생산된다. C에 대한 데이터를 찾을 때 A와 B 모두를 보여 줄 수 있다. 예를 들어 A는 대륙권인 아시아, B는 나라인 한국, C는 수도인 서울이라 할 때 C의 데이터 서울만으로 서울은 아시아 권에 위치한다는 추론된 데이터, 즉 정보를 생산할 수 있다.

온톨로지에서 정보체계는 사실에 근거한 데이터 간의 관계를 통해 추론된 데이터인 정보를 제공할 수 있는 기반을 마련해주고 있다. 즉, 정보를 쪼개고 쪼개서 그 구조를 기계가 처리할 수 있도록 토대를 만들어 준 것이다. 물론 이 과정에는 또 다른 노력들이 있었다.

 

3. 밑바닥의 시작

정보를 찾기 쉽게, 관리하기 쉽게 하기 위한 노력은 수세기 전부터 있어왔다. 최초의 도서관이라 할 수 있는 알렉산드리아 도서관에서는 도서관에 어떤 책들이 있는지 목록을 만들어 두었다. 듀이와 랑가나단은 지식을 특성에 따라 구분하고자 분류법을 고안하였다. 문서를, 책을 기계로 관리하게 된 이래 문서 또는 책을 직접 보지 않고도 그 문서 또는 책에 대해 간략하게 알 수 있는 특징들을 정리하는 메타데이터가 등장하였다. 그리고 마침내 기계가 데이터와 데이터 간의 관계를 통해 새로운 데이터를 제공하는 온톨로지가 등장하였다. 물론 개념뿐만 이지만. 대신 현실적 대안인 시맨틱 웹이 구현되었다.

이런 많은 노력들을 단 한번에 정리하기는 어렵다. 다음 포스팅에서는 우선 목록부터 차근차근 살펴보도록 하겠다.

Posted by readholic
ontoBox2009/04/04 22:39

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

Posted by readholic
ontoBox2009/01/31 20:16

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

비단 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에서 깨짐)

  1. Deborah L. McGuinness. Frank van Harmelen. 2004. OWL Web Ontology Language Overview. W3C. (http://www.w3.org/TR/owl-features/) [본문으로]
  2. 모든 결론이 계산 가능함을 보증할 수 있는 성질 [본문으로]
  3. 모든 계산이 특정한 시간 내에 완료될 수 있는 성질 [본문으로]
Posted by readholic
ontoBox2009/01/30 20:28

온톨로지에 대한 부족한 글을 써놓은 지도 벌써 6개월여가 다 되어간다. 이런저런 핑계를 대며 미뤄온 온톨로지에 대한 이야기들을 다시 시작해 보고자 한다. 지난번에는 온톨로지의 기본요소들은 무엇이 있는지에 대한 이야기들을 하였다. 어쩐지 '필요할까'라는 생각이 들기도 하지만 온톨로지의 종류에 대해서 한번쯤은 짚고 넘어가는 작업이 필요하다고 본다. 어쨌거나 온톨로지를 이해해보기 위한 글이니까.

 

 형식상 분류

앞선 포스트에서 온톨로지는 클래스(Class), 관계(Relation), 함수(Function), 공리(Axiom), 인스턴스(Instance)의 다섯 가지 요소를 이용하여 형식화된다고 했다. 하나의 온톨로지는 이들 요소를 모두 갖추어 형식화됨으로써 의미가 분명한 온톨로지가 될 수 있다. Uschold와 Gruninger는 의미가 분명한, 그러니까 개념과 그 개념을 나타내는 용어가 분명히 정의된 온톨로지를 형식적 온톨로지라고 보고 조금은 모호한 기준으로 온톨로지를 다음의 네 가지 형태로 구분하고 있다[각주:1].

온톨로지 유형

설명

비형식적
(highly informal)

공리 없이 자연어로 자유롭게 표현된 용어의 집합

일반 사전, 용어사전

반비형식적
(semi-informal)

자연어의 제한적이며 구조화된 형식으로 표현하여 모호성을 줄임으로써 명확성을 상당히 높인 형태

시소러스, 계층 분류

반형식적
(semi-formal)

형식적으로 잘 정의된 언어를 통해 표현한 형태

XML 스키마, XML DTD, DB 스키마

형식적
(rigorously formal)

속성 등의 형식적 의미, 논리, 논증으로 정교하게 정의된 용어로 표현한 형태

시맨틱 네트워크, RDFs, OWL

어느 정도 의역하기는 했지만 그대로 옮겨 적은 것이라 아무래도 어렵다(어렵다는 말을 너무 많이 하는 것 같지만, 어려운 걸 어떡해 ㅜㅜ). 필자가 나름 이해한 바를 여러분께 전하자면, 이 형식성이라는 것은 컴퓨터가 읽을 수 있고 처리할 수 있는 형태로 표현하는 것으로 얼마나 정확하게, 정교하게, 모호하지 않게 표현했나 하는 정도에 따라 달라진다는 것이다. 뭘 정확하게, 정교하게, 모호하지 않게 표현하는가?

"개념용어로!"

개념은 우리의 머릿속에만 존재하는 것이다. 뭐 이견이 있을 수는 있겠지만, 어떤 면에서는 맞는 말이니까. 여튼, 이 머릿속에 존재하는 것을 눈에 보이게, 컴퓨터가 처리할 수 있도록 하기 위해서는 구체적인 형태를 갖추도록 해야 할 것이다. 용어가 바로 그 구체적인 형태이며 이 용어가 얼마나 개념을 잘 표현하고 있는지, 그 관계는 얼마나 정교하게 설정되어 있는가의 정도를 통해 형식성의 정도를 결정하는 것이다.


 

 적용 범위상 분류

온톨로지는 적용 범위에 있어서 크게 상위(upper-level) 온톨로지와 하위(lower-level) 온톨로지로 구분할 수 있다. 상위 온톨로지란 다양한 영역에 적용될 수 있는 상식적인 개념들을 정의하여 우리가 일반적으로 이해하고 있는 현실 세계를 표현하고자 한다. 반면 하위 온톨로지는 경계가 있는 특정 영역의 현실 세계를 구체화하는 것을 목적으로 하고 있다. 이러한 종류의 온톨로지는 특정 영역(domain)이나 분야에 한정된 시각에서 그 영역의 개념과 개념간의 관계를 정의함으로써 특정 영역을 구체화하고 체계화하고자 한다.

Guraino는 하위 온톨로지를 보다 구체적으로 구분하여 다음의 네 가지 유형으로 온톨로지를 구분하고 있다[각주:2].

  • 상위 수준 온톨로지(top-level ontology): 매우 일반적인 개념을 묘사하는 것으로 다양한 이용자, 개발자 등을 위한 통일된 온톨로지 이론 제공
  • 도메인 온톨로지(domain ontology): 특정분야에 한정된 개념들을 제공하며 개념 규정 시 보다 정제된 정의를 요구
  • 과업 온톨로지(task ontology): 특정 과업 수행을 위한 개념을 기술하며 일반 또는 특정 영역에서 사용하는 언어를 재사용하여 상위 수준 온톨로지에 도입해 사용
  • 응용 온톨로지(application ontology): 특정 영역과 과제 온톨로지 모두에 종속되는 개념을 묘사하는 것으로 온톨로지의 특수화라고 할 수 있음

상위 수준 온톨로지는 하위 온톨로지(도메인, 과업, 응용)의 최상위 개념을 기술하여 이들 개념이 연결될 수 있는 기반을 만드는 것이라 할 수 있다. 도메인 온톨로지와 과업 온톨로지는 특정 영역, 즉 보다 구체적인 영역에서의 개념들과 행위를 정의하여 실제로 온톨로지를 활용할 수 있는 기반을 만드는 것이다. 응용 온톨로지는 특정응용분야에서 요구되는 지식을 모형화하는데 필요한 모든 정의들을 기술한다. 응용 온톨로지는 흔히 도메인 온톨로지와 업무온톨로지의 어휘들을 해당 응용분야에 맞게 구체화하고 상세화 한다.

이러한 분류는 일반화 정도에 따른 분류라고 보는 사람들도 있다. 일반화라는 말이 크게 와 닿지 않는데 다른 말로 하자면 구체성이라고 할 수 있겠다. 넓은 범위에서 좁은 범위로, 일반적인 것에서 특정적인 것으로 대상의 표현을 구체화하는 것이다. 도메인 온톨로지와 과업 온톨로지는 상위 수준 온톨로지의 개념을 특정 영역과 행위로 보다 상세화하는 – 넓은 범위에서 좁은 범위로 – 것이다. 즉, 얼마나 구체적인가의 문제인 것이다.


 

 그 밖의 분류

온톨로지는 다양한 분야에서 그 목적에 맞게 개발되고 있다. 그렇기 때문에 각 분야의 관점에 따라 분류가 다르다. 앞에서 이야기한 형식상 분류와 적용 범위상 분류가 일반적인 분류라 할 수 있다. 이 밖에 특정영역에 관계 없이 지식표현 형식의 기초가 되는 표현 온톨로지, 일반적이고 기초적인 개념을 제공하는 일반 온톨로지, 도메인 온톨로지와 일반 온톨로지 사이에서 인터페이스로 사용되는 중개 온톨로지, 개념 정의와 관계 표현 정도에 따른 중량(Heavy-weight) 온톨로지와 경량(light-weight) 온톨로지 등 형태, 영역, 개발 방법 등 다양한 온톨로지가 분류되고 있다.

이처럼 온톨로지의 유형은 일일이 언급하기도 어려울 정도로 다양하지만 지식의 명확하고 분명한 표현과 포착을 위한 도구로써 개발되고 있다는 점이 중요하다.

  1. Mike Uschold & Michael Gruninger, Ontologies : Principle, Methods and Applications, Edinburgh, Edinburgh University, 1996 [본문으로]
  2. 이현실, “온톨로지를 이용한 의학용어의 개념 모델링 사례분석 연구,” 정보관리학회지, 제21권, 제3호(2004. 9) [본문으로]
Posted by readholic
ontoBox2008/08/02 18:55
  톨로지에 대한 포스팅을 한지 꽤 되었다. 논문이다 프로젝트다 핑계를 대고 미루어 왔지만 어쩐지 이대로 놔둘 수는 없는지라 온톨로지에 한 발 더 다가갈 수 있는 글을 남겨보고자 한다.

  지난 포스팅에서 온톨로지는 "이 세상의 지식, 즉 개념을 잘 정의하고 이들 간의 관계를 설명하기 위한 체계"라고 말했었다. Gruber 씨가 말씀하셨 듯이 "온토롤지는 공유된 개념의 정형화된 명세로" 이 정의와 나의 설명(정의라 하기엔 background가 빈약하여 ㅡㅜ)은 어느 정도 일맥상통하지 않는가 자부해 본다. 그렇다고는 해도 아직 잘 모르겠는 것이 온톨로지이다. 아무래도 온톨로지를 좀 더 알기 위해서는 어떻게 생겨먹었는지 알아볼 필요가 있겠다.

온톨로지의 기본 요소


  사람에게 이목구비가 있듯이, 자동차에 차체, 엔진, 바퀴가 있듯이 온톨로지도 모양을 갖추기 위한 구성요소가 있다. 엄격히 말하자면 기본 요소라 말하는 것이 맞겠다.

  결론부터 말하자면, 온톨로지는 개념, 관계, 함수, 공리, 인스턴스의 5가지 요소를 통해 지식을 표현한다. 좀 더 어려운 말로 하면 "온톨로지는 지식은 클래스(Class), 관계(Relation), 함수(Function), 공리(Axiom), 인스턴스(Instance)의 다섯가지 요소를 이용하여 형식화된다[각주:1]" 라고 할 수 있다. 그럼 하나하나 살펴보도록 하자

1) 클래스(개념): 클래스는 앞선 포스팅에서 설명했던 개념화 또는 개념의 정의로 생각할 수 있다. 개념의 정의에 대해서는 Note 정도로 잠시 후에 이야기 해보겠다.

2) 관계: 관계는 클래스로 정의된 개념들의 상관관계를 나타내는 것으로 문장 성분으로 따지면 '~하다, ~이다' 와 같은 서술어 부분에 해당한다.

3) 함수: 이는 관계가 특정한 값을 가질 때, 즉 계속해서 사용이 되는 관계, 특정한 관계가 될 때 성립되는, 일종의 공식과 같은 것으로 이해하면 된다.

4) 공리: 공리는 일반적으로 '두루 통하는 진리나 도리'라는 의미를 가지나 온톨로지에서는 수학적 정의인 "증명이 없이 자명한 진리로 인정되며, 다른 명제를 증명하는 데 전제가 되는 원리"라는 의미로 이해하는 것이 보다 정확하다. 이 공리를 전제로 추론이 가능하게 된다.

5) 인스턴스: 데이터베이스를 공부하신 분이라면 좀 익숙하실텐데, 온톨로지에서도 역시 같은 의미로 이해하시면 될 듯하다. 인스턴스는 온톨로지에서의 실제 값, 즉 더 이상 나눌 수도 의미를 부여할 수도 없는 지경에까지 이른 데이터이다. - 어쩐지 논란의 여지가 있을 듯하나 이해하기에는 무리 없을 듯하여 pass~~ -

 그럼 이들 요소는 어떻게 써먹을까? 말로 설명하기엔 좀 복잡하니 그림으로 보면..
사용자 삽입 이미지
문장으로 나타내보면,

"SUV는 자동차의 한 종류이다"

가 된다. 즉, '자동차는 클래스다', 'SUV는 클래스다' 라는 대전제 다시 말해, Axioms에 의해 SUV와 자동차를 비교해볼 여지가 생기고 그 비교는 'A는 B의 한 종류이다'라는 관계로 정의되어 실제 값인 인스턴스에 새로의 정보 또는 의미를 부여할 수 있게 되는 것이다. 여기서 관계가 'IsKindsOf'과 같은 계속해서 사용하게 되는 경우 '함수(Fucntion)'이 되는 것이다.

  온톨로지적 추론에 의해 스포티징은 SUV의 인스턴스이므로 SUV와 자동차와의 관계에 따라 스포티징은 자동차라는 새로운 정보(또는 의미)가 생성된다.

  현재는 온톨로지를 사용하여 인간의 지식과 같은 정교한 수준의 논리적 추론은 아무래도 힘들지만 논리적 구조를 잘 짜면 가능할 수 있다(아직 해보지 않아서 ㅡㅡ;). 논리적으로, 이론적으로는 새롭게 생성된 정보, 즉 의미가 부여된 정보를 클래스로 정의하여 논리적 추론에 재사용할 수 있지만 견문이 부족한 탓에 아직 실예를 본 적은 없으므로 섣불리 말하기는 어렵다.

Note  Classification & Taxonomy
  개념을 정의하는 방법은 매우 다양하겠지만 문헌정보학의 한 영역인 정보조직에 대한 이해가 있다면 좀 더 효과적이고 효율적인 방법을 찾을 수 있을 것이다. 문헌을 체계적으로 조직, 쉽게 말해 잘 정리하기 위해서 고대부터 목록을 작성하였다. 문헌정보학의 정보조직 영역은 이러한 문헌정리를 위한 목록의 작성을 포함하여 정보의 체계적 조직에 이르는 광범위한 정보 조직 체계에 대해 연구하고 있다.
  정보를 체계적으로 조직하는 가장 큰 이유는 특정 정보를 쉽고, 빠르고, 정확하게 찾기 위해서라고 할 수 있겠다. 따라서 정보의 특성, 속성을 고려하여 공통된 특성, 속성을 같는 정보를 따로 정리하고 이러한 정보의 묶음에 쉽게 알아 볼 수 있는 이름을 붙여주면 굉장히 편리할 것이다. 하지만 어떤 정보가 언제 생길지, 얼마나 더 많이 생길지 알 수 없는 일이다. 문헌정보학에서는 지식이 정보를 포함하고 있다고 여기고 지식을 공통된 특성, 속성에 따라 먼저 나누어 묶어 두고자 연구했다. 그것이 바로 분류학이다.

  분류는 classification과 taxonomy의 측면에서 살펴 볼 수 있다. 둘 모두 분류법으로 국역되지만 둘은 조금 의미를 달리해야 한다. classification은 철학적 분류, taxonomy는 실용적 분류 정도로 볼 수 있을 것이다. 철학적 분류와 실용적 분류의 차이는 오토바이를 분류함에 따르는 차이를 예로 이해해 볼 수 있다. 오토바이를 자동차로 분류할 수 있는가. classification에서는 조금 어렵다. 자동차라 함은 네 개의 바퀴를 갖고 있으며 엔진으로 그 바퀴를 돌려 이동하는 장치 혹은 도구이다. 하지만 오토바이는 바퀴가 두 개뿐이므로 엄격한 의미에서는 자동차라 할 수 없다. 그러나 엔진을 갖고 그 힘으로 바퀴를 돌려 이동하기 때문에 어떤 의미에서는 자동차라 할 수 있다. classification은 논리적, 철학적으로 사물이나 현상, 개념 등을 유사한 것은 모으고 상이한 것은 구분한다. taxonomy에서는 조금 다른 관점에서 접근하여
시스템의 체계 및 계통 등을 일정한 규칙에 따라 분류한다. 다시 한번 오토바이의 예를 들면, 오토바이는 단순히 운송수단으로 분류될 수도 있고 2륜 원동장치로 분류될 수 있다. taxonomy는 분류의 목적 및 활용에 매우 의존적이다.

  이러한 분류의 개념을 이해한다면 개념을 정의하는데에 많은 도움이 될 것이다. 온톨로지에서 개념의 정의는 해당 온톨로지의 활용 목적을 고려해야하지만 개념적으로 정의하여 공유될 수 있어야 하므로 논리적, 철학적으로 정의하는 것 또한 중요하기 때문이다.



온톨로지 예전 포스팅
2008/04/29 - [ontoBox] - 온톨로지에 대한 쉬운 설명
2008/01/29 - [ontoBox] - 온톨로지란 무엇인가

                                                                         
  1. Oscar Corcho. Mariano Fernandez-Lopez & Asuncion Gomez Perez. Onto Web Technical Road-map v1.0. IST Programme of the Commision of the European Communities as Project No. IST-2000-29243. pp.10-11.[서휘, 2006, 온톨로지 자동구축을 위한 OWL의 어휘와 구문 사용방법에 대한 이론적 연구, 한국도서관․정보학회지, 제37권 제2호, 재인용] [본문으로]
Posted by readholic