SHACL 1.2 프로파일링

프로파일링은 어떤 것의 "프로파일"을 만드는 행위입니다.

일반적으로 영어에서 어떤 것의 "profile"은 다음과 같습니다.

물리적 객체나 특징의 윤곽, 또는 이에 대한 표현

- 옥스퍼드 영어 사전, 17세기 이후 "profile"이라는 단어의 용례

데이터의 세계에서는 위 내용과 일관되는 "profile"의 파생 정의가 다음과 같습니다.

요약 또는 추출

이 정의에서는 영어 단어의 핵심 의미가 유지됩니다. 데이터 객체의 요약 또는 데이터 객체로부터의 추출은 그것의 윤곽일 수 있기 때문입니다. 예를 들어 3D 공간 객체의 2D 표현, 또는 많은 부분을 가진 데이터셋의 통계적 요약이 이에 해당합니다.

경고: 소개에서 이 지점까지의 프로파일링 배경은 The Profiles Vocabulary의 갱신된 버전으로 상향 반영될 수 있습니다.

정의상 SHACL은 RDF 데이터를 제약합니다. 따라서 shapes graph에 따라 유효한 모든 데이터는 data graph의 프로파일이 됩니다. shapes graph가 data graph의 모든 요소를 검증한다면, 그 결과로 나온 유효한 데이터는 해당 data graph의 "null" 프로파일이 됩니다. 이는 원래 데이터 그래프와 동일하다는 뜻입니다.

The Profiles Vocabulary는 specification의 맥락에서 profile을 다음과 같이 정의합니다.

다른 명세의 사용에 대해 제약하거나, 확장하거나, 결합하거나, 지침 또는 설명을 제공하는 명세

shapes graph를 "specification"으로 본다면, shapes graph에 따라 유효한 데이터가 검증된 data graph의 프로파일일 뿐만 아니라, shapes graph 자체도 data graph에 사용된 데이터 모델의 프로파일로 기능합니다.

이 문서에서는 최적의 프로파일링을 위해 SHACL 정보를 패키징하는 방법을 설명하고, 각 SHACL 명세를 위해 만들어진 SHACL shapes의 패키징을 통해 이를 예시합니다.

위 절의 개념을 염두에 두고, 이 명세는 다음을 정의합니다.

1. SHACL 패키징
2. SHACL의 프로파일
3. SHACL을 사용한 프로파일링

이 명세 전반에서 사용되는 용어는 여기에서 정의되거나 여러 출처 중 하나에서 가져온 것입니다. 그 다른 출처는 다음과 같습니다.

The Profiles Vocabulary

일반 프로파일링 용어 및 프로파일링 온톨로지 용어

SHACL 1.2 Core

SHACL 기술 용어

RDF 1.2 Concepts and Abstract Data Model

RDF 용어

다른 출처에서 가져온 용어는 본문에서 그 정의로 연결됩니다.

여기에서 정의하는 용어는 다음과 같습니다.

null profile

명세의 규칙 중 일부, 그리고 아마도 전부를 구현하지만 추가 규칙은 확실히 구현하지 않는 명세의 프로파일입니다.

null profile의 목적은 프로파일링 대상 명세가 실행 가능한 검증기와 같은 프로파일링 산출물을 제공하지 않을 때 이를 제공하는 것입니다.

SHACL Element

SHACL 명세 중 하나에서 정의된 RDF/OWL 클래스 또는 속성입니다.

경고: null profile의 정의는 The Profiles Vocabulary의 갱신된 버전으로 상향 반영될 수 있습니다. 이슈 dx-prof/56을 참조하세요.

이 명세에서 사용되는 모든 정의된 용어는 색인에 나열되어 있습니다.

이 명세에서는 다음 namespace prefix 정의가 사용됩니다.

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

{
  "@context": {
    "dcterms": "http://purl.org/dc/terms/",
    "ex": "http://example.com/ns#",
    "owl": "http://www.w3.org/2002/07/owl#",
    "prof": "http://www.w3.org/ns/dx/prof/" ,
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "role": "http://www.w3.org/ns/dx/prof/role/" ,
    "sh": "http://www.w3.org/ns/shacl#",
    "shpr": "http://www.w3.org/ns/shpr#"
  }
}

