无法在 SHACL 形状图中定义限制继承，只能在数据图中定义？
Impossible to define restriction inheritance in SHACL shapes graph, only in data graph?
我正在努力理解（对我来说）关于形状约束继承的一个非常不直观的特征。我的问题是，当我尝试通过 rdfs:subClassOf 继承形状约束时，仅当在数据图中指定继承时，这才有效 ，而不是在形状图中指定时.
我已经在旧的和 Zazuko SHACL 游乐场中验证了以下 PoC，并收到了相同的答案。
形状图：
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix : <http://lorem.ipsum/#> .
:Agent a rdfs:Class,
sh:Nodeshape;
sh:property [
sh:minCount 1;
sh:path :Name;
].
:Adult rdfs:subClassOf :Agent.
数据图：
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix : <http://lorem.ipsum/#> .
:Father a :Adult.
:UnknownPerson a :Agent.
这个版本只要求:UnknownPerson至少有一个:Name 属性，但是当我将:Adult rdfs:subClassOf :Agent移动到数据图时，它立即识别出:Father和:UnknownPerson应该有。
我不明白为什么我不能在形状图本身中定义这种继承？
如果在更基本的 RDF 级别上，:Adult class 被定义为 :Agent class 的 subclass（子集），因此它也应该是 sh:NodeShape，当它被定义为模式的一部分而不是要验证的数据的一部分时，为什么不对它应用 属性 约束？
这是一个非常有效的问题，决定可能是任何一种方式。定义 SHACL 的工作组最终采用了当前设计——要求目标机制的数据图中有 rdfs:subClassOf 个三元组，在 sh:class 等地方——因为它被认为更一致并且 self-contained.基本概念是“SHACL 实例”，它确定一个节点是否算作 class 的实例。鉴于 rdf:type 三元组当然会在数据图中，我们认为最好也假设 subClassOf 三元组在同一个图中。
除其他外，这意味着算法不需要在图之间切换（例如在 SPARQL 中它将是路径表达式 rdf:type/rdfs:subClassOf*），并且可以将形状图编译成一些静态数据结构，确保在验证期间不需要再次查询原始 RDF 形状图。我忘记了当前设计的其他原因。和往常一样，W3C Data Shapes WG 的会议纪要存档可能有更多详细信息。
在实践中，通常通过将形状图包含到数据图中来解决这个问题，例如使用 owl:imports。这样，rdfs:subClassOf 三元组只需要在形状图中断言，但在数据图中也可见。
由于评论区的名额很少，我决定在这里更详细地阐述我的用例。问题的要点是，与我一起工作的许多 IT 架构师都具有 UML 背景，因此假设 class RDF 世界中的继承将以类似的方式工作 和 模式和符合所述模式的实例数据之间存在严格的区别。我一直试图做的是找到一个关于如何在 RDF 中表示他们的范例的 PoC（我们努力增加链接数据的使用并以易于理解的方式介绍其范例）并且作为标准 SHACL 是其中之一明显的主要候选人。
PoC 的要求之一是能够按照 UML 表示句法约束：将一些 all-encompassing 约束构建到基础级别 class（形状）中，然后利用这些约束属于根域 class（形状）的所有 sub-classes（形状）。例如。我们可能想要指定一个 Person 形状，其普遍要求是所有人都有社会保险号，然后将 Person 扩展为 subclass 以涵盖特定角色，例如Patient/Doctor 有额外的限制。从本质上讲，我们希望避免在 subclass 链上重复和维护相同的属性。
另一个要求是将所有 schema-related 约束（形状）推入形状图中并利用它，例如通过 RDF4j 以这样的方式航行，当向数据库输入新的实例数据（患者“Foo Bar”）时，如果 Person 形状中出现的约束（So.Sec.Nr.）和其他患者约束不存在，事务将自动失败使满意。对于内务管理，只为实例数据提供一个图，并在另一个图中定义其结构的所有内容会更容易卖给面向 RDBMS 的人。
关于 owl:imports，我假设您指的是对数据图的基本添加：
<http://lorem.ipsum/> rdf:type owl:Ontology;
owl:imports <http://somewhere.else/datagraph> .
但这在某种意义上不是也不是很 self-contained 因为所有三元组（包括形状）都暴露给数据图而不仅仅是实例数据，并且在某种意义上我们正在声明一个ontology（带来额外的语义包袱）仅用于相当于简单导入语句的内容？我错过了什么吗？
我正在努力理解（对我来说）关于形状约束继承的一个非常不直观的特征。我的问题是，当我尝试通过 rdfs:subClassOf 继承形状约束时，仅当在数据图中指定继承时，这才有效 ，而不是在形状图中指定时.
我已经在旧的和 Zazuko SHACL 游乐场中验证了以下 PoC，并收到了相同的答案。
形状图：
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix : <http://lorem.ipsum/#> .
:Agent a rdfs:Class,
sh:Nodeshape;
sh:property [
sh:minCount 1;
sh:path :Name;
].
:Adult rdfs:subClassOf :Agent.
数据图：
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix : <http://lorem.ipsum/#> .
:Father a :Adult.
:UnknownPerson a :Agent.
这个版本只要求:UnknownPerson至少有一个:Name 属性，但是当我将:Adult rdfs:subClassOf :Agent移动到数据图时，它立即识别出:Father和:UnknownPerson应该有。
我不明白为什么我不能在形状图本身中定义这种继承？
如果在更基本的 RDF 级别上，:Adult class 被定义为 :Agent class 的 subclass（子集），因此它也应该是 sh:NodeShape，当它被定义为模式的一部分而不是要验证的数据的一部分时，为什么不对它应用 属性 约束？
这是一个非常有效的问题，决定可能是任何一种方式。定义 SHACL 的工作组最终采用了当前设计——要求目标机制的数据图中有 rdfs:subClassOf 个三元组，在 sh:class 等地方——因为它被认为更一致并且 self-contained.基本概念是“SHACL 实例”，它确定一个节点是否算作 class 的实例。鉴于 rdf:type 三元组当然会在数据图中，我们认为最好也假设 subClassOf 三元组在同一个图中。
除其他外，这意味着算法不需要在图之间切换（例如在 SPARQL 中它将是路径表达式 rdf:type/rdfs:subClassOf*），并且可以将形状图编译成一些静态数据结构，确保在验证期间不需要再次查询原始 RDF 形状图。我忘记了当前设计的其他原因。和往常一样，W3C Data Shapes WG 的会议纪要存档可能有更多详细信息。
在实践中，通常通过将形状图包含到数据图中来解决这个问题，例如使用 owl:imports。这样，rdfs:subClassOf 三元组只需要在形状图中断言，但在数据图中也可见。
由于评论区的名额很少，我决定在这里更详细地阐述我的用例。问题的要点是，与我一起工作的许多 IT 架构师都具有 UML 背景，因此假设 class RDF 世界中的继承将以类似的方式工作 和 模式和符合所述模式的实例数据之间存在严格的区别。我一直试图做的是找到一个关于如何在 RDF 中表示他们的范例的 PoC（我们努力增加链接数据的使用并以易于理解的方式介绍其范例）并且作为标准 SHACL 是其中之一明显的主要候选人。
PoC 的要求之一是能够按照 UML 表示句法约束：将一些 all-encompassing 约束构建到基础级别 class（形状）中，然后利用这些约束属于根域 class（形状）的所有 sub-classes（形状）。例如。我们可能想要指定一个 Person 形状，其普遍要求是所有人都有社会保险号，然后将 Person 扩展为 subclass 以涵盖特定角色，例如Patient/Doctor 有额外的限制。从本质上讲，我们希望避免在 subclass 链上重复和维护相同的属性。
另一个要求是将所有 schema-related 约束（形状）推入形状图中并利用它，例如通过 RDF4j 以这样的方式航行，当向数据库输入新的实例数据（患者“Foo Bar”）时，如果 Person 形状中出现的约束（So.Sec.Nr.）和其他患者约束不存在，事务将自动失败使满意。对于内务管理，只为实例数据提供一个图，并在另一个图中定义其结构的所有内容会更容易卖给面向 RDBMS 的人。
关于 owl:imports，我假设您指的是对数据图的基本添加：
<http://lorem.ipsum/> rdf:type owl:Ontology;
owl:imports <http://somewhere.else/datagraph> .
但这在某种意义上不是也不是很 self-contained 因为所有三元组（包括形状）都暴露给数据图而不仅仅是实例数据，并且在某种意义上我们正在声明一个ontology（带来额外的语义包袱）仅用于相当于简单导入语句的内容？我错过了什么吗？