如何解决指定属性数据类型 – 使用 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 确实提供了对自定义验证器的支持),但我认为有只是其中的一小部分。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。