SHACL 1.2 SPARQL 확장

W3C 작업 초안

이 문서에 대한 자세한 정보
이 버전:
https://www.w3.org/TR/2026/WD-shacl12-sparql-20260821/
최신 공개 버전:
https://www.w3.org/TR/shacl12-sparql/
최신 편집자 초안:
https://w3c.github.io/data-shapes/shacl12-sparql/
이력:
https://www.w3.org/standards/history/shacl12-sparql/
커밋 이력
테스트 스위트:
https://w3c.github.io/data-shapes/data-shapes-test-suite/
최신 권고안:
https://www.w3.org/TR/2017/REC-shacl-20170720/#part2
편집자:
(TopQuadrant, Inc.)
(Corning)
(JPMorgan Chase & Co.)
(Swansea University)
이전 편집자:
Dimitris Kontokostas
피드백:
GitHub w3c/data-shapes (풀 리퀘스트, 새 이슈, 열린 이슈)
public-shacl@w3.org에 제목 줄 [shacl12-sparql] 사용 (아카이브)

Copyright © 2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

개요

이 문서는 SHACL 도형 제약 언어의 SPARQL 관련 확장을 정의합니다. SHACL의 Core 부분은 도형의 기본 구문과 SHACL에서 지원하는 가장 일반적인 제약 조건 구성 요소를 정의하는 반면, SPARQL 관련 확장은 SPARQL을 통해 Core의 표현력을 확장하는 기능을 다룹니다. 특히 이 문서는 SPARQL을 사용하여 제약 조건 및 제약 조건 구성 요소를 정의하는 방법을 설명합니다. 또한 이 문서는 노드 목록을 도출하는 데 사용할 수 있는 SPARQL 기반 노드 표현식을 도입합니다. 마지막으로 이 문서는 도형과 함께 사용할 수 있는 SPARQL 기반 추론 규칙을 정의합니다.

이 문서의 상태

이 절은 이 문서가 발행된 시점의 상태를 설명합니다. 현재 W3C 발행물과 이 기술 보고서의 최신 개정 목록은 W3C 표준 및 초안 색인에서 확인할 수 있습니다.

이 문서는 Data Shapes Working Group에서 Recommendation 트랙을 사용하여 Working Draft로 발행했습니다.

Working Draft로 발행되었다고 해서 W3C와 그 회원들이 이를 승인한다는 의미는 아닙니다.

이 문서는 초안 문서이며 언제든지 다른 문서로 업데이트, 대체 또는 폐기될 수 있습니다. 이 문서를 진행 중인 작업 이외의 것으로 인용하는 것은 부적절합니다.

이 문서는 W3C Patent Policy에 따라 운영되는 그룹에서 작성했습니다. W3C는 해당 그룹의 산출물과 관련하여 이루어진 모든 특허 공개의 공개 목록을 유지합니다. 해당 페이지에는 특허 공개를 위한 지침도 포함되어 있습니다. 개인이 해당 개인이 Essential Claim(s)를 포함한다고 믿는 특허에 대해 실제로 알고 있는 경우, Essential Claim(s) 해당 정보를 W3C Patent Policy의 6절에 따라 공개해야 합니다.

이 문서는 2025년 8월 18일 W3C Process Document의 적용을 받습니다.

SHACL 명세

이 명세는 SHACL 1.2 명세군의 일부입니다. 이에 대한 더 자세한 소개는 SHACL 1.2 개요를 참조하세요.

명세는 다음과 같습니다.

작업 초안:

SHACL 1.2 Core
SHACL의 Core를 정의합니다
SHACL 1.2 SPARQL 확장
SHACL의 SPARQL 관련 확장을 정의합니다
SHACL 1.2 Node Expressions
SHACL에서 포커스 노드와 값 노드를 도출하는 데 사용되는 표현식을 정의합니다
SHACL 1.2 Rules
SHACL의 rule 기반 추론 방법을 정의합니다
SHACL 1.2 UI
User Interface 생성을 위한 SHACL의 사용을 정의합니다
SHACL 1.2 Profiling
SHACL 데이터를 포함한 데이터 profiling을 위한 SHACL의 사용을 정의합니다

Working Group Note 초안:

SHACL 1.2 Overview
SHACL 명세 집합을 개괄합니다
SHACL 1.2 Compact Syntax
SHACL 개념을 표현하기 위한 RDF 구문을 정의합니다
참고

구현자는 위 명세들에 대한 적합성 수준을 SHACL 1.2 test suite의 테스트 케이스를 성공적으로 통과함으로써 부분적으로 확인할 수 있습니다. 그러나 test suite의 모든 테스트를 통과한다고 해서 명세에 대한 완전한 적합성을 의미하지는 않습니다. 이는 구현이 test suite에서 테스트한 측면에 적합하다는 것만을 의미합니다.

1. 소개

이 문서는 SHACL(Shapes Constraint Language)의 SPARQL 관련 기능을 명시합니다.

1.1 용어

이 문서 전체에서 다음 용어가 사용됩니다.

이 문서에서 정의하는 SHACL SPARQL Extensions는 때때로 SHACL-SPARQL이라고 합니다.

RDF 1.2 Concepts and Abstract Syntax의 일부에 링크된 용어는 그곳에서 정의된 대로 SHACL-SPARQL에서 사용됩니다. SPARQL 1.2 Query Language의 일부에 링크된 용어는 그곳에서 정의된 대로 SHACL-SPARQL에서 사용됩니다. SHACL 1.2 Core의 일부에 링크된 용어는 그곳에서 정의된 대로 SHACL-SPARQL에서 사용됩니다. 특정 용어가 이 문서에서 나타나는 모든 경우에 대해 정의를 제공하려면 한 번의 링크로 충분합니다.

정의는 이 문서 안에서 완결됩니다. 즉, 이 문서 안에서 어떤 상황을 참으로 만드는 규칙이 없다면 그 상황은 거짓입니다.

기본 RDF 용어
이 문서에서는 RDF 그래프, RDF 트리플, IRI, 리터럴, 블랭크 노드, 노드인 RDF 그래프의 용어, 데이터타입, 구체화자, RDF 용어, 그리고 주어, 술어, 그리고 목적어 라는 RDF 트리플의 용어를 RDF 1.2 개념 및 추상 구문 [rdf12-concepts]에서 정의된 대로 사용한다.
Binding, Solution
binding은 (variable, RDF term)의 쌍이며, [sparql12-query]에서의 용어 사용과 일치합니다. solution은 각 variable이 고유해야 하는 bindings의 집합입니다. 비공식적으로, solution은 흔히 SPARQL query의 결과 테이블 본문에서 한 행으로 이해됩니다.

1.2 문서 규약

SHACL의 구문은 RDF입니다. 이 문서의 예제는 Turtle [rdf12-turtle]을 사용합니다. RDF/XML과 같은 다른 RDF 직렬화도 실제로 사용될 수 있습니다. 독자는 triples와 같은 기본 RDF 개념 [rdf12-concepts] 및 SPARQL [sparql12-query]에 익숙해야 합니다.

이 문서에서는 다음 namespace prefix bindings가 사용됩니다.

Prefix Namespace
owl: http://www.w3.org/2002/07/owl#
rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs: http://www.w3.org/2000/01/rdf-schema#
sh: http://www.w3.org/ns/shacl#
xsd: http://www.w3.org/2001/XMLSchema#
ex: http://example.com/ns#

이 문서에서는 다음 JSON-LD context가 사용됩니다. 

{
  "@context": {
    "owl": "http://www.w3.org/2002/07/owl#",
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "sh": "http://www.w3.org/ns/shacl#",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "ex": "http://example.com/ns#"
  }
}

SHACL vocabulary 자체를 정의하는 graph의 URI는 위 namespace와 동일합니다. 즉, #를 포함합니다. 예를 들어 owl:imports를 통한 SHACL vocabulary 참조는 #를 포함해야 합니다.

문서 전체에서 Turtle의 RDF graphs를 포함하는 색상 구분 상자가 나타납니다. 이러한 Turtle 문서 조각은 위에 제시된 prefix bindings를 사용합니다.

SHACL Definitions는 파란색 상자에 나타납니다.

SPARQL 또는 TEXTUAL DEFINITIONS
# This box contains SPARQL or textual definitions.

이와 같은 회색 상자는 shapes graph에 적용되는 구문 규칙을 포함합니다.

$ marker를 사용하는 SPARQL variables는 SPARQL query 실행 전에 pre-bound되거나, $PATH의 경우 substituted되는 외부 bindings를 나타냅니다 (4.3 SPARQL 기반 Constraint Components를 사용한 검증에서 설명함).

true는 RDF term "true"^^xsd:boolean을 나타냅니다. false는 RDF term "false"^^xsd:boolean을 나타냅니다.

1.3 적합성

비규범으로 표시된 절뿐만 아니라, 이 명세의 모든 작성 지침, 도표, 예제 및 참고는 비규범입니다. 이 명세의 그 밖의 모든 내용은 규범적입니다.

이 문서에서 해도 된다, 해야 한다, 해서는 안 된다 및 하는 것이 좋다라는 핵심어는 여기에 표시된 것처럼 모두 대문자로 표기된 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석해야 한다.

이 문서는 SHACL Core를 확장하는 SHACL-SPARQL 언어를 정의합니다. 이 명세는 다음에 대한 적합성 기준을 설명합니다.

또한 SHACL Core의 적합성 절에 있는 올바른 형식에 관한 논의를 참조하십시오.

2. SPARQL 쿼리를 위한 접두사 선언

이 절에서는 SPARQL 쿼리의 네임스페이스 접두사를 선언하기 위해 이 문서 전체에서 사용되는 메커니즘을 소개합니다.

도형 그래프는 네임스페이스 접두사 선언을 포함할 수 있으며, 이를 통해 동일한 도형 그래프에서 파생된 SPARQL 쿼리를 이러한 접두사로 축약할 수 있습니다. 이러한 접두사 선언의 구문은 다음 예시에 나와 있습니다.

sh:prefix와 sh:namespace 모두에 대한 값을 갖는 IRI 또는 공백 노드를 접두사 선언이라고 합니다. SHACL 어휘에는 이러한 접두사 선언의 유형으로 sh:PrefixDeclaration 클래스가 포함되어 있지만, 이를 위해 rdf:type 트리플이 요구되지는 않습니다. 접두사 선언은 sh:prefix 속성에 대해 정확히 하나의 값을 갖습니다. sh:prefix의 값은 데이터 유형이 xsd:string인 리터럴입니다. 접두사 선언은 sh:namespace 속성에 대해 정확히 하나의 값을 갖습니다. sh:namespace의 값은 데이터 유형이 xsd:anyURI 또는 xsd:string인 리터럴입니다. 이러한 값의 쌍은 접두사에서 네임스페이스로의 단일 매핑을 지정합니다. sh:declare 속성의 값은 접두사 선언입니다.

sh:declare 값에 권장되는 주어는 해당 접두사를 사용하는 도형을 포함하는 명명된 그래프의 IRI입니다. 이러한 IRI는 흔히 sh:ShapesGraph 또는 owl:Ontology의 인스턴스로 선언되지만, 반드시 그래야 하는 것은 아닙니다.

무엇보다도 접두사 선언은 SPARQL 기반 제약 조건, SPARQL 기반 제약 조건 구성 요소의 검증기, SPARQL 기반 노드 표현식 및 SPARQL 기반 추론 규칙에서 사용할 수 있습니다. 이러한 노드는 sh:prefixes 속성을 사용하여 접두사 매핑 집합을 지정할 수 있습니다. sh:prefixes 속성의 사용 예시는 이 예시에서 확인할 수 있습니다.

