YAML-LD 1.0

Abstract

[JSON-LD11] is a JSON-based format to serialize Linked Data [LINKED-DATA]. In recent years, [YAML] has emerged as a more concise format to represent information that had previously been serialized as [JSON], including API specifications, data schemas, and Linked Data.

This document defines YAML-LD as a set of conventions on top of YAML which specify how to serialize Linked Data as YAML based on JSON-LD syntax, semantics, and APIs.

Since YAML is more expressive than JSON, both in the available data types and in the document structure (see [RFC9512]), this document identifies constraints on YAML such that any YAML-LD document can be represented in JSON-LD.

YAML-LD applies JSON-LD's data model and processing model to YAML so that Linked Data can be written in a YAML syntax while remaining representable as JSON-LD.

It is intended for documents that are read and written by humans and by software agents, including those based on Large Language Models.

An introductory YAML-LD example is presented below.

Example 1: Introductory YAML-LD document

"@context":
  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

This section is non-normative.

To understand the basics of this specification, one must be familiar with the following:

[YAML] data markup language, which is the underlying syntax for YAML-LD
basic Linked Data [LINKED-DATA] principles

This document is intended primarily for two main audiences, as described below.

Software developers who want to —
- encode Linked Data in a variety of programming languages which can use YAML
- convert existing YAML to YAML-LD
- understand the design decisions and language syntax for YAML-LD
- implement processors and APIs for YAML-LD
- generate or consume Linked Data, an RDF Graph, or an RDF Dataset in a YAML syntax
Among related technologies, JSON-LD familiarity would be required to build most YAML-LD capable applications, while RDF familiarity is only required when it is desired to convert YAML-LD to RDF graphs, or vice versa.
Other professionals, both IT and otherwise who want to read and/or produce Linked Data documents in YAML-LD format. Such documents can be —
- consumed by programming systems capable of understanding YAML-LD
- transformed with JSON-LD framing algorithms
- published on the Web for human and machine consumption
For these users, familiarity with JSON-LD is not required, but understanding of Linked Data principles might be beneficial.

This section is non-normative.

This document uses the following terms as defined in external specifications and defines terms specific to JSON-LD.

A YAML-LD stream is a YAML stream of YAML-LD documents. On disk or on the wire, YAML-LD is always exchanged as a YAML-LD stream (one stream per file or HTTP body), containing one or more YAML-LD documents.

A YAML-LD document is any YAML document from which a conversion to [JSON] produces a valid JSON-LD document which can be interpreted as [LINKED-DATA].

The term media type is imported from [RFC6838].

The term JSON is imported from [JSON].

The term JSON document represents a serialization of a resource conforming to the [JSON] grammar.

The terms JSON-LD document, and value object are imported from [JSON-LD11].

The terms internal representation, and documentLoader are imported from [JSON-LD11-API].

The terms array, boolean, map, map entry, null, and string are imported from [INFRA].

The term number is imported from [ECMASCRIPT].

The terms YAML, YAML representation graph, YAML stream, YAML directive, TAG directive, YAML document, YAML sequence (either block sequence or flow sequence), YAML mapping (either block mapping or flow mapping), node, scalar, node anchor, node tags, and alias node, are imported from [YAML].

The term content negotiation is imported from [RFC9110].

The terms RDF literal, language-tagged string, datatype IRI, and language tag are imported from [RDF11-CONCEPTS].

The terms fragment and fragment identifier in this document are to be interpreted as in [URI].

The term Linked Data is imported from [LINKED-DATA].

This section is non-normative.

This specification makes use of the following namespace prefixes:

Prefix	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#

Editor's note

See YAML-LD version of this table at namespace-prefixes.yamlld .

These are used within this document as part of a compact IRI as a shorthand for the resulting IRI, such as schema:url used to represent https://schema.org/url.

This section is non-normative.

