RDF·OWL·SPARQL·SHACL - 온톨로지를 표현하고 조회하고 검증하는 기술

네 가지 표준 기술, 동사로 기억하기

industrial-ontology-basics에서 온톨로지가 무엇인지 봤다면, 이번에는 그걸 실제로 적고 쓰는 기술입니다. 네 가지 모두 W3C 공개 표준이라 특정 제품에 묶이지 않습니다.

RDFS는 클래스·하위 클래스·domain/range 같은 기본 어휘만 제공하고, OWL은 "두 클래스는 겹치지 않는다", "두 대상은 같다" 같은 풍부한 표현을 더합니다. 저장소(GraphDB, Apache Jena Fuseki 등)와 추론기는 이 표현을 처리하는 프로그램입니다.

예제: 라인 C의 모터 한 대

설명용 가상 시나리오입니다. 라인 C의 모터 M01을 센서 S07이 관측하고, 정비일지 R12가 M01의 작업 이력을 기록합니다. 온도 98°C와 임계값 95°C는 설명용 숫자입니다.

RDF: 사실을 한 줄씩

Motor rdfs:subClassOf Equipment       클래스의 포함 관계
Motor_01 rdf:type Motor              특정 개체의 소속
Sensor_07 monitors Motor_01          개체 사이의 관계
Motor_01 serialNumber "M-001"        개체와 값의 관계

한 줄에 사실 하나, 이 한 줄을 트리플이라고 부릅니다. 대상은 IRI라는 전역 식별자로 부르기 때문에, 시스템이 달라도 같은 IRI면 같은 대상입니다. EQ-001과 M01이 같은 설비인지의 문제를 푸는 기반입니다.

테이블은 열이 미리 정해져 있어 새 정보를 넣으려면 구조를 바꿔야 하지만, RDF는 트리플 한 줄만 추가하면 됩니다. 대신 대량 집계 성능은 관계형 DB가 유리한 경우가 많습니다.

OWL: 규칙을 적고 추론한다

"모터는 설비의 하위 클래스"라는 공리와 "Motor_01은 모터"라는 데이터가 있으면, 누구도 입력하지 않았지만 "Motor_01은 설비에도 속한다" 는 결론이 나옵니다. 그래서 '설비 전체'를 조회해도 이 모터가 빠지지 않습니다.

추론은 모델에 적은 의미 안에서만 결론을 냅니다. "센서값이 높으니 다음 주에 고장 날 확률이 높다"는 추론이 아니라 별도 예측 모델의 몫입니다.

SPARQL: 그래프 패턴으로 질문한다

SQL과 비슷한 역할입니다. "95도를 넘은 관측이 있는 모터와 그 정비일지를 찾아라"를 그래프 패턴으로 적으면, 빈칸(?변수)에 맞는 값을 그래프에서 찾아 Motor_01, 98도, 측정 시각, Report_12를 돌려줍니다.

이런 질문을 하려면 온도값에 무엇을 쟀는지, 단위, 시각이 함께 있어야 합니다. 그래서 측정 하나하나를 "관측"이라는 개체로 만들고, SSN/SOSA 같은 표준으로 센서·관측 대상·결과·시간을 구분합니다. 초당 수천 건의 원시 시계열은 보통 기존 시계열 저장소에 두고, 그래프에는 센서·설비·관측 요약과 원본 위치만 연결합니다.

관계를 여러 번 따라가는 것은 추론이 아니라 다중 홉 조회입니다. 추론은 적혀 있지 않은 사실을 공리로부터 도출하는 것입니다.

SHACL: 정한 조건을 지키는지 검사한다

"모든 관측에는 측정 시각과 단위가 최소 하나씩 있어야 한다"는 shape를 정해 두면, 측정 시각이 없는 관측을 위반으로 보고합니다. DB의 NOT NULL과 비슷하지만, "모든 센서는 정확히 하나의 설비를 관측해야 한다"처럼 관계를 따라가는 조건도 표준 문법으로 적을 수 있습니다. SHACL은 보고만 하고, 막을지·보류할지·경고만 할지는 데이터 처리 흐름에서 정합니다.

