sparql - RDFS 蕴含机制不一致

Question

SPARQL 1.1 Entailment Regimes 的文档断言有可能产生不一致的图表，而且不一致的单一来源:rdf:XMLLiteral :

ex:a ex:b "<"^^rdf:XMLLiteral .
ex:b rdfs:range rdf:XMLLiteral .

推理是 <不是有效的 XML 片段，因此 "<"^^rdf:XMLLiteral必须被解释为 rdfs:Literal 中不存在的内容(显然)。这看起来有点随意和复杂，所以我有以下问题:

• 为什么不能"<"^^rdf:XMLLiteral可以简单地解释为"<" ？它不是 XML 文字是有道理的，但为什么它根本不能是文字呢？
• 为什么只有 rdf:XMLLiteral而不是例如 xsd:boolean或者其他数据类型？如果我们开始验证常见数据类型，就会发现很多不一致之处。
• 从 RDF 1.1 开始，我理解 rdf:XMLLiteral是不规范的。这是否意味着 RDFS 的新解释始终是一致的？
• 这条规则是否在实践中实现过？是否有一些 SPARQL 端点可能(仍然)拒绝 RDFS 不一致的图？

Answer 1

SPARQL 1.1 蕴含制度于 2013 年 3 月标准化，基于 RDF Semantics来自 2004 年标准(我将其称为 RDF 1.0)。在 RDF 1.0 中，RDFS 蕴涵并不强制将数据类型 URI 解释为数据类型，但它为 rdf:XMLLiteral 分配了特殊的语义。以及具有此数据类型 URI 的文字。其他文字不受其数据类型 URI 以任何方式约束，因此 xsd:boolean例如，不影响 RDFS 蕴含的一致性。事实上，RDF entailment imposes the special treatment of rdf:XMLLiteral ，它延续到 RDFS 蕴涵。

为了找到由于数据类型导致的其他不一致，您必须考虑另一种蕴涵机制，例如 D-蕴涵或 OWL。在 RDF 1.0 中，D-entailment被定义为 RDFS 的扩展，因此 RDFS 中不存在“验证通用数据类型”。 这应该回答你的第二个问题。

此外，"<"^^rdf:XMLLiteral是一个错误类型的 XML 文字，因此不得将其解释为 XML 值，并且由于 RDF 蕴含的约束，其解释不得为 rdf:XMLLiteral 类型。 ，更正式地说，对 (IL( "<"^^rdf:XMLLiteral ),IS( rdf:XMLLiteral ))，由文字 "<"^^rdf:XMLLiteral 的解释组成以及 URI rdf:XMLLiteral 的解释，不得位于属性 rdf:type 的扩展 IEXT(IS( rdf:type )) 中。此外，错误类型的 XML 文字不得等于任何文字值，其中必然包括纯文字值(UNICODE 字符串和语言标记字符串)，因此它不能表示字符串 "<" 。原因是我们不希望错误类型的文字与某些格式正确的文字表示相同的值。 这应该回答您的第一个问题。

2014年，RDF 1.1 was standardised with an updated semantics 。 D-entailment不再是 RDFS entailment 的扩展。反之亦然:RDFS 蕴涵是相对于 recognized datatype IRIs 的集合 D 来定义的。 。这意味着 RDFS 蕴含不再是单个蕴含机制，而是由 D 参数化的一系列蕴含机制。在最简单的实例中，RDFS 蕴含必须仅识别 xsd:string。和rdf:langString ，这意味着仍然可能存在不一致，因为并非所有 UNICODE 字符串都是有效的 XSD 字符串。此外，RDF 1.1 还改变了对错误类型文字的解释。在 RDF 1.1 语义中，错误类型的文字不表示任何内容。这意味着你甚至不能谈论它们。一旦 RDF 图中存在类型错误的文字，该图就会不一致。因此:

<s>  <p>  "\u0000"^^xsd:string .

在 RDFS 1.1 蕴含机制中不一致。 这应该回答你的第三个问题。

关于你最后一个问题，我不知道。然而，我确实相信，无论是 2004 年版本还是 2014 年版本，没有任何现有工具能够正确且完整地实现 RDFS 蕴涵。