온톨로지·지식그래프와 조경의 규칙

1단위. 같은 대상을 같은 의미로 읽기

8.1 이름을 맞추는 것에서 개념을 정의하는 것으로

설계 파일에는 ‘교목’, 수량표에는 ‘수목’, 조사표에는 ‘느티나무’가 적혀 있을 수 있다. 세 표현은 일부 대상에서 겹치지만 같은 뜻은 아니다. 수목이라는 넓은 범주, 형태에 따른 범주, 수종 이름을 모두 하나의 코드로 바꾸면 구분이 사라진다. 자동 분류와 검토를 하려면 단어를 통일하는 것뿐 아니라 단어 사이의 의미를 정리해야 한다.

통제어휘는 사용할 용어와 표기 규칙을 정한 목록이다. 분류체계는 대상을 일정한 기준으로 나누고 범주 사이의 구조를 만든다. **온톨로지(ontology)**는 다루는 영역의 개념·속성·관계와 그 의미를 명시한 모델이다. **지식그래프(knowledge graph)**는 그 의미를 바탕으로 개별 대상과 사실·주장을 관계로 연결한 자료다. 온톨로지는 질문에 필요한 의미 구조를, 지식그래프는 그 구조에 들어가는 개별 기록을 중심으로 이해하면 좋다.

전통적인 시방서 목차와 수목 대장은 이미 용어를 정리하는 역할을 했다. 디지털 의미 모델은 여러 문서와 프로그램이 그 구분을 함께 사용하도록 만든다. 단순 수량 집계만 필요하면 잘 정리한 표와 코드 사전이 충분할 수 있다. 문서마다 다른 이름을 연결하고, 객체–작업–근거–검측을 가로질러 질문해야 할 때 관계 구조의 가치가 커진다.

SKOS는 대표 이름·다른 이름, 넓은 개념·좁은 개념 등의 관계로 어휘체계를 표현하는 방법이다. ‘상위 개념’ 관계와 생물학적 분류, 부품 관계를 무조건 같은 것으로 만들지 않는 것이 중요하다. W3C: SKOS Primer

8.2 클래스·개체·속성과 관계

**클래스(class)**는 공통 조건으로 묶은 대상의 종류이고, **개체(instance)**는 그 종류에 속하는 특정 대상이다. ‘수목’은 클래스이고 D03의 TREE-017은 개체다. ‘수종’과 ‘규격’은 그 수목을 설명하는 속성이다. 수종 이름과 규격 값은 클래스의 이름을 대신하지 않는다.

관계는 두 대상을 연결한다. ‘수목이 구역에 속한다’, ‘식재 작업이 수목을 대상으로 한다’, ‘검측 기록이 작업을 확인한다’처럼 방향과 의미를 정한다. ‘수목의 부분인 가지’와 ‘구역에 있는 수목’은 모두 포함처럼 보이지만 관계가 다르다. 부분 관계를 공간 포함 관계로 바꾸면 수목을 이동할 때 가지의 소속까지 잘못 해석할 수 있다.

ID는 화면에 보이는 이름과 분리한다. 이름이 바뀌어도 같은 객체의 과거 기록을 따라갈 수 있어야 한다. 반대로 교체한 수목이 같은 자리에 심어졌다면 이전 개체와 새 개체를 어떻게 구분할지 자산 식별 정책이 필요하다. 위치나 수종이 같다는 것만으로 같은 개체라고 결정하지 않는다.

2단위. 사실을 연결하고 조건을 검사하기

8.3 RDF와 OWL의 기본 역할

RDF는 정보를 주어–술어–목적어의 세 항목으로 표현한다. 이 세 항목을 **트리플(triple)**이라고 한다. 조경의 예로 ‘TREE-017 — 유형 — 수목’, ‘관측 A — 대상 후보 — TREE-017’처럼 쓸 수 있다. 같은 ID가 여러 문장의 주어나 목적어로 등장하면서 기록이 연결된다. 다음은 문법을 익히기 위한 코드가 아니라 의미를 보여주는 자체 표다. W3C: RDF 트리플

면적을 별도 기록으로 만든 이유는 숫자에 단위와 버전, 설계·관측 구분을 붙이기 위해서다. 모든 속성을 이렇게 복잡하게 만들 필요는 없지만, 검토의 근거가 되는 양에는 출처를 따라갈 구조가 필요하다. ‘60’이라는 숫자만으로는 어떤 면적이며 언제의 값인지 알 수 없다.

OWL은 클래스와 관계의 의미를 논리적으로 기술하는 언어다. 예를 들어 정한 모델에서 교목을 수목의 하위 클래스로 선언하고 어떤 개체를 교목으로 기록했다면, 그 개체가 수목에도 속한다는 결론을 추론할 수 있다. 이 추론은 입력한 의미와 사실을 따른 것이며 현장에서 나무를 새로 발견한 것은 아니다.

OWL의 개방세계 가정에서는 기록되지 않은 사실이 곧 거짓이라는 뜻이 아니다. 수종 정보가 없으면 수종이 없는 나무라고 단정하지 않는다. 이 원리는 자료가 부분적으로 연결되는 환경에 적합하지만, 필수 필드 누락을 검사하는 업무와는 역할이 다르다. W3C: OWL과 개방세계

