YAML-LD 1.0

摘要

[JSON-LD11] 是一种基于 JSON 的格式，用于序列化链接数据 [LINKED-DATA]。近年来，[YAML] 已成为一种更简洁的格式，用来表示此前以 [JSON] 序列化的信息，包括 API 规范、数据模式和链接数据。

本文档将 YAML-LD 定义为一组基于 YAML 的约定，这些约定指定如何基于 JSON-LD 的语法、语义和 API，将链接数据序列化为 YAML。

由于 YAML 比 JSON 表达能力更强，无论是在可用的数据类型方面，还是在文档结构方面（见 [RFC9512]），本文档标识了对 YAML 的约束，使任何 YAML-LD 文档都可以用 JSON-LD 表示。

目标
本文档定义了 YAML-LD，它是一组构建于 YAML 之上的约定，概述了如何基于 JSON-LD 的语法、语义和 API，将链接数据序列化为 YAML。YAML 作为一种更简洁的格式出现，用于表示此前以 JSON 序列化的信息，包括链接数据，这促成了 YAML-LD 的发展。

方法
本文档定义了对 YAML 的约束，使任何 YAML-LD 文档都可以用 JSON-LD 表示。这是必要的，因为 YAML 在可用数据类型和文档结构方面都比 JSON 表达能力更强。本文档还注册了 application/ld+yaml 媒体类型。

结果
本文档清晰描述了如何在 YAML 中序列化链接数据。它还描述了实现 YAML-LD 的基本概念和核心要求，包括 JSON 与 YAML 的比较、受支持的 YAML 特性以及编码注意事项。

局限性
YAML 的特性集比 JSON 更丰富，本规范不支持多项 YAML 特性。不过，本规范为未来开发支持这些特性的 YAML-LD 版本奠定了基础—— 通过扩展 YAML-LD 配置文件来实现。

结论
YAML-LD 提供了一种高效方式，可在多种能够使用 YAML 的编程语言中编码链接数据。

YAML-LD 入门示例如下所示。

示例 1：YAML-LD 入门文档

"@context":
  - https://json-ld.org/contexts/dollar-convenience.jsonld
  - schema: https://schema.org/
    dbo: http://dbpedia.org/ontology/
    dbp: http://dbpedia.org/property/
    dbr: http://dbpedia.org/resource/
    xsd: http://www.w3.org/2001/XMLSchema#
    dbp:discovered:
      "@type": xsd:date
    dbp:star:
      "@type": "@id"

$id: dbr:Proxima_Centauri_b
$type: dbo:Planet
schema:description: >-
  The closest known exoplanet to Earth,
  orbiting in Proxima Centauri's habitable zone.
dbp:discovered: 2016-08-24
dbp:star: dbr:Proxima_Centauri

编者注

请参阅本规范的 YAML-LD 描述： spec.yamlld 。

本节为非规范性内容。

要理解本规范的基础，必须熟悉以下内容：

[YAML] 数据标记语言，它是 YAML-LD 的底层语法
基本链接数据 [LINKED-DATA] 原则

本文档主要面向以下两类受众。

软件开发者，他们希望：
- 在多种能够使用 YAML 的编程语言中编码链接数据
- 将现有 YAML 转换为 YAML-LD
- 理解 YAML-LD 的设计决策和语言语法
- 实现 YAML-LD 的处理器和 API
- 以 YAML 语法生成或消费链接数据、RDF 图或 RDF 数据集
在相关技术中，构建大多数支持 YAML-LD 的应用时需要熟悉 JSON-LD；而只有在希望将 YAML-LD 转换为 RDF 图，或反向转换时，才需要熟悉 RDF。
其他专业人员，包括 IT 及非 IT 领域人员，他们希望阅读和/或制作 YAML-LD 格式的链接数据文档。此类文档可以：
- 由能够理解 YAML-LD 的编程系统消费
- 通过 JSON-LD 框架算法进行转换
- 发布到 Web 上，供人类和机器消费
对这些用户而言，不要求熟悉 JSON-LD，但理解链接数据原则可能会有帮助。

本节为非规范性内容。

本文档使用以下在外部规范中定义的术语，并定义 JSON-LD 专用术语。

YAML-LD 流是由YAML 流组成的 YAML-LD 文档序列。

YAML-LD 文档是指任何 YAML 文档，对其转换为 [JSON] 会产生一个有效的 JSON-LD 文档，并且该文档可解释为 [LINKED-DATA]。

术语媒体类型引自 [RFC6838]。

