如果在OWL Property Restrictions 和SHACL 之间进行选择，是否还有理由再选择 OWL 方法？
特别是关于基数约束，我想知道是否认为 SHACL 会取代 OWL。根据我的随意检查，语法看起来很相似。
我可能错过了 OWL 基数约束的目的。作为本体的一部分，它们应该促进推理（与验证不同的关注点）。但是基数约束如何促进推理？
【问题讨论】：
A EquivalentTo p min 2 的东西和一个带有x p y1 和x p y2 和`y1 differentFrom y2`的个人x，你可以推断出x 属于类A
标签： constraints rdf owl semantic-web shacl
OWL 和 SHACL 的区别如下表所示。
| OWL | SHACL |
|---|---|
| Based on open world assumption | Based on closed world assumption |
| Designed for inferencing | Designed for validation |
| Computationally cheap (typical problems are decidable) | ? |
| A lot of inferences almost "out of the box" | One have to define a lot of constraints manually |
| Is useful as documentation for RDF |
关于 OWL 中的基数约束，这些约束允许在某些情况下在某些方面关闭世界，以获得额外的推理。
基数约束的逻辑在 OWL 和 SHACL 中是相反的。非正式地：
在 SHACL 中，
ex:PersonShape
a sh:NodeShape ;
sh:targetClass ex:Person ;
sh:path ex:parent ;
sh:minCount 1 .`
意味着如果某人是一个人，那么他/她必须至少有一个父母。
在 OWL 中，
ex:Person owl:equivalentClass [ rdf:type owl:Restriction ;
owl:onProperty ex:parent ;
owl:minCardinality "1" ] . `
意味着如果某人至少有一个父母，那么他/她就是一个人。
来自TopBraid marketing materials：
SHACL 与 RDF Schema 和 OWL 有何不同？ RDFS 和 OWL 是为一个“开放世界”而设计的，在这个世界中，数据可以从语义网上的许多地方组装。多年来，这个设计目标引起了很多挫折，因为它甚至无法检查最明显的完整性约束，例如属性是否具有一定数量的值。相比之下，SHACL 假设一个“封闭世界”，符合典型商业用户的期望。此外，OWL 已针对特定类型的分类问题进行了优化，但它不能用于执行数据验证所需的常规操作，例如数学计算或文本操作。 SHACL 更具表现力。此外，它与 SPARQL 无缝集成以表达几乎任意条件。顺便说一句，使用 SHACL 语句增量扩展 RDFS 或 OWL 模型是非常好的，同时支持这两个世界。
【讨论】：
owl:equivalentClass 意味着一个人必须至少有一个父母，并且至少有一个父母的任何事物都是一个人。如果您使用rdfs:subClassOf，语义会更好地与 SHACL 保持一致。但是效果仍然不同（如果缺少父母，SHACL 会拒绝数据，而 OWL 会通知您somewhere 必须有父母，并且仅当它可以证明一个人没有父母时才拒绝数据)。
根据我的经验，大多数 OWL 用户并没有真正理解或不关心 OWL 的实际语义（开放世界假设等）。在许多情况下，由于没有其他选择，因此使用了 OWL 基数限制。然而，正如在其他地方指出的那样，owl:maxCardinality 1 的语义与大多数人的期望相反：这意味着如果属性有两个值，那么这些值被假定为相同 (owl:sameAs)。在 SHACL 中，sh:maxCount 1 表示如果属性有两个值，则需要删除其中一个。
继续使用 OWL 支持 SHACL 的主要原因是 OWL 具有更长的历史（即更多工具、可重用的本体和示例），并且如果您想使用 OWL (DL) 推理。但如果您需要传统的封闭世界语义，请使用 SHACL。请注意，SHACL 和 OWL 可以混合使用，例如在一个文件中定义类和属性，然后在另一个文件中定义 OWL 限制，在另一个文件中定义 SHACL 约束。
【讨论】：
根据我的经验，OWL 推理很少使用，复杂的 OWL 构造（包括 Restriction 和 unionOf）不是很有用。
即使是rdfs:domain/range 也会导致重用问题，因为它们是单态的：将它们与多个值一起使用，你就是在自找麻烦。
因此，我们 Ontotext 最近一直在使用基于示例的模型、非承诺的 schema:domain/rangeIncludes 和形状来表达如何一起使用类和道具。
【讨论】：
rdfs:domain 和rdfs:range.. 我自然倾向于将它们用作期望值类型，但这不是它的意图。您是说例如单个 rdf:Property 的多个 rdfs:range 值会给您带来麻烦吗？这对schema:domainIncludes 和schema:rangeIncludes 更好，因为它允许值是这些类型中的任何一种，而不是自动获取所有类型。那是对的吗？你能解释一下你所说的不承诺是什么意思吗？
我认为 OWL 完全基于开放世界假设这一事实使其非常独特。在某些用例中，您可以将来自许多不同来源的需要此独特功能的许多数据集组合在一起。对于任何给定的事实，可能总会有来自不同来源的不同意见。在您的“数据结构”（或企业知识图）中对“真相的多个版本”的基本支持至关重要，甚至更强大：它是企业范围用例的唯一最重要的推动力。对于 EKG，我们需要 OWL 作为核心。形成所有数据的“无偏见”表示，不强迫任何特定的封闭世界观，推断所有正确的事实。在洋葱圈中有很多翻译语言，例如 SHACL（严格的特定于上下文的对象的封闭世界形状）、SPARQL（图表 2 表格）、R2RML（表格 2 图表）等等。
【讨论】：