JSON-LD 1.1

1.1 この文書の読み方

このセクションは規範的ではありません。

この文書は、JSONでのLinked Dataのシリアライズに関する詳細な仕様です。本書は主に次の読者を想定しています：

• JSONを扱えるさまざまなプログラミング言語でLinked Dataをエンコードしたいソフトウェア開発者
• 既存のJSONをJSON-LDに変換したいソフトウェア開発者
• JSON-LDの設計上の決定や言語構文を理解したいソフトウェア開発者
• JSON-LDのプロセッサやAPIを実装したいソフトウェア開発者
• JSON構文でLinked Data、RDF graph、またはRDF Dataset を生成／消費したいソフトウェア開発者

補助文書である JSON-LD 1.1 Processing Algorithms and API 仕様 [JSON-LD11-API] は、一般的なJSON-LD操作のための標準ライブラリインターフェースを提供することで、JSON-LD をより高いレベルで扱う方法を規定しています。

この仕様の基本を理解するには、まず JSON に精通している必要があります。これは [RFC8259] に詳述されています。

ハイパーリンクに関しては、この文書ではほぼ例外なく略語の IRI（Internationalized Resource Indicator）という用語を使用します。多くのWeb開発者は URL（Uniform Resource Locator）という用語に馴染みがあります。本書では稀にURI（Uniform Resource Indicator）という用語も使用します。これらの用語は技術コミュニティ間で混用されることが多いですが、それぞれには重要な区別があり、本仕様は常に適切な用語を使用するよう努めています。

この文書は、JSON-LD 1.0 版からの変更を強調表示できます。 変更を表示するには を選択してください。

1.2 貢献

このセクションは規範的ではありません。

この仕様の開発に参加する方法はいくつかあります：

• 技術的な議論は通常ワーキンググループのメーリングリストで行われます： public-json-ld-wg@w3.org
• ワーキンググループは #json-ld IRC チャネルを使用しており、irc.w3.org 上でリアルタイム議論が可能です。
• #json-ld IRC チャネルは irc.freenode.net 上でもリアルタイム議論が可能です。

1.3 組版規則

このセクションは規範的ではありません。

例は薄いカーキ色のボックス内に表示され、左の境界線はカーキ色で、番号付きの "Example" ヘッダーがカーキ色で表示されます。
例は常に情報提供的です。例の内容はモノスペースフォントで表示され、構文色分けされる場合があります。

例にはタブ式のナビゲーションボタンがあり、
例を他の表現に変換した結果を表示できます。

1.4 用語

このセクションは規範的ではありません。

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

1.5 設計目標と根拠

このセクションは規範的ではありません。

JSON-LD は次の設計目標を満たします：

シンプルさ

基本的な形式を使う場合、追加のプロセッサやソフトウェアライブラリは不要です。言語は開発者にとって学習曲線が非常に緩やかです。Linked Data に関心のない開発者は JSON を理解し、@context プロパティを含めて無視するだけで JSON-LD の基本機能を利用できます。

互換性

JSON-LD ドキュメントは常に有効な JSON ドキュメントです。これにより、標準的な JSON ライブラリが JSON-LD ドキュメントとシームレスに動作します。

表現力

この構文はラベル付き有向グラフをシリアライズします。これにより、ほとんどすべての現実世界のデータモデルを表現できます。

簡潔さ

JSON-LD 構文は非常に簡潔で人間に読みやすく、開発者の労力を最小限に抑えます。

ほとんどの場合のゼロ編集

JSON-LD は既存の JSON ベースのシステムからのスムーズで簡単な移行を保証します。多くの場合、JSON ドキュメントを編集せず、HTTP レスポンスに 1 行を追加するだけで十分です（§ 6.1 Interpreting JSON as JSON-LD を参照）。これにより、大規模な JSON ベースのインフラを既に展開している組織でも、日常業務に支障をきたすことなく JSON-LD の機能を利用できます。ただし、JSON をグラフ表現にマッピングすることが複雑な場合もあります。そのような場合、JSON-LD を拡張して稀なユースケースをサポートするのではなく、サポートしないことを選択しました。ゼロ編集は設計目標ですが、言語に大きな複雑さを加えずに常に可能であるとは限りません。JSON-LD は可能な限りシンプルさを重視します。

RDF として使用可能

JSON-LD は RDF の知識がなくても慣用的な JSON として開発者に使用され得ます。JSON-LD はまた RDF として利用できるため、RDF ツールと共に使用する場合には他の RDF 構文と同様に扱うことができます。JSON-LD が RDF とどのように関連するかの詳細は、セクション § 10. Relationship to RDF を参照してください。

1.6 データモデル概要

このセクションは規範的ではありません。

一般に、JSON-LD document によって記述されるデータモデルは、ラベル付きの有向 graph です。グラフは nodes を含み、それらは有向弧で接続されます。ノードはプロパティを持つ resource であるか、またはそれらのプロパティのデータ値（strings、numbers、typed values（日付や時刻など）、および IRIs）のいずれかです。

有向グラフ内では、ノードは resources であり、無名（IRI によって識別されない）である場合があり、これを blank nodes と呼び、blank node identifier で識別されることがあります。これらの識別子は JSON のような木構造を用いて完全に接続されたグラフを表現する際に必要となることがありますが、それ自体に本質的な意味はありません。文字列や数値などのリテラル値も resources と見なされ、JSON-LD は node objects と value objects を区別して異なる種類の resource を区別します。

この単純なデータモデルは非常に柔軟で強力であり、ほとんどあらゆる種類のデータをモデル化できます。データモデルの詳細な説明については、セクション § 8. Data Model を参照してください。

Linked Data 技術に慣れた開発者は、このデータモデルが RDF Data Model として認識されるでしょう。JSON-LD と RDF がどのように関連するかの詳細はセクション § 10. Relationship to RDF を参照してください。

