셰이프는 제약 조건 컴포넌트의 매개변수를 사용하여 제약 조건을 선언할 수 있습니다.

제약 조건 컴포넌트는 IRI입니다. 각 제약 조건 컴포넌트에는 하나 이상의 필수 매개변수가 있으며, 각각은 속성입니다. 각 제약 조건 컴포넌트에는 0개 이상의 선택적 매개변수가 있으며, 각각은 속성입니다. 제약 조건 컴포넌트의 매개변수는 해당 컴포넌트의 필수 매개변수와 선택적 매개변수를 합한 것입니다.

예를 들어, 컴포넌트 sh:MinCountConstraintComponent는 특정 속성에 대해 노드가 최소한 일정 개수 이상의 값을 가져야 한다는 제한을 나타내기 위해 매개변수 sh:minCount를 선언합니다.

필수 매개변수 p1, ... pn을 갖는 제약 조건 컴포넌트 C에 대해, 셰이프 그래프 SG의 셰이프 s는 SG에서 s가 pi에 대한 값으로 vi를 가질 때, 필수 매개변수 값 <p1,v1>, ... <pn,vn>을 가지며 종류가 C인 제약 조건을 선언합니다. 선택적 매개변수를 갖는 제약 조건 컴포넌트의 경우, 제약 조건 선언은 셰이프가 해당 컴포넌트의 모든 필수 및 선택적 매개변수에 대해 갖는 값으로 구성됩니다.

일부 제약 조건 컴포넌트는 단 하나의 매개변수만 선언합니다. 예를 들어 sh:ClassConstraintComponent에는 단일 매개변수 sh:class가 있습니다. 이러한 매개변수는 동일한 셰이프에서 여러 번 사용할 수 있으며, 그러한 매개변수의 각 값은 개별 제약 조건을 선언합니다. 이러한 선언은 논리곱으로 해석됩니다. 즉, 모든 제약 조건이 적용됩니다. 다음 예에서는 ex:customer의 값이 ex:Customer와 ex:Person 모두의 SHACL 인스턴스여야 함을 지정합니다.

sh:PatternConstraintComponent와 같은 일부 제약 조건 컴포넌트는 둘 이상의 매개변수를 선언합니다. 이러한 컴포넌트의 매개변수 중 하나라도 둘 이상의 값을 갖는 셰이프는 잘못된 형식입니다.

이 구문 규칙을 우회하는 한 가지 방법은 다음 예와 같이 제약 조건을 여러 (속성) 셰이프에 분산하는 것입니다.

제약 조건 컴포넌트는 검증기와 연결되며, 검증기는 매개변수를 사용하여 데이터를 검증하는 방법에 대한 지침(예를 들어 SPARQL 쿼리로 표현됨)을 제공합니다. RDF 항을 셰이프에 대해 검증하는 것은, 해당 셰이프가 제약 조건의 컴포넌트의 모든 필수 매개변수에 대해 값을 갖는 각 제약 조건에 대해, 각각의 컴포넌트와 연결된 검증기를 사용하여 해당 항을 검증하는 것을 포함합니다.

SHACL 코어에 포함된 제약 조건 컴포넌트 목록은 7. 코어 제약 조건 컴포넌트에 설명되어 있습니다. SHACL-SPARQL을 사용하여 추가적인 SPARQL 기반 제약 조건 컴포넌트를 선언할 수 있습니다.

데이터 그래프의 트리플을 사용하여 셰이프에 대해 검증되는 RDF 용어를 포커스 노드라고 합니다.

이 섹션의 나머지 부분은 비규범입니다.

셰이프에 대한 포커스 노드 집합은 다음과 같이 식별될 수 있습니다:

• 대상 선언을 사용하여 셰이프 안에서 지정됨
• 셰이프를 기대하는 제약 매개변수(예: sh:node)의 매개변수에서 셰이프를 참조하는 모든 제약 안에서 지정됨
• 특정 RDF 용어를 셰이프에 대해 검증하기 위한 SHACL 프로세서의 명시적 입력으로 지정됨

셰이프 그래프에서 셰이프의 대상 선언은 트리플로, 셰이프를 주어로, 이 문서에 설명된 특정 속성을 (예: sh:targetClass) 술어로 갖습니다. 또한 sh:shape 트리플은 데이터 그래프에서 대상을 선언할 수 있습니다. 대상 선언은 셰이프의 초점 노드를 생성하는 데 사용할 수 있습니다. 대상 선언의 대상은 이 절의 나머지 부분에 설명된 규칙을 데이터 그래프에 적용하여 생성된 RDF 용어의 집합입니다. 셰이프의 대상은 해당 셰이프에 선언된 개별 대상이 생성한 모든 RDF 용어의 합집합입니다. 이 대상은 셰이프에 대해 선언됩니다.

SHACL 코어에는 다음과 같은 종류의 대상이 포함됩니다:

• 노드 대상
• 클래스 기반 대상 (암시적 클래스 기반 대상 포함)
• 주어 대상
• 객체 대상
• 조건 대상
• 명시적 셰이프 대상

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

대상이 생성한 RDF 용어는 데이터 그래프에 노드로 존재할 필요가 없습니다. 셰이프의 검증 프로세스에 초점 노드가 입력으로 직접 제공되는 경우, 해당 셰이프의 대상은 무시됩니다. 여기에는 셰이프가 셰이프를 요구하는 제약 조건 매개변수(예: sh:node) 중 하나의 값이고, 해당 제약 조건 컴포넌트(예: sh:NodeConstraintComponent)를 검증하는 동안 초점 노드가 결정되는 경우도 포함됩니다. 이러한 경우 제공된 초점 노드는 셰이프의 대상에 포함될 필요가 없습니다.

셰이프는 셰이프 그래프에서 sh:severity 속성에 대해 최대 하나의 값을 가질 수 있습니다. 각 sh:severity 값은 IRI입니다.

셰이프별 심각도를 선언하는 것 외에도, 속성 sh:severity는 셰이프가 주어이고 제약의 매개변수 중 하나가 술어인 트리플의 구상화자에도 사용할 수 있습니다.

