JSON-LD 1.1

1.1 如何阅读本文档

本节为非规范性内容。

本文档是关于在 JSON 中序列化链接数据的详细规范。本文档主要面向以下受众：

• 希望在可使用 JSON 的各种编程语言中对链接数据进行编码的软件开发者
• 希望将现有 JSON 转换为 JSON-LD 的软件开发者
• 希望理解 JSON-LD 的设计决策和语言语法的软件开发者
• 希望实现 JSON-LD 处理器和 API 的软件开发者
• 希望在 JSON 语法中生成或消费链接数据、RDF graph 或 RDF Dataset 的软件开发者

配套文档 JSON-LD 1.1 Processing Algorithms and API 规范 [JSON-LD11-API] 描述了如何通过为常见 JSON-LD 操作提供标准库接口，在更高层次上使用 JSON-LD。

要理解本规范的基础内容，你首先必须熟悉 JSON，该内容在 [RFC8259] 中有详细说明。

本文档在讨论超链接时几乎完全使用术语 IRI（Internationalized Resource Indicator）。许多 Web 开发者更熟悉 URL（Uniform Resource Locator）一词。本文档也会偶尔使用 URI（Uniform Resource Indicator）术语。虽然这些术语在技术社区中常被互换使用，但它们之间具有重要区别，本规范尽力在各处使用恰当的术语。

本文档可以高亮显示自 JSON-LD 1.0 版本以来的更改。选择以 显示更改。

1.2 贡献

本节为非规范性内容。

参与本规范开发的方式有多种：

• 技术讨论通常在工作组邮件列表上进行：public-json-ld-wg@w3.org
• 工作组使用 #json-ld IRC 频道 在 irc.w3.org 上进行实时讨论。
• #json-ld IRC 频道 也可在 irc.freenode.net 上用于实时讨论。

1.3 排版约定

本节为非规范性内容。

示例以浅黄褐色框显示，左侧带黄褐色边框，并带有编号的“示例”标题（黄褐色）。
示例始终为信息性内容。示例内容使用等宽字体，并可做语法着色。

示例可包含选项卡式导航按钮
以展示将示例转换为其他表示形式的结果。

1.4 术语

本节为非规范性内容。

本文档使用下列在外部规范中定义的术语，并定义了特定于 JSON-LD 的术语。

1.5 设计目标与基本原理

本节为非规范性内容。

JSON-LD 满足下列设计目标：

Simplicity

在最基本的形式下使用 JSON-LD 不需要额外的处理器或软件库。该语言为开发者提供了非常低的学习曲线。不关心链接数据的开发者只需理解 JSON，并知道可以包含但忽略 @context 属性，即可使用 JSON-LD 的基本功能。

Compatibility

JSON-LD 文档始终是有效的 JSON 文档。这确保所有标准的 JSON 库能够与 JSON-LD 文档无缝工作。

Expressiveness

该语法序列化标注的有向图，从而确保几乎所有现实世界的数据模型都可以表达。

Terseness

JSON-LD 语法简洁且易于阅读，对开发者而言尽可能减少工作量。

Zero Edits, most of the time

JSON-LD 确保从现有基于 JSON 的系统平滑且简单地迁移。在许多情况下，对 JSON 文档无需修改，仅在 HTTP 响应中添加一行即可（见 § 6.1 Interpreting JSON as JSON-LD）。这使得已经部署大量基于 JSON 基础设施的组织能够以不干扰日常运营且对现有用户透明的方式使用 JSON-LD 的功能。然而，有时将 JSON 映射为图表示是一个复杂的任务。在这些情况下，与其为支持这些深奥用例而增加语言复杂性，我们选择不支持这些用例。虽然 Zero Edits 是一个设计目标，但在不引入巨量复杂性的前提下并非总是可行。JSON-LD 在可能时优先关注简洁性。

Usable as RDF

JSON-LD 可被开发者作为惯用的 JSON 使用，无需理解 RDF [RDF11-CONCEPTS]。JSON-LD 也可用作 RDF，因此打算将 JSON-LD 与 RDF 工具一起使用的人会发现它可以像其他 RDF 语法一样使用。JSON-LD 与 RDF 的完整关系详见第 § 10. Relationship to RDF 节。

1.6 数据模型概述

本节为非规范性内容。

一般而言，由 JSON-LD document 描述的数据模型是一个标注的、有向的 graph。该图包含由有向弧连接的 nodes。一个 node 要么是具有 properties 的 resource，要么是这些 properties 的数据值，包括 strings、numbers、typed values（如日期和时间）以及 IRIs。

在有向图中，nodes 是 resources，并且可能是 未命名的，即不由 IRI 标识；这类节点称为 blank nodes，可以使用 blank node identifier 来标识。这些标识符在使用树结构（例如 JSON）表示一个完全连接的图时可能是必需的，但除此之外并无固有意义。字面值（如 strings 和 numbers）也被视为 resources，JSON-LD 区分 node objects 与 value objects，以区分不同类型的 resource。

这一简单的数据模型非常灵活且强大，能够建模几乎任何类型的数据。欲深入了解该数据模型，请参见第 § 8. Data Model 节。

熟悉链接数据技术的开发者会认出该数据模型即为 RDF 数据模型。要更深入了解 JSON-LD 与 RDF 的关系，请参见第 § 10. Relationship to RDF 节。

在表面层面，JSON-LD document 仅仅是 JSON，详见 [RFC8259]。为描述核心数据结构之目的，本文限定为 arrays、maps（作为 JSON Object 的解析版本）、strings、numbers、booleans 和 null，称为 JSON-LD internal representation。这使得除 JSON 以外的表面语法在映射到等效的核心数据结构时也能使用相同算法进行处理。