表面的には、JSON-LD document は単に JSON です。コアデータ構造を記述する目的では、これは arrays、maps（解析された JSON Object の版）、strings、numbers、booleans、および null に限定されます。これを JSON-LD internal representation と呼びます。これは、表面上の構文が JSON 以外であっても、同等のコアデータ構造にマップする場合に同じアルゴリズムで操作できることを可能にします。

1.7 構文トークンとキーワード

このセクションは規範的ではありません。

JSON-LD は言語の中核をなす多数の構文トークンと keywords を定めています。キーワードの規範的な記述は § 9.16 Keywords にあります。

:

compact IRIs を使用する JSON のキーと値の区切り記号です。

@base

文書に対して相対的に解釈される相対 IRI 参照を解決するための基準となる base IRI を設定するために使用されます。詳細は § 4.1.3 Base IRI を参照してください。

@container

term のデフォルトコンテナタイプを設定するために使われます。関連する説明は複数のセクションで行われています（Value Ordering、Data Indexing、Language Indexing、Node Identifier Indexing、Node Type Indexing、Named Graphs、Named Graph Indexing、Named Graph Data Indexing 等）。

@context

JSON-LD ドキュメント全体で使用される短縮名（terms）を定義するために使用されます。詳細は § 3.1 The Context を参照してください。

@direction

typed values でない JSON-LD value（例：strings や language-tagged strings）の base direction を設定するために使用されます。詳細は § 4.2.4 String Internationalization を参照してください。

@graph

graph を表現するために使用されます。詳細は § 4.9 Named Graphs を参照してください。

@id

ドキュメント内で記述される node objects を IRI または blank node identifier で一意に識別するために使用されます。詳細は § 3.3 Node Identifiers を参照してください。node reference は @id のみを含む node object で、文書内の他の場所にある node object を参照する可能性があります。

@import

context definition 内で外部の context を読み込み、包含する context definition とマージするために使用されます。これにより JSON-LD 1.0 の contexts に JSON-LD 1.1 の機能を追加できます。

@included

トップレベルの node object 内で included block を定義し、別の node object 内に二次的な node objects を含めるために使用されます。

@index

コンテナが情報を索引化するために使われ、処理が JSON データ構造の深部へ継続することを示します。詳細は Data Indexing セクションを参照してください。

@json

@json は JSON literal の @type 値として使用されます。詳細は § 4.2.2 JSON Literals を参照してください。

@language

特定の文字列値の言語、または JSON-LD ドキュメントのデフォルト言語を指定するために使用されます。詳細は § 4.2.4 String Internationalization を参照してください。

@list

順序付きのデータ集合を表現するために使用されます。詳細は § 4.3.1 Lists を参照してください。

@nest

node object のプロパティをグループ化するために使用されるプロパティを定義しますが、それ自体はグラフのエッジではありません。

@none

index map、id map、language map、type map 等で index 値として使用され、索引化対象のノードが該当する機能を持たない場合に用いられます。

@prefix

true の場合、その term をコンパクト化時に compact IRI を構築するために使用できます。false の場合は compact IRI の構築に使用されません。compact IRIs を展開する際にその term を考慮するかどうかも決定します。

@propagate

context definition 内でその context のスコープを変更するために使用されます。デフォルトは true で、context が node objects 間で伝播することを意味します。false に設定すると、新しい node object に入るときにその context 内で作成された term definitions が削除されます。

@protected

context の term definitions が他の contexts によって上書きされるのを防ぎます。詳細は Protected Term Definitions セクションを参照してください。

@reverse

逆プロパティを表現するために使用されます。詳細は Reverse Properties セクションを参照してください。

@set

順序のないデータ集合を表現し、値が常に配列として表現されることを保証するために使用されます。詳細は Sets セクションを参照してください。

@type

ノードの型または typed value のデータ型を設定するために使用されます。詳細は Specifying the Type（§ 3.5）および Typed Values（§ 4.2.1）を参照してください。

Note

@type を node objects と value objects 両方の型を定義するために使用することは、リテラル値や複雑なリソースの両方に型付けする基本的なニーズに対応します。専門家は @type の多用途性を懸念するかもしれませんが、Web 開発者による長年の利用はそれによる誤用を招いていないことに注意してください。

@value

グラフ内の特定のプロパティに関連するデータを指定するために使用されます。文字列の国際化や typed values に関する詳細は該当セクションを参照してください。

@version

context definition 内で processing mode を設定するために使用されます。本仕様で導入された JSON-LD 1.0 以降の新機能は、processing mode が明示的に json-ld-1.0 に設定されている場合は利用できません。

Note

context definition 内では @version は特定の値 1.1 を取ります（文字列の "json-ld-1.1" ではありません）。JSON-LD 1.0 プロセッサは文字列値を受け入れる可能性がありますが、数値値を拒否するためです。

Note

@version の値として 1.1 を使用することは JSON-LD 1.1 に関連していることを意図していますが、Semantic Versioning の要件に従っているわけではありません。

@vocab

共通のプレフィックスを用いて @type 内のプロパティや値を展開するために使用されます。詳細は Default Vocabulary セクションを参照してください。

JSON-LD におけるすべてのキー、keywords、および値は大文字小文字を区別します。

3.1 コンテキスト

この節は情報提供的です。

人と人がコミュニケーションする際、会話は通常共有された環境（「会話のコンテキスト」）の中で行われます。この共有コンテキストにより、共通の友人のファーストネームのようなショートカット用語を使っても正確さを失わずに素早くやり取りできます。JSON-LD のコンテキストも同様に機能します。コンテキストにより、2 つのアプリケーションがショートカット用語を使って効率的に通信しつつ、正確さを保てるようになります。

簡単に言えば、context は terms を IRIs にマッピングするために使われます。Terms は大文字小文字を区別し、予約された JSON-LD の keywords でない限り、ほとんどの有効な strings を term として使用できます。例外は空文字列 "" と、キーワードの形式（つまり先頭が "@" で続く 1 つ以上の ALPHA 文字からなる文字列）を持つ文字列であり、これらは term として使用してはなりません。また ":" を含むなど IRI の形式を持つ文字列も term として使用すべきではありません。

