JSON-LD 1.1

1.1 このドキュメントの読み方

この項は非規範的です。

このドキュメントは、リンクト・データをJSONでシリアル化するための詳細仕様です。このドキュメントは、主に次の読者を対象としています。

• JSONを使用できる様々なプログラミング言語でリンクト・データをエンコードしたいソフトウェア開発者
• 既存のJSONをJSON-LDに変換したいソフトウェア開発者
• JSON-LDの設計方針と言語構文を理解したいソフトウェア開発者
• JSON-LD用のプロセッサとAPIを実装したいソフトウェア開発者
• リンクト・データ、RDFグラフ、RDFデータセットをJSON構文で生成したり利用したりしたいソフトウェア開発者

関連ドキュメントであるJSON-LD 1.1処理アルゴリズムとAPI仕様[JSON-LD11-API]は、共通するJSON-LDの操作のための標準的なライブラリ・インターフェースを提供することにより、より高いレベルでJSON-LDを扱う方法を規定しています。

この仕様の基本を理解するためには、まず、[RFC8259]で詳細に説明されているJSONに精通していなければなりません。

このドキュメントでは、ハイパーリンクについて論じる場合には、ほぼIRI(Internationalized Resource Indicator)という用語のみを用います。多くのウェブ開発者には、URL(Uniform Resource Locator)という用語の方が馴染みがあるでしょう。このドキュメントでは、稀であるものの、URI(Uniform Resource Indicator)という用語も用います。技術コミュニティでは、これらの用語は同じ意味で用いられることが多いですが、互いに重要な差異があるため、この仕様では労を惜しまずに常に適切な用語を用いるよう努めています。

このドキュメントでは、JSON-LD 1.0バージョン以降の変更点を強調表示できます。変更のを選択してください。

1.2 貢献

この項は非規範的です。

この仕様の開発にご参加いただける方法がいくつかあります。

• 通常、技術的な議論はワーキンググループのメーリング・リストであるpublic-json-ld-wg@w3.orgで行われます。
• ワーキンググループは、irc.w3.org上のリアルタイムな議論に利用できる#json-ld IRCチャネルを用いています。
• irc.freenode.net上のリアルタイムな議論にも#json-ld IRCチャネルを利用できます。

1.3 表記上の規定

この項は非規範的です。

例は、カーキ色の左枠線と番号付きのカーキ色の「例」という見出しが付いた薄カーキ色のボックスに入っています。
例は常に参考情報です。例の内容は等幅フォントで、構文の色が付いている可能性があります。

例を他の表現に変換した結果を示すために、例にはタブ型のナビゲーション・ボタンが含まれている場合があります。

1.4 用語

この項は非規範的です。

このドキュメントでは、外部仕様で定義されている次の用語を用いるとともに、JSON-LD固有の用語も定義しています。

1.5 設計の目標と原理

この項は非規範的です。

JSON-LDは、次の設計目標を満たしています。

シンプルさ

JSON-LDを最も基本的な形式で用いるのであれば、追加のプロセッサやソフトウェア・ライブラリは不要です。この言語は、開発者に非常に簡単な学習曲線を提供します。リンクト・データに関心のない開発者がJSON-LDの基本的な機能を用いるためには、JSONを理解し、@contextプロパティーを含めつつも無視することだけを知っていれば十分です。

互換性

JSON-LDドキュメントは常に有効なJSONドキュメントです。そのため、すべての標準的なJSONライブラリは、JSON-LDドキュメントで確実にシームレスに動作します。

表現力

構文により、ラベル付き有向グラフがシリアル化されます。それにより、ほぼすべての実世界のデータ・モデルを表現できます。

簡潔さ

JSON-LD構文は非常に簡潔かつ人間が読める形式であり、開発者は最小限の労力しか求められません。

ほとんどの場合に編集不要

JSON-LDは、既存のJSONベースのシステムからのスムーズでシンプルな移行を保証します。多くの場合、JSONドキュメントは編集不要で、HTTP応答に1行追加するだけで十分です(§ 6.1 JSONをJSON-LDとして解釈を参照)。これにより、すでに大規模なJSONベースのインフラストラクチャを展開している組織は、日常の運用に支障をきたさず、現在の利用者が気付かない方法でJSON-LDの機能を使用できます。しかし、グラフ表現へのJSONのマッピングは複雑な作業になりえます。その場合には、JSON-LDを拡張して難解なユースケースをサポートするのではなく、そのユースケースはサポートしないことにしました。編集不要とすることが設計目標ですが、言語に非常に複雑な要素を追加せずに常に実現できるとは限りません。JSON-LDは、可能な場合はシンプルさを重視します。

