Taxonomy부터 Context Graph까지: AI 데이터 기반 다섯 층의 차이와 쌓는 순서

Taxonomy, ontology, knowledge graph, semantic layer, context graph는 차례로 쌓는 다섯 층이고 층마다 답하는 질문이 다릅니다. 에이전트에 맥락을 주려면 맨 위 context graph보다 그 밑의 ontology부터 단단히 해야 합니다. 여러 나라에 파는 회사는 번역어 대신 시장마다 개념 노드를 따로 둬야 합니다.

요약

Julia Díez는 2026년 8월 22일 Substack ‘Elsewhere’에 AI 팀과 현지화(localization) 팀을 위한 용어 정리를 올렸습니다. 다섯 용어는 섞여 쓰이지만 각자 다른 질문에 답한다는 것이 출발점입니다. Taxonomy(분류 체계)는 무엇이 무엇의 한 종류인지, ontology(온톨로지)는 개념에 무엇이 참이고 개념끼리 어떻게 이어지는지 답합니다. Knowledge graph(지식 그래프)는 그 규칙에 맞는 실제 대상을 담습니다. Semantic layer(시맨틱 레이어)는 그 참을 도구마다 어떤 정의로 보여 줄지, context graph(컨텍스트 그래프)는 지금 이 과업에 무엇이 필요한지를 맡습니다. 저자는 러닝화 한 품목으로 다섯 층을 팀이 보통 만드는 순서대로 올립니다.

다섯 용어는 같은 것의 다른 이름이 아닙니다. 층마다 답하는 질문이 다릅니다.

저자가 경계하는 것은 혼동의 비용입니다. Knowledge graph가 필요한데 taxonomy를 만들거나 태그를 모은 스프레드시트를 ontology라고 부르게 됩니다. 순서 규칙도 하나 있습니다. 각 층은 앞 층이 단단해야 섭니다. 약한 ontology 위의 context graph는 틀린 조각을 빠르고 자신 있게 조립합니다. 여러 시장에 파는 회사는 개념을 언어가 아니라 시장 단위로 나눠야 합니다. 이 층이 틀리면 하류가 아무리 정교해도 모든 시장에서 현지 언어로 틀린 답이 나옵니다. 아래에서는 층마다 작동 방식을 부품·설비·협력사 가상 예시로 풀고 저장 형식, 검증 방법, 4주 층 진단 계획을 덧붙였습니다.

팀이 보통 만드는 순서입니다. 앞 층이 약하면 뒤 층은 틀린 답을 자신 있게 냅니다.

핵심 메커니즘

Taxonomy: ‘무엇의 한 종류인가’만 답하는 분류 트리

범주를 부모, 자식, 형제로 늘어놓은 계층입니다. is-a(~의 한 종류) 관계 하나로만 이어져 사람이 훑어 찾기 쉽습니다. 그래서 이커머스 메뉴와 콘텐츠 태깅의 뼈대가 됩니다. 경쟁, 구성품, 규제처럼 계층이 아닌 관계는 담지 못합니다. 이런 관계를 트리에 끼우면 도메인이 실제와 다르게 그려집니다. 원문의 예는 러닝화 → 신발 → 의류입니다.

작은 예시(가상). ‘깊은 홈 볼베어링 → 볼베어링 → 베어링 → 기계 요소’는 taxonomy로 충분합니다. 하지만 ‘프레스 PR-07의 구성품이다’, ‘협력사 A만 공급한다’는 트리에 넣을 자리가 없습니다.

가상 예시. 품목 분류는 is-a 트리로 충분하지만 구성 관계와 공급 관계는 넣을 자리가 없습니다.

Ontology: 개념의 속성·관계·금지 규칙을 정한 도메인 모델

Taxonomy에 여러 관계 유형과 무엇이 허용되는지에 대한 형식 규칙을 더한 것입니다. 개념, 속성, 제약을 특정 데이터셋이나 언어와 떼어 적으므로 사람과 기계가 같은 규칙으로 추론합니다. 한 번 정의한 개념은 하류 시스템이 물려받습니다. 저자가 이 층을 semantic governance(개념 정의를 한곳에서 관리하는 일)의 자리로 보는 이유입니다. 원문에서 러닝화는 size 속성이 필수이고 특정 양말 소재와 호환되며 brand가 제조합니다. 배타적인 두 범주에 동시에 속할 수도 없습니다.

