SHACL 1.2 配置文件化

配置文件化是为某物创建“配置文件”的行为。

一般而言，在英语中，某物的“profile”如下：

物理对象或特征的轮廓，或对此的表示

- 《牛津英语词典》，自 17 世纪以来对 “profile” 一词的用法

在数据领域中，与上述含义一致的“profile”派生定义为：

摘要或提取

在这个定义中，保留了该英语词的核心含义，因为对一个数据 对象的摘要或提取可能是它的轮廓；例如，三维空间对象的二维表示，或 对具有许多部分的数据集进行的统计 摘要。

警告：引言中截至此处的配置文件化背景内容，可能会被上游纳入 The Profiles Vocabulary 的更新 版本。

根据定义，SHACL 约束 RDF 数据。因此，任何根据 形状图 有效的数据，都将是该 数据 图的一个配置文件。如果某个 形状图 验证了 数据 图的所有元素，则得到的有效数据将是该 数据 图的“空”配置文件，这意味着它与原始数据 图相同。

The Profiles Vocabulary 在 规范的上下文中，将 配置文件定义为：

一种规范，它约束、扩展、组合或提供有关 使用 其他规范的指导或说明

如果一个 形状图被视为 “规范”，那么不仅根据该 形状图有效的数据是 被验证的 数据图的配置文件，而且 该 形状图本身也 充当用于该 数据 图的数据模型的配置文件。

在本文档中，我们描述如何打包 SHACL 信息以实现最佳配置文件化，并通过对 每个 SHACL 规范所创建的 SHACL 形状进行打包来举例说明。

结合上一节的概念，本规范定义如下内容：

1. 打包 SHACL
2. SHACL 的配置文件
3. 使用 SHACL 进行配置文件化

本规范通篇使用的术语，要么在此定义，要么取自若干 来源之一。这些 其他来源包括：

The Profiles Vocabulary

通用配置文件化术语和配置文件化本体术语

SHACL 1.2 Core

SHACL 技术术语

RDF 1.2 概念与抽象数据模型

RDF 术语

取自其他来源的术语会在文本中链接到其定义。

此处定义的术语包括：

空配置文件

某个规范的配置文件，其中实现了该规范的一些规则，并且很可能实现了全部 规则，但明确没有任何附加规则。

空配置文件的目的，是在被配置文件化的规范本身没有提供时， 提供配置文件化制品，例如可执行的 验证器。

SHACL 元素

由某个 SHACL 规范定义的 RDF/OWL 类或属性。

警告：空配置文件的定义可能会被上游纳入 The Profiles Vocabulary 的更新版本。参见 议题 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 等同于 上述命名空间，也就是说，它包含 #。 对 SHACL 词汇表的引用，例如通过 owl:imports，应包含 #。

在整个规范中，将出现带有颜色编码的框，其中包含 Turtle 和 JSON-LD 形式的 RDF 图。 框的颜色和标题指示它是 形状 图、 数据 图，还是其他 内容。 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 附录的 SHACL-SHACL Profiling 验证器进行验证来测试。

人们可能出于多种原因，希望标识 SHACL 元素组，并 了解组与单个 SHACL 元素之间的关系。 这些原因包括想要理解一个组的目的、一个组中的变更如何影响 另一个组，以及如何创建新的组。 对此已经阐明了三个用例：

1. 标识 SHACL 元素组
2. 找出某个组所依赖的所有 SHACL 元素
3. 找出某个组所依赖的所有 SHACL 元素组

对上述用例的解决方案产生了以下建议，这些建议建立在 已确立的实践之上，例如使用 sh:ShapesGraph 的实例来分组 SHACL 元素：

1. sh:ShapesGraph 的实例SHOULD用于分组 SHACL 元素的实例
2. SHACL 元素的实例SHOULD使用 rdfs:isDefinedBy 谓词指示定义它的 sh:ShapesGraph 实例
3. 使用某个 SHACL 元素、 但并不定义它的 sh:ShapesGraph 实例，SHOULD使用 rdfs:member 谓词将该 SHACL 元素指示为成员
4. 用于分组 SHACL 元素的 sh:ShapesGraph 实例，SHOULD使用 owl:imports 谓词指示其对其他 SHACL 元素组的依赖，这些组使用 sh:ShapesGraph 的实例标识

以下各小节详细说明这些建议。