[YAML] is a superset of [JSON], i.e., every valid JSON document is also a valid YAML document. YAML also offers a number of extra features, chief among which is improved human readability due to the minimized punctuation requirements.

YAML is more flexible than JSON, as illustrated by the comparison table below.

Features	[JSON]	[YAML]	YAML-LD
Allowed encodings
UTF-8	✅	✅	✅
UTF-16	❌	✅	❌
UTF-32	❌	✅	❌
Native data types
`{}` object	✅	✅	✅
`[]` array	✅	✅	✅
string	✅	✅	✅
number	✅	✅ integer floating point	✅
bool	✅	✅	✅
null	✅	✅	✅
Features
Delimited strings, arrays, objects	✅	✅	✅
Punctuation-free strings, arrays, objects	❌	✅	✅
Custom types	❌	✅ via tags	Core Schema only
Documents per file	1	⩾ 1 via YAML stream	⩾ 1 (depending on `extractAllScripts` flag, see Stream Processing)
Comments	❌	✅	✅ Treated as Whitespace
Anchors & aliases	❌	✅	✅ Anchor names do not bear semantic information
Cycles	❌	✅	❌ Not permitted
Mapping key types	`string`	Any type representable in YAML, from strings to mappings	`string`

Editor's note

See YAML-LD version of this table at json-vs-yaml.yamlld .

[eriksson-hallberg] showed that, although YAML can be larger than equivalent JSON for some deeply nested documents, for many flatter documents it is smaller than pretty-printed JSON while remaining human-readable. That combination can reduce the amount of text that large language models and other software agents must process, without requiring a separate minified encoding.

The goal of this specification is to allow a JSON-LD document to be processed and serialized into YAML, and then back into JSON-LD, without losing any semantic information.

This is always possible because

a YAML representation graph can always represent a tree
set of JSON data types is a subset of the set of YAML data types
JSON encoding is UTF-8.

JSON-LD serialization of Example 1:

Example 2: JSON-LD equivalent of the introductory example