T를 셰이프 안의 제약을 나타내는 트리플들의 집합이라고 합시다. 셰이프 그래프는 T에 있는 트리플들의 구상화자에서 속성 sh:severity에 대해 최대 하나의 값을 지정할 수 있습니다.

sh:severity의 값을 심각도라고 합니다. SHACL은 심각도를 나타내기 위해 아래 표에 나열된 IRI를 포함합니다. 이들은 SHACL 어휘에서 sh:Severity의 SHACL 인스턴스로 선언됩니다.

이 섹션의 나머지 부분은 비규범입니다.

검증 프로세스는 적합성 검사에 따라 sh:severity의 값을 처리합니다. 또한 사용자 인터페이스 도구는 이 값을 사용하여 검증 결과를 분류할 수 있습니다. sh:severity의 값은 SHACL 프로세서가 검증 결과의 sh:resultSeverity 필드를 채우는 데 사용됩니다. 검증 결과의 심각도에 관한 섹션을 참조하십시오. 어떤 IRI도 심각도로 사용할 수 있습니다.

모든 셰이프와 제약에 대해, sh:severity가 지정되지 않으면 sh:Violation이 기본값입니다. 다음 예제는 이를 설명합니다.

다음 예제는 위 셰이프 그래프의 변형이지만, 구상화를 사용하여 개별 제약의 심각도를 지정합니다:

셰이프는 sh:message 속성의 값을 가질 수 있습니다. sh:message의 값은 리터럴이며, 데이터 유형은 xsd:string, rdf:dirLangString, rdf:langString 또는 rdf:HTML입니다. 주어는 동일한 언어 태그를 가진 sh:message 값을 둘 이상 가져서는 안 되며, 데이터 유형이 xsd:string인 값도 여러 개 가져서는 안 됩니다.

셰이프가 셰이프 그래프에서 sh:message에 대한 값을 하나 이상 가지면, 그 셰이프의 결과로 생성되는 모든 검증 결과는 sh:resultMessage의 값으로 정확히 이러한 메시지들을 가지게 됩니다. 즉, 값은 셰이프 그래프에서 결과 그래프로 복사됩니다.

셰이프별 메시지를 선언하는 것 외에도, 속성 sh:message는 셰이프가 주어이고 제약의 매개변수 중 하나가 술어인 트리플의 구상화자에도 사용할 수 있습니다.

T를 셰이프 안의 제약을 나타내는 트리플들의 집합이라고 합시다. 셰이프 그래프는 T에 있는 트리플들의 구상화자에서 속성 sh:message에 대해 최대 하나의 값을 지정할 수 있습니다.

이 섹션의 나머지 부분은 비규범입니다.

sh:resultMessage의 값이 채워지는 방식에 대한 자세한 내용은 검증 결과의 sh:resultMessage에 관한 섹션을 참조하십시오.

이전 섹션의 예제는 이 메커니즘을 사용하여 두 번째 검증 결과에 두 개의 메시지를 제공합니다. 다음 예제는 구상화를 사용하여 메시지를 선언하는 변형입니다.

셰이프는 sh:deactivated 속성에 대해 최대 하나의 값만 가질 수 있습니다. sh:deactivated의 값은 노드 표현식이며, 유일한 출력 노드로 true 또는 false를 가져야 합니다.

expr을 셰이프에서 sh:deactivated의 값이라고 하겠습니다. 만약 evalExpr(expr, 데이터 그래프, 초점 노드, {}) 가 유일한 출력 노드로 true를 생성하면 해당 셰이프를 비활성화된 셰이프라고 합니다. 비활성화된 셰이프는 검증 중에 무시됩니다.

셰이프의 모든 제약 조건을 비활성화하는 것 외에도 개별 제약 조건을 비활성화할 수 있습니다. 이는 구체화를 사용하여 수행합니다.

셰이프를 주어로, 매개변수(예: sh:minCount)를 술어로 갖는 트리플은 sh:deactivated 속성의 값을 갖는 구체화자를 최대 하나만 가질 수 있습니다.

expr을 셰이프를 주어로, 매개변수를 술어로 갖는 트리플의 구체화자에서 sh:deactivated의 값이라고 하겠습니다. 만약 evalExpr(expr, 데이터 그래프, 초점 노드, {}) 가 유일한 출력 노드로 true를 생성하면 해당 트리플을 사용하는 제약 조건을 비활성화된 제약 조건이라고 합니다. 비활성화된 제약 조건은 검증 중에 무시됩니다.

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

SHACL 코어에서 sh:deactivated에 유효한 값은 상수 리터럴 노드 표현식인 true와 false뿐입니다.

이 기능의 사용 사례에는 셰이프 재사용과 디버깅이 포함됩니다. 다른 그래프나 파일의 셰이프를 특정 셰이프 그래프로 가져오는 경우, 가져온 셰이프에 대해 로컬 셰이프 그래프에서 sh:deactivated를 true로 설정하여 현재 애플리케이션의 맥락에 적용되지 않는 셰이프를 제외할 수 있습니다. 이를 통해 원래 작성자의 특정 가정에 동의하지 않더라도 다른 사람이 개발한 SHACL 그래프를 재사용할 수 있습니다. 셰이프 작성자가 다른 사람이 셰이프를 비활성화하거나 수정해야 할 가능성을 예상한다면, 실제 셰이프에 빈 노드 대신 IRI를 사용하는 것이 좋습니다. 예를 들어, ex:PersonShape 셰이프에서 ex:name 속성에 대한 속성 셰이프는 다음 IRI를 가질 수 있습니다: ex:PersonShape-name. sh:deactivated의 또 다른 일반적인 사용 사례는 셰이프를 개발하고 테스트하는 동안 특정 셰이프를 일시적으로 비활성화하는 것입니다.

다음 예제는 sh:deactivated를 사용하여 셰이프를 비활성화하는 방법을 보여줍니다. 다른 그래프에서 셰이프를 가져오는 경우, sh:deactivated true 트리플은 가져오기를 수행하는 그래프에 존재하게 됩니다.

다음 변형은 구상화를 사용하여 같은 속성 셰이프의 다른 제약에는 영향을 주지 않고 sh:minCount 제약만 비활성화합니다.

