来自 schema.org 的 JSON LD 序列化 [英] JSON LD serialization from schema.org

问题描述

以下示例在 json-ld 游乐场 上给出.

The following example is given on the json-ld playground.

人物示例(扩展):

json-ld:

{
  "@context": "http://schema.org/",
  "@type": "Person",
  "name": "Jane Doe",
  "jobTitle": "Professor",
  "telephone": "[phone]",
  "url": "http://www.janedoe.com"
}

序列化扩展后:

[
  {
    "@type": [
      "http://schema.org/Person"
    ],
    "http://schema.org/jobTitle": [
      {
        "@value": "Professor"
      }
    ],
    "http://schema.org/name": [
      {
        "@value": "Jane Doe"
      }
    ],
    "http://schema.org/telephone": [
      {
        "@value": "[phone]"
      }
    ],
    "http://schema.org/url": [
      {
        "@id": "http://www.janedoe.com"
      }
    ]
  }
]

我问自己，序列化程序从哪里获取信息以将属性映射到正确的后续架构(name).要实现这一点，它必须能够抓住 person json ld 模式.但是如果我去 https://schema.org/Person 我得到一个 HTML 而不是 JSON-LD文件.

I ask myself where does the serializer gets the information to map the properties to the right subsequent schema (name). To achieve that, it must be able to get hold on to the person json ld schema. But if I go to https://schema.org/Person I get an HTML back and not a JSON-LD file.

那么序列化知识从何而来?

So where does the serialization knowledge come from?

推荐答案

Jay 是正确的，知识来自 @context.这可以通过几种方式指定:

Jay is correct that the knowledge comes from the @context. This can be specified in a couple of ways:

• 内联，使用 @context 的对象值(或包含对象的数组)，

• Inline, using an object value for @context (or an array, which includes an object),

通过直接从指定的 URL 检索上下文(例如，https://json-ld.org/contexts/person.jsonld),

By directly retrieving a context from the URL specified (e.g., https://json-ld.org/contexts/person.jsonld),

通过让服务器对请求进行上下文协商，因为 HTTP 请求包含一个首选 JSON-LD 的 Accept 标头(请参阅 将 JSON 解释为 JSON-LD) 如下:

By having the server do context-negotiation on the request, as an HTTP request includes an Accept header preferring JSON-LD (see Interpreting JSON as JSON-LD) such as the following:

GET /ordinary-json-document.json HTTP/1.1
Host: example.com
Accept: application/ld+json,application/json,*/*;q=0.1

或者，正如目前 schema.org 所部署的那样，通过返回链接标头以及标识要加载的实际上下文位置的 GET 或 HEAD 请求(参见 备用文档位置):

HTTP/1.1 200 OK
...
Content-Type: text/html
Link: <alternate.jsonld>; rel="alternate"; type="application/ld+json"

最后一种情况由 schema.org 使用，因为在某些静态站点生成器上使 HTTP 内容协商正常工作存在挑战.如果您在 https://schema.org 处收到 HEAD 请求，您将返回包括以下内容的标头:

This last case is used by schema.org because of the challenges of making HTTP Content-Negotiation work properly on certain static site generators. If you to a HEAD request at https://schema.org, you'll get back headers including the following:

HTTP/2 200 
link: </docs/jsonldcontext.jsonld>; rel="alternate"; type="application/ld+json"

符合 JSON-LD 的处理器(例如在 json-ld.org 游乐场上)知道通过此链接查找实际上下文.

A conforming JSON-LD processor (such as on the json-ld.org playground) knows to follow this link to find the actual context.

在 Person 示例的情况下，Person"其他键根据上下文文件中的指令转换为 IRI，例如:

In the case of the Person example, "Person" and the other keys are turned into IRIs based on instructions in that context file such as the following:

{
  "@context": {
    ...
    "schema": "http://schema.org/",
    "Person": {"@id": "schema:Person"},
    "name": { "@id": "schema:name"},
    "jobTitle": { "@id": "schema:jobTitle"},
    "telephone": { "@id": "schema:telephone"},
    "url": { "@id": "schema:url", "@type": "@id"},
    ...
  }
}

请注意，在url"的情况下，它也知道该属性的值应该被视为 IRI，而不是文本字符串.

Note that in the case of "url", it also knows that the value of that property should be treated as an IRI, rather than a text string.

这篇关于来自 schema.org 的 JSON LD 序列化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！