前節のサンプルドキュメントでは、context は次のようになります：

{
  "@context": {
    "name": "http://schema.org/name",
    ↑ This means that 'name' is shorthand for 'http://schema.org/name'
    "image": {
      "@id": "http://schema.org/image",
      ↑ This means that 'image' is shorthand for 'http://schema.org/image'
      "@type": "@id"
      ↑ This means that a string value associated with 'image'
        should be interpreted as an identifier that is an IRI
    },
    "homepage": {
      "@id": "http://schema.org/url",
      ↑ This means that 'homepage' is shorthand for 'http://schema.org/url'
      "@type": "@id"
      ↑ This means that a string value associated with 'homepage'
        should be interpreted as an identifier that is an IRI 
    }
  }
}

上の context が示すように、term definition の値は単純な文字列（term を IRI にマップする）であるか、または map であり得ます。

context はキー @context をもつ entry を用いて導入され、node object や value object の中に現れることがあります。

もし entry が term をキーとして map 値を持つ場合、その map は expanded term definition と呼ばれます。上の例では、image と homepage の値が文字列であれば IRI として解釈されることを指定しています。Expanded term definitions はまた、用語を index maps に使用したり、配列値が sets として解釈されるか lists として解釈されるかを指定したりできます。展開された term definitions はキーとして IRI または compact IRIs を使って定義することができ、これは主に IRI や compact IRI に型や言語情報を関連付けるために使われます。

Contexts はドキュメント内に直接埋め込む（embedded context）ことも、URL で参照することもできます。もし前の例のコンテキストドキュメントが https://json-ld.org/contexts/person.jsonld で取得可能であれば、それを参照する一行を追加するだけで JSON-LD ドキュメントをはるかに簡潔に表現できます。次の例をご覧ください：

参照されるコンテキストは、Schema.org ボキャブラリ内で用語がどのように IRI にマップされるかを指定するだけでなく、homepage と image に関連する文字列値が IRI として解釈可能であること（"@type": "@id"、詳細は § 3.2 IRIs を参照）を指定します。これにより、開発者はサイトごとにデータの相互運用性について合意することなく互いのデータを再利用できます。外部の JSON-LD コンテキストドキュメントは @context キーの外にある用語に関するドキュメントなどの追加情報を含む場合がありますが、外部コンテキストドキュメントとして使用される場合、その @context の外側にある情報は無視されます。

リモートコンテキストは相対 URL を使って参照することもでき、その解決は参照を含むドキュメントの位置に対して行われます。例えばドキュメントが http://example.org/document.jsonld にあり、相対参照として context.jsonld を含む場合、参照されるコンテキストドキュメントは http://example.org/context.jsonld に存在します。

{
  "@context": "context.jsonld",
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "image": "http://manu.sporny.org/images/manu.png"
}

JSON ドキュメントは、context を HTTP Link Header を使って参照することで、修正することなく JSON-LD として解釈できます（詳細は § 6.1 Interpreting JSON as JSON-LD を参照）。また、JSON-LD 1.1 API を使ってカスタムコンテキストを適用することも可能です。

JSON-LD ドキュメント では、contexts をインラインで指定することもできます。これにより、ウェブへの接続がない場合でもドキュメントを処理できる利点があります。最終的にはモデリング上の判断であり、ユースケースに応じた取り扱いが必要です。リモートコンテキストの使用に関する議論は Security Considerations を § C. IANA Considerations で参照してください。

この節は JSON-LD コンテキストの最も基本的な機能のみを扱っています。コンテキストは indexed values、順序付き値、ネストされたプロパティ のようなより複雑な JSON データ構造の解釈にも役立ちます。コンテキストに関連する高度な機能は § 4. Advanced Concepts で扱われます。

3.2 IRIs

この節は情報提供的です。

IRIs（Internationalized Resource Identifiers） は Linked Data にとって基本的であり、ほとんどの nodes や properties がこれによって識別されます。JSON-LD では、IRIs は IRI reference として表現されることがあります。IRIs は [RFC3987] において、scheme、path、およびオプションの query と fragment セグメントを含むものとして定義されています。相対 IRI 参照 は別の IRI に対して相対的な IRI 参照です。JSON-LD では以下に述べる例外を除き、すべての相対 IRI 参照は base IRI を基準に解決されます。

string は、キーが @id の map entry の値である場合に IRI として解釈されます：

{
  ...
  "homepage": { "@id": "http://example.com/" }
  ...
}

IRI として解釈される値は、相対 IRI 参照 としても表現できます。例えば、次のドキュメントが http://example.com/about/ にある場合、相対参照 ../ は http://example.com/ に展開されます（相対 IRI 参照がどこで使えるかの詳細については § 9. JSON-LD Grammar を参照してください）。

{
  ...
  "homepage": { "@id": "../" }
  ...
}

IRIs はキーの位置に直接書くこともできます。例えば：

{
  ...
  "http://schema.org/name": "Manu Sporny",
  ...
}

上の例では、キー http://schema.org/name は IRI として解釈されます。

term が active context 内で定義されている場合、そのキーが term と一致すると、term から IRI への展開が行われます。

上の例のように、JSON キーが IRI に展開されない場合（例: status）は、そのキーは Linked Data ではないため処理時に無視されます。

もし特定の term やプロパティ IRI に対して 型の強制（coercion） ルールが @context 内で指定されている場合、文字列から IRI が生成されます：

上の例では、値 http://manu.sporny.org/ が JSON の string として表現されているため、型の強制ルールによりデータ処理時にその値は IRI に変換されます。詳細は § 4.2.3 Type Coercion を参照してください。

まとめると、IRIs は JSON-LD 内でさまざまな方法で表現できます：