1.7 语法标记与关键字

本节为非规范性内容。

JSON-LD 指定了若干语法标记和 keywords，它们是该语言的核心部分。关于这些 keywords 的规范性描述见 § 9.16 Keywords。

:

用于使用 compact IRIs 的 JSON 键和值之间的分隔符。

@base

用于设置用于解析那些否则相对于文档解释的相对 IRI 引用的 base IRI。该关键字在 § 4.1.3 Base IRI 中描述。

@container

用于设置某个 term 的默认容器类型。该关键字在下列章节中描述：

• § 4.3 Value Ordering,
• § 4.6.1 Data Indexing,
• § 4.6.2 Language Indexing,
• § 4.6.3 Node Identifier Indexing,
• § 4.6.4 Node Type Indexing
• § 4.9 Named Graphs,
• § 4.9.3 Named Graph Indexing,
• § 4.9.2 Named Graph Data Indexing

@context

用于定义在整个 JSON-LD 文档中使用的短名称（称为 terms），以便开发者以紧凑的方式表达特定标识符。@context 关键字在 § 3.1 The Context 中详细描述。

@direction

用于设置非 typed values（例如 strings 或 language-tagged strings）的 JSON-LD value 的 base direction。此关键字在 § 4.2.4 String Internationalization 中描述。

@graph

用于表达一个 graph。该关键字在 § 4.9 Named Graphs 中描述。

@id

用于唯一标识文档中被描述的 node objects，使用 IRIs 或 blank node identifiers。该关键字在 § 3.3 Node Identifiers 中描述。仅包含 @id 属性的 node object 称为 node reference，可表示对文档中其他位置 node object 的引用。

@import

在 context definition 中用于加载外部 context，并将其与包含该条目的 context definition 合并。这对于向 JSON-LD 1.0 的 contexts 添加 JSON-LD 1.1 功能很有用。

@included

在顶层 node object 中用于定义 included block，以便在另一个 node object 中包含次级的 node objects。

@index

用于指定某个容器用于索引信息，并指示处理应深入 JSON 数据结构。该关键字在 § 4.6.1 Data Indexing 中描述。

@json

作为 JSON literal 的 @type 值使用。该关键字在 § 4.2.2 JSON Literals 中描述。

@language

用于指定某个字符串值的语言或 JSON-LD 文档的默认语言。该关键字在 § 4.2.4 String Internationalization 中描述。

@list

用于表达有序的数据集合。该关键字在 § 4.3.1 Lists 中描述。

@nest

用于定义 node object 的一个 property，该 property 将该节点的若干 properties 组合在一起，但并不是图中的边。

@none

用作 index map、id map、language map、type map 或其他用于索引值的 map 的索引值，当被索引的节点不具备被索引的特征时使用。

@prefix

当值为 true 时，允许该 term 在紧凑化时用于构造 compact IRI；当值为 false 时，禁止该 term 用于构造 compact IRI。它还决定在扩展 compact IRIs 时是否考虑该 term。

@propagate

在 context definition 中用于改变该 context 的作用域。默认值为 true，表示 contexts 会跨 node objects 传播（type-scoped contexts 的默认值为 false）。将其设置为 false 会导致在进入新的 node object 时移除在该 context 中创建的 term 定义。

@protected

用于防止某个 context 的 term definitions 被其他 context 覆盖。该关键字在 § 4.1.11 Protected Term Definitions 中描述。

@reverse

用于表达反向属性。该关键字在 § 4.8 Reverse Properties 中描述。

@set

用于表达无序的数据集合并确保值始终以数组表示。该关键字在 § 4.3.2 Sets 中描述。

@type

用于设置 node 的类型或 typed value 的数据类型。该关键字在 § 3.5 Specifying the Type 和 § 4.2.1 Typed Values 中有进一步说明。

注

使用 @type 来为 node objects 和 value objects 同时定义类型可满足对数据进行类型化的基本需求，无论它是一个字面值还是更复杂的资源。专家可能会对 @type 关键字的双重用法有所顾虑，但应注意多年来 Web 开发者对此功能的使用并未导致其被滥用，因为 @type 用于表示类型化字面值的情况相对较少。

@value

用于指定与图中某个 property 相关联的数据。该关键字在 § 4.2.4 String Internationalization 和 § 4.2.1 Typed Values 中描述。

@version

在 context definition 中用于设置 processing mode。自 JSON-LD 1.0 以来在本规范中描述的新特性在 processing mode 显式设置为 json-ld-1.0 时不可用。

注

在 context definition 中 @version 采用的具体值为 1.1（而不是 "json-ld-1.1"），因为 JSON-LD 1.0 处理器可能接受字符串形式的 @version，但会拒绝数值形式。

注

将 @version 的值设为 1.1 旨在使 JSON-LD 1.0 处理器停止处理。尽管该值显然与 JSON-LD 1.1 相关，但它并不遵循 语义化版本控制 的要求。

@vocab

用于使用通用前缀扩展 properties 和 @type 中的值为 IRI。该关键字在 § 4.1.2 Default Vocabulary 中描述。

JSON-LD 中的所有键、keywords 和数值均区分大小写。

3.1 上下文

本节为非规范性内容。

当两个人互相交流时，对话发生在一个共享的环境中，通常称为“对话的上下文”。这种共享的上下文允许双方使用快捷术语（例如共同朋友的名字）进行更快速的交流而不丢失精确性。JSON-LD 中的上下文以相同方式工作：它允许两个应用使用快捷术语更高效地互相通信，同时保持语义上的准确性。