RDFとしての使用可能性

開発者は、RDF[RDF11-CONCEPTS]を理解する必要なく、JSON-LDを慣用的なJSONとして使用できます。JSON-LDはRDFとしても使用できるため、RDFツールでJSON-LDを用いようとしている人は、他のRDF構文と同じように使用できることに気づくでしょう。JSON-LDとRDFがどのように関係しているかに関する詳細は、§ 10. RDFとの関係にあります。

1.6 データ・モデルの概要

この項は非規範的です。

一般的に言えば、JSON-LDドキュメントで記述されているデータ・モデルは、ラベル付きの有向グラフです。グラフには、有向アークで接続されたノードが含まれています。ノードは、プロパティーを持つ資源か、文字列、数値、型付き値(日付や時刻など)、IRIなどのプロパティーのデータ値のいずれかです。

有向グラフ内では、ノードは資源であり、名前がない、つまり、IRIで識別されない場合があり、これは空白ノードと呼ばれ、空白ノード識別子を用いて識別できます。この識別子は、JSONなどのツリー構造を用いて完全に接続されたグラフを表すために必要でありえますが、それ以外には本質的な意味はありません。文字列や数値などのリテラル値も資源と見なされ、JSON-LDは様々な種類の資源を区別するために、ノード・オブジェクトと値オブジェクトを区別します。

このシンプルなデータ・モデルは非常に柔軟かつ強力であり、いかなる種類のデータでもほとんどモデル化できます。データ・モデルのより深い説明については、§ 8. データ・モデルの項を参照してください。

リンクト・データの技術に精通している開発者は、データ・モデルをRDFデータ・モデルとして認識するでしょう。JSON-LDとRDFの関係についてさらに深く知りたい場合は、§ 10. RDFとの関係を参照してください。

表層レベルでは、JSON-LDドキュメントは単なるJSONであり、[RFC8259]で詳細に説明されています。コアなデータ構造を記述するために、これは、配列、マップ(JSONオブジェクトの解析済みバージョン)、文字列、数値、ブール、nullに限定されており、JSON-LD内部表現と呼ばれます。これにより、JSON以外の表層構文は、構文が同等のコアなデータ構造にマッピングされている場合に、同じアルゴリズムを用いて操作できます。

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

この項は非規範的です。

JSON-LDは、言語のコアとなるいくつかの構文トークンとキーワードを規定しています。キーワードの規範的な記述は、§ 9.16 キーワードで示しています。

:

短縮IRIを用いるJSONのキーと値の区切り記号。

@base

通常ならばドキュメントに対して相対的に解釈される相対IRI参照を解決するための基底IRIを設定するために用います。このキーワードについては、§ 4.1.3 基底IRIで説明しています。

@container

用語に対するデフォルトのコンテナ型を設定するために用います。このキーワードについては、以下の項で記述しています。

• § 4.3 値の順序付け、
• § 4.6.1 データのインデックス化、
• § 4.6.2 言語のインデックス化、
• § 4.6.3 ノード識別子のインデックス化、
• § 4.6.4 ノード型のインデックス化、
• § 4.9 名前付きグラフ、
• § 4.9.3 名前付きグラフのインデックス化、および
• § 4.9.2 名前付きグラフのデータのインデックス化

@context

JSON-LDドキュメント全体で用いる短縮名を定義するために用います。この短縮名は用語と呼ばれ、開発者が特定の識別子を短縮形で表現するのに役立ちます。@contextキーワードについては、§ 3.1 コンテキストで詳細に説明しています。

@direction

型付き値ではない(文字列や言語タグ付き文字列など)JSON-LD値の基本書字方向を設定するために用います。このキーワードについては、§ 4.2.4 文字列の国際化で説明しています。

@graph

グラフを表すために用います。このキーワードについては、§ 4.9 名前付きグラフで説明しています。

@id

ドキュメントに記述されているノード・オブジェクトをIRIや空白ノード識別子で一意に識別するために用います。このキーワードについては、§ 3.3 ノード識別子で説明しています。ノード参照は、@idプロパティーのみを含んでいるノード・オブジェクトであり、ドキュメントの他の場所にあるノード・オブジェクトへの参照を表すことができます。

@import

コンテキスト定義で用いて外部コンテキストを読み込み、それに含まれているコンテキスト定義が内部に統合されます。JSON-LD 1.0のコンテキストにJSON-LD 1.1の機能を追加するのに役立ちます。