术语 JSON引自 [JSON]。

术语 JSON 文档表示一种资源的序列化，该资源符合 [JSON] 语法。

术语 JSON-LD 文档，以及值对象引自 [JSON-LD11]。

术语内部表示，以及 documentLoader 引自 [JSON-LD11-API]。

术语数组、布尔值、映射、映射条目、 null，以及字符串引自 [INFRA]。

术语数值引自 [ECMASCRIPT]。

术语 YAML、 YAML 表示图、 YAML 流、 YAML 指令、 TAG 指令、 YAML 文档、 YAML 序列（即块序列或流式序列）、 YAML 映射（即块映射或流式映射）、节点、标量、节点锚点、节点标签，以及别名节点，均引自 [YAML]。

术语内容协商引自 [RFC9110]。

术语 RDF 字面量、带语言标签的字符串、数据类型 IRI，以及语言标签引自 [RDF11-CONCEPTS]。

本文档中的术语片段和片段标识符应按照 [URI] 中的含义解释。

术语链接数据引自 [LINKED-DATA]。

本节为非规范性内容。

本规范使用以下命名空间前缀：

前缀	IRI
ex	https://example.org/
i18n	https://www.w3.org/ns/i18n#
rdf	http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs	http://www.w3.org/2000/01/rdf-schema#
xsd	http://www.w3.org/2001/XMLSchema#
schema	https://schema.org/
prov	http://www.w3.org/ns/prov#

编者注

请参阅此表的 YAML-LD 版本： namespace-prefixes.yamlld 。

这些前缀在本文档中用作紧凑 IRI 的一部分，作为所得 IRI 的简写，例如使用 schema:url 表示 https://schema.org/url。

本节为非规范性内容。

YAML 是 JSON 的超集，即每个有效的 JSON 文档也是有效的 YAML 文档。 YAML 还提供了许多额外特性，其中最重要的是由于能够使用最少标点而提升的人类可读性。

如下方比较表所示，YAML 比 JSON 更灵活。

特性	[JSON]	[YAML]	YAML-LD
允许的编码
UTF-8	✅	✅	✅
UTF-16	❌	✅	❌
UTF-32	❌	✅	❌
原生数据类型
`{}` 对象	✅	✅	✅
`[]` 数组	✅	✅	✅
字符串	✅	✅	✅
数值	✅	✅ 整数浮点数	✅
布尔值	✅	✅	✅
null	✅	✅	✅
特性
带分隔符的字符串、数组、对象	✅	✅	✅
无标点字符串、数组、对象	❌	✅	✅
自定义类型	❌	✅ 通过标签	仅 Core Schema
每个文件中的文档数	1	⩾ 1，通过 YAML 流	⩾ 1（取决于 `extractAllScripts` 标志，见流处理）
注释	❌	✅	✅ 视为空白
锚点与别名	❌	✅	✅ 锚点名称不承载语义信息
循环	❌	✅	❌ 不允许
映射键类型	`string`	YAML 中可表示的任何类型，从字符串到映射	`string`

编者注

请参阅此表的 YAML-LD 版本： json-vs-yaml.yamlld 。

本规范的第一个目标是允许将 JSON-LD 文档处理并序列化为 YAML，然后再转换回 JSON-LD，且不丢失任何语义信息。

这始终是可能的，因为

YAML 表示图始终可以表示树
JSON 数据类型集合是 YAML 数据类型集合的子集
JSON 编码为 UTF-8。

示例 1 的 JSON-LD 序列化：

示例 2：入门示例的 JSON-LD 等价形式

{
  "@context": [
    "https://json-ld.org/contexts/dollar-convenience.jsonld",
    {
      "schema": "https://schema.org/",
      "dbo": "http://dbpedia.org/ontology/",
      "dbp": "http://dbpedia.org/property/",
      "dbr": "http://dbpedia.org/resource/",
      "xsd": "http://www.w3.org/2001/XMLSchema#",
      "dbp:discovered": {
        "@type": "xsd:date"
      },
      "dbp:star": {
        "@type": "@id"
      }
    }
  ],
  "$id": "dbr:Proxima_Centauri_b",
  "$type": "dbo:Planet",
  "schema:description": "The closest known exoplanet to Earth, orbiting in Proxima Centauri's habitable zone.",
  "dbp:discovered": "2016-08-24",
  "dbp:star": "dbr:Proxima_Centauri"
}

YAML-LD 文档 MUST 使用 UTF-8 编码，以确保与 [JSON] 的互操作性；否则， MUST 检测到 invalid-encoding，并中止处理。

