온톨로지란 무엇인가
같은 단어를 사람마다 다른 뜻으로 쓰면 같은 데이터에서도 다른 숫자가 나옵니다. 오늘은 그 차이를 명시적인 정의로 합의하는 도구, 온톨로지의 정의를 원문으로 확인합니다.
이번 회차, 내 속도로.
기초를 더 짚거나 궁금한 주제로 잠깐 넓혀 보세요. 최대 3단계를 거쳐 DAY 51로 돌아옵니다.
난이도·관심 주제 고르기
1/2개 선택 · 새 보충·심화 수업과 본과정 다시 읽기를 선택할 수 있어요.
이렇게 다녀와요 1단계 · 약 12분
- 출발 · DAY 51공유된 개념화의 명세
- 1. 관심 주제ConceptScheme·레이블 규칙·broader 방향추가 21 · 새 추가 수업
- 복귀 · DAY 51원래 회차 이어가기
- ConceptScheme·레이블 규칙·broader 방향 · DAY 52에서 시소러스 단계를 개념으로 봤다면, 여기서는 실제 SKOS 트리플을 써 보며 어떤 레이블이 허용되고 어떤 계층이 추론되는지 확인합니다.
선택과 경로 기록은 이 브라우저에 저장됩니다. 본과정의 회차 완료와는 별도입니다.
핵심 개념
철학에서 존재론(ontology)은 무엇이 존재하는지를 묻는 분야입니다. 컴퓨터 과학에서는 Gruber(1993)의 정의가 가장 널리 인용됩니다. “An ontology is an explicit specification of a conceptualization.” 여기서 개념화(conceptualization)는 어떤 목적을 위해 표현하려는 세계를 추상화·단순화한 관점, 곧 관심 영역에 존재한다고 보는 대상·개념과 그 관계입니다. Gruber는 지식 기반 시스템에서 ‘존재한다’는 것은 곧 표현할 수 있는 것이라고 덧붙였습니다.
Studer, Benjamins & Fensel(1998)은 Gruber와 Borst의 정의를 바탕으로 “a formal, explicit specification of a shared conceptualisation”이라고 다듬었습니다. 논문의 설명을 따르면 개념화는 어떤 현상의 관련 개념을 식별한 추상 모델이고, 명시적(explicit)은 개념의 종류와 사용 제약을 분명히 정의한다는 뜻, 형식적(formal)은 자연어가 아니라 기계가 읽을 수 있다는 뜻, 공유된(shared)은 한 개인이 아니라 집단이 받아들인 합의된 지식이라는 뜻입니다.
현장에서 이 정의가 왜 필요한지는 ‘고객’ 같은 흔한 단어에서 드러납니다. 영업팀은 계약한 조직을, 지원팀은 문의한 사람을, 재무팀은 청구서를 받은 계정을 고객이라 부를 수 있습니다. 머릿속 개념화가 다르니 같은 테이블에서도 고객 수가 셋으로 갈립니다. 온톨로지는 이 차이를 드러내고 하나의 정의로 합의하거나, 서로 다른 개념(고객·문의자·청구 계정)으로 나누어 이름을 붙이게 합니다.
명세는 문서·코드·RDF 같은 형식으로 적힌 결과물이고, 개념화는 사람들의 머릿속에 있는 이해입니다. 명세가 기계 판독 가능하다고 해서 실제 세계와 맞는다는 보장은 없으며, 합의도 특정 목적과 범위 안에서만 유효합니다. 모든 부서의 모든 질문에 맞는 정의는 드물기 때문에, 온톨로지를 만들 때는 누가 무엇을 위해 쓰는지를 먼저 정해야 합니다.
작은 예제로 따라가기
레코드 네 개를 놓습니다. A사(계약·청구 완료), B사(문의만), C씨(문의만), D사(계약·문의, 아직 청구 전).
부서 정의대로 세면 영업(계약한 조직)은 A·D 2곳, 지원(문의한 주체)은 B·C·D 3곳, 재무(청구서를 받은 계정)는 A 1곳으로 숫자가 모두 다릅니다.
‘고객 = 유효한 계약이 1건 이상 있는 조직’으로 합의하고, 문의만 한 주체는 ‘문의자’라는 별도 개념으로 분리하면 ‘고객은 몇 곳인가?’의 답이 2로 하나로 정해집니다.
직접 실험해 보기
세 부서가 정의한 ‘고객’ 카드를 읽고 차이를 먼저 찾은 뒤, ‘합의된 정의’ 버튼을 눌러 클래스·필수 속성·예와 비예가 어떻게 명시되는지 확인하세요.
세 부서의 ‘고객’을 하나의 명세로 합의하기
| 거래처 | 견적 | 결제 | 유효 계약 | 부서 기준 |
|---|---|---|---|---|
| 가람상사 | 있음 | 0건 | – | 고객 |
| 나래물산 | 있음 | 2건 | – | 고객 |
| 다온식품 | 있음 | 5건 | 있음 | 고객 |
| 라온테크 | – | 1건 | 있음 | – |
| 마루디자인 | 있음 | 0건 | 있음 | 고객 |
개념화(conceptualization)는 각 부서 머릿속의 뜻이고, 명세(specification)는 그 뜻을 문서·코드로 적은 것입니다. 지금은 명세가 없어 같은 질문에 4·3·3이라는 다른 답이 나옵니다.
이번에는 직접 풀어 보세요
정답을 보기 전에 계산과 이유를 적어 보세요. 해설과 비교하고 확인 표시를 남기면 완료할 수 있습니다.
힌트 보기
같은 배송이 어느 시점에 ‘완료’로 세어지는지 두 팀 기준으로 비교해 보세요.
풀이와 비교하기
창고 기준으로는 출고하자마자 완료로 세어 완료율이 높게 나오고, 고객 기준으로는 수령 뒤에야 셉니다. 같은 날 보고서의 완료 건수가 달라집니다. 예를 들어 ‘배송 완료 = 수령 확인(서명 또는 사진)이 기록된 배송’으로 정의하고, 차량에 실린 상태는 ‘출고됨’이라는 별도 상태로 둡니다. 두 개념을 나누면 같은 단어가 다른 숫자를 만드는 일을 막을 수 있습니다.
풀이와 확인 표시는 이 브라우저에 저장됩니다.
오늘 이해한 것과 다시 볼 것
계산이 달라진 이유, 헷갈린 개념, 다음에 확인할 질문을 남겨 보세요.
메모는 이 브라우저에 저장됩니다. 홈에서 전체 기록을 내려받을 수 있습니다.오늘의 이해 확인
Studer 등(1998)의 정의에서 ‘공유된(shared)’이 뜻하는 것은?
완료 조건: 확인 퀴즈 정답 · / 직접 풀기 0/1
더 깊이 읽기
예제와 실험 데이터는 이 과정을 위해 만든 것입니다. 원문은 선택 자료이며, 강의와 직접 풀기만으로도 다음 회차를 이어갈 수 있습니다.
A translation approach to portable ontology specificationsGruber (1993)Knowledge engineering: Principles and methodsStuder, Benjamins & Fensel (1998)이 자료는 개념 학습용입니다. 실제 데이터베이스·라이브러리·플랫폼의 동작과 설정은 제품과 버전마다 다를 수 있습니다.