작은 예시(가상). 부품에는 도면번호가 반드시 있어야 합니다. 부품은 설비의 구성품이 되고 협력사가 공급하며 양산과 단종 상태에 동시에 있을 수 없습니다. 이런 규칙을 개념 수준에서 정합니다. 개별 부품 데이터는 아직 없습니다.

가상 예시. 관계 유형과 금지 규칙을 개념 수준에서 정하면 아래 시스템이 같은 규칙을 물려받습니다.

Knowledge Graph: ontology에 실제 대상을 채운 그래프

하나 이상의 ontology를 실제 인스턴스로 채운 것입니다. Ontology가 ‘제품에는 제조사가 있다’고 정하면 그래프는 ‘SKU 4471(러닝화)의 제조사는 Brooks’라고 적습니다. 스키마가 의미를 담고 있어 관계와 제약이 데이터와 함께 남습니다. 그래서 관계를 따라가는 traversal(순회)로 미리 프로그래밍하지 않은 질문에 답합니다. 원문의 질문은 ‘Brooks가 만들고 트레일 조건에 맞으며 지금 EU에서 살 수 없는 것’입니다. 순회의 품질은 밑에 깔린 ontology를 넘지 못합니다.

작은 예시(가상). ‘PR-07에 들어가는 부품 중 공급사가 한 곳뿐이고 그 공급사가 지난 분기 납기를 두 번 넘긴 것’은 BOM, 협력사 마스터, 입고 이력을 이은 그래프에서 관계를 세 번 따라가면 나옵니다. 이 질문용 리포트를 따로 만들 필요가 없습니다.

가상 예시. 관계를 세 번 따라가면 미리 짜 두지 않은 질문에도 답이 나옵니다.

Semantic Layer: 같은 정의를 모든 도구에 내보내는 인터페이스

데이터 모델과 그것을 쓰는 앱 사이의 층입니다. ‘revenue’가 어디서나 같은 식으로 계산되도록 정의를 노출해 도구끼리 숫자가 어긋나지 않게 합니다. 저자의 구분으로 ontology는 무엇이 참인지 정하고 semantic layer는 그 참을 소비자마다 각자의 용어로 어떻게 보여 줄지 정합니다. 진실의 원천이 아니라 인터페이스입니다.

작은 예시(가상). 구매팀 대시보드는 ‘납기 준수율’을 확약 납기일로, 협력사 포털은 최초 요청일로 계산해 숫자가 다릅니다. 계산식을 semantic layer에 하나만 두고 모든 소비자가 그 식을 부르면 숫자가 맞습니다. 실제 기업 사례는 Morgan Stanley Wealth Semantic Layer 노트를 보면 됩니다.

가상 예시. 계산식을 한곳에 두고 세 소비자가 같은 식을 부르면 숫자가 어긋나지 않습니다.

Context Graph: 지금 이 과업을 위해 잠깐 조립하는 조각

다섯 가운데 가장 새롭고 표준이 덜 잡혔으며 AI 시스템에 가장 특화된 층입니다. 특정 과업, 사용자, 순간에 필요한 엔터티와 관계와 상태를 knowledge graph, semantic layer, 최근 상호작용, 실시간 데이터에서 골라 조립합니다. 과업이 끝나면 버리거나 다시 만듭니다. 저자는 ontology와 knowledge graph를 장기 기억에, context graph를 attention(주의)에 빗댑니다.

작은 예시(가상). 정비 에이전트가 ‘PR-07 이상 진동’ 신고를 받으면 PR-07 구성품, 최근 90일 정비 이력, 진동 센서 값, 대체 부품 재고만 모아 작업 맥락을 만듭니다. 작업 지시가 닫히면 이 조각을 버립니다.

가상 예시. 장기 기억(KG)에서 이번 과업에 필요한 조각만 꺼내 쓰고 끝나면 버립니다.

쌓는 순서: 앞 층이 단단해야 다음 층이 선다

순서는 분류, 의미와 관계 정의, 인스턴스 채우기, 도구에 정의 노출, 과업 맥락 조립입니다. 각 층은 앞 층이 탄탄할 때만 제대로 작동합니다. 맨 위 층이 에이전트와 가까워 눈에 띄지만 정확도는 아래 층이 정합니다.

작은 예시(가상). Ontology에 양산과 단종을 배타 관계로 정하지 않으면 두 상태가 함께 붙은 부품이 생깁니다. 이 단종 부품이 정비 에이전트의 맥락에 대체품 후보로 들어가고 에이전트는 거리낌 없이 발주를 추천합니다.