YAML-LD 文档中的注释会被视为空白。

更多详细信息，请参见 “+yaml” 结构化语法后缀的互操作性考量。

注

在本规范中，锚点指 YAML 的节点锚点机制（连同别名节点，在序列化中使用 & 和 *）用于在序列化图中通过引用复用同一个逻辑节点。它与 HTML 超链接或 URL 片段标识符无关。参见 [YAML] §3.2.2.2 锚点与别名和 §6.9.2 节点锚点。

由于锚点名称是序列化细节，此类锚点 MUST NOT 用于传达相关信息，在处理文档时 MAY 被更改，并且在 YAML-LD 处理期间 MAY 被丢弃。

YAML-LD 文档 MAY 包含带锚点的节点和别名节点，但其表示图 MUST NOT 包含循环；否则，MUST 检测到 loading-document-failed 错误，并中止处理。

将文档解释为 JSON-LD 时，别名节点 MUST 按值解析为其目标节点。

锚点在 @context 块中特别有用。当多个术语共享同一个术语定义时——例如所有取 IRI 值的属性——可以只锚定一次共享定义，并为每个术语使用别名，从而避免重复。以下示例将 IRI 强制定义锚定为 &iri，并将其复用于三个属性：

示例 3：带锚点的 YAML-LD 上下文

"@context":
  dbo: http://dbpedia.org/ontology/
  dbp: http://dbpedia.org/property/
  dbr: http://dbpedia.org/resource/

  dbp:star:            &iri
    "@type": "@id"
  dbp:discoveryMethod: *iri
  dbp:discoverySite:   *iri

"@id": dbr:Proxima_Centauri_b
dbp:star:            dbr:Proxima_Centauri
dbp:discoveryMethod: dbr:Doppler_spectroscopy
dbp:discoverySite:   dbr:European_Southern_Observatory

所有锚点和别名解析完成后，等价的 JSON-LD 为：

示例 4：由带锚点的 YAML-LD 上下文得到的 JSON-LD

{
  "@context": {
    "dbo": "http://dbpedia.org/ontology/",
    "dbp": "http://dbpedia.org/property/",
    "dbr": "http://dbpedia.org/resource/",
    "dbp:star": {
      "@type": "@id"
    },
    "dbp:discoveryMethod": {
      "@type": "@id"
    },
    "dbp:discoverySite": {
      "@type": "@id"
    }
  },
  "@id": "dbr:Proxima_Centauri_b",
  "dbp:star": "dbr:Proxima_Centauri",
  "dbp:discoveryMethod": "dbr:Doppler_spectroscopy",
  "dbp:discoverySite": "dbr:European_Southern_Observatory"
}

注：锚点和别名是 YAML 序列化的特性

映射键类型 MUST 是 string。否则，会引发处理错误。

YAML-LD 使用 YAML Core Schema 进行标量类型解析。无法在 [JSON] 中表示的浮点值—— 具体来说，无穷大（.inf、-.inf、+.inf）和非数值（.nan）——MUST 导致 loading-document-failed 错误。

YAML Core Schema 未定义时间戳类型；像 2018-04-01 这样的标量会解析为普通字符串。但是，许多 YAML 库默认实现 YAML 1.1 时间戳解析，并会静默地将此类标量转换为原生 date 或 datetime 对象。 YAML-LD 处理器 MUST NOT 执行此类转换，并且 MUST 将这些值视为字符串。

除了 YAML Core Schema 所定义的标量类型解析之外，YAML-LD 不会为节点标签赋予额外的 JSON-LD 含义。

注：Core Schema 类型解析

下表总结了根据 YAML Core Schema 进行的标量类型解析以及 YAML-LD 行为：

模式	解析后的标签	YAML-LD
`null \| Null \| NULL \| ~`	`tag:yaml.org,2002:null`	JSON `null`
（空）	`tag:yaml.org,2002:null`	JSON `null`
`true \| True \| TRUE \| false \| False \| FALSE`	`tag:yaml.org,2002:bool`	JSON `true` / `false`
`[-+]?[0-9]+`	`tag:yaml.org,2002:int`（10 进制）	JSON number
`0o[0-7]+`	`tag:yaml.org,2002:int`（8 进制）	JSON number
`0x[0-9a-fA-F]+`	`tag:yaml.org,2002:int`（16 进制）	JSON number
`[-+]?(\.[0-9]+\|[0-9]+(\.[0-9]*)?)([eE][-+]?[0-9]+)?`	`tag:yaml.org,2002:float`（数值）	JSON number
`[-+]?(\.inf\|\.Inf\|\.INF)`	`tag:yaml.org,2002:float`（无穷大）	引发 `loading-document-failed`
`\.nan\|\.NaN\|\.NAN`	`tag:yaml.org,2002:float`（NaN）	引发 `loading-document-failed`
（任何其他值）	`tag:yaml.org,2002:str`	JSON string