简单来说，context 用于将 terms 映射到 IRIs。Terms 区分大小写，且大多数不是保留的 JSON-LD keywords 的有效字符串都可以用作 term。例外情况包括空字符串 "" 以及形式像关键字的字符串（即以 "@" 开头且随后全部由一个或多个 ALPHA 字符组成的字符串（参见 [RFC5234]）），这些不得用作术语。形式上像 IRI（例如包含 ":"）的字符串也不应被用作术语。

对于上节的示例文档，一个 context 大致如下所示：

{
  "@context": {
    "name": "http://schema.org/name",
    ↑ This means that 'name' is shorthand for 'http://schema.org/name'
    "image": {
      "@id": "http://schema.org/image",
      ↑ This means that 'image' is shorthand for 'http://schema.org/image'
      "@type": "@id"
      ↑ This means that a string value associated with 'image'
        should be interpreted as an identifier that is an IRI
    },
    "homepage": {
      "@id": "http://schema.org/url",
      ↑ This means that 'homepage' is shorthand for 'http://schema.org/url'
      "@type": "@id"
      ↑ This means that a string value associated with 'homepage'
        should be interpreted as an identifier that is an IRI 
    }
  }
}

如上所示，context 中的 term definition 的值可以是一个简单字符串（将 term 映射到一个 IRI），也可以是一个 map。

可以通过键为 @context 的 entry 引入一个 context，它可以出现在 node object 或 value object 中。

当以 term 为键的 entry 的值是一个 map 时，该 map 被称为 expanded term definition。上例说明了若 image 与 homepage 的值为字符串，则应将其解释为 IRIs。扩展术语定义 还允许使用术语来构建 index maps，以及指定数组值应解释为 sets 还是 lists。扩展术语定义可使用 IRI 或 compact IRIs 作为键，这主要用于将类型或语言信息与 IRI 或 compact IRI 关联。

Contexts 可以直接嵌入文档（称为 embedded context），也可以通过 URL 引用。假设上例中的上下文文档可在 https://json-ld.org/contexts/person.jsonld 获取，则可以通过添加一行引用来引用它，从而使 JSON-LD 文档能够更简洁地表达，如下所示：

被引用的上下文不仅规定了术语如何映射到 Schema.org 词汇中的 IRIs，还规定了与 homepage 与 image 属性关联的字符串值可以解释为 IRI（即 "@type": "@id"，详见 § 3.2 IRIs）。这些信息使开发者能够重用彼此的数据而无需在站点级别达成数据互操作的约定。外部的 JSON-LD 上下文文档可能包含位于 @context 键之外的额外信息，例如对文档中声明术语的文档说明。当文档作为外部 JSON-LD context document 使用时，@context 值之外的信息将被忽略。

远程上下文也可以使用相对 URL 引用，并相对于包含引用的文档的位置进行解析。例如，如果某文档位于 http://example.org/document.jsonld 并包含对 context.jsonld 的相对引用，则所引用的上下文文档位于 http://example.org/context.jsonld。

{
  "@context": "context.jsonld",
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "image": "http://manu.sporny.org/images/manu.png"
}

JSON 文档可以通过在 HTTP Link Header 中引用 context（如 RFC8288 所述）而无需修改即可被解释为 JSON-LD，详见 § 6.1 Interpreting JSON as JSON-LD。也可以使用 JSON-LD 1.1 API 应用自定义上下文 [JSON-LD11-API]。

在 JSON-LD documents 中，contexts 也可以以内联方式指定。这样做的优点是即使在无法连接到 Web 的情况下也能处理文档。最终这是一个建模决策，不同用例可能需要不同处理。关于使用远程上下文的讨论，请参见 安全考虑，位于 § C. IANA Considerations。

本节仅覆盖 JSON-LD 上下文的最基本特性。上下文还可用于帮助解释更复杂的 JSON 数据结构，例如 indexed values、有序值 以及 嵌套属性。与 JSON-LD 上下文相关的更多高级特性载于 § 4. 高级概念。

3.2 IRIs

本节为非规范性内容。

IRIs（[RFC3987] 所述的 Internationalized Resource Identifiers）是链接数据的基础，因为大多数 nodes 与 properties 正是通过它们来标识。在 JSON-LD 中，IRIs 可以表示为 IRI reference。IRI 在 RFC3987 中定义为包含一个 scheme、path 以及可选的 query 与 fragment 段。相对 IRI 引用 是相对于另一个 IRI 的引用。在 JSON-LD 中，除下文描述的例外情况外，所有相对 IRI 引用都相对于 base IRI 进行解析。

当一个 字符串 是键为 @id 的 map entry 的值时，该字符串将被解释为 IRI：

{
  ...
  "homepage": { "@id": "http://example.com/" }
  ...
}

被解释为 IRIs 的值也可以表示为 相对 IRI 引用。例如，假设下列文档位于 http://example.com/about/，则相对 IRI 引用 ../ 会扩展为 http://example.com/（有关相对 IRI 引用可用位置的更多信息，请参阅 § 9. JSON-LD Grammar）。

{
  ...
  "homepage": { "@id": "../" }
  ...
}

IRIs 也可以直接出现在键的位置，例如：

{
  ...
  "http://schema.org/name": "Manu Sporny",
  ...
}

在上例中，键 http://schema.org/name 被解释为一个 IRI。

若键与 active context 中定义的 term 匹配，则会进行术语到 IRI 的扩展：

那些不能扩展为 IRI 的 JSON 键（例如上例中的 status）并非链接数据，因此在处理时会被忽略。