층이 올라갈수록 아래 층 전부에 기댑니다. 강조한 Ontology 층의 품질이 위 세 층의 정확도를 정합니다.

Multi-market: 언어가 아니라 시장마다 개념 노드를 둔다

여러 시장에 파는 회사의 ontology에는 언어별 번역어가 아니라 시장별 노드가 필요하다는 주장입니다. 같은 제품도 지역에 따라 팔 수 없거나, 다르게 포지셔닝되거나, 속성이 다릅니다. 미국 ontology의 러닝화에 있는 widths 속성이 EU 인스턴스에는 없을 수 있습니다. 보충제가 한 시장에서는 웰니스 제품이고 다른 시장에서는 규제 의약품이라면 제약, 판매 가능 여부, 컴플라이언스 경로가 다른 별도 노드가 되고 부모 개념만 공유합니다. 저자는 이것이 “not a translation problem at all”이라고 못 박습니다.

작은 예시(가상). 같은 산업용 제어 모듈이 시장 A에서는 일반 부품이고 시장 B에서는 수출 허가 품목이라면, 공통 부모 아래 시장별 노드를 두고 노드마다 판매 가능 여부와 허가 경로를 답니다.

가상 예시. 시장마다 판매 가능 여부와 규제 경로가 다르면 노드를 나눕니다.

통념과 다른 주장

흔히 이렇게 봅니다Ontology, knowledge graph, semantic layer는 대체로 같은 말이고 태그를 정리한 스프레드시트도 ontology라고 부를 수 있다고 봅니다.

저자는 이렇게 봅니다다섯 용어는 서로 다른 질문에 답하는 다른 층입니다. 이름을 섞어 쓰면 필요한 층 대신 엉뚱한 층을 만들게 됩니다.

근거Taxonomy는 is-a 관계만 담아 '경쟁한다', '구성품이다', '규제를 받는다' 같은 관계를 표현하지 못합니다.

이름을 섞어 쓰면 필요한 것과 다른 층을 만들게 됩니다.

흔히 이렇게 봅니다Semantic layer에 지표를 모아 두면 그곳이 회사의 단일 진실 원천이 된다고 봅니다.

저자는 이렇게 봅니다무엇이 참인지는 ontology가 정합니다. Semantic layer는 그 참을 소비자마다 각자의 용어로 보여 주는 인터페이스입니다.

근거저자는 참을 정의하는 층과 참을 보여 주는 방식을 정의하는 층을 나눕니다. 보여 주는 층이 부실하면 두 대시보드가 같은 지표에 다른 숫자를 낸다고 설명합니다.

참을 정하는 층과 참을 보여 주는 층을 나눠 봅니다.

흔히 이렇게 봅니다해외 시장으로 넓힐 때는 용어와 라벨을 현지어로 옮기면 된다고 봅니다.

저자는 이렇게 봅니다시장마다 개념 노드가 따로 필요합니다. 시장에 따라 판매 가능 여부, 속성, 규제 지위가 달라집니다.

근거미국 러닝화의 widths 속성이 EU 인스턴스에는 없을 수 있습니다. 보충제는 시장에 따라 웰니스 제품이 되기도 하고 규제 의약품이 되기도 합니다.

언어가 아니라 시장이 노드를 가르는 기준입니다.

저자가 든 사례

저자는 특정 기업의 도입 사례 대신 설명용 예시를 씁니다. 예시는 세 갈래로 묶입니다.

러닝화 한 품목으로 올린 세 층

상황: 러닝화 한 품목을 세 층으로 설명합니다.
한 일: 분류 트리, 속성·관계 규칙, SKU 4471의 제조사 Brooks를 차례로 쌓습니다.
결과: 미리 짜 두지 않은 질문에 순회로 답합니다. 효과 수치는 원문에서 밝히지 않음.
연결: Taxonomy, Ontology, Knowledge Graph.

같은 품목이 층을 올라갈수록 답할 수 있는 질문이 늘어납니다. 효과 수치는 원문에서 밝히지 않음.

두 대시보드와 revenue

상황: 여러 도구가 같은 데이터를 조회합니다.
한 일: ‘revenue’ 정의를 semantic layer가 한 계산으로 노출합니다.
결과: 도구끼리 숫자가 같아집니다. 부실하면 두 대시보드의 숫자가 갈립니다.
연결: Semantic Layer, 두 번째 통념.

부실한 semantic layer는 같은 지표에 두 숫자를 만듭니다. 효과 수치는 원문에서 밝히지 않음.