{
  "@context": {
    "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 Ain't Markup Language (YAML™) version 1.2.2 describes YAML processing in a number of steps, reproduced in Figure 1. This processing transforms a stream of characters in the YAML syntax (on the right) to and from a so-called "native data structure" (on the left). In JSON-LD, that data structure is the JSON-LD internal representation.

YAML Processing Overview — Figure 1 YAML processing overview, from [YAML]

This section describes the requirements imposed by YAML-LD on the YAML processing steps, in the load direction (right to left in Figure 1). Dump proceeds in the opposite direction, producing a conforming YAML-LD stream from a JSON-compatible internal representation.

Presentation is the YAML character stream in Figure 1.

JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8.

— [JSON] §8.1 Character Encoding

A YAML-LD stream MUST be encoded in UTF-8; otherwise, an invalid-encoding error MUST be detected, and processing aborted.

Comments are a presentation detail and must not have any effect on the serialization tree or representation graph.

— [YAML] §3.2.3.3 Comments

Comments in YAML-LD streams are treated as white space.

See YAML and JSON interoperability considerations for more details.

YAML allows several serialization trees to be contained in the same YAML presentation stream, as a series of documents separated by markers.

— [YAML] §3.2.3 Presentation Stream

A YAML-LD stream MAY contain more than one YAML-LD document, as shown below.

Example 3: YAML-LD with several documents in one file

"@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

Note: Interoperability considerations on YAML streams

For interoperability considerations on YAML streams, see the relevant section in YAML Media Type.

Serialization is the ordered tree produced by Parse (and consumed by Present) in Figure 1.

Anchor names are a serialization detail and are discarded once composing is completed.

— [YAML] §3.2.2.2 Anchors and Aliases

Note

In this specification, anchor means YAML's node anchor mechanism (with alias nodes, using & and * in the serialization) to reuse the same logical node by reference in the serialized graph. It is not related to HTML hyperlinks or URL fragment identifiers. See [YAML] §6.9.2 Node Anchors.

Consequently, anchor names MUST NOT be used to convey relevant information, MAY be altered when processing the document, and MAY be dropped during YAML-LD processing.

Anchors are particularly useful within a @context block. When several terms share the same term definition — for example, all IRI-valued properties — the shared definition can be anchored once and aliased for each term, avoiding repetition. The following example anchors the IRI coercion definition as &iri and reuses it for three properties:

Example 4: YAML-LD context with anchors

"@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

Once all anchors and aliases have been resolved, the equivalent JSON-LD is:

Example 5: JSON-LD resulting from YAML-LD context with anchors

{
  "@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"
}

Note: Anchors and aliases are features of YAML serialization

Representation is the YAML representation graph produced by Compose in Figure 1.

A YAML-LD document MAY contain anchored nodes and alias nodes in its serialization, but its representation graph MUST NOT contain cycles; otherwise, a loading-document-failed error MUST be detected, and processing aborted.

When composing the representation graph, each alias node MUST resolve to the node identified by its target anchor. When constructing the JSON-LD internal representation, each reference to that node MUST be treated as a copy of the node.

When composing a complete representation graph, YAML-LD uses the YAML Core Schema for scalar type resolution. Float values that cannot be represented in [JSON] — specifically infinity (.inf, -.inf, +.inf) and not-a-number (.nan) — MUST cause a loading-document-failed error to be raised when constructing the JSON-LD internal representation.

The YAML Core Schema does not define a timestamp type; scalars such as 2018-04-01 resolve to plain strings. However, many YAML libraries implement YAML 1.1 timestamp resolution by default and will silently convert such scalars to native date or datetime objects. YAML-LD processors MUST NOT perform such conversion and MUST treat these values as strings.

YAML-LD does not assign additional JSON-LD meaning to node tags beyond the scalar type resolution defined by the YAML Core Schema.

Note: Core Schema type resolution

The following table summarizes scalar type resolution per the YAML Core Schema and YAML-LD behaviour:

Pattern	Resolved tag	YAML-LD
`null \| Null \| NULL \| ~`	`tag:yaml.org,2002:null`	JSON `null`
(empty)	`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` (base 10)	JSON number
`0o[0-7]+`	`tag:yaml.org,2002:int` (base 8)	JSON number
`0x[0-9a-fA-F]+`	`tag:yaml.org,2002:int` (base 16)	JSON number
`[-+]?(\.[0-9]+\|[0-9]+(\.[0-9]*)?)([eE][-+]?[0-9]+)?`	`tag:yaml.org,2002:float` (number)	JSON number
`[-+]?(\.inf\|\.Inf\|\.INF)`	`tag:yaml.org,2002:float` (infinity)	raises `loading-document-failed`
`\.nan\|\.NaN\|\.NAN`	`tag:yaml.org,2002:float` (NaN)	raises `loading-document-failed`
(any other)	`tag:yaml.org,2002:str`	JSON string

The native data structure produced by Construct in Figure 1 is the JSON-LD internal representation.

[JSON-LD11-API] defines the extractAllScripts flag, which allows to parse multiple <script> tags with JSON-LD content in an HTML document.

A conformant YAML-LD implementation MUST apply this flag when constructing the JSON-LD internal representation from a YAML-LD stream.

If the flag is true, the internal representation MUST be an array containing the constructed value of each document in the stream, even if the stream contains only one document.
If the flag is false, only the first document in the stream MUST be constructed.

An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string.

— [JSON] §4 Objects

Consequently, all mapping keys in YAML-LD MUST be strings. Otherwise, a mapping-key-error error is raised.

This section is non-normative.

The @json keyword from JSON-LD 1.1 defines a JSON literal as a value object with @type @json and @value containing JSON data. A processor treats such a value as a JSON literal, rather than interpreting it further as JSON-LD. Consider the following example.

Example 6: JSON literal with orbital parameters for Proxima Centauri b

"@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

Consider the expanded form.

Example 7: Expanded JSON literal with orbital parameters for Proxima Centauri b

[
  {
    "@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
        }
      }
    ]
  }
]

