来自schema.org的JSON序列化

Question

在json-ld操场上给出了下面的示例。

人的例子(扩大)：

json-ld：

{
  "@context": "http://schema.org/",
  "@type": "Person",
  "name": "Jane Doe",
  "jobTitle": "Professor",
  "telephone": "(425) 123-4567",
  "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": "(425) 123-4567"
      }
    ],
    "http://schema.org/url": [
      {
        "@id": "http://www.janedoe.com"
      }
    ]
  }
]

我问自己，序列化程序从哪里获取信息来将属性映射到正确的后续模式(name)。为了实现这一点，它必须能够保持json模式的人。但是如果我去https://schema.org/Person，我会得到一个HTML，而不是一个JSON文件。

那么，序列化知识从何而来呢？

Answer 1

杰伊是正确的，知识来自@context。这可以通过以下几种方式来指定：

• 内联，使用@context的对象值(或包含对象的数组)，
• 通过直接从指定的URL (例如，https://json-ld.org/contexts/person.jsonld)检索上下文，
• 通过让服务器对请求进行上下文协商，因为HTTP请求包括一个Accept报头，更倾向于JSON(参见将JSON解释为JSON-LD)，如下所示： .json HTTP/1.1主机: example.com Accept: application/ld+json，application/json，*/*;q=0.1
• 或者，正如schema.org当前部署的那样，返回一个链接头以及一个GET或HEAD请求，标识要加载的实际上下文的位置(参见备用文件位置)： HTTP/1.1 200 OK ..。类型: text/html链接：；rel=“备用”；type="application/ld+json“ 最后一种情况是由schema.org使用的，因为在某些静态站点生成器上使HTTP协商正常工作是一项挑战。如果您访问https://schema.org的HEAD请求，您将得到包含以下内容的头文件：

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

符合json处理器(例如在json-ld.org操场上)知道遵循这个链接来找到实际的上下文。

在Person示例中，根据上下文文件中的说明将"Person“和其他键转换为IRIs，如下所示：

{
  "@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，而不是文本字符串。