1. Map entries でキーが term にマップされている場合、（context definition の外では）そのキーは IRI に展開されます。
2. @id または @type を使って指定された文字列値については IRI が生成されます。
3. @type キーが @id または @vocab を値に持つような型の強制ルール（coercion）があるキーの文字列値についても IRI が生成されます。

この節では JSON-LD における IRI に関する最も基本的な機能のみを扱いました。IRI に関連する高度な機能は § 4. Advanced Concepts で扱われます。

3.3 ノード識別子

この節は情報提供的です。

RDF グラフ内のノードを外部から参照できるようにするためには、ノードに識別子があることが重要です。IRIs は Linked Data の基本概念であり、ノードが真にリンクされるためには識別子をデリファレンスするとそのノードの表現が得られるべきです。これによりアプリケーションはそのノードに関する追加情報を取得できます。

JSON-LD では、ノードは @id キーワードを使って識別されます：

上の例には、node object が http://me.markus-lanthaler.com/ という IRI によって識別されています。

この節では JSON-LD におけるノード識別子に関する最も基本的な機能のみを扱います。ノード識別子に関連する高度な機能は § 4. Advanced Concepts で扱われます。

3.5 型の指定

この節は情報提供的です。

Linked Data では、グラフノードの型を指定することが一般的です。多くの場合、これは特定の node object 内で使用されるプロパティや、ノードが値であるプロパティに基づいて推論できます。例えば schema.org ボキャブラリでは givenName プロパティは Person と関連付けられています。したがって、もし node object に givenName が含まれていれば、そのノードの型は Person であると推論できます。@type を明示的に用いることでその関連を明確にできます。

特定のノードの型は @type キーワードを使って指定できます。Linked Data では型は IRI によって一意に識別されます。

配列を用いることで、ノードに複数の型を割り当てることもできます：

@type キーの値は、term（active context 内で定義された）であることもできます：

ノードの型を設定することに加え、@type は値の型を設定して typed value を作成するためにも使えます。この用途における @type の使用は、ノードオブジェクトの型指定に似ていますが、value objects は単一の型のみを持つ制約があります。typed values の使用については § 4.2.1 Typed Values を参照してください。

typed values は展開された term definition 内で @type を指定することで暗黙的に定義することもできます。これは § 4.2.3 Type Coercion で詳述されています。

4.1 高度なコンテキストの使用

この節は規範的ではありません。

セクション § 3.1 The Context では JSON-LD が機能するための基本が導入されました。本節では context の基本原則を拡張し、より高度なユースケースが JSON-LD を用いてどのように実現できるかを示します。

一般に、コンテキストはmap が定義されるときにいつでも使用できます。直接別のコンテキスト定義の子として（expanded term definition の一部としている場合を除き）コンテキストを表現できない唯一の場面です。例えば、JSON-LD document はひとつ以上の array から構成される形式を取り得て、それぞれのトップレベルの node object でコンテキスト定義を使用することがあります：

外側の配列は expanded document form および flattened document form におけるドキュメントの標準形であり、ノード同士が相互参照しない切断されたグラフを記述する際に必要となる場合があります。そのような場合、トップレベルの map に @graph プロパティを用いることで @context の繰り返しを避けるのに便利です。詳細は § 4.5 Embedding を参照してください。

コンテキストの重複する terms は、 最も最近定義されたものが優先される（most-recently-defined-wins）メカニズムによって上書きされます。

上の例では、より深いネストされた details 構造内で name の term が上書きされており、その構造は自身の embedded context を使用しています。これは通常は良い作成手法ではなく、既存の（レガシーな）アプリケーションが特定の map 構造に依存している場合に典型的に使用されます。もしコンテキスト内で term が再定義されると、その以前の定義に関連するすべてのルールは削除されます。もし term が null に再定義された場合、その用語は有効な active context に定義された terms のリストから実質的に除外されます。

複数のコンテキストは array を使って結合でき、配列は順番に処理されます。特定の map 内で定義されたコンテキストの集合は local contexts と呼ばれます。active context はドキュメント内部の特定の位置で有効な local contexts の蓄積を指します。local context を null に設定すると、active context を以前のコンテキストで定義されていた term definitions、default language などがない空のコンテキストに実質的にリセットします。次の例は外部コンテキストを指定し、その上に embedded context を重ねる例です：

JSON-LD 1.1 では、スコープ付きコンテキストやインポートされたコンテキストを含む、コンテキスト導入のための他のメカニズムや、用語定義の保護の新しい方法があります。そのため、最後に定義されたインラインコンテキストが必ずしも用語のスコープを定義するものではない場合があります。詳細は § 4.1.8 Scoped Contexts、§ 4.1.9 Context Propagation、§ 4.1.10 Imported Contexts、および § 4.1.11 Protected Term Definitions を参照してください。

{
  "@context": {
    "@version": 1.1,
    ...
  },
  ...
}

{
  "@context": {
    "label": "http://www.w3.org/2000/01/rdf-schema#label"
  },
  "@id": "",
  "label": "Just a simple document"
}

{
  "@context": {
    "@version": 1.1,
    "@base": "http://example/document",
    "@vocab": "#"
  },
  "@id": "http://example.org/places#BrewEats",
  "@type": "Restaurant",
  "name": "Brew Eats"
  ...
}

[{
  "http://example.com/vocab/property": [{"@value": "property"}],
  "http://example.com/vocab/propertyOne": [{"@value": "propertyOne"}]
}]

{
  "@context": {
    "vocab": "http://example.com/vocab/",
    "property": "http://example.com/vocab/property"
  }
}

{
  "@context": {
    "@version": 1.1,
    "vocab": "http://example.com/vocab/",
    "property": {
      "@id": "http://example.com/vocab/property",
      "@prefix": true
    }
  }
}