검증과 적합성 검사는 실패를 초래할 수 있습니다. 예를 들어, 특정 SHACL 프로세서는 재귀적 셰이프를 허용하지만 실패를 보고할 수 있습니다. 데이터 내에서 순환을 감지한 경우입니다. 리소스 고갈로 인해 실패가 보고될 수도 있습니다. 실패는 구현별 채널을 통해 알립니다.

만약 셰이프 그래프에 형식이 올바르지 않은 노드가 포함되어 있다면, 검증 과정의 결과는 정의되지 않습니다. SHACL 프로세서는 생성하는 것이 좋습니다. 실패를 이 경우에 생성합니다. 또한 6.9.1.4 구문 검사: 셰이프 그래프 (sh:shapesGraphWellFormed)를 참조하세요.

다음 속성은 이른바 셰이프를 요구하는 제약 조건 매개변수이며, SHACL Core에 속합니다:

• sh:and
• sh:not
• sh:or
• sh:property
• sh:qualifiedValueShape
• sh:node
• sh:memberShape
• sh:reifierShape
• sh:someValue
• sh:xone

다음 속성은 이른바 리스트를 받는 제약 조건 매개변수이며, SHACL Core에 속합니다:

• sh:and
• sh:ignoredProperties
• sh:in
• sh:languageIn
• sh:or
• sh:xone

또한, sh:class, sh:datatype, sh:nodeKind, sh:rootClass 및 sh:uniqueValuesFor는 리스트를 받는 제약 조건 매개변수가 됩니다. 해당 값이 다음인 경우입니다. SHACL 리스트입니다.

RDF 그래프 G의 셰이프 s1이 참조하는 셰이프가 s2이고, 이 셰이프가 G에 있는 경우란 s2가 다음의 값인 경우입니다. 리스트를 받지 않고 셰이프를 요구하는 어떤 제약 조건 구성 요소의 매개변수이거나, s2가 구성원인 경우이며, 이때의 값은 리스트를 받고 셰이프를 요구하는 어떤 제약 조건 구성 요소의 매개변수에 대한 값입니다. 또는 s2가 값으로서 sh:targetWhere에 지정된 경우입니다. RDF 그래프 G의 셰이프가 재귀적 셰이프인 것은 G에서 다음과 같이 연결되는 경우입니다. 자신과 연결되며, 그 연결은 다음의 전이 폐포에 의합니다. 참조 관계이며 G 내의 관계입니다.

검증에서 재귀적 셰이프를 사용하는 것은 SHACL에서 정의하지 않으며 SHACL 프로세서 구현에 맡깁니다. 예를 들어, SHACL 프로세서는 재귀 시나리오를 지원하거나 감지 시 실패를 생성할 수 있습니다. 감지하는 것은 재귀입니다.

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

위의 재귀 정책은 다양한 구현 전략을 지원하기 위해 선택되었습니다. 재귀를 정의하지 않음으로써, 구현은 재귀를 지원하지 않도록 선택할 수 있으며, 이에 따라 순환을 지원할 필요 없이 정적인 SPARQL 쿼리 집합을 (SPARQL 엔드포인트에) 실행할 수 있습니다. 작업 그룹은 다른 구현이 재귀를 지원할 수 있으며 일부 셰이프 그래프가 이러한 특정 특성에 의존할 수 있음을 인지하고 있습니다. 향후 작업, 예를 들어 W3C 커뮤니티 그룹의 작업을 통해 정의될 것으로 기대합니다. 재귀가 명확히 정의된 특정 SHACL 방언을 정의하는 것입니다.

데이터 그래프는 속성을 사용해도 됩니다. sh:conformsToShapesGraph를 사용하여 자신의 적합 여부를 나타내며, 기준은 주어진 셰이프 그래프입니다. 값은 IRI이며, 식별하는 것은 셰이프 그래프입니다. 이 속성에는 rdfs:domain sh:DataGraph와 rdfs:range sh:ShapesGraph가 있습니다.

다음의 결과는, 검증 과정의 결과는 정확히 하나의 SHACL 인스턴스를 가진 RDF 그래프이며, 인스턴스의 클래스는 sh:ValidationReport입니다.

SHACL은 sh:ValidationResult를 sh:AbstractResult의 하위 클래스로 정의하여 개별 SHACL 검증 결과를 보고합니다. SHACL 구현은 다른 SHACL 하위 클래스를 사용할 수 있으며, 상위 클래스는 sh:AbstractResult입니다. 예를 들어, 성공적으로 완료된 제약 조건 검사나 누적된 결과를 보고하는 데 사용할 수 있습니다.

이 절의 나머지 하위 절에서 설명하는 모든 속성은 sh:ValidationResult에 지정할 수 있습니다. sh:focusNode, sh:resultSeverity 및 sh:sourceConstraintComponent 속성만이 모든 검증 결과에 필수인 속성입니다.

데이터 그래프에는 의도적으로 일부 정보만 포함될 수 있습니다. 그 대상은 일부 노드이며, 예를 들어 관심 영역 밖의 "외부" 리소스에 연결하는 경우, 또는 나머지 트리플이 아직 입력되지 않았지만 나중에 입력될 것으로 예상되는 노드에 연결하는 경우입니다. SHACL은 다음에서 사용할 수 있는 두 속성을 정의합니다. 데이터 그래프에서 이러한 노드를 불완전한 것으로 선언하는 데 사용합니다:

• sh:incomplete는 다음 여부를 나타냅니다. 주어가 불완전한지(true) 또는 완전한지 (false) 여부입니다. 다음 값, 즉 sh:incomplete의 값은 리터럴이며, 데이터타입은 xsd:boolean입니다.
• sh:incompleteURIStart의 값이 true이면, 다음을 가진 모든 노드를 선언합니다. 해당 IRI가 주어의 IRI로 시작하는 노드이며, 이 노드들은 불완전합니다(주어 자체는 제외). 단, 달리 명시된 경우는 제외하며, 사용하는 것은 sh:incomplete false입니다. 다음 값, 즉 sh:incompleteURIStart의 값은 리터럴이며, 데이터타입은 xsd:boolean입니다. 다음 주어, 즉 트리플의 주어이며 그 술어가 sh:incompleteURIStart인 경우, 이는 IRI입니다.