每个 YAML-LD 文件都是一个 YAML-LD 流，并且可能包含多个 YAML-LD 文档，如下例所示。

示例 5：一个文件中包含多个文档的 YAML-LD

"@context":
  dbo: http://dbpedia.org/ontology/
  dbr: http://dbpedia.org/resource/
"@id": dbr:Proxima_Centauri
"@type": dbo:Star
---
"@context":
  dbo: http://dbpedia.org/ontology/
  dbr: http://dbpedia.org/resource/
"@id": dbr:Proxima_Centauri_b
"@type": dbo:Planet

[JSON-LD11-API] 定义了 extractAllScripts 标志，该标志允许解析 HTML 文档中包含 JSON-LD 内容的多个 <script> 标签。

一致的 YAML-LD 规范在解析普通 YAML-LD 流时，也必须考虑此标志。

如果该标志为 true，则 YAML 流会被视为一个数组，其中的每个文档都是该数组中的一项，即使该流中只有一个文档也是如此；
如果该标志为 false，则只会处理流中的第一个文档。

注：关于 YAML 流的互操作性考虑

关于 YAML 流的互操作性考虑，参见 YAML 媒体类型中的相关章节。

本节为非规范性内容。

JSON-LD 1.1 中的 @json 关键词将 JSON 字面量定义为一个值对象，其 @type 为 @json，并且 @value 包含 JSON 数据。处理器会将这样的值视为 JSON 字面量，而不是进一步将其解释为 JSON-LD。请看以下示例。

示例 6：带有 Proxima Centauri b 轨道参数的 JSON 字面量

"@context":
  schema: https://schema.org/
  dbr: http://dbpedia.org/resource/

"@id": dbr:Proxima_Centauri_b
schema:additionalProperty:
  "@type": "@json"
  "@value":
    semiMajorAxis: 0.0485
    orbitalPeriod: 11.186
    equilibriumTemperature: 234
    eccentricity: 0.11

请看展开形式。

示例 7：带有 Proxima Centauri b 轨道参数的展开 JSON 字面量

[
  {
    "@id": "http://dbpedia.org/resource/Proxima_Centauri_b",
    "https://schema.org/additionalProperty": [
      {
        "@type": "@json",
        "@value": {
          "semiMajorAxis": 0.0485,
          "orbitalPeriod": 11.186,
          "equilibriumTemperature": 234,
          "eccentricity": 0.11
        }
      }
    ]
  }
]

虽然该关键词名为 @json，但它并不要求 @value 的值在 YAML-LD 中使用 JSON 语法书写。如本例所示，metadata 值对象在展开过程中会以其 JSON-LD 形式保留下来——这是该关键词所要求的。

当它被转换为 RDF 时，JSON 字面量的词法形式是由 JSON 文本从内部表示重建而来。

本节已提交给互联网工程指导组（IESG）审查、批准并在 IANA 注册。

本节描述了根据 [RFC6838] 注册上述媒体类型所需的信息

类型名称：

application

子类型名称：

ld+yaml

必需参数：

不适用

可选参数：

profile

一个非空的、由空格分隔的 URI 列表，用于标识适用于 YAML-LD 文档的特定约束或约定，依据 [RFC6906]。在不了解 profile 的情况下处理时，profile 不会改变资源表示的语义，因此了解和不了解已设定 profile 的资源的客户端都可以安全地使用同一表示。profile 参数 MAY 由客户端用于在内容协商过程中表达其偏好。如果给出了 profile 参数，服务器 SHOULD 返回一个遵循列表中其能够识别的 profile 的文档，并且 MUST 忽略列表中其无法识别的 profile。 RECOMMENDED profile URI 可解引用，并在该 URI 处提供有用的文档。更多信息和背景请参见 [RFC6906]。

本规范允许使用中列出的 profile 参数，并另外定义以下内容：

http://www.w3.org/ns/json-ld#extended: 用于请求或指定扩展 YAML-LD 文档形式。

编者注

这是一个占位符，用于指定类似一种扩展 YAML-LD 文档形式的内容，该形式会使用 YAML 特有的特性。

