YAML-LD 1.0

概要

[JSON-LD11] は、Linked Data [LINKED-DATA] をシリアライズするための JSON ベースの形式です。近年、[YAML] は、以前は [JSON] としてシリアライズされていた情報、 API 仕様、データスキーマ、Linked Data などを表現するための、より簡潔な形式として登場しました。

この文書は、YAML-LD を YAML 上の一連の規約として定義します。これらの規約は、JSON-LD の構文、意味論、および API に基づいて、 Linked Data を YAML としてシリアライズする方法を指定します。

YAML は、利用可能なデータ型と文書構造の両面で JSON よりも表現力が高いため ([RFC9512] を参照)、この文書は、任意の YAML-LD 文書が JSON-LD で表現できるようにするための、 YAML に対する制約を特定します。

YAML-LDはJSON-LDのデータモデルおよび処理モデルをYAMLに適用し、 Linked DataをYAML構文で記述しながら、引き続き JSON-LDとして表現できるようにします。

これは、人間およびソフトウェアエージェントによって読み書きされる文書を対象としており、大規模言語モデルに基づくものも含まれます。

YAML-LDの入門例を以下に示します。

例 1: YAML-LDの入門文書

"@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] データマークアップ言語。これは YAML-LD の基盤となる構文です
基本的な Linked Data [LINKED-DATA] の原則

この文書は主に、以下で説明する 2 つの主要な読者層を対象としています。

ソフトウェア開発者で、次のことを行いたい人 —
- YAML を使用できるさまざまなプログラミング言語で Linked Data をエンコードする
- 既存の YAML を YAML-LD に変換する
- YAML-LD の設計判断と言語構文を理解する
- YAML-LD のプロセッサーと API を実装する
- YAML 構文で Linked Data、RDF グラフ、または RDF データセットを生成または消費する
関連技術の中では、JSON-LD への理解は、ほとんどの YAML-LD 対応アプリケーションを構築するために必要です。一方、RDF への理解は、 YAML-LD を RDF グラフへ、またはその逆へ変換したい場合にのみ必要です。
IT 分野かどうかを問わないその他の専門家で、 YAML-LD 形式の Linked Data 文書を読み書きしたい人。そのような文書は —
- YAML-LD を理解できるプログラミングシステムによって消費される
- JSON-LD フレーミングアルゴリズムで変換される
- 人間と機械による利用のために Web 上で公開される
これらの利用者にとって、JSON-LD への理解は必須ではありませんが、Linked Data の原則を理解していることは有益な場合があります。

このセクションは非規範的です。

この文書では、外部仕様で定義された次の用語を使用し、 JSON-LD に固有の用語を定義します。

YAML-LD ストリームは、YAML ストリームであり、YAML-LD 文書から構成される。ディスク上または通信経路上では、YAML-LD は常にYAML-LD ストリーム（ファイルまたは HTTP 本文ごとに 1 つのストリーム）として交換され、1 つ以上のYAML-LD 文書を含む。

YAML-LD 文書とは、[JSON] への変換によって、 [LINKED-DATA] として解釈できる有効な JSON-LD 文書が生成される任意の YAML 文書です。