如果在 @context 中为某个 term 或属性的 IRI 指定了类型 coercion 规则，则会生成一个 IRI：

在上例中，由于值 http://manu.sporny.org/ 以 JSON 字符串形式给出，类型强制规则会在处理数据时将该字符串转换为 IRI。有关此特性的更多细节，请参见 § 4.2.3 Type Coercion。

综上，IRIs 在 JSON-LD 中可以通过多种方式表达：

1. 映射条目，其键映射到术语（位于活动上下文中）时，会展开为一个IRI（仅适用于上下文定义之外）。
2. 对于使用 @id 或 @type 指定的字符串值，会生成一个IRI。
3. 对于任何键的字符串值，如果存在包含一个且其值被设置为 @id 或 @vocab 的 强制转换 规则，则会为该字符串值生成一个IRI。

本节仅介绍了 JSON-LD 中与 IRI 相关的最基本特性。与 IRI 相关的更多高级特性请参见 § 4. 高级概念。

3.3 节点标识符

本节为非规范性内容。

为了能够在 RDF graph 中从外部引用 nodes，重要的是这些 nodes 必须有标识符。IRIs 是链接数据的一个基本概念；若要真正实现节点之间的链接，反解该标识符应当能返回该节点的表示，这样应用就可以检索有关该节点的更多信息。

在 JSON-LD 中，节点由 @id keyword 标识：

上例包含了一个由 IRI http://me.markus-lanthaler.com/ 标识的 node object。

本节仅涵盖与 JSON-LD 中节点标识符相关的最基本特性。与节点标识符相关的更多高级特性见 § 4. 高级概念。

3.5 指定类型

本节为非规范性内容。

在链接数据中，常常需要为图节点指定类型；在许多情况下，可以根据给定 node object 中使用的属性或该节点作为值的属性来推断类型。例如，在 schema.org 词汇中，属性 givenName 与 Person 相关联。因此，如果某个 node object 包含属性 givenName，则可以推断其类型为 Person；使用 @type 明确指定有助于澄清这种关联。

可以使用 @type keyword 来为某个节点指定类型。在链接数据中，类型以唯一的 IRI 标识。

可以通过使用 数组 为节点指定多个类型：

@type 键的值也可以是 active context 中定义的一个术语：

除了为节点设置类型之外，@type 还可以用于为一个值设置类型，从而创建 typed value。此用法类似于为 node object 定义类型，但 value objects 被限制为仅具有单个类型。关于此用途的更详细讨论见 § 4.2.1 Typed Values。

还可以通过在扩展术语定义中隐式定义 @type 来定义 typed values。此内容在 § 4.2.3 Type Coercion 中有更完整的覆盖。

4.1 高级上下文用法

本节为非规范性内容。

第 § 3.1 The Context 节介绍了 JSON-LD 工作的基本要素。本节在 上下文 的基本原理上进行扩展，并示范如何使用 JSON-LD 实现更高级的用例。

一般来说，只要定义了一个 map 就可以使用上下文。唯一不能表达上下文的情况是将其作为另一个上下文定义的直接子项（但可作为 扩展术语定义 的一部分）。例如，JSON-LD 文档 可以采用由一个或多个 node objects 组成的 数组 形式，并在每个顶级 node object 中使用上下文定义：

外层数组是 展开文档形式 和 展平文档形式 中文档的常见结构，当描述一个不连通的图（节点可能彼此不引用）时是必要的。在此类情况下，使用带有 @graph 属性的顶层 map 可以避免重复编写 @context。详见 § 4.5 嵌入。

重复的上下文 术语 使用“最近定义的优先”机制覆盖先前定义。

在上例中，name 这个 术语 在更深层的 details 结构中被覆盖，后者使用了它自己的 嵌入式上下文。注意这通常不是良好的编辑实践，通常仅在与依赖于特定 map 结构的遗留应用一起工作时使用。如果在上下文中重新定义了某个 术语，则与先前定义相关的所有规则都会被移除。如果将某个 术语 重新定义为 null，则该术语将从 活动上下文 中定义的术语列表中有效地移除。

可以通过使用一个 数组 来组合多个上下文，数组按顺序处理。特定 map 中定义的一组上下文被称为 本地上下文。活动上下文 指的是在文档中某一点处处于作用域内的 本地上下文 的累积。将 本地上下文 设置为 null 会将 活动上下文 有效地重置为空上下文（没有 术语定义、默认语言 或先前上下文中定义的其他内容）。下例指定了一个外部上下文，然后在该外部上下文之上叠加了一个 嵌入式上下文：

在 JSON-LD 1.1 中，引入上下文的机制还有其他方式，包括 scoped contexts（范围上下文）和 imported contexts（导入上下文），并且有新的方法来保护术语定义，因此并非总是最后定义的内联上下文决定术语的作用域。请参见 § 4.1.8 范围上下文、§ 4.1.9 上下文传播、§ 4.1.10 导入上下文 以及 § 4.1.11 受保护的术语定义 以获取更多信息。

{
  "@context": {
    "@version": 1.1,
    ...
  },
  ...
}

{
  "@context": {
    "label": "http://www.w3.org/2000/01/rdf-schema#label"
  },
  "@id": "",
  "label": "Just a simple document"
}

{
  "@context": {
    "@version": 1.1,
    "@base": "http://example/document",
    "@vocab": "#"
  },
  "@id": "http://example.org/places#BrewEats",
  "@type": "Restaurant",
  "name": "Brew Eats"
  ...
}

