콘텐츠로 이동

Ch 4. 온톨로지 설계 — 개념·관계·제약·계층

이 챕터에서 배우는 것

  • 온톨로지가 정의하는 네 가지 — 개념(클래스) · 관계 · 제약 · 계층
  • 컴피턴시 질문(competency question)으로 설계를 시작하는 법
  • 작게 시작해 키우는 실전 절차와, 과설계를 피하는 감각
  • 관계로 둘지 속성으로 둘지, 클래스로 올릴지 결정하는 기준

전제

Ch 2의 온톨로지=스키마 구분, Ch 3의 트리플.

1. 개념 — 온톨로지가 정의하는 네 가지

온톨로지는 도메인의 "틀"이다. 네 가지를 정의한다.

  • 개념(클래스) — 도메인에 어떤 종류의 개체가 있는가. Person, Company, Drug, Disease.
  • 관계(properties) — 개체들이 어떻게 이어지는가. employedBy, treats, cites.
  • 제약(constraints) — 관계의 규칙. treats의 출발은 Drug이고 도착은 Disease다(domain/range), 한 사람은 한 번에 한 곳에 고용된다(cardinality).
  • 계층(hierarchy) — 개념 간 상속. Cardiologist는 Doctor의 하위, Doctor는 Person의 하위.

이 네 가지가 "어떤 그래프가 말이 되는가"를 정한다. 지식 그래프(인스턴스)는 이 틀 안에서만 채워진다.

2. 왜 필요한가 — 컴피턴시 질문에서 시작한다

온톨로지 설계의 가장 흔한 실패는 "도메인의 모든 걸 모델링하려는 것"이다. 끝이 없고, 정작 쓸모와 무관한 디테일에 시간을 쓴다.

좋은 출발점은 컴피턴시 질문 — "이 온톨로지가 답할 수 있어야 하는 질문들"을 먼저 적는 것이다. 온톨로지는 그 질문에 답하는 데 필요한 만큼만 있으면 된다.

컴피턴시 질문 (의료 도메인 예)
- 이 약은 어떤 질병을 치료하는가?
- 이 질병에 금기인 약은?
- 이 약과 상호작용하는 다른 약은?
- 특정 성분을 포함한 약을 모두 찾아라.

이 질문들에서 명사(약·질병·성분)는 개념 후보, 동사(치료한다·금기다·상호작용한다·포함한다)는 관계 후보가 된다. 질문이 설계를 끌고 간다.

3. 어디서부터 — 작게 시작해 키운다

실전 절차는 단순하다.

  1. 컴피턴시 질문 10~20개를 적는다.
  2. 거기서 핵심 개념을 추린다(명사). 처음엔 5~10개면 충분하다.
  3. 질문이 따라가는 관계를 정의한다(동사). 방향과 양 끝 타입(domain/range)을 정한다.
  4. 꼭 필요한 제약·계층만 추가한다. 나머지는 나중에.

작은 의료 온톨로지 스케치:

클래스:   Drug, Disease, Ingredient
관계:     Drug —treats→ Disease
          Drug —contains→ Ingredient
          Drug —interactsWith→ Drug
계층:     (없음 — 필요해지면 추가)
제약:     treats: domain=Drug, range=Disease

여기서 출발해 컴피턴시 질문이 늘 때마다 개념·관계를 보탠다. "완벽한 온톨로지를 먼저"가 아니라 "질문에 답하는 최소 온톨로지부터"다.

4. 자주 깨지는 포인트

과설계. OWL의 모든 기능을 쓰려다 첫 그래프를 못 만든다. 컴피턴시 질문이 요구하지 않는 추상화는 빚이다.

관계 vs 속성 vs 클래스 혼동. 판단 기준: 그 정보를 따라가며 질의해야 하면 관계(엣지), 단순 값이면 속성. 그 관계에 자체 속성이 줄줄이 붙으면 클래스로 승격한다(예: Prescription이 약·환자·용량·날짜를 묶는다).

클래스 폭발. 비슷한 개념을 잘게 쪼개 클래스를 수십 개 만든다. 계층(상속)으로 묶을 수 있는지, 속성 하나로 구분되는지 먼저 본다(Doctor 하나에 specialty 속성 vs Cardiologist/Neurologist 별도 클래스).

5. 연습 & 다음 챕터

확인 문제

  1. 내 도메인의 컴피턴시 질문 10개를 적고, 명사/동사를 개념/관계 후보로 분류하라.
  2. "처방"을 관계로 둘 때와 클래스로 올릴 때를 각각 어떤 상황이 가르는가?

다음

대부분의 조직엔 이미 정규화된 DB 스키마가 있다. 거기엔 온톨로지가 숨어 있다 — 그걸 끌어내는 법으로 간다 → Ch 5.

원전

  • Noy & McGuinness (2001). Ontology Development 101. Stanford KSL
  • Grüninger & Fox (1995). Methodology for the Design and Evaluation of Ontologies (competency questions)
  • Allemang & Hendler (2011). Semantic Web for the Working Ontologist.