시장마다 달라지는 러닝화와 보충제

상황: 같은 품목이 시장에 따라 속성과 규제 지위가 다릅니다.
한 일: widths 속성은 미국 쪽에만 두고 보충제는 시장별 별도 노드로 나눕니다.
결과: 노드마다 제약, 판매 가능 여부, 컴플라이언스 경로가 따로 붙습니다.
연결: Multi-market, 세 번째 통념.

러닝화는 속성이, 보충제는 규제 지위가 시장마다 달라집니다.

기술 디테일: 다섯 층을 실제로 저장하고 시험하려면

원문에 없는 실행 방법을 AX Review가 새로 짰습니다. SKOS, OWL 2, SHACL, RDF는 W3C 표준에서 가져온 이름이고 원문에는 나오지 않습니다. 숫자 설정은 모두 가상 예시입니다.

층마다 저장 형식을 따로 고릅니다(다섯 층 전체). Taxonomy는 W3C SKOS로 적어 broader·narrower로 계층을 잇고 prefLabel·altLabel에 언어 태그를 붙입니다. Ontology는 OWL 2로 클래스와 관계를 정하고(배타 범주는 owl:disjointWith) 데이터가 규칙을 지키는지는 SHACL로 검사합니다. Knowledge graph는 RDF 저장소나 property graph DB에 두고 인스턴스마다 ID, 출처 시스템(ERP, MES 등), 갱신 시각을 남깁니다. Semantic layer는 지표 정의 파일(YAML 등)로, context graph는 과업별 JSON 조각으로 둡니다.

실제로 돌릴 때 쓰는 형식의 예입니다. W3C 표준과 일반 관행에서 가져왔으며 원문에 나오는 이름은 아닙니다.

Ontology 규칙은 검증 게이트로 돌립니다(Ontology, 쌓는 순서). 규칙을 SHACL로 적어 매일 밤 그래프 전체를 검사합니다. 위반이 남은 노드는 context graph 조립에서 뺍니다. 약한 ontology가 틀린 맥락을 만드는 경로를 여기서 끊습니다.

ex:PartShape a sh:NodeShape ;
  sh:targetClass ex:Part ;
  sh:property [ sh:path ex:drawingNo ; sh:minCount 1 ; sh:datatype xsd:string ] ;
  sh:property [ sh:path ex:suppliedBy ; sh:minCount 1 ; sh:class ex:Supplier ] .
ex:InProduction owl:disjointWith ex:Discontinued .

규칙 초안은 LLM으로 뽑습니다. 품목 기준서, 설비 대장, 구매 규정을 넣고 temperature 0으로 개념·부모·관계·근거 문서를 JSON으로 받습니다. 같은 입력으로 3회 돌려 3회 모두 나온 후보만 검토 목록에 올리고 도메인 전문가가 인증한 것만 규칙으로 씁니다. 이 초안·인증 흐름을 도구로 묶은 예는 Agent Knowledge Foundation 노트에 있습니다.

가상 예시 설정. 규칙 위반이 남은 노드는 에이전트 맥락에 들어가지 못하게 막습니다.

Knowledge graph와 semantic layer는 정답과 대조합니다(Knowledge Graph, Semantic Layer). 현업이 실제로 묻는 관계형 질문 20개마다 정답 노드 목록을 사람이 먼저 적습니다. 그래프 질의 결과와 비교해 누락과 오답을 셉니다. 누락은 대개 관계 누락이나 협력사 중복 코드에서, 오답은 느슨한 ontology 규칙에서 나옵니다. 지표 정의 파일에는 metric_id, 계산식, 분자와 분모, 기준일 필드, 담당 부서, 버전을 적습니다. 그리고 같은 기간 값을 대시보드·포털·에이전트에서 각각 뽑아 같은지 봅니다.

Context graph는 조립 규칙을 고정해 재현성을 봅니다(Context Graph, Multi-market). 작업 지시의 설비를 seed(출발 노드)로 삼습니다. 과업 유형마다 허용 관계를 정하고 최대 2홉, 노드 50개 상한을 둡니다. 사용자의 시장으로 먼저 거른 뒤 관계를 따라갑니다. SKOS의 prefLabel@ko·@en은 이름만 바꾸므로 시장 차이는 market, saleable, compliance_path를 단 시장별 노드로 표현합니다. 같은 입력으로 3회 조립해 노드 집합이 같은지 확인합니다. 조각은 작업이 끝나면 버리되 쓴 노드 ID와 규칙 버전은 로그로 남깁니다.

