온톨로지 소양 교육 — GT·WT 진단 온톨로지 프로젝트

① Class — "어떤 종류가 있는가"

개념의 범주를 선언합니다. "이런 종류의 것이 세상에 있다"는 카탈로그.

② Instance — "그 종류의 실제 사례"

Class가 "터빈이라는 개념"이라면,
Instance는 "바로 그 WTG03호기". 구체적인 개별 개체입니다.

③ Object Property — "개체와 개체를 잇는 관계"

두 개체 사이를 잇는 "동사"입니다.
터빈이 hasPart 기어박스, 기어박스를 monitoredBy 센서처럼.

④ Datatype Property — "개체의 속성·값"

개체에 붙는 "형용사·숫자·날짜"입니다.
다른 개체가 아니라 단순한 데이터값을 가리킵니다.

요소 선택:

풍력 도메인 그래프 실제 적용

같은 구조를 우리 풍력에 적용하면

Class

Instance

Object Property

Datatype Property

rdf:type (a)

선택된 요소

버튼을 클릭해 요소를 선택하면 관계도에서 해당 요소만 강조됩니다. — 전체 보기: 모든 요소가 동시에 보입니다.

🧠 멘탈 모델 — 한 줄로

Class = 명사의 종류, Instance = 그 명사의 한 사례, Object Property = 두 개체를 잇는 동사, Datatype Property = 개체에 붙는 형용사·수치·날짜.

위 코드는 결국 "WTG03(Instance) ─hasPart(동사)→ Gearbox_03(Instance)"처럼 명사를 동사로 잇고, 그 명사들에 형용사(출력·날짜·진동값)를 붙인 것뿐입니다. 새 도메인을 만나도 "명사가 뭐고, 동사가 뭐고, 형용사가 뭔가"만 정리하면 됩니다.

한 단계 더 — Object vs Datatype 경계의 함정

예: 센서의 "측정값"을 문자열로 저장하면 datatype property, 측정 이벤트 인스턴스로 저장하면 object property. 후자가 훨씬 강력합니다 — 같은 센서 종류를 공유하는 설비들이 자동 그룹되고, 측정 이벤트 자체에 타임스탬프·품질 플래그 등을 추가할 수 있습니다.

처음에 datatype으로 시작했다가 나중에 object property로 "승격"하는 마이그레이션이 흔합니다. 사전에 비용을 평가하세요.

⚠ 함정 — Class와 Instance 경계를 도중에 바꾸지 마십시오

같은 개념을 "종류(Class)"로 둘 것인지, "사례(Instance)"로 둘 것인지 — 이 결정은 모델링 첫 단계에서 정해두고 가야 합니다. 도중에 뒤집으면 그 위에 쌓아 올린 쿼리와 대시보드가 한꺼번에 깨집니다.

일상 비유 — "부품 유형(PartType)"을 어떻게 둘 것인가

컴퓨터 폴더 구조에 비유해 보십시오.

(A) Class로 두는 방식 = "Gearbox는 폴더 종류이고, 대형·소형 기어박스는 그 하위 폴더" → ":LargeGearbox는 :Gearbox의 하위 종류"
(B) Instance로 두는 방식 = "Gearbox는 태그 목록이고, 대형·소형은 목록 안의 항목" → ":LargeGearbox는 :Gearbox의 한 사례"

무엇이 깨지는가. 처음에 A로 짜놓고, 다른 팀이 "부품 유형별 고장 빈도"를 보는 대시보드를 만들었다고 칩시다. 그 안에는 "Gearbox의 하위 종류를 전부 찾아 고장 이력을 집계"하는 쿼리가 들어 있습니다. 그런데 어느 날 모델을 B로 바꾸면 — 그 쿼리는 빈 결과를 돌려줍니다. 더 이상 "하위 종류"가 아니라 단순 태그 목록이기 때문입니다. 대시보드·리포트·데이터 파이프라인을 전부 다시 짜야 합니다.

처음에 어떻게 고르나. 그 개념이 (1) "카운트하거나 합계 낼 대상이 되는가"면 → Instance에 가깝습니다. (2) "앞으로 하위 분류가 더 늘어날 가능성이 있는가"면 → Class에 가깝습니다. 둘 다 해당된다면 — 더 자주 쓰일 방향을 먼저 고르고, 나머지는 별도 속성으로 보조하는 게 안전합니다.

그럼 이 4가지 부품은 — 어떻게 적을까요?
답은 단 하나, "주어 · 술어 · 목적어" 세 칸짜리 한 줄입니다. 다음 페이지에서 봅니다.