sh:ShapesGraph 的实例SHOULD用于分组 SHACL 元素的实例。

SHACL 元素与许多其他 RDF 定义性数据一样，过去 通常被分组在 OWL 2 Web Ontology Language RDF-Based Semantics (Second Edition) 的 owl:Ontology 类实例中。

例如，开放地理空间联盟的 GeoSPARQL 1.1 空间 RDF 数据标准 提供了一个 SHACL 验证器， 其中在一个 Turtle 文件内包含 27 个 sh:NodeShape 实例以及数量相近的 sh:PropertyShape 实例。该文件还包含一个 owl:Ontology 实例，用于呈现该 验证资源的元数据，例如其 修改日期、使用许可证等等。

本建议取代该实践，并建议使用 sh:ShapesGraph 这一 owl:Ontology 的专门子类来分组 SHACL 元素。这是为了避免 有歧义的分组对象。

SHACL 元素的实例SHOULD使用 rdfs:isDefinedBy 谓词指示定义它的 sh:ShapesGraph 实例。

将 SHACL 元素放入由 sh:ShapesGraph 实例标识的组中时，常见实践 只是将这些元素和本体实例包含在一个 RDF 文件中。对于 数据交换而言，这是合理的； 但是，当交换的文件被存储到 RDF 数据库中时， sh:ShapesGraph 实例 与其中定义的 SHACL 元素之间的关联可能会丢失。如果加载到 命名图中， 该关联可能会通过命名图保留下来，该命名图对本体和 SHACL 元素进行分组，但这是一种非语义的 关联，即不能直接在图中看到的关联。

本建议提出，SHACL 元素的创建者SHOULD指示 定义该 SHACL 元素的组。此类 RDF 断言的示例如下：

使用某个 SHACL 元素、 但并不定义它的 sh:ShapesGraph 实例，SHOULD使用 rdfs:member 谓词将该 SHACL 元素指示为 成员

当一个 SHACL 元素在某个元素组内被使用但并非由该组 定义时，SHOULD NOT将其指示为由该组 定义，因此上一节中的建议并不适用。根据链接数据原则 [LDP]， 在不定义 SHACL 元素的组内复用这些元素是预期且受鼓励的。

以下示例展示了如何使用 rdfs:member 谓词来指示某个 SHACL 元素被包含在一个 并不定义它的组中，同时也展示了如上例所示的 rdfs:isDefinedBy 的使用：

用于分组 SHACL 元素的 sh:ShapesGraph 实例，SHOULD使用 owl:imports 谓词指示其对其他 SHACL 元素组的依赖， 这些组使用 sh:ShapesGraph 的实例标识。

在 SHACL 验证工具中，从一个集合（例如包含 RDF 数据的 文件）通过 owl:imports 指令将 SHACL 元素导入 另一个集合，是已经确立的实践。许多 SHACL 验证引擎 都这样做，例如 pySHACL [PYSH]；推荐采用这种实践来指示从一个集合/组 到另一个集合/组的依赖，即使并不预期某个特定验证引擎会因该断言而采取行动： 对 SHACL 数据管理而言，这也很可能具有有用的信息价值。

owl:imports 的示例如下。

可以从上述四项建议的使用中得出依赖项含义，这些含义可用于回答 动机一节中指出的 三个用例。

TODO

可能有必要将由 形状 图对 数据 图执行的验证操作结果持久化到 RDF 中。若是如此， 数据图 DG MAY使用 shpr:conformsTo 谓词被指示为符合 形状图 SG。在这种情况下，将推断 DG 是 sh:DataGraph 的实例，SG 是 sh:ShapesGraph 的实例。

SHACL 的配置文件应使用 The Profiles Vocabulary 来声明。SHACL 1.2 Core 配置文件的声明如下：

此声明使用 IRI <http://www.w3.org/ns/shacl/profile/core> 标识 Core 配置文件，并 指示它是 prof:Profile 的一个实例，是 2015 年原始 SHACL 发布物的一个配置文件，并且具有两个配置文件资源：一个规范和一个验证器。

使用 The Profiles Vocabulary 中的术语描述时， 上面链接的每个规范的在线文档形式，只是共同构成 SHACL 1.2 配置文件的众多 资源之一。该文档 扮演 Specification 这一资源角色——“以人类可读的形式定义配置文件”——而其他资源 扮演其他角色。SHACL 用户尤其感兴趣的是每个 配置文件的 SHACL 形状图，它扮演 Validation 角色—— “提供关于如何验证数据是否符合该 配置文件的说明”。SHACL 1.2 的各个配置文件 可能会提供具有其他配置文件资源角色的附加资源。