sh:prefixes의 값은 IRI 또는 공백 노드입니다. SHACL 프로세서는 SPARQL 기반 제약 조건 또는 검증기의 SPARQL 속성 경로 sh:prefixes/(^owl:versionIRI?/owl:imports)*/sh:declare의 값인 모든 개별 접두사 매핑을 합집합하여 접두사 매핑 집합을 수집합니다. ^owl:versionIRI? 요소는 추가 owl:imports를 따르기 전에 버전 IRI에서 도형 그래프 IRI로 이동하여 owl:versionIRI로 가져온 그래프를 지원합니다. 이러한 접두사 선언의 모음에 동일한 sh:prefix 값에 대한 서로 다른 여러 네임스페이스가 포함되어 있으면, 도형 그래프는 잘못된 형식입니다. (SHACL 프로세서는 도달하지 않는 접두사 선언을 무시할 수 있습니다).

SPARQL 쿼리에 sh:prefixes의 값이 없으면 시스템은 접두사 선언 중 도형 그래프에서 sh:declare의 값이며 owl:Ontology의 SHACL 인스턴스, sh:DataGraph, sh:ShapesGraph, 또는 sh:RulesGraph(sh:ShapesGraph의 하위 클래스)를 사용한다.

SHACL 프로세서는 모든 접두사 매핑에 대한 PREFIX 선언을 앞에 추가하여 sh:select의 값과 sh:ask 및 sh:construct 같은 유사한 속성의 값을 SPARQL로 변환합니다. 각 sh:prefix 값은 PNAME_NS로 변환되고, 각 sh:namespace 값은 PREFIX 선언의 IRIREF로 변환됩니다. 위의 예시 도형 그래프에 대해 SHACL-SPARQL 프로세서는 PREFIX ex: <http://example.com/ns#>와 같은 행을 생성합니다. 결과 쿼리 문자열을 유효한 SPARQL 1.2 쿼리로 구문 분석할 수 없으면 SHACL-SPARQL 프로세서는 실패를 생성해야 합니다.

이 문서의 나머지 부분에서는 간결성을 위해 sh:prefixes 문이 생략되었을 수 있습니다.

3. SPARQL 기반 제약 조건

SHACL-SPARQL은 SPARQL SELECT 쿼리를 기반으로 제한을 표현하는 데 사용할 수 있는 제약 조건 구성 요소를 지원합니다.

제약 조건 구성 요소 IRI: sh:SPARQLConstraintComponent

매개변수:
속성 요약
sh:sparql 평가할 SPARQL 쿼리를 선언하는 SPARQL 기반 제약 조건.

SPARQL 기반 제약 조건의 구문 규칙과 유효성 검사 절차는 이 절의 나머지 부분에서 정의합니다.

3.1 SPARQL 기반 제약 조건의 예

이 절은 비규범적입니다.

다음 예시는 SPARQL 기반 제약 조건의 구문을 보여 줍니다.

SPARQL 쿼리는 제약 조건을 위반하는 value 변수의 모든 바인딩에 대해 결과 집합의 솔루션을 반환합니다. 해당 결과 집합의 각 솔루션에는 나중에 설명하는 매핑 규칙을 적용한 하나의 유효성 검사 결과가 있습니다. 이 예시에서 각 유효성 검사 결과는 this 변수의 바인딩을 sh:focusNode로, ex:germanLabel을 sh:resultPath로, 위반 값을 sh:value로 갖습니다.

다음 예시는 위와 유사하지만 속성 도형을 사용하는 시나리오를 보여 줍니다.

3.2 SPARQL 기반 제약 조건의 구문

도형은 sh:sparql 속성에 대한 값을 가질 수 있으며, 이러한 값은 IRI 또는 공백 노드입니다. 이러한 값을 SPARQL 기반 제약 조건이라고 합니다.

SPARQL 기반 제약 조건은 sh:select 속성에 대해 정확히 하나의 값을 갖습니다. sh:select의 값은 데이터 유형이 xsd:string인 리터럴입니다. sh:SPARQLConstraint 클래스는 SHACL 어휘에 정의되어 있으며 이러한 제약 조건의 유형으로 사용할 수 있습니다(유형이 요구되지는 않음). 접두사 처리 규칙을 사용할 때 sh:select의 값은 유효한 SPARQL 1.2 SELECT 쿼리입니다. sh:select의 값에서 파생된 SPARQL 쿼리는 SELECT 절에서 this 변수를 프로젝션합니다.

다음 두 속성은 도형에서의 사용 방식과 유사합니다.

SPARQL 기반 제약 조건은 sh:message 속성에 대한 값을 가질 수 있으며, 이러한 값은 데이터 유형이 xsd:string, rdf:dirLangString, rdf:langString 또는 rdf:HTML인 리터럴입니다. 동일한 언어 태그가 있는 sh:message 값이 둘 이상이거나 데이터 유형이 xsd:string인 값이 여러 개여서는 안 됩니다. SPARQL 기반 제약 조건은 sh:deactivated 속성에 대해 최대 하나의 값을 가질 수 있습니다 그리고 이 값은 true 또는 false입니다. SPARQL 기반 제약 조건은 sh:severity 속성에 대해 최대 하나의 값을 가질 수 있으며, 이 값은 IRI입니다.

속성 도형의 맥락에서 사용되는 SELECT 쿼리는 해당 도형이 사용하는 경로의 자리표시자로 PATH라는 특수 변수를 사용합니다.

SPARQL 기반 제약 조건 및 SELECT 기반 검증기의 SPARQL 쿼리에서 PATH 변수를 합법적으로 사용할 수 있는 유일한 위치는 트리플 패턴의 술어 위치입니다. 다른 위치에서 PATH 변수를 사용하는 쿼리는 잘못된 형식입니다.

3.3 SPARQL 기반 제약 조건을 사용한 유효성 검사

이 절에서는 sh:SPARQLConstraintComponent의 검증기를 설명합니다. 이 검증기는 가능한 구현 전략 중 하나만 설명하며, 결과가 동등하다면 SHACL 프로세서는 다른 접근 방식을 선택할 수 있습니다.

텍스트 정의
$sparql을 sh:sparql의 값이라고 합니다. SPARQL 기반 제약 조건이 sh:deactivated 속성에 대해 true를 값으로 가지면 유효성 검사 결과가 없습니다. 그렇지 않으면 3.3.1 SPARQL 제약 조건의 사전 바인딩된 변수 $this에 설명된 대로 변수 this를 사전 바인딩하여 SPARQL 기반 제약 조건 $sparql이 지정하는 SPARQL 쿼리를 실행합니다. 도형이 속성 도형이면 실행 전에 속성 도형의 sh:path를 통해 지정된 SHACL 속성 경로의 유효한 SPARQL 표면 구문 문자열로, 트리플 패턴의 술어 위치에 나타나는 PATH 변수를 치환합니다. failure 변수의 바인딩이 true가 아닌 각 솔루션마다 하나의 유효성 검사 결과가 있습니다. 이러한 유효성 검사 결과는 3.3.2 솔루션 바인딩을 결과 속성에 매핑에서 설명하는 속성 값을 가져야 합니다. $sparql이 sh:severity에 대한 값을 가지면 유효성 검사 결과는 해당 값을 유일한 sh:resultSeverity로 가져야 합니다. 솔루션 중 하나가 failure의 바인딩으로 true를 갖는 경우에만 실패가 생성되어야 합니다.

3.3.1 SPARQL 제약 조건의 사전 바인딩된 변수 $this

SPARQL 기반 제약 조건의 SPARQL 쿼리와 SPARQL 기반 제약 조건 구성 요소의 검증기가 처리될 때, SHACL-SPARQL 프로세서는 $this 변수의 값을 현재 포커스 노드로 사전 바인딩합니다.

3.3.2 솔루션 바인딩을 결과 속성에 매핑

유효성 검사 결과 노드의 속성 값은 결과 솔루션과 제약 조건 자체의 값을 조합하여 다음 규칙에 따라 파생됩니다. 규칙은 위에서 아래로 실행되며, 처음 바인딩된 값을 사용합니다.

속성 생성 규칙
sh:focusNode
  1. this 변수의 바인딩
sh:resultPath
  1. path 변수의 바인딩이 IRI인 경우 해당 바인딩
  2. 속성 도형에서 생성된 결과의 경우, 해당 도형의 sh:path 값과 동등한 SHACL 속성 경로
sh:value
  1. value 변수의 바인딩
  2. 값 노드
sh:resultMessage
  1. message 변수의 바인딩
  2. SPARQL 기반 제약 조건의 경우: SPARQL 기반 제약 조건의 sh:message 값. SPARQL 기반 제약 조건 구성 요소의 경우: SPARQL 기반 제약 조건 구성 요소의 검증기에 있는 sh:message 값.
  3. SPARQL 기반 제약 조건 구성 요소의 경우: SPARQL 기반 제약 조건 구성 요소의 sh:message 값.
  4. 그렇지 않으면 도형 또는 제약 조건에서 메시지를 선언하는 기본 메커니즘이 적용됩니다.
이러한 메시지 리터럴에는 {?varName} 또는 {$varName}을 통해 모든 SELECT 결과 변수의 이름이 포함될 수 있습니다. 제약 조건이 SPARQL 기반 제약 조건 구성 요소를 기반으로 하면 구성 요소의 매개변수 이름도 사용할 수 있습니다. 이러한 {?varName} 및 {$varName} 블록은 해당 변수 값의 적절한 문자열 표현으로 대체하는 것이 좋습니다.
sh:sourceConstraint
  1. SPARQL 기반 제약 조건, 즉 sh:sparql의 값

4. SPARQL 기반 제약 조건 구성 요소

SPARQL 기반 제약 조건은 높은 유연성을 제공하지만 일부 사람에게는 이해하기 어렵거나 반복을 유발할 수 있습니다. 이 절에서는 SPARQL의 복잡성을 추상화하고 Core 제약 조건 구성 요소와 유사한 고수준의 재사용 가능한 구성 요소를 선언하기 위한 방법으로 SPARQL 기반 제약 조건 구성 요소를 소개합니다. 이러한 제약 조건 구성 요소는 SHACL RDF 어휘를 사용하여 선언할 수 있으므로 공유하고 재사용할 수 있습니다.

4.1 SPARQL 기반 제약 조건 구성 요소의 예

이 절은 비규범적입니다.

다음 예시는 SHACL-SPARQL 언어를 사용하여 SPARQL로 새로운 제약 조건 구성 요소를 지정하는 방법을 보여 줍니다. 이 예시는 각 값 노드가 주어진 정규식과 일치하는지 검증하기 위해 sh:pattern과 sh:flags를 SPARQL ASK 쿼리로 구현합니다. 이는 예시 구현일 뿐이며 규범적인 것으로 간주해서는 안 됩니다.

제약 조건 컴포넌트가 선언되면 다음 예에 설명된 것처럼 해당 매개변수를 도형에서 사용할 수 있습니다.

