YAML-LD 1.0 W3C Working Draft 26 August 2026 More details about this document This version: https://www.w3.org/TR/2026/WD-yaml-ld-10-20260826/ Latest published version: https://www.w3.org/TR/yaml-ld-10/ Latest editor's draft: https://w3c.github.io/yaml-ld/ History: https://www.w3.org/standards/history/yaml-ld-10/ Commit history Test suite: https://w3c.github.io/yaml-ld/tests/ Editors: Anatoly Scherbakov ( Invited Expert ) Gregg Kellogg ( Invited Expert ) (until 2025-09-06), in memoriam Authors: Gregg Kellogg ( Invited Expert ) Anatoly Scherbakov ( Invited Expert ) Roberto Polli ( Par-Tec ) Feedback: GitHub w3c/yaml-ld ( pull requests , new issue , open issues ) [email protected] with subject line [yaml-ld-10] … message topic … ( archives ) Copyright © 2020-2026 World Wide Web Consortium . W3C ® liability , trademark and permissive document license rules apply. 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. Status of This Document This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index . This specification was initially developed by the JSON-LD Community Group . This document was published by the JSON-LD Working Group as a Working Draft using the Recommendation track . Publication as a Working Draft does not imply endorsement by W3C and its Members. This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress. This document was produced by a group operating under the W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy . This document is governed by the 18 August 2025 W3C Process Document . Table of Contents 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 1. Introduction 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 dbpedia.org/resource/Proxi ma_Centauri_b dbpedia.org/ontology/Planet 📅 2016-08-24 The closest known exoplanet to Earth, orbiting in Proxima Centauri’s habitable zone. dbpedia.org/resource/Proxi ma_Centauri w3.org/1999/02/22-rdf-synt ax-ns#type dbpedia.org/property/discov ered schema.org/description dbpedia.org/property/star 1.1 How to read this document 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. 1.2 Terminology 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 ]. 1.3 Namespace Prefixes 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 . 2. Conformance As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words MAY , MUST , MUST NOT , RECOMMENDED , and SHOULD in this document are to be interpreted as described in BCP 14 [ RFC2119 ] [ RFC8174 ] when, and only when, they appear in all capitals, as shown here. A YAML-LD document complies with the YAML-LD Basic profile of this specification if it follows the normative statements from this specification and can be transformed into a [ JSON-LD11 ] representation, then back to a conforming YAML-LD document, without loss of semantic information. For convenience, normative statements for documents are often phrased as statements on the properties of the document. 2.1 Base Specification Versions YAML-LD supports JSON-LD 1.1 [ JSON-LD11 ] and later. YAML-LD is based on YAML Ain't Markup Language (YAML™) version 1.2.2 [ YAML ]. YAML-LD processors MUST use a YAML 1.2 (or later, backward-compatible) implementation; see 8. Interoperability Considerations for the interoperability concerns that arise with YAML 1.1. Implementers MAY specify the YAML version in a given document by using the %YAML directive. 2.2 Test Suites To be conformant, an implementation MUST satisfy all test cases from the following test suites: YAML-LD tests (this specification); JSON-LD API tests [ JSON-LD11-API ]; JSON-LD Framing tests [ JSON-LD11-FRAMING ], ...disregarding the test cases where: processingMode option is provided and set to json-ld-1.0 . Note Since YAML is a superset of JSON , testing a YAML-LD implementation against test cases from JSON-LD test suites should be trivial. 3. Basic Concepts This section is non-normative. 3.1 JSON vs YAML comparison [ 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. 3.2 Goal of this specification 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" } 4. Core Requirements 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 . 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 . 4.1 Presentation Presentation is the YAML character stream in Figure 1 . 4.1.1 Encoding 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. 4.1.2 Comments 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. 4.1.3 Streams 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 dbpedia.org/resource/Proxi ma_Centauri_b dbpedia.org/ontology/Planet dbpedia.org/resource/Proxi ma_Centauri dbpedia.org/ontology/Star w3.org/1999/02/22-rdf-synt ax-ns#type w3.org/1999/02/22-rdf-synt ax-ns#type Note : Interoperability considerations on YAML streams For interoperability considerations on YAML streams, see the relevant section in YAML Media Type . 4.2 Serialization Serialization is the ordered tree produced by Parse (and consumed by Present ) in Figure 1 . 4.2.1 Anchors and Aliases 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 dbpedia.org/resource/Proxi ma_Centauri_b dbpedia.org/resource/Europ ean_Southern_Observatory dbpedia.org/resource/Doppl er_spectroscopy dbpedia.org/resource/Proxi ma_Centauri dbpedia.org/property/discov erySite dbpedia.org/property/discov eryMethod dbpedia.org/property/star 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 Converting a YAML-LD document with anchors or aliases to JSON-LD, and then serializing it back to YAML-LD, preserves the semantic data but is not expected to recreate the original anchors, aliases, or anchor names. 4.3 Representation 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. 4.3.1 Scalar Value Types 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 4.4 Native Data Structure The native data structure produced by Construct in Figure 1 is the JSON-LD internal representation . 4.4.1 Stream Processing [ 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. 4.4.2 Mapping Key Types 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 string s. Otherwise, a mapping-key-error error is raised, as in the following example: Example 6 : Non-string mapping key (raises mapping-key-error) "@context": - https://json-ld.org/contexts/dollar-convenience.jsonld - dbo: http://dbpedia.org/ontology/ dbp: http://dbpedia.org/property/ dbr: http://dbpedia.org/resource/ prov: http://www.w3.org/ns/prov# xsd: http://www.w3.org/2001/XMLSchema# dbp:discovered: "@type": xsd:date dbp:star: &iri "@type": "@id" prov:wasDerivedFrom: *iri { $id: dbr:Proxima_Centauri_b , $type: dbo:Planet , dbp:star: dbr:Proxima_Centauri } : dbp:discovered: 2016-08-24 prov:wasDerivedFrom: https://dbpedia.org/page/Proxima_Centauri_b 4.4.3 JSON literals 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 7 : 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 dbpedia.org/resource/Proxi ma_Centauri_b {“eccentricity“:0.11,“equilibri umTemperature“:234,“orbita lPeriod“:11.186,“semiMajor Axis“:0.0485} schema.org/additionalPrope rty Consider the expanded form. Example 8 : 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 . 5. YamlLdErrorCode The YamlLdErrorCode represents the collection of valid YAML-LD error codes, which extends the JsonLdErrorCode definitions. WebIDL enum YamlLdErrorCode { " invalid-encoding " , " mapping-key-error " , " profile-error " }; invalid-encoding The character encoding of an input is invalid. mapping-key-error A YAML mapping key was found that was not a string . profile-error The parsed YAML document contains features incompatible with the specified profile. 6. Security Considerations This section is non-normative. See Security considerations in JSON-LD 1.1 and +yaml structured syntax suffix. 7. Privacy Considerations This section is non-normative. See Privacy considerations in JSON-LD 1.1 . 8. Interoperability Considerations This section is non-normative. For general interoperability considerations on the serialization of JSON documents in [ YAML ], see YAML and the Interoperability considerations of the +yaml structured syntax suffix. The considerations and analysis provided here, including interoperability and security considerations, are based on the YAML 1.2.2 specification. Many popular YAML libraries default to YAML 1.1 parsing. YAML 1.1 implementations cause interoperability issues; in particular, the so-called "Norway problem" arises because YAML 1.1 treats no , No , NO , yes , on , off , and similar values as booleans, whereas YAML 1.2 Core Schema treats them as plain strings. YAML-LD processors that use a YAML 1.1 library will fail the conformance tests and are not compliant. 9. Embedding YAML-LD in HTML Documents YAML-LD content can be easily embedded in HTML [ HTML ] by placing it in a <script> element with the type attribute set to application/ld+yaml , as illustrated in an example below. Example 9 : YAML-LD document embedded in HTML <script type="application/ld+yaml"> "@context": 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 "@id": dbr:Proxima_Centauri_b "@type": dbo:Planet dbp:discovered: "2016-08-24" </script> dbpedia.org/resource/Proxi ma_Centauri_b dbpedia.org/ontology/Planet 📅 2016-08-24 w3.org/1999/02/22-rdf-synt ax-ns#type dbpedia.org/property/discov ered YAML syntax is indentation based. Therefore, when processing each <script> block with YAML-LD content, YAML-LD processor MUST preserve the content of the block for YAML parsing as-is , including whitespace characters. If the YAML-LD <script> tag contains a YAML Stream with multiple YAML documents , each of these documents MUST be treated as if it was included in a separate <script> tag. See Stream Processing for details. A. IANA Considerations 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 ] A.1 application/ld+yaml 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 <[email protected]> Intended usage: Common Restrictions on usage: N/A Author(s): Roberto Polli, Gregg Kellogg Change controller: W3C B. Why are comments treated as whitespace? This section is non-normative. B.1 Consistency [ 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. B.2 Predictability 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. C. Acknowledgements This section is non-normative. C.1 In Memoriam Gregg Kellogg was a central figure in the story of JSON-LD and YAML-LD. He worked tirelessly on JSON-LD and many other specifications for more than a decade, right up until his death on September 6th, 2025. Gregg's passion for solving hard problems with finesse was only exceeded by his willingness to collaborate with and encourage others in reaching that destination. The JSON-LD and broader Linked Data communities will be forever grateful for Gregg's consistent, careful, and kindly delivered contributions during their most formative years. C.2 Contributions The editors would especially like to thank the following individuals for making significant contributions to the authoring and editing of this specification: Vladimir Alexiev (Ontotext) Rob Atkinson (Open Geospatial Consortium) Pierre-Antoine Champin ( W3C ) Ted Thibodeau Jr (OpenLink Software) Benjamin Young (Digital Bazaar) Permalink Referenced in: § 1.2 Terminology § 4. Core Requirements § 4.1.1 Encoding § 4.1.2 Comments § 4.1.3 Streams § A.1 application/ld+yaml Permalink Referenced in: § Abstract § 1.2 Terminology (2) § 2. Conformance § 4.1.3 Streams § 4.3 Representation Permalink Referenced in: § 8. Interoperability Considerations Permalink exported Referenced in: Not referenced in this document. Permalink exported IDL Referenced in: § 5. YamlLdErrorCode Permalink exported IDL Referenced in: § 4.1.1 Encoding § 5. YamlLdErrorCode Permalink exported IDL Referenced in: § 5. YamlLdErrorCode Permalink exported IDL Referenced in: § 5. YamlLdErrorCode D. References D.1 Normative references [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/ D.2 Informative references [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/ ↑