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 を定義します。YAML-LD は YAML の上に構築された一連の規約であり、JSON-LD の構文、意味論、および API に基づいて、 Linked Data を YAML としてシリアライズする方法を概説します。 Linked Data を含め、以前は JSON としてシリアライズされていた情報を表現するためのより簡潔な形式として YAML が登場したことにより、 YAML-LD の開発につながりました。

方法
この文書は、任意の YAML-LD 文書を JSON-LD で表現できるようにするため、 YAML に対する制約を定義します。これは、利用可能なデータ型と文書構造の両面で、YAML が JSON よりも表現力に富むため必要です。この文書はまた、application/ld+yaml メディア型を登録します。

結果
この文書は、Linked Data を YAML でシリアライズする方法を明確に説明します。また、JSON と YAML の比較、サポートされる YAML 機能、およびエンコーディングに関する考慮事項を含め、YAML-LD を実装するための基本概念と中核要件についても説明します。

制限事項
YAML の機能セットは JSON よりも豊富であり、多くの YAML 機能はこの仕様ではサポートされていません。ただし、Extended YAML-LD Profile を通じて、それらの機能をサポートする将来の YAML-LD バージョンの開発に向けた基盤が整えられています。

結論
YAML-LD は、YAML を使用できるさまざまなプログラミング言語で Linked Data をエンコードするための効率的な方法を提供します。

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

編集者注

この仕様の YAML-LD 記述については spec.yamlld を参照してください。

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

この仕様の基本を理解するには、次の事項に精通している必要があります:

[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 文書とは、[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	✅	✅	✅
機能
区切り記号付きの文字列、配列、オブジェクト	✅	✅	✅
句読点なしの文字列、配列、オブジェクト	❌	✅	✅
カスタム型	❌	タグ経由で ✅	Core Schema のみ
ファイルあたりの文書数	1	YAML ストリーム経由で ⩾ 1	⩾ 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 文書は、[JSON] との相互運用性を確保するため、 UTF-8 でエンコードされなければなりません (MUST)。そうでない場合、 invalid-encoding が検出されなければならず (MUST)、処理は中止されます。

YAML-LD 文書内のコメントは空白として扱われます。

詳細については、"+yaml" 構造化構文接尾辞の相互運用性に関する考慮事項を参照してください。

注記

この仕様における アンカー とは、シリアライズされたグラフ内で同じ論理ノードを参照によって再利用するための YAML のノードアンカー機構 (エイリアスノードを伴い、シリアライゼーションでは & および * を使用するもの) を意味します。これは、HTML ハイパーリンクや URL フラグメント識別子とは関係ありません。 [YAML] §3.2.2.2 Anchors and Aliases および §6.9.2 Node Anchors を参照してください。

アンカー名はシリアライゼーション上の詳細であるため、そのようなアンカーは関連情報を伝えるために使用してはならず (MUST NOT)、文書の処理時に変更されてもよく (MAY)、 YAML-LD 処理中に削除されてもよいです (MAY)。

YAML-LD 文書は、アンカー付きノードおよびエイリアスノードを含んでもよいですが (MAY)、その表現グラフは循環を含んではなりません (MUST NOT)。そうでない場合、 loading-document-failed エラーが検出されなければならず (MUST)、処理は中止されます。

文書を JSON-LD として解釈する場合、エイリアスノードは、その対象ノードへの値として解決されなければなりません (MUST)。

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

例 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 シリアライゼーションの機能です

マッピングキー型は string でなければなりません (MUST)。そうでない場合、処理エラーが発生します。

YAML-LD は、スカラーの型解決に YAML Core Schema を使用します。 [JSON] で表現できない浮動小数点値 — 具体的には無限大 (.inf, -.inf, +.inf) および非数 (.nan) — は、 loading-document-failed エラーを発生させなければなりません (MUST)。

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

YAML-LD は、ノードタグに対して、 YAML Core Schema で定義されたスカラー型解決を超える追加の 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: 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

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

適合する YAML-LD 仕様は、通常の YAML-LD ストリームを解析する際にも、このフラグを考慮に入れなければなりません。

フラグが true の場合、YAML ストリームは配列とみなされ、その中の各文書は、そのストリーム内に文書が 1 つしかない場合でも、その配列内の項目になります。
フラグが false の場合、ストリーム内の最初の文書のみが処理されます。

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

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

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

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

例 6: プロキシマ・ケンタウリ 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: プロキシマ・ケンタウリ 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 パラメーターは、コンテンツネゴシエーション過程でクライアントが自身の選好を表明するために使用してもよいです (MAY)。 profile パラメーターが与えられた場合、サーバーは、リスト内の認識できるプロファイルを尊重する文書を返すべきであり (SHOULD)、認識できないリスト内のプロファイルは無視しなければなりません (MUST)。 profile URI は参照解決可能であり、その URI で有用な文書を提供することが推奨されます (RECOMMENDED)。詳細情報と背景については [RFC6906] を参照してください。

この仕様は、profile パラメーターとしてに列挙されたものの使用を許可し、さらに次を定義します:

http://www.w3.org/ns/json-ld#extended: 拡張 YAML-LD 文書形式を要求または指定するため。

編集者注

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

メディア型パラメーター [RFC4288] として、 HTTP Accept ヘッダーフィールド [RFC9110] 内で使用される場合、 profile パラメーターの値に空白などの特殊文字が含まれるなら、その値は引用符 (") で囲まれなければなりません (MUST)。これは複数の profile URI を結合する場合に必要です。

"profile" メディア型パラメーターを処理する際には、その値が 1 つ以上の URI を含み、IRI ではない点に注意することが重要です。したがって、場合によっては、[RFC3987] の第3節 IRIs と URIs の関係で指定されているように、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 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]: JavaScript Object Notation (JSON) データ交換形式. T. Bray, Ed. IETF. 2017年12月. Internet Standard. 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 Recommendation. 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 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. 2020年7月16日. W3C Recommendation. URL: https://www.w3.org/TR/json-ld11-framing/
[RFC2119]: RFC において要求レベルを示すために用いるキーワード. S. Bradner. IETF. 1997年3月. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc2119/
[RFC3986]: Uniform Resource Identifier (URI): 汎用構文. T. Berners-Lee; R. Fielding; L. Masinter. IETF. 2005年1月. Internet Standard. URL: https://www.rfc-editor.org/info/rfc3986/
[RFC3987]: Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. 2005年1月. Proposed Standard. URL: https://www.rfc-editor.org/info/rfc3987/
[RFC4288]: メディア型仕様および登録手続き. N. Freed; J. Klensin. IETF. 2005年12月. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc4288/
[RFC6838]: メディア型仕様および登録手続き. N. Freed; J. Klensin; T. Hansen. IETF. 2013年1月. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc6838/
[RFC6906]: 'profile' リンク関係型. E. Wilde. IETF. 2013年3月. Informational. URL: https://www.rfc-editor.org/info/rfc6906/
[RFC8174]: RFC 2119 キーワードにおける大文字と小文字の曖昧さ. B. Leiba. IETF. 2017年5月. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc8174/
[RFC9110]: HTTP Semantics. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed. IETF. 2022年6月. Internet Standard. 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 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 言語仕様. Ecma International. URL: https://tc39.es/ecma262/multipage/
[LINKED-DATA]: Linked Data 設計上の課題. Tim Berners-Lee. W3C. 2006年7月27日. 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. 2014年2月25日. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
[RFC8259]: JavaScript Object Notation (JSON) データ交換形式. T. Bray, Ed. IETF. 2017年12月. Internet Standard. URL: https://www.rfc-editor.org/info/rfc8259/
[RFC9512]: YAML メディア型. R. Polli; E. Wilde; E. Aro. IETF. 2024年2月. Informational. URL: https://www.rfc-editor.org/info/rfc9512/
[TURTLE]: RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 2014年2月25日. W3C Recommendation. URL: https://www.w3.org/TR/turtle/
[URI]: Uniform Resource Identifier (URI): 汎用構文. T. Berners-Lee; R. Fielding; L. Masinter. IETF. 2005年1月. Internet Standard. 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 の比較

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