온톨로지 소양 교육

DB 안에서 역할이 두 갈래로 나뉜다

트리플 스토어에 넣는 RDF는 무엇을 담느냐에 따라 역할이 둘로 나뉩니다.

Class · 종류 Instance · 실제 사례 관계 값·속성

TBOX · 설계도

"이런 종류·관계가 있다"는 약속

진동 알람이란 무엇이고, 기어박스·센서·근거 문서와 어떤 관계를 가질 수 있나?

B 챕터에서 그린 지도 — Class, Object Property, Datatype Property 슬롯 — 가 여기 모입니다.
아직 구체적인 설비·날짜·측정값은 없습니다. 클래스와 관계·속성 이름만 있습니다.
지도는 자주 바꾸지 않습니다. 모델 버전 관리 대상입니다.

ABOX · 현장 기록

"구체적 사실들이 스키마에 맞춰 채워짐"

WTG03 기어박스에서 6월 13일 진동 알람이 났다 — 근거 문서·센서는 어디?

현장 기록 카드 (예시) 호기 · WTG03 | 부품 · Gearbox_03
발생 · 2026-06-13 | 진동 · 4.2
근거 문서 · 정비보고 p.14 | 센서 · VibSensor_03

그 지도 위로 Instance가 올라가고, 관계와 값이 채워집니다.
박물관 표본 태그처럼, 이 사례만의 식별자·날짜·수치가 붙습니다.

✋ 잠시만! — 왜 TBox와 ABox를 나누나?

RDF 자체는 이 둘을 나누라고 강제하지 않습니다. 한 TTL 파일에 설계와 인스턴스를 함께 넣어도 됩니다.
그러나 , 규칙이 있는 쪽(TBox)과 사실이 쌓이는 쪽(ABox)을 구분해 두는 게 운영에 유리합니다.

바뀌는 주기 — TBox(설계)는 느리게, ABox(현장 데이터)는 자주 갱신
담당 — 모델 설계와 데이터 적재를 분리 (RDB의 DDL과 INSERT를 나누는 것과 비슷)
질의·적재 범위 — 사실만 넣을 때 규칙 쪽을 건드리지 않기 쉽게

TTL 하나에 다 들어가나?

기술적으로는 가능합니다

하나의 .ttl 파일 안에 클래스 정의, 속성 정의, 실제 인스턴스, 문서 URI를 모두 적을 수 있습니다. GraphDB 입장에서는 결국 트리플 묶음이기 때문입니다.

역할에 따라 나누기도 합니다

파일 개수·이름은 정해진 표준이 아닙니다. 아래는 흔히 쓰는 예시일 뿐입니다.

# 예시 — 프로젝트마다 다름
schema.ttl      # TBox
instances.ttl   # ABox
# 원본 역추적이 필요할 때만 추가
source-meta.ttl # → graph:source-meta 등

파일은 나뉘는데, GraphDB에는 어떻게 들어가나?

GraphDB는 저장소(창고) 하나 — TTL 파일은 사람이 Git·폴더에서 나눕니다.
DB 안에서는 Named Graph(서랍) — 트리플 묶음 이름표 — 로 구역을 나눕니다.
RDB 테이블·별도 DB와 다름 — 인스턴스 하나 안의 논리 구역입니다.
Query에서 GRAPH <…>로 꺼낼 범위만 정합니다 — 트리플은 한 저장소에 있습니다.
파일 개수 ≠ 서랍 개수 · 파일 이름과 서랍 이름은 자동 1:1이 아님 — Import 때 지정.
graph:source-meta는 ETL 로그가 아니라, 사실의 원본 위치 참조입니다.

1. 임포트 흐름

파일 이름 ≠ 서랍 이름 — Import할 때 “이 파일은 이 서랍에”라고 직접 지정해야 합니다.

GRAPH <…>로 Query 범위(서랍)를 지정합니다 — 나머지 트리플은 건드리지 않습니다.

여기까지는 TTL을 GraphDB에 Import하는 방법이었습니다 — graph:schema · graph:data에 나눠 넣기까지.
다음은 SPARQL로 그 트리플을 찾는 조회입니다.
순서는 "출발점 찍기 → 이동 → 읽기"입니다. 다음 페이지에서 봅니다.