1

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

thing
    artist
    album
    playlist

literal
    literal_coordinate
    literal_integer
    literal_json
    literal_string

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

我的理解是 rdfs:range （或不那么严格的“schema:rangeIncludes”）可用于对三元语句的对象位置中的预期值进行广义的理解。

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

问题

哪种方法可以战略性地以全局方式指定每个属性的预期 DataType？对于此用例，“范围”似乎过于开放，无法依赖，我不确定 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])"

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

4

1 回答 1

1

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\\/.+" .

现在您知道要在 HTMLpattern属性中添加什么了。

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

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 确实提供了对自定义验证器的支持），但我认为有只有少数。

于 2021-01-23T13:48:50.720 回答