8.4 의미 추론과 자료 검증을 구별한다

**자료 검증(validation)**은 정한 요구 조건을 자료가 만족하는지 확인하는 과정이다. ‘이 단계의 수목 정보에는 규격 값과 단위가 있어야 한다’는 요구는 현장에 실제로 나무가 있는지를 추론하는 것과 다르다. 데이터 계약을 검사하는 질문이다.

SHACL은 RDF 자료가 특정 형태와 제약을 만족하는지 검사하고 결과를 보고하는 언어다. 필수 값의 수, 자료형, 허용 범위 등을 규칙으로 표현할 수 있다. 검증 결과에는 어떤 대상의 어느 속성이 어떤 조건에 맞지 않는지 남긴다. W3C: SHACL 검증과 보고

D03 집수정의 관저 표고는 미정이다. ‘관로 시공 검토에 들어가기 전에 관저 표고가 필요하다’는 자체 자료 요구를 적용하면 필요한 값이 없다고 보고할 수 있다. 이 결과를 실제 시공 불량으로 부르지 않는다. 아직 자료가 부족하여 해당 검토를 진행할 수 없다는 뜻이다. 설계 초기 단계에는 허용되는 미정 값도 시공 전 단계에서는 필수일 수 있으므로 적용 단계와 조건을 함께 둔다.

이 규칙을 기록한다면 이름은 “시공 전 관저 표고 준비”, 대상은 “관로 시공 검토 대상 집수정”, 요구는 “표고 값·단위·높이 기준 존재”, 결과는 “입력 준비/추가 조사 필요”가 된다. 이는 책에서 만든 자료 요구 예이며 법정 시공 기준을 인용한 것이 아니다.

숫자 크기 검증에는 단위가 전제된다. mm 값을 m로 해석한 상태에서 범위 검사를 통과시키지 않도록 변환과 검증의 순서를 정한다. 검증할 객체 범위가 비어 있으면 누락 자료가 있어도 검사 결과가 깨끗해 보일 수 있다. 실행 때는 대상 객체 수와 적용 규칙 수를 함께 보고한다.

규칙에 없던 문제가 남을 수 있으므로 ‘자료 규칙 통과’와 ‘설계 전체 적합’을 별도 상태로 기록한다.

3단위. 문헌과 시방에서 의미 모델을 만드는 과정

8.5 질문을 먼저 정하고 작은 범위에서 만든다

온톨로지 구축을 시작하며 조경의 모든 용어를 수집하면 분량만 커지고 어디에 쓸지 불분명해질 수 있다. 먼저 시스템이 답해야 할 질문을 정한다. 예를 들어 ‘이 식재 작업에 필요한 수목 규격이 모두 있는가’, ‘이 관측은 어느 설계 버전의 어느 객체와 비교했는가’처럼 입력과 출력이 분명한 질문을 둔다. 이를 온톨로지가 답할 수 있어야 하는 **역량 질문(competency question)**으로 활용할 수 있다.

다음은 자료의 권위와 적용 범위를 구분하는 일이다. 국가·기관 기준, 프로젝트 시방, 연구 논문, 제조사 설명은 서로 다른 성격을 가진다. 한 문서에서 제시한 실험 조건을 모든 수목의 시공 기준으로 올리지 않는다. 사용자가 제공한 조경시방서는 3장의 WBS 구성 근거이며, 이 장에서는 그 내용을 객체·작업·검측 항목에 연결하는 방법을 설명한다.

작은 범위에서 구축할 때는 다음 순서가 유용하다.

1. 질문에 필요한 자료와 해당 버전·적용 범위를 정한다.
2. 용어의 정의와 서로 다른 표기를 기록한다.
3. 클래스·속성·관계와 값의 단위를 구분한다.
4. D03의 소수 객체에 적용해 누락·모호함을 찾는다.
5. 질의와 자료 검증을 실행할 수 있는 형태로 구체화하고 검토 이력을 남긴다.

이는 정답 하나로 고정된 구축법이 아니라, 실제 질문에서 의미 모델이 작동하는지 확인하기 위한 편집·설계 절차다. 기존 표준의 이름을 그대로 가져오는 경우에도 적용 의미가 맞는지 확인하고, 원 표준 버전과 자체 확장 부분을 구별한다.

8.6 AI가 도울 수 있는 추출과 사람이 결정할 의미

디지털 문헌 수집은 검색식·수집 날짜·포함 기준을 기록하는 데서 시작한다. 같은 보고서의 복사본과 개정판을 구별하고, 문서 ID와 절·쪽 위치를 남긴다. 스캔 PDF에는 OCR이 필요할 수 있지만 표의 열이 섞이거나 단위가 빠질 수 있으므로 추출 결과를 원문과 대조한다. 2장의 사회분석에서 주민 발언을 구조화할 때도 같은 원칙이 적용된다.