{
  "@context": {
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "http://xmlns.com/foaf/0.1/name",
    "age": {
      "@id": "http://xmlns.com/foaf/0.1/age",
      "@type": "xsd:integer"
    },
    "homepage": {
      "@id": "http://xmlns.com/foaf/0.1/homepage",
      "@type": "@id"
    }
  },
  ...
}

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "foaf:name",
    "age": {
      "@id": "foaf:age",
      "@type": "xsd:integer"
    },
    "homepage": {
      "@id": "foaf:homepage",
      "@type": "@id"
    }
  },
  ...
}

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "foaf:name",
    "foaf:age": {
      "@id": "http://xmlns.com/foaf/0.1/age",
      "@type": "xsd:integer"
    },
    "foaf:homepage": {
      "@type": "@id"
    }
  },
  ...
}

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "foaf:name",
    "foaf:age": {
      "@id": "http://xmlns.com/foaf/0.1/age",
      "@type": "xsd:integer"
    },
    "foaf:homepage": {
     "@id": "http://schema.org/url",
     "@type": "@id"
    }
  },
  ...
}

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "foaf:name",
    "foaf:age": {
      "@id": "http://xmlns.com/foaf/0.1/age",
      "@type": "xsd:integer"
    },
    "http://xmlns.com/foaf/0.1/homepage": {
      "@type": "@id"
    }
  },
  ...
}

{
  "@context": {
    "term1": "term2:foo",
    "term2": "term1:bar"
  },
  ...
}

{
  "@context": {
    "@version": 1.1,
    "@vocab": "http://example.com/vocab/",
    "property": {
      "@id": "http://example.com/vocab/property",
      "@context": {
        "term1": "http://example.com/vocab/term1"
         ↑ "property" のスコープ付きコンテキストは term1 を定義
      }
    },
    "Type1": {
      "@id": "http://example.com/vocab/Type1",
      "@context": {
        "term3": "http://example.com/vocab/term3"
         ↑ "Type1" のスコープ付きコンテキストは term3 を定義
      }
    },
    "Type2": {
      "@id": "http://example.com/vocab/Type2",
      "@context": {
        "term4": "http://example.com/vocab/term4"
         ↑ "Type2" のスコープ付きコンテキストは term4 を定義
      }
    }
  },
  "property": {
    "@context": {
      "term2": "http://example.com/vocab/term2"
         ↑ 埋め込みコンテキストは term2 を定義
    },
    "@type": ["Type2", "Type1"],
    "term1": "a",
    "term2": "b",
    "term3": "c",
    "term4": "d"
  }
}

{
  "@context": {
    "@vocab": "http://example.com/vocab/",
    "property": "http://example.com/vocab/property",
    "Type1": "http://example.com/vocab/Type1",
    "Type2": "http://example.com/vocab/Type2"
  },
  "property": {
    "@context": [{
        "term1": "http://example.com/vocab/term1"
         ↑ 以前のスコープ付きコンテキスト（property）が term1 を定義
      }, {
        "term2": "http://example.com/vocab/term2"
         ↑ 埋め込みコンテキストが term2 を定義
      }, {
        "term3": "http://example.com/vocab/term3"
         ↑ 以前のスコープ付きコンテキスト（Type1）が term3 を定義
      }, {
      "term4": "http://example.com/vocab/term4"
         ↑ 以前のスコープ付きコンテキスト（Type2）が term4 を定義
    }],
    "@type": ["Type2", "Type1"],
    "term1": "a",
    "term2": "b",
    "term3": "c",
    "term4": "d"
  }
}

{
  "@context": {
    "Type1": "http://example.com/vocab/Type1",
    "Type2": "http://example.com/vocab/Type2",
    "term1": "http://example.com/vocab#term1",
    "term2": "http://example.com/vocab#term2",
    ...
  }
}

{
  "@context": {
    "@version": 1.1,
    "MyType": {
      "@id": "http://example.com/vocab#MyType",
      "@context": {
        "@version": 1.1,
        "@import": "https://json-ld.org/contexts/remote-context.jsonld",
        "@propagate": true
      }
    }
  }
}

{
  "@context": {
    "@version": 1.1,
    "MyType": {
      "@id": "http://example.com/vocab#MyType",
      "@context": {
        "@version": 1.1,
        "Type1": "http://example.com/vocab/Type1",
        "Type2": "http://example.com/vocab/Type2",
        "term1": "http://example.com/vocab#term1",
        "term2": "http://example.com/vocab#term2",
        ...
        "@propagate": true
      }
    }
  }
}

{
  "@context": {
    "@version": 1.1,
    "@import": "https://json-ld.org/contexts/remote-context.jsonld",
    "@vocab": "http://example.org/vocab#",
     ↑ これは処理前に既存の @vocab 定義を置き換えます
    "term1": {
      "@id": "http://example.org/vocab#term1",
      "@type": "http://www.w3.org/2001/XMLSchema#integer"
    }
     ↑ これは処理前に古い term1 定義を置き換えます
  }
}

{
  "@context": {
    "@version": 1.1,
    "Type1": "http://example.com/vocab/Type1",
    "Type2": "http://example.com/vocab/Type2",
    "term1": {
      "@id": "http://example.org/vocab#term1",
      "@type": "http://www.w3.org/2001/XMLSchema#integer"
    },
     ↑ 注意: term1 は処理前に置き換えられています
    "term2": "http://example.com/vocab#term2",
    ...,
    "@vocab": "http://example.org/vocab#"
  }
}

{
  "@context": [
    {
      "@version": 1.1,
      "Person": "http://xmlns.com/foaf/0.1/Person",
      "knows": "http://xmlns.com/foaf/0.1/knows",
      "name": {
        "@id": "http://xmlns.com/foaf/0.1/name",
        "@protected": true
      }
    },
    {
      – この試みはエラーになり失敗します
      "name": "http://schema.org/name"
    }
  ],
  "@type": "Person",
  "name": "Manu Sporny",
  "knows": {
    "@context": [
      – この試みもエラーで失敗します
      null,
      "http://schema.org/"
    ],
    "name": "Gregg Kellogg"
  }
}

4.2 値の記述