SHACL vocabulary 자체를 정의하는 그래프의 URI는 위의 namespace와 동일하며, 즉 #를 포함한다는 점에 유의하세요. 예를 들어 owl:imports를 통한 SHACL vocabulary에 대한 참조는 #를 포함해야 합니다.

명세 전반에 걸쳐 Turtle 및 JSON-LD의 RDF 그래프를 담은 색상으로 구분된 상자가 나타납니다. 상자의 색상과 제목은 그것이 shapes graph인지, data graph인지, 또는 그 밖의 것인지를 나타냅니다. Turtle 명세 조각은 위에 제시된 prefix binding을 사용합니다. Turtle 명세에만 일부가 강조 표시됩니다.

그림 내 관례는 다음 범례로 설명됩니다.

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

이 문서의 핵심어 MAY, MUST, MUST NOT, RECOMMENDED, SHOULD, 및 SHOULD NOT은 여기 표시된 것처럼 모두 대문자로 나타나는 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석되어야 합니다.

이 문서는 프로파일링 목적을 위해 SHACL Core 명세 [shacl12-core]의 데이터 모델에 대한 확장을 정의합니다.

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

여기에 명시된 구문 규칙은 영어로 제공되며 핵심어 MAY, MUST, MUST NOT, RECOMMENDED, SHOULD, 및 SHOULD NOT를 사용합니다. 이러한 핵심어는 여기 표시된 것처럼 모두 대문자로 나타나는 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석되어야 합니다.

이 명세의 규칙에 대한 데이터의 적합성 주장은 SHACL Overview 명세 [shacl12-overview]의 SHACL-SHACL Annex에 있는 SHACL-SHACL Profiling 검증기를 사용한 검증으로 테스트할 수 있습니다.

SHACL 요소의 그룹을 식별하고 그룹과 개별 SHACL 요소 사이의 관계를 알고자 하는 데에는 여러 이유가 있습니다. 이러한 이유에는 그룹의 목적, 한 그룹의 변경이 다른 그룹에 미치는 영향, 그리고 새 그룹을 만드는 방법을 이해하려는 것이 포함됩니다. 이를 위해 세 가지 유스 케이스가 명시되었습니다.

1. SHACL 요소 그룹 식별
2. 그룹이 의존하는 모든 SHACL 요소 찾기
3. 그룹이 의존하는 모든 SHACL 요소 그룹 찾기

위에 표시된 유스 케이스에 대한 해결책은 sh:ShapesGraph의 인스턴스를 사용하여 SHACL 요소를 그룹화하는 것과 같은 잘 정립된 관행을 바탕으로 다음 권고 사항으로 이어집니다.

1. sh:ShapesGraph의 인스턴스는 SHACL 요소의 인스턴스를 그룹화하는 데 사용되어야 합니다(SHOULD)
2. SHACL 요소의 인스턴스는 이를 정의하는 sh:ShapesGraph의 인스턴스를 rdfs:isDefinedBy 술어로 표시해야 합니다(SHOULD)
3. SHACL 요소를 사용하지만 이를 정의하지 않는 sh:ShapesGraph의 인스턴스는 rdfs:member 술어로 해당 SHACL 요소를 멤버로 표시해야 합니다(SHOULD)
4. SHACL 요소를 그룹화하는 데 사용되는 sh:ShapesGraph의 인스턴스는 sh:ShapesGraph의 인스턴스를 사용하여 식별된 다른 SHACL 요소 그룹에 대한 의존성을 owl:imports 술어로 표시해야 합니다(SHOULD)

다음 하위 절에서는 이러한 각 권고 사항을 자세히 설명합니다.

sh:ShapesGraph의 인스턴스는 SHACL 요소의 인스턴스를 그룹화하는 데 사용되어야 합니다(SHOULD).

SHACL 요소는 다른 많은 RDF 정의 데이터와 마찬가지로 흔히 OWL 2 Web Ontology Language RDF-Based Semantics (Second Edition)의 owl:Ontology 클래스 인스턴스 안에 그룹화되어 왔습니다.