제약 조건 구성 요소는 도형 내에서 제약 조건을 식별하고 검증하는 방법에 관한 지침을 유효성 검사 엔진에 제공합니다. 일반적으로 도형 S가 속성 p에 대한 값을 가지며, p를 매개변수로 지정하는 제약 조건 구성 요소 C가 있고, S가 C의 모든 필수 매개변수에 대한 값을 가지면, 이러한 매개변수 값 집합(선택적 매개변수 포함)은 제약 조건을 선언하며 유효성 검사 엔진은 이 제약 조건을 검증하기 위해 C에서 적절한 검증기를 사용합니다. 위 예시에서 sh:PatternConstraintComponent는 필수 매개변수 sh:pattern, 선택적 매개변수 sh:flags, 그리고 노드 도형 또는 속성 도형을 검증하는 데 사용할 수 있는 검증기를 선언합니다.

4.2 SPARQL 기반 제약 조건 구성 요소의 구문

SPARQL 기반 제약 조건 구성 요소는 도형 그래프에서 SHACL 유형 sh:ConstraintComponent를 갖는 IRI입니다.

이 문서에서 새로운 제약 조건 구성 요소를 선언하는 메커니즘은 SPARQL 기반 구성 요소로 제한됩니다. 그러나 매개변수와 검증기를 선언하는 일반 구문은 JavaScript와 같은 다른 확장 언어에서도 작동하도록 설계되었습니다.

4.2.1 매개변수 선언(sh:parameter)

제약 조건 구성 요소의 매개변수는 sh:parameter 속성을 통해 선언됩니다. sh:parameter의 값을 매개변수 선언이라고 합니다. sh:Parameter 클래스는 매개변수 선언의 유형으로 사용할 수 있지만 이러한 트리플이 요구되지는 않습니다. 각 매개변수 선언은 sh:path 속성에 대해 정확히 하나의 값을 갖습니다. 매개변수 선언에서 sh:path의 값은 IRI입니다.

IRI의 로컬 이름은 IRI 끝에 있는 가장 긴 NCNAME으로 정의되며, IRI의 첫 번째 콜론 바로 뒤에 오는 것은 제외됩니다. 매개변수 선언의 매개변수 이름은 sh:path 값의 로컬 이름으로 정의됩니다. 매개변수에서 SPARQL 변수로 올바르게 매핑할 수 있도록 다음 구문 규칙이 적용됩니다.

모든 매개변수 이름은 유효한 SPARQL VARNAME입니다. 매개변수 이름은 다음 중 하나여서는 안 됩니다. this, path, PATH, value. 둘 이상의 매개변수 선언이 동일한 매개변수 이름을 사용하는 제약 조건 구성 요소는 잘못된 형식입니다.

sh:optional의 값은 데이터 유형이 xsd:boolean인 리터럴이어야 합니다. 매개변수 선언은 sh:optional 속성에 대해 최대 하나의 값을 가질 수 있습니다. true로 설정하면 매개변수 선언은 선택적 매개변수를 선언합니다. 모든 제약 조건 구성 요소에는 선택 사항이 아닌 매개변수가 하나 이상 있습니다.

sh:Parameter 클래스는 sh:PropertyShape의 SHACL 하위 클래스로 정의되며, 속성 도형에 적용할 수 있는 모든 속성은 매개변수에도 사용할 수 있습니다. 여기에는 sh:name 및 sh:description과 같은 설명 속성뿐 아니라 sh:class와 같은 제약 조건 매개변수도 포함됩니다. 매개변수에 선언된 제약 조건을 준수하지 않는 도형은 잘못된 형식입니다. 일부 구현은 잘못된 매개변수 값을 가진 제약 조건 구성 요소가 실행되지 않도록 이러한 제약 조건 매개변수를 사용할 수 있습니다.

4.2.2 레이블 템플릿(sh:labelTemplate)

sh:labelTemplate 속성은 모든 제약 조건 구성 요소에서 제약 조건을 사람에게 어떻게 렌더링할 수 있는지 제안하는 데 사용할 수 있습니다. sh:labelTemplate의 값은 문자열이며 언어 태그를 포함할 수도 있습니다. 이러한 값을 레이블 템플릿이라고 합니다.

이 절의 나머지 부분은 비규범적입니다.

레이블 템플릿은 {?varName} 또는 {$varName} 구문을 사용하여 제약 조건 구성 요소에 선언된 매개변수의 이름을 포함할 수 있으며, 여기서 varName은 매개변수 이름입니다. 표시할 때 이러한 {?varName} 및 {$varName} 블록은 실제 매개변수 값으로 대체해야 합니다. 동일한 주어에 대해 여러 레이블 템플릿이 있을 수 있지만 동일한 언어 태그를 가져서는 안 되며, 데이터 유형이 xsd:string인 템플릿은 둘 이상이어서는 안 됩니다.

4.2.3 검증기

지원되는 각 도형 유형, 즉 속성 도형 또는 노드 도형에 대해 제약 조건 구성 요소는 적절한 검증기를 선언합니다. 주어진 제약 조건에 대해 다음 규칙을 순서대로 사용하여 제약 조건 구성 요소에서 검증기를 선택합니다.

  1. 노드 도형의 경우 sh:nodeValidator 값이 있으면 그중 하나를 사용합니다.
  2. 속성 도형의 경우 sh:propertyValidator 값이 있으면 그중 하나를 사용합니다.
  3. 그렇지 않으면 sh:validator 값 중 하나를 사용합니다.

적절한 검증기를 찾을 수 없으면 SHACL-SPARQL 프로세서는 해당 제약 조건을 무시합니다.

SHACL-SPARQL에는 SPARQL SELECT 쿼리 (sh:nodeValidator 및 sh:propertyValidator용) 또는 SPARQL ASK 쿼리(sh:validator용)를 기반으로 하는 두 유형의 검증기가 포함됩니다.

4.2.3.1 SELECT 기반 검증기

SHACL 유형 sh:SPARQLSelectValidator를 갖는 검증기를 SELECT 기반 검증기라고 합니다. sh:nodeValidator의 값은 SELECT 기반 검증기여야 합니다. sh:propertyValidator의 값은 SELECT 기반 검증기여야 합니다. SELECT 기반 검증기는 sh:select 속성에 대해 정확히 하나의 값을 갖습니다. sh:select의 값은 앞서 설명한 접두사 처리 규칙을 사용하는 유효한 SPARQL SELECT 쿼리입니다. sh:select의 값에서 파생된 SPARQL 쿼리는 SELECT 절에서 this 변수를 프로젝션합니다.

이 절의 나머지 부분은 비규범적입니다.

다음 예는 SPARQL SELECT 쿼리를 기반으로 하는 제약 조건 구성 요소의 선언을 보여준다. 이는 3.1 SPARQL 기반 제약 조건의 예에 나온 예를 일반화한 변형이다. 해당 SPARQL 쿼리에는 두 개의 상수, 즉 특정 속성 ex:germanLabel과 언어 태그 de가 포함되어 있었지만, 이 예에서는 모든 속성을 언어 태그와 함께 정의할 수 있도록 제약 조건을 일반화한다. 실제로 제약 조건 구성 요소는 매개변수 술어를 셰이프에 추가하여(예: ex:lang "de") 적용되며, SHACL-SPARQL 프로세서는 SELECT 검증기를 실행하기 전에 이를 해당 SPARQL 변수(예: $lang)에 사전 바인딩한다. 제약 조건 구성 요소를 사용하면 이러한 시나리오를 일반화하여 상수가 사전 바인딩된 매개변수가 되도록 할 수 있다. 이를 통해 새로운 SPARQL을 작성하지 않고도 여러 위치에서 쿼리 논리를 재사용할 수 있다.

제약 조건 컴포넌트가 (도형 그래프에서) 선언되면 그 매개변수를 다음 예와 같이 사용할 수 있습니다. ex:lang을 포함하는 모든 속성 도형은 ex:LanguageConstraintComponentUsingSELECT을 사용하는 것으로 해석됩니다 ($lang을 해당 값에 바인딩함).

위의 예제 도형은 ex:germanLabel의 모든 값에 언어 태그 de가 지정되고 ex:englishLabel의 모든 값에는 언어로 en이 지정되어야 한다는 조건을 명시합니다. 이러한 세부 사항은 제약 조건 컴포넌트에 필요한 ex:lang 매개변수의 값을 갖는 두 속성 도형을 통해 명시됩니다.

4.2.3.2 ASK 기반 검증기

많은 제약 조건 구성 요소는 모든 값 노드를 특정 불리언 조건에 대해 개별적으로 검사하는 형식입니다. 이러한 구성 요소에 SELECT 쿼리를 작성하는 작업은 특히 제약 조건 구성 요소를 속성 도형과 노드 도형 모두에 사용할 수 있는 경우 번거롭습니다. SHACL-SPARQL은 ASK 쿼리를 기반으로 하는 검증기를 위한 더 간결한 대체 구문을 제공합니다.

SHACL 유형 sh:SPARQLAskValidator를 갖는 검증기를 ASK 기반 검증기라고 합니다. sh:validator의 값은 ASK 기반 검증기여야 합니다. ASK 기반 검증기는 sh:ask 속성에 대해 정확히 하나의 값을 갖습니다. sh:ask의 값은 데이터 유형이 xsd:string인 리터럴이어야 합니다. sh:ask의 값은 앞서 설명한 접두사 처리 규칙을 사용하는 유효한 SPARQL ASK 쿼리여야 합니다.

이 절의 나머지 부분은 비규범적입니다.

ASK 쿼리는 주어진 값 노드 (사전 바인딩된 변수 value로 나타냄)가 제약 조건을 준수하는 경우에만 true를 반환합니다.

다음 예시는 ASK 쿼리를 사용하는 제약 조건 구성 요소를 선언합니다.

ASK 쿼리가 구현하는 유효성 검사 조건은 대응하는 SELECT 쿼리와 비교하여 "반대 방향"이라는 점에 유의하십시오. ASK 쿼리는 제약 조건을 준수하는 값 노드에 대해 true를 반환하지만, SELECT 쿼리는 준수하지 않는 값 노드를 반환합니다.

4.3 SPARQL 기반 제약 조건 구성 요소를 사용한 유효성 검사

이 절에서는 SPARQL 기반 제약 조건 구성 요소의 검증기를 정의합니다. 이 검증기는 가능한 구현 전략 중 하나만 설명하며, 결과가 동등하다면 SHACL 프로세서는 다른 접근 방식을 선택할 수 있습니다.

첫 번째 단계로 4.2.3 검증기에 설명된 규칙에 따라 검증기를 선택해야 합니다. 그런 다음 다음 규칙을 적용하여 SPARQL 쿼리의 솔루션 집합을 생성합니다.

위 SPARQL 쿼리를 실행할 때는 3.3.1 SPARQL 제약 조건의 사전 바인딩된 변수 $this에 설명된 대로 변수 this를 사전 바인딩해야 합니다. 또한 제약 조건에 있는 제약 조건 구성 요소의 각 매개변수 값은 해당 매개변수 이름을 이름으로 갖는 변수로 사전 바인딩되어야 합니다.

유효성 검사 결과의 생성 규칙은 위에서 생성한 QS 솔루션을 사용한다는 점을 제외하면 SPARQL 기반 제약 조건의 생성 규칙과 동일합니다.

5. 주석 속성

이 절은 SPARQL 기반 constraints 또는 constraint components를 사용하여 validation results를 생성하는 일반 mechanism을 확장합니다.

이 기능을 지원하는 구현은 SPARQL 기반 constraint 또는 constraint component의 SELECT queries가 생성한 각 solution에 대해 만들어지는 validation result nodes에 annotation properties를 주입할 수 있게 합니다. 그러한 annotation property는 sh:select 또는 sh:ask triple의 subject에서 sh:resultAnnotation의 value를 통해 선언되어야 합니다.