この節は情報提供的です。

値とは文字列、日付、時刻などのスカラー値に対応するグラフの葉ノードです（strings やその他の原子的な値を含みます）。

{
  ...
  "@id": "http://example.org/posts#TripToWestVirginia",
  "@type": "http://schema.org/BlogPosting",  ← これはノード型です
  "http://purl.org/dc/terms/modified": {
    "@value": "2010-05-29T14:17:39+02:00",
    "@type": "http://www.w3.org/2001/XMLSchema#dateTime"  ← これは値の型です
  }
  ...
}

{
  "@context": {
    ...
    "@version": 1.1,
    "@vocab": "http://example.com/",
    "@language": "ja",
    "details": {
      "@context": {
        "@language": null
      }
    }
  },
  "name": "花澄",
  "details": {"occupation": "Ninja"}
}

{
  "@context": {
    ...
    "ex": "http://example.com/vocab/",
    "@language": "ja",
    "name": { "@id": "ex:name", "@language": null },
    "occupation": { "@id": "ex:occupation" },
    "occupation_en": { "@id": "ex:occupation", "@language": "en" },
    "occupation_cs": { "@id": "ex:occupation", "@language": "cs" }
  },
  "name": "Yagyū Muneyoshi",
  "occupation": "忍者",
  "occupation_en": "Ninja",
  "occupation_cs": "Nindža",
  ...
}

{
  "@context": {
    ...
    "occupation": { "@id": "ex:occupation", "@container": "@language" }
  },
  "name": "Yagyū Muneyoshi",
  "occupation": {
    "ja": "忍者",
    "en": "Ninja",
    "cs": "Nindža"
  }
  ...
}

{
  "@context": {
    ...
    "@language": "ja"
  },
  "name": "花澄",
  "occupation": {
    "@value": "Scientist",
    "@language": "en"
  }
}

{
  "@context": {
    ...
    "@language": "ja"
  },
  "name": {
    "@value": "Frank"
  },
  "occupation": {
    "@value": "Ninja",
    "@language": "en"
  },
  "speciality": "手裏剣"
}

{
  "@context": {
    ...
    "@version": 1.1,
    "@vocab": "http://example.com/",
    "@language": "ar-EG",
    "@direction": "rtl",
    "details": {
      "@context": {
        "@direction": null
      }
    }
  },
  "title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
  "details": {"genre": "Technical Publication"}
}

{
  "@context": {
    ...
    "@version": 1.1,
    "@language": "ar-EG",
    "@direction": "rtl",
    "ex": "http://example.com/vocab/",
    "publisher": { "@id": "ex:publisher", "@direction": null },
    "title": { "@id": "ex:title" },
    "title_en": { "@id": "ex:title", "@language": "en", "@direction": "ltr" }
  },
  "publisher": "مكتبة",
  "title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
  "title_en": "HTML and CSS: Design and Build Websites",
  ...
}

{
  "@context": {
    ...
    "@language": "ar-EG",
    "@direction": "rtl"
  },
  "title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
  "author": {
    "@value": "Jon Duckett",
    "@language": "en",
    "@direction": null
  }
}

4.3 値の順序付け

この節は情報提供的です。

JSON-LD の作成者は、配列を使って複数の値を簡潔に表現できます。グラフはノード間のリンクの順序を記述しないため、JSON-LD の配列はデフォルトで含まれる要素の順序を意味しません。これは、通常の JSON 配列（デフォルトで順序がある）の振る舞いとは正反対です。例えば次の簡単なドキュメントを考えてみてください：

複数の値は展開形式を使って表現することもできます：

プロパティの複数値は通常同じ型ですが、JSON-LD はこれを制限しないため、異なる型の値を持つこともできます：

{
  "type": "Feature",
  "bbox": [-10.0, -10.0, 10.0, 10.0],
  "geometry": {
    "type": "Polygon",
    "coordinates": [
        [
            [-10.0, -10.0],
            [10.0, -10.0],
            [10.0, 10.0],
            [-10.0, -10.0]
        ]
    ]
  }
  //...
}

{
  "@context": {
    "@version": 1.1,
    "@type": {"@container": "@set"}
  },
  "@type": ["http:/example.org/type"]
}

4.5 埋め込み

この節は情報提供的です。

埋め込み は、作者が ノードオブジェクト を プロパティ値として使用できる JSON-LD の機能です。これは2つのノード間に親子関係を作るために一般的に用いられます。

埋め込みを使用しない場合、ノードオブジェクト は別のノードオブジェクトの識別子を参照することでリンクされます。例えば次のようになります：

前の例は Manu と Gregg の2つの ノードオブジェクト を記述しており、knows プロパティは文字列値を識別子として扱うよう定義されています。埋め込み を使うと、Gregg のノードオブジェクトを knows プロパティの値として 埋め込む ことができます：

上記のようなノードオブジェクトは、JSON-LD ドキュメント本文内の任意の値位置で使用できます。

グラフ内のノードに識別子を付与することは推奨されますが、実用上それが難しい場合もあります。データモデルでは明示的な識別子を持たないノードを ブランクノード と呼び、JSON-LD のようなシリアライゼーションでは ブランクノード識別子 を使って表現できます。前の例では、Manu のトップレベルノードは識別子を持たず、データモデル内で記述するために識別子を持つ必要はありません。しかし Gregg から Manu への knows 関係を記述したい場合は、ブランクノード識別子（ここでは _:b0）を導入する必要があります。

ブランクノード識別子 は flattening のようなアルゴリズムによって自動導入されることがありますが、作者がそのような関係を直接記述するためにも有用です。

4.6 インデックス化された値

この節は情報提供的です。

複数のプロパティ値に対して、配列を走査するよりも直接的にアクセスする必要がある場合があります。JSON-LD は、中間の マップ を用いて特定のインデックスと関連する値を関連付けるインデックス機構を提供します。

データ インデクシング