@included

最上位のノード・オブジェクトで用いて、二次的なノード・オブジェクトを別のノード・オブジェクト内に含めるための包含ブロックを定義します。

@index

情報をインデックス化するためにコンテナを用い、その処理はJSONデータ構造のより深くまで継続すべきであることを指定するために用います。このキーワードについては、§ 4.6.1 データのインデックス化で説明しています。

@json

JSONリテラルの@typeの値として用います。このキーワードについては、§ 4.2.2 JSONリテラルで説明しています。

@language

特定の文字列の値に対する言語や、JSON-LDドキュメントのデフォルト言語を指定するために用います。このキーワードについては、§ 4.2.4 文字列の国際化で説明しています。

@list

順序付きデータの集合を表すために用います。このキーワードについては、§ 4.3.1 リストで説明しています。

@nest

ノードのプロパティーをグループ化するノード・オブジェクトのプロパティーを定義するために用いますが、グラフのエッジではありません。

@none

インデックス付きのノードにインデックス化されている機能がない場合に、インデックス・マップ、idマップ、言語マップ、型マップ、その他の、値にインデックス化するためにマップを用いる場所で、インデックス値として用います。

@prefix

値がtrueの場合は、この用語を用いて短縮時に短縮IRIを構築できます。値がfalseの場合は、この用語では短縮IRIを構築できません。また、短縮IRIの展開時に用語が考慮されるかどうかも決定します。

@propagate

コンテキスト定義で用いて、そのコンテキストの範囲を変更します。これはデフォルトではtrueで、コンテキストがノード・オブジェクト全体に伝播することを意味します(デフォルトでfalseに設定される型の範囲付きコンテキストを除く)。これをfalseに設定すると、そのコンテキスト内で作成された用語定義は、新しいノード・オブジェクトの入力時に削除されます。

@protected

コンテキストの用語定義が他のコンテキストによって上書きされるのを防ぐために用います。このキーワードについては、§ 4.1.11 保護された用語定義で説明しています。

@reverse

逆プロパティーを表すために用います。このキーワードについては、§ 4.8 逆プロパティーで説明しています。

@set

順不同のデータの集合を表すため、また、値が常に配列として表されることを保証するために用います。このキーワードについては、§ 4.3.2 集合で説明しています。

@type

ノードの型または型付き値のデータ型を設定するために用います。このキーワードについては、§ 3.5 型の指定および§ 4.2.1 型付き値で詳細に説明しています。

注

@typeを用いてノード・オブジェクトと値オブジェクトの両方の型を定義することで、リテラル値や、より複雑な資源であっても、データの型付けに関する基本的なニーズに対応できます。専門家は、両方の目的のために@typeキーワードが過剰に用いられていることに気づくかもしれませんが、@typeを用いて型付きリテラル値を表す頻度ははるかに低いため、ウェブの開発者がこの機能を複数年にわたって用いても、誤用は生じていないことに注意すべきです。

@value

グラフ内の特定のプロパティーに関連付けるデータを指定するために用います。このキーワードについては、§ 4.2.4 文字列の国際化と§ 4.2.1 型付き値で説明しています。

@version

コンテキスト定義で用いて、処理モードを設定します。この仕様で記述しているJSON-LD 1.0[JSON-LD10]以後の新機能は、処理モードが明示的にjson-ld-1.0に設定されている場合には使用できません。

注

JSON-LD 1.0プロセッサは、@versionの文字列の値を受け入れることはできても、数値は拒否するため、コンテキスト定義内では@versionは"json-ld-1.1"ではなく、1.1という特定の値を取ります。

注

@versionの値に1.1を用いるのは、JSON-LD 1.0プロセッサの処理を停止させるのが目的です。これは明らかにJSON-LD 1.1に関するものですが、それ以外の点ではセマンティック・バージョニングの要件に準拠していません。

@vocab

共通する接頭辞IRIで@typeのプロパティーと値を展開するために用います。このキーワードについては、§ 4.1.2 デフォルトの語彙で説明しています。

JSON-LDのすべてのキー、キーワード、および値は、大文字と小文字を区別します。

3.1 コンテキスト

この項は非規範的です。

2人がコミュニケーションを取り合う場合、会話は「会話のコンテキスト」と通常呼ばれる共有環境で行われます。このコンテキストの共有により、共通の友人のファースト・ネームなど、省略形の用語を個々が用いて、正確さを失うことなく、より迅速にやり取りを行えます。JSON-LDのコンテキストもこれと同じように機能します。これにより、2つのアプリケーションが省略形の用語を用いて、正確さを失うことなく、より効率的にコミュニケーションを取り合えます。