形状图验证资源在 SHACL 1.2 Overview 的 SHACL-SHACL 附录中给出。

描述如何使用 SHACL 的打包来挑选要在你的配置文件中支持的 SHACL 元素。

在本规范发布时，已知存在一个对应于上文列出的每个规范的 SHACL 1.2 配置文件。此外，一个联合配置文件——所有规范配置文件的组合—— 也已知存在。

还已知存在一个由计算工作定义的 SHACL 配置文件，以及一个由 SHACL UI 实现工作定义的 SHACL 配置文件。

这些已知配置文件列在附录 A中，未来的 SHACL 配置文件将列在 W3C SHACL 社区控制的仓库中，地址为 https://github.com/w3c/shacl-resources。

以下是一些使用不同逻辑来界定其内容范围的其他 SHACL 配置文件。

可以使用任何标准创建 SHACL 1.2 的附加配置文件。例如，可能希望 为 SHACL 1.2 Core 创建只实现限于特定计算复杂度的形状类型的配置文件，这很 类似于 OWL 的配置文件 OWL 2 Web Ontology Language Profiles (Second Edition)。在这种情况下，可以利用 上文 打包 SHACL 一节给出的机制来制定一个配置文件定义， 只包含 SHACL 1.2 Core 的部分 元素。

在制作 SHACL 1.2 配置文件时，重要的是按照当前已知的 SHACL 1.2 配置文件——规范配置文件和联合配置文件——来标识并呈现该配置文件，以便它们能够 有效使用，包括 被他人使用。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 的 资源 角色实例词汇表，似乎很明显， SHACL 图可以在配置文件中承担 Validation 角色，或许 也可以承担 Specification 角色，因为 SHACL 可用于 声明节点形状和属性形状，正如 OWL 可用于声明类和属性一样。

SHACL 形状天然约束模型和数据，因此如果用来指示某个配置文件如何约束 某个事物 ——标准或另一个配置文件——它们就可以承担 Constraints 角色。

如果实现了 SHACL 规则以将数据从一种模型转换为另一种模型， 它们也可以承担 Mapping 角色。

配置文件层级是一种安排，其中一个配置文件是另一个配置文件的专门化，形成一条链， 更具体的配置文件从更宽泛的配置文件继承约束。按照 The Profiles Vocabulary 的规则，如果 C 是 B 的配置文件，而 B 是 A 的配置文件，则 希望符合 C 的数据，只有在也符合 B 和 A 时才可能有效。

检查数据对配置文件的一致性，意味着使用具有 Validation 角色的配置文件资源来测试该数据。

未完成

使用 SHACL 创建的某个规范的 空配置文件，是该规范的一个 配置文件，其中 SHACL 被用于实现该规范的一些规则，并且很可能实现全部规则，但不在 SHACL 中实现任何其他规则。

使用 SHACL 创建规范空配置文件的主要目的，是能够通过 SHACL 验证来测试 对该规范的一致性。这个目的之所以存在，是因为许多 RDF 数据模型 具有 模型规范，或许是 OWL 模型，或者只是模型的自然语言文档，但并不 提供 数据验证机制，例如 SHACL 验证器。此类模型的示例包括：Data Catalog Vocabulary (DCAT) - Version 3、Schema.org、 The RDF Data Cube Vocabulary，以及许多 W3C 标准。

无法给出创建规范空配置文件的通用且精确的方法， 因为就该任务的本质而言，规范的规则可能定义得并不精确，因此 用 SHACL 对它们进行刻画的方法——而 SHACL 是精确的——也会像不精确的规则 定义本身一样有所不同。

有关其他规范的空配置文件示例，请参见 B. 空配置文件示例。

“conforms to”规则是一条推理规则：如果存在与 Data Graph关联的 Validation Report， 该报告指示 Shapes Graph 被用于验证，并且 sh:conforms 属性指示为 true，则允许指示该 Data Graph 符合 该 Shapes Graph。

由于需要测试 sh:conforms 属性值， 这条推理规则不能表述为 OWL 属性链公理，因此这里同时以 SPARQL 1.2 Query Language 规则和 SHACL 1.2 Rules 规则的形式给出。