§ 4.6.1 Data Indexing で説明されているように、データインデクシングは任意のキーでノードや値を参照できるようにします。

言語インデクシング

§ 4.6.2 Language Indexing で説明されているように、言語インデクシングは言語を文字列に関連付け、その文字列に紐づく言語として解釈されるようにします。

ノード識別子インデクシング

§ 4.6.3 Node Identifier Indexing で説明されているように、ノード識別子インデクシングはIRIでノードを参照し、そのノードの識別子として解釈されるようにします。

ノード型インデクシング

§ 4.6.4 Node Type Indexing で説明されているように、ノード型インデクシングはIRIでノードを参照し、そのノードの型として解釈されるようにします。

JSON-LD におけるその他のインデクシングの使用法については § 4.9 Named Graphs を参照してください。

4.8 逆プロパティ

この節は情報提供的です。

JSON-LD は有向のグラフをシリアライズします。つまり、すべてのプロパティはあるノードから別のノードや値へ向かって指されます。しかし場合によっては、逆方向にシリアライズすることが望ましいことがあります。例えば、人とその子供を文書内で記述したいが、使用している語彙にchildren プロパティがなく、代わりに parent プロパティしかないとします。その場合、子を表す各ノードが親へ向かうプロパティを持つように表現する必要があります。次の例を参照してください。

このようなデータは、JSON-LD の @reverse キーワード を使うとずっと簡潔に表現できます：

@reverse の キーワードは、 次の例のように、展開済み用語定義内でも使用して逆プロパティを作成できます：

4.9 名前付きグラフ

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

時には、単一のグラフ自体について、 あるいは単に個々のノードだけでなく記述する必要がある場合があります。これは、@graph キーワードを用いて一連のノードをグループ化することで行えます。開発者はまた、@graph キーワードに対して@id キーワードを組み合わせることにより、@graphで表現されたデータに名前を付けることもできます。以下の例を参照してください：

上の例は、名前付きグラフを IRI http://example.org/foaf-graphで識別していることを示します。そのグラフは Manu と Gregg に関する記述から構成されます。グラフ自体のメタデータはgeneratedAtプロパティによって表現され、グラフが生成された時刻を指定します。

JSON-LD 文書の最上位構造が、マップであり、 @graph と（省略可能な）@context以外のキーを含まない場合（IRI や キーワード にマッピングされないプロパティは無視されます）、 @graph は暗黙の デフォルトグラフを表していると見なされます。この仕組みは、文書のトップレベルに複数のノードが存在し、同じコンテキストを共有する場合（例えば文書がフラット化されている場合）に便利です。@graph キーワードはそのようなノードを配列に集め、共有コンテキストの使用を可能にします。

この場合、グラフには無関係なノードが含まれるため、埋め込みは使用できません。 これは、複数のノードオブジェクトを配列で用意し、各ノードオブジェクト内で@contextを定義するのと同等です：

4.10 文書のロード

このセクションは規範的ではありません。

JSON-LD 1.1 Processing Algorithms and API specification [JSON-LD11-API] は JSON-LD プロセッサ へのインターフェースを定義しており、さまざまな形式の JSON-LD を操作するための複数のメソッドを含んでいます（§ 5. Forms of JSON-LD を参照）。これには、参照された JSON-LD ドキュメントやリモートコンテキストの読み込み、さらには [HTML] のような他の形式から埋め込まれた JSON-LD を抽出するための一般的なメカニズムが含まれます。これについては [JSON-LD11-API] の「Remote Document and Context Retrieval」でより詳細に説明されています。

documentLoaderは、リモートドキュメントの読み込みが問題になる多くの状況で有用です：

• リモートコンテキストドキュメントは、各リクエストごとにリモートコンテキストの配信元に過度の負荷をかけないようキャッシュされるべきです。通常は HTTP のキャッシュインフラストラクチャがこれを扱うことが期待されますが、状況によってはそれが現実的でない場合があります。documentLoader 実装は、こうしたキャッシュを行うための独自のロジックを提供するかもしれません。
• 非標準の URL スキームは広く実装されていない可能性があり、あるいは特定のアプリケーション領域に固有の挙動を持つかもしれません。documentLoader によってドキュメント取得のセマンティクスを実装できます。
• 特定のよく知られたコンテキストは、documentLoader 実装内に静的にキャッシュされている場合があります。これは、埋め込みアプリケーションなど、リモートドキュメントにアクセスすることが実用的でない、あるいは不可能な場合に特に有用です。
• セキュリティ上の理由から、ドキュメントをリモートで取得する行為自体がアプリケーションの挙動の手がかりとなることがあります。documentLoader を慎重に使用することで、アプリケーションを隔離し、そのオンライン上のフィンガープリントを低減できます。

5.1 展開ドキュメント形式

このセクションは規範的ではありません。

JSON-LD 1.1 Processing Algorithms and API specification [JSON-LD11-API] は JSON-LD ドキュメントを 展開 するための方法を定義します。 Expansion は、 JSON-LD ドキュメントに context を適用し、 すべての IRI、型、および値が展開されて @context が不要になるようにするプロセスです。

たとえば、次の JSON-LD 入力ドキュメントを考えます：

{
   "@context": {
      "name": "http://xmlns.com/foaf/0.1/name",
      "homepage": {
        "@id": "http://xmlns.com/foaf/0.1/homepage",
        "@type": "@id"
      }
   },
   "name": "Manu Sporny",
   "homepage": "http://manu.sporny.org/"
}

上の JSON-LD 入力ドキュメントに対して JSON-LD の Expansion algorithm を実行すると、次のような出力が得られます：

JSON-LD のメディアタイプ は、 profile パラメータを定義しており、それによって 展開ドキュメント形式 を示したり要求したりできます。展開ドキュメント形式を示すプロファイル URI は http://www.w3.org/ns/json-ld#expanded です。

5.2 圧縮ドキュメント形式

このセクションは規範的ではありません。

