SHACL 닫힌 셰이프 검수, 등록하지 않은 속성은 어디에서 막을까

2026-11-04 기준, SHACL 닫힌 셰이프는 노드의 직접 속성을 검사합니다. 연결 노드까지 제한하려면 그 노드의 셰이프도 적용합니다.

품목 정보를 다른 팀에 전달할 때, 약속한 품목 코드와 공급사 참조 외에 원천 메모가 들어왔다고 가정하겠습니다. 원천팀에는 필요한 메모여도 교환용 품목에서는 별도 승인 대상일 수 있습니다. 아래 인수표는 품목 자체와 연결된 공급사 참조에서 어떤 속성을 허용하는지 나눕니다.

품목을 닫으면 공급사 정보도 검사되나요?#

품목에 적용한 닫힌 셰이프는 품목이 주어인 RDF 트리플의 속성 IRI를 검사합니다. 공급사로 연결되는 속성이 허용됐더라도 공급사 노드의 속성은 별도 규칙을 적용해야 검사할 수 있습니다. W3C SHACL 닫힌 제약

교환용 품목에서 코드와 공급사 참조를 허용하고, 공급사 참조에서는 공급사 코드만 받는다고 합의할 수 있습니다. 이 경우 공급사 관계의 값에도 공급사 참조 셰이프를 적용합니다. SHACL에서는 sh:node로 그 셰이프를 지정할 수 있습니다. W3C SHACL 노드 제약

같은 데이터를 어떤 표본으로 비교하나요?#

같은 가상 품목에 변경을 하나씩 넣고 어떤 노드와 속성에서 실패하는지 확인합니다. 품목과 공급사 참조는 각각 닫고, 품목의 rdf:type만 닫힌 제약의 예외로 둡니다.

Turtle에서 어느 줄이 허용 범위를 정하나요?#

sh:closed를 true로 두고, 같은 셰이프의 sh:property에서 단일 IRI를 경로로 선언합니다. 추가로 허용할 속성은 sh:ignoredProperties에 넣습니다. 이 예에서는 품목의 rdf:type을 예외로 지정하고, 공급사 참조에는 별도의 닫힌 셰이프를 적용합니다.

@prefix ex: <https://example.org/catalog/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

ex:ItemShape a sh:NodeShape ;
  sh:targetNode ex:item ;
  sh:closed true ;
  sh:ignoredProperties ( rdf:type ) ;
  sh:property [
    sh:path ex:itemCode ;
    sh:minCount 1
  ] ;
  sh:property [
    sh:path ex:supplier ;
    sh:minCount 1 ;
    sh:nodeKind sh:IRI ;
    sh:node ex:SupplierRefShape
  ] .

ex:SupplierRefShape a sh:NodeShape ;
  sh:closed true ;
  sh:property [
    sh:path ex:supplierCode ;
    sh:minCount 1
  ] .

아래 적합 표본은 별도 데이터 그래프로 넣습니다.

@prefix ex: <https://example.org/catalog/> .

ex:item ex:itemCode "A" ; ex:supplier ex:s .
ex:s ex:supplierCode "S" .

pySHACL 0.30.1로 가상 표본을 실행했습니다. 공급사 참조에만 내부 메모가 있을 때, 연결 셰이프를 적용하면 위반이 나왔고 연결을 빼면 품목 검사는 통과했습니다. 예시에서는 sh:targetNode로 품목 한 개를 정했습니다. 배치에서는 검수할 품목이 대상에 모두 포함됐는지 확인합니다. SHACL 검증 대상 누락 검수

원천 그래프에도 같은 규칙을 적용해야 하나요?#

원천팀이 속성을 추가할 수 있는 그래프라면 교환용으로 내보낼 데이터에 닫힌 검사를 적용하는 편이 맞을 수 있습니다. 미등록 속성을 발견했을 때는 원천을 보존하고, 매핑 누락인지 새 속성의 승인 요청인지 구분합니다. 규칙에서 빠진 값을 허용 목록에 곧바로 넣으면 이후에도 검수에서 놓칠 수 있습니다.

보고서에 연결 속성만 보인다면 공급사 참조의 상세 결과를 확인합니다. 검증기가 세부 위반을 표시하지 않으면 해당 노드와 연결 셰이프를 따로 재현해 어떤 속성이 걸렸는지 확인합니다. 승인한 속성 변경은 온톨로지 스키마 변경과 복구 검수와 함께 관리할 수 있습니다.

2026년 11월 2일 공개된 SHACL 1.2 Core 작업 초안에는 타입을 바탕으로 허용 속성을 계산하는 sh:ByTypes도 나옵니다. 위 예시는 2017년 권고의 sh:closed true를 사용합니다. 새 옵션을 고려한다면 검증기 지원과 같은 입력에 대한 결과를 확인합니다. W3C SHACL 1.2 Core 작업 초안

SHACL 닫힌 셰이프 FAQ#

sh:ignoredProperties에 넣으면 값도 검사를 건너뛰나요?

해당 속성은 닫힌 제약에서 허용됩니다. 같은 속성에 데이터형이나 값의 개수 제약을 따로 걸었다면 그 제약은 계속 평가합니다.

sh:closed를 켜면 허용된 속성이 반드시 있어야 하나요?

필수 항목은 sh:minCount 같은 별도 조건으로 지정합니다. 닫힌 제약에서는 실제로 존재하는 속성이 허용 목록에 있는지를 확인합니다.

공급사 참조까지 닫으려면 어떻게 하나요?

품목의 공급사 속성에서 sh:node로 공급사 참조 셰이프를 적용할 수 있습니다. 공급사 참조 셰이프에도 sh:closed를 설정하고 그 노드에서 허용할 속성을 지정합니다.

새 속성이 필요하면 원천에서 지워야 하나요?

원천 값을 보존하고 교환용 데이터에 포함할지 협의합니다. 포함하기로 했다면 매핑과 검수 규칙을 함께 갱신하고, 기존에 통과하던 표본도 다시 확인합니다.

닫힌 셰이프를 쓰면 조회 권한까지 보호되나요?

닫힌 제약은 전달된 그래프의 속성을 검사합니다. 원천 접근과 조회 권한은 별도 정책에서 적용하고 권한 밖 조회가 차단되는지 따로 시험합니다.

교환 데이터 허용 속성 협의#

알파카랩스의 온톨로지 구축 서비스는 개념·관계·제약 정의, 원천 매핑과 대표 표본 검수 범위를 협의합니다. 비식별 품목 예시와 공급사에 연결할 값을 준비하면, 직접 속성과 연결 노드의 허용 범위를 담은 인수표 초안을 함께 정할 수 있습니다.