Although the keyword is named @json, it does not require the value of @value to be written using JSON syntax in YAML-LD. As this example shows, the metadata value object is preserved during expansion in its JSON-LD form, — as this keyword mandates.

When it is converted to RDF, the JSON literal's lexical form is JSON text reconstructed from the internal representation.

This section has been submitted to the Internet Engineering Steering Group (IESG) for review, approval, and registration with IANA.

This section describes the information required to register the above media type according to [RFC6838]

Type name:

application

Subtype name:

ld+yaml

Required parameters:

N/A

Optional parameters:

profile

A non-empty list of space-separated URIs identifying specific constraints or conventions that apply to a YAML-LD stream according to [RFC6906]. A profile does not change the semantics of the resource representation when processed without profile knowledge, so that clients both with and without knowledge of a profiled resource can safely use the same representation. The profile parameter MAY be used by clients to express their preferences in the content negotiation process. If the profile parameter is given, a server SHOULD return a document that honors the profiles in the list which it recognizes, and MUST ignore the profiles in the list which it does not recognize. It is RECOMMENDED that profile URIs are dereferenceable and provide useful documentation at that URI. For more information and background please refer to [RFC6906].

This specification allows the use of the profile parameters listed in and additionally defines the following:

http://www.w3.org/ns/json-ld#extended: To request or specify the YAML-LD Extended Profile.
Editor's note
This is a placeholder for specifying something like the YAML-LD Extended Profile making use of YAML-specific features.

When used as a media type parameter [RFC4288] in an HTTP Accept header field [RFC9110], the value of the profile parameter MUST be enclosed in quotes (") if it contains special characters such as whitespace, which is required when multiple profile URIs are combined.

When processing the "profile" media type parameter, it is important to note that its value contains one or more URIs and not IRIs. In some cases it might therefore be necessary to convert between IRIs and URIs as specified in section 3 Relationship between IRIs and URIs of [RFC3987].

Encoding considerations:

Same as +yaml.

Security considerations:

See 6. Security Considerations.

Interoperability considerations:

See 8. Interoperability Considerations.

Published specification:

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

Applications that use this media type:

Any programming environment that requires the exchange of directed graphs.

Additional information:

Deprecated alias names for this type:

N/A

Magic number(s):

Same as application/yaml

File extension(s):

.yaml
.yamlld

Macintosh file type code(s):

Same as application/yaml

Windows Clipboard Name:

Same as application/yaml

Person & email address to contact for further information:

W3C JSON-LD Working Group <public-json-ld-wg@w3.org>

Intended usage:

Common

Restrictions on usage:

N/A

Author(s):

Roberto Polli, Gregg Kellogg

Change controller:

W3C

[HTML]: HTML Standard. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]: Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[JSON]: The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed. IETF. December 2017. Internet Standard. URL: https://www.rfc-editor.org/info/rfc8259/
[JSON-LD11]: JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 16 July 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld11/
[JSON-LD11-API]: JSON-LD 1.1 Processing Algorithms and API. Gregg Kellogg; Dave Longley; Pierre-Antoine Champin. W3C. 16 July 2020. W3C Recommendation. 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. 16 July 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld11-framing/
[RFC2119]: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc2119/
[RFC3986]: Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://www.rfc-editor.org/info/rfc3986/
[RFC3987]: Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc3987/
[RFC4288]: Media Type Specifications and Registration Procedures. N. Freed; J. Klensin. IETF. December 2005. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc4288/
[RFC6838]: Media Type Specifications and Registration Procedures. N. Freed; J. Klensin; T. Hansen. IETF. January 2013. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc6838/
[RFC6906]: The 'profile' Link Relation Type. E. Wilde. IETF. March 2013. Informational. URL: https://www.rfc-editor.org/info/rfc6906/
[RFC8174]: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc8174/
[RFC9110]: HTTP Semantics. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed. IETF. June 2022. Internet Standard. URL: https://httpwg.org/specs/rfc9110.html
[RFC9512]: YAML Media Type. R. Polli; E. Wilde; E. Aro. IETF. February 2024. Informational. URL: https://www.rfc-editor.org/info/rfc9512/
[YAML]: YAML Ain't Markup Language (YAML™) version 1.2.2. Oren Ben-Kiki; Clark Evans; Ingy döt Net. YAML Language Development Team. 2021-10-01. URL: https://yaml.org/spec/1.2.2/
[yaml-ld-extended-profile]: YAML-LD Extended Profile. Gregg Kellogg; Pierre-Antoine Champin; Anatoly Scherbakov. W3C. W3C Draft Group Note. URL: https://www.w3.org/TR/yaml-ld-extended-profile/

