온톨로지에 대해서

원본 자료는 여기에

온톨로지

어떤 세계에 대해서 모든 구성 요소를 디지털 세계의 형식으로 표현될 수 있도록 만든 것이 온톨로지의 정의다.

온톨로지의 원말은 철학에서 '존재론'이라는 것에서 번역된 것으로 존재에 대한 이해를 추구하는 학문의 의미이다.

우리가 가지고 있는 인문학(사실 세계)에서 시맨틱 데이터로 변화하는 과정은 다음과 같다고 할 수 있다.

1. 사실 세계를 가져온다.
2. 사실 세계에서 시맨틱 모델링을 만든다
3. 시맨틱 모델링에서 온톨로지 구조를 만든다.
4. 온톨로지 구조를 바탕으로 큐레이션를 만들어낸다.
5. 온톨로지 구조를 바탕으로 시맨틱 데이터를 만들어낸다.

큐레이션은 총 3가지 모습으로 나타남

1. 모델링 하는 과정에서
2. 온톨로지에서 시맨틱 데이터를 만드는 과정에서
3. 시맨틱 데이터가 만들어진 이후 그것을 바탕으로 만드는 것

정보 기술 분야에서 말하는 온톨로지는 ‘명시적 명세화의 방법에 의한 개념화’(explicit specification of a conceptualization)이다. 정보화하고자 하는 대상 세계를 일정한 체계 속에서 파악하는 것, 예를 들면 그 세계에 무엇이 있고, 그것은 어떤 속성을 품고 있으며, 그것들 사이의 관계는 무엇인가 하는 일정한 질문의 틀 속에서 대상 세계를 이해하는 방식이라고 할 수 있다.

여기서 명세화(specification)는 대상세계의 존재하는 개체 속성 관계 등을 일목 요연한 목록으로 정리하는 것이다. 여기서 명시적(explicit)이란 개념은 정리된 목록이 사람이 읽을 수 있는 것 뿐만 아니라 기계도 읽을 수 있어야 한다는 것이다.

그러므로 그 사실 세계에서 존재하는 모든 개체(individuals)들을 클래스(class)로 범주화 하고, 각각 클래스에 속하는 개체들의 공통 속성(attribute, datatype property)를 가지게 한다. 여기서 개체 들과 개체들이 관계(relation, object property)를 맺을 수 있도록 명시적 기술을 하는 것이 일반적인 온톨로지 설계이다.

온톨로지 구성요소

온톨로지 구성 요소	용도	Web Ontology Language(OWL)
온톨로지 구성 요소 (권장 용어)	용도	Web Ontology Language (OWL)
Class, 클래스	공동의 속성을 가진 개체들을 묶는 범주 a group of individuals that belong together because they share some properties.	owl:Class
Individual, 개체	클래스에 속하는 개체 Instances of classes	owl:NamedIndividual
Relation, 관계	(같거나 다른 클래스에 속하는) 개체들 사이의 관계 relationships between pairs of individuals	owl:ObjectProperty
Attribute, 속성	개체가 속성으로 갖는 데이터 값 relationships from individuals to data values	owl:DatatypeProperty
Relation Attribute, 관계 속성	관계 정보에 부수되는 속성 attributes related to relations	N/A in OWL Can be used when you implement Graph Database with Cypher Query Language.
Domain, 정의역	특정 ObjectProperty 또는 DatatypeProperty의 주어가 될 수 있는 클래스를 한정 A domain of a property which limits the individuals to which the property can be applied	rdfs:domain
Range, 치역	특정 ObjectProperty의 목적어가 될 수 있는 클래스를 한정 The range of a property limits the individuals that the property may have as its value	rdfs:range

클래스(class)

온톨로지 설계에서 ‘클래스’라고 하는 것은 대상 세계의 다양한 구성 요소들을 유형별로 묶는 범주이다.