シンプルに言えば、コンテキストは用語をIRIにマッピングするために用います。用語は大文字と小文字を区別し、予約済みのJSON-LDキーワードではない最も有効な文字列を用語として使用できます。例外は、空の文字列である""と、キーワードの形式を持つ文字列(つまり、"@"で始まり、1つ以上のALPHA文字([RFC5234]を参照)のみが続く文字列)で、これらを用語として用いてはなりません。IRIの形式を持つ文字列(":"を含んでいるものなど)は、用語として用いるべきではありません。

前項のドキュメントの例の場合、コンテキストは次のようになります。

{
  "@context": {
    "name": "http://schema.org/name",
    ↑ これは「name」が「http://schema.org/name」の省略形であることを意味します。
    "image": {
      "@id": "http://schema.org/image",
      ↑ これは「image」が「http://schema.org/image」の省略形であることを意味します。
      "@type": "@id"
      ↑ これは、「image」に関連付けられている文字列値が
        IRIである識別子として解釈されるべきであることを意味します。
    },
    "homepage": {
      "@id": "http://schema.org/url",
      ↑ これは、「homepage」が「http://schema.org/url」の省略形であることを意味します。
      "@type": "@id"
      ↑ これは、「homepage」に関連付けられている文字列値が
        IRIである識別子として解釈されるべきであることを意味します。 
    }
  }
}

上記のコンテキストが示しているように、用語定義の値は、用語をIRIにマッピングしているシンプルな文字列かマップのいずれかでありえます。

コンテキストは、@contextキーを持つエントリーを用いて導入され、ノード・オブジェクトまたは値オブジェクト内に出現できます。

用語キーを持つエントリーにマップの値がある場合、そのマップは展開用語定義と呼ばれます。上記の例では、image(画像)とhomepage(ホームページ)の値が文字列の場合、それらをIRIとして解釈すべきであると指定しています。展開用語定義により、用語をインデックス・マップに用いたり、配列の値を集合やリストとして解釈すべきかどうかを指定したりすることもできます。展開用語定義は、IRIや短縮IRIをキーとして用いて定義でき、これは主に型や言語の情報をIRIや短縮IRIに関連付けるために用います。

コンテキストは、ドキュメントに直接組み込むか(組み込みコンテキスト)、URLを用いて参照することができます。前の例のコンテキスト・ドキュメントをhttps://json-ld.org/contexts/person.jsonldで取得できると仮定すると、1行追加すればそれを参照でき、以下の例で示しているように、JSON-LDドキュメントをより簡潔に表現できるようになります。

参照されているコンテキストは、Schema.org語彙で用語をIRIにどのようにマッピングするかを指定するだけでなく、homepageとimageのプロパティーに関連付けられている文字列の値がIRIとして解釈できることも指定しています("@type": "@id"。詳細は§ 3.2 IRIを参照)。この情報により、開発者は、サイトごとにデータの相互運用方法について同意する必要なく、データを相互に再利用できます。外部のJSON-LDコンテキスト・ドキュメントには、ドキュメントで宣言されている用語に関するドキュメントなど、@contextキーの外部にある追加情報を含むことができます。ドキュメントが外部のJSON-LDコンテキスト・ドキュメントとして用いられていれば、@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ドキュメントは、§ 6.1 JSONをJSON-LDとして解釈で説明しているように、HTTPリンク・ヘッダーを介してコンテキストを参照して変更する必要なく、JSON-LDとして解釈できます。また、JSON-LD 1.1 API[JSON-LD11-API]を用いてカスタマイズしたコンテキストを適用することもできます。

JSON-LDドキュメントでは、コンテキストをインラインで指定することもできます。これには、ウェブへの接続がない場合でもドキュメントを処理できるという利点があります。結局のところ、これはモデル化の判断であり、ユースケースが異なれば、異なる対応が必要になりえます。遠隔のコンテキストの使用に関する議論については、§ C. IANAに関する留意点のセキュリティに関する留意点を参照してください。

この項では、JSON-LDコンテキストの最も基本的な機能のみを扱っています。コンテキストを用いて、インデックス付きの値、順序付きの値、入れ子のプロパティーなど、他のより複雑なJSONデータ構造の解釈に役立てることもできます。JSON-LDコンテキストに関連するより高度な機能については、§ 4. 高度な概念で扱っています。

3.2 IRI

この項は非規範的です。