[ECMASCRIPT]: ECMAScript Language Specification. Ecma International. URL: https://tc39.es/ecma262/multipage/
[eriksson-hallberg]: Comparison between JSON and YAML for data serialization. Malin Eriksson; Victor Hallberg. KTH Royal Institute of Technology. 2011. Bachelor's thesis. URL: https://www.csc.kth.se/utbildning/kth/kurser/DD143X/dkand11/Group2Mads/Rapport_Malin_Eriksson_Viktor_Hallberg.pdf
[LINKED-DATA]: Linked Data Design Issues. Tim Berners-Lee. W3C. 27 July 2006. W3C-Internal Document. URL: https://www.w3.org/DesignIssues/LinkedData.html
[RDF11-CONCEPTS]: RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
[RFC8259]: The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed. IETF. December 2017. Internet Standard. URL: https://www.rfc-editor.org/info/rfc8259/
[TURTLE]: RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/
[URI]: Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://www.rfc-editor.org/info/rfc3986/

[TURTLE] and other Linked Data serializations which support comments

do not provide a means to preserve them when processing and serializing the document in other formats

YAML

requires that parts of the document not reflected by representation graph, such as

comments
directives
mapping key order
anchor names

must not be used to convey application level information.

Theoretically, we could try harvesting YAML comments into JSON-LD documents. We would define a specific predicate, like https://json-ld.org/yaml-ld/comment, and convert every # My comment fragment into a {"yaml-ld:comment": "My comment"} piece of the JSON-LD document.

This would, however, have the following impacts on implementations:

They would be more complicated, because most industrially available YAML parsers discard comments on reading YAML data
They would be less predictable, because order of keys is not preserved in JSON — and therefore, when converting a JSON-LD document back to YAML-LD, comments might be displaced.

YAML-LD 1.0

Abstract

Status of This Document

1. Introduction

1.1 How to read this document

1.2 Terminology

1.3 Namespace Prefixes

2. Conformance

2.1 Base Specification Versions

2.2 Test Suites

3. Basic Concepts

3.1 JSON vs YAML comparison

3.2 Goal of this specification

4. Core Requirements

4.1 Presentation

4.1.1 Encoding

4.1.2 Comments

4.1.3 Streams

4.2 Serialization

4.2.1 Anchors and Aliases

4.3 Representation

4.3.1 Scalar Value Types

4.4 Native Data Structure

4.4.1 Stream Processing

4.4.2 Mapping Key Types

4.4.3 JSON literals

5. YamlLdErrorCode

6. Security Considerations

7. Privacy Considerations

8. Interoperability Considerations

9. Embedding YAML-LD in HTML Documents

A. IANA Considerations

A.1 application/ld+yaml

B. Why are comments treated as whitespace?

B.1 Consistency

B.2 Predictability

C. Acknowledgements

C.1 In Memoriam

C.2 Contributions

D. References

D.1 Normative references

D.2 Informative references