[{
  "http://example.com/vocab/property": [{"@value": "property"}],
  "http://example.com/vocab/propertyOne": [{"@value": "propertyOne"}]
}]

{
  "@context": {
    "vocab": "http://example.com/vocab/",
    "property": "http://example.com/vocab/property"
  }
}

{
  "@context": {
    "@version": 1.1,
    "vocab": "http://example.com/vocab/",
    "property": {
      "@id": "http://example.com/vocab/property",
      "@prefix": true
    }
  }
}

{
  "@context": {
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "http://xmlns.com/foaf/0.1/name",
    "age": {
      "@id": "http://xmlns.com/foaf/0.1/age",
      "@type": "xsd:integer"
    },
    "homepage": {
      "@id": "http://xmlns.com/foaf/0.1/homepage",
      "@type": "@id"
    }
  },
  ...
}

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "foaf:name",
    "age": {
      "@id": "foaf:age",
      "@type": "xsd:integer"
    },
    "homepage": {
      "@id": "foaf:homepage",
      "@type": "@id"
    }
  },
  ...
}

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "foaf:name",
    "foaf:age": {
      "@id": "http://xmlns.com/foaf/0.1/age",
      "@type": "xsd:integer"
    },
    "foaf:homepage": {
      "@type": "@id"
    }
  },
  ...
}

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "foaf:name",
    "foaf:age": {
      "@id": "http://xmlns.com/foaf/0.1/age",
      "@type": "xsd:integer"
    },
    "foaf:homepage": {
     "@id": "http://schema.org/url",
     "@type": "@id"
    }
  },
  ...
}

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "foaf:name",
    "foaf:age": {
      "@id": "http://xmlns.com/foaf/0.1/age",
      "@type": "xsd:integer"
    },
    "http://xmlns.com/foaf/0.1/homepage": {
      "@type": "@id"
    }
  },
  ...
}

{
  "@context": {
    "term1": "term2:foo",
    "term2": "term1:bar"
  },
  ...
}

{
  "@context": {
    "@version": 1.1,
    "@vocab": "http://example.com/vocab/",
    "property": {
      "@id": "http://example.com/vocab/property",
      "@context": {
        "term1": "http://example.com/vocab/term1"
         ↑ 为 "property" 定义的作用域上下文定义了 term1
      }
    },
    "Type1": {
      "@id": "http://example.com/vocab/Type1",
      "@context": {
        "term3": "http://example.com/vocab/term3"
         ↑ 为 "Type1" 定义的作用域上下文定义了 term3
      }
    },
    "Type2": {
      "@id": "http://example.com/vocab/Type2",
      "@context": {
        "term4": "http://example.com/vocab/term4"
         ↑ 为 "Type2" 定义的作用域上下文定义了 term4
      }
    }
  },
  "property": {
    "@context": {
      "term2": "http://example.com/vocab/term2"
         ↑ 嵌入的上下文定义了 term2
    },
    "@type": ["Type2", "Type1"],
    "term1": "a",
    "term2": "b",
    "term3": "c",
    "term4": "d"
  }
}

{
  "@context": {
    "@vocab": "http://example.com/vocab/",
    "property": "http://example.com/vocab/property",
    "Type1": "http://example.com/vocab/Type1",
    "Type2": "http://example.com/vocab/Type2"
  },
  "property": {
    "@context": [{
        "term1": "http://example.com/vocab/term1"
         ↑ 先前为 "property" 定义的作用域上下文定义了 term1
      }, {
        "term2": "http://example.com/vocab/term2"
         ↑ 嵌入的上下文定义了 term2
      }, {
        "term3": "http://example.com/vocab/term3"
         ↑ 先前为 "Type1" 定义的作用域上下文定义了 term3
      }, {
      "term4": "http://example.com/vocab/term4"
         ↑ 先前为 "Type2" 定义的作用域上下文定义了 term4
    }],
    "@type": ["Type2", "Type1"],
    "term1": "a",
    "term2": "b",
    "term3": "c",
    "term4": "d"
  }
}

{
  "@context": {
    "Type1": "http://example.com/vocab/Type1",
    "Type2": "http://example.com/vocab/Type2",
    "term1": "http://example.com/vocab#term1",
    "term2": "http://example.com/vocab#term2",
    ...
  }
}

{
  "@context": {
    "@version": 1.1,
    "MyType": {
      "@id": "http://example.com/vocab#MyType",
      "@context": {
        "@version": 1.1,
        "@import": "https://json-ld.org/contexts/remote-context.jsonld",
        "@propagate": true
      }
    }
  }
}

{
  "@context": {
    "@version": 1.1,
    "MyType": {
      "@id": "http://example.com/vocab#MyType",
      "@context": {
        "@version": 1.1,
        "Type1": "http://example.com/vocab/Type1",
        "Type2": "http://example.com/vocab/Type2",
        "term1": "http://example.com/vocab#term1",
        "term2": "http://example.com/vocab#term2",
        ...
        "@propagate": true
      }
    }
  }
}

{
  "@context": {
    "@version": 1.1,
    "@import": "https://json-ld.org/contexts/remote-context.jsonld",
    "@vocab": "http://example.org/vocab#",
     ↑ This will replace any previous @vocab definition prior to processing it
    "term1": {
      "@id": "http://example.org/vocab#term1",
      "@type": "http://www.w3.org/2001/XMLSchema#integer"
    }
     ↑ This will replace the old term1 definition prior to processing it
  }
}

