왜 표준 온톨로지가 중요한가

공장이 100개면 데이터 모델이 100개. 호환이 안 된다. 표준(RDF, OWL)을 따르면 공장 간, 시스템 간 데이터 교환이 가능해진다.

눌러서 크게 보기

RDF (Resource Description Framework)

한 줄 정의: 세상의 모든 사실을 (주어, 술어, 목적어) 트리플로 표현하는 W3C 표준.

# Turtle 표기법 (RDF의 가장 흔한 직렬화)
@prefix mfg: <http://example.org/mfg#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

mfg:cnc_mill_003 rdf:type mfg:Equipment .
mfg:cnc_mill_003 mfg:hasName "CNC밀링 3호기" .
mfg:cnc_mill_003 mfg:hasComponent mfg:spindle_unit_003 .
mfg:spindle_unit_003 mfg:hasPart mfg:bearing_main_003 .
mfg:bearing_main_003 mfg:canCause mfg:alarm_e201 .
mfg:alarm_e201 mfg:causedBy mfg:cause_bearing_wear .

핵심 특징

• URI(고유 식별자)로 모든 엔티티 식별 → 다른 시스템과 충돌 없음
• 직렬화: Turtle, RDF/XML, JSON-LD, N-Triples
• 쿼리 언어: SPARQL

OWL (Web Ontology Language)

RDF가 "사실을 적는 문법"이라면, OWL은 **"개념 체계를 정의하는 문법"**이다. 아래 블록은 그대로 떼어 rdflib이나 Protégé에 넣으면 파싱된다. 접두사 선언이 빠지면 첫 줄에서 막히므로 예제마다 필요한 접두사를 모두 적는다.

@prefix mfg:  <http://example.org/mfg#> .
@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl:  <http://www.w3.org/2002/07/owl#> .
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .

# (1) 클래스 계층: CNC 공작기계는 설비의 한 종류다 (is-a)
mfg:CNCMachine rdfs:subClassOf mfg:Equipment .

# (2) 필요조건: 설비라면 구성요소를 하나 이상 가진다
mfg:Equipment rdfs:subClassOf [
  a owl:Restriction ;
  owl:onProperty mfg:hasComponent ;
  owl:minCardinality "1"^^xsd:nonNegativeInteger
] .

# (3) 추론의 재료: hasComponent는 hasPart의 하위 속성이고, hasPart는 이행적이다
mfg:hasComponent rdfs:subPropertyOf mfg:hasPart .
mfg:hasPart a owl:TransitiveProperty .

# (4) 사실
mfg:cnc_mill_003     mfg:hasComponent mfg:spindle_unit_003 .
mfg:spindle_unit_003 mfg:hasPart      mfg:bearing_main_003 .

(3)과 (4)에서 무엇이 따라 나오는가

cnc_mill_003     hasComponent spindle_unit_003    (적어 둔 사실)
spindle_unit_003 hasPart      bearing_main_003    (적어 둔 사실)
--------------------------------------------------------------
cnc_mill_003     hasPart      spindle_unit_003    (하위 속성 선언에서)
cnc_mill_003     hasPart      bearing_main_003    (hasPart의 이행성에서)

이행성 하나만으로는 이 결론이 나오지 않는다. hasPart가 이행적이라는 말이 보장하는 것은 hasPart를 두 번 따라간 경우뿐인데 여기서는 첫 홉이 hasComponent이므로, 두 속성을 잇는 다리가 따로 필요하다. rdfs:subPropertyOf가 그 다리이고, 같은 결론을 owl:propertyChainAxiom으로 얻을 수도 있다. a(= rdf:type)를 빠뜨리고 mfg:hasPart owl:TransitiveProperty .라고 쓰면 목적어가 없는 문장이 되어 파서가 거부한다.

자주 틀리는 곳: OWL은 제약 언어가 아니다

위 (2)를 rdfs:subClassOf 대신 owl:equivalentClass로 쓰면 뜻이 뒤집힌다.

@prefix mfg: <http://example.org/mfg#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .

mfg:Equipment owl:equivalentClass [
  a owl:Restriction ;
  owl:onProperty mfg:hasComponent ;
  owl:someValuesFrom owl:Thing
] .

mfg:pallet_007 mfg:hasComponent mfg:label_007 .

equivalentClass로 묶으면 Equipment는 "hasComponent를 가진 모든 것"과 같은 집합이 된다. 그래서 라벨 하나를 붙여 둔 팔레트도 추론기가 Equipment로 분류해 버린다. 필요조건만 걸고 싶으면 rdfs:subClassOf를 써야 한다.