예를 들어, Open Geospatial Consortium의 공간 RDF 데이터를 위한 GeoSPARQL 1.1 표준은 Turtle 파일 안에 27개의 sh:NodeShape 인스턴스와 비슷한 수의 sh:PropertyShape 인스턴스를 포함하는 SHACL 검증기를 제공합니다. 이 파일에는 검증 리소스의 수정일, 사용 라이선스 등과 같은 메타데이터를 제시하는 owl:Ontology의 인스턴스도 포함됩니다.

이 권고 사항은 그러한 관행을 대체하며, owl:Ontology의 특수화된 하위 클래스인 sh:ShapesGraph를 사용하여 SHACL 요소를 그룹화할 것을 권고합니다. 이는 모호한 그룹화 객체를 피하기 위한 것입니다.

SHACL 요소의 인스턴스는 이를 정의하는 sh:ShapesGraph의 인스턴스를 rdfs:isDefinedBy 술어로 표시해야 합니다(SHOULD).

sh:ShapesGraph 인스턴스를 사용하여 식별되는 그룹에 SHACL 요소를 넣을 때의 일반적인 관행은 단순히 요소와 온톨로지 인스턴스를 RDF 파일 안에 포함하는 것이었습니다. 이는 데이터 교환에는 합리적이지만, 교환된 파일이 RDF 데이터베이스에 저장될 때 sh:ShapesGraph 인스턴스와 그 안에 정의된 SHACL 요소 사이의 연관이 사라질 수 있습니다. named graph로 로드되는 경우, 온톨로지와 SHACL 요소를 그룹화하는 named graph를 통해 연관이 유지될 수도 있지만, 이는 비의미론적 연관, 즉 그래프에서 직접 보이지 않는 연관입니다.

이 권고 사항은 SHACL 요소의 작성자가 해당 SHACL 요소가 정의된 그룹을 표시해야 한다고 제안합니다(SHOULD). RDF에서 이러한 주장의 예는 다음과 같습니다.

SHACL 요소를 사용하지만 이를 정의하지 않는 sh:ShapesGraph의 인스턴스는 rdfs:member 술어로 해당 SHACL 요소를 멤버로 표시해야 합니다(SHOULD)

SHACL 요소가 요소 그룹 안에서 사용되지만 그 그룹에 의해 정의되지 않는 경우, 해당 그룹에 의해 정의된 것으로 표시해서는 안 되므로(SHOULD NOT) 위 절의 권고 사항은 관련이 없습니다. Linked Data 원칙 [LDP]에 따라, 이를 정의하지 않는 그룹 안에서 SHACL 요소를 재사용하는 것은 예상되고 권장됩니다.

SHACL 요소가 이를 정의하지 않는 그룹에 포함됨을 나타내기 위해 rdfs:member 술어를 사용하는 예와, 위 예에서처럼 rdfs:isDefinedBy를 사용하는 예는 다음과 같습니다.

SHACL 요소를 그룹화하는 데 사용되는 sh:ShapesGraph의 인스턴스는 sh:ShapesGraph의 인스턴스를 사용하여 식별된 다른 SHACL 요소 그룹에 대한 의존성을 owl:imports 술어로 표시해야 합니다(SHOULD).

SHACL 검증 도구에서는 RDF 데이터를 포함하는 파일과 같은 한 컬렉션에서 다른 컬렉션으로 owl:imports 지시를 통해 SHACL 요소를 가져오는 것이 확립된 관행입니다. pySHACL [PYSH]과 같은 많은 SHACL 검증 엔진이 이를 수행하며, 이 관행은 특정 검증 엔진의 동작이 해당 주장으로부터 발생할 것으로 기대되지 않더라도 한 컬렉션/그룹에서 다른 컬렉션/그룹으로의 의존성을 나타내는 데 권장됩니다. 이는 SHACL 데이터 관리에도 유용한 정보가 될 가능성이 높습니다.

owl:imports의 예는 아래 예와 같습니다.

위 네 가지 권고 사항의 사용으로부터 의존성 함의를 도출할 수 있으며, 이는 동기 절에 표시된 세 가지 유스 케이스에 답하는 데 사용할 수 있습니다.

TODO

data graph에 대해 shapes graph가 수행한 검증 작업의 결과를 RDF에 영속화해야 할 수 있습니다. 그렇다면 data graph DG는 술어 shpr:conformsTo를 사용하여 shapes graph SG에 적합한 것으로 표시될 수 있습니다(MAY). 이 상황에서 DG는 sh:DataGraph의 인스턴스로, SG는 sh:ShapesGraph의 인스턴스로 추론됩니다.

