RDF 파일 비교 검수: blank node 이름이 바뀌어도 같은 데이터일까

RDF 파일의 blank node 이름이 달라도 그래프는 같을 수 있습니다. 2026-11-02 기준, 업무 키의 동일성은 따로 검수합니다.

같은 자료를 내보냈는데 파일 비교 화면이 변경으로 가득한 상황을 가정해 보겠습니다. 차이가 임시 식별자의 재배정에서 생겼다면 모든 데이터를 갱신했다는 설명은 부정확합니다. 이 글은 가상 RDF 표본으로 파일 차이와 구조 변화의 인수 기준을 나눕니다.

무엇이 같아야 검수 통과인가요?#

납품 파일의 바이트, RDF 관계 구조, 원천 업무 개체 중 무엇을 비교할지 먼저 정합니다. 파일 보관 무결성을 확인하는 팀과 데이터 교환을 인수하는 팀은 서로 다른 증거가 필요합니다. 같은 조건의 기준을 아래처럼 나눌 수 있습니다.

이미 결정한 고객·품목의 중복 후보를 검토하는 문제라면 온톨로지 개체 해소와 공통 식별자 검수를 먼저 보세요. 스키마의 관계 정의를 바꾸고 복원하는 절차는 온톨로지 스키마 버전 관리에서 다룹니다. 여기서는 RDF 데이터 파일의 지역 식별자 비교에 집중합니다.

blank node 이름이 달라도 같은 구조일 수 있나요?#

blank node는 IRI로 이름을 붙이지 않은 노드입니다. 파일에 보이는 _:a 같은 식별자는 지역 범위의 표기이며, 교환 후에도 같은 업무 개체를 가리킨다는 영구 키가 아닙니다. W3C의 RDF 1.1 blank node 정의가 이 범위를 설명합니다. 2014-02-25 권고안, 확인일 2026-11-02입니다.

아래는 가상 주소 관계를 나타낸 별개의 N-Triples 문서입니다. 두 문서의 IRI와 문자열은 그대로이고, 문서 B는 blank node 이름과 줄 순서만 바꿨습니다. example.org는 설명용 주소입니다.

# 문서 A
<https://example.org/item/sample-a> <https://example.org/hasAddress> _:a .
_:a <https://example.org/region> "가상지역" .

# 문서 B (별도 문서)
_:z <https://example.org/region> "가상지역" .
<https://example.org/item/sample-a> <https://example.org/hasAddress> _:z .

_:a를 _:z에 일대일로 대응시키면 두 관계가 보존됩니다. W3C의 그래프 동형 정의는 blank node의 대응을 허용하면서 IRI와 리터럴은 보존합니다. 이 가상 표본은 동형이지만, 주소가 현실에서 같은 대상을 뜻하는지는 이 비교가 입증하지 않습니다.

표본의 작은 관계 집합은 일대일 치환으로 대조했습니다. RDF 파서나 RDFC-1.0 구현을 실행한 결과는 아닙니다. 서로 다른 문서에 같은 _:a가 보인다는 이유로 자동 연결하는 정책도 이 예시에서 도출할 수 없습니다.

정규화하면 파일 diff 문제를 해결할 수 있나요?#

같은 범위의 RDF 데이터를 공통 표현으로 비교할 때 정규화를 검토합니다. W3C의 RDF Dataset Canonicalization은 RDFC-1.0을 정의한 2024-05-21 권고안입니다. 단순한 줄 정렬과 달리 blank node가 연결된 구조를 반영해 정규형을 만듭니다. 확인일은 2026-11-02입니다.

정규형은 영구적인 업무 식별자 발급기가 아닙니다. 연결 구조가 바뀌면 정규화 식별자도 재배정돼 diff가 실제 변경보다 커질 수 있다고 같은 권고안은 설명합니다. 변경량을 작업 건수로 바로 환산하거나 정규화 ID로 고객 이력을 묶지 마세요.

비교할 그래프 목록과 데이터 버전, 입력 형식·파서, 정규화 구현·알고리즘과 해시 설정을 함께 남깁니다. 언어 태그 표기 같은 입력 처리 차이도 확인합니다. 그래프 선택이 다르면 SPARQL 조회 범위 검수에서처럼 조건부터 다시 맞춰야 합니다. 빈 그래프의 존재가 업무상 의미를 가진다면 쿼드 비교 외에 그래프 목록도 인수 항목에 둡니다.

최신 흐름도 버전을 구별해 봐야 합니다. 2026-11-02 확인한 RDF 1.2 Concepts는 2026-04-07 Candidate Recommendation Snapshot이며 최종 권고안으로 표시되지 않았습니다. 지역 식별자의 한계는 유지되지만 triple term 같은 새 항목이 포함됩니다. 해당 데이터를 쓴다면 파서와 정규화 도구의 지원 범위를 별도로 확인합니다.