클래스 설계는 대상 세계를 무차별적인 사실이나 사물의 나열로 보지 않고, 일정한 체계 속에서 이해하려는 노력이라고 할 수 있다. 따라서 어떠한 클래스를 정하느냐 하는 것은 연구자가 대상을 어떠한 시각에서 보고자 하느냐에 따라 달라진다.

위 말을 다시 풀이하자면 대상 세계는 동일하더라도 그것을 이해하는 클래스 연구자가 다른 시각을 가지고 있다면 그 연구자에 의해서 다른 정의의 클래스 기준이 만들어지는 것이다.

클래스를 설정해야 하는 이유는 2가지 관점에서 설명 할 수 있다.

1. 사실세계를 큐레이션 하는 과정에서 대상 세계의 구성 요소를 균형적으로 파악하고 있는지 확인하는 가이드라인 역할을 한다. 마땅한 기준이 없으면 데이터는 어느 한 방향으로 편중되고 대상 세계를 균형적으로 보이는 것이 불가능 하다.
2. 개체의 속성이나 개체 사이의 관계를 기술할 때 유효성과 정확성을 높이는 데 도움이 되기 때문이다.

위 내용을 종합해본다면 온톨로지 설계는 관계형 데이터베이스의 엔티티와 유사한 것을 알 수 있다. 즉 관계형 데이터베이스 설계에 익숙한 사람은 온톨로지 설계에서 어렵게 생각하지 않는다. 다만 인문계 학생들의 경우 클래스를 학문적 분류 체계로 오해를 하는 상황이 종종 발생해 어려움을 보이고 있다. 여기서 주의해야 할 점은 복잡한 인문학 기준에서 분류의 기준은 매우 난해하고 빠져나가기 힘든 함정이다. 이런 함정에 빠지지 않고 본인이 관심있는 유형에 것들을 데이터 세계로 옮기는데 중점을 두라는 것이다.

개체(Individual Object)

앞에서 언급한 class 는 대상 세계의 다양한 구성 요소를 유형별로 묶어서 보려는 것이지 실제로 존재하는 것이 아니다. 예를 들어 하나의 인간형 동물을 본다고 전체 인간을 정의 할 수 없으며 무수히 많은 인간형태를 묶어서 인간으로 볼 수 있기 때문이다. 즉 묶어 놓고 보니 보이는 개념이다.

그러므로 개체는 사실 세계에서 실제로 존재하는 Object 물체 모든 것을 말한다.

물리적인 세계에 존재하는 개체의 어느 것을 선택해서 그것을 디지털 세계의 개체로 옮겨 놓는 작업, 즉 개체 데이터를 만드는 작업은  ‘온톨로지 설계’가 아니라  먼저 만들어진 온톨로지에 따라 시맨틱 데이터를 만드는 일에 해당한다. 하지만 앞으로 만들어질 다지털 세계의 개체가 어떤 요건을 갖추어야 하는지, 어떤 속성을 가질 수 있는지를 정하는 것은 온톨로지 ‘설계’에 속한다.

그리고 온톨로지 세계에서 개체가 되기 위해서는 식별자와 클래스 소속 두가지 요소가 필요하다.

식별자

무엇보다 먼저, 데이터로서의 개체는 그것을 유일하게 식별할 수 있는 고유한 이름(identifier, 식별자)을 가져야 한다. 그래야만 하나의 개체를 다른 것과 연결지을 때 혼란과 애매함이 발생하지 않기 때문이다. 이것은 개체를 데이터로 정리할 시 ID라고 부르는 것이다.

인문지식 큐레이션을 위해 온톨로지를 사용하고자 할 때에는 개체에 대해 식별자를 부여하는 기준과 방법에 대해 충분히 숙고해야 한다. 예를 들어서 역사에 등장하는 다양한 동명이인 사람들의 대한 식별자를 구별하거나, 아명이나 다른 언어로 쓰인 인명을 같은 식별자로 부여하는 등 여러가지 사례가 있기 때문이다. 반면에 시간에 따른 동일 물품으로 불리더라도 그 시간의 물품과 다른 시간의 물품은 다른 것이기 때문에 이걸 다르게 식별한다는지 하는 것이다.