불완전성 값은 다음 노드 n에 대해 다음의 값입니다. sh:incomplete의 값으로, n에 대한 값이며 위치는 데이터 그래프입니다. 여기에 더해 값 노드도 포함하며, n이 초점 노드인 각 속성 셰이프 p에 대한 것입니다. 이 셰이프가 속한 셰이프 그래프에서 sh:incomplete를 값으로 가지며, 해당 속성은 sh:path입니다. 여기서 n은 다음에 속합니다. 셰이프의 대상이며 해당 셰이프는 p입니다. 또는 다음의 셰이프의 대상에 속하며, 해당 셰이프는 p를 값으로 갖고 해당 속성은 sh:property입니다. 이를 통해 다음을 선언할 수 있습니다. 노드가 불완전함을 셰이프 그래프에서 선언하며, sh:values 또는 sh:defaultValue를 사용합니다. (6.10.2 값 노드: 속성 셰이프의 값 노드를 참조하세요.)

노드 n이 불완전한 것은 false가 포함되지 않은 경우입니다. 포함 여부를 판단하는 것은 불완전성 값으로, n의 값이며, 또한 적어도 다음 조건 중 하나를 만족해야 합니다:

1. true가 다음에 포함됩니다. 불완전성 값이며, 해당 노드는 n입니다.
2. n은 IRI이며, 다음으로 시작하지만 동일하지는 않습니다. IRI로서, 어떤 주어의 IRI이며 해당 주어는 true를 유일한 값으로 갖습니다. 해당 속성은 sh:incompleteURIStart이고, 위치는 데이터 그래프입니다.

특히, 노드에 true와 false가 모두 다음에 포함되어 있다면, 불완전성 값에 포함된 경우 해당 노드는 아닙니다. 불완전한 노드가 아닙니다.

리터럴은 결코 불완전하지 않습니다.

불완전한 노드의 존재는 검증 결과를 변경하지 않습니다. 해당 결과에는 sh:conforms의 값도 포함되며, 이는 검증 보고서의 값입니다.

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

SHACL 기반 도구는 불완전한 데이터 트리플을 사용해도 됩니다. 이를 통해 변경하는 것은 표시 방식이며, 불완전한 데이터로 인해 발생한 검증 결과의 표시 방식입니다. 특히, 도구는 다음을 수행해도 됩니다:

• sh:minCount 위반을 시각적으로 숨기거나 낮은 수준으로 표시하며, 대상은 불완전한 초점 노드입니다.
• sh:class 위반을 시각적으로 숨기며, 대상은 불완전한 값 노드입니다.

위 목록이 모든 경우를 망라하지는 않습니다. 다른 예로는 sh:node와 sh:qualifiedMinCount가 있습니다.

다음 예제에서 ex:Bob은 불완전한 것으로 선언되며, 사용하는 것은 sh:incomplete입니다. 그의 이메일 주소가 아직 입력되지 않았기 때문입니다. ex:Bob과 ex:Carla는 모두 sh:minCount 제약 조건을 위반하지만, 도구는 ex:Bob의 위반을 숨기도록 선택할 수 있으며, ex:Carla의 위반은 정상적으로 표시합니다.

다음 예제에서 데이터 그래프는 다른 곳에서 기술된 회사에 연결하며, 해당 위치는 다른 그래프입니다. sh:incompleteURIStart를 사용하여 모든 IRI, 즉 이러한 회사의 IRI를 불완전한 것으로 선언하여, 누락된 rdf:type 트리플을 반드시 표시하지 않아도 되도록 합니다. sh:class 위반으로 최종 사용자에게 표시하는 것을 말합니다. 따라서 ex:Alice의 위반은 숨겨질 수 있습니다. ex:Bob의 위반은 정상적으로 표시됩니다. 그의 고용주가 sh:incomplete false를 사용하여 완전한 것으로 선언되었기 때문입니다. ex:Carla는 적합합니다. 그녀의 고용주가 ex:Company라고 명시되어 있기 때문입니다.

다음 예제에서 셰이프 그래프는 다음 상태를 가진 모든 사람을 선언합니다. ex:WorkInProgress 상태이며, 불완전한 것으로 선언합니다. 속성 셰이프에 sh:path sh:incomplete가 있으며, 제약 조건은 없지만 해당 sh:values는 다음을 생성합니다. 값 노드이며, true를 생성합니다. 이는 각 초점 노드에 대한 것이고 해당 셰이프는 ex:WorkInProgressShape입니다. 이로 인해 true가 다음 중 하나가 됩니다. 불완전성 값입니다. ex:Dave와 ex:Erin은 모두 sh:minCount 제약 조건을 위반하지만, 도구는 ex:Dave의 위반을 숨기도록 선택할 수 있습니다.

다음의 경우, 노드 셰이프에서 값 노드는 개별 초점 노드이며, 구성원이 정확히 하나인 집합을 형성합니다.

다음의 경우, 속성 셰이프가 값을 가지며, 해당 속성은 sh:path이고 값은 p일 때, 다음 집합, 값 노드의 집합은 다음 단계에 따라 생성됩니다:

1. 모든 노드를 추가합니다. 위치는 데이터 그래프이며, 다음으로부터 도달할 수 있는 노드입니다. 초점 노드에서 경로 매핑을 사용하며, 해당 경로는 p입니다.
2. e가 다음의 값이라면, sh:values의 값이며 해당 위치는 속성 셰이프이고, 이때 추가하는 것은 출력 노드이며, 다음의 출력 노드입니다. evalExpr(e, 데이터 그래프, 초점 노드, {}).
3. 집합이 여전히 비어 있고 d가 다음의 값이라면, sh:defaultValue의 값이며, 해당 위치는 속성 셰이프이고, 이때 추가하는 것은 출력 노드이며, 다음의 출력 노드입니다. evalExpr(d, 데이터 그래프, 초점 노드, {}).

