指定属性数据类型 – 使用 SHACL、rdfs:range 还是自定义属性？

问题描述

我有一个像下面这样的本体，带有类和文字：

thing
    artist
    album
    playlist

literal
    literal_coordinate
    literal_integer
    literal_json
    literal_string

在引入新属性时，我想确保属性使用特定的“数据类型”（类似于：https://www.wikidata.org/wiki/Help:Data_type），以便用户界面可以显示正确的条目类型或显示格式：AutoComplete for对象，literal_integer 的数字，literal_coordinate 的 Map 等等。

我的理解是可以使用 rdfs:range（或不太严格的“schema:rangeIncludes”）来大致了解三元组语句的对象位置中的预期值。

此外，还有 sh:datatype、sh:nodeKind 和 sh:class 类型的 SHACL 形状约束可以约束预期值 (https://www.w3.org/TR/shacl/#core-components-value-type)。

问题

哪种方法对于以全局方式指定每个属性的预期数据类型具有战略意义？“范围”似乎过于开放世界，无法依赖于此用例，我不确定SHACL 旨在用于此类“全局信息”，还是主要处理图形子集的验证？与更复杂的对象/文字层次结构相比，Wikibase/Wikidata 似乎使用“平面数据类型设置”：

```json
datatypes
    Item (object relation)
    Media
    Mathematical expression
    etc.
```

理想情况下，解决方案还应考虑围绕数据类型的特定元数据的概念，例如“外部标识符”（有关详细信息，请参阅 Wikidata 链接）。此数据类型告诉系统使用来自属性的附加信息来格式化值：

    Data type
    {libraryOfCongressId} {dataType} {externalID} 

    Formatting options
    {libraryOfCongressId} {formatterURL} "https://id.loc.gov/authorities/$1"

    Property constraints
    {libraryOfCongressId} {formatConstraint} "(|((n|nb|nr|no|ns|sh|gf)([4-9])"

那么，开始一个具有类似用例的新本体，这是识别和格式化外部标识符的好蓝图，还是有更合适的解决方案？

解决方法

RDF 本身不会对任何图中的三元组施加任何有效性约束。这得益于 RDFS 本质上是可加的这一事实：

ex:prop rdfs:range xsd:integer .

ex:resource ex:prop "abc" .

当配备推理器（针对特定本体）时，这意味着 "abc" a xsd:integer。推理器可用于检测矛盾；例如，如果它知道 xsd:integer 实例的完整集合，它可能会检测到 "abc" 不是其中之一，那么图形就会矛盾。但是，如果只是想从图中推断出额外的陈述，则不需要进行一致性检查（尽管逻辑学家会争辩说，可以从矛盾的陈述中推断出任何东西）。

您对问题的描述似乎更侧重于推理而不是验证，但我认为 rdfs:range 适合这两种情况。我现在也将坚持使用 RDFS，因为这是最容易理解的。另请注意，schema:rangeIncludes 实际上并没有为任何类型的推理提供任何有用的信息（但它可能对数据的生产者有用）。

ex:authorityURL a rdfs:Datatype ;
  rdfs:subClassOf xsd:anyURI .

ex:formatterURL rdfs:range ex:authorityURL .

我们已经说过，任何与 ex:formatterURL 链接的对象都应该被视为 ex:authorityURL 并且是一个有效的 URI。由于 ex:authorityURL 现在是图表中的一个节点，因此您可以将任何其他元数据链接到您使用的所有工具。

ex:authorityURL schema:valuePattern "https:\\/\\/id\\.loc\\.gov\\/authorities\\/.+" .

现在您知道要在 HTML pattern 属性中放入什么了。 ?

在生成数据时，您不需要显式地将数据类型添加到文字中（因为它可以被推断），但它可能对擅长数据类型检查但不擅长推理的工具有用：

ex:library1 ex:formatterURL "https://id.loc.gov/authorities/1"^^ex:authorityURL .
ex:library2 ex:formatterURL "https://id.loc.gov/authorities/2" .

在检查数据的格式良好时，您还可以使用多种工具：一种用于具体化数据类型（即将 "https://id.loc.gov/authorities/2" 转换为 "https://id.loc.gov/authorities/2"^^ex:authorityURL），另一种用于确保所有文字根据他们的数据类型。

乍一看，SHACL 似乎更侧重于验证节点的属性而不是文字本身：

ex:LibraryShape a sh:NodeShape ;
  sh:targetClass ex:Library ;
  sh:property [
    sh:path ex:formatterURL ;
    sh:datatype ex:authorityURL ;
    sh:pattern "^https:\\/\\/id\\.loc\\.gov\\/authorities\\/."
  ] .

在我看来，生成以下形状来验证所有文字似乎是合理的，但我不确定这是否符合 SHACL 规范：

ex:authorityURL a sh:NodeShape ;
  sh:pattern "^https:\\/\\/id\\.loc\\.gov\\/authorities\\/." .

由于 ex:authorityURL 是一个类，它的实例应该根据形状来验证，所以这取决于它是否能够识别文字是其数据类型的实例并将模式应用于其值。

OWL 也可以用来指定限制：

ex:authorityURL a rdfs:Datatype ;
  owl:onDatatype xsd:anyURI ;
  owl:withRestrictions ( [ xsd:pattern "https:\\/\\/id\\.loc\\.gov\\/authorities\\/.+" ] ) .

这使得类包含使用适当的 XML 架构方面限制的所有文字。您也可以在纯 XML 中定义限制，但我不知道有多少工具支持。

到目前为止，有 3 个属性可用于描述数据类型。这取决于工具中哪个是最好的，但是没有什么可以阻止您使用所有这些工具。模式本身也略有不同（schema:valuePattern 指的是使用 JavaScript 规范的 HTML，而 sh:pattern 指的是使用 XPath 规范的 SPARQL，它构建在 xsd:pattern 之上，但具有类似添加了 ^ 和 $）。

我只展示了一种特定数据类型的示例，但该过程可以普遍应用。还有像 JSON 这样的复杂类型（不幸的是，我无法找到一个标准化的数据类型 URI），在那里你可能没有太多运气让它自我描述（虽然 SHACL 确实提供了对自定义验证器的支持），但我认为有只是其中的一小部分。

ontology rdf rdfs shacl wikidata