无法在 SHACL 形状图中定义限制继承，只能在数据图中定义限制继承？
我正在努力理解（对我来说）关于形状约束继承的一个非常不直观的功能。我的问题是，当我尝试通过 rdfs:subClassOf 继承形状约束时，只有在数据图中指定继承时才有效，而不是在形状图中指定继承时有效。
我已在旧 SHACL 和 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，为什么当它定义为时不将属性约束应用于它模式的一部分而不是要验证的数据的一部分？
I am struggling to understand (for me) a very unintuitive feature regarding the inheritance of shape constraints. My problem is that when i try to inherit shape constraints via rdfs:subClassOf, this works only when the inheritance is specified in the data graph, not when it is specified in the shapes graph.
I have validated the following PoC in both the old and Zazuko SHACL playgrounds and receive identical answers.
The shapes graph:
@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.
The Data graph:
@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.
This version only demands that :UnknownPerson should have at least one :Name property, but when I move the :Adult rdfs:subClassOf :Agent to the data graph, it immediately recognizes that both :Father and :UnknownPerson should have it.
I do not understand why I cannot define this inheritance in the shapes graph itself?
If on a more fundamental RDFs level :Adult class is defined as the subclass (subset) of the :Agent class and as such it should also be a sh:NodeShape, why aren't the property constraints applied to it when it is defined as part of the schema and not as part of the data to be validated?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是一个非常有效的问题，无论哪种方式都可以做出决定。定义 SHACL 的工作组最终采用了当前的设计 - 要求目标机制的数据图中以及 sh:class 等位置使用 rdfs:subClassOf 三元组 - 因为它被认为更加一致和独立。基本概念是“SHACL实例”，它确定节点是否算作类的实例。鉴于 rdf:type 三元组当然会出现在数据图中，我们认为最好也假设 subClassOf 三元组位于同一图中。
除此之外，这意味着算法不需要在图之间切换（例如，在 SPARQL 中，它将是路径表达式 rdf:type/rdfs:subClassOf*），并且形状图可以编译成某种静态数据结构，以确保在验证过程中不需要再次查询原始 RDF 形状图。目前的设计可能还有其他原因，我已经忘记了。与往常一样，W3C 数据形状工作组的会议纪要存档可能包含更多详细信息。
在实践中，这个问题通常通过将形状图包含到数据图中来解决，例如使用 owl:imports。这样，rdfs:subClassOf 三元组只需在形状图中进行断言，但在数据图中也可见。
This is a very valid question and the decision could have gone either way. The working group that defined SHACL ended up with the current design - requiring rdfs:subClassOf triples in the data graph for the target mechanism and in places like sh:class - because it was deemed to be more consistent and self-contained. The basic concept is "SHACL instance" which determines whether a node counts as an instance of a class. Given that the rdf:type triple will, of course, be in the data graph, we thought it best to also assume that the subClassOf triples be in the same graph.
Among others, this means that algorithms don't need to switch between graphs (e.g. in SPARQL it would be the path expression rdf:type/rdfs:subClassOf*), and that shapes graphs can be compiled into some static data structure that makes sure that the original RDF shapes graph doesn't need to be queried again during validation. There may have been other reasons for the current design that I have forgotten. As usual, the archive of the meeting minutes of the W3C Data Shapes WG may have more details.
In practice, the issue is often worked around by including the shapes graph into the data graph, e.g. using owl:imports. This way, the rdfs:subClassOf triples only need to be asserted in the shapes graph yet are also visible in the data graph.