sh:class가 지정하는 조건은 각 값 노드가 주어진 유형의 SHACL 인스턴스여야 한다는 것입니다.

제약 조건 컴포넌트 IRI: sh:ClassConstraintComponent

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

sh:class의 여러 값은 논리곱으로 해석된다는 점에 유의하세요. 즉, 값은 모든 클래스의 SHACL 인스턴스여야 합니다. 합집합 의미 체계를 사용하려면 목록을 사용하세요.

다음 예제는 sh:class에 목록 기반 구문을 사용하는 방법을 보여줍니다. 이는 ex:pet 속성의 값이 고양이 또는 개여야 함을 의미합니다.

sh:datatype은 각 값 노드의 데이터 유형과 관련하여 충족해야 하는 조건을 지정합니다.

제약 조건 컴포넌트 IRI: sh:DatatypeConstraintComponent

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

sh:datatype의 값은 일반적으로 xsd:string과 같은 데이터 유형입니다.

다음 예제는 목록 기반 구문을 보여주며, 모든 rdfs:label 값이 xsd:string 또는 rdf:langString이어야 함을 의미합니다.

sh:nodeKind는 각 값 노드의 RDF 노드 종류가 충족해야 하는 조건을 지정합니다.

제약 조건 컴포넌트 IRI: sh:NodeKindConstraintComponent

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

다음 예제는 모든 주어에서 ex:knows의 값이 반드시 IRI여야 함을 나타냅니다.

다음 예제는 목록 기반 구문을 보여주며, 모든 주어에서 ex:knows의 값이 IRI 또는 빈 노드여야 함을 의미합니다.

sh:minCount는 조건을 충족하는 값 노드의 최소 개수를 지정합니다. 최소 기수 값이 0이면 이 제약 조건은 항상 충족되므로 생략할 수 있습니다.

제약 조건 컴포넌트 IRI: sh:MinCountConstraintComponent

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

sh:maxCount는 조건을 충족하는 값 노드의 최대 개수를 지정합니다.

제약 조건 컴포넌트 IRI: sh:MaxCountConstraintComponent

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

sh:minExclusive는 각 값 노드가 초과해야 하는 배타적 최솟값을 지정합니다.

제약 조건 컴포넌트 IRI: sh:MinExclusiveConstraintComponent

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

값 노드를 지정된 범위와 비교할 수 없는 경우에도 검증 결과가 발생합니다. 예를 들어 문자열을 정수와 비교하는 경우입니다.

sh:minInclusive는 각 값 노드가 크거나 같아야 하는 포괄적 최솟값을 지정합니다.

제약 조건 컴포넌트 IRI: sh:MinInclusiveConstraintComponent

sh:maxExclusive는 각 값 노드가 미만이어야 하는 배타적 최댓값을 지정합니다.

제약 조건 컴포넌트 IRI: sh:MaxExclusiveConstraintComponent

sh:maxInclusive는 각 값 노드가 작거나 같아야 하는 포괄적 최댓값을 지정합니다.

제약 조건 컴포넌트 IRI: sh:MaxInclusiveConstraintComponent

sh:minLength는 조건을 충족하기 위해 각 값 노드가 가져야 하는 최소 문자열 길이를 지정합니다. 이는 모든 리터럴과 IRI에 적용할 수 있지만, 빈 노드에는 적용할 수 없습니다.

제약 조건 컴포넌트 IRI: sh:MinLengthConstraintComponent

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

sh:minLength의 값이 0이면 문자열 길이에 제한이 없지만, 값 노드가 빈 노드이면 여전히 제약 조건을 위반합니다.

sh:maxLength는 조건을 충족하기 위해 각 값 노드가 가져야 하는 최대 문자열 길이를 지정합니다. 이는 모든 리터럴과 IRI에 적용할 수 있지만, 빈 노드에는 적용할 수 없습니다.

제약 조건 컴포넌트 IRI: sh:MaxLengthConstraintComponent

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

sh:pattern은 각 값 노드가 조건을 충족하기 위해 일치해야 하는 정규 표현식을 지정합니다.

제약 조건 컴포넌트 IRI: sh:PatternConstraintComponent

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

true로 설정하면 sh:singleLine은 값 노드에 줄바꿈이 포함되어서는 안 된다고 지정합니다. 제약 조건 검증 외에도 사용자 인터페이스 빌더는 이 정보를 활용하여 (단일 행) 텍스트 필드와 (여러 행) 텍스트 영역 중 하나를 선택할 수 있습니다.

제약 조건 컴포넌트 IRI: sh:SingleLineConstraintComponent

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

sh:languageIn이 지정하는 조건은 각 값 노드에 허용되는 언어 태그가 주어진 언어 태그 목록으로 제한된다는 것입니다.

제약 조건 컴포넌트 IRI: sh:LanguageInConstraintComponent

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

다음 예제 셰이프는 ex:prefLabel의 모든 값이 영어 또는 마오리어일 수 있다고 명시합니다.

sh:uniqueLang 속성을 true로 설정하면 어떤 두 값 노드도 동일한 언어 태그를 사용할 수 없다고 지정하며, 텍스트 방향이 있는 경우 이를 함께 고려합니다.

제약 조건 컴포넌트 IRI: sh:UniqueLangConstraintComponent

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

sh:memberShape는 SHACL 목록인 값 노드의 모든 구성원이 주어진 노드 셰이프를 준수해야 한다고 지정합니다.

제약 조건 컴포넌트 IRI: sh:MemberShapeConstraintComponent

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

값 노드 v의 구성원 중 $memberShape를 준수하지 않는 각 구성원 m은 v에 대한 검증 결과에서 별도의 sh:detail로 보고하는 것이 좋습니다. v가 유효한 SHACL 목록이 아니라면, 이를 최상위 검증 결과로 보고하고 개별 구성원의 검증을 시도하지 않는 것이 좋습니다.

검증 결과에서 sh:detail을 생성하는 방법의 예제는 SHACL 테스트 스위트의 sh:memberShape 테스트 사례에서 확인할 수 있습니다: memberShape-001.ttl.

다음 예제에서 ex:speakerOrder 속성의 모든 값은 구성원이 IRI인 SHACL 목록이어야 합니다.

