Ontology Development 101: A Guide to Creating Your First Ontology
Natalya F. Noy and Deborah L. McGuinness
Stanford University, Stanford, CA, 94305
noy@smi.stanford.edu and dlm@ksl.stanford.edu
인간과 컴퓨터의 자유로운 소통은 오랜 과제였다. 사람의 언어를 컴퓨터가 이해하도록 만들기 위해, 수많은 프로그래밍 언어가 개발되었고, 인간의 언어인 자연어를 컴퓨터로 처리하려는 시도들이 이어졌다. 이 과제는ChatGPT를 비롯한 LLM의 등장으로 결정적 전환점을 맞았다. LLM 기반의 AI 에이전트는 자연어를 이해하고 상호작용을 하면서, 스스로 판단하는 것 '처럼’ 보인다. 최근 이러한 AI기술의 진화속도는 전문가도 따라가기 힘들 정도로 가속화되고, 적용 범위도 점차 넓어지고 있다. 이제 인간과 컴퓨터의 소통은 진정으로 완성될 것인가?
AI의 발전 과정은 인류 문명의 진화와 닮아 있다. 인간이 돌도끼에서 부터 청동, 철기 시대로 이동하며 새로운 도구를 손에 넣었듯, LLM을 기반으로 동작하는 에이전트에게도 다양한 도구들이 주어지기 시작했다. 에이전트가 외부 시스템을 호출하고 자동으로 업무를 수행할 수 있게 해주는 기능의 연결, 즉 Agent-to-Function(A2F)을 위한 표준으로 MCP(Model Context Protocol)와 Function Calling이 그 역할을 맡는다.
'도구'의 진화가 인간의 생활을 변화시켰다면, '협력'은 생산성과 방향성을 가진 집단 문명을 만들어냈다. 사람들이 무리를 이루고 협업하면서 마을이 생기고 부족과 국가가 형성되었듯, 이제 에이전트들도 혼자 작동하지 않는다. 그들도 서로 정보를 교환하고, 역할을 나누며 협력한다. 이것이 Agent-to-Agent(A2A)이며, 멀티에이전트 프레임워크가 그 기반이 된다.
한편 AI 에이전트는 결국 데이터를 통해 물리적, 사회적, 환경적 세계를 배운다. 데이터를 구조화해 질의하는 Text-to-SQL 엔진, 비정형 지식을 검색하는 벡터 DB, 이를 연결하는 임베딩 모델은 AI가 ‘지식에 접근하는 방식’을 책임진다. 이는 인류가 인쇄술을 발명하고, 책을 만들고, 도서관을 세우고, 인터넷을 통해 지식을 연결한 역사와 맞닿아 있다.
인류의 최초 문자는 그림이었다. 그림으로 기록을 남기고, 문자를 발명해 책으로 지식을 저장하고, 텍스트와 영상으로 정보를 전달하며 지혜를 공유하는 오늘날 문명을 만들어 왔다. 이 지식들은 결국 인터넷이라는 웹(Web) 공간으로 집결했고, AI역시 그 위에서 학습하고 추론한다. 이 '웹(Web)' 이라는 공간은 데이터로 구성된 인류의 집단 지성을 품고 있으며, AI가 탐색하고 학습하는 하나의 거대한 하이퍼 스페이스(Hyper Space)가 되었다. 웹 공간은 인류와 AI가 협력하는 사회이자, 기업이고, 국가 그 이상의 의미를 가진다.
그러나 이 모든 컴포넌트가 개별적으로 존재하는 것만으로는 ‘지능형 시스템’이라 부르기 어렵다. 서로 다른 국가와 집단은 쓰는 용어도 개념도 다르다. "dog" = "개" 로 인식하는 통번역은 인간이 가진 개념을 통합하는 원초적인 시스템이다. 이제는 모든 인류와 모든 컴퓨터, AI Agent 들을 구성하는 시스템 전체를 관통하는 개념적 지식 구조가 필요하다.
이는 서로 다른 데이터·프로세스·규칙·관계를 일관된 방식으로 연결해주는 상위 추상화 계층이 존재해야 한다. W3C*는 이 흐름을 일찍이 예견하고 ‘시맨틱 웹(Semantic Web)’이라는 개념을 제안했다. 웹 위의 모든 개념과 관계에 태그를 붙여 의미적으로(Sematic) 서로 연결(Web)하자는 발상이었다. 이것은 인간이 인지하는 모든 지식구조를 컴퓨터가 이해하도록 만들기 위한 시도였다. 당시에는 지나치게 이상적이라는 평가도 있었지만, LLM·RAG·Agentic AI가 부상한 지금, 그 아이디어는 다시 주목받고 있다. AI가 세상을 추론할 수 있는 기반, 곧 지식의 구조를 명시적으로 정의해야 한다는 요구가 커지고 있기 때문이다.
* W3C : 월드 와이드 웹 컨소시엄(World Wide Web Consortium), 웹 표준 개발 국제 기구
바로 그 역할을 수행하는 것이 온톨로지(Ontology)이다. 온톨로지는 팔란티어의 주가 덕에 유명해졌지만, 지금으로부터 약 2400년전의 철학자이자 "인간은 사회적 동물이다" 라는 말로 우리에게 친숙한 "아리스토텔레스"에 의해 연구되어 온 분야이다. 그에 따르면 온톨로지는 "존재의 개념과 그 개념사이의 관계를 정의한 명세서" 이다. 예를 들면, "인간이 인공지능을 만들었다." 는 인간(Object) → 인공지능(Object), 사이의 관계 '만들다'(make : Relation) 가 존재한다. 다시 인간은 이름, 성별, 지능 등의 다양한 속성을 지니고, 인공지능 또한 모델명, 기능, 목적 등의 속성을 가질수 있다. 그리고 관계는 '만들다' 뿐만 아니라, 역방향으로 인공지능(Object) → 인간(Object), '돕는다'(help : Relation)는 관계를 정의할 수도 있다.
이처럼 온톨로지는 객체, 속성, 관계, 제약조건, 도메인 규칙을 명시적으로 정의함으로써 지식을 통합적 구조로 정의한다. 앞서 설명한 LLM, 에이전트, 함수호출, 데이터베이스 체계가 모두 온톨로지 위에서 같은 의미의 정합성을 확보할 때, AI는 단순한 자동화를 넘어 ‘문맥을 이해하고 추론하는 시스템’, 인간과 진정으로 소통하는 존재로 발전한다. 이러한 구조적 지식 기반이 마련되어야 비로소, '디지털 트윈' 을 통해 현실 세계를 논리적으로, 동적으로, 예측 가능하게 모사할 수 있다.
AI 기술의 눈부신 발전에도 불구하고, 저자 스스로는 연구원으로서 2024년과 2025년 동안 생성형 AI, RAG, Agentic AI를 연구하며 많은 한계와 어려움을 마주했다. 이는 아마 저자 만의 문제가 아닐 것이다. 그 끝에서 다시 주목받고 있는 온톨로지(Ontology)와 디지털 트윈(Digital Twin)이라는 개념을 통해 잠시 생각의 정거장을 만났고, 시작은 있었지만 끝을 알 수 없는 공부를 계속 이어가고 있다. 이 글은 그 과정에서 마주한 선구자들의 지식과 경험, 논문들을 정리한 기록이다.
대표적으로 2001년 스탠퍼드대학교에서 진행된 연구 'Ontology Development 101: A Guide to Creating Your First Ontology'는, “왜 온톨로지를 만들어야 하는가?”라는 질문에서 출발해 처음 온톨로지를 구축하는 사람도 따라 할 수 있는 실무 중심의 방법론을 제시한다. 논문 제목에 사용된 ‘101’은 미국 대학에서 입문 과목 번호를 관습적으로 ‘101’로 붙이는 전통에서 유래한 것으로 보인다. 예를 들어 Psychology 101은 심리학 입문, Computer Science 101은 컴퓨터공학 기초를 의미한다.
다시 말하지만 팔란티어(Palantir)의 주가상승 덕분에 명성을 되찾은 '온톨로지'는 새로운 개념이 아니다. 온톨로지는 여러 대형 시스템의 핵심 요소가 되었지만, 이에 비해 교육 자료와 가이드가 부족했다는 문제의식을 가진다. 위 논문은 선언적 지식 표현 시스템(declarative knowledge representation)을 기반으로 온톨로리를 만드는 절차를 단계별로 설명하며, 특히 Protégé-2000, Ontolingua, Chimaera 같은 도구에서 저자들이 실제로 겪은 경험을 바탕으로 한다. 이 과정은 “와인–음식(wine & food)” 예제를 사용해, 개념(클래스)을 정의하고, 속성(슬롯)을 만들고, 제약(facets)을 주고, 인스턴스를 채워 넣는 흐름을 보여 준다.
또한 이 방법론은 프레임 기반 시스템(frame-based systems)을 대상으로 하지만, 객체 중심(object-centered) 시스템 전반에서 적용 가능한 일반적인 가이드로 제시된다. 결과적으로, 이 논문은 “처음 온톨로지를 만드는 사람에게 필요한 가이드” 역할을 하며, 온톨로지를 통해 지식 공유, 재사용, 도메인 가정의 명시화, 도메인 지식과 운영 로직의 분리를 어떻게 실무에서 구현할 수 있는지 보여 준다.
2025년 11월 지금, 만일 당신이 Agentic AI를 실제 개발하거나 연구하고 있다면, 실무적으로 만족스럽지 못한 성능에 대한 해답의 실마리를 찾을 수 있기를 바란다.
1. 왜 온톨로지를 개발하는가?
최근 들어 온톨로지—즉, 특정 도메인의 용어들과 그들 사이의 관계를 명확하고 형식적인 방식으로 정의한 지식 구조(Gruber, 1993)—의 개발은 더 이상 인공지능 연구실에만 머물지 않고, 다양한 도메인 전문가들이 직접 사용하는 실무 도구로 확산되고 있다. 오늘날 웹에서도 온톨로지는 매우 흔하게 사용된다. 웹의 온톨로지는 매우 다양한 형태를 띤다. 예를 들어 Yahoo!는 웹사이트를 분류하기 위한 대규모 분류체계를 사용하고, Amazon.com은 상품과 그 특성을 체계적으로 구조화하기 위해 온톨로지를 활용한다. W3C(World Wide Web Consortium)는 전자(electric) 에이전트가 웹페이지 안의 정보를 이해하고 처리할 수 있도록 지식을 표현하는 언어인 RDF(Resource Description Framework, Brickley & Guha 1999)를 개발하고 있다.
DARPA 역시 W3C와 협력하여 RDF를 확장한 DAML(DARPA Agent Markup Language)을 개발하고 있는데(Hendler & McGuinness 2000), 이는 웹상의 에이전트들이 보다 풍부한 방식으로 상호작용할 수 있도록 설계된 언어이다. 여러 전문 분야에서는 이제 도메인 지식을 공유하고 주석을 달기 위한 표준 온톨로지를 제작하고 있다. 예를 들어 의학 분야에서는 SNOMED(Price & Spackman 2000)와 UMLS의 의미 네트워크(Humphreys & Lindberg 1993)와 같은 대규모 표준 어휘체계를 만들어 사용한다. 보다 일반적인 범용 온톨로지도 등장하고 있다. 예를 들어 UNDP와 Dun & Bradstreet는 상품과 서비스를 표현하기 위한 용어체계인 UNSPSC 온톨로지를 공동 개발했다.
온톨로지는 특정 도메인에서 연구자나 시스템이 정보를 공유할 수 있도록 공통된 어휘를 정의한다. 여기에는 도메인의 주요 개념들과 이들 사이의 관계가 기계가 해석 가능한 방식으로 포함된다. 그렇다면 왜 온톨로지를 개발해야 하는가? 주요 이유는 다음과 같다.
사람이나 소프트웨어 에이전트 간, 정보를 동일한 구조로 이해하기 위함
To share common understanding of the structure of information among people or software agents
도메인 지식을 재사용하기 위함
To enable reuse of domain knowledge
도메인에 대한 가정을 명확히 드러내기 위함
To make domain assumptions explicit
도메인 지식과 운영 로직을 분리하기 위함
To separate domain knowledge from the operational knowledge
도메인 지식을 분석하기 위함
To analyze domain knowledge
정보 구조에 대한 공통된 이해를 사람들 또는 소프트웨어 에이전트 사이에서 공유하는 것은 온톨로지를 개발할 때 가장 흔한 목표 중 하나이다(Musen 1992; Gruber 1993). 예를 들어 여러 웹사이트가 의료 정보를 제공하거나 의료 관련 전자상거래 서비스를 제공한다고 가정해 보자. 만약 이 웹사이트들이 각각 사용하는 용어들에 대해 동일한 기반 온톨로지를 공유하고 이를 공개한다면, 컴퓨터 에이전트는 이들 서로 다른 사이트에서 정보를 추출하고 통합할 수 있다. 그리고 이러한 에이전트들은 통합된 정보를 이용하여 사용자 질의를 처리하거나 다른 애플리케이션의 입력 데이터로 활용할 수 있다.
일반인이 말하는 “감기약” 에 대해, 의사는 “상기도 감염 치료제(URI treatment)”나 “항바이러스제(oseltamivir)” 처럼 전문 용어를 사용하며, 약국에는 “APAP(acetaminophen), “타미플루" 같은 성분이나 상표 중심 표현을 쓴다. 온톨로지가 없으면 AI는 “감기약”, “URI 치료제”, "타미플루" 가 모두 같은 치료 범주를 의미한다는 것을 스스로 알기 어렵다. 하지만 온톨로지가 감기약이라는 개념 아래에 약물 종류, 성분, 작용 등을 구조적으로 연결해두면, AI는 서로 다른 표현을 모두 동일한 의미로 묶어 정확한 정보 검색과 응답을 수행할 수 있게 된다.
건설 현장도 마찬가지다. 우리가 흔히 얘기하는 같은 "철근" 을 두고도 사람마다 표현이 다르다. 현장 작업자는 그냥 “리바”이라고 부르고, 기술감리나 설계자는 “콘크리트용 이형봉강(SD400)” 같은 규격 명칭을 쓰며, 시공담당자는 “주근·배근 다웰바”처럼 역할 중심 용어를 사용한다. 온톨로지가 없으면 AI는 “철근”, “이형봉강”, “SD400”, “주근”이 모두 같은 개념을 가리킨다는 사실을 스스로 알기 어렵다. 하지만 온톨로지가 철근이라는 개념 아래에 규격, 역할, 시공 요소를 구조적으로 연결해두면, AI는 서로 다른 표현을 모두 동일한 의미로 묶어 정확한 분석과 답변을 제공할 수 있게 된다.
도메인 지식을 재사용할 수 있도록 하는 것은 최근 온톨로지 연구의 급격한 증가를 이끈 주요 동력 중 하나였다. 예를 들어 많은 도메인의 모델들은 ‘시간’이라는 개념을 표현해야 한다. 이러한 표현에는 시간 구간, 특정 시점, 상대적 시간 측정 등과 같은 개념들이 포함된다. 만약 어떤 연구 그룹이 이런 온톨로지를 상세하게 개발해 놓으면, 다른 연구자들은 이를 자신들의 도메인에 그대로 재사용할 수 있다. 또한 큰 규모의 온톨로지를 구축해야 하는 경우에는, 그 큰 도메인의 일부를 기술하는 여러 기존 온톨로지를 통합할 수도 있다. 그리고 UNSPSC 온톨로지와 같은 범용 온톨로지를 재사용하고 이를 확장하여 우리가 관심 있는 특정 도메인을 기술할 수도 있다.
구현의 기반이 되는 도메인 가정을 명시적으로 드러내면, 도메인에 대한 우리의 지식이 변할 때 이러한 가정을 쉽게 변경할 수 있다. 반대로 프로그래밍 언어 코드에 세계에 대한 가정을 하드코딩해 버리면, 이러한 가정은 찾기도 어렵고 이해하기도 어렵고, 특히 프로그래밍 전문지식이 없는 사람에게는 변경하기도 어려워진다. 또한 도메인 지식을 명시적으로 기술해 두는 것은 도메인의 용어가 무엇을 의미하는지 배워야 하는 신규 사용자에게도 도움이 된다.
도메인 지식을 운영 지식(operational knowledge)과 분리하는 것 역시 온톨로지의 흔한 활용 방식이다. 예를 들어 어떤 제품을 요구되는 사양에 맞추어 구성하는 작업을 그 구성 요소들을 기반으로 기술할 수 있으며, 제품이나 구성요소 자체와는 독립적으로 이 구성을 수행하는 프로그램을 구현할 수 있다(McGuinness and Wright 1998). 그런 다음 PC 부품과 특성에 대한 온톨로지를 개발하고 그 알고리즘을 적용하여 주문형 PC를 구성할 수 있다. 동일한 알고리즘을 엘리베이터 구성에 사용하려면, 엘리베이터 구성요소 온톨로지를 알고리즘에 “입력으로 공급”하면 된다(Rothenfluh et al. 1996).
용어에 대한 선언적 명세가 제공되면 도메인 지식을 분석할 수 있다. 용어에 대한 형식적 분석은 기존 온톨로지를 재사용하려 할 때나 이를 확장하려 할 때 매우 가치가 있다(McGuinness et al. 2000).
종종 특정 도메인의 온톨로지는 그 자체가 목표가 아니다. 온톨로지를 개발하는 것은 다른 프로그램들이 사용할 데이터와 그 구조를 정의하는 것에 가깝다. 문제 해결 방법, 도메인 독립적 애플리케이션, 소프트웨어 에이전트는 온톨로지와 그로부터 구축된 지식베이스를 데이터로 사용한다. 예를 들어 이 논문에서는 와인과 음식, 그리고 특정 음식과 잘 어울리는 와인의 조합에 대한 온톨로지를 개발한다. 이 온톨로지는 레스토랑 관리 도구 모음의 일부 애플리케이션의 기반으로 사용할 수 있다. 한 애플리케이션은 하루 메뉴에 맞는 와인을 추천하거나 웨이터나 고객의 질의에 답할 수 있으며, 다른 애플리케이션은 와인 저장고의 재고 목록을 분석하여 어떤 와인 카테고리를 확대할지 또는 어떤 와인을 향후 메뉴나 요리책 구성을 위해 구매해야 할지를 제안할 수 있다.
About this guide
이 가이드는 Protégé-2000(Protege 2000), Ontolingua(Ontolingua 1997), Chimaera(Chimaera 2000)와 같은
온톨로지 편집 환경을 사용한 경험을 바탕으로 한다. 이 문서에서는 예시를 위해 Protégé-2000을 사용한다.
1) Protégé-2000
스탠퍼드에서 개발한 온톨로지 개발 도구 그래픽 인터페이스로 클래스, 슬롯(속성), 인스턴스를 쉽게 만들 수 있음 OWL, RDF(S) 등으로 내보내기(export) 가능 온톨로지 작성·편집·시각화에 가장 널리 사용되는 툴 중 하나 현재는 Protégé 최신 버전으로 계속 발전됨
2) Ontolingua
스탠퍼드 KSL에서 개발한 온톨로지 표준화·공유 플랫폼 여러 온톨로지 표현 언어를 공통 포맷으로 변환해주는 역할 (예: KIF → LOOM → CLASSIC 등 다양한 KR 언어 간 변환) 공유 가능한 온톨로지 라이브러리 제공 초창기 웹 기반 협업 온톨로지 편집 환경으로 중요한 역할
3) Chimaera
스탠퍼드에서 개발한 온톨로지 진단·병합(merge) 도구 주요 기능: 온톨로지 검증(논리 오류 진단) 중복 개념 탐지 여러 온톨로지 통합 지원 단순히 만드는 툴이 아니라 품질 검사·분석에 특화
이 가이드 전반에 걸쳐 사용되는 와인 및 음식 예시는 서술 논리 기반 지식 표현 시스템인 CLASSIC(Brachman et al. 1991)의 예제 지식베이스에 느슨하게 기반한다. CLASSIC 튜토리얼(McGuinness et al. 1994)에서는 이 예제를 더 발전시켰다. Protégé-2000과 기타 프레임 기반 시스템은 클래스 계층구조와 개별 인스턴스가 어떤 클래스에 속하는지를 명시적으로 선언하여 온톨로지를 기술한다.
이 가이드에 등장하는 일부 온톨로지 설계 아이디어는 객체지향 설계(Object-Oriented Design) 문헌(Rumbaugh et al. 1991; Booch et al. 1997)에서 유래되었다. 그러나 온톨로지 개발은 객체지향 프로그래밍에서 클래스와 관계를 설계하는 것과는 다르다.객체지향 프로그래밍은 주로 클래스의 "기능(Operational properties)” 중심으로 설계 결정을 내린다. 반면 온톨로지 설계자는 클래스의 "구조(Structural properties)"에 기반해 설계 결정을 내린다. 따라서 동일한 도메인이라 할지라도, 온톨로지의 클래스 구조와 관계는 객체지향 프로그램의 클래스 구조와는 다르게 형성된다.
객체지향 : “이 객체는 무엇을 할 수 있는가? 어떤 기능과 동작을 가져야 하는가? → 메서드 중심”
Ontology : “이 개념은 무엇이고 어떻게 연결되는가? 다른 개념과 어떤 관계에 있는가? → 구조·관계 중심”
온톨로지 개발자가 마주하게 되는 모든 문제를 이 가이드에서 다 다루는 것은 불가능하며, 그럴 의도도 없다. 대신 이 문서는 초보 온톨로지 설계자가 온톨로지를 개발할 때 참고할 출발점을 제공하려는 목적을 가진다. 문서 끝에서는 더 복잡한 구조나 설계 기법이 필요할 경우 참고할 문헌도 제시한다.
마지막으로, 온톨로지 설계 방법론에는 정답이 하나 존재하지 않는다. 이 가이드에서 제시하는 아이디어들은 저자들이 직접 온톨로지를 개발하면서 유용하다고 판단한 것들이다. 문서 마지막에는 대안적 방법론을 제시하는 참고 문헌 목록도 포함되어 있다.
2. What is in an ontology?
인공지능 분야의 문헌에는 온톨로지에 대한 다양한 정의가 있으며, 서로 모순되는 경우도 많다. 이 가이드에서는 온톨로지를 다음과 같이 정의한다. 온톨로지는 특정 도메인 영역(domain of discourse)에 존재하는 개념들(Classes 클래스, 또는 콘셉트라고도 부름), 각 개념의 다양한 특징과 속성을 설명하는 프로퍼티(Slots 슬롯, 또는 roll or properties 역할·속성이라고도 부름), 그리고 이러한 슬롯에 적용되는 제약(Facets 패싯, 혹은 역할 제한이라고도 부름)을 명시적으로 기술한 형식적 구조이다. 온톨로지에 클래스의 개별 인스턴스를 함께 포함하면 하나의 지식베이스가 된다. 실제로는 온톨로지와 지식베이스의 경계가 매우 모호한 경우가 많다.
클래스는 대부분의 온톨로지에서 중심 요소이다. 클래스는 도메인의 개념을 설명한다. 예를 들어, Wine 클래스는 모든 와인이라는 개념을 표현하며, 실제 특정 와인은 이 클래스의 인스턴스이다. 지금 이 문서를 읽는 동안 당신 앞에 놓여 있는 한 잔의 보르도 와인은 Bordeaux 클래스의 인스턴스가 된다. 한 클래스는 더 구체적인 개념을 나타내는 하위 클래스를 가질 수 있다. 예를 들어, 모든 와인 클래스를 적색, 백색, 로제 와인으로 나눌 수 있다. 또는 모든 와인을 스파클링 와인과 비(非)스파클링 와인으로 나눌 수도 있다.
슬롯은 클래스와 인스턴스의 속성을 설명한다. 예를 들어 Château Lafite Rothschild Pauillac 와인의 경우, 바디(body)가 full이고, 생산자는 Château Lafite Rothschild 와이너리라고 할 때, 우리는 이 와인을 설명하는 두 개의 슬롯 — body 슬롯(full 값)과 maker 슬롯(해당 와이너리 값) — 을 가지게 된다. 클래스 수준에서는 Wine 클래스의 모든 인스턴스가 flavor, body, sugar level, maker 등의 슬롯을 갖는다고 정의할 수 있다.
Wine 및 그 하위 클래스인 Pauillac의 모든 인스턴스는 maker 슬롯을 가지며, 이 값은 Winery 클래스의 인스턴스가 된다. 반대로 Winery 클래스의 모든 인스턴스는 produces 슬롯을 가지고 있으며, 이는 해당 와이너리가 생산하는 모든 와인(Wine 및 그 하위 클래스의 인스턴스)을 가리킨다.
온톨로지를 개발한다는 것은 실제로 다음 활동을 의미한다.
• 온톨로지에 포함될 클래스들을 정의하고,
• 이 클래스들을 서브 클래스–슈퍼 클래스 계층 구조에 배치하며,
• 클래스의 속성을 표현하는 슬롯을 정의하고 가능한 값들을 제한하며,
• 마지막으로 인스턴스를 생성하여 슬롯 값을 채운다.
이렇게 만들어진 클래스와 인스턴스들은 지식베이스를 구성하게 된다.
3. A Simple Knowledge-Engineering Methodology
간단한 지식 공학 방법론
앞에서 말했듯이, 온톨로지를 개발하는 “유일하게 정답인” 방법이나, 방법론은 존재하지 않는다. 여기에서는 온톨로지를 개발할 때 고려해야 할 일반적인 이슈들을 논의하고, 가능한 하나의 절차를 제시한다. 우리는 온톨로지 개발을 반복적(iterative)인 접근으로 설명한다. 먼저 온톨로지에 대해 거친 1차 초안을 만들고, 이후 온톨로지가 진화해 가는 과정에서 이를 계속 수정·정제하면서 세부 내용을 채워 넣는다. 이 과정을 설명하는 동안, 설계자가 내려야 할 모델링 결정들, 그리고 여러 대안적 해법의 장단점과 그 의미도 함께 논의할 것이다. 먼저, 이후 여러 번 참조하게 될 온톨로지 설계의 몇 가지 기본 규칙을 강조하고자 한다. 이 규칙들은 다소 독단적으로 보일 수 있다. 하지만 실제로는 많은 상황에서 설계 결정을 내리는 데 큰 도움이 된다.
1) 어떤 도메인을 모델링하는 “유일하게 옳은” 방법은 없다 —항상 여러 가지 실행 가능한 대안이 존재한다.가장 좋은 해법은 거의 항상, 당신이 염두에 두고 있는 애플리케이션과 앞으로 예상되는 확장 방향에 따라 달라진다.
2) 온톨로지 개발은 본질적으로 반복적인 과정이다.
3) 온톨로지에 포함되는 개념들은, 관심 도메인 내의 객체(물리적 객체이든 논리적 객체이든)와 그들 사이의 관계에 가깝게 정의되어야 한다.이들은 해당 도메인을 설명하는 문장에서 주로 명사(객체)와 동사(관계)로 등장하는 것들이다.
즉, 온톨로지를 무엇에 사용할 것인지, 그리고 온톨로지를 얼마나 세부적으로 혹은 얼마나 일반적으로 만들 것인지에 대한 결정이 이후의 수많은 모델링 결정들을 이끌게 된다. 여러 개의 타당한 대안이 있을 때, 우리는 예상되는 작업에 더 잘 맞고, 더 직관적이며, 더 확장 가능하고, 유지보수하기 쉬운 쪽을 선택해야 한다. 또한 온톨로지는 세상의 현실을 모델링한 것이며, 온톨로지의 개념들은 이 현실을 반영해야 한다는 점을 기억해야 한다. 온톨로지의 초기 버전을 정의한 뒤에는, 이를 실제 애플리케이션이나 문제 해결 방법에서 사용해 보거나, 해당 분야 전문가들과 논의해 봄으로써 평가하고 디버깅할 수 있다. 그 결과, 초기 온톨로지는 거의 확실하게 수정이 필요해질 것이다. 이러한 반복 설계 과정은 온톨로지의 전체 수명 주기 동안 계속될 가능성이 높다.
"온톨로지는 디지털 트윈의 기반이 될 수 있다"
[공통점]
현실(world)을 디지털로 모델링한다
표준화와 일관성이 중요하다 (온톨로지는 개념·관계의 표준화, 디지털 트윈은 데이터·모델의 표준화)
현실이 변하면, 개념도 모델도 바뀌어야 한다.
[차이점]
온톨로지 = 세상을 이해하는 구조(meaning model)
개념과 관계를 정의하고 이해하기 위한 지식 구조
정의·구조 중심, 실시간 업데이트가 핵심이 아님
디지털 트윈 = 세상을 작동시키는 모델(behavioral model)
실제 시스템을 모니터링·예측·제어하기 위한 동적 모델
동적(Dynamic) → IoT·센서·실시간 데이터가 반드시 연결됨
Step 1. Determine the domain and scope of the ontology
온톨로지의 도메인과 범위를 결정한다
온톨로지 개발은, 해당 온톨로지의 도메인과 범위를 정의하는 것에서 시작할 것을 권장한다. 즉, 다음과 같은 기본적인 질문들에 답해 보아야 한다.
• 이 온톨로지가 다루게 될 도메인은 무엇인가?
• 우리는 이 온톨로지를 무엇에 사용할 것인가?
• 이 온톨로지에 담긴 정보는 어떤 유형의 질문에 답을 줄 수 있어야 하는가?
• 누가 이 온톨로지를 사용하고, 누가 유지관리할 것인가?
이 질문들에 대한 답은 온톨로지 설계 과정 중에 바뀔 수 있다. 그러나 어느 시점에서든, 이런 답들은 모델의 범위를 제한하는 데 도움을 준다. 앞에서 소개했던 와인과 음식에 대한 온톨로지를 생각해 보자. 음식과 와인을 표현하는 것이 이 온톨로지의 도메인이다. 우리는 이 온톨로지를 와인과 음식의 좋은 조합을 추천하는 애플리케이션에서 사용할 계획이다.
자연스럽게, 서로 다른 종류의 와인을 설명하는 개념들, 주요 음식 유형들, 와인과 음식의 좋은 조합과 나쁜 조합을 나타내는 개념들이 온톨로지에 포함될 것이다. 반면, 와이너리의 재고를 관리하거나 레스토랑 직원들을 관리하는 개념들은, 비록 와인과 음식이라는 주제와 어느 정도 관련이 있긴 하지만, 이 온톨로지에는 포함되지 않을 가능성이 크다.
만약 우리가 설계하는 온톨로지가 와인 잡지의 기사에 대한 자연어 처리를 돕기 위해 사용된다면, 온톨로지의 개념들에 대해 동의어(synonym)나 품사(part-of-speech) 정보 등을 포함하는 것이 중요해질 수 있다. 반면, 레스토랑 고객이 어떤 와인을 주문할지 결정하는 데 도움을 주기 위해 온톨로지를 사용한다면, 소매 가격(retail price) 정보가 필요할 것이다. 와인 바이어들이 와인 셀러를 채우기 위한 구매 의사결정을 돕기 위한 목적이라면, 도매 가격(wholesale price)과 재고 가능 여부(availability)가 중요해질 수 있다. 온톨로지를 유지관리하는 사람들이 온톨로지 사용자와 다른 언어로 도메인을 설명한다면, 그 언어들 사이의 매핑(mapping)을 제공해야 할 수도 있다.
Competency questions. 역량 질문
온톨로지가 이러한 유형의 질문들에 답하기에 충분한 정보를 포함하고 있는가?
온톨로지의 범위를 정하는 한 가지 방법은, 해당 온톨로지를 기반으로 하는 지식베이스가 답할 수 있어야 할 질문들의 목록을
대략적으로 그려보는 것이다. 이를 역량 질문(competency questions)이라고 부른다(Gruninger and Fox 1995). 이 질문들은 나중에 리트머스 시험지 역할을 한다. 즉, 온톨로지가 이러한 유형의 질문들에 답하기에 충분한 정보를 포함하고 있는가? 해당 질문에 답하기 위해서는 특정 수준의 세부 표현이나 특정 영역에 대한 표현이 필요한가? 이 역량 질문들은 어디까지나 초안일 뿐이며, 완전할 필요는 없다.
와인과 음식 도메인에서 생각해볼 수 있는 역량 질문의 예시는 다음과 같다.
• 와인을 고를 때 고려해야 할 와인의 특성은 무엇인가?
• Bordeaux는 레드 와인인가, 화이트 와인인가?
• Cabernet Sauvignon은 해산물과 잘 어울리는가?
• 구운 고기 요리에 가장 잘 맞는 와인은 무엇인가?
• 어떤 와인의 특성이 특정 요리와의 궁합에 영향을 미치는가?
• 특정 와인의 부케(bouquet)나 바디(body)는 빈티지(vintage) 연도에 따라 변하는가?
• Napa Zinfandel의 좋은 빈티지는 언제였는가?
이 질문 목록으로부터, 온톨로지는 다양한 와인 특성, 와인 종류, 그리고 좋은/나쁜 빈티지 연도에 대한 정보, 그리고 적절한 와인 선택에 영향을 미치는 음식 분류, 와인–음식 추천 조합에 대한 정보를 포함해야 한다는 것을 알 수 있다.
Step 2. Consider reusing existing ontologies
기존 온톨로지의 재사용을 고려한다
거의 항상, 다른 사람이 이미 해놓은 작업을 검토하고, 그 중에서 우리 도메인과 작업에 맞게 다듬거나 확장할 수 있는 것이 있는지 살펴볼 가치가 있다. 특히, 우리 시스템이 이미 특정 온톨로지나 통제 어휘(controlled vocabulary)에 의존하고 있는 다른 애플리케이션과 상호 작용해야 한다면, 기존 온톨로지를 재사용하는 것은 거의 필수 요건일 수 있다.
이미 전자 형태로 제공되는 온톨로지가 많이 있으며, 우리가 사용하는 온톨로지 개발 환경으로 가져와(import) 사용할 수 있다. 온톨로지가 표현된 형식(formalism)은 종종 크게 중요하지 않다. 많은 지식 표현 시스템이 서로 간에 온톨로지를 가져오고 내보낼 수 있기 때문이다. 심지어 어떤 시스템이 특정 형식의 온톨로지를 직접 다룰 수 없더라도, 한 형식에서 다른 형식으로 온톨로지를 변환하는 작업은 보통 크게 어렵지 않다.
웹과 문헌에는 재사용 가능한 온톨로지 라이브러리가 존재한다. 예를 들어, Ontolingua 온톨로지 라이브러리(http://www.ksl.stanford.edu/software/ontolingua/)나 DAML 온톨로지 라이브러리(http://www.daml.org/ontologies/)를 사용할 수 있다. 또한 공개된 상용 온톨로지들도 존재한다(예: UNSPSC (www.unspsc.org), RosettaNet (www.rosettanet.org), DMOZ (www.dmoz.org)).예를 들어, 프랑스 와인에 대한 지식베이스가 이미 존재할 수 있다. 우리가 이 지식베이스와 그 기반이 되는 온톨로지를 가져올 수 있다면, 프랑스 와인의 분류뿐 아니라, 와인을 구분하고 설명하는 데 사용되는 와인 특성에 대한 1차 분류 또한 확보하게 된다. 와인 속성 목록은 이미 www.wines.com 같은 상업용 웹사이트에서, 고객들이 와인을 구매할 때 참고할 수 있도록 제공되고 있을 수도 있다. 그러나 이 가이드에서는, 관련된 온톨로지가 이미 존재하지 않는다고 가정하고, 온톨로지를 처음부터 개발하는 경우를 다루겠다.
1. RDF (Resource Description Framework) — “사물 간 관계를 문장처럼 표현하는 언어”
- RDF는 주어–술어–목적어(Subject–Predicate–Object) 형태로 정보를 표현한다.
- 예: “타미플루는 약이다” → (타미플루, is-a, 약) “현장 A는 SD400 철근을 사용한다” → (현장A, uses, SD400)
- 데이터의 의미와 관계를 표현하는 가장 기본 언어로, 온톨로지의 기초 벽돌 역할을 한다.
2. RDFS (RDF Schema) — “RDF에 최소한의 구조를 부여하는 언어”
- RDF가 단순 관계를 표현한다면, RDFS는 여기에 클래스, 계층, 속성 구조를 정의하도록 돕는다.
- 예: 약은 의약품의 하위 개념이다. maker라는 속성은 “와이너리 → 와인”을 연결한다.
- 즉, “어떤 것이 더 일반적이고, 어떤 것이 구체적인지”를 정의한다.
3. OWL (Web Ontology Language) — “더 똑똑하고 정교한 온톨로지를 만드는 언어”
- RDFS보다 훨씬 강력한 논리 규칙, 제약, 추론이 가능하다.
- 예: “모든 SD400은 ‘철근’의 하위 클래스이며, 항복강도는 400MPa다.”
“A라는 약은 성분 B를 반드시 최소 1개 포함해야 한다.”
- AI가 논리적으로 추론하고 판단하도록 하는 온톨로지의 핵심 언어다.
4. SPARQL — “온톨로지를 검색하고 질의하는 SQL 같은 언어”
- RDF로 만든 데이터베이스에서 원하는 정보를 질의(Query)할 때 사용한다.
- SQL이 RDBMS를 검색하듯, SPARQL은 지식 그래프(Knowledge Graph)를 검색한다.
- 예: “SD400 철근을 사용하는 모든 프로젝트를 찾아줘.” “타미플루와 동일 성분(oseltamivir)을 가진 약 목록을 알려줘.” - 온톨로지가 쌓인 지식을 실제로 ‘활용’하는 단계에서 필수적인 언어이다.
Step 3. Enumerate important terms in the ontology
온톨로지에 포함될 중요한 용어를 나열한다
온톨로지에서 우리가 진술을 하거나 사용자에게 설명하고 싶은 모든 용어 목록을 적어보는 것이 유용하다.
우리가 이야기하고자 하는 용어들은 무엇인가?
그 용어들은 어떤 속성을 가지고 있는가?
우리는 그 용어들에 대해 무엇을 말하고 싶은가?
예를 들어, 와인 관련해서 중요한 용어에는 와인(wine), 포도품종(grape), 저장고(winery), 위치(location), 와인의 색(color), 바디(body), 향미(flavor), 당도(sugar content), 그리고 음식의 종류(예: fish, red meat), 와인의 하위 유형(예: white wine) 등이 포함될 것이다. 초기에는, 이 용어들이 표현하는 개념들 사이에 겹침이 있는지, 용어들 간의 관계가 무엇인지, 각 개념이 어떤 속성을 가지는지, 또는 그 개념이 클래스인지 슬롯인지 등을 걱정하지 않고, 일단 최대한 포괄적인 용어 목록을 만드는 것이 중요하다.
다음 두 단계 — 클래스 계층을 개발하는 것과 개념의 속성(슬롯)을 정의하는 것 — 은 서로 밀접하게 얽혀 있다. 둘 중 하나를 완전히 끝낸 뒤에 다른 하나를 하는 것은 거의 불가능에 가깝다. 일반적으로 우리는 먼저 몇 개의 개념 정의와 계층 구조를 만든 다음, 그 개념들의 속성을 정의하는 식으로 번갈아 진행한다. 이 두 단계는 온톨로지 설계 과정에서 가장 중요한 단계이기도 하다. 여기에서는 먼저 간단히 설명하고, 다음 두 섹션에서 고려해야 할 더 복잡한 이슈들 — 흔한 함정, 내려야 할 결정들 등 — 을 자세히 논의할 것이다.
Step 4. Define the classes and the class hierarchy
클래스와 클래스 계층 구조를 정의한다
클래스 계층을 개발하는 데에는 여러 가지 접근법이 있다(Uschold and Gruninger 1996).
• 상향식(Top-down) 개발 과정은 도메인에서 가장 일반적인 개념부터 정의하고, 이후 점점 세분화하는 방식이다.
예를 들어, 먼저 Wine과 Food라는 상위 개념의 클래스를 만든다. 그리고 Wine의 하위 클래스로 White wine, Red wine, Rosé wine 등을 만든다. Red wine 클래스는 다시 Syrah, Red Burgundy, Cabernet Sauvignon 등 세분화할 수 있다.
• 하향식(Bottom-up) 개발 과정은 가장 구체적인 클래스들, 즉 계층 구조의 잎(leaf)에 위치한 클래스들부터 정의하고,
이후 이들을 점차 더 일반적인 개념으로 묶어가는 방식이다. 예를 들어, 먼저 Pauillac과 Margaux 와인에 대한 클래스를 정의한다. 그런 다음 이 둘의 공통 상위 클래스로 Medoc을 만들고, 다시 Medoc을 Bordeaux의 하위 클래스로 둘 수 있다.
• 혼합(Combination) 개발 과정은 상향식과 하향식 방식을 결합한 것이다. 먼저 눈에 띄는 주요 개념들을 정의한 뒤,
이를 적절히 일반화하거나 세분화하는 방식이다. 예를 들어, 상위 개념 몇 개(Wine 등)와 특정한 구체 개념(Margaux 등)부터 시작한 다음, 이들을 중간 수준의 개념(Medoc 등)에 연결할 수 있다. 이후 프랑스의 지역별 와인 클래스들을 모두 생성하면서 여러 중간 수준 개념들을 만들어 나갈 수 있다.
Figure 2는 서로 다른 일반성 수준에 따른 가능한 분해 구조를 보여준다.
이 세 가지 방법 중 어느 것도 본질적으로 더 우월하지 않다. 어떤 접근을 택할지는 도메인에 대한 설계자의 관점에 크게 의존한다. 만약 설계자가 도메인에 대해 체계적인 상향식(top-down) 관점을 가지고 있다면, 상향식 접근이 더 쉽고 자연스러울 수 있다. 많은 온톨로지 설계자에게는 혼합 접근법이 가장 쓰기 편한 방식인데, 그 이유는 “중간 수준” 개념들이 도메인에서 가장 설명적(descriptive)인 경우가 많기 때문이다(Rosch 1978).
와인을 떠올릴 때 가장 일반적인 분류 기준부터 먼저 생각하는 편이라면 상향식(top-down) 접근이 더 잘 맞을 것이다. 반대로, 구체적인 예시들부터 바닥을 다지고 싶다면 하향식(bottom-up) 접근이 더 적합할 수 있다.
어떤 접근을 선택하든, 우리는 보통 클래스를 정의하는 일부터 시작한다. 3단계에서 만든 용어 목록 중에서, 어떤 대상이 “독립적으로 존재하는 객체”를 가리키는지, 그리고 어떤 용어는 이 객체들을 설명하는지 구분한다. 독립적인 객체를 가리키는 용어들이 온톨로지의 클래스가 되어 클래스 계층의 “앵커(anchor)”가 된다. 우리는 다음 질문을 반복해서 던지면서 클래스들을 계층적인 분류체계로 조직한다.
만약 클래스 A가 클래스 B의 상위 클래스(superclass)라면, B의 모든 인스턴스는 A의 인스턴스이기도 하다.
다시 말해, 클래스 B는 A라는 개념의 “한 종류(kind of)”를 표현한다. 예를 들어, 모든 Pinot Noir 와인은 반드시 레드 와인이다. 따라서 Pinot Noir 클래스는 Red Wine 클래스의 하위 클래스(subclass)이다.
Figure 2는 Wine 온톨로지의 클래스 계층 일부를 보여준다. 4장은 클래스 계층을 정의할 때 살펴볼 점들에 대해 상세히 논의한다.
Step 5. Define the properties of classes—slots
클래스의 속성, 즉 슬롯을 정의한다
클래스만으로는 1단계에서의 역량 질문(competency questions)에 답하기에 충분한 정보를 제공하지 못한다.
* 역량 질문(competency questions; 해당 온톨로지를 기반으로 하는 지식베이스가 답할 수 있어야 할 질문들의 목록)
일단 몇몇 클래스를 정의하고 나면, 우리는 개념의 내부 구조를 설명해야 한다.
우리는 이미 3단계에서 만든 용어 목록에서 클래스를 선택했다. 남아 있는 대부분의 용어들은 이러한 클래스들의 속성이 될 가능성이 있다. 이러한 용어에는 예를 들어 와인의 색, 바디, 풍미와 당도, 그리고 와이너리의 위치가 포함된다. 목록에 있는 각 속성에 대해, 그것이 어떤 클래스를 설명하는지 결정해야 한다. 이러한 속성들은 클래스에 연결된 슬롯이 된다. 따라서 Wine 클래스는 color, body, flavor, 그리고 sugar 슬롯을 갖게 된다. 그리고 Winery 클래스는 location 슬롯을 갖게 된다.
일반적으로 온톨로지에서 슬롯이 될 수 있는 객체 속성에는 여러 유형이 있다:
- 와인의 풍미처럼 “내재적(intrinsic)” 속성;
- 와인의 이름이나 산지처럼 “외재적(extrinsic)” 속성;
- 객체가 구조화되어 있다면 그 객체를 구성하는 “부분(parts)”
(물리적이거나 추상적일 수 있음, 예: 식사의 코스); - 다른 개체들과의 관계; 이는 클래스의 개체와 다른 항목 간의 관계를 의미한다
(예: 와인과 와이너리 간의 관계를 나타내는 maker, 와인을 만드는 포도 품종).
따라서 앞서 확인한 속성들에 더해, 우리는 Wine 클래스에 다음 슬롯들을 추가해야 한다: name, area, maker, grape.
그림 3은 Wine 클래스에 대한 슬롯들을 보여준다. 어떤 클래스의 모든 서브클래스는 그 클래스의 슬롯을 상속한다. 예를 들어 Wine 클래스의 모든 슬롯은 Red Wine과 White Wine을 포함한 Wine의 모든 서브클래스에 상속될 것이다. 우리는 Red Wine 클래스에 추가 슬롯인 tannin level(low, moderate, 또는 high)을 추가할 것이다. tannin level 슬롯은 Bordeaux와 Beaujolais와 같이 레드 와인을 나타내는 모든 클래스에 상속될 것이다. 슬롯은 해당 속성을 가질 수 있는 가장 일반적인 클래스에 연결되어야 한다. 예를 들어, 와인의 body와 color는 이 속성을 가진 인스턴스들에 대해 가장 일반적인 클래스인 Wine 클래스에 연결되어야 한다.
Step 6. Define the facets of the slots
슬롯의 패싯(facets)을 정의한다
슬롯은 값의 타입, 허용되는 값들, 값의 개수(카디널리티), 그리고 슬롯이 가질 수 있는 값들의 특징을 설명하는 다양한 패싯(facet)을 가질 수 있다. 예를 들어 name 슬롯의 값(“와인의 이름”과 같은 경우)은 하나의 문자열이다. 즉, name은 값 유형이 String인 슬롯이다. produces 슬롯(“와이너리가 이 와인들을 생산한다”는 의미)은 여러 값을 가질 수 있으며 그 값들은 Wine 클래스의 인스턴스이다. 즉, produces는 값 유형이 Instance이며 Wine이 허용 클래스이다. 이제 몇 가지 일반적인 패싯을 설명한다.
슬롯 카디널리티 Slot cardinality
슬롯 카디널리티는 슬롯이 가질 수 있는 값의 개수를 정의한다. 어떤 시스템은 단일 카디널리티(최대 한 개의 값 허용)와 복수 카디널리티(값의 개수에 제한 없음)만 구분한다. 와인의 body는 단일 카디널리티 슬롯이 될 것이다(와인은 오직 하나의 body만 가질 수 있다). 특정 와이너리가 생산한 와인들은 Winery 클래스의 produces라는 복수 카디널리티 슬롯을 채운다.
어떤 시스템은 최소 및 최대 카디널리티를 지정하여 슬롯 값의 개수를 보다 정확하게 설명할 수 있게 한다. 최소 카디널리티 N은 슬롯이 최소한 N개의 값을 가져야 함을 의미한다. 예를 들어 Wine의 grape 슬롯은 최소 카디널리티가 1이다. 즉, 각 와인은 적어도 하나의 포도 품종으로 만들어진다. 최대 카디널리티 M은 슬롯이 최대 M개의 값을 가질 수 있음을 의미한다. 단일 품종 와인의 경우 grape 슬롯의 최대 카디널리티는 1이다 : 이러한 와인은 단 하나의 포도 품종으로 만들어진다. 때때로 최대 카디널리티를 0으로 설정하는 것이 유용할 수 있다. 이 설정은 특정 서브클래스에 대해 해당 슬롯이 어떤 값도 가져서는 안 됨을 의미한다.
슬롯 값 유형 Slot-value type
값 유형 패싯은 슬롯에 어떤 유형의 값이 들어갈 수 있는지를 설명한다. 다음은 보다 일반적인 값 유형 목록이다.
- String은 가장 단순한 값 유형으로 name과 같은 슬롯에 사용되며 값은 단순한 문자열이다.
- Number(때로는 Float과 Integer 같은 더 구체적인 유형이 사용됨)는 숫자 값을 가진 슬롯을 설명한다. 예를 들어 와인의 가격은 Float 값 유형을 가질 수 있다.
- Boolean 슬롯은 단순한 yes–no 플래그이다. 예를 들어 스파클링 와인을 별도의 클래스로 표현하지 않기로 한 경우, 와인이 스파클링인지 여부는 Boolean 슬롯으로 표현할 수 있다. 값이 “true”(“yes”)이면 그 와인은 스파클링이며, 값이 “false”(“no”)이면 스파클링이 아니다.
- Enumerated 슬롯은 특정 허용 값 목록을 지정한다. 예를 들어 flavor 슬롯은 strong, moderate, delicate 세 가지 값 중 하나를 가질 수 있다고 지정할 수 있다. Protégé-2000에서 enumerated 슬롯은 Symbol 유형이다.
- Instance 유형 슬롯은 개별 개체들 간의 관계 정의를 가능하게 한다. 값 유형이 Instance인 슬롯은 또한 인스턴스가 속할 수 있는 허용 클래스 목록을 정의해야 한다. 예를 들어 Winery 클래스의 produces 슬롯은 Wine 클래스의 인스턴스를 값으로 가질 수 있다.
Domain and range of a slot
슬롯의 도메인과 레인지 Instance 유형 슬롯의 허용 클래스는 종종 슬롯의 레인지라고 불린다. Figure 4는 Winery 클래스에서 produces 슬롯이 어떻게 정의되는지 보여준다. 어떤 시스템은 특정 클래스에 슬롯이 연결될 때 슬롯의 레인지를 제한할 수 있도록 한다. 슬롯이 연결된 클래스 또는 슬롯이 속성을 설명하는 클래스는 슬롯의 도메인이라고 불린다. Winery 클래스는 produces 슬롯의 도메인이다. 슬롯을 클래스에 연결하는 시스템에서는 슬롯이 연결된 클래스가 보통 그 슬롯의 도메인이 되며 도메인을 별도로 지정할 필요가 없다. 슬롯의 도메인과 레인지를 결정하는 기본 규칙은 유사하다.
슬롯의 도메인이나 레인지를 정의할 때, 각각 슬롯의 도메인 또는 레인지가 될 수 있는 가장 일반적인 클래스나 클래스들을 찾아라. 반면 도메인과 레인지를 지나치게 일반적으로 정의하지 말라. 슬롯의 도메인에 있는 모든 클래스는 해당 슬롯으로 설명될 수 있어야 하고, 슬롯의 레인지에 있는 모든 클래스의 인스턴스는 슬롯을 채울 수 있는 잠재적 값이어야 한다. 레인지로 지나치게 일반적인 클래스(예: THING)를 선택해서는 안 되지만, 모든 값을 포함할 수 있는 적절한 클래스를 선택해야 한다.
produces 슬롯의 레인지를 정의할 때 Wine 클래스의 모든 서브클래스를 열거하는 대신 Wine만 나열하면 된다. 동시에 슬롯의 레인지를 온톨로지에서 가장 일반적인 클래스인 THING으로 지정해서는 안 된다. 더 구체적으로 말하면,
슬롯의 도메인이나 레인지를 정의하는 클래스 목록에 어떤 클래스와 그 서브클래스가 모두 포함되어 있다면 서브클래스를 제거하라.
예를 들어 슬롯의 레인지에 Wine 클래스와 Red Wine 클래스가 모두 포함되어 있다면 Red Wine을 제거할 수 있다. 이는 새로운 정보를 추가하지 않기 때문이다. Red Wine은 Wine의 서브클래스이며 따라서 레인지는 이미 Wine의 모든 서브클래스를 암묵적으로 포함하고 있다.
슬롯의 도메인이나 레인지 정의 클래스 목록에 클래스 A의 모든 서브클래스는 포함되어 있지만 A 자체는 포함되어 있지 않다면, 레인지는 서브클래스가 아니라 클래스 A만 포함해야 한다.
예를 들어 레인지를 Red Wine, White Wine, Rose Wine으로 정의하는 대신 Wine 하나로 제한할 수 있다. 슬롯의 도메인이나 레인지 정의 클래스 목록에 클래스 A의 거의 모든 서브클래스가 포함되어 있고 몇 개만 빠져 있다면, 클래스 A를 더 적절한 레인지 정의로 고려해야 한다. 슬롯을 클래스에 연결하는 것이 슬롯 도메인에 클래스를 추가하는 것과 동일한 시스템에서는 슬롯 연결에도 동일한 규칙이 적용된다. 한편으로는 가능한 한 일반적으로 만들어야 한다. 다른 한편으로는 슬롯을 연결하는 각 클래스가 실제로 그 슬롯이 나타내는 속성을 가질 수 있어야 한다. 우리는 tannin level 슬롯을 Bordeaux, Merlot, Beaujolais 등 레드 와인을 나타내는 각 클래스에 연결할 수 있다. 그러나 모든 레드 와인이 tannin level 특성을 가지므로 이 슬롯은 더 일반적인 Red Wines 클래스에 연결해야 한다. tannin level 슬롯의 도메인을 더 일반화하여 Wine 클래스에 연결하는 것은 적절하지 않다. 예를 들어 우리는 tannin level을 화이트 와인을 설명하는 데 사용하지 않기 때문이다.
Step 7. Create instances
7단계. 인스턴스를 생성한다
마지막 단계는 계층 구조에 정의된 클래스들의 개별 인스턴스를 만드는 것이다.
어떤 클래스의 인스턴스를 정의하려면
(1) 클래스를 선택하고,
(2) 그 클래스의 인스턴스를 하나 만들고,
(3) 슬롯 값을 채워 넣으면 된다.
예를 들어, 특정 Beaujolais 와인을 나타내기 위해
Chateau-Morgon-Beaujolais라는 인스턴스를 만들 수 있다.
Chateau-Morgon-Beaujolais는
모든 Beaujolais 와인을 나타내는 Beaujolais 클래스의 인스턴스이다.
이 인스턴스는 다음과 같은 슬롯 값을 가진다(Figure 5).
• Body: Light
• Color: Red
• Flavor: Delicate
• Tannin level: Low
• Grape: Gamay (Wine grape 클래스의 인스턴스)
• Maker: Chateau-Morgon (Winery 클래스의 인스턴스)
• Region: Beaujolais (Wine-Region 클래스의 인스턴스)
• Sugar: Dry
Figure 5. Beaujolais 클래스 인스턴스의 정의.
이 인스턴스는 Beaujolais 지역의 Chateau Morgon winery가 Gamay 포도로 생산한
Chateaux Morgon Beaujolais 와인을 나타낸다.
이 와인은 light body, delicate flavor, red color, low tannin level을 가지며,
dry 와인이다.
4. Defining classes and a class hierarchy
클래스와 클래스 계층 구조 정의하기
이 절에서는 3장의 Step 4에서 다룬,
클래스와 클래스 계층을 정의할 때 주의해야 할 점들과
쉽게犯할 수 있는 오류들을 논의한다.
앞에서 이미 언급했듯이,
어떤 도메인에 대해서도 “단 하나의 정답인 클래스 계층”은 존재하지 않는다.
클래스 계층은 온톨로지의 용도,
애플리케이션에서 필요한 세부 수준,
개인적 선호,
그리고 때로는 다른 모델들과의 호환성 요구사항 등에 따라 달라진다.
그러나 클래스 계층을 개발할 때
염두에 두면 좋은 몇 가지 가이드라인이 있다.
상당수의 클래스를 정의한 다음에는
잠시 뒤로 물러서,
현재 만들어진 계층 구조가
이들 가이드라인에 부합하는지 확인해 보는 것이 좋다.
4.1 Ensuring that the class hierarchy is correct
4.1 올바른 클래스 계층 구조인지 확인하기
“is-a” 관계
클래스 계층은 “is-a” 관계를 표현한다.
즉, 클래스 A가 클래스 B의 하위 클래스라면,
A의 모든 인스턴스는 B의 인스턴스이기도 하다.
예를 들어, Chardonnay는 White wine의 하위 클래스이다.
분류 관계를 “kind-of” 관계로 생각해 볼 수도 있다.
Chardonnay는 White wine의 한 종류이다.
Jetliner는 aircraft의 한 종류이다.
Meat은 food의 한 종류이다.
어떤 클래스의 하위 클래스는
항상 그 상위 클래스가 표현하는 개념의
“한 종류(kind of)”를 표현한다.
단일 와인은 ‘모든 와인’의 하위 클래스가 아니다
흔한 모델링 오류 중 하나는,
같은 개념의 단수 이름과 복수 이름을 모두 클래스 계층에 넣고,
단수를 복수의 하위 클래스로 만드는 것이다.
예를 들어, Wines라는 클래스를 만들고
Wine 클래스를 Wines의 하위 클래스로 만드는 것은 잘못이다.
클래스 계층을 “kind-of” 관계로 생각해 보면
이 오류는 명확하다.
하나의 Wine은 Wines의 한 종류가 아니다.
이런 실수를 피하는 가장 좋은 방법은
항상 클래스 이름에 단수형이나 복수형 중 하나만 일관되게 사용하는 것이다
(6장에서 개념 이름에 대해 더 논의한다).
계층 관계의 추이성
하위 클래스 관계는 추이적이다.
만약 B가 A의 하위 클래스이고
C가 B의 하위 클래스라면,
C는 A의 하위 클래스이다.
예를 들어, 우리는 Wine 클래스를 정의한 뒤
White wine을 Wine의 하위 클래스로 정의할 수 있다.
그리고 Chardonnay를 White wine의 하위 클래스로 정의한다.
하위 클래스 관계의 추이성에 따라,
Chardonnay 클래스는 Wine의 하위 클래스이기도 하다.
때로는 직접 하위 클래스(direct subclass)와
간접 하위 클래스(indirect subclass)를 구분하기도 한다.
직접 하위 클래스는 어떤 클래스의 “가장 가까운” 하위 클래스이다.
즉, 클래스와 그 하위 클래스 사이에
다른 클래스가 존재하지 않는 경우를 말한다.
위 예에서 Chardonnay는 White wine의 직접 하위 클래스이며,
Wine의 직접 하위 클래스는 아니다.
클래스 계층의 진화
도메인이 진화함에 따라
일관된 클래스 계층을 유지하는 일은 점점 어려워질 수 있다.
예를 들어, 오랫동안 모든 Zinfandel 와인은 레드 와인이었다.
따라서 우리는 Zinfandel을 Red wine의 하위 클래스로 정의했다.
그러나 어느 시점부터 와인 생산자들이
포도를 눌러 색을 내는 성분을 바로 제거함으로써
와인의 색을 바꾸기 시작했다.
그 결과 색이 로제(rose)인 “white zinfandel”이 등장했다.
이제 우리는 Zinfandel 클래스를
White zinfandel과 Red zinfandel 두 클래스로 나누고,
각각을 Rose wine과 Red wine의 하위 클래스로
다시 분류해야 한다.
클래스와 그 이름
클래스와 그 이름(name)을 구분하는 것은 매우 중요하다.
클래스는 도메인의 개념을 나타내며,
그 개념을 가리키는 단어 자체가 아니다.
우리가 다른 용어를 선택하면
클래스 이름은 바뀔 수 있지만,
그 클래스가 표현하는 개념 자체는
세상 속의 객관적인 현실을 가리킨다.
예를 들어, Shrimps라는 클래스를 만들었다가
이를 Prawns라는 이름으로 바꾸더라도,
그 클래스가 표현하는 개념은 변하지 않는다.
이전에 “shrimp 요리”에 맞는 와인 조합이라고 했던 것은
이제 “prawn 요리”에도 똑같이 적용된다.
좀 더 실질적인 규칙은 다음과 같다.
동일한 개념에 대한 동의어들은
서로 다른 클래스를 의미하지 않는다.
동의어는 하나의 개념이나 용어를
다른 방식으로 부르는 이름일 뿐이다.
따라서 Shrimp 클래스, Prawn 클래스, Crevette 클래스를
각각 별도로 둘 이유는 없다.
이들 중 하나의 이름(예: Shrimp 또는 Prawn)을
클래스 이름으로 사용하고,
나머지는 동의어로 다루어야 한다.
많은 시스템은 클래스에 동의어, 번역, 표시 이름 등을
연결할 수 있게 해준다.
그렇지 않은 시스템에서는
클래스 문서에 동의어 목록을 적어둘 수 있다.
클래스 사이의 순환(cycle) 피하기
클래스 계층에서 순환 구조는 피해야 한다.
클래스 A가 하위 클래스 B를 가지고 있으면서,
동시에 B가 A의 상위 클래스인 경우,
우리는 계층에 순환이 있다고 말한다.
이런 순환을 만들면
결국 A와 B가 동등한 클래스라고 선언하는 셈이 된다.
A의 모든 인스턴스는 B의 인스턴스이고,
B의 모든 인스턴스는 A의 인스턴스이기 때문이다.
실제로, B가 A의 하위 클래스라면
B의 모든 인스턴스는 A의 인스턴스여야 한다.
또한 A가 B의 하위 클래스라면
A의 모든 인스턴스는 B의 인스턴스여야 한다.
4.2 Analyzing siblings in a class hierarchy
4.2 클래스 계층에서 형제(sibling) 클래스 분석하기
클래스 계층의 형제들
계층 구조에서 형제(sibling) 클래스란
같은 클래스의 직접 하위 클래스들이다(4.1절 참고).
계층 구조에서 모든 형제 클래스들
(루트에 있는 클래스들은 제외)은
동일한 수준의 일반성을 가져야 한다.
예를 들어, White wine과 Chardonnay를
둘 다 Wine의 하위 클래스로 두어서는 안 된다.
White wine은 Chardonnay보다 더 일반적인 개념이다.
형제 클래스들은 책의 같은 수준 목차처럼,
“같은 선상”에 있는 개념들을 표현해야 한다.
이런 의미에서, 클래스 계층에 대한 요구사항은
책의 목차를 구성하는 요구사항과 비슷하다.
계층의 루트에 있는 개념들
(대개 THING과 같은 매우 일반적인 클래스의
직접 하위 클래스로 표현되는 개념들)은
도메인의 주요 분할을 나타내며,
서로 비슷한 개념일 필요는 없다.
얼마나 많은 형제가 많고, 얼마나 적으면 적은가?
한 클래스가 가져야 할 직접 하위 클래스의 개수에 대한
엄격한 규칙은 없다.
그러나 많은 잘 구성된 온톨로지에서
직접 하위 클래스의 수는 보통
2개에서 12개 사이인 경우가 많다.
따라서 다음 두 가지 가이드라인을 제시할 수 있다.
어떤 클래스가 직접 하위 클래스를
딱 하나만 가지고 있다면,
모델링에 문제가 있거나
온톨로지가 아직 완성되지 않았을 가능성이 있다.
어떤 클래스가 12개가 넘는
많은 하위 클래스를 갖고 있다면,
추가적인 중간 수준 카테고리가
필요할 가능성이 있다.
첫 번째 규칙은
글머리표 목록에 글머리표가 하나만 있는 것은
지양해야 한다는 조판 규칙과 비슷하다.
예를 들어, 대부분의 red Burgundy 와인은
Côtes d’Or 와인이라고 하자.
만약 우리가 Burgundy 와인의 이 다수 유형만 표현하고 싶다면,
Red Burgundy 클래스를 만들고
그 하위 클래스로 Cotes d’Or 하나만 두는 식이 될 수 있다(Figure 6a).
그러나 표현 상에서 red Burgundy 와인과 Côtes d’Or 와인이
본질적으로 동일하다면
(모든 red Burgundy 와인은 Côtes d’Or 와인이며,
모든 Côtes d’Or 와인은 red Burgundy 와인인 경우),
Cotes d’Or 클래스를 만드는 것은 불필요하며
표현에 새로운 정보를 더해주지 않는다.
만약 우리가 Côtes d’Or 바로 남쪽 지역에서 나오는
좀 더 저렴한 Burgundy 와인인
Côtes Chalonnaise 와인도 포함시키려 한다면,
Burgundy 클래스의 하위 클래스로
Cotes d’Or와 Cotes Chalonnaise를
둘 다 만들게 될 것이다(Figure 6b).
Figure 6. Red Burgundy 클래스의 하위 클래스들.
어떤 클래스가 하나의 하위 클래스만 가지고 있다면
보통 모델링에 문제가 있음을 시사한다.
이제 Wine 클래스의 직접 하위 클래스로
모든 와인 종류를 나열해 보자.
이 목록에는 Beaujolais, Bordeaux와 같은
좀 더 일반적인 와인 종류뿐 아니라,
Pauillac, Margaux 같은
더 구체적인 와인 종류도 포함될 것이다(Figure 6a).
이 경우 Wine 클래스는
너무 많은 직접 하위 클래스를 가지게 된다.
실제로, 온톨로지가 다양한 와인 종류를
좀 더 잘 조직된 방식으로 반영하려면,
Medoc을 Bordeaux의 하위 클래스로,
Cotes d’Or를 Burgundy의 하위 클래스로 두어야 한다.
또한 Red wine, White wine 같은
중간 수준 카테고리를 두는 것도
많은 사람들이 가지고 있는
와인 도메인의 개념적 모델을
더 잘 반영해 준다(Figure 6b).
하지만, 형제 클래스들의 긴 목록을
자연스럽게 묶어 줄 수 있는 클래스들이
존재하지 않는다면,
억지로 인위적인 중간 클래스를 만들 필요는 없다.
온톨로지는 결국 현실 세계를 반영해야 하며,
현실 세계에서 카테고리가 존재하지 않는다면
온톨로지에서도 그것을 만들 필요는 없다.
Figure 7. 와인 분류하기.
모든 와인과 와인 종류를
한 수준에 두는 경우와,
여러 수준으로 계층화하는 경우 비교.
4.3 Multiple inheritance
4.3 다중 상속
대부분의 지식 표현 시스템은
클래스 계층에서 다중 상속을 허용한다.
즉, 하나의 클래스가 여러 클래스의 하위 클래스가 될 수 있다.
예를 들어, 우리는 Dessert wine이라는
디저트 와인 클래스를 만들고 싶다고 하자.
Port wine은 레드 와인이면서 동시에
디저트 와인이기도 하다.4
따라서 Port 클래스는
Red wine과 Dessert wine 두 클래스를
모두 상위 클래스로 가진다.
Port 클래스의 모든 인스턴스는
Red wine과 Dessert wine 클래스의
인스턴스이기도 하다.
Port 클래스는 두 상위 클래스로부터
슬롯과 그 패싯들을 모두 상속받는다.
즉, Dessert wine 클래스로부터는
Sugar 슬롯 값 SWEET를 상속받고,
Red wine 클래스로부터는
tannin level 슬롯과 color 슬롯의 값을 상속받는다.
4.4 When to introduce a new class (or not)
4.4 언제 새로운 클래스를 도입할 것인가 (또는 도입하지 않을 것인가)
모델링 과정에서 가장 어려운 결정 중 하나는,
새로운 클래스를 도입할 것인지,
아니면 단순히 다른 속성 값으로
구분을 표현할 것인지 결정하는 일이다.
너무 깊게 중첩된 계층과 불필요한 클래스가 많은 구조는
이해·관리하기 어렵고,
반대로 너무 평평한 계층과
슬롯에 너무 많은 정보를 집어넣은 구조 역시
다루기 어렵다.
이 둘 사이에서 균형을 찾는 것은 쉽지 않다.
계층에 새로운 클래스를 도입할지 여부를 결정하는 데
도움이 되는 몇 가지 경험적 규칙이 있다.
어떤 클래스의 하위 클래스는 보통
(1) 상위 클래스에는 없는 추가 속성을 가지거나,
(2) 상위 클래스와 다른 제약 조건을 가지거나,
(3) 상위 클래스와 다른 관계에 참여한다.
예를 들어, Red wines는
다양한 수준의 tannin을 가질 수 있지만,
이 속성은 모든 와인을 설명하는 데
사용되는 것은 아니다.
Dessert wine 클래스의 sugar 슬롯은
값이 항상 SWEET이지만,
Dessert wine의 상위 클래스에는
이런 제약이 없다.
또 다른 예로, Pinot Noir 와인은
해산물과도 잘 어울릴 수 있지만,
다른 레드 와인들은 그렇지 않을 수 있다.
즉, 새로운 클래스를 도입하는 경우는 대부분
그 클래스에 대해서는 말할 수 있지만
상위 클래스에 대해서는 말할 수 없는
어떤 내용이 있기 때문이다.
실무적으로는, 각 하위 클래스는
새로운 슬롯을 추가하든지,
새로운 슬롯 값을 정의하든지,
혹은 상속된 슬롯의 패싯을
어떤 방식으로든 오버라이드해야 한다.
그러나 때로는 새로운 속성을 추가하지 않더라도
새로운 클래스를 만드는 것이 유용할 수 있다.
용어 계층(terminological hierarchy)의 클래스들은
새로운 속성을 도입할 필요가 없다.
예를 들어, 일부 온톨로지는
도메인에서 자주 사용되는 용어들에 대한
대형 참조 계층(reference hierarchy)을 포함한다.
전자 의무 기록 시스템의 온톨로지를 생각해 보자.
이 시스템은 다양한 질병들에 대한 분류를
온톨로지로 가지고 있을 수 있다.
이 분류는 속성이 전혀 없거나,
모든 클래스가 동일한 속성 집합만 가지는
단순 용어 계층일 수 있다.
이 경우에도, 용어들을 평면 목록으로 두는 것보다
계층 구조로 조직하는 것이 유용하다.
(1) 용어 탐색과 탐험이 더 쉬워지고,
(2) 의사가 상황에 맞는 적절한 일반성 수준의
용어를 쉽게 선택할 수 있기 때문이다.
새로운 속성을 추가하지 않더라도
새로운 클래스를 만드는 또 다른 이유는,
우리가 그 구분 자체를 모델링하기로 선택하지 않았더라도
도메인 전문가들이 실제로는
그 개념들 사이를 구분하고 있기 때문이다.
온톨로지는 도메인 전문가 간,
또는 도메인 전문가와 지식기반 시스템 간
의사소통을 돕기 위해 사용되므로,
전문가들이 도메인을 보는 방식을
온톨로지에 반영하고 싶어질 때가 있다.
마지막으로, 모든 제약 조건마다
별도 하위 클래스를 만드는 것은 피해야 한다.
예를 들어, 우리는 와인 세계에서
자연스러운 구분이기 때문에
Red wine, White wine, Rosé wine 클래스를 도입했다.
하지만 delicate wine, moderate wine 등
바디 수준마다 별도 클래스를 만들지는 않았다.
클래스 계층을 정의할 때 우리의 목표는,
클래스 조직에 도움이 되는 새로운 클래스를 도입하는 것과,
너무 많은 클래스를 만들어 복잡성을 키우는 것 사이에서
균형을 찾는 것이다.
4.5 A new class or a property value?
4.5 새로운 클래스인가, 아니면 속성 값인가?
도메인을 모델링할 때,
white, red, rosé 같은 구분을
새로운 클래스 집합으로 표현할지,
아니면 하나의 클래스에서 슬롯 값으로 표현할지 결정해야 할 때가 많다.
이 결정은 결국 온톨로지의 범위와
해당 작업의 목적에 따라 달라진다.
우리는 White wine 클래스를 만들 것인가,
아니면 Wine 클래스 하나만 만들고
color 슬롯 값으로 white, red 등을 표현할 것인가?
답은 보통,
우리가 온톨로지의 범위를 어떻게 정의했는지에 달려 있다.
White wine이라는 개념이
우리 도메인에서 얼마나 중요한가?
만약 와인이 도메인에서 부수적인 역할만 하고,
와인이 white인지 여부가
다른 객체와의 관계에 특별한 영향을 주지 않는다면,
white 와인을 별도의 클래스로 만들 필요는 없다.
예를 들어, 와인 라벨을 생산하는 공장에 대한 도메인 모델에서는
와인의 색과 관계없이 라벨 규칙이 같다면,
색 구분이 중요한 요소가 아니다.
반대로, 와인과 음식, 그리고 그들의 조합을 표현하는 도메인에서는
레드 와인과 화이트 와인은 매우 다른 존재이다.
각각 다른 음식과 짝을 이루고,
다른 특성들을 가지기 때문이다.
와인 테이스팅 순서를 결정하기 위한
와인지식베이스에서도 색(color)은 중요한 요소이다.
따라서 이 경우에는
White wine을 별도의 클래스로 만드는 것이 타당하다.
만약 슬롯 값의 차이가
다른 클래스에서 서로 다른 제약으로 사용된다면,
그 구분은 새로운 클래스로 표현하는 것이 좋다.
그렇지 않다면, 슬롯 값으로 표현하는 편이 낫다.
비슷하게, 우리의 와인 온톨로지에는
Red Merlot과 White Merlot 클래스가
각각 존재한다.
모든 Merlot 와인을 하나의 클래스로 두지 않는다.
레드 Merlot과 화이트 Merlot은,
같은 포도 품종으로 만들긴 하지만
실제로는 매우 다른 와인이며,
우리가 정교한 와인 온톨로지를 만들고자 한다면
이 구분은 중요하기 때문이다.
어떤 구분이 도메인에서 중요한 의미를 가지며,
사람들이 그 구분이 다른 값을 가진 객체들을
서로 다른 종류의 객체로 인식한다면,
그 구분을 위한 새로운 클래스를 만드는 것이 좋다.
어떤 개념을 위한 새로운 클래스를
도입할지 여부를 결정할 때,
그 클래스의 개별 인스턴스를 상상해 보는 것도 도움이 된다.
어떤 개별 인스턴스가 속한 클래스는
자주 바뀌어서는 안 된다.
보통, 개념의 내재적(intrinsic) 속성이 아닌
외재적(extrinsic) 속성으로 클래스를 구분하면,
인스턴스들이 클래스 사이를 자주 옮겨 다니게 된다.
예를 들어, 레스토랑의 와인 병을 표현하는 온톨로지에서
Chilled wine은 별도의 클래스가 되어서는 안 된다.
“차갑게 식힌 상태”라는 속성은
와인 병의 속성으로 표현되어야 한다.
왜냐하면 어떤 와인 병은
Chilled wine 클래스의 인스턴스였다가
온도가 올라가면 더 이상 이 클래스의 인스턴스가 아니게 되고,
다시 식히면 다시 이 클래스의 인스턴스가 되기 때문이다.
일반적으로 숫자, 색, 위치 같은 것들은
슬롯 값으로 표현되며
새로운 클래스를 만드는 근거가 되지 않는다.
하지만 와인의 경우, 색(color)은
와인을 설명하는 데 매우 핵심적인 속성이기 때문에
예외적인 경우이다.
또 다른 예로, 인체 해부학 온톨로지를 생각해 보자.
갈비뼈(ribs)를 표현할 때,
“왼쪽 1번 갈비뼈”, “왼쪽 2번 갈비뼈” 등
각각을 별도의 클래스로 만들어야 할까?
아니면 Rib라는 하나의 클래스에
순서(order)와 좌우 위치(lateral position) 슬롯을 두어 표현해야 할까?5
만약 우리가 각 갈비뼈에 대해
표현하고자 하는 정보가 상당히 다르다면,
각 갈비뼈마다 별도의 클래스를 만드는 것이 타당하다.
예를 들어, 각 갈비뼈가 둘러싸고 있는 장기나
보호하는 부위, 인접 구조 등이 서로 다르다면 말이다.
반면, 우리가 해부학을 약간 더 일반적인 수준에서 모델링하고,
애플리케이션 관점에서 모든 갈비뼈를 비슷하게 다룬다면
(예: X-ray에서 어느 갈비뼈가 부러졌는지만 말하면 되고,
다른 신체 부위에 어떤 의미가 있는지는 고려하지 않는 경우),
Rib라는 하나의 클래스와
lateral position, order 두 개의 슬롯만 두는 것이
더 단순한 계층 구조를 만들 수 있다.
4.6 An instance or a class?
4.6 인스턴스인가, 클래스인가?
어떤 개념을 온톨로지에서 클래스(class)로 표현할지,
아니면 개별 인스턴스로 표현할지는
온톨로지의 잠재적 애플리케이션에 달려 있다.
클래스와 인스턴스의 경계를 어디에 둘지 결정하는 일은,
표현에서 어느 수준까지를
가장 세부적인 단위(최소 단위)로 볼지 결정하는 것에서 출발한다.
이 세부 수준은 다시
온톨로지의 잠재적 애플리케이션에 의해 정해진다.
즉, 지식베이스에 표현하고자 하는
가장 구체적인 대상들은 무엇인가?
3장 1단계에서 정리했던 역량 질문들을 다시 떠올려 보면,
이 질문들의 답으로 등장하는
가장 구체적인 개념들이
지식베이스에서 인스턴스로 표현될 좋은 후보가 된다.
지식베이스에서 인스턴스는
가장 구체적인 개념을 나타낸다.
예를 들어, 우리가 와인과 음식의 궁합만 다룰 것이라면,
개별 와인 병 하나하나는 관심 대상이 아닐 것이다.
이 경우 Sterling Vineyards Merlot 같은 용어가
아마도 우리가 사용하는 가장 구체적인 용어가 될 것이다.
다시 말해, Wine 클래스는
개별 와인 병들의 집합이 아니라,
각 와이너리가 생산하는 구체적인 와인들의 집합을 나타낸다.
따라서 Sterling Vineyards Merlot은
지식베이스에서 인스턴스로 표현된다.
반대로, 와인–음식 궁합 지식베이스뿐 아니라
레스토랑 와인 재고까지 함께 관리하고 싶다면,
각 와인에 속한 개별 병들도
지식베이스에서 인스턴스가 될 수 있다.
마찬가지로,
Sterling Vineyards Merlot의 각 빈티지별로
서로 다른 특성을 기록하고 싶다면,
각 빈티지별 와인(예: Sterling Vineyards Merlot 1997 등)이
지식베이스의 인스턴스가 되고,
Sterling Vineyards Merlot 자체는
그 빈티지 인스턴스들을 포함하는 클래스가 된다.
또 다른 규칙은,
일부 인스턴스를 클래스 집합으로 옮겨야 할 이유를 제시해 준다.
만약 어떤 개념들이 자연스러운 계층을 이루고 있다면,
그 개념들은 클래스들로 표현해야 한다.
와인 지역(wine regions)을 생각해 보자.
처음에는 France, United States, Germany 같은
주요 와인 생산국들을 클래스,
그리고 그 안에 포함되는 특정 와인 지역들을
각국 클래스의 인스턴스로 표현하고 싶어질 수 있다.
예를 들어, Bourgogne region을
French region 클래스의 인스턴스로 둘 수 있다.
하지만 우리는 또한 Cotes d’Or region이
Bourgogne region의 일종이라는 사실도 표현하고 싶을 수 있다.
그렇다면 Bourgogne region은
하위 클래스나 인스턴스를 가질 수 있어야 하므로
클래스가 되어야 한다.
그러나 Bourgogne region을 클래스,
Cotes d’Or region을 그 인스턴스로 두는 것은
어느 정도 임의적이다.
어떤 지역이 클래스이고 어떤 지역이 인스턴스인지
명확하게 구분하기가 매우 어렵기 때문이다.
따라서 우리는 모든 와인 지역을 클래스들로 정의한다.
Protégé-2000에서는
어떤 클래스가 직접 인스턴스를 가질 수 없음을 나타내기 위해
그 클래스를 Abstract로 지정할 수 있다.
우리의 예에서는 모든 지역 관련 클래스들을
추상 클래스(Abstract)로 지정할 수 있다(Figure 8).
19
Figure 8. 와인 지역 계층 구조.
클래스 이름 옆의 "A" 아이콘은
해당 클래스가 추상 클래스이며,
직접 인스턴스를 가질 수 없음을 나타낸다.
이때 클래스 이름에서 “region”이라는 단어를 생략한다면
위 계층 구조는 잘못된 것이 된다.
예를 들어, Alsace가 France의 하위 클래스라고 말할 수는 없다.
Alsace는 France의 한 종류가 아니기 때문이다.
하지만 Alsace region은 French region의 한 종류이다.
클래스만이 계층 구조로 조직될 수 있다.
지식 표현 시스템에는 “하위 인스턴스(sub-instance)”라는 개념이 없다.
따라서 4.2절에서 논의한 용어 계층처럼
용어들 사이에 자연스러운 계층이 존재한다면,
그 용어들은 각자 인스턴스를 가지지 않더라도
클래스로 정의해야 한다.
4.7 Limiting the scope
4.7 범위 제한하기
클래스 계층 정의에 관한 마지막 메모로,
온톨로지 정의가 어느 정도 “완성”되었는지 판단할 때
항상 도움이 되는 규칙이 있다.
온톨로지는 도메인에 대한
모든 가능한 정보를 포함해서는 안 된다.
애플리케이션에 필요한 수준보다
더 많이 세분화(또는 더 많이 일반화)할 필요는 없다
(필요하다면 위/아래 한 단계 정도까지만).
와인과 음식 예제에서,
우리는 와인 라벨에 사용된 종이 재질이나
새우 요리를 어떻게 조리하는지까지 알 필요는 없다.
마찬가지로,
온톨로지는 클래스 계층에 존재하는
모든 가능한 속성과 구분을
다 포함할 필요가 없다.
우리 온톨로지에서는
와인이나 음식이 가질 수 있는
모든 속성을 표현하지 않았다.
우리는 온톨로지에 포함된 항목들에 대해
가장 핵심적인(salient) 속성들만 표현했다.
와인 책에서 포도알의 크기를 설명한다 하더라도,
우리는 이 정보를 온톨로지에 포함하지 않았다.
또한, 시스템 안에서 정의된 모든 용어들 사이에
생각해볼 수 있는 모든 관계들을 추가하지도 않았다.
예를 들어, favorite wine이나 favorite food 같은 관계를
단지 더 완전한 연결 구조를 위해 추가하지 않았다.
이 마지막 규칙은,
이미 온톨로지에 포함된 개념들 사이의 관계를
설정할 때에도 적용된다.
예를 들어, 생물학 실험을 설명하는 온톨로지를 생각해 보자.
이 온톨로지에는 Biological organisms라는 개념이 포함될 것이다.
또한 실험을 수행하는 Experimenter 개념도 포함될 것이다
(이름, 소속 등과 함께).
실험자도 사람(person)이므로,
실제로는 생물학적 유기체(biological organism)이기도 하다.
하지만 이 구분을 온톨로지에 반영해야 할까?
실험자 표현의 목적에서 보면,
우리는 실험자 자체를 실험 대상으로 다루지 않을 것이므로,
이 구분을 반영할 필요가 없다.
만약 우리가 온톨로지에서
각 클래스에 대해 말할 수 있는 모든 것을 표현하려 한다면,
Experimenter는 Biological Organism의 하위 클래스가 되어야 할 것이다.
그러나 우리가 예상하는 애플리케이션에서는
이 지식이 전혀 필요하지 않다.
실제로, 이런 추가적인 분류를 도입하는 것은
해가 될 수도 있다.
Experimenter를 Biological Organism의 하위 클래스로 만들면,
Experimenter 인스턴스는 이제 몸무게(weight), 나이(age),
종(species) 등 생물학적 유기체에 관한 슬롯들을 가지게 되지만,
실험을 표현하는 맥락에서는 전혀 관련이 없기 때문이다.
이런 설계 결정은
온톨로지를 바라보게 될 사용자들이
우리가 염두에 둔 애플리케이션을 모를 수 있다는 점을 고려해
문서에 명시해 두는 것이 좋다.
그렇지 않으면,
이 온톨로지를 다른 목적으로 재사용하려는 사람들이
Experimenter를 사람(person)의 하위 클래스로 사용하려 할 때,
원래 모델링이 그 사실을 전혀 고려하지 않았다는 점을
알지 못한 채 활용하게 될 위험이 있다.
4.8 Disjoint subclasses
4.8 서로 배타적인(disjoint) 하위 클래스들
많은 시스템은
여러 클래스들이 서로 배타적(disjoint)임을
명시적으로 지정할 수 있게 해 준다.
서로 배타적인 클래스들은
공통 인스턴스를 가질 수 없다.
예를 들어, 우리의 온톨로지에서
Dessert wine과 White wine 클래스는
서로 배타적이지 않다.
둘 모두에 속하는 와인들이 많기 때문이다.
Sweet Riesling의 하위 클래스인
Rothermel Trochenbierenauslese Riesling 인스턴스는
그런 예 중 하나이다.
반면, Red wine과 White wine 클래스는
서로 배타적이다.
어떤 와인도 동시에 레드이면서 화이트일 수는 없다.
이처럼 클래스들이 서로 배타적임을 지정해 두면,
시스템이 온톨로지의 정합성을
더 잘 검증할 수 있게 된다.
예를 들어, Red wine과 White wine을
서로 배타적이라고 선언한 뒤,
나중에 Riesling(White wine의 하위 클래스)과
Port(Red wine의 하위 클래스)의
하위 클래스로 동시에 정의되는 새로운 클래스를 만들면,
시스템은 이를 모델링 오류로 표시할 수 있다.
5. Defining properties—more details
속성 정의하기 — 좀 더 자세한 내용
이 절에서는 3장의 5단계와 6단계에서 다루었던,
온톨로지에서 슬롯을 정의할 때
유념해야 할 몇 가지 추가적인 사항들을 논의한다.
주로, 역슬롯(inverse slots)과
슬롯 기본값(default values)에 대해 살펴본다.
5.1 Inverse slots
5.1 역슬롯
어떤 슬롯의 값은
다른 슬롯의 값에 의해 결정될 수 있다.
예를 들어,
어떤 와인이 특정 와이너리에서 생산되었다면,
그 와이너리는 해당 와인을 생산(produces)한다고 말할 수 있다.
이 두 관계, maker와 produces는
서로 역관계(inverse relation)이다.
정보를 “양방향으로” 모두 저장하는 것은
중복(redundant)이다.
우리가 어떤 와인이 어느 와이너리에서 생산되었는지
알고 있다면,
지식베이스를 사용하는 애플리케이션은
항상 역관계, 즉
해당 와이너리가 그 와인을 생산한다는 정보도
유도해낼 수 있다.
그러나 지식 획득(knowledge acquisition) 관점에서는
두 방향의 정보를 모두
명시적으로 이용할 수 있는 것이 편리하다.
이렇게 하면,
어떤 경우에는 와인 인스턴스에서 maker를 입력하고,
다른 경우에는 와이너리 인스턴스에서 produces를 입력할 수 있다.
지식 획득 시스템은
역슬롯에 대한 값을 자동으로 채워 넣어
지식베이스의 일관성을 보장할 수 있다.
우리 예제에는
Wine 클래스의 maker 슬롯과
Winery 클래스의 produces 슬롯이라는
역슬롯 쌍이 있다.
사용자가 Wine 클래스 인스턴스를 만들고
maker 슬롯 값을 채우면,
시스템은 자동으로
해당 Winery 인스턴스의 produces 슬롯에
이 와인 인스턴스를 추가한다.
예를 들어,
Sterling Merlot이
Sterling Vineyard 와이너리에서 생산된다고 입력하면,
시스템은 자동으로
Sterling Vineyard 인스턴스의 produces 목록에
Sterling Merlot을 추가한다(Figure 9).
21
Figure 9. 역슬롯을 가진 인스턴스.
Winery 클래스의 produces 슬롯은
Wine 클래스의 maker 슬롯의 역슬롯이다.
둘 중 하나를 채우면,
다른 하나가 자동으로 갱신된다.
5.2 Default values
5.2 기본 값
많은 프레임 기반 시스템은
슬롯에 대한 기본 값(default value)을
지정할 수 있게 해 준다.
어떤 슬롯 값이
대부분의 인스턴스에서 동일하다면,
그 값을 슬롯의 기본 값으로 정의할 수 있다.
이 경우,
해당 클래스를 기반으로 새로운 인스턴스를 만들 때마다,
시스템이 자동으로 기본 값을 채워 넣는다.
이후 사용자는 필요하다면
해당 값을, 패싯이 허용하는 다른 값으로 변경할 수 있다.
즉, 기본 값은 편의를 위한 기능일 뿐이며,
모델에 새로운 제약을 추가하지도,
모델을 변경하지도 않는다.
예를 들어,
우리가 다룰 와인 대부분이 full-bodied 와인이라면,
Wine의 body 슬롯 기본 값을 “full”로 둘 수 있다.
그러면 별도로 값을 지정하지 않는 한,
정의되는 모든 와인은 기본적으로 full-bodied가 된다.
이는 슬롯 값(slot value) 자체와는 다르다.
슬롯 값은 변경할 수 없다.
예를 들어, Dessert wine 클래스에서
sugar 슬롯의 값을 SWEET으로 지정하면,
Dessert wine 클래스의 모든 하위 클래스와 인스턴스는
항상 sugar = SWEET 값을 가진다.
이 값은 하위 클래스나 인스턴스에서
변경할 수 없다.
6. What’s in a name?
이름에는 무엇이 들어 있는가?
온톨로지에서 개념의 이름 규칙을 정하고,
그 규칙을 일관되게 지키는 것은,
온톨로지를 이해하기 쉽게 만들 뿐 아니라
흔한 모델링 실수를 피하는 데도 도움이 된다.
개념 이름을 정하는 데에는 여러 가지 대안이 있다.
어떤 이름을 선택하더라도
특별히 더 낫거나 나쁜 것은 아닌 경우가 많다.
그러나 중요한 것은,
클래스와 슬롯에 대한 이름 규칙을 정하고,
이를 철저히 지키는 것이다.
지식 표현 시스템의 몇 가지 특징들은
이름 규칙 선택에 영향을 줄 수 있다.
• 시스템이 클래스, 슬롯, 인스턴스에
동일한 네임스페이스를 사용하는가?
즉, 같은 이름을 가진 클래스와 슬롯
(예: 클래스 winery와 슬롯 winery)을
동시에 가질 수 있는가?
• 시스템이 대소문자를 구분(case-sensitive)하는가?
즉, Winery와 winery를 서로 다른 이름으로 취급하는가?
• 이름에 허용되는 구분자(delimiter)는 무엇인가?
즉, 이름에 공백, 콤마, 별표 등을 포함할 수 있는가?
예를 들어 Protégé-2000은
모든 프레임에 대해 단일 네임스페이스를 사용하며,
대소문자를 구분한다.
따라서 클래스 winery와 슬롯 winery를
동시에 가질 수 없다.
대신 클래스 이름을 Winery(대문자 W)로,
슬롯 이름을 winery(소문자)로 사용할 수 있다.
반면 CLASSIC은
대소문자를 구분하지 않고,
클래스, 슬롯, 인스턴스에
서로 다른 네임스페이스를 사용한다.
따라서 시스템 관점에서
클래스와 슬롯을 모두 Winery라는 이름으로 두어도
아무 문제가 없다.
6.1 Capitalization and delimiters
6.1 대소문자와 구분자
개념 이름에서 대소문자를 일관되게 사용하면,
온톨로지의 가독성을 크게 개선할 수 있다.
예를 들어,
(시스템이 대소문자를 구분하는 경우)
클래스 이름은 대문자로 시작하고,
슬롯 이름은 소문자로 시작하는 것이 일반적이다.
개념 이름이 두 단어 이상으로 이루어져 있다면
(예: Meal course),
단어들을 어떻게 구분할지 결정해야 한다.
가능한 선택지는 다음과 같다.
• 공백 사용: Meal course
(Protégé를 포함한 많은 시스템은
이름에 공백을 허용한다.)
• 단어들을 붙이고, 새 단어의 첫 글자를 대문자로:
MealCourse
• 언더스코어, 대시 등 구분자 사용:
Meal_Course, Meal_course, Meal-Course, Meal-course
(구분자를 사용한다면,
새 단어를 대문자로 시작할지 여부도 정해야 한다.)
지식 표현 시스템이 이름에 공백을 허용한다면,
많은 온톨로지 설계자에게
공백을 사용하는 것이 가장 직관적인 선택일 수 있다.
하지만 우리 시스템이
다른 시스템과 상호 연동해야 한다면,
상대 시스템이 공백을 사용하지 않거나
표현 매체가 공백을 잘 처리하지 못할 수도 있다.
이런 경우에는 다른 방식을 사용하는 것이 좋을 수 있다.
6.2 Singular or plural
6.2 단수형인가 복수형인가
클래스 이름은 객체들의 집합을 나타낸다.
예를 들어, Wine 클래스는
실제로는 “모든 와인들”을 나타낸다.
이 때문에 일부 설계자에게는
클래스 이름을 Wine보다 Wines로 두는 것이
더 자연스럽게 느껴질 수 있다.
둘 중 어느 쪽이 더 좋다고 말할 수는 없다
(실제로는 단수형을 더 많이 사용하는 편이다).
그러나 어느 쪽을 택하든,
온톨로지 전체에서 일관되게 사용하는 것이 중요하다.
일부 시스템은 아예
개념 이름에 단수형 또는 복수형 중
어느 것을 사용할지 사전에 선언하게 하고,
이후 그 선택에서 벗어나지 못하게 하기도 한다.
항상 같은 형태를 사용하면,
4.1절에서 보았던 것처럼
Wines 클래스를 만들고
그 하위 클래스에 Wine을 두는 것과 같은
모델링 오류를 막는 데도 도움이 된다.
6.3 Prefix and suffix conventions
6.3 접두사·접미사 규칙
일부 지식베이스 방법론은
클래스와 슬롯 이름을 구분하기 위해
접두사(prefix)나 접미사(suffix)를 사용하기를 권장한다.
두 가지 일반적인 방식은
슬롯 이름 앞에 has-를 붙이거나,
뒤에 -of를 붙이는 것이다.
예를 들어, has- 규칙을 택하면
우리의 슬롯들은 has-maker, has-winery가 된다.
-of 규칙을 택하면
maker-of, winery-of가 될 것이다.
이 방식은 어떤 용어를 보더라도
그것이 클래스인지 슬롯인지
즉시 파악할 수 있게 해 준다.
단점은, 이름이 다소 길어진다는 점이다.
6.4 Other naming considerations
6.4 그 밖의 이름 관련 고려사항
이름 규칙을 정할 때
함께 생각해 볼 만한 사항은 다음과 같다.
• 이름에 “class”, “property”, “slot” 같은 문자열을
덧붙이지 않는다.
개념이 클래스인지 슬롯인지는
문맥에서 항상 알 수 있으며,
클래스와 슬롯에 서로 다른 이름 규칙
(예: 클래스 대문자 시작, 슬롯 소문자 시작)을 쓰면
이름만 보고도 개념 종류를 알 수 있다.
• 개념 이름에 축약형을 사용하는 것은
보통 좋은 생각이 아니다
(예: Cab 대신 Cabernet Sauvignon 사용).
• 동일한 상위 클래스를 공유하는
형제 클래스들의 이름에는,
상위 클래스 이름을
모두 포함시키거나 모두 빼야 한다.
예를 들어, Wine 클래스의
두 하위 클래스를 만들 때,
Red Wine과 White Wine 또는
Red와 White처럼,
둘 다 상위 클래스 이름을 포함시키거나
둘 다 포함시키지 않는 방식으로 통일해야 한다.
Red Wine과 White처럼 섞어 쓰지 않는다
7 Other Resources
7 기타 자료
우리는 예제에서
Protégé-2000을 온톨로지 개발 환경으로 사용했다.
Duineveld와 동료들(Duineveld et al. 2000)은
여러 다른 온톨로지 개발 환경들을
설명하고 비교하였다.
우리는 온톨로지 개발의 가장 기초적인 부분에 초점을 맞추었으며,
많은 고급 주제나
대안적 온톨로지 개발 방법론은
다루지 않았다.
Gómez-Pérez (1998)와 Uschold (Uschold and Gruninger 1996)는
대안적인 온톨로지 개발 방법론을 제시한다.
Ontolingua 튜토리얼(Farquhar 1997)은
지식 모델링의 형식적 측면을 다룬다.
현재 연구자들은
온톨로지 개발뿐 아니라
온톨로지 분석에도 많은 관심을 기울이고 있다.
더 많은 온톨로지가 생성되고 재사용될수록,
온톨로지를 분석하는 도구도 더 많이 등장할 것이다.
예를 들어, Chimaera(McGuinness et al. 2000)는
온톨로지 분석을 위한 진단 도구를 제공한다.
Chimaera가 수행하는 분석에는
온톨로지의 논리적 정합성 검사와
흔한 온톨로지 설계 오류 진단이 포함된다.
온톨로지 설계자는
진화 중인 온톨로지가
일반적인 온톨로지 모델링 관행에
얼마나 부합하는지 확인하기 위해
Chimaera 진단을 수행해 볼 수 있다.
8 Conclusions
결론
이 가이드에서는
선언적 프레임 기반 시스템을 위한
온톨로지 개발 방법론을 설명하였다.
우리는 온톨로지 개발 과정의 단계들을 나열하고,
클래스 계층과
클래스 및 인스턴스의 속성을 정의할 때
직면하는 복잡한 이슈들을 다루었다.
그러나 모든 규칙과 제안을 다 따른다 하더라도,
기억해야 할 가장 중요한 사실 중 하나는 다음과 같다.
어떤 도메인에 대해서도
단 하나의 “옳은” 온톨로지는 존재하지 않는다.
온톨로지 설계는 창의적인 과정이며,
서로 다른 사람이 설계한 두 온톨로지는
절대 동일하지 않을 것이다.
온톨로지의 잠재적 애플리케이션과
설계자가 도메인을 이해하고 바라보는 방식은
온톨로지 설계 선택에
반드시 영향을 미치게 된다.
“Proof is in the pudding”이라는 말처럼,
우리가 설계한 온톨로지의 품질은
오직, 그것을 원래 설계했던 애플리케이션에서
실제로 사용해 봄으로써만 평가할 수 있다.
'빅데이터(Big Data) 이론과 코드 > 1. 용어의 정의' 카테고리의 다른 글
| 파라미터(Parameter), 하이퍼파라미터(Hyper Parameter), 아규먼트(Argument)의 용어 정의 (1) | 2021.09.28 |
|---|