sh:resultAnnotation의 values를 result annotations라고 하며, 이는 IRIs 또는 blank nodes입니다.

Result annotations는 다음 properties를 가집니다.

Property 요약 및 구문 규칙
sh:annotationProperty 설정되어야 하는 property입니다. 각 result annotation은 property sh:annotationProperty에 대해 정확히 하나의 value를 가지며, 이 value는 IRI입니다.
sh:annotationVarName annotation values를 가져올 SPARQL variable의 이름입니다. 각 result annotation은 property sh:annotationVarName에 대해 최대 1개의 value를 가지며, 이 value는 xsd:string datatype을 가진 literal입니다.
sh:annotationValue 기본값으로 사용되어야 하는 constant RDF terms입니다.

솔루션의 각 SELECT 결과 집합에 대해, 주석을 지원하는 SHACL 프로세서는 선언된 결과 주석을 따라갑니다. 결과 주석에서 SPARQL 변수로의 매핑은 다음 규칙을 사용합니다:

  1. sh:annotationVarName 속성의 값을 사용합니다
  2. 그러한 값이 없으면, sh:annotationProperty의 로컬 이름을 변수 이름으로 사용합니다.

변수 이름을 결정할 수 있으면, SHACL 프로세서는 현재 솔루션에 대해 생성되는 바인딩을 sh:annotationProperty를 사용하여 지정된 속성의 값으로 복사해 생성 중인 검증 결과에 넣습니다. 결과 집합 솔루션에서 해당 변수에 바인딩이 없으면, 존재할 경우 sh:annotationValue의 값을 사용합니다.

6. SPARQL 기반 노드 표현식

이 절에서는 SPARQL을 기반으로 하는 노드 표현식 함수를 소개합니다.

6.1 선택 표현식

sh:select에 대한 value를 가진 node expression을 function name sh:SelectExpression을 가진 select expression이라고 합니다.

RDF graph의 node는 blank node이며, predicate sh:select에 대해 정확히 하나의 value를 가지고, 이 value가 xsd:string datatype을 가진 literal인 경우, well-formed select expression입니다. well-formed select expression은 property sh:prefixes에 대해 최대 하나의 value를 가질 수 있으며, 이 value는 IRI 또는 blank node일 수 있습니다.

prefix handling rules를 사용하면, sh:select의 value는 유효한 SPARQL 1.2 SELECT query입니다. sh:select의 value에서 파생된 SPARQL query는 SELECT clause에서 정확히 하나의 variable을 projects합니다.

SELECT EXPRESSIONS의 평가

출력 노드는 select expression의 것으로, 쿼리가 포커스 그래프에 대해 평가될 때 SELECT 절에서 투영된 (유일한) 변수의 바인딩으로만 이루어진 목록 resultNodes입니다. focusNode의 값은 SPARQL 변수 this의 값으로 사전 바인딩됩니다. 각 범위 변수의 값은 동일한 이름과 값을 가진 SPARQL 변수로 사전 바인딩됩니다. 범위 내 변수의 이름이 문자열 리터럴이 아니면 "arg" + str(name)을 사용합니다. 예를 들어, 변수 이름이 "0"^^xsd:integer이면 arg0을 사용합니다. 범위 변수 중 하나가 this로 불리면 실패가 생성됩니다.

evalExpr(expr, focusGraph, focusNode, scope) -> resultNodes

이 절의 나머지는 비규범입니다.

6.2 SPARQL Expr 표현식

sh:sparqlExpr에 대한 value를 가진 node expression을 function name sh:SPARQLExprExpression을 가진 SPARQL expr expression이라고 합니다.

RDF graph의 node는 blank node이며, predicate sh:sparqlExpr에 대해 정확히 하나의 value를 가지고, 그 value가 xsd:string datatype을 가진 literal인 경우, well-formed SPARQL expr expression입니다. well-formed SPARQL expr expression은 property sh:prefixes에 대해 최대 하나의 value를 가질 수 있으며, 이 value는 IRI 또는 blank node입니다.

$EXPR$를 sh:eval의 value라고 하고, $PREFIXES$를 sh:prefixes의 value를 사용하여 prefix handling rules에서 나온 SPARQL prefixes block이라고 하면, select는 $EXPR$와 $PREFIXES$가 다음에 삽입된 문자열로 정의됩니다.

$PREFIXES$ SELECT ($EXPR$ AS ?result) WHERE {}

 select는 유효한 SPARQL 1.2 SELECT query입니다.

SPARQL EXPR EXPRESSIONS의 평가

출력 노드는 SPARQL expr expression의 것으로, 위에서 정의한 select 쿼리의 SELECT 절에서 투영된 (유일한) 변수의 바인딩으로만 이루어진 목록 resultNodes입니다. 쿼리가 포커스 그래프에 대해 평가될 때, focusNode의 값은 SPARQL 변수 this의 값으로 사전 바인딩됩니다. 각 범위 변수의 값은 동일한 이름과 값을 가진 SPARQL 변수로 사전 바인딩됩니다. 범위 내 변수의 이름이 문자열 리터럴이 아니면 "arg" + str(name)을 사용합니다. 예를 들어, 변수 이름이 "0"^^xsd:integer이면 arg0을 사용합니다. 범위 변수 중 하나가 this로 불리면 실패가 생성됩니다.

evalExpr(expr, focusGraph, focusNode, scope) -> resultNodes

이 절의 나머지는 비규범입니다.

7. 노드 표현식을 기반으로 한 SPARQL 함수 선언

SHACL 1.2 Node Expressions는 새로운 노드 표현식 함수를 선언하기 위한 메커니즘으로 커스텀 리스트 파라미터 함수를 정의합니다. 이러한 함수는 다른 SHACL 노드 표현식의 일부로 평가될 수 있으며, 함수와 유사한 실행을 지원하는 다른 엔진에도 유용할 수 있습니다.

SPARQL 사양은 일부 SPARQL 엔진이 추가 SPARQL 함수를 제공할 수 있도록 하는 확장 지점을 정의합니다. 이 절은 SPARQL 프로세서가 해당 확장 지점을 사용하여 SHACL 리스트 파라미터 함수를 SPARQL 함수로 사용할 수 있게 하는 선언적 메커니즘을 소개합니다.

7.1 일반 노드 표현식을 사용하는 SPARQL 함수 예시

7.2 SPARQL 기반 노드 표현식을 사용하는 SPARQL 함수 예시

다음의 커스텀 리스트 파라미터 함수들은 평가 시 "중첩된" SPARQL 쿼리를 사용합니다.

다음 예시는 본문으로 sh:select 노드 표현식을 사용합니다.

7.3 사용자 정의 SPARQL 함수의 평가

이 문서는 이러한 사용자 정의 SPARQL 함수가 언제 그리고 어떻게 추가되는지에 대한 정확한 제약을 정의하지 않습니다. 권장 사항은 SPARQL 엔진이 제공된 SHACL 인스턴스에 대해 sh:ListParameterExpressionFunction의 모든 것에 대한 함수를 shapes graph에서 등록해야 한다는 것입니다. 동일한 IRI를 가진 함수가 이미 등록되어 있다면, SHACL 엔진은 해당 함수를 이전에 사용자 정의 SPARQL 함수로 추가한 경우가 아니면 재정의하려는 시도를 무시해야 합니다. SPARQL 엔진은 SPARQL 쿼리를 실행하는 동안 등록된 SPARQL 함수를 수정해서는 안 됩니다.

사용자 정의 SPARQL 함수의 평가

f를 SPARQL 함수 호출의 iri라고 하고, args를 Expression 인자들의 목록이라고 합시다. function을 f를 그래프에서 IRI로 갖는 대응하는 사용자 정의 리스트 파라미터 함수라고 합시다.

각 SPARQL 표현식에 대해 args를 평가하여, 노드들의 새로운 목록 nodesList를 생성합니다. 평가 중 오류가 발생하면, 해당 SPARQL 함수 호출의 결과도 오류가 되며, 해당 인자에 대응하는 sh:parameter가 sh:optional true가 아닌 한 그렇습니다. 그 경우 그 인자는 scope에서 unbound 상태가 됩니다.

현재 활성 SPARQL 컨텍스트의 쿼리 그래프를 focusGraph로, 그리고 nodesList에서 평가된 인자들을 인덱스를 변수 이름(map key)으로 하는 맵을 scope로 할 때, evalExpr(function, focusGraph, f, scope)의 출력 노드를 rs라고 합시다.

출력 노드 목록 rs가 정확히 하나의 원소를 가지면 그 노드를 반환합니다. 그렇지 않거나, 평가가 평가 실패를 생성하면, SPARQL 함수 호출의 결과는 오류입니다.

Note

SPARQL 쿼리의 평가 중에는 전용 포커스 노드가 없습니다. 대신 노드 표현식을 기반으로 한 사용자 정의 SPARQL 함수에 전달되는 focusNode는 함수 자체의 IRI입니다.

8. SPARQL 기반 추론 규칙

SHACL은 노드 집합에 적용되는 shape - 제약들의 집합 - 을 설명하기 위한 RDF 어휘를 정의합니다. Shape는 유연한 타깃 메커니즘을 사용하여 노드와 연관될 수 있으며, 예를 들어 어떤 클래스의 모든 인스턴스에 적용할 수 있습니다. SHACL의 한 핵심 영역은 데이터 검증입니다. 그러나 shape에서 데이터 패턴을 설명하는 동일한 원리는 다른 목적에도 활용될 수 있습니다. SHACL rules는 SHACL을 기반으로 하여 기존 asserted triple로부터 추론된 RDF triple을 도출하기 위한 경량 RDF 어휘를 형성합니다.

본 절에서 정의하는 SHACL 규칙 기능은 sh:rule 및 sh:condition과 같은 속성을 사용하는 일반적인 프레임워크와, 특정 규칙 유형을 위한 확장 메커니즘을 포함한다. 이 문서는 이러한 규칙 유형 두 가지를 정의한다: SPARQL 규칙 및 트리플 규칙.

8.1 SHACL Rules 예시

이 절은 비규범적입니다.

다음 예시는 SPARQL rule의 간단한 사용 사례를 보여줍니다. 이 rule은 클래스 ex:Rectangle의 모든 인스턴스에 적용되며, 직사각형의 너비와 높이를 곱하여 ex:area 속성 값을 계산합니다:

이러한 rule을 실행할 수 있는 엔진은 shapes graph에 연결된 shape들의 target 진술을 사용하여 어떤 rule을 어떤 target node에 대해 실행해야 하는지 결정합니다. 해당 target node가 어떤 조건 shape에도 적합한 경우, 제공된 CONSTRUCT 쿼리를 실행하여 추론된 triple을 생성합니다. 쿼리 실행 중 변수 this는 현재 포커스 노드가 사전 바인딩된 값입니다.

다음 데이터 graph에 대해, 아래의 triples가 생성됩니다.

8.2 SHACL Rules의 일반 정의

SHACL 인스턴스 중 sh:Rule의 인스턴스(하위 클래스인 sh:SPARQLRule 및 sh:TripleRule 포함)는 SHACL 규칙이라고 한다. SHACL은 여러 유형의 규칙을 지원할 수 있는 유연하고 확장 가능한 설계를 가지지만, 이 문서에서는 그중 두 가지인 SPARQL 규칙 및 트리플 규칙만 정의한다. 각 규칙 유형은 해당 유형의 rdf:type으로 사용되는 IRI로 식별된다. 각 규칙 유형은 또한 규칙 엔진에서 구현할 수 있는 실행 지침을 정의한다.