{
  "@context": {
    "@version": 1.1,
    "Type1": "http://example.com/vocab/Type1",
    "Type2": "http://example.com/vocab/Type2",
    "term1": {
      "@id": "http://example.org/vocab#term1",
      "@type": "http://www.w3.org/2001/XMLSchema#integer"
    },
     ↑ Note term1 has been replaced prior to processing
    "term2": "http://example.com/vocab#term2",
    ...,
    "@vocab": "http://example.org/vocab#"
  }
}

{
  "@context": [
    {
      "@version": 1.1,
      "Person": "http://xmlns.com/foaf/0.1/Person",
      "knows": "http://xmlns.com/foaf/0.1/knows",
      "name": {
        "@id": "http://xmlns.com/foaf/0.1/name",
        "@protected": true
      }
    },
    {
      – this attempt will fail with an error
      "name": "http://schema.org/name"
    }
  ],
  "@type": "Person",
  "name": "Manu Sporny",
  "knows": {
    "@context": [
      – this attempt would also fail with an error
      null,
      "http://schema.org/"
    ],
    "name": "Gregg Kellogg"
  }
}

4.2 描述值

本节为非规范性内容。

值是图中与标量值（例如字符串、日期、时间等原子值）相关联的叶节点。

{
  ...
  "@id": "http://example.org/posts#TripToWestVirginia",
  "@type": "http://schema.org/BlogPosting",  ← 这是节点类型
  "http://purl.org/dc/terms/modified": {
    "@value": "2010-05-29T14:17:39+02:00",
    "@type": "http://www.w3.org/2001/XMLSchema#dateTime"  ← 这是值类型
  }
  ...
}

{
  "@context": {
    ...
    "@version": 1.1,
    "@vocab": "http://example.com/",
    "@language": "ja",
    "details": {
      "@context": {
        "@language": null
      }
    }
  },
  "name": "花澄",
  "details": {"occupation": "Ninja"}
}

{
  "@context": {
    ...
    "ex": "http://example.com/vocab/",
    "@language": "ja",
    "name": { "@id": "ex:name", "@language": null },
    "occupation": { "@id": "ex:occupation" },
    "occupation_en": { "@id": "ex:occupation", "@language": "en" },
    "occupation_cs": { "@id": "ex:occupation", "@language": "cs" }
  },
  "name": "Yagyū Muneyoshi",
  "occupation": "忍者",
  "occupation_en": "Ninja",
  "occupation_cs": "Nindža",
  ...
}

{
  "@context": {
    ...
    "occupation": { "@id": "ex:occupation", "@container": "@language" }
  },
  "name": "Yagyū Muneyoshi",
  "occupation": {
    "ja": "忍者",
    "en": "Ninja",
    "cs": "Nindža"
  }
  ...
}

{
  "@context": {
    ...
    "@language": "ja"
  },
  "name": "花澄",
  "occupation": {
    "@value": "Scientist",
    "@language": "en"
  }
}

{
  "@context": {
    ...
    "@language": "ja"
  },
  "name": {
    "@value": "Frank"
  },
  "occupation": {
    "@value": "Ninja",
    "@language": "en"
  },
  "speciality": "手裏剣"
}

{
  "@context": {
    ...
    "@version": 1.1,
    "@vocab": "http://example.com/",
    "@language": "ar-EG",
    "@direction": "rtl",
    "details": {
      "@context": {
        "@direction": null
      }
    }
  },
  "title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
  "details": {"genre": "Technical Publication"}
}

{
  "@context": {
    ...
    "@version": 1.1,
    "@language": "ar-EG",
    "@direction": "rtl",
    "ex": "http://example.com/vocab/",
    "publisher": { "@id": "ex:publisher", "@direction": null },
    "title": { "@id": "ex:title" },
    "title_en": { "@id": "ex:title", "@language": "en", "@direction": "ltr" }
  },
  "publisher": "مكتبة",
  "title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
  "title_en": "HTML and CSS: Design and Build Websites",
  ...
}

{
  "@context": {
    ...
    "@language": "ar-EG",
    "@direction": "rtl"
  },
  "title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
  "author": {
    "@value": "Jon Duckett",
    "@language": "en",
    "@direction": null
  }
}

4.3 值的排序

本节为非规范性内容。

JSON-LD 作者可以通过使用数组以紧凑的方式表示多个值。由于图（graph）不描述节点之间链接的顺序，JSON-LD 中的数组默认并不传达其中元素的顺序。这与常规 JSON 数组正好相反，后者默认是有序的。例如，考虑下面的简单文档：

也可以使用展开形式来表示多个值：

尽管某属性的多个值通常属于相同类型，JSON-LD 并不对此加以限制，属性可以具有不同类型的值：

{
  "type": "Feature",
  "bbox": [-10.0, -10.0, 10.0, 10.0],
  "geometry": {
    "type": "Polygon",
    "coordinates": [
        [
            [-10.0, -10.0],
            [10.0, -10.0],
            [10.0, 10.0],
            [-10.0, -10.0]
        ]
    ]
  }
  //...
}

{
  "@context": {
    "@version": 1.1,
    "@type": {"@container": "@set"}
  },
  "@type": ["http:/example.org/type"]
}

4.5 嵌入

本节为非规范性内容。

嵌入 是 JSON-LD 的一项特性，允许作者将 节点对象 用作属性值（property values）。这是一种常用机制，用于在两个节点之间创建父子关系。

如果不使用嵌入，节点对象 可以通过引用另一个节点对象的标识符来链接。例如：

上例分别描述了 Manu 与 Gregg 两个节点对象，并将 knows 属性定义为将字符串值视为标识符。嵌入 允许将 Gregg 的节点对象作为 knows 属性的值进行 嵌入：