IRI(Internationalized Resource Identifiers[RFC3987])は、ほとんどのノードとプロパティーがこの方法で識別されるため、リンクト・データの基本です。JSON-LDでは、IRIはIRI参照として表すことができます。IRIは、スキームとともにパスやオプションのクエリとフラグメントのセグメントを含むと[RFC3987]で定義されています。相対IRI参照は、他のIRIに対して相対的なIRIです。JSON-LDでは、以下に示す例外を除いて、すべての相対IRI参照は基底IRIに対して相対的に解決されます。

文字列は、@idというキーを持つマップ・エントリーの値である場合、IRIとして解釈されます。

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

IRIとして解釈される値は、相対IRI参照として表すこともできます。例えば、次のドキュメントがhttp://example.com/about/にあると仮定すると、相対IRI参照../は、http://example.com/に展開されます(相対IRI参照を使用できる場所に関する詳細については、§ 9. JSON-LD文法を参照してください)。

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

IRIは、次のようにキーの位置で直接表すことができます。

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

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

用語からIRIへの展開は、キーがアクティブ・コンテキスト内で定義されている用語と一致する場合に発生します。

上記の例のstatusなど、IRIに展開されないJSONキーは、リンクト・データではないため、処理時に無視されます。

特定の用語やプロパティーのIRIに対して@contextで型の強制規則が指定されている場合は、IRIが生成されます。

上記の例では、http://manu.sporny.org/という値はJSONの文字列として表されているため、データを処理する際に型の強制規則によって値がIRIに変換されます。この機能の詳細については、§ 4.2.3 型の強制を参照してください。

要約すると、JSON-LDではIRIを次の様々な方法で表現できます。

1. アクティブ・コンテキストの用語へのキー・マッピングを持つマップ・エントリーは、IRIに展開されます(コンテキスト定義の外部にのみ適用される)。
2. IRIは、@idまたは@typeを用いて指定された文字列の値に対して生成されます。
3. IRIは、@idまたは@vocabの値に設定されている@typeキーを含んでいる強制規則があるキーの文字列の値に対して生成されます。

この項では、JSON-LDのIRIに関連する最も基本的な機能のみを扱っています。IRIに関するより高度な機能については、§ 4. 高度な概念の項で扱っています。

3.3 ノード識別子

この項は非規範的です。

RDFグラフ内のノードを外部参照できるようにするには、ノードが識別子を持っていることが重要です。IRIは、リンクト・データの基本的な概念であり、ノードが真にリンク付けされるためには、識別子を逆参照すると、そのノードが表されるようになるべきです。これにより、アプリケーションはノードに関する詳細情報を取得できます。

JSON-LDでは、ノードは@idキーワードを用いて識別されます。

上記の例には、http://me.markus-lanthaler.com/というIRIによって識別されるノード・オブジェクトが含まれています。

この項では、JSON-LDのノード識別子に関連する最も基本的な機能のみを扱っています。ノード識別子に関するより高度な機能については、§ 4. 高度な概念で扱っています。

3.5 型の指定

この項は非規範的です。

リンクト・データでは、グラフ・ノードの型を指定するのが一般的です。多くの場合、これは、特定のノード・オブジェクト内で用いられているプロパティーや、ノードが値であるプロパティーに基づいて推測できます。例えば、schema.org語彙では、givenName(名)プロパティーは、Person(人)に関連付けられます。したがって、ノード・オブジェクトにgivenNameというプロパティーが含まれていれば、型はPersonであると推論でき、@typeでこれを明示すると関連性が明確になります。

特定のノードの型は、@typeキーワードを用いて指定できます。リンクト・データでは、型はIRIで一意に識別されます。

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

@typeキーの値は、アクティブ・コンテキストで定義される用語にすることもできます。

ノードの型の設定に加え、@typeを用いて値の型を設定し、型付き値を作成することもできます。この@typeの使用方法は、ノード・オブジェクトの型を定義するためのものと似ていますが、値オブジェクトは1つの型しか持てないように制限されています。@typeを用いた型付き値の作成については、§ 4.2.1 型付き値でより完全に論じています。

型付き値は、展開用語定義で@typeを指定することにより、暗黙的に定義することもできます。これについては、§ 4.2.3 型の強制でより完全に扱っています。

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

この項は非規範的です。

§ 3.1 コンテキストの項では、JSON-LDが機能するための基本について紹介しました。この項では、コンテキストの基本原則を拡張し、JSON-LDを用いてより高度なユースケースを実現する方法を示します。