그리고 시맨틱 데이터가 온라인 환경 월드와이드웹 전역에서 유통될 수 있게 하려는 시맨틱 웹에서는 특정 온톨로지가 정의된 개체가 범지구적으로 유일하게 식별 될 수 있게 인터넷 주소 형식으로 이름을 부여한다.

http://dh.aks.ac.kr/individuals#이귀-1557 -> 한중연 웹사이트 아래 객체 이귀-1557 식별자

http://dh.aks.ac.kr/individuals#표피방석 -> 한중연 웹사이트 아래 객체 표피방석 식별자

이 형식은 특정 온톨로지 안에서 정의된 개체 식별자 앞에 인터넷 주소 형식의 이름공간(namespace) 식별자(URI, uniform resource identifer) 를 붙이는 것이다. 이름 공간(namespace)이란 하나의 이름이 단 하나의 개체만을 가리키는 범위를 추상적으로 상정한 것이며, 그것이 URI 형태를 취하는 것은 인터넷 상에서 유일성을 보장하는 명명법이기 때문이다. 이름 공간(namespace)의 URI는 그저 이름일 뿐이며, 그 주소에 해당하는 사이트가 인터넷 상에 꼭 있어야 하는 것은 아니다.

클래스 소속

온톨로지의 개체는 예외없이 어느 하나의 클래스에 속한다. 필요에 따라 두 개 이상의 클래스 속하게 할 수도 있는데 그것도 기준과 원칙을 세워 두어야 한다. 특히 2개의 클래스가 속하는 단계에 있어서는 매우 골치 아픈 상황으로 발전 할 수 있다. 여기서 대부분 분류의 함정에 빠지게 된다.

‘황성신문’은 남궁억 등이 설립한 신문사이고, 을사조약에 항의한 장지연의 논설 ‘시일야방성대곡’이 실린 ‘기록물’이며,  현재의 종각역 5번 출구 근처에 자리했던 황성신문사 건물을 뜻하기도 한다. 이 내용을 종합하면, 황성신분은 신문사 기록물 건물 이라는 3가지 클래스가 중복이 되게 된다.

이 경우 이렇게 처리하는 방식이 있다.

Source	Target	Relation
황성신문(신문)	황성신문(신문사)	publisher
황성신문(건물)	황성신문(신문사)	isOfficeBuildingOf
황성신문(신문사)	남궁억	founder
시일야방성대곡	황성신문(신문)	isPostedIn
황성신문_터	황성신문(건물)	isSiteOf

이 방법은 황성신문 뒤에 세부 텍스트를 넣어 모두 다른 식별자로 구별하고 그것을 Relation으로 묶어서 처리한 것이다.

또는 아예 신문 건물 신문사 등등 따로 클래스를 설정하여 처리하는 방식이 있다.

여기에 대해서는 절대적인 규칙은 없다. 이 온톨로지 설계에서 본인이 큐레이션 하여 보이고 싶은 것에 일관된 기준을 가지고 진행하는 것이 있어야 한다.

관계성(Relation, Object Property)

‘관계성’이란 개체가 가질 수 있는 속성 가운데 다른 개체와의 관계로 설명될 수 있는 것을 말한다.

다음 아래 예시를 보자

1. 김홍도의 아들은 김양기이다 -> 관계성 표현
2. 김홍도의 호는 단원이다 -> 속성

여기서 ‘아들이 김양기’라는 것과 ‘호가 단원’이라는 것은 모두 ‘김홍도’라는 개체가 가지고 있는 특성을 이야기하는 것이라고 할 수 있다. 그런데 첫 번째 문장에 나오는 ‘김양기’는 ‘김홍도’와 마찬가지로 한 사람의 인물이라는 점에서 독립적인 개체로 인정될 수 있는 존재이다. 이에 반해 ‘단원’은 굳이 독립적인 개체로 삼을 필요가 없고 ‘김홍도’라는 인물에 종속된 데이터로만 쓰면 된다. 전자는 ‘관계성’(Relation)의 표현이고 후자는 ‘속성’(Attribute)의 표현이다.