각 SHACL rule은 적어도 하나의 rdf:type 을 가지며, 이는 IRI여야 합니다.

rule은 여러 type을 가질 수 있습니다. 예를 들어, 엔진의 기능에 따라 SPARQL 또는 JavaScript 중 하나로 작동하는 지침을 제공할 수 있습니다. 그러한 rule의 작성자는 해당 rule들이 일관된 의미를 갖도록 보장해야 합니다. rule R은 R이 T의 SHACL 인스턴스이면 rule type T를 갖습니다.

8.2.1 규칙 집합

SHACL 규칙 프로세서의 입력은 규칙 집합이라고 하는 규칙의 집합이다. 규칙 집합은 IRI로 식별된다. 속성 sh:hasRule은 규칙 집합에 주어진 규칙이 구성원으로 포함되어 있음을 선언하는 데 사용할 수 있다. 그래프의 기본 규칙 집합은 그래프에 있는 모든 규칙의 집합이다. 규칙 집합은 속성 sh:includesRuleSet을 사용하여 다른 규칙 집합을 (전이적으로) 포함할 수 있다.

SHACL 인스턴스 중 sh:RuleSet의 인스턴스는 모두 IRI를 가진다. 규칙 집합은 값을 sh:hasRule에 대해 가질 수 있으며, 그 값은 규칙이다. 값은 sh:includesRuleSet에 대해 규칙 집합에 지정된 경우 IRI이다.

8.2.2 셰이프 규칙 및 전역 규칙 (sh:rule)

속성 sh:rule은 셰이프 (주어)를 셰이프 규칙 (목적어)과 연결하는 데 사용할 수 있다. 주어는 sh:rule 트리플에서 IRI이다.

SHACL 규칙은 다음 두 범주로 나눌 수 있다:

  • 셰이프 규칙은 규칙이며, 해당 규칙은 목적어로서 sh:rule 트리플에 나타난다. 셰이프 규칙은 대상 노드 모두에 대해 실행된다. 이 노드들은 셰이프의 대상이며, 그 셰이프는 주어로서 sh:rule 트리플에 나타난다.
  • 전역 규칙은 규칙이며, 연결되지 않은 규칙으로, 셰이프와의 연결에 sh:rule 술어가 사용되지 않는다.

셰이프 규칙의 예는 위의 예제 16에 제시되어 있다.

다음 예제는 전역 규칙을 보여 준다.

8.2.3 셰이프 규칙의 조건 (sh:condition)

셰이프 규칙은 속성 sh:condition에 대한 값을 가질 수 있으며, 이 값은 셰이프를 지정한다. 대상 노드는 해당 규칙의 포커스 노드가 되기 전에 이 셰이프를 준수해야 한다.

sh:condition의 값은 규칙에서 올바른 형식의 셰이프여야 한다.

sh:condition의 값 C가 SHACL 인스턴스로서 sh:NodeShape 및 rdfs:Class 모두의 인스턴스인 경우, 포커스 노드는 제약 조건도 준수해야 한다. 이는 비활성화되지 않은 SHACL 상위 클래스 중 C의 상위 클래스이면서 SHACL 인스턴스로서 sh:NodeShape와 rdfs:Class 모두의 인스턴스인 것들의 제약 조건이다. 이는 검증 중 암시적 클래스 대상이 해석되는 방식과 유사하다.

8.2.4 비활성화된 규칙 (sh:deactivated)

규칙은 sh:deactivated를 true로 설정하여 비활성화할 수 있다. 비활성화된 규칙은 규칙 엔진에서 무시된다.

각 규칙은 속성 sh:deactivated에 대해 최대 하나의 값을 가질 수 있다. sh:deactivated의 값은 xsd:boolean 리터럴 true 또는 false 중 하나이다.

8.2.5 규칙을 계층으로 그룹화 (sh:layer)

규칙은 숫자 값으로 식별되는 계층으로 그룹화할 수 있다. 실행 중 SHACL 규칙 엔진은 동일한 계층의 모든 규칙을 반복 처리한 후 다음 계층으로 이동한다. 숫자 값이 작은 계층은 값이 큰 계층보다 먼저 실행된다.

각 규칙은 속성 sh:layer에 대해 최대 하나의 값을 가질 수 있다. 규칙에서 sh:layer의 값은 리터럴이며 데이터 타입은 xsd:integer이다.

지정하지 않으면 규칙의 기본 계층은 0이다.

규칙의 실행 순서를 제어하기 위해 sh:layer를 사용하는 예는 예제 21에 제시되어 있다.

8.2.6 규칙의 순서 지정 (sh:order)

규칙은 이 섹션에서 정의한 대로 동일한 실행 순서를 동일한 계층 내에서 상대적으로 지정할 수 있다.

각 규칙은 속성 sh:order에 대해 최대 하나의 값을 가질 수 있다. 규칙에서 sh:order의 값은 리터럴이며 데이터 타입은 xsd:decimal 또는 xsd:integer이다.

지정하지 않으면 기본 실행 순서는 0이다. 규칙이 실행될 때 동일한 계층 내에서 순서 값이 큰 규칙은 순서 값이 작은 규칙보다 나중에 실행된다.

8.2.7 일회 실행 규칙 (sh:runOnce)

SHACL 규칙 엔진은 규칙을 반복 처리하여 더 이상 트리플이 추론되지 않을 때까지 동일한 규칙을 여러 번 실행할 수 있게 한다. 그러나 일부 규칙은 실행할 때마다 새로운 빈 노드를 생성하여 무한 반복을 일으킬 수 있다.

규칙은 속성 sh:runOnce을 사용하여 해당 규칙을 한 번만 실행하고 동일한 계층의 다른 규칙보다 먼저 실행하도록 규칙 엔진에 지시할 수 있다.

각 규칙은 속성 sh:runOnce에 대해 최대 하나의 값을 가질 수 있다. 규칙에서 sh:runOnce의 값은 리터럴이며 데이터 타입은 xsd:boolean이다.

일회 실행 규칙은 최대 한 번 실행되는 규칙이다(셰이프마다 한 번, 셰이프 규칙인 경우). 그 밖의 모든 규칙은 반복 규칙이라고 한다. 규칙의 sh:runOnce에 대한 값이 true이면 해당 규칙은 일회 실행 규칙이다.

8.2.8 예상 파생 트리플 (sh:expectedPredicate)

SHACL 코어에는 데이터 그래프에 반드시 명시되어 있지는 않은 속성 값을 파생하기 위한 다음 속성이 포함되어 있다:

  • sh:defaultValue는 속성에 다른 값이 없을 때 어떤 값을 사용해야 하는지 정의한다. 예를 들어 ex:childCount의 기본값은 0일 수 있다.
  • sh:values는 속성의 파생 값을 계산하기 위한 일반적인 지침을 정의한다. 예를 들어 직사각형의 ex:area는 ex:width와 ex:height를 곱하여 파생할 수 있다.

두 속성 모두 노드 표현식을 사용할 수 있으며, 여기에는 SHACL 1.2 노드 표현식에 정의된 표현식도 포함된다. 두 속성 모두 주어진 목적어를 계산하는 데만 사용할 수 있으며, 해당 술어는 주어에 대해 계산되고 그 주어는 셰이프의 대상이다. 이는 sh:defaultValue와 sh:values가 규칙이 생성하는 추론과 유사한 암시적 트리플을 설명한다는 의미이다.

규칙이 특정 속성을 참조할 때는 규칙이 이러한 암시적 트리플이 존재할 것으로 예상하는 것이 합리적이다. 이 섹션에서는 규칙이 실행되기 전에 그러한 파생 트리플이 존재하도록 보장하는 방법을 설명한다.

주어진 술어 p에 대해 파생 값 노드는 모든 값 노드이며, sh:defaultValue와 sh:values를 사용하여 계산할 수 있다. 이는 SHACL 1.2 코어에서 정의한 대로 모든 (비활성화되지 않은) 속성 셰이프 중 셰이프 그래프에서 p를 sh:path로 사용하는 셰이프에 적용된다. 이러한 파생 값 노드 v에 대한 파생 트리플은 트리플이며, 여기서 v는 목적어이고, p는 술어이며, 주어는 속성 셰이프의 대상 노드이다.

규칙의 예상 파생 트리플은 파생 트리플이며, 값은 모두 해당 규칙의 속성 sh:expectedPredicate에 지정된 값이다. 이 모든 내용은 예제로 설명하는 것이 가장 좋다:

SHACL 규칙 엔진은 각 계층의 처리가 끝날 때 추론 결과에서 파생 트리플을 제거한다. 단, 규칙에 의해서도 추론된 트리플은 제외한다. 일부 엔진에는 모든 파생 트리플을 유지하는 설정이 있을 수 있다. 예를 들어 SHACL을 지원하지 않는 시스템으로 데이터를 내보낼 때 사용할 수 있다.

8.3 Rules Graph

rules graph은 shapes graph로, SHACL rules를 포함합니다.

sh:RulesGraph class는 일반적으로 rules graph 역할을 하는 graph의 IRI의 rdf:type으로 MAY 사용될 수 있습니다.

이 절의 나머지는 비규범적입니다.

graph type class(sh:DataGraph, sh:ShapesGraph, sh:RulesGraph)는 서로 배타적이지 않은 역할을 나타내며, 단일 graph는 이들 중 둘 이상으로 type될 수 있습니다. rules graph는 다른 graph에 정의된 shape를 참조하는 sh:rule triple을 포함할 수 있어, rules를 shape 및 ontology 정의와 독립적으로 관리할 수 있게 합니다.

8.4 sh:Rules entailment regime

SHACL은 shapes graph를 entailment regimes와 연결하기 위한 속성 sh:entailment를 정의합니다. IRI sh:Rules는 SHACL rules entailment regime를 나타냅니다. 다음 예에서 shapes graph는 SHACL validation engine에게 shapes graph 내부의 SHACL rules를 validation을 시작하기 전에 실행해야 한다고 알려줍니다. 

<http://example.org/my-shapes>
	a owl:Ontology ;
	sh:entailment sh:Rules .

SHACL의 일반 정책에 따라, SHACL rules entailment regime를 지원하지 않는 validation engine은 이 triple이 존재하면 failure를 보고해야 합니다. 이 entailment regime를 지원하는 validation engine은 실제 validation을 수행하기 전에 rules execution instructions를 따라 rules를 실행합니다.

8.5 Temporary Triples

추론 rule이 최종 추론에는 남지 않지만 다른 rule 실행 중에만 보이는 triple을 생성하는 것이 때때로 유용합니다. temporary triple은 추론 graph에 reifier가 있고 그 value가 sh:tempTriple true인 추론된 triple입니다. Temporary triples와 그 reifiers는 실행 중인 rules에 보입니다. Rules는 다음 예시처럼 이러한 triple을 생성할 수 있습니다:

temporary triple을 만드는 것은 계산이 단일 rule로 수행하기에는 너무 복잡할 때 유용할 수 있습니다. 복잡한 계산은 여러 rule로 분해할 수 있습니다: 일부 rule은 부분 결과를 추론하고, 다른 rule은 그 부분 결과로부터 최종 결과를 도출합니다. 부분 결과는 최종 결과 계산에만 필요하고 이후에는 더 이상 필요하지 않습니다. 이러한 부분 결과를 temporary triple로 표시하면 최종 결과를 계산한 후 자동으로 제거됩니다.

8.6 SHACL Rules의 일반 실행 지침