一般的に、コンテキストはマップが定義されていればいつでも使用できます。コンテキストを表現できないのは、(展開用語定義の一部としてではなく)別のコンテキスト定義の直接の子としてのみです。例えば、JSON-LDドキュメントは、1つ以上のノード・オブジェクトで構成される配列の形式を取ることができ、これは、それぞれの最上位のノード・オブジェクトでコンテキスト定義を用います。

外部の配列は、展開ドキュメント形式およびフラット化ドキュメント形式のドキュメントのための標準であり、ノードが相互参照を行えない、切断されたグラフを記述するときに必要になりえます。このようなケースでは、@graphプロパティーを持つ最上位のマップを用いると、@contextの繰り返しを省くのに便利でありえます。詳細については、§ 4.5 組み込みを参照してください。

重複するコンテキストの用語は、最も直近に定義されたものが有効となるメカニズムを用いて上書きされます。

上記の例では、nameという用語は、独自の組み込みコンテキストを用いている、より深い入れ子のdetails構造では上書きされます。これが良いオーサリング方法であることは稀であり、通常は、マップの特定の構造に依存する旧式アプリケーションを扱うときに用いられるものであることに注意してください。コンテキスト内で用語が再定義されると、以前の定義に関連付けられていた以前のすべての規則が削除されます。用語をnullに再定義すると、アクティブ・コンテキストで定義されている用語のリストからその用語が効果的に削除されます。

複数のコンテキストは、配列を用いて組み合わせることができ、順番に処理されます。特定のマップ内で定義されているコンテキストの集合は、ローカル・コンテキストと呼ばれます。アクティブ・コンテキストとは、ドキュメント内の特定の位置で範囲内にあるローカル・コンテキストの蓄積を意味します。ローカル・コンテキストをnullに設定すると、アクティブ・コンテキストが空のコンテキストへと効果的にリセットされ、用語定義、デフォルトの言語、または以前のコンテキスト内で定義されていたその他のものがなくなります。次の例では、外部コンテキストを指定した後に、その外部コンテキストの上に組み込みコンテキストをレイヤー状に配置しています。

JSON-LD 1.1には、範囲付きコンテキストやインポートされたコンテキストなど、コンテキストを導入する方法が他にもあり、用語定義の保護という新しい方法もあるため、最後に定義されたインラインのコンテキストが必ずしも用語の範囲を定義するものではない場合があります。詳細については、§ 4.1.8 範囲付きコンテキスト、§ 4.1.9 コンテキストの伝播、§ 4.1.10 インポートされたコンテキスト、§ 4.1.11 保護された用語定義を参照してください。

