我正在尝试收集一组需求并以 JSON-LD 格式记录它们。 JSON-LD 文档将作为配置文件在短期内驱动自动化数据分析。从长远来看,我的老板希望利用此配置的底层 RDF 图以及我们也在 JSON-LD 中生成的其他文档。不确定他到底打算做什么,但他有一个很大的大脑,所以我只负责短期。
标题中的问题。我对 axel 感到困惑,试图弄清楚如何正确地将属性值扩展为有意义的 URI/URL。扩展属性名称似乎很容易,但我希望扩展这些属性的值。
我在 JSON-LD 沙箱中度过了两天,这就是我必须展示的我的努力:
{
"@context" : {
"number" : "locator:requirements/number/",
"var" : "locator:models/"
},
"@graph" : [
{
"@id" : "number:001",
"target" : {
"@type" : "float",
"@value" : 22.6
},
"variable" : {
"@id" : "var:StarTracker/AngleToSun"
},
"operator" : "minimum"
}
]
}
我想扩展到:
[
{
"@id": "locator:requirements/number/001",
"operator": [
{
"@value": "minimum"
}
],
"target": [
{
"@type": "float",
"@value": 22.6
}
],
"variable": [
{
"@id": "locator:models/StarTracker/AngleToSun"
}
]
}
]
按照这个答案的建议,我使用
@vocab
取得了一些小进步。然而,似乎 @vocab
表示默认 URI,它应用于所有内容,而不仅仅是我想要的位。随着我的新背景
"@context" : {
"@vocab" : "locator:requirements/number/",
"number" : "locator:requirements/number/",
"var" : "locator:models/"
}
我现在得到了这个扩展包,其中有很多我不想要的东西。
[
{
"@id": "locator:requirements/number/001",
"locator:requirements/number/operator": [ <------------ UNWANTED EXPANSION
{
"@value": "minimum"
}
],
"locator:requirements/number/target": [ <-------------- UNWANTED EXPANSION
{
"@type": "locator:requirements/number/float", <---- UNWANTED EXPANSION
"@value": 22.6
}
],
"locator:requirements/number/variable": [ <------------ UNWANTED EXPANSION
{
"@id": "locator:models/StarTracker/AngleToSun"
}
]
}
]
我现在意识到
@vocab
是一个“默认”扩展,所以不是我应该使用的。我该如何正确地做到这一点?
为了使 JSON-LD 能够与 RDF 互操作,您需要从属性到 URI 的映射。在您的原始示例中,属性
operator
、target
和 variable
(以及数据类型 float
)未映射到任何 URI,因此实际上被 JSON-LD 处理器忽略。
常见的解决方案是通过
@context
直接或在它指向的文件中定义所有词汇项。在你的情况下,那就是:
{
"@context": {
"number": "locator:requirements/number/",
"var": "locator:models/",
"operator": "locator:schema/operator",
"target": "locator:schema/target",
"variable": "locator:schema/variable",
"float": "locator:schema/float"
},
"@graph": [
{
"@id": "number:001",
"target": {
"@type": "float",
"@value": 22.6
},
"variable": {
"@id": "var:StarTracker/AngleToSun"
},
"operator": "minimum"
}
]
}
显式定义所有项目是有利的,因为它有助于检测何时使用未定义的项目,并且您可以为属性提供额外的上下文以进一步缩短语法,例如:
{
"@context": {
"number": "locator:requirements/number/",
"var": "locator:models/",
"variable": {
"@id": "locator:schema/variable",
"@type": "@id"
}
},
"@graph": [
{
"@id": "number:001",
"variable": "var:StarTracker/AngleToSun"
}
]
}
通过制作
variable
@id
的类型,就不需要每次都完整地写出来了。
另一种解决方案是为每个项目使用前缀:
{
"@context": {
"number": "locator:requirements/number/",
"var": "locator:models/",
"s": "locator:schema/"
},
"@graph": [
{
"@id": "number:001",
"s:target": {
"@type": "s:float",
"@value": 22.6
},
"s:variable": {
"@id": "var:StarTracker/AngleToSun"
},
"s:operator": "minimum"
}
]
}
这与之前的解释相同,但没有任何显式的项目定义,并且需要修改 JSON 部分。
最后,您也可以在这里轻松使用
@vocab
,同样的解释:
{
"@context": {
"number": "locator:requirements/number/",
"var": "locator:models/",
"@vocab": "locator:schema/"
},
"@graph": [
{
"@id": "number:001",
"target": {
"@type": "float",
"@value": 22.6
},
"variable": {
"@id": "var:StarTracker/AngleToSun"
},
"operator": "minimum"
}
]
}
如果您看到不想
@vocab
应用的位,无论如何您都需要将它们定义为 URI – @vocab
只是为您未映射的所有内容指定默认命名空间,但这意味着需要它首先映射。
使用哪种解决方案?最好是全部——对于最常见的属性,使用数据类型和可能的其他信息明确定义它们。对于其他更“奇特”的属性或来自其他词汇表的属性(您可能不需要仅通过 JSON 处理那么多),请使用前缀。如果您的命名空间无法以这种方式定义,请在
@base
中使用 @id
,在其他地方使用 @vocab
。