즉 다시 말하면 1번 문장은 김홍도와 김양기의 관계성을 설명한 것이라 관계성 표현이고, 2번 문장은 김홍도의 호는 단원이라는 속성 이라는 것이다.

그리고 관계성은 데이터화 할 수 있다. 이런 구조를 RDF(Resource Description Framework)라고 부른다. 아래 예시를 보면 알 수 있다.

source	target	relation	설명
김홍도	김양기	hasSon	김홍도는 김양기를 아들로 두었다.
단원유목첩	김홍도	creator	단원유목첩의 창작자는 김홍도이다
단원유목첩	김양기	contributor	단원유목첩의 기여자는 김양기이다
단원유목첩	국립중앙박물관	currentLocation	단원유목첩은 국립중앙박물관에 소장되어 있다
김양기	호산외사	isMentionedIn	김양기는 호산외사라는 책에 언급되어 있다
호산외사	조희룡	creator	호사외사의 저자는 조희룡이다

RDF 문의 구조는 단순하다. 하지만 다양한 관계서술어를 정의해서 사용할 수 있고 이것을 이용하여 서로 관계가 있다고 판단되는 모든 개체들을 연결해 줄 수 있기 때문에 대상 세계의 복잡한 사실 관계를 구조적인 데이터로 전환하는 역할을 할 수 있다.

RDF 구문에 사용하는 관계서술어 어휘는 클래스(Class) 정의와 마찬가지로 온톨로지 개발자가 정하는 것이다.

다만 본인이 온톨로지 설계한 클래스나 관계서술어 어휘 뿐만이 아니라 여러 전문분야의 국제적인 기구나 단체에서 해당 분야 데이터의 교환·공유를 위해 제정한 온톨로지의 어휘들을 참조할 수 있다. 이 두가지를 절충해서 사용하는 것을 권장한다.

속성(Attribute, Datatype Property)

개체와 개체의 관계성을 설명하는 것은 관계성(relation)을 말하는 것이며 여기서 설명하는 것은 다른 개체와 무관하게 그 개체에 속한 특성을 문자나 숫자 값으로 서술하는 것을 ‘속성’(Attribute, Datatype Property)이라고 한다. 예를 들어 화가 김홍도에 대해 그의 호가 ‘단원(檀園)’이었다거나, 그의 출생년도가 ‘1745년’이라고 하는 등의 정보는 대체로 ‘속성’ 데이터로 취급되는 경우가 많다.

보통 한 개체에 대해서 무수히 많은 속성이 있을 수 있지만 본인 큐레이션 및 만들려고 하는 온톨로지 설계에서 취사선택을 할 수 있다.

그러므로 온톨로지의 속성 설계는 관계성 설계와 마찬가지로 처음부터 망라적인 탬플릿을 만들려 하기보다는 현재의 실용적인 관점에서 쓰임새가 있는 요소들을 위주로 하는 것이 권장된다. 향후 대상 자원이나 활용 목적이 확장되었을 때 새로운 속성 요소를 추가하는 것이 가능하기 때문이다.

관계 속성(Attribute of Relationship)

‘관계 속성’이란 두 개체 사이의 관계에서 파악되는 특성에 대한 정보이다. 예를 들면 다음 아래와 같다.

조선 영조의 왕비가 정순왕후였음을 알리려면 ‘조선_영조’와 ‘정순왕후’라는 두 개체를 ‘hasWife’라는 관계어(Relation, Object Property)로 연결해 주면 된다.