当在媒体类型参数 [RFC4288] 中，作为 HTTP Accept 标头字段 [RFC9110] 的一部分使用时，如果 profile 参数的值包含空白等特殊字符，MUST 用引号（"）括起，这在组合多个 profile URI 时是必需的。

处理 "profile" 媒体类型参数时，重要的是要注意其值包含的是一个或多个 URI，而不是 IRI。在某些情况下，因此可能需要按照 [RFC3987] 的第 3 节 IRI 与 URI 之间的关系中的规定，在 IRI 和 URI 之间进行转换。

编码考量：

与 +yaml 相同。

安全考量：

见 6. 安全考量。

互操作性考量：

见 8. 互操作性考量。

已发布规范：

http://www.w3.org/TR/yaml-ld

使用此媒体类型的应用：

任何需要交换有向图的编程环境。

其他信息：

此类型的已弃用别名：

不适用

幻数：

与 application/yaml 相同

文件扩展名：

.yaml
.yamlld

Macintosh 文件类型代码：

与 application/yaml 相同

Windows 剪贴板名称：

与 application/yaml 相同

获取更多信息的联系人及电子邮件地址：

W3C JSON-LD 工作组 <public-json-ld-wg@w3.org>

预期用途：

通用

使用限制：

不适用

作者：

Roberto Polli, Gregg Kellogg

变更控制方：

W3C

[HTML]: HTML 标准。Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters。WHATWG。现行标准。URL：https://html.spec.whatwg.org/multipage/
[INFRA]: Infra 标准。Anne van Kesteren; Domenic Denicola。WHATWG。现行标准。URL：https://infra.spec.whatwg.org/
[JSON]: JavaScript Object Notation（JSON）数据交换格式。T. Bray, Ed. IETF。2017 年 12 月。互联网标准。URL：https://www.rfc-editor.org/info/rfc8259/
[JSON-LD11]: JSON-LD 1.1。Gregg Kellogg; Pierre-Antoine Champin; Dave Longley。W3C。2020 年 7 月 16 日。W3C 推荐标准。URL：https://www.w3.org/TR/json-ld11/
[JSON-LD11-API]: JSON-LD 1.1 处理算法和 API。Gregg Kellogg; Dave Longley; Pierre-Antoine Champin。W3C。2020 年 7 月 16 日。W3C 推荐标准。URL：https://www.w3.org/TR/json-ld11-api/
[JSON-LD11-FRAMING]: JSON-LD 1.1 Framing。Dave Longley; Gregg Kellogg; Pierre-Antoine Champin。W3C。2020 年 7 月 16 日。W3C 推荐标准。URL：https://www.w3.org/TR/json-ld11-framing/
[RFC2119]: 用于 RFC 中表示要求级别的关键词。S. Bradner。IETF。1997 年 3 月。当前最佳实践。URL：https://www.rfc-editor.org/info/rfc2119/
[RFC3986]: 统一资源标识符（URI）：通用语法。T. Berners-Lee; R. Fielding; L. Masinter。IETF。2005 年 1 月。互联网标准。URL：https://www.rfc-editor.org/info/rfc3986/
[RFC3987]: 国际化资源标识符（IRI）。M. Duerst; M. Suignard。IETF。2005 年 1 月。提议标准。URL：https://www.rfc-editor.org/info/rfc3987/
[RFC4288]: 媒体类型规范和注册程序。N. Freed; J. Klensin。IETF。2005 年 12 月。当前最佳实践。 URL：https://www.rfc-editor.org/info/rfc4288/
[RFC6838]: 媒体类型规范和注册程序。N. Freed; J. Klensin; T. Hansen。IETF。2013 年 1 月。当前最佳实践。URL：https://www.rfc-editor.org/info/rfc6838/
[RFC6906]: 'profile' 链接关系类型。E. Wilde。IETF。2013 年 3 月。资料性。URL：https://www.rfc-editor.org/info/rfc6906/
[RFC8174]: RFC 2119 关键词中大写与小写的歧义。B. Leiba。IETF。2017 年 5 月。当前最佳实践。URL：https://www.rfc-editor.org/info/rfc8174/
[RFC9110]: HTTP 语义。R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed. IETF。2022 年 6 月。互联网标准。URL：https://httpwg.org/specs/rfc9110.html
[YAML]: YAML Ain't Markup Language (YAML™) version 1.2.2。Oren Ben-Kiki; Clark Evans; Ingy döt Net。YAML 语言开发团队。 2021-10-01。URL：https://yaml.org/spec/1.2.2/
[yaml-ld-extended-profile]: YAML-LD 扩展配置文件。 Gregg Kellogg; Pierre-Antoine Champin; Anatoly Scherbakov。W3C。W3C 群组草案说明。URL：https://www.w3.org/TR/yaml-ld-extended-profile/