{
  "@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 値の記述

この項は非規範的です。

値は、文字列、日付、時刻、その他のアトミック値などのスカラー値に関連付けられたグラフのリーフ・ノード(leaf node)です。

{
  ...
  "@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つのノード間に親-子関係を作成するために一般的に用いられる方法です。

組み込みを行わくても、別のノード・オブジェクトの識別子を参照することによりノード・オブジェクトをリンクすることができます。例えば、次のとおりです。

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

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

グラフ内のノードを識別することがベスト・プラクティスであると考えられていますが、これが実用的でない場合もあります。データ・モデルでは、明示的な識別子のないノードを空白ノードと呼び、空白ノード識別子を用いてJSON-LDなどのシリアル化で表すことができます。前の例では、Manuの最上位ノードには識別子がなく、データ・モデル内でそれを記述する必要はありません。しかし、GreggからManuへのknows(知っている)という関係を記述したい場合は、空白ノード識別子(ここでは_:b0)を導入する必要があるでしょう。

空白ノード識別子は、フラット化(flattening)などのアルゴリズムによって自動的に導入される場合がありますが、作成者がそのような関係を直接記述するのにも有用です。

4.6 インデックス付きの値

この項は非規範的です。

複数の配列の値を繰り返すのではなく、より直接的な方法で複数のプロパティー値にアクセスする必要がある場合があります。JSON-LDは、中間マップを用いて関連する値に特定のインデックスを関連付けられるようにするインデックス化のメカニズムを提供します。

Data Indexing(データのインデックス化)

§ 4.6.1 データのインデックス化で説明しているように、データのインデックス化により、任意のキーがノードや値を参照できるようになります。

Language Indexing(言語のインデックス化)

§ 4.6.2 言語のインデックス化で説明しているように、言語のインデックス化により、言語が文字列を参照し、その文字列に関連付けられた言語として解釈できるようになります。

Node Identifier Indexing(ノード識別子のインデックス化)

§ 4.6.3 ノード識別子のインデックス化で説明しているように、ノード識別子のインデックス化により、IRIがノードを参照し、そのノードの識別子として解釈できるようになります。

Node Type Indexing(ノード型のインデックス化)

§ 4.6.4 ノード型のインデックス化で説明しているように、ノード型のインデックス化により、IRIがノードを参照し、そのノードの型として解釈できるようになります。

JSON-LDでのインデックス化のその他の使用方法については、§ 4.9 名前付きグラフを参照してください。

4.8 逆プロパティー

この項は非規範的です。

JSON-LDは有向グラフをシリアル化します。つまり、すべてのプロパティーは、あるノードから別のノードや値を指し示します。しかし、逆方向にシリアル化することが望ましい場合もあります。例えば、ある人とその子供がドキュメントに記述されているべきケースについて考えてみましょう。用いている語彙で子供のプロパティーではなく親のプロパティーのみが提供されている場合、次の例のように、子供を表すすべてのノードを、親を指し示すプロパティーを用いて表さなければなりません。

JSON-LDの@reverseキーワードを用いると、このようなデータをよりシンプルに表現できます。

次の例で示しているように、展開用語定義で@reverseキーワードを用いて逆プロパティーを作成することもできます。

4.9 名前付きグラフ

この項は非規範的です。

単なる1つのノードでなく、グラフそのものに関するステートメントを作成する必要がある場合があります。これは、@graphキーワードを用いてノードの集合をグループ化することで行えます。次の例で示しているように、開発者は、@graphキーワードを用いて表されているデータを@idキーワードとペアにすることで、それに名前を付けることもできます。

上記の例は、http://example.org/foaf-graphというIRIによって識別される名前付きグラフを表しています。そのグラフは、ManuとGreggに関するステートメントで構成されています。グラフそのものに関するメタデータは、グラフがいつ生成されたかを指定するgeneratedAtプロパティーにより表されています。

JSON-LDドキュメントの最上位構造が、@graphキーのみ(およびオプションで@context)を含むマップである場合(IRIまたはキーワードにマッピングされていないプロパティーは無視される)、@graphは、通常であれば暗黙的であるデフォルト・グラフを表していると見なされます。このメカニズムは、同じコンテキストを共有するノードがドキュメントの最上位に多数存在する場合、例えば、ドキュメントがフラット化されている場合に有用です。@graphキーワードは、そのようなノードを配列にまとめ、共有コンテキストの使用を可能にします。

このケースでは、グラフには関係付けられていないノードが含まれているため、組み込みは使用できません。これは、配列で複数のノード・オブジェクトを用い、個々のノード・オブジェクト内で@contextを定義することと同等です。

4.10 ドキュメントの読み込み

この項は非規範的です。

JSON-LD 1.1処理アルゴリズムとAPI仕様[JSON-LD11-API]は、JSON-LDプロセッサに対するインターフェースについて定義しており、様々な形式のJSON-LDを操作するための方法が多く含まれています(§ 5. JSON-LDの形式を参照)。これには、参照されているJSON-LDドキュメントと遠隔のコンテキストを含む、遠隔のドキュメントを読み込むためのメカニズムと、潜在的に[HTML]などの他の形式から組み込まれているJSON-LDを抽出するための一般的なメカニズムが含まれます。これについては、[JSON-LD11-API]の遠隔のドキュメントとコンテキストの取得でより完全に説明しています。

documentLoaderは、遠隔のドキュメントの読み込みが問題となりえるいくつかのコンテキストで便利でありえます。

• リクエストごとに遠隔のコンテキストの位置で過負荷とならないように、遠隔のコンテキスト・ドキュメントをキャッシュすべきです。通常、HTTPキャッシング・インフラストラクチャがこれを処理することが期待されますが、状況によってはこれを実行できない場合があります。documentLoaderの実装は、そのようなキャッシュを実行するために、別のロジックを提供する可能性があります。
• 標準ではないURLスキームは、広範な実装ができなかったり、特定のアプリケーション領域に固有の動作があったりする可能性があります。documentLoaderを定義して、ドキュメント検索のセマンティクスを実装できます。
• ある種の有名なコンテキストは、documentLoaderの実装内に静的にキャッシュすることができます。これは、遠隔のドキュメントへのアクセスに適していない、または不可能ですらある、組み込みアプリケーションで特に便利です。
• セキュリティ上の理由から、ドキュメントを遠隔で取得する行為により、アプリケーションの動作が発信される可能性があります。documentLoaderを適切に用いることで、アプリケーションを分離し、オンラインでのフィンガープリントを減少されることができます。

5.1 展開ドキュメント形式

この項は非規範的です。

JSON-LD 1.1処理アルゴリズムとAPI仕様[JSON-LD11-API]は、JSON-LDドキュメントを展開する方法を定義しています。展開とは、JSON-LDドキュメントを取得し、すべての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展開アルゴリズムを実行した結果は、次の出力になるでしょう。

JSON-LDのメディア・タイプは、展開ドキュメント形式を通知またはリクエストするために使用できるprofileパラメータを定義します。展開ドキュメント形式を識別するプロファイルURIはhttp://www.w3.org/ns/json-ld#expandedです。

5.2 短縮ドキュメント形式

この項は非規範的です。

JSON-LD 1.1処理アルゴリズムとAPI仕様[JSON-LD11-API]は、JSON-LDドキュメントを短縮する方法を定義しています。短縮とは、開発者が提供するコンテキストを適用し、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"
    }
  }
}