어느 쪽으로 쓰든 OWL은 위반을 잡아 주지 않는다. OWL의 의미론은 개방세계 가정(Open World Assumption) 위에 서 있어서, 구성요소가 하나도 연결되지 않은 설비를 보면 "규칙을 어겼다"가 아니라 "아직 적히지 않았다"로 읽는다. 카디널리티 공리는 검사 기준이 아니라 추론의 근거다.

규칙을 지켰는지 검사하려면 검사하는 도구를 따로 쓴다. RDF 쪽 표준은 SHACL이다. 형상(shape)을 선언해 데이터에 걸면 위반이 보고서로 나온다.

@prefix sh:  <http://www.w3.org/ns/shacl#> .
@prefix mfg: <http://example.org/mfg#> .

mfg:EquipmentShape a sh:NodeShape ;
  sh:targetClass mfg:Equipment ;
  sh:property [
    sh:path mfg:hasComponent ;
    sh:minCount 1 ;
    sh:message "설비에 구성요소가 하나도 연결되어 있지 않습니다"
  ] .

Neo4j 쪽에서는 스키마 제약을 쓴다. 다만 관계·속성의 존재 제약은 Enterprise 에디션 기능이므로, 이 과정에서 쓰는 커뮤니티 에디션에서는 조회로 위반을 찾아내고 적재하는 쪽에서 막는다.

// 구성요소가 하나도 없는 설비 찾기 (커뮤니티 에디션에서 쓰는 검사)
MATCH (e:Equipment)
WHERE NOT (e)-[:HAS_COMPONENT]->()
RETURN e.name AS violation

OWL 추론기가 하는 일과 하지 않는 일

여기서 일관성 검사는 서로 배타적이라고 선언한 두 클래스에 같은 개체가 동시에 속하는 것 같은 논리적 모순을 찾는 일이지, 값이 비었는지 보는 무결성 검사가 아니다. 둘을 섞으면 "OWL을 넣었는데 왜 이상한 데이터가 그대로 들어오느냐"는 자리에 도착한다.

제조 도메인 표준 온톨로지

이미 만들어진 표준이 있으면 그것부터 살펴본다. 아래 다섯은 각각 다루는 영역이 다르다.

# ISA-95 설비 계층을 옮긴 예시
@prefix isa:  <http://example.org/isa95#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl:  <http://www.w3.org/2002/07/owl#> .

# 다섯 단계는 서로 상속 관계가 아니라 같은 층위의 자매 클래스다
isa:Enterprise rdfs:subClassOf isa:EquipmentHierarchyLevel .
isa:Site       rdfs:subClassOf isa:EquipmentHierarchyLevel .
isa:Area       rdfs:subClassOf isa:EquipmentHierarchyLevel .
isa:WorkCenter rdfs:subClassOf isa:EquipmentHierarchyLevel .
isa:WorkUnit   rdfs:subClassOf isa:EquipmentHierarchyLevel .

# 단계 사이를 잇는 것은 상속이 아니라 포함 관계다
isa:contains a owl:TransitiveProperty ;
  rdfs:domain isa:EquipmentHierarchyLevel ;
  rdfs:range  isa:EquipmentHierarchyLevel .

Site rdfs:subClassOf Enterprise라고 쓰고 싶어지는 자리인데, 그렇게 쓰면 "모든 사업장은 기업이다"라는 뜻이 되어 버린다. 사업장은 기업의 부분이지 기업의 종류가 아니다. 계층이 상속인지 포함인지 구분하는 것이 온톨로지 설계에서 가장 먼저 갈리는 지점이고, Day 1 실습에서도 이 둘을 다른 필드로 나누어 쓴다.

우리 프로젝트: 표준을 어떻게 활용할까

[현실적 권장사항]

1. 처음부터 표준 100% 적용 ❌
   → 너무 복잡, PoC 실패 가능성

2. 표준을 "참고" → 우리 도메인에 맞게 단순화 ✅
   → 클래스 이름, 관계 이름은 표준과 유사하게
   → 향후 표준 매핑(Mapping) 시 비용 절감

3. ID 체계는 URI 패턴 사용
   → http://example.org/mfg#cnc_mill_003
   → 표준 RDF 도구와 호환

Neo4j와 RDF의 관계

둘 다 그래프지만 다르다.

이번 주는 Neo4j를 쓴다. 학습 곡선이 완만하고 시각화가 강력하기 때문. 나중에 RDF로 전환하고 싶으면 neosemantics(n10s) 플러그인으로 변환 가능.