[ECMASCRIPT]: ECMAScript 语言规范。 Ecma International。URL：https://tc39.es/ecma262/multipage/
[LINKED-DATA]: 链接数据设计问题。Tim Berners-Lee。W3C。2006 年 7 月 27 日。W3C 内部文档。URL：https://www.w3.org/DesignIssues/LinkedData.html
[RDF11-CONCEPTS]: RDF 1.1 概念与抽象语法。Richard Cyganiak; David Wood; Markus Lanthaler。W3C。2014 年 2 月 25 日。 W3C 推荐标准。URL：https://www.w3.org/TR/rdf11-concepts/
[RFC8259]: JavaScript Object Notation（JSON）数据交换格式。T. Bray, Ed. IETF。2017 年 12 月。互联网标准。URL：https://www.rfc-editor.org/info/rfc8259/
[RFC9512]: YAML 媒体类型。R. Polli; E. Wilde; E. Aro。IETF。2024 年 2 月。资料性。URL：https://www.rfc-editor.org/info/rfc9512/
[TURTLE]: RDF 1.1 Turtle。Eric Prud'hommeaux; Gavin Carothers。W3C。2014 年 2 月 25 日。W3C 推荐标准。URL：https://www.w3.org/TR/turtle/
[URI]: 统一资源标识符（URI）：通用语法。T. Berners-Lee; R. Fielding; L. Masinter。IETF。2005 年 1 月。互联网标准。URL：https://www.rfc-editor.org/info/rfc3986/

[TURTLE] 以及其他支持注释的链接数据序列化

在处理文档并将其序列化为其他格式时，不提供保留这些注释的方法

YAML

要求文档中未反映在表示图中的部分，例如

注释
指令
映射键顺序
锚点名称

不得用于传达应用级信息。

理论上，我们可以尝试将 YAML 注释收集到 JSON-LD 文档中。我们会定义一个特定谓词，例如 https://json-ld.org/yaml-ld/comment，并把每个 # My comment 片段转换为 JSON-LD 文档中的一个 {"yaml-ld:comment": "My comment"} 片段。

但是，这会对实现产生以下影响：

它们会更复杂，因为大多数工业可用的 YAML 解析器在读取 YAML 数据时会丢弃注释
它们会更不可预测，因为 JSON 不保留键的顺序—— 因此，当把 JSON-LD 文档转换回 YAML-LD 时，注释可能会错位。

YAML-LD 1.0

摘要

本文档状态

1. 引言

1.1 如何阅读本文档

1.2 术语

1.3 命名空间前缀

2. 一致性

2.1 基础规范版本

2.2 测试套件

3. 基本概念

3.1 JSON 与 YAML 比较

4. 核心要求

4.1 编码

4.2 注释

4.3 锚点与别名

4.4 映射键类型

4.5 标量值类型

4.6 流

4.7 JSON 字面量

5. YamlLdErrorCode

6. 安全考量

7. 隐私考量

8. 互操作性考量

9. 在 HTML 文档中嵌入 YAML-LD

A. IANA 考量

A.1 application/ld+yaml

B. 为什么注释被视为空白？

B.1 一致性

B.2 可预测性

C. 致谢

C.1 缅怀

C.2 贡献

D. 参考文献

D.1 规范性引用

D.2 资料性引用

YAML-LD 1.0

摘要

本文档状态

1. 引言

1.1 如何阅读本文档

1.2 术语

1.3 命名空间前缀

2. 一致性

2.1 基础规范版本

2.2 测试套件

3. 基本概念

3.1 JSON 与 YAML 比较

4. 核心要求

4.1 编码

4.2 注释

4.3 锚点与别名

4.4 映射键类型

4.5 标量值类型

4.6 流

4.7 JSON 字面量

5. YamlLdErrorCode

6. 安全考量

7. 隐私考量

8. 互操作性考量

9. 在 HTML 文档中嵌入 YAML-LD

A. IANA 考量

A.1 application/ld+yaml

B. 为什么注释被视为 空白？

B.1 一致性

B.2 可预测性

C. 致谢

C.1 缅怀

C.2 贡献

D. 参考文献

D.1 规范性引用

D.2 资料性引用

B. 为什么注释被视为空白？