JSON-LD 1.1 Processing Algorithms and API specification [JSON-LD11-API] は、 JSON-LD ドキュメントを 圧縮 するための方法を定義します。Compaction は、 開発者が提供する context を適用して、IRI を用語や コンパクト IRI に短縮し、展開形式で表現された JSON-LD の値を 文字列や数値などの単純な値に戻すプロセスです。 これにより、ドキュメントがアプリケーション固有の用語で表現され、扱いやすくなることがよくあります。圧縮されたドキュメントは人間にとっても読みやすくなります。

たとえば、次の JSON-LD 入力ドキュメントを考えます：

[
  {
    "http://xmlns.com/foaf/0.1/name": [ "Manu Sporny" ],
    "http://xmlns.com/foaf/0.1/homepage": [
      {
       "@id": "http://manu.sporny.org/"
      }
    ]
  }
]

さらに、次のような開発者提供の JSON-LD コンテキストを考えます：

{
  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": {
      "@id": "http://xmlns.com/foaf/0.1/homepage",
      "@type": "@id"
    }
  }
}

上の context を用いて、 前述の入力ドキュメントに対して JSON-LD の Compaction algorithm を実行すると、次のような出力が得られます：

JSON-LD のメディアタイプ は、 profile パラメータを定義しており、それによって 圧縮ドキュメント形式 を示したり要求したりできます。圧縮ドキュメント形式を示すプロファイル URI は http://www.w3.org/ns/json-ld#compacted です。

Compaction の詳細は [JSON-LD11-API] の Compaction algorithm に記載されています。 この節は、コンテキストを作成する著者向けのガイドとしてアルゴリズムがどのように動作するかの短い説明を提供します。

圧縮の目的は、term definitions、語彙マッピング、デフォルト言語、および base IRI を既存の JSON-LD ドキュメントに適用し、 JSON として直接使用するのに適した形式に表現することです。 これには可能な場合に値を 文字列 として表現したり、 リストオブジェクト を単純な配列に短縮したり、 ノード間の関係の向きを反転させたり、配列で表現する代わりにデータマップを使用して複数の値に索引付けすることが含まれます。

5.3 フラット化ドキュメント形式

このセクションは規範的ではありません。

JSON-LD 1.1 Processing Algorithms and API specification [JSON-LD11-API] は、 JSON-LD ドキュメントを フラット化 する方法を定義します。 Flattening は、 ノードのすべてのプロパティを単一の マップ に集め、 すべてのブランクノードにブランクノード識別子を付与します。 これによりデータの形状が保証され、特定のアプリケーションで JSON-LD を処理するために必要なコードを大幅に簡素化することがあります。

たとえば、次の JSON-LD 入力ドキュメントを考えます：

{
  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name",
    "knows": "http://xmlns.com/foaf/0.1/knows"
  },
  "@id": "http://me.markus-lanthaler.com/",
  "name": "Markus Lanthaler",
  "knows": [
    {
      "@id": "http://manu.sporny.org/about#manu",
      "name": "Manu Sporny"
    }, {
      "name": "Dave Longley"
    }
  ]
}

上の入力ドキュメントに対して JSON-LD の Flattening algorithm を同じコンテキストで実行すると、次のような出力が得られます：

JSON-LD のメディアタイプ は、 profile パラメータを定義しており、それによって フラット化ドキュメント形式 を示したり要求したりできます。フラット化ドキュメント形式を示すプロファイル URI は http://www.w3.org/ns/json-ld#flattened です。 これは 展開ドキュメント形式 や 圧縮ドキュメント形式 と組み合わせることができます。

5.4 フレームドドキュメント形式

このセクションは規範的ではありません。

JSON-LD 1.1 Framing specification [JSON-LD11-FRAMING] は、 JSON-LD ドキュメントを フレーミング する方法を定義します。Framing は、例示的な frame ドキュメントを用いてドキュメント内のデータを整形するために使用されます。 その frame は flattened データにマッチさせるために使われ、結果として得られるデータの形の例を示します。

たとえば、次の JSON-LD frame を考えます：

{
  "@context": {
    "@version": 1.1,
    "@vocab": "http://example.org/"
  },
  "@type": "Library",
  "contains": {
    "@type": "Book",
    "contains": {
      "@type": "Chapter"
    }
  }
}

この frame ドキュメントは、 型が Library のオブジェクトをトップレベルに配置し、Library オブジェクトに対して contains プロパティでリンクされた型が Book のオブジェクトをそのプロパティ値として埋め込み、 さらに型が Chapter のオブジェクトを該当の Book オブジェクト内に埋め込む構造を記述します。

フレームのコンポーネントにマッチするフラット化されたオブジェクト群を使用する場合：

{
  "@context": {
    "@vocab": "http://example.org/",
    "contains": {"@type": "@id"}
  },
  "@graph": [{
    "@id": "http://example.org/library",
    "@type": "Library",
    "contains": "http://example.org/library/the-republic"
  }, {
    "@id": "http://example.org/library/the-republic",
    "@type": "Book",
    "creator": "Plato",
    "title": "The Republic",
    "contains": "http://example.org/library/the-republic#introduction"
  }, {
    "@id": "http://example.org/library/the-republic#introduction",
    "@type": "Chapter",
    "description": "An introductory chapter on The Republic.",
    "title": "The Introduction"
  }]
}

Frame Algorithm はフレームの構造に従った新しいドキュメントを作成できます：

JSON-LD のメディアタイプ は、 profile パラメータを定義しており、それによって フレームドドキュメント形式 を示したり要求したりできます。フレームドドキュメント形式を示すプロファイル URI は http://www.w3.org/ns/json-ld#framed です。

JSON-LD のメディアタイプ はまた、 HTML ドキュメント内でフレームを含むスクリプト要素を識別するための profile パラメータも定義しています。 HTML ドキュメント内で最初に現れるタイプ application/ld+json;profile=http://www.w3.org/ns/json-ld#frame の script element はフレームを見つけるために使用されます。