SHACL 규칙 엔진은 입력으로 데이터 그래프, 셰이프 그래프 및 선택적인 규칙 집합(기본값은 기본 규칙 집합이며, 이는 셰이프 그래프의 기본 규칙 집합임)을 받는 컴퓨터 절차이며, 트리플을 데이터 그래프에 추가할 수 있다. 규칙 엔진이 생성하는 새로운 트리플을 추론된 트리플이라고 한다.

논리적 관점에서 데이터 그래프는 트리플이 추론되면 수정된다는 점에 유의한다. 이는 다른 트리플이 추론된 후에 규칙이 작동할 수 있음을 의미한다. 그러나 원본 데이터를 수정해서는 안 되는 경우 구현은 원본 데이터를 하나의 하위 그래프로 갖고 전용 추론 그래프를 또 다른 하위 그래프로 갖는 논리적 데이터 그래프를 구성할 수 있으며, 추론된 트리플은 추론 그래프에만 추가된다.

규칙의 실행은 해당 규칙으로부터 추론된 트리플을 생성하는 절차이며, 그 규칙의 규칙 유형에 대한 실행 지침을 기반으로 한다. 규칙이 셰이프 규칙인 경우(즉, sh:rule을 통해 하나 이상의 셰이프에 연결된 경우), 해당 규칙은 각 대상 노드에 대해 실행된다. 이 대상 노드는 연결되어 있고 비활성화되지 않은 셰이프 각각의 대상이며, 해당 셰이프는 모든 조건을 준수한다. 이 조건들은 규칙의 모든 비활성화되지 않은 조건으로서 규칙에 지정되어 있다. 이러한 대상 노드는 실행 중인 셰이프 규칙의 포커스 노드가 된다.

셰이프 그래프에 있는 주어진 규칙 집합에 대해 반복은 각 개별 규칙을 한 번씩 실행하는 것으로, 8.2.6 규칙의 순서 지정 (sh:order)에 지정된 순서를 따르며 비활성화된 규칙은 건너뛴다. 반복 내에서는 한 규칙의 추론된 트리플이 다음 규칙에 즉시 표시된다.

규칙 집합의 실행은 다음과 같이 정의된다: 

규칙 집합의 모든 계층에 대해(오름차순):
	계층의 모든 규칙에 대한 예상 파생 트리플을 계산한다
	계층의 모든 일회 실행 규칙에 대해 한 번 반복한다
	다음을 수행한다
		계층의 모든 반복 규칙에 대해 한 번 반복한다
	반복에서 새로 추론된 트리플이 생성되는 동안
	파생 트리플(규칙에 의해서도 추론된 트리플 제외)과
	  해당 구체화자를 삭제한다

임시 트리플과 해당 구체화자를 삭제한다

규칙 중 하나라도 실행 중 실패를 보고하면, 규칙 집합의 실행도 실패를 생성한다.

규칙 엔진이 주어진 규칙을 실행할 수 없고, 그 이유가 해당 규칙의 규칙 유형을 하나도 지원하지 않기 때문이라면, 규칙 엔진은 실패를 보고한다.

규칙 엔진은 다음 경우에도 실패를 보고할 수 있다: 미리 구성된 최대 반복 횟수를 초과했거나, 미리 구성된 최대 개수의 추론된 트리플이 생성된 경우이다. 이는 메모리 부족 문제와 무한 루프를 방지하는 보호 장치로 도움이 될 수 있다.

추론된 트리플은 어떤 시점에도 셰이프 그래프에 표시되지 않는다. 즉, 규칙이 규칙 또는 셰이프의 정의를 수정하는 것은 불가능하다.

8.7 triple을 생성한 rule 추적 (sh:sourceRule)

Rule engine은 추론된 triple을 어떤 rule이 생성했는지 추적하는 데 사용할 수 있는 추가 triple을 생성하는 옵션을 가질 수 있습니다. 속성 sh:sourceRule은 inferences graph에 있는 triple의 reifier에서 그 triple과 rule을 연결하는 데 사용할 수 있습니다. sh:sourceRule의 값은 SHOULD IRI여야 합니다.

다음 예시는 triple ex:Alice ex:friend ex:Bob이 rule ex:SymmetricPropertyRule에 의해 추론되었음을 나타냅니다. 

<< ex:Alice ex:friend ex:Bob >> sh:sourceRule ex:SymmetricPropertyRule .

RDF triple로 완전히 확장하면 다음과 동등합니다: 

_:id rdf:reifies <<( ex:Alice ex:friend ex:Bob )>> .
_:id sh:sourceRule ex:SymmetricPropertyRule .

Rule engine이 이러한 triple을 추가하는 경우, 그 triple은 실행 중인 rules에 보이면 안 됩니다.

8.8 SHACL Rule 구현의 변형

위에서 설명한 일반 실행 알고리즘은 의도적으로 일반적으로 유지되어 특정 구현에 많은 유연성을 제공합니다. 특히, rule의 순서가 명시적으로 지정되지 않으면 결과가 실행마다 다를 수 있다는 점에서 알고리즘은 비결정적입니다. 이는 예를 들어, rule이 특정 triple의 개수로부터 결론을 도출하지만 그 triple이 다른 rule에 의해 생성될 수 있는 경우에 해당합니다. 이 문서에서는 예측 가능한 순서와 layering/grouping을 생성하는 책임을 rule 작성자에게 맡깁니다.

일부 SHACL rule 구현은 sh:runOnce를 무시한 run-once rules, sh:order를 무시한 rule order, sh:layer를 무시한 stata를 결정하기 위해 다른 알고리즘을 구현할 수 있습니다. 이는 예를 들어 rule 의존성을 자동으로 계산할 수 있는 SHACL rule의 제어된 하위 집합을 지원하는 엔진에 사용할 수 있습니다. 또 다른 예로는 rule이 blank node를 생성해 무한 루프를 자동으로 방지하는 rule engine이 있습니다. 이러한 구현은 명시적으로 주어진 sh:order, sh:runOnce, sh:layer 값에만 의존하는 구현과 다른 결과를 낼 수 있습니다.

일부 SHACL rule 구현은 기본 알고리즘이 보고하지 않는 추가 failure도 보고할 수 있습니다.

Issue 1073: 규칙: SPARQL-Full과 SPARQL-RL SPARQLSRLSHACL 규칙

이는 이것이 SHACL Rules 변형이 된다면, 진행 중인 SRL 작업을 교차 참조하기에 좋은 위치가 될 것입니다.

8.9 SPARQL Rules

이 절은 SPARQL rules라는 rule type를 정의하며, 이는 sh:SPARQLRule IRI로 식별됩니다. SPARQL rules는 다음 속성을 가집니다:

Property Summary and Syntax Rules
sh:construct SPARQL CONSTRUCT query입니다. SPARQL rules는 sh:construct 속성에 대해 정확히 하나의 value를 가져야 합니다. sh:construct의 값은 datatype이 xsd:string인 literals입니다.
sh:prefixes sh:construct를 SPARQL query로 바꾸는 데 사용할 prefixes입니다. SPARQL rules는 Prefix Declarations for SPARQL Queries 메커니즘에 기반한 prefixes 의존성을 선언하기 위해 sh:prefixes 속성을 사용할 수 있습니다. 이 메커니즘은 사용자가 sh:construct 문자열에서 URI를 줄여 쓸 수 있게 합니다.
SPARQL RULES의 실행
Q를 shapes graph의 SPARQL rule에 있는 sh:construct와 sh:prefixes 속성 값들로부터 파생된 SPARQL CONSTRUCT query라고 합시다.
Note

global SPARQL rules는 pre-binding을 사용하지 않으므로, A. SPARQL 쿼리에서 변수의 사전 바인딩에 언급된 syntax 제한은 적용되지 않습니다.

8.10 트리플 규칙

이 절에서는 규칙 유형이라고 하는 트리플 규칙을 정의하며, 이는 IRI sh:TripleRule로 식별된다. 트리플 규칙은 다음 속성을 가진다:

속성 요약 및 구문 규칙
sh:subject 노드 표현식은 트리플의 주어를 계산하는 데 사용된다. 각 트리플 규칙은 sh:subject 속성의 값을 최대 하나만 가져야 한다(해당 값은 올바른 형식의 노드 표현식이어야 한다).
sh:predicate 노드 표현식은 트리플의 술어를 계산하는 데 사용된다. 각 트리플 규칙은 sh:predicate 속성의 값을 최대 하나만 가져야 한다(해당 값은 올바른 형식의 노드 표현식이어야 한다).
sh:object 노드 표현식은 트리플의 목적어를 계산하는 데 사용된다. 각 트리플 규칙은 sh:object 속성의 값을 최대 하나만 가져야 한다(해당 값은 올바른 형식의 노드 표현식이어야 한다).
트리플 규칙의 실행
S, P 및 O를 각각 sh:subject, sh:predicate 및 sh:object의 값인 노드 표현식을 트리플 규칙에서 평가하여 생성된 노드 집합이라고 하자. sh:subject, sh:predicate 또는 sh:object가 없는 경우 현재 초점 노드로 구성된 목록을 사용한다 (전역 규칙에서는 비어 있다). S의 구성원 s, P의 구성원 p 및 O의 구성원 o의 각 조합에 대해 추론하여 트리플을 생성한다. 이 트리플은 주어 s, 술어 p 및 목적어 o를 가진다. 잘못된 형식의 트리플은 건너뛴다. 예를 들어 빈 노드가 술어로 사용되는 경우가 이에 해당한다.

부록

A. SPARQL Queries에서 Variables의 사전 바인딩

SHACL-SPARQL의 일부 기능은 이 절에서 정의하는 변수의 사전 바인딩 개념에 의존한다.

(위험 기능) 이슈 999: SPARQL 1.2에 맞게 사전 바인딩 업데이트 SPARQL

이 기능은 "위험 상태"이며 이 영역에서 현재 진행 중인 RDF 및 SPARQL 1.2 작업에 맞추기 위해 변경될 수 있다(제거되지는 않는다). 원래 이슈 647에서 논의되었다.

SHACL에서 사용하는 사전 바인딩의 정의는 SPARQL 쿼리에 다음과 같은 제한을 요구한다. SHACL-SPARQL 프로세서는 사전 바인딩된 변수로 실행되며 이러한 "반드시" 제한 중 하나라도 위반하는 SHACL-SPARQL 쿼리(sh:ask, sh:construct 및 sh:select를 통해)를 포함하는 도형 그래프를 처리할 때 실패를 반드시 보고해야 한다. 사전 바인딩될 가능성이 있는 변수라는 용어에는 변수 this, value(ASK 쿼리의 경우), 그리고 해당 쿼리를 사용하는 제약 조건 구성요소의 매개변수를 나타내는 모든 변수가 포함된다는 점에 유의한다.

또한 SPARQL 쿼리는 연합 쿼리(SERVICE)를 포함하지 않는 것이 좋다. SERVICE를 허용하지 않는 구현은 위에서 언급한 대로 실패를 반드시 보고해야 한다. 그러나 일부 SPARQL 구현은 특정한(일반적으로 로컬) 작업의 구문으로 SERVICE 키워드를 사용하므로 이 키워드가 일반적으로 금지되는 것은 아니다.

정의: Values Insertion

solution mapping μ에 대해, Table(μ)를 μ에서 형성된 multiset으로 정의합니다.

   Table(μ) = { μ }
   Card[μ] = 1

