与 owl:import 相比，应该如何解释 sh:shapesGraph？

Question

我正在努力理解应该如何使用 sh:shapesGraph。 到目前为止，我已经使用了一个 SHACL 验证器，它确实遍历 owl:import 并将内容带到数据图中，以便我可以从 rdfs:subClassOf 等中受益。

但是，根据 SHACL 规范，数据图中的 sh:shapesGraph 声明“是一个 IRI，表示应该包含在用于验证数据图的形状图中的图。” 该规范明确指出在数据图中声明了 sh:shapesGraph 三元组： “数据图可以包含三元组，用于通过谓词 sh:shapesGraph 向 SHACL 处理器建议一个或多个图。”

因此，例如，当使用https://www.itb.ec.europa.eu/shacl/shacl/upload进行验证时，我的理解是除了包含的数据图外，我不需要提供任何东西

[] sh:shapesGraph <http://foo.bar/#> .

这应该会自动使用http://foo.bar/#形状填充形状图。

从例如 AllegroGraph 文档判断，这正是应该发生的事情： “如果未指定 shape-graph-iri/s，SHACL 处理器将首先通过在数据图中使用谓词 sh:shapesGraph 查找三元组来创建 shapesGraph。如果没有这样的三元组，那么 shapesGraph 将被假定为与 dataGraph 相同。”

然而，我尝试过的所有开放验证器（EU ITB 验证器或 Zazuko 游乐场）都没有以任何方式对 sh:shapesGraph 做出反应（无论我是否将其声明为空白节点），而 owl:import from the same URL 完美地工作.

这种行为完全标准化了吗？ 对于这样的基本功能，我假设所有验证器的行为都是相似的。

有人可以阐明并用世俗的术语解释我在这里缺少的东西吗？

Answer 1

sh:shapesGraph 的想法是让数据发布者能够提供有关应将哪些形状应用于数据的提示。 工具被邀请但不需要遵循此提示。 某些 API 支持此属性，但其他操作显式文件上传的工具可能不会寻找它。

所以我相信你的解释是正确的，但考虑到 sh:shapesGraph 属性没有引擎强制性的严格形式语义，它的覆盖范围是不完整的。 注意规范中的“应该”和“可以”。

FWIW 当数据图的预期形状很清楚时，我们在实践中所做的是，我们将形状放入本体中，然后 owl:import 从数据图中导入本体。 这具有更多 API 和工具将遵循 owl:imports 的效果，因此您可以将形状放入数据图中。 然后，如果您将形状图留为“空”，大多数系统应该假定形状图 = 数据图并使用提供的形状。