개방 세계 가정과 SHACL

처음에는 "개방 세계 가정(OWA)과 폐쇄 세계 가정(CWA) 중 하나를 골라야 한다"고 이해했는데, 정확하지 않았습니다.

• OWL은 OWA를 따릅니다. 교정일이 기록되지 않았다고 "교정하지 않았다"가 아니라 "모른다"고 봅니다. 여러 시스템을 합칠 때는 한 곳에 없는 정보가 다른 곳에 있을 수 있어 이쪽이 안전합니다.
• 업무상 "분석용 센서는 교정일이 반드시 있어야 한다"는 요구는 SHACL로 입력 데이터를 검증하는 문제입니다.
• SHACL을 쓴다고 OWL의 의미 체계가 폐쇄 세계로 바뀌지는 않습니다. 둘을 함께 씁니다.

그리고 검증을 통과했다는 건 정한 조건을 지켰다는 뜻일 뿐, 값이 맞다는 뜻은 아닙니다. 형식은 맞지만 센서 고장으로 틀린 값일 수도 있습니다.

같은 "판단"처럼 보여도 성격이 다르다

온톨로지는 이 중 대상·근거·관련 문서를 일관되게 연결하는 기반이고, "점검이 필요한가"를 판단하거나 설비를 멈추는 일은 다른 구성요소가 맡습니다. 이 표가 이번 조사에서 가장 정리할 가치가 있었던 부분입니다.

데이터를 연결할 때 지킬 것

모델보다 먼저 정해야 하는 건 시간과 식별자였습니다.

• ID 대응에는 근거와 유효기간을 남긴다. 이름이나 위치가 비슷하다는 이유만으로 다른 설비를 같은 개체로 합치면 이력이 섞입니다. 후보는 자동으로 찾아도 확정은 사람이 검토합니다. 같은 대상의 다른 이름은 skos:prefLabel/altLabel로, 다른 데이터의 같은 대상은 owl:sameAs로 연결합니다.
• 측정 시각과 수집 시각을 구분한다. 지연 도착 데이터에서 무엇을 최신으로 볼지 정해야 합니다.
• 관계에도 시점을 둔다. 센서를 다른 설비로 옮기면 부착 관계에 시작·종료 시점을 기록해, 과거 관측은 당시 설비에 연결합니다.
• 추정은 추정으로 저장한다. 문서에서 추출한 "이상 추정"은 원문·작성자·검토 상태와 함께 둡니다.

품질 검사도 층을 나눠서 합니다.

온톨로지, 매핑 규칙, SHACL shape, CQ 질의, 정답 데이터, 추론 설정은 한 버전으로 묶어 관리합니다.

작게 시작해서 비교하기

라인 하나나 설비군 하나로 범위를 좁혀 설비 마스터 · 센서 관측 · 정비일지를 연결하는 소규모 실증이 현실적인 출발점이라고 생각합니다. 평가는 이렇게 합니다.

일부 질문은 SQL로도 충분히 답할 수 있습니다. 그래서 같은 질문을 기존 방식(SQL, 문서 검색)과 온톨로지 방식으로 답해 보고 비교하는 것이 중요합니다. 온톨로지의 가치는 "같은 질문을 풀 수 있는가"보다 시스템 간 의미 재사용, 출처 추적, 변경 대응에서 드러난다고 생각합니다. 그리고 LLM 질의응답(RAG·GraphRAG)을 얹는다면 근거 없는 주장 비율, 인용 적합성, 답할 수 없는 질문의 처리를 따로 평가해야 합니다(rag-evaluation-ragas-deepeval).

자산 단위의 디지털 트윈 표준인 AAS와 온톨로지가 만나는 지점은 aas-and-opc-ua에서 다룹니다.

참조

• W3C RDF 1.1 Concepts
• W3C OWL 2 Overview · OWL 2 Primer
• W3C SPARQL 1.1 Query
• W3C SHACL
• W3C SSN/SOSA
• OOPS! (Ontology Pitfall Scanner)
• neosemantics (Neo4j Labs)