Values Insertion 함수 Replace(X, μ)를 X 안에 있는 Basic Graph Pattern, Property Path Expression, Graph(Var, pattern)의 각 발생 Y를 join(Y, Table(μ))로 바꾸는 것으로 정의합니다.

정의: variables의 사전 바인딩

pre-bound variables μ를 가진 SPARQL Query Q = (E, DS, QF)의 평가는 SPARQL query Q' = (Replace(E, μ), DS, QF)의 평가로 정의됩니다.

B. SHACL 구문 규칙 요약

이 절은 SHACL의 모든 규범적 구문 규칙을 열거합니다. 이 절은 이 명세의 다른 부분에서 자동으로 생성되며, 규칙의 맥락이 불명확한 경우 본문으로 돌아가는 hyperlinks가 제공됩니다. shapes graph에서 이러한 규칙을 위반하는 nodes는 ill-formed입니다.

Syntax Rule Id Syntax Rule Text
prefix-count Prefix declarations은 sh:prefix 속성에 대해 정확히 하나의 값을 가져야 합니다.
prefix-datatype sh:prefix의 값은 datatype이 xsd:string인 literals입니다.
namespace-count Prefix declarations은 sh:namespace 속성에 대해 정확히 하나의 값을 가져야 합니다.
namespace-datatype sh:namespace의 값은 datatype이 xsd:anyURI 또는 xsd:string인 literals입니다.
declare-nodeKind sh:declare 속성의 values는 prefix declarations입니다
prefixes-nodeKind sh:prefixes의 값은 IRIs 또는 blank nodes 중 하나입니다.
prefixes-duplicates SHACL processor는 values인 모든 개별 prefix mapping의 합집합으로 prefix mapping 집합을 수집합니다. 이는 SPARQL property path sh:prefixes/(^owl:versionIRI?/owl:imports)*/sh:declare of the SPARQL-based constraint 또는 validator의 values입니다. ^owl:versionIRI? element는 version IRI로 가져온 graph를 지원하며, 이후의 owl:imports를 따르기 전에 version IRI에서 shapes graph IRI로 이동합니다. 이러한 prefix declarations 집합이 동일한 sh:prefix 값에 대해 여러 다른 namespace를 포함한다면, shapes graph는 ill-formed입니다.
sparql-nodeKind Shapes는 sh:sparql 속성에 대한 값을 가질 수 있으며, 그 값은 IRIs 또는 blank nodes 중 하나입니다.
SPARQLConstraint-select-count SPARQL-based constraints은 sh:select 속성에 대해 정확히 하나의 value를 가져야 합니다
SPARQLConstraint-select-datatype sh:select의 값은 datatype이 xsd:string인 literal입니다.
select-query-valid prefix handling rules를 사용하면, sh:select의 값은 유효한 SPARQL 1.2 SELECT query입니다.
select-query-this sh:select의 값으로부터 파생된 SPARQL query는 SELECT clause에서 변수 this를 project합니다.
SPARQLConstraint-message-datatype SPARQL-based constraints은 sh:message 속성에 대한 값을 가질 수 있으며 그 값은 datatype이 xsd:string, rdf:dirLangString, rdf:langString, 또는 rdf:HTML인 literals입니다. 동일한 언어 태그를 가진 sh:message 값이 둘 이상 있어서는 안 되며, datatype이 xsd:string인 값도 여러 개 있어서는 안 됩니다.
SPARQLConstraint-deactivated-maxCount SPARQL-based constraints은 sh:deactivated 속성에 대해 최대 하나의 값을 가질 수 있습니다
SPARQLConstraint-severity SPARQL-based constraints은 sh:severity 속성에 대해 최대 하나의 값을 가질 수 있으며 그 값은 IRI입니다.
PATH-position SPARQL-based constraints 및 SELECT-based validators의 SPARQL query에서 변수 PATH를 합법적으로 사용할 수 있는 유일한 위치는 predicate 위치의 triple pattern입니다.
ConstraintComponent SPARQL-based constraint component는 IRI이며, shapes graph에서 SHACL type sh:ConstraintComponent를 가집니다.
Parameter-predicate-count 각 parameter declaration은 sh:path 속성에 대해 정확히 하나의 값을 가집니다
Parameter parameter declarations에서 sh:path의 값은 IRI입니다.
parameter-name-VARNAME 모든 parameter name은 유효한 SPARQL VARNAME입니다.
parameter-name-not-in Parameter names은 다음 중 하나여서는 안 됩니다: this, path, PATH, value.
parameter-name-unique 둘 이상의 parameter declarations가 동일한 parameter names를 사용하는 constraint component는 ill-formed입니다.
optional-datatype sh:optional의 값은 datatype이 xsd:boolean인 literal이어야 합니다.
optional-maxCount parameter declaration은 sh:optional 속성에 대해 최대 하나의 값을 가질 수 있습니다.
ConstraintComponent-parameter 모든 constraint component는 적어도 하나의 비선택적 매개변수를 가집니다.
Parameter-conformance 매개변수에 대해 선언된 제약을 충족하지 않는 Shapes는 ill-formed입니다.
labelTemplate-datatype sh:labelTemplate의 값은 문자열입니다(언어 태그가 있을 수 있음)
nodeValidator-class sh:nodeValidator의 값은 SELECT-based validators여야 합니다.
propertyValidator-class sh:propertyValidator의 값은 SELECT-based validators여야 합니다.
SPARQLSelectValidator-select-count SELECT-based validators는 sh:select 속성에 대해 정확히 하나의 값을 가져야 합니다.
validator-class sh:validator의 값은 ASK-based validators여야 합니다.
ask-count ASK-based validators는 sh:ask 속성에 대해 정확히 하나의 값을 가져야 합니다
ask-datatype sh:ask의 값은 datatype이 xsd:string인 literal이어야 합니다.
ask-sparql sh:ask의 값은 앞서 언급한 prefix handling rules를 사용한 유효한 SPARQL ASK query여야 합니다.
resultAnnotation-nodeKind sh:resultAnnotation의 values는 result annotations라고 불리며, IRIs 또는 blank nodes입니다
annotationProperty 각 result annotation은 sh:annotationProperty 속성에 대해 정확히 하나의 value를 가지며, 이 값은 IRI입니다.
annotationVarName 각 result annotation은 sh:annotationVarName 속성에 대해 최대 1개의 value를 가지며 이 value는 datatype이 xsd:string인 literal입니다.
SelectExpression-syntax RDF graph의 한 node가 well-formed select expression인 것은, 그것이 blank node이고 sh:select predicate에 대해 정확히 하나의 value를 가지며, 그 value가 datatype이 xsd:string인 literal일 때입니다.
SelectExpression-syntax-prefixes well-formed select expression은 sh:prefixes 속성에 대해 최대 하나의 value를 가질 수 있으며 이 값은 IRI 또는 blank node여야 합니다.
SelectExpression-query-valid prefix handling rules를 사용하면, sh:select의 값은 유효한 SPARQL 1.2 SELECT query입니다.
SelectExpression-query-output-nodes sh:select의 값으로부터 파생된 SPARQL query는 SELECT clause에서 정확히 하나의 변수를 project합니다.
SPARQLExprExpression-syntax-eval RDF graph의 한 node 가 well-formed SPARQL expr expression인 것은, 그것이 blank node이고 sh:sparqlExpr predicate에 대해 정확히 하나의 value를 가지며 그 value가 datatype이 xsd:string인 literal일 때입니다.
SPARQLExprExpression-syntax-prefixes well-formed SPARQL expr expression은 sh:prefixes 속성에 대해 최대 하나의 value를 가질 수 있으며 이 값은 IRI 또는 blank node입니다.
SPARQLExprExpression-template $EXPR$를 sh:eval의 value라고 하고 $PREFIXES$ 를 sh:prefixes의 값을 사용한 prefix handling rules에서 생성된 SPARQL prefixes block이라고 하면, select는 $EXPR$과 $PREFIXES$가 다음 문자열에 삽입된 형태로 정의됩니다:

$PREFIXES$ SELECT ($EXPR$ AS ?result) WHERE {}
SPARQLExprExpression-query-valid select는 유효한 SPARQL 1.2 SELECT query입니다.
rule-type 각 SHACL 규칙은 하나 이상의 rdf:type을 가지며, 이는 IRI이다.
RuleSet-nodeKind SHACL 인스턴스 중 sh:RuleSet의 인스턴스는 모두 IRI를 가진다.
hasRule 규칙 집합은 sh:hasRule에 대한 값을 가질 수 있으며, 그 값은 규칙이다.
includesRuleSet-nodeKind sh:includesRuleSet의 값은 규칙 집합에서 IRI이다.
rule 속성 sh:rule은 셰이프(주어)를 셰이프 규칙(목적어)과 연결하는 데 사용할 수 있다. 주어는 sh:rule 트리플에서 IRI이다.
condition-node sh:condition의 값은 규칙에서 올바른 형식의 셰이프여야 한다.
deactivated-maxCount 각 규칙은 속성 sh:deactivated에 대해 최대 하나의 값을 가질 수 있다.
deactivated-in sh:deactivated의 값은 xsd:boolean 리터럴 true 또는 false 중 하나이다.
rule-layer-maxCount 각 규칙은 속성 sh:layer에 대해 최대 하나의 값을 가질 수 있다.
rule-layer-datatype 규칙에서 sh:layer의 값은 데이터 타입이 xsd:integer인 리터럴이다.
rule-order-maxCount 각 규칙은 속성 sh:order에 대해 최대 하나의 값을 가질 수 있다.
rule-order-datatype 규칙에서 sh:order의 값은 데이터 타입이 xsd:decimal 또는 xsd:integer인 리터럴이다.
run-once-maxCount 각 규칙은 속성 sh:runOnce에 대해 최대 하나의 값을 가질 수 있다.
run-once-datatype 규칙에서 sh:runOnce의 값은 데이터 타입이 xsd:boolean인 리터럴이다. 데이터 타입은 xsd:boolean이다.
RulesGraph sh:RulesGraph 클래스는 사용할 수 있다. 이 클래스는 rdf:type으로 사용되며, 그 대상은 IRI이다. 이 IRI는 일반적으로 규칙 그래프 역할을 하는 그래프를 식별한다.
construct-count SPARQL 규칙은 속성 sh:construct에 대해 정확히 하나의 값을 가져야 한다.
construct-datatype sh:construct의 값은 데이터 타입이 xsd:string인 리터럴이다.
TripleRule-subject 각 트리플 규칙이 가질 수 있는 속성 sh:subject의 값은 최대 하나여야 한다 (이 값은 올바른 형식의 노드 표현식이어야 한다).
TripleRule-predicate 각 트리플 규칙이 가질 수 있는 속성 sh:predicate의 값은 최대 하나여야 한다 (이 값은 올바른 형식의 노드 표현식이어야 한다).
TripleRule-object 각 트리플 규칙이 가질 수 있는 속성 sh:object의 값은 최대 하나여야 한다 (이 값은 올바른 형식의 노드 표현식이어야 한다).
pre-binding-limitations