SHACL의 프로파일은 The Profiles Vocabulary를 사용하여 선언해야 합니다. SHACL 1.2의 Core 프로파일 선언은 다음과 같습니다.

이 선언은 Core 프로파일을 IRI <http://www.w3.org/ns/shacl/profile/core>로 식별하고, 그것이 prof:Profile의 인스턴스이며, 2015년의 원래 SHACL 발행물의 프로파일이고, 두 개의 프로파일 리소스, 즉 명세와 검증기를 가진다는 것을 나타냅니다.

The Profiles Vocabulary의 용어를 사용해 설명하면, 위에 링크된 각 명세의 온라인 문서 형태는 SHACL 1.2의 프로파일을 함께 구성하는 많은 리소스 중 하나일 뿐입니다. 이 문서는 Specification — "사람이 읽을 수 있는 형식으로 프로파일을 정의" — 의 리소스 역할을 수행하며, 다른 리소스들은 다른 역할을 수행합니다. SHACL 사용자에게 특히 관심 있는 것은 각 프로파일의 SHACL shapes graph로, 이는 Validation — "데이터가 프로파일에 적합한지 검증하는 방법에 대한 지침 제공" — 의 역할을 수행합니다. SHACL 1.2의 다양한 프로파일은 다른 프로파일 리소스 역할을 가진 추가 리소스를 제공할 수 있습니다.

shapes graph 검증 리소스는 SHACL 1.2 Overview의 SHACL-SHACL 부록에 제공됩니다.

SHACL 패키징을 사용하여 프로파일에서 지원할 SHACL 요소를 선택하는 방법을 설명합니다.

이 명세의 발행 시점에는 위에 나열된 명세 각각에 대한 SHACL 1.2 프로파일이 알려져 있습니다. 또한 모든 명세 프로파일을 결합한 union profile도 알려져 있습니다.

계산 노력으로 정의된 SHACL 프로파일과 SHACL UI 구현 노력으로 정의된 SHACL 프로파일도 알려져 있습니다.

이러한 알려진 프로파일은 부록 A에 나열되어 있으며, 향후 SHACL 프로파일은 W3C SHACL 커뮤니티가 관리하는 저장소 https://github.com/w3c/shacl-resources에 나열될 예정입니다.

다음은 콘텐츠의 범위를 정하기 위해 서로 다른 논리를 사용하는 SHACL의 다른 프로파일입니다.

SHACL 1.2의 추가 프로파일은 어떤 기준으로든 만들 수 있습니다. 예를 들어, OWL 2 Web Ontology Language Profiles (Second Edition)의 프로파일과 매우 비슷하게, 특정 계산 복잡도로 제한된 shape types만 구현하는 SHACL 1.2 Core의 프로파일을 갖는 것이 바람직할 수 있습니다. 이 경우, 위의 SHACL 패키징 절에 제시된 메커니즘을 사용하여 SHACL 1.2 Core 요소 중 일부만 포함하는 프로파일 정의를 만들 수 있습니다.

SHACL 1.2의 프로파일을 만들 때에는, 현재 알려진 SHACL 1.2의 프로파일 — Specification Profiles 및 Union Profile — 에 따라 프로파일을 식별하고 제시하는 것이 중요합니다. 그래야 다른 사람을 포함하여 효과적으로 사용할 수 있습니다. SHACL 1.2 프로파일의 작성자는 다음을 해야 합니다(SHOULD).

1. IRI로 프로파일을 식별합니다
2. 이 명세에서 정의한 SHACL 1.2의 프로파일로 해당 프로파일을 정의합니다
   • 부록 A를 참조하세요
3. SHACL 사용자 커뮤니티와 프로파일을 공유합니다
   • SHACL 커뮤니티 리소스 공유에 대한 정보는 SHACL Resources Repository를 참조하세요

위의 명세 프로파일링과 중복되어 절 내용이 제거되었습니다.

