SHACL 집합 일치 검수: 건수가 같아도 명단이 다른 이유

SHACL 집합 일치는 양쪽 값을 대조합니다. 2026-11-07 기준, 건수가 같아도 명단이 다르면 실패하고 양쪽이 비면 통과할 수 있습니다.

예정 담당자도 2명, 실제 배정도 2명인데 서로 다른 사람이 들어갈 수 있습니다. 명단이 일부 겹친다는 사실도 전체 일치의 증거가 되지 않습니다. 같은 대상의 두 속성에서 찾은 값들을 비교해 누락·추가·공통 값을 구분해야 합니다.

숫자 하한·상한의 대소관계는 SHACL 필드 비교 검수에서 다룹니다. 이 글은 값 목록 전체의 일치를 확인하는 sh:equals와 값이 겹치면 안 되는 sh:disjoint를 비교합니다. 검사할 대상 자체가 빠지는 문제는 SHACL 검증 대상 커버리지에서 별도로 확인할 수 있습니다.

같은 건수인데 왜 명단 일치가 실패하나요?#

양쪽 원소 수가 같아도 원소 자체가 다를 수 있기 때문입니다. 기준 명단이 a·b이고 실제 명단이 a·c라면 b가 빠졌고 c가 추가됐습니다. sh:equals는 양쪽의 이런 차이를 검사합니다.

W3C의 2017-07-20 SHACL 권고는 sh:equals를 값 노드 집합과 같은 대상의 비교 속성 값 집합이 같은 조건으로 정의합니다. 한쪽에만 있는 값은 각 방향의 검증 결과가 됩니다. sh:equals 공식 정의를 2026-11-07 확인했습니다.

설계 담당자는 “같은 명단이어야 하는가”와 “두 역할이 겹치면 안 되는가”를 먼저 정합니다. 전자는 equals, 후자는 disjoint의 검수 문제입니다. 데이터 담당자는 비교 속성이 같은 기준 시점·권한·업무 대상을 나타내는지 확인하고, 현업 담당자는 누락·추가된 식별자별 기대 결과를 대조합니다.

두 건수가 같다는 검사, 한 명이라도 공통이라는 검사, 두 집합이 같다는 검사는 각각 다른 판정입니다. 등록 건수만 맞춘 자료를 전체 명단 일치로 승인하지 않도록 인수표에 판정 종류를 적습니다.

같은 입력에서 equals와 disjoint는 어떻게 갈리나요?#

equals는 양쪽 값 집합이 같아야 통과합니다. disjoint는 공통 값이 없어야 통과합니다. 아래 a·b·c는 서로 다른 가상 IRI의 축약이며, 사람 이름이나 고객 명단이 아닙니다. 같은 행의 규칙들은 별도 셰이프 그래프에서 실행했습니다.

순서를 바꾼 같은 값 목록은 집합 비교에서 일치했습니다. 일부 값이 겹친 행에서는 일치와 비겹침이 모두 실패했습니다. 두 집합이 다르다는 이유만으로 disjoint가 통과하는 것은 아닙니다. sh:disjoint 공식 정의는 공통 값이 없는 조건을 설명합니다.

합성 입력·세 가지 규칙·기대값 JSON과 값 집합을 대조하는 Python 스크립트를 공개했습니다. 두 파일을 같은 폴더에 두고 pySHACL 0.40.2·RDFLib 7.6.0이 있는 환경에서 python shacl-set-equality-check.py로 실행할 수 있습니다. 스크립트는 실제 값·누락·추가·공통 값과 검증 결과를 출력하고 기대값 및 별도 Python 집합 연산과 대조합니다.

어떤 속성끼리 비교하는지 어떻게 고정하나요?#

같은 검사 대상에서 기준 명단과 실제 명단으로 쓰는 속성을 명시합니다. 다음은 표에서 사용한 최소 equals 규칙입니다. 필수 개수나 권한·승인 조건은 포함하지 않았습니다.

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

ex:EqualShape a sh:NodeShape ;
  sh:targetNode ex:request ;
  sh:property [
    sh:path ex:expected ;
    sh:equals ex:actual
  ] .