sh:minListLength는 SHACL 목록인 값 노드가 가져야 하는 최소 구성원 수를 지정합니다.

제약 조건 컴포넌트 IRI: sh:MinListLengthConstraintComponent

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

다음 예제에서 ex:skills 속성의 모든 값은 구성원이 하나 이상인 SHACL 목록이어야 합니다. sh:minListLength에 대한 추가 테스트 사례는 SHACL 테스트 스위트에서 확인할 수 있습니다: minListLength-001.ttl.

sh:maxListLength는 SHACL 목록인 값 노드가 가질 수 있는 최대 구성원 수를 지정합니다.

제약 조건 컴포넌트 IRI: sh:MaxListLengthConstraintComponent

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

다음 예제에서 ex:hobbies 속성의 모든 값은 구성원이 최대 2개인 SHACL 목록이어야 합니다. sh:maxListLength에 대한 추가 테스트 사례는 SHACL 테스트 스위트에서 확인할 수 있습니다: maxListLength-001.ttl.

sh:uniqueMembers는 SHACL 목록인 값 노드가 고유한 구성원을 가져야 하는지 지정합니다.

제약 조건 컴포넌트 IRI: sh:UniqueMembersConstraintComponent

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

목록 v의 중복된 각 구성원 m은 v에 대한 검증 결과에서 별도의 sh:detail로 보고하는 것이 좋습니다. 목록 v가 유효한 SHACL 목록이 아니라면, 이를 최상위 검증 결과로 보고하고 구성원의 고유성 검증을 시도하지 않는 것이 좋습니다.

검증 결과에서 sh:detail을 생성하는 방법의 예제는 SHACL 테스트 스위트의 sh:uniqueMembers 테스트 사례에서 확인할 수 있습니다: uniqueMembers-001.ttl.

다음 예제에서 ex:preferences 속성의 모든 값은 각 SHACL 목록 내에서 구성원 값이 고유한 SHACL 목록이어야 합니다.

sh:equals는 모든 값 노드의 집합이 sh:equals로 지정한 SHACL 속성 경로를 통해 초점 노드에서 도달할 수 있는 노드의 집합과 같아야 한다는 조건을 지정합니다.

제약 조건 컴포넌트 IRI: sh:EqualsConstraintComponent

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

다음 예제는 셰이프에서 sh:equals를 사용하여 특정 초점 노드의 ex:firstName과 ex:givenName에 대한 값 집합이 같아야 한다는 조건을 지정하는 방법을 보여줍니다.

다음 예제는 SHACL 속성 경로를 sh:path와 sh:equals 모두의 값으로 사용할 수 있음을 보여줍니다.

sh:disjoint는 값 노드의 집합이 sh:disjoint의 값인 SHACL 속성 경로를 통해 초점 노드에서 도달할 수 있는 노드의 집합과 서로소여야 한다는 조건을 지정합니다.

제약 조건 컴포넌트 IRI: sh:DisjointConstraintComponent

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

다음 예제는 셰이프에서 sh:disjoint를 사용하여 특정 초점 노드의 ex:prefLabel과 ex:altLabel이 어떤 값도 공유해서는 안 된다는 조건을 지정하는 방법을 보여줍니다.

sh:subsetOf는 모든 값 노드에 또한 도달할 수 있어야 한다는 조건을 지정합니다. 즉, 초점 노드에서 sh:subsetOf로 지정한 SHACL 속성 경로를 통해서도 도달할 수 있어야 합니다.

제약 조건 컴포넌트 IRI: sh:SubsetOfConstraintComponent

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

다음 예제는 셰이프에서 sh:subsetOf를 사용하여 어떤 사람의 가장 좋아하는 자녀가 실제 자녀 중 하나여야 한다는 조건을 지정하는 방법을 보여줍니다.

sh:lessThan는 각 값 노드가 모든 노드보다 작아야 한다는 조건을 지정합니다. 이러한 노드는 초점 노드에서 sh:lessThan의 값인 SHACL 속성 경로를 통해 도달할 수 있습니다.

제약 조건 컴포넌트 IRI: sh:LessThanConstraintComponent

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

다음 예제는 셰이프에서 sh:lessThan을 사용하여 ex:startDate의 모든 값이 ex:endDate의 값보다 "이전"이어야 한다고 지정하는 방법을 보여줍니다.

sh:lessThanOrEquals는 각 값 노드가 모든 노드보다 작거나 같아야 한다는 조건을 지정합니다. 이러한 노드는 초점 노드에서 sh:lessThanOrEquals의 값인 SHACL 속성 경로를 통해 도달할 수 있습니다.

제약 조건 컴포넌트 IRI: sh:LessThanOrEqualsConstraintComponent

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

다음 예제는 셰이프에서 sh:lessThanOrEquals를 사용하여 ex:startDate의 값이 ex:endDate의 값보다 늦지 않아야 한다고 지정하는 방법을 보여줍니다. sh:lessThan과 달리 프로젝트는 시작한 날에 종료될 수도 있습니다.

sh:not은 각 값 노드가 주어진 셰이프를 준수해서는 안 된다는 조건을 지정합니다. 이는 부정 및 논리 "NOT" 연산자에 해당합니다.

제약 조건 컴포넌트 IRI: sh:NotConstraintComponent

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

다음 예제는 셰이프에서 sh:not을 사용하여 특정 초점 노드가 ex:property의 값을 가져서는 안 된다는 조건을 지정하는 방법을 보여줍니다.

sh:and는 각 값 노드가 제공된 모든 셰이프를 준수해야 한다는 조건을 지정합니다. 이는 논리곱 및 논리 "AND" 연산자에 해당합니다.

제약 조건 컴포넌트 IRI: sh:AndConstraintComponent

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

sh:and의 값은 셰이프의 SHACL 목록이지만, 해당 셰이프의 순서는 검증 결과에 영향을 미치지 않는다는 점에 유의하세요. 단축 평가 의미 체계를 사용하는 구현에서는 순서가 검증 효율성에 영향을 미칠 수 있습니다. 평가하기 쉽거나 실패할 가능성이 높은 제약 조건을 목록의 앞쪽에 배치하는 것이 좋습니다.