用語メディア型は [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 は [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	✅	✅	✅
機能
区切り記号付きの文字列、配列、オブジェクト	✅	✅	✅
区切り記号なしの文字列、配列、オブジェクト	❌	✅	✅
カスタム型	❌	タグにより✅	コアスキーマのみ
ファイル当たりの文書数	1	YAMLストリームにより⩾ 1	⩾ 1（`extractAllScripts`フラグに応じる。ストリーム処理を参照）
コメント	❌	✅	✅ 空白として扱われる
アンカーとエイリアス	❌	✅	✅ アンカー名は意味情報を持たない
循環	❌	✅	❌ 許可されない
マッピングキーの型	`string`	YAMLで表現可能な任意の型。文字列からマッピングまで	`string`

編集者注

この表の YAML-LD 版については json-vs-yaml.yamlld を参照してください。

[eriksson-hallberg]は、一部の深くネストされた文書ではYAMLが同等のJSONより大きくなる場合があるものの、より平坦な多くの文書では、人間が読みやすいまま、整形されたJSONより小さくなることを示しました。この組み合わせにより、別途圧縮されたエンコーディングを必要とせずに、大規模言語モデルやその他のソフトウェアエージェントが処理しなければならないテキスト量を削減できます。

本仕様の目的は、JSON-LD文書を YAMLとして処理および直列化し、その後、意味情報を一切失うことなくJSON-LDへ戻せるようにすることです。

これは、次の理由により常に可能です。

YAML 表現グラフは常に木を表現できる
JSONデータ型の集合は、YAMLデータ型の集合の部分集合である
JSONのエンコーディングはUTF-8である。

例1のJSON-LD直列化：

例 2：入門例と同等の JSON-LD

{
  "@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": "プロキシマ・ケンタウリのハビタブルゾーンを公転する、地球に最も近い既知の太陽系外惑星。",
  "dbp:discovered": "2016-08-24",
  "dbp:star": "dbr:Proxima_Centauri"
}

YAMLはマークアップ言語ではない（YAML™）バージョン1.2.2では、YAML処理が複数の段階として説明されており、その概要を図1に再掲します。この処理は、YAML構文による文字ストリーム（右側）と、いわゆる「ネイティブデータ構造」（左側）との間で相互に変換します。 JSON-LDでは、このデータ構造はJSON-LDの内部表現です。

この節では、YAML処理の各段階に対してYAML-LDが課す要件を、読み込み方向（図1の右から左）について説明します。ダンプは反対方向に進み、JSON互換の内部表現から、適合するYAML-LDストリームを生成します。

提示とは、図1におけるYAML文字ストリームです。

閉じたエコシステムに属さないシステム間で交換されるJSONテキストは、 UTF-8を使用して符号化されなければならない。

— [JSON] §8.1 文字エンコーディング

YAML-LDストリームはUTF-8で符号化されなければならない。それ以外の場合は、 invalid-encoding エラーを検出しなければならず、処理を中止しなければならない。

コメントは提示上の詳細であり、直列化ツリーまたは表現グラフにいかなる影響も与えてはならない。

— [YAML] §3.2.3.3 コメント

YAML-LDストリーム内のコメントは空白として扱われます。

詳細については、 YAMLとJSONの相互運用性に関する考慮事項を参照してください。

YAMLでは、マーカーによって区切られた一連の文書として、同じYAML 提示ストリームに複数の直列化ツリーを含めることができます。

— [YAML] §3.2.3 提示ストリーム

YAML-LDストリームには、以下に示すように、複数の YAML-LD文書を含めてもよい。

例 3：1つのファイルに複数の文書を含む 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

注記： YAMLストリームに関する相互運用性の考慮事項

YAMLストリームに関する相互運用性の考慮事項については、 YAML メディアタイプの該当する節を参照してください。

直列化とは、解析によって生成され（かつ提示によって消費される）、図1における順序付きツリーです。

アンカー名は直列化上の詳細であり、構成が完了すると破棄されます。

— [YAML] §3.2.2.2 アンカーとエイリアス

注記

本仕様において、アンカーとは、直列化グラフ内で同じ論理ノードを参照によって再利用するためのYAMLのノードアンカー機構（エイリアスノードを伴い、直列化では &および* を使用する）を意味します。これは、HTML ハイパーリンクまたはURLフラグメント識別子とは関係ありません。 [YAML] §6.9.2 ノードアンカーを参照してください。

したがって、アンカー名を関連情報の伝達に使用してはならず、文書の処理時に変更してもよく、 YAML-LD処理中に破棄してもよい。

アンカーは、@contextブロック内で特に有用です。複数の用語が同じ用語定義を共有する場合（たとえば、すべての IRI値プロパティ）、共有定義に一度アンカーを設定し、各用語でエイリアスとして使用することで、繰り返しを避けられます。次の例では、IRI型強制の定義に &iriとしてアンカーを設定し、3つのプロパティで再利用します。

例 4：アンカーを含む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は次のようになります。

例 5：アンカーを含む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直列化の機能である

表現とは、図1において構成によって生成されるYAMLの表現グラフです。

YAML-LD文書は、その直列化にアンカー付きノードおよびエイリアスノードを含んでもよいが、その表現グラフに循環を含めてはならない。それ以外の場合は、 loading-document-failed エラーを検出しなければならず、処理を中止しなければならない。

表現グラフを構成するとき、各エイリアスノードは、その対象アンカーによって識別されるノードへ解決されなければならない。 JSON-LDの内部表現を構築するとき、そのノードへの各参照は、ノードのコピーとして扱われなければならない。

完全な表現グラフを構成するとき、YAML-LDはスカラー型の解決に YAMLコアスキーマを使用します。 [JSON]で表現できない浮動小数点値、具体的には無限大（.inf、-.inf、+.inf）および非数（.nan）は、JSON-LDの内部表現を構築するときに loading-document-failed エラーを発生させなければならない。

YAMLコアスキーマはタイムスタンプ型を定義していません。 2018-04-01のようなスカラーはプレーン文字列に解決されます。しかし、多くのYAMLライブラリはデフォルトでYAML 1.1のタイムスタンプ解決を実装しており、このようなスカラーをネイティブの日付または日時オブジェクトへ暗黙に変換します。 YAML-LDプロセッサはこのような変換を行ってはならず、これらの値を文字列として扱わなければならない。

YAML-LDは、YAMLコアスキーマで定義されるスカラー型の解決を超えて、ノードタグに追加のJSON-LD上の意味を割り当てません。

注記：コアスキーマの型解決

次の表は、 YAMLコアスキーマおよび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数値
`0o[0-7]+`	`tag:yaml.org,2002:int`（8進数）	JSON数値
`0x[0-9a-fA-F]+`	`tag:yaml.org,2002:int`（16進数）	JSON数値
`[-+]?(\.[0-9]+\|[0-9]+(\.[0-9]*)?)([eE][-+]?[0-9]+)?`	`tag:yaml.org,2002:float`（数値）	JSON数値
`[-+]?(\.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文字列

図1において構築によって生成されるネイティブデータ構造は、JSON-LDの内部表現です。

[JSON-LD11-API]は、 HTML文書内のJSON-LDコンテンツを含む複数の <script>タグを解析できる extractAllScripts フラグを定義しています。

適合するYAML-LD実装は、YAML-LDストリームからJSON-LDの内部表現を構築するときに、このフラグを適用しなければならない。

フラグがtrueの場合、内部表現は、ストリームに文書が1つしか含まれていない場合でも、ストリーム内の各文書から構築された値を含む配列でなければならない。
フラグがfalseの場合、ストリーム内の最初の文書のみを構築しなければならない。

オブジェクト構造は、0 個以上の名前と値のペア（またはメンバー）を囲む一対の波括弧として表される。名前は文字列である。

— [JSON] §4 オブジェクト

したがって、YAML-LD のすべてのマッピングキーは string でなければなりません。そうでない場合、次の例のように mapping-key-error エラーが発生します。

例 6: 文字列ではないマッピングキー（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

この節は非規範的です。

JSON-LD 1.1の@jsonキーワードは、JSONリテラルを、 @typeが@jsonであり、JSONデータを含む@valueを持つ値オブジェクトとして定義します。プロセッサはこのような値を、 JSON-LDとしてさらに解釈するのではなく、JSONリテラルとして扱います。次の例を考えてみます。

例 7: プロキシマ・ケンタウリ 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

展開形式を考えてみます。

例 8: プロキシマ・ケンタウリ 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 ですが、YAML-LD において @value の値が JSON 構文で書かれている必要はありません。この例が示すように、メタデータの値オブジェクトは、展開時に JSON-LD 形式で保持されます — このキーワードが求めるとおりです。

RDF に変換される場合、JSON リテラルの字句形式は、 JSON テキストであり、内部表現から再構成されます。

このセクションは、レビュー、承認、および IANA への登録のために Internet Engineering Steering Group (IESG) へ提出されています。

このセクションでは、[RFC6838] に従って、上記のメディア型を登録するために必要な情報を説明します。

型名:

application

サブタイプ名:

ld+yaml

必須パラメーター:

該当なし

任意パラメーター:

profile

[RFC6906] に従って、YAML-LD ストリームに適用される特定の制約または規約を識別する、空白で区切られた URI の空でないリスト。プロファイルに関する知識なしで処理した場合でも、プロファイルはリソース表現の意味論を変更しないため、プロファイル付きリソースに関する知識を持つクライアントと持たないクライアントの双方が、同じ表現を安全に使用できる。 profile パラメーターは、コンテンツネゴシエーション処理においてクライアントがその選好を表明するために使用してもよい。 profile パラメーターが指定された場合、サーバーは、リスト内の認識するプロファイルに従う文書を返すべきであり、リスト内の認識しないプロファイルを無視 しなければならない。プロファイル URI は参照解決可能であり、その URI において有用な文書を提供することが推奨される。詳細および背景については、[RFC6906] を参照されたい。

この仕様では、に列挙された profile パラメーターの使用を許可し、さらに次を定義する。

http://www.w3.org/ns/json-ld#extended: YAML-LD 拡張プロファイルを要求または指定するため。

編集者注記

これは、YAML 固有の機能を利用する YAML-LD 拡張プロファイルのようなものを指定するためのプレースホルダーである。

[RFC4288] のメディア型パラメーターとして、 [RFC9110] のHTTP Accept ヘッダーフィールド内で使用する場合、 profile パラメーターの値に空白などの特殊文字が含まれる場合は、引用符（"）で囲まなければならない。これは、複数のプロファイル URI を組み合わせる場合に必要となる。

「profile」メディア型パラメーターを処理する場合、その値には IRI ではなく 1 つ以上の URI が含まれることに注意することが重要である。したがって、場合によっては、[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 Working Group <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（編）。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フレーミング。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（編）; M. Nottingham（編）; J. Reschke（編）。IETF。2022年6月。インターネット標準。URL：https://httpwg.org/specs/rfc9110.html
[RFC9512]: YAMLメディアタイプ。R. Polli; E. Wilde; E. Aro。IETF。2024年2月。情報提供。URL：https://www.rfc-editor.org/info/rfc9512/
[YAML]: YAMLはマークアップ言語ではない（YAML™）バージョン 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/
[eriksson-hallberg]: データ直列化における JSONとYAMLの比較。Malin Eriksson; Victor Hallberg。 KTH王立工科大学。2011年。学士論文。URL：https://www.csc.kth.se/utbildning/kth/kurser/DD143X/dkand11/Group2Mads/Rapport_Malin_Eriksson_Viktor_Hallberg.pdf
[LINKED-DATA]: 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（編）。IETF。2017年12月。インターネット標準。URL：https://www.rfc-editor.org/info/rfc8259/
[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] およびコメントをサポートするその他の Linked Data シリアライゼーション

文書を処理し、他の形式でシリアライズする際に、それらを保持する手段を提供しません

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 の比較

3.2 本仕様の目的

4. 中核要件

4.1 提示

4.1.1 符号化

4.1.2 コメント

4.1.3 ストリーム

4.2 直列化

4.2.1 アンカーとエイリアス

4.3 表現

4.3.1 スカラー値型

4.4 ネイティブデータ構造

4.4.1 ストリーム処理

4.4.2 マッピングキーの型

4.4.3 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. なぜコメントは空白として扱われるのか?