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は、 仕様の文脈における profileを次のように定義する:

他の仕様の使用について制約、拡張、結合、またはガイダンスや説明を提供する仕様

shapes graphを 「仕様」とみなす場合、 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の更新版へ上流化される可能性がある。Issue dx-prof/56を参照されたい。

この仕様で用いられる定義済み用語はすべて、索引に一覧されている。

この仕様では、次の名前空間接頭辞定義を用いる:

この仕様では、次のJSON-LDコンテキストを用いる:

{
  "@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語彙自体を定義するグラフのURIは、上記の名前空間と同等であり、 すなわち#を含むことに注意。 例えばowl:importsを介したSHACL語彙への参照には、 #を含めるべきである。

仕様全体を通じて、TurtleおよびJSON-LDのRDFグラフを含む色分けされたボックスが現れる。 ボックスの色とタイトルは、それが shapes graph、 data graph、またはそれ以外のもののいずれであるかを示す。 Turtle仕様断片では、上で与えた接頭辞バインディングを用いる。 ハイライトされる部分を持つのは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 validatorを用いた検証によってテストできる。

SHACL要素のグループを 識別し、グループと個々のSHACL要素との関係を知りたい理由は複数ある。 これらの理由には、グループの目的、あるグループの変更が別のグループにどのような影響を与えるか、 そして新しいグループをどのように作成するかを理解したいというものが含まれる。 このために3つのユースケースが明示されている:

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 validator を提供している。このファイルには、更新日、利用ライセンスなど、検証リソースのメタデータを提示する 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であるため、上記セクションの推奨事項は関係しない。 それらを定義しないグループ内でのSHACL要素の再利用は、Linked Dataの原則 [LDP]に従って 期待され、奨励される。

それを定義しないグループにSHACL要素が含まれることを示すための rdfs:member述語の使用例、および上記例と同様の rdfs:isDefinedByの使用例は、次のとおりである:

SHACL要素を グループ化するために用いられるsh:ShapesGraphのインスタンスは、 sh:ShapesGraphのインスタンスを用いて識別される他のSHACL要素の グループへの依存を、owl:imports 述語で示すSHOULD。

SHACL検証ツールでは、RDFデータを含むファイルなど、あるコレクションから SHACL要素を owl:imports命令によって別のコレクションへインポートすることが確立された実践である。 pySHACL [PYSH]など、多くのSHACL検証エンジンが これを行っており、この実践は、特定の検証エンジンの動作がそのアサーションから生じることを期待しない場合でも、 あるコレクション／グループから別のものへの依存を示すために推奨される。 SHACLデータ管理にとっても、有用な情報となる可能性が高い。

owl:importsの例は、以下の例のとおりである。

依存関係の含意は、上記4つの推奨事項の使用から導くことができ、これは 動機セクションで示した3つのユースケースに答えるために利用できる。

TODO

data graphに対して shapes graphによって実行された検証アクションの結果を、RDFに永続化する必要があるかもしれない。 その場合、データグラフDGは、述語 shpr:conformsToを用いて、shapeグラフ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公開物のプロファイルであること、 そして仕様と検証器という2つのプロファイル・リソースを持つことを示す。

The Profiles Vocabularyの用語を用いて記述すると、 上でリンクされている各仕様のオンライン文書形式は、SHACL 1.2のプロファイルを構成する多数のリソースの うちの1つにすぎない。この文書は、 Specification —「プロファイルを人間が読める形式で定義する」— というリソース役割を果たし、他のリソースは 他の役割を果たす。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型のみを 実装する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データに対する制約と推論ルールを実装できる言語である。これら2つは、 プロファイル設計者が行いたいことの完全な集合ではない。例えば、プロファイルがなぜ、どのように 作成されたかについての文書を含めたい場合や、拡張スキーマ内で新しいモデル要素 （クラス、述語など）を提供したい場合がある。

SHACLは考えられるすべてのプロファイル部分に使用できるわけではないため、プロファイル設計者は、 プロファイルの全体的な部分集合と、それらを互いにどのように関連付けるかについてのガイダンスを、 SHACL仕様ファミリーの外部の仕様に求める必要がある。 The Profiles Vocabularyが そのために使用されることが期待される。

The Profiles Vocabularyの Resource Role Instancesの語彙を参照すると、 SHACLグラフがプロファイル内で Validationの役割を果たすことは明らかであり、 また、SHACLはOWLがクラスやプロパティを宣言するのと同じようにNode ShapeおよびProperty Shapeを宣言できるため、 Specificationの役割も 果たせる可能性がある。

SHACL shapesは自然にモデルとデータを制約するため、あるもの — 標準または別のプロファイル — をプロファイルがどのように制約するかを示すために用いられる場合、 Constraintsの役割を果たすことができる。

また、SHACL Rulesがあるモデルから別のモデルへデータを変換するために実装される場合、 Mappingの役割を果たすこともできる。

プロファイル階層とは、あるプロファイルが別のプロファイルの特殊化であり、より具体的なプロファイルが より広いプロファイルから制約を継承する連鎖を形成する配置である。 The Profiles Vocabularyの規則に従うと、 CがBのプロファイルであり、BがAのプロファイルである場合、 Cに適合しようとするデータは、BおよびAにも適合している場合にのみ 妥当になり得る。

プロファイルに対するデータの適合性を確認するとは、 Validation 役割を持つプロファイル・リソースでデータをテストすることを意味する。

未完成

SHACLを用いて作成される仕様の null profileとは、SHACLを用いてその仕様のルールの一部、 おそらくはすべてを実装するが、他のルールはSHACLで実装しない、その仕様のプロファイルである。

SHACLを用いて仕様のnull profileを作成する主な目的は、SHACL検証によってその仕様への適合性テストを 可能にすることである。この目的が存在するのは、多くのRDFデータモデルが、OWLモデルまたは モデルの自然言語文書のみといったモデル仕様を持つ一方で、SHACL validatorのようなデータ検証の仕組みを 提供していないためである。そのようなモデルの例には、 Data Catalog Vocabulary (DCAT) - Version 3、Schema.org、 The RDF Data Cube Vocabulary、および多くのW3C 標準がある。

仕様のnull profileを作成するための普遍的かつ精密な方法論を与えることはできない。 なぜなら、その作業の性質上、仕様のルールが不正確に定義されている場合があり、そのため、 精密であるSHACLでそれらを特徴付けるために用いる方法も、不正確なルール定義と同様に変化するからである。

他の仕様のnull profileの例については、B. Nullプロファイルの例を参照されたい。

「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規則の両方として示す。