그런데, 정순왕후가 영조의 두 번째 왕비였음을 부가적으로 알리고자 한다면, 그 정보는 어디에 귀속시켜야 할까? 여기서 ‘두 번째’라는 정보는 ‘조선_영조’ 또는 ‘정순왕후’라는 개체의 속성이 아니고, ‘hasWife’라는 관계어의 속성도 아니다. 그것은 ‘조선_영조’가 ‘정순왕후’를 ‘아내로 삼았다(hasWife)’고 하는, 두 개체 사이에 맺어진 관계(relationship, connection)의 속성이다.

이렇듯 두 개체 사이의 연결이 이루어졌을 때 부수적으로 발생하는 특성을 ‘관계 속성’이라고 부르기로 한다.

‘관계 속성’은  ‘관계어’만으로는 표현하기 어려운 관계의 정황을 데이터화하기 위해서 사용한다. 위의 예에서 보인 관계의 순서를 비롯해, 횟수, 분량, 강도 등에 관한 정보를 부가하거나 관계성을 만들어낸 행위에 부수되는 정보(시점, 역할 등)를 표시한다. 역사 사실에서 두 사이의 관계에서 시간 속성을 부여하고 싶으면 두 사건이 일어난 시기도 관계 속성으로 표시 할 수 있다.

온톨로지 기술언어

이상에서 언급한 클래스, 개체, 관계성, 속성, 관계 속성 등이 온톨로지를 설계할 때 필수적으로 포함시키는 주요 구성 요소들이다. 대상 세계를 분석해서 그 세계를 정보화하는 데 필요한 온톨로지 요소들을 디자인하는 구상이 이루어졌다면 다른 사람들도 그 구상을 이해하고 참조할 수 있도록 정리해 놓을 필요가 있다.

이와 관련하여 가장 권장할 만한 방법은 온톨로지를 설계할 때 ‘온톨로지 편집기(Ontology Editor)’라는 유형의 소프트웨어를 사용하는 것이다. 온톨로지 편집기는 ‘온톨로지’의 설계와 검증, 지속적인 확장 및 수정, 보완 기능을 제공하는 소프트웨어이다. 이용자는 이 소프트웨어상에서 클래스, 속성, 관계성, 개체 등 온톨로지 핵심 요소들을 디자인할 수 있고, 데이터의 입력을 통해 어느 정도 규모의 실험적인 데이터베이스를 구축할 수도 있다. 온톨로지 편집기상에서 데이터 클래스의 구조, 개체 상호간의 관계성 등을 시각적인 그래프로 확인하는 것도 가능하다.

온톨로지 편집기는 온톨로지 설계와 그 결과의 확인을 용이하게 하지만, 그것을 쓰는 보다 큰 이유는 이 소프트웨어를 사용함으로써 온톨로지 설계의 결과를 ‘웹 온톨로지 언어(Web Ontology Language, OWL)' 라고 하는 표준적인 온톨로지 기술 언어로 문서화할 수 있기 때문이다.

나는 주관적으로 이 기계적 언어의 터득이 인문지식의 디지털 큐레이션을 위한 선행과정으로서 반드시 필요한 것은 아니라고 판단한다. OWL은 온톨로지를 기술(記述)하는 방법의 하나일 뿐, 온톨로지 설계의 절대적인 기준은 아니기 때문이다. 실제로 인문학 영역에서 추구하는 지식을 데이터화할 때, OWL의 규칙을 그대로 따르는 것이 불편하거나 비효율적인 경우도 적지 않다. 실제적인 데이터 아카이브의 구현을 위해서는 온톨로지 설계 기법과 함께 데이터베이스 구축에서 일반적으로 사용하는 엔티티 설계의 방법을 혼용해야 할 필요도 있다. 내가 이 책에서 지향하는 것은 독자들이 온톨로지 기반 데이터 큐레이션의 목적과 취지를 충분히 이해하고 그 방법을 준용할 수 있게 하되, 그것을 위해 마련된 기술적 형식의 세세한 부분에는 구애될 필요 없이 보다 유연한 방법으로 인문지식 큐레이션의 결과를 얻을 수 있게 하려는 것이다.