{
  "task_id": "WO-2026-1103-017",
  "task_type": "이상 진동 원인 추정",
  "seed": "equip:PR-07",
  "allowed_relations": ["hasComponent", "maintenanceLog", "stockOf"],
  "max_hops": 2,
  "node_limit": 50,
  "market": "KR",
  "nodes": ["equip:PR-07", "part:P-2210", "log:M-8812", "stock:P-2210-ALT"],
  "live": {"vibration_rms_mm_s": 7.4, "read_at": "2026-11-03T09:12:00+09:00"},
  "excluded_by_shacl": ["part:P-1907"],
  "rule_version": "ont-v0.3",
  "expires": "on_work_order_close"
}

가상 예시 설정. 홉 수와 노드 상한을 정해 두면 같은 입력에 같은 조각이 나오는지 시험할 수 있습니다.

현업 실행 디테일: 누가, 언제, 무엇을

역할	담당	4주 동안 하는 일
스폰서	대상 도메인 임원(예: 생산·정비 총괄)	범위와 판정 기준 승인, 4주차 판정 회의 주재
도메인 전문가	현업 2명(정비 자재, 구매)	개념·관계 규칙 인증, 순회 질문 20개와 정답 작성
데이터 아키텍트	1명	층별 저장 형식 결정, SHACL 검증과 조립 규칙 구현
데이터 스튜어드	MDM 담당 1명	품목·협력사 마스터의 중복 코드 정리, 동의어 목록
BI 담당	1명	지표 정의 파일 작성, 도구 간 대조 시험
법무·수출 관리	1명(다시장 판매 시)	시장별 판매 가능 여부와 허가 경로 확인
AX 추진	PM 1명	일정, 결과 집계, 판정 보고서

시작 전 준비물: 품목 분류 체계, 품목·협력사·설비 마스터, 대상 설비 BOM, 최근 6개월 입고·정비 이력, 지표 정의서, 에이전트에 넣는 맥락 자료, 시장별 판매 제한 목록.

첫 주에는 가진 자산이 실제로 어느 층인지 매핑합니다.

회사가 가진 것(예)	실제 층	확인 질문
품목 분류 코드 체계	Taxonomy	is-a 말고 다른 관계가 있는가
MDM 품목 마스터와 필수 속성 규칙	Ontology 일부	관계 규칙과 배타 규칙이 적혀 있는가
BOM, 설비 대장, 협력사 마스터를 잇는 키	Knowledge graph 후보	시스템을 넘어 관계를 따라갈 수 있는가
BI 지표 정의서	Semantic layer	모든 도구가 같은 정의 파일을 부르는가
에이전트 프롬프트에 붙이는 자료	Context graph	과업마다 규칙대로 조립하고 버리는가

주차	할 일	산출물
1주	한 도메인 확정, 자산을 다섯 층에 매핑, 순회 질문 20개 작성	층 진단표, 질문 세트
2주	개념·관계·금지 규칙 20개 초안과 인증, SHACL로 작성	인증 규칙 목록, 첫 위반 보고서
3주	마스터를 이어 그래프 적재, 순회 질문 시험, 지표 대조 시험	누락·오답 표, 지표 차이 목록
4주	과업 하나의 context graph 조립 시연, 재현성 시험, 판정 회의	조립 로그, 판정 보고서

가상 예시 일정. 한 도메인(예: 정비 자재)으로 범위를 좁혀 시작합니다.

도메인 전문가에게 물을 것.

이 품목은 ‘무엇의 한 종류인가’ 말고 어떤 관계로 다른 대상과 이어집니까? (구성품, 공급, 대체, 규제)
동시에 성립하면 안 되는 상태나 범주는 무엇입니까? (양산과 단종, 승인과 반려)
같은 협력사나 품목이 시스템마다 다른 코드로 들어가 있습니까?
이름은 같은데 화면마다 숫자가 다른 지표는 무엇이고 기준일은 어느 날짜입니까?
시장에 따라 팔 수 없거나 속성이 달라지는 품목은 무엇입니까?

진행 판정 기준(예시). 네 조건을 모두 채우면 에이전트 연결 단계로 넘어갑니다. SHACL 위반이 대상 노드의 1% 미만, 순회 질문 20개 중 17개 이상 정답, 대조한 지표가 모든 도구에서 같음, 같은 과업을 3회 조립했을 때 노드 집합이 같음. 순회 정답이 14개에 못 미치면 context graph 작업을 멈추고 ontology 규칙과 마스터 중복부터 다시 봅니다. 기준은 시험 전에 정합니다.