像上面所示的那类 节点对象 可以在 JSON-LD 文档主体的任何值位置使用。

虽然在图中标识节点被视为最佳实践，但有时这并不现实。在数据模型中，未显式标识符的节点称为 空白节点，可以通过诸如 JSON-LD 的序列化使用 空白节点标识符 来表示。在前例中，Manu 的顶层节点没有标识符，也不需要在数据模型中有一个来描述它。然而，如果我们想描述 Gregg 到 Manu 的 knows 关系，就需要引入一个空白节点标识符（例如 _:b0）。

空白节点标识符 可能会被诸如 扁平化 等算法自动引入，但它们也对作者在文档中直接描述此类关系十分有用。

4.6 索引值

本节为非规范性内容。

有时需要比遍历多个数组值更直接地访问多个属性值。JSON-LD 提供了一种索引机制，允许使用中间的map将特定索引与其关联的值相关联。

数据索引

如 § 4.6.1 数据索引 所述，数据索引允许任意键引用一个节点或值。

语言索引

如 § 4.6.2 语言索引 所述，语言索引允许使用语言来引用一个字符串，并将其解释为与该字符串关联的语言。

节点标识符索引

如 § 4.6.3 节点标识符索引 所述，节点标识符索引允许一个IRI引用一个节点，并将其解释为该节点的标识符。

节点类型索引

如 § 4.6.4 节点类型索引 所述，节点类型索引允许一个IRI引用一个节点，并将其解释为该节点的类型。

有关 JSON-LD 中索引的其他用法，请参见 § 4.9 命名图。

4.8 反向属性

本节为非规范性内容。

JSON-LD 将有向 图 进行序列化。这意味着每个 属性 都从一个 节点 指向另一个 节点 或 值。然而在某些情况下，希望以相反方向进行序列化。例如，当想在文档中描述某人及其子女时，如果使用的词汇表没有提供 children 属性，只有 parent 属性，那么每个表示子女的节点都必须用指向其父的属性来表达，如下例所示。

使用 JSON-LD 的 @reverse 关键字 可以更简单地表达此类数据：

还可以在展开的术语定义中使用 @reverse 来创建反向属性，如下例所示：

4.9 命名图

本节为非规范性内容。

有时需要对图本身而不仅仅是单个节点进行陈述。这可以通过使用@graph 关键字将一组节点分组来完成。开发人员也可以通过将其与 @id 关键字配对来为使用 @graph 表示的数据命名，如下面示例所示：

上例表达了由 IRI 标识的命名图： http://example.org/foaf-graph。该图由关于 Manu 和 Gregg 的陈述组成。图本身的元数据通过 generatedAt 属性表达，用以指定图生成的时间。

当 JSON-LD 文档的顶层结构是一个只包含 @graph 和（可选）@context 的 map（非映射到 IRI 或关键字的属性会被忽略）时， @graph 被视为表达本该隐含的默认图。当在文档顶层存在若干共享相同 上下文 的节点时（例如文档已被 扁平化），这种机制会很有用。@graph 关键字将这些节点收集到一个 数组中，并允许使用共享上下文。

在这种情况下，由于图包含无关的节点，嵌入不可用。 等价于在数组中使用多个节点对象并在每个节点对象中定义 @context：

4.10 加载文档

本节为非规范性内容。

JSON-LD 1.1 处理算法与 API 规范 [JSON-LD11-API] 定义了JSON-LD 处理器接口，并包含用于操作不同形式 JSON-LD 的多种方法（参见§ 5. JSON-LD 形式）。 这包括用于加载远程文档的一般机制，包括引用的 JSON-LD 文档和远程上下文，并可用于提取嵌入于如 [HTML] 等其他格式中的 JSON-LD。 详见 远程文档与上下文获取 （参见 [JSON-LD11-API]）。

documentLoader在需要加载远程文档出现问题的场景下非常有用：

• 远程上下文文档应被缓存，以防止每次请求时对远程上下文位置造成过载。通常可以通过 HTTP 缓存基础设施实现在某些环境下无法实现。documentLoader 实现可能会提供独立的缓存逻辑。
• 非标准 URL scheme 可能无法被广泛实现，或可能具有特定于应用领域的行为。可通过自定义documentLoader实现文档获取语义。
• 某些知名上下文可在documentLoader实现中静态缓存。 这在嵌入式应用中尤为有用，因为此类环境下无法或不允许访问远程文档。
• 出于安全目的，远程检索文档的行为可能会暴露应用行为信息。 明智地使用documentLoader可以隔离应用并减少其在线指纹。

5.1 展开文档形式

本节为非规范性内容。

JSON-LD 1.1 Processing Algorithms and API 规范 [JSON-LD11-API] 定义了对 JSON-LD 文档进行“展开”的方法。 Expansion 是将 JSON-LD 文档应用 context 的过程，使得所有 IRI、类型和数值都被展开，从而使得 @context 不再必要。

例如，假设下面的 JSON-LD 输入文档：

{
   "@context": {
      "name": "http://xmlns.com/foaf/0.1/name",
      "homepage": {
        "@id": "http://xmlns.com/foaf/0.1/homepage",
        "@type": "@id"
      }
   },
   "name": "Manu Sporny",
   "homepage": "http://manu.sporny.org/"
}

对上述 JSON-LD 输入文档运行 JSON-LD 的 Expansion algorithm 将得到如下输出：

JSON-LD 的媒体类型 定义了一个可用于指示或请求 展开文档形式 的 profile 参数。标识 展开文档形式 的 profile URI 为 http://www.w3.org/ns/json-ld#expanded。

