我很难理解(对我来说(关于形状约束继承的一个非常直观的特性。我的问题是，当我试图通过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类被定义为：Agent类的子类(子集(，因此它也应该是sh:NodeShape，那么当它被定义为架构的一部分而不是要验证的数据的一部分时，为什么不应用属性约束呢？
这是一个非常有效的问题，决策可能会朝任何一种方向发展。定义SHACL的工作组最终采用了当前的设计，要求在目标机制的数据图中以及sh:class等位置使用rdfs:subClassOf三元组，因为它被认为更一致和自包含。基本概念是"；SHACL实例"；其确定节点是否算作类的实例。考虑到rdf:type三元组当然会在数据图中，我们认为最好也假设三元组的subClassOf在同一个图中。
除其他外，这意味着算法不需要在图之间切换(例如，在SPARQL中，它将是路径表达式rdf:type/rdfs:subClassOf*(，并且形状图可以编译成一些静态数据结构，以确保在验证期间不需要再次查询原始rdf形状图。目前的设计可能还有其他原因，我已经忘记了。和往常一样，W3C数据形状工作组的会议记录档案可能有更多细节。
在实践中，通常通过将形状图包含到数据图中来解决此问题，例如使用owl:imports。这样，rdfs:subClassOf三元组只需要在形状图中断言，但在数据图中也可见。