다음 예제는 셰이프에서 sh:and를 사용하여 특정 초점 노드가 ex:property의 값을 정확히 하나 가져야 한다는 조건을 지정하는 방법을 보여줍니다. 이는 최소 개수를 지정하는 별도의 이름 있는 셰이프(ex:SuperShape)와 최대 개수를 추가로 지정하는 속성 셰이프의 논리곱을 통해 구현됩니다. 여기에서 볼 수 있듯이 sh:and를 사용하여 셰이프 간의 특수화 메커니즘을 구현할 수 있습니다.

sh:or는 각 값 노드가 제공된 셰이프 중 하나 이상을 준수해야 한다는 조건을 지정합니다. 이는 논리합 및 논리 "OR" 연산자에 해당합니다.

제약 조건 컴포넌트 IRI: sh:OrConstraintComponent

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

sh:or의 값은 셰이프의 SHACL 목록이지만, 해당 셰이프의 순서는 검증 결과에 영향을 미치지 않는다는 점에 유의하세요. 단축 평가 의미 체계를 사용하는 구현에서는 순서가 검증 효율성에 영향을 미칠 수 있습니다. 평가하기 쉽거나 성공할 가능성이 높은 제약 조건을 목록의 앞쪽에 배치하는 것이 좋습니다.

다음 예제는 셰이프에서 sh:or를 사용하여 특정 초점 노드가 ex:firstName의 값을 하나 이상 또는 ex:givenName의 값을 하나 이상 가져야 한다는 조건을 지정하는 방법을 보여줍니다.

다음 예제는 속성 셰이프에서 sh:or를 사용하여 주어진 속성 ex:address의 값이 데이터 유형 xsd:string인 리터럴 또는 ex:Address 클래스의 SHACL 인스턴스일 수 있음을 지정하는 방법을 보여줍니다.

SHACL의 모든 제약 조건은 실행 시 논리곱으로 결합된다는 점에 유의하세요. 다음 예제를 살펴보겠습니다:

올바른 해석은 (shapeA OR shapeB) AND (shapeC OR shapeD)입니다. 대상 노드는 shapeA 또는 shapeB를 준수해야 하며, 동시에 shapeC 또는 shapeD도 준수해야 합니다.

sh:xone은 각 값 노드가 제공된 셰이프 중 정확히 하나를 준수해야 한다는 조건을 지정합니다.

제약 조건 컴포넌트 IRI: sh:XoneConstraintComponent

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

sh:xone의 값은 셰이프의 SHACL 목록이지만, 해당 셰이프의 순서는 검증 결과에 영향을 미치지 않는다는 점에 유의하세요.

다음 예제는 셰이프에서 sh:xone을 사용하여 다음 조건을 지정하는 방법을 보여줍니다. 특정 초점 노드는 ex:fullName의 값을 갖거나, ex:firstName과 ex:lastName의 값을 가져야 하지만, 둘 다 가져서는 안 됩니다.

sh:node는 각 값 노드가 주어진 노드 셰이프를 준수해야 한다는 조건을 지정합니다.

제약 조건 컴포넌트 IRI: sh:NodeConstraintComponent

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

다음 예제는 속성 셰이프에서 sh:node를 사용하는 방법을 보여줍니다. ex:address 속성의 모든 값은 셰이프 ex:AddressShape가 나타내는 제약 조건을 충족해야 합니다.

다음 예제는 노드 셰이프에서 sh:node를 사용하는 방법을 보여줍니다.

SHACL에서 재귀적 셰이프를 처리하는 방법은 6.7.3 재귀적 셰이프 처리를 참조하세요.

sh:property는 각 값 노드가 주어진 속성 셰이프를 가져야 한다고 지정하는 데 사용할 수 있습니다.

제약 조건 컴포넌트 IRI: sh:PropertyConstraintComponent

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

sh:property와 sh:node 사이에는 중요한 차이가 있다는 점에 유의하세요. 값 노드가 제약 조건을 위반하면 해당 값 노드에 대한 sh:node의 검증 결과는 하나만 존재하며, sh:sourceConstraintComponent의 값으로 sh:NodeConstraintComponent를 갖습니다. 반면 sh:property에 대해서는 여러 검증 결과가 존재할 수 있으며, 이러한 결과는 속성 셰이프에 있는 제약 조건의 개별 제약 조건 컴포넌트를 sh:sourceConstraintComponent의 값으로 갖습니다.

다른 모든 검증 결과와 마찬가지로, sh:property를 통해 속성 셰이프에 도달할 때마다 검증 엔진은 새로운 검증 결과 노드를 반드시 생성해야 합니다. 여기에는 동일한 초점 노드가 동일한 속성 셰이프에 대해 검증되지만, 셰이프 그래프에서 서로 다른 경로를 통해 도달하는 경우도 포함됩니다.

sh:someValue는 하나 이상의 값 노드가 주어진 셰이프를 준수해야 한다는 조건을 지정합니다.

제약 조건 컴포넌트 IRI: sh:SomeValueConstraintComponent

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

구현은 값 노드 중 하나가 준수하는 것으로 확인되면 값 노드의 처리를 중단할 수 있습니다. 값 노드 집합에 있는 노드의 순서는 정의되지 않으므로, 실패를 일으키는 노드에 반드시 도달한다는 보장은 없습니다. 따라서 처리의 예측 가능성을 높이기 위해 모든 값 노드를 검사했지만 성공하지 못한 경우를 제외하고는 실패를 알리지 않고 무시합니다.

다음 예제에서 ex:DuckFarmerShape를 준수하는 모든 노드는 ex:tendsAnimal에 대해 하나 이상의 값을 가져야 하며, 해당 값은 ex:Duck의 SHACL 인스턴스여야 합니다.

sh:someValue는 sh:qualifiedValueShape와 sh:qualifiedMinCount 1을 조합한 구문 설탕으로 볼 수 있습니다.

또한 sh:someValue는 주로 속성 셰이프에서 사용할 때 의미가 있다는 점에 유의하세요. 노드 셰이프에서 sh:someValue는 sh:node 또는 sh:property를 사용하는 것과 동일합니다.