SHACL에서 사용하는 사전 바인딩의 정의는 SPARQL 쿼리에 다음 제한 사항을 요구한다. SHACL-SPARQL 프로세서는 반드시 실패를 보고해야 한다. 이는 셰이프 그래프를 처리할 때, 해당 그래프에 SHACL-SPARQL 쿼리가 포함되어 있고(sh:ask, sh:construct 및 sh:select을 통해), 그 쿼리가 사전 바인딩된 변수로 실행되면서 이러한 "반드시 준수해야 하는" 제한 사항 중 하나라도 위반하는 경우이다. 잠재적으로 사전 바인딩된 변수라는 용어에는 this, value(ASK 쿼리의 경우), 그리고 쿼리를 사용하는 매개변수를 나타내는 모든 변수가 포함된다는 점에 유의한다. 이 매개변수는 제약 조건 컴포넌트의 매개변수이다.

  • SPARQL 쿼리는 반드시 MINUS 절을 포함하지 않아야 한다
  • SPARQL 쿼리는 반드시 잠재적으로 사전 바인딩된 변수를 언급하는 VALUES 절을 포함하지 않아야 한다
  • SPARQL 쿼리는 반드시 잠재적으로 사전 바인딩된 변수에 구문 형식 ​​AS ?var를 사용하지 않아야 한다

또한 SPARQL 쿼리는 가급적 연합 쿼리를 포함하지 않아야 한다 (SERVICE). SERVICE를 허용하지 않는 구현은 반드시 위에서 언급한 대로 실패를 보고해야 한다. 그러나 일부 SPARQL 구현은 SERVICE 키워드를 특정한(일반적으로 로컬인) 작업의 구문으로 사용한다고 알려져 있으므로, 이 키워드는 일반적으로 금지되지 않는다.

C. SHACL Core 제약 검증기의 잠재적 SPARQL 정의

이 절은 비규범적입니다.

이 부록에서는 [shacl12-core]의 제약 조건 구성 요소와 대상의 의미론에 대한 비규범적 대체 정의에서 SPARQL 1.2의 일부를 사용한다. 이는 일부 구현자에게 도움이 될 수 있지만, SHACL 코어 언어를 구현하는 데 SPARQL이 필요한 것은 아니다.

$ 마커를 사용하는 SPARQL 변수는 실행 전에 SPARQL 질의에서 사전 바인딩되거나, $PATH의 경우 대체되는 외부 바인딩을 나타낸다(4.3 SPARQL 기반 제약 조건 구성 요소를 사용한 검증에서 설명함).

C.1 sh:targetClass

다음 질의는 SPARQL에서 클래스 대상의 잠재적 정의를 표현한다. 변수 targetClass는 주어진 sh:targetClass 값에 사전 바인딩된다. 해에서 변수 this의 모든 바인딩이 포커스 노드가 된다.

SPARQL에서의 잠재적 정의
SELECT DISTINCT ?this    # ?this는 포커스 노드이다
WHERE {
	?this rdf:type/rdfs:subClassOf* $targetClass .
}

C.2 sh:targetSubjectsOf

다음 질의는 SPARQL에서 주어 대상의 잠재적 정의를 표현한다. 변수 targetSubjectsOf는 주어진 sh:targetSubjectsOf 값에 사전 바인딩된다. 해에서 변수 this의 모든 바인딩이 포커스 노드가 된다.

SPARQL에서의 잠재적 정의
SELECT DISTINCT ?this    # ?this는 포커스 노드이다
WHERE {
	?this $targetSubjectsOf ?any .
}

C.3 sh:targetObjectsOf

다음 질의는 SPARQL에서 목적어 대상의 잠재적 정의를 표현한다. 변수 targetObjectsOf는 주어진 sh:targetObjectsOf 값에 사전 바인딩된다. 해에서 변수 this의 모든 바인딩이 포커스 노드가 된다.

SPARQL에서의 잠재적 정의
SELECT DISTINCT ?this    # ?this는 포커스 노드이다
WHERE {
	?any $targetObjectsOf ?this .
}

C.4 sh:class

다음 질의는 sh:class에 대한 잠재적인 SPARQL 기반 검증기를 표현한다.

SPARQL에서의 잠재적 정의(각 값 노드 $value에 대해 true로 평가되어야 함)
ASK {
	$value rdf:type/rdfs:subClassOf* $class .
}

C.5 sh:nodeKind

다음 질의는 sh:nodeKind에 대한 잠재적인 SPARQL 기반 검증기를 표현한다.

SPARQL에서의 잠재적 정의(각 값 노드 $value에 대해 true로 평가되어야 함)
ASK {
	FILTER ((isIRI($value) && $nodeKind IN ( sh:IRI, sh:BlankNodeOrIRI, sh:IRIOrLiteral ) ) ||
		(isLiteral($value) && $nodeKind IN ( sh:Literal, sh:BlankNodeOrLiteral, sh:IRIOrLiteral ) ) ||
		(isBlank($value)   && $nodeKind IN ( sh:BlankNode, sh:BlankNodeOrIRI, sh:BlankNodeOrLiteral ) )) .
}

C.6 sh:minExclusive(등)

다음 질의는 sh:minExclusive에 대한 잠재적인 SPARQL 기반 검증기를 표현한다. 값 노드를 지정된 범위와 비교할 수 없는 경우, 예를 들어 문자열과 정수를 비교하는 경우 SPARQL 표현식에서 오류가 발생한다. 비교를 수행할 수 없으면 검증 결과가 생성된다. 이는 이러한 오류가 아무런 결과도 생성하지 않고 조용히 처리되는 일반 SPARQL 질의 등과는 다르다.

SPARQL에서의 잠재적 정의(각 값 노드 $value에 대해 true로 평가되어야 함)
ASK {
	FILTER ($minExclusive < $value)
}

다음에도 유사한 정의를 사용할 수 있다.

C.7 sh:minLength

다음 질의는 sh:minLength에 대한 잠재적인 SPARQL 기반 검증기를 표현한다.

SPARQL에서의 잠재적 정의(각 값 노드 $value에 대해 true로 평가되어야 함)
ASK {
	FILTER (STRLEN(str($value)) >= $minLength) .
}

C.8 sh:maxLength

다음 질의는 sh:maxLength에 대한 잠재적인 SPARQL 기반 검증기를 표현한다.

SPARQL에서의 잠재적 정의(각 값 노드 $value에 대해 true로 평가되어야 함)
ASK {
	FILTER (STRLEN(str($value)) <= $maxLength) .
}

C.9 sh:pattern

다음 질의는 sh:pattern에 대한 잠재적인 SPARQL 기반 검증기를 표현한다.

SPARQL에서의 잠재적 정의(각 값 노드 $value에 대해 true로 평가되어야 함)
ASK {
	FILTER (!isBlank($value) && IF(bound($flags), regex(str($value), $pattern, $flags), regex(str($value), $pattern)))
}

C.10 sh:disjoint

다음 질의는 sh:disjoint에 대한 잠재적인 SPARQL 기반 검증기를 표현한다.

SPARQL에서의 잠재적 정의(주어진 $PATH에 대해 결과를 반환하지 않아야 함) 
SELECT DISTINCT $this ?value
WHERE {
	$this $PATH ?value .
	$this $disjoint ?value .
}

C.11 sh:lessThan

다음 질의는 sh:lessThan에 대한 잠재적인 SPARQL 기반 검증기를 표현한다.

SPARQL에서의 잠재적 정의(주어진 $PATH에 대해 결과를 반환하지 않아야 함) 
SELECT $this ?value
WHERE {
	$this $PATH ?value .
	$this $lessThan ?otherValue .
	BIND (?value < ?otherValue AS ?result) .
	FILTER (!bound(?result) || !(?result)) .
}

C.12 sh:lessThanOrEquals

다음 질의는 sh:lessThanOrEquals에 대한 잠재적인 SPARQL 기반 검증기를 표현한다.

SPARQL에서의 잠재적 정의(주어진 $PATH에 대해 결과를 반환하지 않아야 함) 
SELECT $this ?value
WHERE {
	$this $PATH ?value .
	$this $lessThanOrEquals ?otherValue .
	BIND (?value <= ?otherValue AS ?result) .
	FILTER (!bound(?result) || !(?result)) .
}

D. 보안 및 개인정보 고려사항

이 절은 비규범입니다.

GRAPH 및 FROM과 같은 SPARQL key words는 dataset 안에서 active data graph가 아닌 graphs에 대한 접근을 제공할 수 있음에 유의하세요. SHACL-SPARQL engine은 SPARQL engine이 validation을 트리거한 user에게 접근이 허용되지 않은 named graphs에 대한 접근을 제공하지 않도록 보장해야 합니다.

SHACL-SPARQL의 보안 고려사항에는 SPARQL, SPARQL Federated Query (SERVICE) 및 SHACL Core의 모든 보안 고려사항이 포함됩니다.

E. 감사의 글

이 절은 비규범입니다.

원래 SHACL core specifications는 RDF Data Shapes Working Group에서 작성했습니다. Core specification의 Acknowledgements section과 Advanced Features specification의 Acknowledgements section을 참조하세요.

F. 원래 SHACL 명세와 SHACL 1.2 SPARQL 사이의 변경사항

이 절은 비규범입니다.

G. 참고 문헌

G.1 규범 참고 문헌

[owl2-syntax]
OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition). Boris Motik; Peter Patel-Schneider; Bijan Parsia. W3C. 2012년 12월 11일. W3C 권고안. URL: https://www.w3.org/TR/owl2-syntax/
[rdf12-concepts]
RDF 1.2 Concepts and Abstract Data Model. Andy Seaborne; Gregg Kellogg; Olaf Hartig; Pierre-Antoine Champin. W3C. 2026년 4월 7일. W3C 후보 권고안. URL: https://www.w3.org/TR/rdf12-concepts/
[rdf12-turtle]
RDF 1.2 Turtle. Gregg Kellogg; Andy Seaborne; Dominik Tomaszuk. W3C. 2026년 8월 12일. W3C 작업 초안. URL: https://www.w3.org/TR/rdf12-turtle/
[REC-xml-names]
Namespaces in XML 1.0 (Third Edition). Tim Bray; Dave Hollander; Andrew Layman; Richard Tobin; Henry Thompson et al. W3C. 2009년 12월 8일. W3C 권고안. URL: https://www.w3.org/TR/xml-names/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. 1997년 3월. 현재 모범 사례. URL: https://www.rfc-editor.org/info/rfc2119/
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. 2017년 5월. 현재 모범 사례. URL: https://www.rfc-editor.org/info/rfc8174/
[shacl12-core]
SHACL 1.2 Core. Holger Knublauch; Thomas Bergwinkl; Yousouf Taghzouti; Jesse Wright. W3C. 2026년 8월 3일. W3C 작업 초안. URL: https://www.w3.org/TR/shacl12-core/
[shacl12-node-expr]
SHACL 1.2 Node Expressions. Robert David; Holger Knublauch; Simon Steyskal. W3C. 2026년 7월 21일. W3C 작업 초안. URL: https://www.w3.org/TR/shacl12-node-expr/
[sparql12-query]
SPARQL 1.2 Query Language. Olaf Hartig; Andy Seaborne; Ruben Taelman; Gregory Williams; Thomas Pellissier Tanon. W3C. 2026년 6월 25일. W3C 작업 초안. URL: https://www.w3.org/TR/sparql12-query/
[vc-data-model]
Verifiable Credentials Data Model v2.0. Ivan Herman; Michael Jones; Manu Sporny; Ted Thibodeau Jr; Gabe Cohen. W3C. 2025년 5월 15일. W3C 권고안. URL: https://www.w3.org/TR/vc-data-model-2.0/

G.2 정보 참고 문헌

[sparql12-federated-query]
SPARQL 1.2 Federated Query. Ruben Taelman; Gregory Williams. W3C. 2026년 4월 23일. W3C Working Draft. URL: https://www.w3.org/TR/sparql12-federated-query/