SHACL은 RDF 데이터에 대한 제약과 추론 규칙을 구현할 수 있는 언어입니다. 이 두 가지는 프로파일 설계자가 하고자 할 수 있는 일의 전체가 아닙니다. 예를 들어, 프로파일이 왜 그리고 어떻게 만들어졌는지에 대한 문서를 포함하거나, 확장된 스키마 안에 새로운 모델 요소(클래스, 술어 등)를 제공하고 싶을 수 있습니다.

SHACL은 가능한 모든 프로파일 부분에 사용할 수 없으므로, 프로파일 설계자는 프로파일의 전체 부분 집합과 이들 간의 관계를 설정하는 방법에 대한 지침을 위해 SHACL 명세군 밖의 명세를 살펴볼 필요가 있습니다. 이를 위해 The Profiles Vocabulary가 사용될 것으로 예상됩니다.

The Profiles Vocabulary의 Resource Role Instances 어휘를 참조하면, SHACL 그래프가 프로파일 안에서 Validation 역할을 수행할 수 있으며, SHACL이 OWL이 Classes와 Properties를 선언하는 것과 마찬가지로 Node 및 Property Shapes를 선언할 수 있으므로 어쩌면 Specification 역할도 수행할 수 있음이 분명해 보입니다.

SHACL shapes는 자연스럽게 모델과 데이터를 제약하므로, 프로파일이 어떤 것 — 표준 또는 다른 프로파일 — 을 어떻게 제약하는지를 나타내는 데 사용된다면 Constraints의 역할을 수행할 수 있습니다.

SHACL Rules가 한 모델에서 다른 모델로 데이터를 변환하도록 구현되는 경우, SHACL shapes는 Mapping 역할도 수행할 수 있습니다.

프로파일 계층 구조는 하나의 프로파일이 다른 프로파일의 특수화가 되어, 더 구체적인 프로파일이 더 넓은 프로파일로부터 제약을 상속하는 체인을 형성하는 배열입니다. The Profiles Vocabulary의 규칙에 따라, C가 B의 프로파일이고 B가 A의 프로파일이라면, C에 적합하려는 데이터는 B와 A에도 적합한 경우에만 유효할 수 있습니다.

프로파일에 대한 데이터의 적합성을 확인한다는 것은 Validation 역할을 가진 프로파일 리소스로 데이터를 테스트한다는 뜻입니다.

미완성

SHACL을 사용하여 만들어진 명세의 null profile은, SHACL을 사용하여 해당 명세의 규칙 중 일부, 그리고 아마도 전부를 구현하지만 SHACL에서 그 밖의 어떤 규칙도 구현하지 않는 그 명세의 프로파일입니다.

SHACL을 사용하여 명세의 null profile을 만드는 주된 목적은 SHACL 검증을 통해 해당 명세에 대한 적합성 테스트를 가능하게 하는 것입니다. 이러한 목적이 존재하는 이유는 많은 RDF 데이터 모델이 모델 명세, 예를 들어 OWL 모델 또는 모델에 관한 자연어 문서만을 가지고 있지만, SHACL 검증기와 같은 데이터 검증 메커니즘을 제공하지 않기 때문입니다. 이러한 모델의 예로는 Data Catalog Vocabulary (DCAT) - Version 3, Schema.org, The RDF Data Cube Vocabulary, 그리고 많은 W3C 표준이 있습니다.

명세의 null profile을 만드는 데 보편적이고 정밀한 방법론을 제시할 수는 없습니다. 그 작업의 본질상 명세의 규칙이 부정확하게 정의되어 있을 수 있으며, 따라서 이를 정밀한 SHACL로 특성화하는 데 사용되는 방법도 부정확한 규칙 정의가 달라지는 것과 마찬가지로 달라질 것이기 때문입니다.

다른 명세의 null profile 예는 B. Null Profile Examples를 참조하세요.

'conforms to' 규칙은 Data Graph와 연결된 Validation Report가 있고, 그 보고서가 Shapes Graph가 검증에 사용되었음을 나타내며 sh:conforms 속성이 true를 나타내는 경우, Data Graph가 Shapes Graph에 적합한 것으로 표시될 수 있게 하는 추론 규칙입니다.

이 추론 규칙은 sh:conforms 속성값에 대한 테스트 때문에 OWL property chain axiom으로 표현할 수 없으므로, 여기서는 SPARQL 1.2 Query Language 규칙과 SHACL 1.2 Rules 규칙으로 모두 제시합니다.