sh:qualifiedValueShape는 지정된 수의 값 노드가 주어진 셰이프를 준수해야 한다는 조건을 지정합니다. 각 sh:qualifiedValueShape는 동일한 주어에 sh:qualifiedMinCount의 값 하나, sh:qualifiedMaxCount의 값 하나 또는 두 속성의 값 하나씩을 가질 수 있습니다.

제약 조건 컴포넌트 IRI: sh:QualifiedMinCountConstraintComponent, sh:QualifiedMaxCountConstraintComponent

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

다음 예제 셰이프는 ex:parent 속성이 정확히 두 개의 값을 가지며, 그중 하나 이상이 여성이어야 한다는 조건을 지정하는 데 사용할 수 있습니다.

다음 예제는 sh:qualifiedValueShapesDisjoint를 사용하여 손에 ex:digit 값이 최대 5개 있어야 한다는 조건(sh:maxCount로 표현)을 지정하고, 그중 정확히 하나는 ex:Thumb의 인스턴스이고 정확히 4개는 ex:Finger의 인스턴스여야 하며, 엄지손가락과 다른 손가락은 서로소여야 한다는 조건을 보여줍니다. 즉, 한 손에서 다른 손가락을 엄지손가락으로 중복 계산할 수 없습니다.

sh:reifierShape는 속성 셰이프를 하나 이상의 노드 셰이프에 연결하는 데 사용할 수 있습니다. 모든 재구체화자는 이러한 노드 셰이프를 준수해야 합니다.

제약 조건 컴포넌트 IRI: sh:ReifierShapeConstraintComponent

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

RDF 데이터 모델은 매우 높은 유연성을 제공합니다. 원칙적으로 모든 노드는 어떤 속성에 대해서든 값을 가질 수 있습니다. 그러나 경우에 따라 노드에 적용할 수 있는 속성을 제한하는 조건을 지정하는 것이 유용합니다. SHACL 코어 언어에는 sh:closed라는 속성이 포함되어 있으며, 이를 사용하여 각 값 노드가 해당 셰이프에 대해 sh:property로 지정된 속성 셰이프를 통해 명시적으로 열거된 속성에 대해서만 값을 갖도록 하는 조건을 지정할 수 있습니다.

제약 조건 컴포넌트 IRI: sh:ClosedConstraintComponent

function collectProperties(S)
    SPARQL 경로를 통해 S에서 도달할 수 있는 모든 IRI 속성을 추가합니다
            sh:property/sh:path
    S가 셰이프 그래프에서 rdfs:Class의 SHACL 인스턴스인 경우 {
        셰이프 그래프에서 (S rdfs:subClassOf ?o)와 일치하는 각 트리플에 대해
            collectProperties(?o)
        셰이프 그래프에서 (?s sh:targetClass S)와 일치하는 각 트리플에 대해
            collectProperties(?s)
    }
    S가 셰이프 그래프에서 sh:NodeShape의 SHACL 인스턴스인 경우
        셰이프 그래프에서 (S sh:node ?o)와 일치하는 각 트리플에 대해
            collectProperties(?o)

데이터 그래프에서 값 노드의 각 rdf:type T에 대해
    collectProperties(T)

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

다음 예제는 셰이프에서 sh:closed를 사용하여 다음 조건을 지정하는 방법을 보여줍니다. 특정 초점 노드는 ex:firstName과 ex:lastName에 대해서만 값을 가질 수 있습니다. "무시되는" 속성인 rdf:type도 허용됩니다.

sh:closed sh:ByTypes의 사용 사례에는 현재 값 노드 유형의 상위 클래스(rdfs:subClassOf를 통해)에 선언된 속성뿐 아니라, sh:targetClass를 통해 해당 유형에 연결된 다른 셰이프와 sh:node를 통해 한 노드 셰이프에서 다른 노드 셰이프로 도달할 수 있는 셰이프도 포함됩니다. sh:ByTypes의 예제는 테스트 사례 라이브러리에서 확인할 수 있습니다: closed-003.ttl, closed-004.ttl.

sh:hasValue는 하나 이상의 값 노드가 주어진 RDF 용어와 같아야 한다는 조건을 지정합니다.

제약 조건 컴포넌트 IRI: sh:HasValueConstraintComponent

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

sh:in은 각 값 노드가 제공된 SHACL 목록의 구성원이어야 한다는 조건을 지정합니다.

제약 조건 컴포넌트 IRI: sh:InConstraintComponent

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

리터럴은 정확히 일치해야 합니다. 예를 들어 "04"^^xsd:byte는 "4"^^xsd:integer와 일치하지 않습니다.

sh:rootClass가 지정하는 조건은 각 값 노드가 주어진 클래스 또는 그 클래스의 (전이적) 하위 클래스여야 한다는 것입니다.

제약 조건 컴포넌트 IRI: sh:RootClassConstraintComponent

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

sh:rootClass 제약 조건은 일반적으로 클래스를 값으로 가질 수 있는 속성 셰이프(예: sh:class rdfs:Class를 통해)에 사용되어 값 노드에 허용되는 하위 클래스 계층을 제한합니다. 주어진 클래스는 허용되는 클래스 계층의 상한 역할을 합니다.

sh:uniqueValuesFor는 값 노드의 하나 이상의 지정된 속성 값이 현재 셰이프의 모든 대상 노드 내에서 고유해야 한다는 조건을 지정합니다.

제약 조건 컴포넌트 IRI: sh:UniqueValuesForConstraintComponent

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

리터럴은 정확히 일치해야 합니다. 예를 들어 "04"^^xsd:byte는 "4"^^xsd:integer와 일치하지 않습니다. 또한 sh:uniqueValuesFor는 이러한 값의 존재 자체를 요구하지 않으므로 흔히 sh:minCount 1 제약 조건과 함께 사용됩니다.

대상 노드의 계산은 셰이프의 정의에만 의존한다는 점에 유의하세요. 예를 들어, sh:uniqueValuesFor 제약 조건도 포함하는 셰이프의 sh:targetClass 선언에 의존합니다.