어떤 전후 표본을 인수표에 넣어야 하나요?#

이름과 순서만 바꾼 표본이 통과하는지, 실제 값이나 연결을 바꾼 표본이 구별되는지 함께 봅니다. 아래 기대 판정은 추론으로 의미가 같은지를 계산하는 규칙이 아닙니다. 같은 범위에서 명시된 RDF 관계 구조를 비교하는 자체 설계입니다.

비교 결과에는 입력 범위와 완료 여부를 붙입니다. 같은 데이터셋 안에서 여러 그래프가 blank node를 공유한다면 그래프마다 제멋대로 새 이름을 붙여 공유 관계를 끊지 않았는지도 확인합니다. 비교 완료와 업무 갱신 승인도 별도 항목으로 남깁니다.

동형 판정 뒤에도 무엇을 따로 검수하나요?#

동형은 구조 비교의 결과입니다. 원천에서 같은 주문이 유지됐는지, 권한에 따라 필요한 자료만 내보냈는지, 갱신을 승인할지는 추가 조건이 필요합니다. 장기 외부 참조가 필요하면 영구 IRI와 원천 키의 발급·재사용· 폐기 규칙을 정하고 매핑을 보존합니다.

처리하기 어려운 입력도 있습니다. 정규화 권고안은 계산이 과도해지는 데이터셋에 대한 시간·반복 제한을 다룹니다. 사용하는 도구가 제한에 도달했을 때 성공 결과로 표시하지 않는지도 검수하세요. 실제 데이터 규모에서의 처리 시간과 지원 형식은 이 글에서 측정하지 않았습니다.

알파카랩스는 공개 온톨로지 구축·개발 서비스에서 공통 식별자·원천 매핑과 사람 검수, 모델·소스 인수 범위를 협의한다고 설명합니다. 2026-11-02 확인한 자사 제공 범위의 자기표기입니다. 이 글의 RDFC 절차가 제품에 구현됐다거나 특정 고객에게 적용됐다는 주장은 아닙니다. 데이터가 단순하고 안정된 원천 키가 있다면 그 키를 기준으로 한 대사만으로 충분한지도 먼저 비교합니다.

RDF 파일 비교 FAQ#

blank node 식별자가 바뀌면 데이터도 바뀐 건가요?

이름 차이만으로 판단할 수 없습니다. 같은 비교 범위에서 blank node를 일대일로 대응시켰을 때 IRI·리터럴과 관계가 보존되는지 확인합니다. 업무 개체의 동일성은 원천 키와 별도 규칙으로 검수합니다.

RDF 파일을 줄 단위로 정렬하면 충분한가요?

줄 순서 차이는 정리할 수 있지만 지역 blank node 식별자의 대응은 해결하지 못합니다. 식별자 문자열이 다른 동형 그래프는 정렬 후에도 다르게 보일 수 있습니다. 모든 식별자를 하나로 바꾸는 방식도 서로 다른 노드를 합치므로 피합니다.

RDFC 정규화 ID를 고객이나 주문의 영구 키로 써도 되나요?

정규화 ID는 비교할 데이터셋의 구조에 영향을 받습니다. 구조가 바뀌면 기존 노드의 정규화 식별자도 달라질 수 있으므로 장기 업무 키로 가정하지 않습니다. 외부 참조가 필요하면 영구 IRI와 원천 키의 발급·유지 규칙을 따로 합의합니다.

정규화 해시가 다르면 바로 재적재해야 하나요?

먼저 대상 그래프와 형식·파서·정규화 알고리즘·해시 설정이 같은지 대조합니다. 해시 차이는 같은 비교 산출물을 얻지 못했다는 신호이며 재적재할 업무 범위를 직접 설명하지는 않습니다. 실제 값·관계 차이를 확인하고 갱신 정책을 적용합니다.

RDF 1.2 데이터도 RDFC-1.0으로 바로 비교할 수 있나요?

2026-11-02 확인한 RDF 1.2 Concepts 공개판은 2026-04-07 Candidate Recommendation Snapshot입니다. 새 데이터 항목을 포함한다면 파서와 정규화 도구가 해당 버전을 지원하는지 확인해야 합니다. RDF 1.1 기반 RDFC-1.0의 지원을 자동으로 확대하지 않습니다.

데이터 교환 인수표를 준비하세요#

비식별 전후 파일과 내보낼 그래프 목록, 원천 업무 키를 준비하세요. 바이트·관계 구조·업무 동일성의 통과 조건을 나누면 비교 도구의 결과를 인수 문서에 연결할 수 있습니다. 준비·상담 시간과 비용은 접근 조건, 데이터 형식과 지원 도구를 확인한 뒤 협의합니다.