上記のJSON-LD入力ドキュメントに対して上記で提供されたコンテキストを指定してJSON-LD短縮アルゴリズムを実行すると、次の出力が生成されるでしょう。

JSON-LDのメディア・タイプは、短縮ドキュメント形式を通知またはリクエストするために使用できるprofileパラメータを定義します。短縮ドキュメント形式を識別するプロファイルURIはhttp://www.w3.org/ns/json-ld#compactedです。

短縮の詳細は、[JSON-LD11-API]の短縮アルゴリズムで説明されています。この項では、JSON-LDドキュメントの短縮に用いるコンテキストを作成する作成者へのガイドとして、アルゴリズムがどのように動作するかを簡潔に説明します。

短縮の目的は、既存のJSON-LDドキュメントに用語定義、語彙マッピング、デフォルト言語、基底IRIを適用し、JSON-LDドキュメントの使用に合った形式で直接JSONとして表せるようにすることです。これには、可能な場合は、値を値オブジェクトではなく文字列として表すこと、リスト・オブジェクトの使用をシンプルな配列に短縮すること、ノード間の関係を逆にすること、複数の値を値の配列として表す代わりにデータ・マップを用いてインデックス化することが含まれます。

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

この項は非規範的です。

JSON-LD 1.1処理アルゴリズムとAPI仕様[JSON-LD11-API]は、JSON-LDドキュメントをフラット化する方法を定義しています。フラット化は、1つのマップ内のノードのすべてのプロパティーをまとめ、すべての空白ノードを空白ノード識別子でラベル付けします。これにより、データの形が確保され、特定のアプリケーションで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入力ドキュメントに対してJSON-LDのフラット化アルゴリズムを実行し、同じコンテキストを用いると、次の出力が生成されます。

JSON-LDのメディア・タイプは、フラット化ドキュメント形式を通知またはリクエストするために使用できるprofileパラメータを定義します。フラット化ドキュメント形式を識別するプロファイルURIはhttp://www.w3.org/ns/json-ld#flattenedです。これは、展開ドキュメント形式または短縮ドキュメント形式を識別するプロファイルURIと組み合わせることができます。

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

この項は非規範的です。

JSON-LD 1.1フレーム化仕様[JSON-LD11-FRAMING]は、JSON-LDドキュメントをフレーム化する方法を定義しています。フレーム化は、JSON-LDドキュメントのデータを整形するために用います。これには、フラット化されたデータを一致させるためと、結果として得られるデータをどのように整形すべきかの例を示すための両方に用いられるフレーム・ドキュメントの例を用います。

例えば、次のJSON-LDフレームを想定してみましょう。

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

このフレーム・ドキュメントは、Library(図書館)という型を持つオブジェクトを最上部に配置し、プロパティー値として組み込まれたcontains(含む)プロパティーを用いてそのLibraryオブジェクトにリンク付けられたBook(図書)という型のオブジェクトを用いた、組み込み構造を記述しています。また、参照している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"
  }]
}

フレーム・アルゴリズムは、フレームの構造に従った新しいドキュメントを作成できます。

JSON-LDのメディア・タイプは、フレーム化ドキュメント形式を通知またはリクエストするために使用できるprofileパラメータを定義します。フレーム化ドキュメント形式を識別するプロファイルURIはhttp://www.w3.org/ns/json-ld#framedです。

JSON-LDのメディア・タイプは、フレームが含まれているHTMLドキュメント内のスクリプト要素を識別するために使用できるprofileパラメータも定義しています。application/ld+json;profile=http://www.w3.org/ns/json-ld#frameという型の最初のスクリプト要素がフレームの検索に用いられるでしょう。