AX 적용 제언. 제조 고객사의 에이전트 과제는 대개 맨 위 층에서 시작합니다. 프롬프트에 BOM 일부와 정비 매뉴얼을 붙이는 식인데, 이 글의 틀로 보면 규칙 없이 조립한 context graph입니다. 첫 과제는 에이전트 만들기보다 한 도메인의 층 진단과 ontology 규칙 인증으로 잡는 편이 맞습니다. 품목 분류와 MDM은 대개 있으니 흔히 비는 곳은 관계 규칙과 시스템을 잇는 그래프입니다. 해외 법인이나 수출 품목이 있으면 2주차에 시장별 노드를 함께 설계합니다. 나중에 라벨로 덧대면 모든 시장의 답이 함께 틀어집니다.

원문 사례

항목	내용
글	Julia Díez, ‘Ontology vs. Taxonomy vs. Knowledge Graph vs. Semantic Layer vs. Context Graph’, Substack ‘Elsewhere’, 2026.08.22
부제 · 대상	AI 팀과 현지화 팀을 위한 정리
핵심 주장	다섯 용어는 각자 다른 질문에 답하는 층이며 팀이 보통 만드는 순서로 쌓임. 각 층은 앞 층이 탄탄해야 함
Taxonomy 예	러닝화 → 신발 → 의류. 이커머스 메뉴와 콘텐츠 태깅에 씀
Ontology 예	러닝화는 size 필수, 특정 양말 소재와 호환, brand가 제조, 배타 범주 동시 소속 불가
Knowledge graph 예	SKU 4471(러닝화)의 제조사 Brooks. Brooks 제품 중 트레일 조건에 맞고 EU에서 구매 불가한 것을 순회로 찾음
Semantic layer 예	‘revenue’를 어디서나 같은 계산으로 노출. 부실하면 두 대시보드가 다른 숫자
Context graph	과업·사용자·순간별 동적 조각. 재료는 KG, semantic layer, 최근 상호작용, 실시간 데이터. 장기 기억 대 attention 비유
다시장 예	미국 러닝화의 widths 속성이 EU에는 없을 수 있음. 보충제는 시장에 따라 웰니스 제품 또는 규제 의약품, 부모 개념만 공유하는 별도 노드
수치 · 기업 사례	SKU 4471 외 수치 없음. 특정 기업 도입 사례 없음

핵심 개념

is-a 관계: 'A는 B의 한 종류다'를 뜻하는 관계. Taxonomy가 담는 유일한 관계.
traversal: 그래프에서 관계를 한 칸씩 따라가며 조건에 맞는 노드를 찾는 질의 방식.
semantic governance: 개념의 정의와 규칙을 한곳에서 관리해 모든 하류 시스템이 같은 정의를 쓰게 하는 일.
배타 범주: 한 대상이 동시에 속할 수 없는 두 범주. OWL에서는 disjointWith로 적음.
부모 개념: 시장별 노드가 함께 기대는 상위 개념. 공통 속성은 여기에, 시장별 차이는 하위 노드에 둠.
seed: context graph를 조립할 때 출발점이 되는 노드. 보통 과업의 대상(설비, 주문, 고객).

내 메모

TODO: 내 생각 추가

원문: Julia Díez, 「Ontology vs. Taxonomy vs. Knowledge Graph vs. Semantic Layer vs. Context Graph」(Substack ‘Elsewhere’, 2026.08.22). 요약, 핵심 메커니즘의 원문 예, 통념과 다른 주장, 저자가 든 사례, 원문 사례 표는 저자가 언급한 내용을 AX Review가 다시 정리했습니다. 핵심 메커니즘의 작은 예시(부품, 설비 PR-07, 협력사 A, 제어 모듈)는 가상 예시입니다. 기술·현업 실행 디테일, Turtle·JSON 예시, 층 진단표, 일정, 질문, 판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했습니다. 저장 형식은 원문이 아닌 W3C 표준 문서로 보강했습니다.

1차 출처: SKOS Simple Knowledge Organization System Reference(W3C Recommendation, 2009), OWL 2 Web Ontology Language Document Overview(W3C Recommendation, 2009, Second Edition 2012), Shapes Constraint Language SHACL(W3C Recommendation, 2017), RDF 1.1 Concepts and Abstract Syntax(W3C Recommendation, 2014). 전체 내용은 원문에서 볼 수 있습니다.