ex:request의 expected 값들과 같은 ex:request의 actual 값들을 비교합니다. 다른 요청의 명단을 자동으로 찾아 조인하는 규칙은 아닙니다. disjoint 실험에서는 같은 경로의 비교 제약을 sh:disjoint ex:actual로 정의한 별도 셰이프를 사용했습니다. 원고의 Turtle과 공개 equals 규칙은 같은 그래프인지 확인했습니다.

W3C의 2026-11-02 SHACL 1.2 Core Working Draft는 equals의 비교 대상을 속성 경로로 기술합니다. 이번 예시는 2017 권고에서 사용하는 직접 IRI 속성 비교로 한정했습니다. 초안이 최종 권고로 확정됐다거나 이번 엔진으로 1.2의 모든 경로 기능을 검증했다는 뜻은 아닙니다. 2026-11-02 고정 초안의 equals 설명을 현재 검토 중인 사양과 구분해 읽을 수 있습니다.

양쪽이 비거나 같은 값이 반복되면 어떻게 판단하나요?#

빈 집합 두 개는 같고 공통 원소도 없습니다. 실제 실험에서도 최소 equals와 disjoint는 양쪽이 없는 입력을 통과시켰습니다. 명단이 필수라면 존재 조건을 추가해 검수해야 합니다.

공개 표본에는 expected와 actual 각각에 sh:minCount 1을 둔 별도의 requiredEquals 규칙도 포함했습니다. 이 규칙은 양쪽이 비었을 때 위반을 냈습니다. 비교 결과가 같다는 조건과 자료가 반드시 있어야 한다는 조건을 나누면, 빈 자료를 업무 완료로 오인하는 것을 막을 수 있습니다.

같은 RDF 트리플을 두 번 적어도 별도 담당자가 늘지는 않았습니다. RDF 1.1 Concepts의 그래프 정의는 RDF 그래프를 트리플 집합으로 설명합니다. 문서는 2014-02-25 권고이며 2026-11-07 확인했습니다. 원천 행의 중복 횟수·발생 순서까지 대사하려면 그 정보를 별도 데이터로 보존하고 검사해야 합니다.

표시명이 같다는 사실도 이번 비교에서 같은 IRI로 합치는 근거가 되지 않았습니다. 실험은 추가 추론을 끄고 서로 다른 a·b에 같은 라벨을 붙였습니다. 식별자 정규화·개체 해소·OWL 동일성은 별도 기준이 필요하며, 이 표는 그 절차를 수행한 결과가 아닙니다.

equals가 통과해도 양쪽 명단이 모두 잘못됐거나 오래된 상태일 수 있습니다. 원천 완전성·기준 시점·권한·역할의 적정성과 실제 반영 승인은 따로 확인합니다. 이는 데이터 비교 규칙이며 실제 시스템의 승인·권한 부여를 구현하거나 시험한 예제가 아닙니다.

이 실험은 2017 SHACL의 직접 속성 집합 비교에 대한 제한 관측입니다. 고객 데이터·운영 시스템·전체 엔진 적합성을 시험하지 않았습니다. 다음 검토일은 2026-12-07이며 W3C 문서 지위, 엔진 버전, 비교 그래프 범위나 식별자 계약이 바뀌면 같은 표본을 다시 실행합니다.

SHACL 집합 일치 검수 FAQ#

값 집합 인수표 초안 협의#

알파카랩스는 온톨로지 구축·컨설팅 서비스에서 원천 매핑·공통 식별자·사람 검수·기존 통계와의 대사를 범위로 협의한다고 설명합니다. 이는 자사 제공 범위의 설명이며 특정 고객의 명단 오류를 해결한 실적으로 제시하는 내용이 아닙니다. 비식별 기준 명단·실제 값 경로·기준 시점을 준비하면 누락·추가·겹침과 필수 조건을 나눈 값 집합 인수표 초안을 협의할 수 있습니다. 소요 시간은 자료와 검수 범위를 확인한 뒤 정합니다.