5.2 压缩文档形式

本节为非规范性内容。

JSON-LD 1.1 Processing Algorithms and API 规范 [JSON-LD11-API] 定义了对 JSON-LD 文档进行“压缩”的方法。Compaction 是将开发者提供的 context 应用于文档，从而将 IRI 缩短为 term 或 compact IRI，并将展开形式的 JSON-LD 值转换为如 字符串 或 数字 之类的简单值。 通常这使得以应用特定术语直接使用该文档变得更简单，压缩后的文档通常也更易于人类阅读。

例如，假设下面的 JSON-LD 输入文档：

[
  {
    "http://xmlns.com/foaf/0.1/name": [ "Manu Sporny" ],
    "http://xmlns.com/foaf/0.1/homepage": [
      {
       "@id": "http://manu.sporny.org/"
      }
    ]
  }
]

此外，假设下面是开发者提供的 JSON-LD 上下文（context）：

{
  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": {
      "@id": "http://xmlns.com/foaf/0.1/homepage",
      "@type": "@id"
    }
  }
}

在上述 context 下运行 JSON-LD 的 Compaction algorithm，对前述 JSON-LD 输入文档进行压缩，将得到如下输出：

JSON-LD 的媒体类型 定义了一个可用于指示或请求 压缩文档形式 的 profile 参数。标识 压缩文档形式 的 profile URI 为 http://www.w3.org/ns/json-ld#compacted。

Compaction 的细节在 Compaction algorithm（见 JSON-LD11-API）中有描述。 本节作为向希望为压缩 JSON-LD 文档创建 contexts 的作者提供的简要指南，介绍算法的工作方式。

压缩的目的是将 term definitions、vocabulary mapping、默认语言 和 base IRI 应用于现有 JSON-LD 文档， 使其以更适合直接作为 JSON 使用的形式呈现。 这包括尽可能将值表示为 字符串（而不是 值对象）， 将 list 对象 简化为普通 数组，反转节点之间的关系，以及使用数据映射来索引多个值而不是将它们表示为值数组。

5.3 扁平化文档形式

本节为非规范性内容。

JSON-LD 1.1 Processing Algorithms and API 规范 [JSON-LD11-API] 定义了对 JSON-LD 文档进行“扁平化”的方法。 Flattening 会将某个 节点 的所有属性收集到一个单一的 映射 中，并为所有空白节点标注空白节点标识符（blank node identifiers）。 这可确保数据的形状，从而在某些应用中显著简化处理 JSON-LD 所需的代码。

例如，假设下面的 JSON-LD 输入文档：

{
  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name",
    "knows": "http://xmlns.com/foaf/0.1/knows"
  },
  "@id": "http://me.markus-lanthaler.com/",
  "name": "Markus Lanthaler",
  "knows": [
    {
      "@id": "http://manu.sporny.org/about#manu",
      "name": "Manu Sporny"
    }, {
      "name": "Dave Longley"
    }
  ]
}

对上述输入文档运行 JSON-LD 的 Flattening algorithm 并使用相同的 context，会产生如下输出：

JSON-LD 的媒体类型 定义了一个可用于指示或请求 扁平化文档形式 的 profile 参数。标识 扁平化文档形式 的 profile URI 为 http://www.w3.org/ns/json-ld#flattened。 它可以与标识 展开文档形式 或 压缩文档形式 的 profile URI 结合使用。

5.4 框架化文档形式

本节为非规范性内容。

JSON-LD 1.1 Framing 规范 [JSON-LD11-FRAMING] 定义了对 JSON-LD 文档进行“框架化（framing）”的方法。Framing 用于塑造 JSON-LD 文档中的数据，使用一个示例 frame 文档来匹配扁平化的数据并展示预期的数据结构示例。

例如，假设如下 JSON-LD frame：

{
  "@context": {
    "@version": 1.1,
    "@vocab": "http://example.org/"
  },
  "@type": "Library",
  "contains": {
    "@type": "Book",
    "contains": {
      "@type": "Chapter"
    }
  }
}

该 frame 文档描述了一种嵌入结构，会将类型为 Library 的对象置于顶部， 并将那些通过 contains 属性链接到图书馆对象的类型为 Book 的对象作为属性值嵌入其中。同时还会将类型为 Chapter 的对象放置在引用它们的 Book 对象内部，作为该 Book 对象的嵌入值。

当使用与 frame 组件匹配的一组扁平化对象时：

{
  "@context": {
    "@vocab": "http://example.org/",
    "contains": {"@type": "@id"}
  },
  "@graph": [{
    "@id": "http://example.org/library",
    "@type": "Library",
    "contains": "http://example.org/library/the-republic"
  }, {
    "@id": "http://example.org/library/the-republic",
    "@type": "Book",
    "creator": "Plato",
    "title": "The Republic",
    "contains": "http://example.org/library/the-republic#introduction"
  }, {
    "@id": "http://example.org/library/the-republic#introduction",
    "@type": "Chapter",
    "description": "An introductory chapter on The Republic.",
    "title": "The Introduction"
  }]
}

框架算法可以创建一个遵循该 frame 结构的新文档：

JSON-LD 的媒体类型 定义了一个可用于指示或请求 框架化文档形式 的 profile 参数。标识 框架化文档形式 的 profile URI 为 http://www.w3.org/ns/json-ld#framed。

JSON-LD 的媒体类型 还定义了一个 profile 参数，可用于标识包含 frame 的 HTML 文档中的 script 元素。 首个类型为 application/ld+json;profile=http://www.w3.org/ns/json-ld#frame 的 script 元素 将用于查找 frame。