AI는 용어 후보, 속성 후보, 관계 문장, 적용 조건을 추출하는 초안을 만들 수 있다. 그 결과는 ‘원문 위치 — 추출한 주장 — 조건 — 제안 관계 — 확인 상태’로 저장한다. 문서에 없는 적용 범위를 AI가 덧붙이거나, 권고를 의무로 바꾸지 않았는지 확인한다. 단순한 문장 요약보다 주장의 주체·조건·단위·근거 위치를 보존하는 구조화가 후속 검토에 유용하다.

자체 개념도. AI 추출 후보에서 검토한 의미 모델로 넘어가는 단계에는 사람의 의미 확인이 포함된다.

‘그늘이 부족하다’는 주민 의견을 예로 들어 보자. AI는 그늘·이용 시각·장소 등의 항목을 찾을 수 있지만, 이 의견을 곧바로 ‘모든 보행로의 그늘 비율을 특정 값 이상으로 한다’는 기준으로 바꿀 근거는 없다. 의견의 맥락을 보존하고, 현장 관측·설계 목표·합의 과정을 통해 검토 항목을 정한다. 디지털 분석이 사회적 판단을 지워서는 안 된다.

어느 방법이 최선인지는 질문에 달려 있다. 용어 검색이면 통제어휘, 표준 필드 검증이면 스키마·규칙, 여러 문서의 사실 연결이면 지식그래프가 적합할 수 있다. LLM이 생성한 온톨로지의 크기보다, 필요한 질문에 근거를 제시하며 답할 수 있는지를 평가한다. 자동화는 초안 추출과 반복 검사에 쓰고 의미를 확정한 책임과 버전은 별도로 기록한다.

4단위. 질의하고 근거를 따라가기

8.7 질문을 자료의 연결로 바꾸기

**질의(query)**는 자료에서 정한 조건에 맞는 항목과 관계를 찾는 요청이다. 관계형 데이터베이스의 표 연결과 마찬가지로, 지식그래프에서는 관계를 따라 패턴을 찾는다. SPARQL은 RDF 그래프에 이런 질의를 표현하는 언어다. 필수 관계와 선택적 관계를 구분할 수 있다. 예를 들어 표고가 없는 집수정도 목록에 남기려면 그 값이 없는 항목이 질의 과정에서 빠지지 않도록 구성한다. W3C: SPARQL의 선택적 값

조경의 질의를 세 종류로 나누어 보면 구현 역할이 분명해진다. ‘판석포장 객체를 찾아라’는 유형 검색이다. ‘그 객체를 대상으로 하는 작업과 검측 기록을 찾아라’는 관계 검색이다. ‘관로에서 특정 거리 안에 있는 수목을 찾아라’는 기하 계산을 포함한다. 마지막 질문은 의미 모델에 관계 이름을 만들었다고 거리가 자동 계산되는 것이 아니다. 좌표·기하 엔진과 연결하고 계산 결과와 조건을 저장해야 한다.

3장의 IFC에서 추출한 객체와 속성도 같은 방식으로 연결할 수 있다. IFC가 주는 정보, 자체 WBS 분류, 시방 근거, 관측 기록을 각자 보존하면서 공통 ID로 묶는다. 파일 형식을 하나로 강제하는 것보다, 원본과 변환 결과 사이 어떤 정보가 유지되는지 설명할 수 있는 것이 중요하다.

8.8 지식도 버전과 불확실성을 가진다

**출처·생성 이력(provenance)**은 자료나 주장이 어디서 나왔고 누가 어떤 활동으로 만들었는지 나타내는 정보다. W3C의 PROV-O는 자료·활동·행위자 등의 관계를 표현한다. 이 원고에서는 문서 버전, 추출 과정, 사람 검토와 결과 사이 연결을 설명하는 데 이 개념을 사용한다. W3C: PROV-O

시방 개정으로 요구 속성이 달라지면 이전 규칙을 삭제하지 않고 새 버전을 만든다. 진행 중인 프로젝트가 어느 규칙을 적용했는지도 남긴다. 새 규칙으로 검사했을 때 결과가 달라진 이유를 객체 변경과 규칙 변경으로 나누어 볼 수 있어야 한다.

문서끼리 주장이 다르면 하나를 조용히 덮어쓰지 않는다. 적용 지역·시기·대상·근거 수준이 다를 수 있다. ‘문헌 A에서 이런 조건을 보고했다’와 ‘현재 프로젝트가 이 기준을 채택했다’는 다른 관계다. 문헌에 등장한 사실을 프로젝트의 확정 속성으로 자동 승격하지 않는다.

온톨로지와 지식그래프가 준비되면 AI 검토는 근거를 찾고 결과를 설명하는 데 이 구조를 이용할 수 있다. 하지만 모든 판단을 논리 규칙으로 표현할 수 있는 것은 아니다. 경관 경험과 사회적 가치처럼 합의와 해석이 필요한 내용은 그 판단 과정 자체를 기록한다. 다음 9장은 관계의 패턴을 학습하는 GNN을 다루며, 의미를 명시하는 이 장의 규칙과 학습된 관계 특징을 구별한다.