JSON-LD 上下文中的不同值前缀答案

【问题标题】：Different value prefixes in JSON-LD contextJSON-LD 上下文中的不同值前缀
【发布时间】：2018-09-01 09:25:32
【问题描述】：

所以我有一个预定义的本体和一个现有的 JSON 服务（两次都读作“不能更改那里的现有内容”）返回类似于以下 JSON 的内容：

{
  "propA": "someResource",
  "propB": "otherResource"
}

我想通过添加（我无法更改现有属性，但可以添加新属性）上下文定义来将该输出转换为 JSON-LD。在第一步中，我添加了这样的默认上下文：

  "@context": {
    "@vocab": "https://example.org/",

    "propA": { "@type": "@vocab" },
    "propB": { "@type": "@vocab" }
  },
  "@id": "https://example.org/blub",

这会将两个资源映射到@vocab (playground) 给出的命名空间。

<https://example.org/blub> <https://example.org/propA> <https://example.org/someResource> .
<https://example.org/blub> <https://example.org/propB> <https://example.org/otherResource> .

但是，两个引用的资源都属于两个不同的命名空间。所以我需要一些上下文，映射到以下内容：

<https://example.org/blub> <https://example.org/propA> <https://foo.com/someResource> .
<https://example.org/blub> <https://example.org/propB> <https://bar.com/otherResource> .

我在某处找到了hack using @base，但这只是一种解决方法，如果您需要一个额外的命名空间而不是多个命名空间。

那么当我需要两个以上的属性时，如何为不同的属性定义单独的命名空间前缀？

【问题讨论】：

标签： namespaces json-ld

【解决方案1】：

这是一种方法：

{
  "@context": {
    "dcat": "http://www.w3.org/ns/dcat#",
    "org": "http://www.w3.org/ns/org#",
    "vcard": "http://www.w3.org/2006/vcard/ns#",
    "foaf": "https://project-open-data.cio.gov/v1.1/schema#",
    "dc": "http://purl.org/dc/terms/",
    "pod": "https://project-open-data.cio.gov/v1.1/schema#",
    "skos": "http://www.w3.org/2004/02/skos/core#",
  }
}

然后您将使用 CURIE 格式 (https://en.wikipedia.org/wiki/CURIE) 来指定 key:value 对，其中 key 是 vocab，value 是公理/语句中使用的 vocab term。

【讨论】：

这需要我将值从"someResource" 更改为"skos:someResource"，不是吗？正如我所提到的，我无法更改现有内容，而只是添加一些新属性。
好的，我应该仔细阅读。恕我直言@base 是行不通的——这是缩写你自己的命名空间的简写（就像在 CSS 中经常做的那样，根是默认的，引用是相对的）。我不知道如何处理您的问题的狭窄限制。你能定义一个你自己设计的新@graph吗？然后，我们也许可以将您现有 @graph 中的 term:value 链接到新的 @graph
如上面的操场链接所示@base 可以被滥用来添加一个更多的命名空间。我真正期望的是，可以在期限级别设置@base："propA": { "@base": "http://bar.com", "@type": "@id" }。这应该覆盖该术语的全局 @base 并允许使用任意前缀扩展值。
关于@graph的建议：根据我的（有限的）理解，这会改变JSON结构，所以我不能在这里使用它。其他遗留系统依赖于当前的结构和价值。我的目标是使用语义技术启用新系统，而不会失去与那些旧系统的兼容性。
希望我能提供帮助，但在您的限制范围内想不出解决方案。我看不出如何使用@base 获得 2 个以上的域，但话又说回来，我从未尝试过。好机会。

【解决方案2】：

经过一番折腾，我认为 JSON-LD 1.1 提供了一个答案：scoped contexts。

{
  "@context": {
    "@version": 1.1,
    "@vocab": "https://example.org/",

    "propA": { "@type": "@id", "@context": { "@base": "https://foo.com/"} },
    "propB": { "@type": "@id", "@context": { "@base": "https://bar.com/"} }
  },
   "@id": "https://example.org/blub",

  "propA": "someResource",
  "propB": "otherResource"
}

有两点需要注意：

添加"@version": 1.1 至关重要。这告诉合规处理器使用 JSON-LD 1.1 规则集。
然后我们可以将每个属性放在单独的上下文中并在此处更改@base。

这将根据 this (dev) playground example 生成以下 Turtle 表示：

<https://example.org/blub> <https://example.org/propA> <https://foo.com/someResource> .
<https://example.org/blub> <https://example.org/propB> <https://bar.com/otherResource> .

旁注：我们甚至可以通过将@type 设置为@vocab 并定义范围上下文的映射，以类似的方式定义可能值映射的枚举。请注意，这一次我们必须在作用域上下文中设置@vocab 而不是@base：

{
  "@context": {
    "@version": 1.1,
    "@vocab": "https://example.org/",

    "propA": { 
      "@type": "@vocab", 
      "@context": { 
        "@vocab": "http://foo.com/", 

        "abc": "http://bar.com/abc", 
        "xyz": "http://baz.com/xyz"
      } 
    }
  },
   "@id": "https://example.org/blub"
}

现在根据赋予propA 的值使用不同的命名空间（play with it）：

"abc" -> <https://example.org/blub> <https://example.org/propA> <http://bar.com/abc> .
"xyz" -> <https://example.org/blub> <https://example.org/propA> <http://baz.com/xyz> .
"mnl" -> <https://example.org/blub> <https://example.org/propA> <http://foo.com/mnl> .

【讨论】：