CyberLibrarian

【注意】 このドキュメントは、W3CのJSON-LD 1.1 : A JSON-based Serialization for Linked Data W3C Recommendation 16 July 2020の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。

First Update: 2020年11月24日


JSON-LD 1.1

リンクト・データのためのJSONベースのシリアル化

W3C勧告

本バージョン:
https://www.w3.org/TR/2020/REC-json-ld11-20200716/
最新公開バージョン:
https://www.w3.org/TR/json-ld11/
最新編集者草案:
https://w3c.github.io/json-ld-syntax/
テスト・スイート:
https://w3c.github.io/json-ld-api/tests/
実装報告書:
https://w3c.github.io/json-ld-api/reports/
旧バージョン:
https://www.w3.org/TR/2020/PR-json-ld11-20200507/
旧勧告:
https://www.w3.org/TR/2014/REC-json-ld-20140116/
編集者:
Gregg Kellogg (v1.0 and v1.1)
Pierre-Antoine Champin (LIRIS - Universite de Lyon) (v1.1)
Dave Longley (Digital Bazaar) (v1.1)
旧編集者:
Manu Sporny (Digital Bazaar) (v1.0)
Markus Lanthaler (Google) (v1.0)
著者:
Manu Sporny (Digital Bazaar) (v1.0)
Dave Longley (Digital Bazaar) (v1.0 and v1.1)
Gregg Kellogg (v1.0 and v1.1)
Markus Lanthaler (Google) (v1.0)
Pierre-Antoine Champin (LIRIS - Universite de Lyon) (v1.1)
Niklas Lindstrom (v1.0)
参加可能:
GitHub w3c/json-ld-syntax
File a bug
Commit history
Pull requests

公開以後に報告されたエラーや問題がないか正誤表を確認してください。

翻訳版も参照してください。

このドキュメントは、規範以外の形式でも入手できます: EPUB


要約

JSONは、データのシリアル化と送受信に便利な形式です。この仕様では、リンクト・データをシリアル化するためのJSONベースの形式であるJSON-LD 1.1を定義しています。この構文は、既にJSONを用いている展開済みのシステムに容易に統合できるように設計されており、JSONからJSON-LDにスムーズにアップグレードするための道筋を示します。これは、ウェブ・ベースのプログラミング環境におけるリンクト・データの利用、相互運用可能なウェブ・サービスの構築、JSONベースのストレージ・エンジン内のリンクト・データの格納のための手段となることを主に意図しています。

この仕様は、JSON-LD 1.0[JSON-LD10]で定義している機能の上位集合を記述しており、特に明記していない限り、この仕様のバージョン1.0を用いて作成されたドキュメントは、JSON-LD 1.1との互換性を維持しています。

このドキュメントのステータス

この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、https://www.w3.org/TR/のW3C技術報告インデックスにあります。

このドキュメントは、JSON-LDワーキング・グループによって開発され、JSON-LDコミュニティ・グループ最終レポートから派生したものです。

このドキュメントで記述している機能を実証できる実演型JSON-LDプレイグラウンドがあります。

この仕様は、JSON-LD 1.0[JSON-LD10]仕様に取って代わることを目的としています。

このドキュメントは、JSON-LDワーキンググループによって勧告として公開されました。

この仕様の議論にはGitHub Issuesをお勧めします。または、メーリング・リストにコメントを送信することもできます。コメントはpublic-json-ld-wg@w3.org(アーカイブ)に送信してください。

ワーキンググループの実装報告書を参照してください。

このドキュメントは、W3Cメンバー、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。これは確定済みドキュメントであり、参考資料として用いたり、別のドキュメントで引用することができます。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。

このドキュメントは、W3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。

このドキュメントは、2019年3月1日のW3Cプロセス・ドキュメントによって管理されています。

ドキュメント集合

このドキュメントは、JSON-LDワーキンググループが作成した次の3つのJSON-LD 1.1勧告うちの1つです。

1. はじめに

この項は非規範的です。

リンクト・データ[LINKED-DATA]は、様々なドキュメントやウェブ・サイトにまたがる標準に基づく、機械が解釈可能なデータのネットワークを作成する方法です。これにより、アプリケーションは、1つのリンクト・データから出発し、ウェブ上の様々なサイトで提供されている他のリンクト・データへの組み込みリンクを辿ることができます。

JSON-LDは、リンクト・データをJSON[RFC8259]でシリアル化するための軽い構文です。その設計により、既存のJSONを最小限の変更でリンクト・データとして解釈できるようになります。JSON-LDは、ウェブ・ベースのプログラミング環境におけるリンクト・データの利用、相互運用可能なウェブ・サービスの構築、JSONベースのストレージ・エンジン内のリンクト・データの格納のための手段となることを主に意図しています。JSON-LDはJSONと100%互換性があるため、現在利用可能な多数のJSONパーサやライブラリを再利用できます。JSONが提供するすべての機能に加えて、JSON-LDでは以下を導入しています。

JSON-LDは、RDF[RDF11-CONCEPTS]の知識がなくても、そのままJSONとして利用できるように設計されています。また、SPARQL[SPARQL11-OVERVIEW]などの他のリンクト・データ技術と組み合わせてRDFとして使用できるようにも設計されています。上記の機能を必要とする開発者や、RDFグラフデータセットをJSONベースの構文でシリアル化する必要のある開発者は、JSON-LDに興味を持つでしょう。JSON-LDをRDFツールとともに用いようとしている人は、[Turtle]や[TriG]のように、別のRDF構文として使用できることに気付くでしょう。JSON-LDとRDFがどのように関係しているかに関する完全な詳細は、§ 10. RDFとの関係の項にあります。

この構文は、JSONに基づいて稼働している展開済みのシステムを妨げることなく、JSONからJSON-LDにスムーズにアップグレードするための道筋を示すように設計されています。そのようなデータの形は非常に多様であるため、JSON-LDは、ドキュメントを決定的な(deterministic)構造に再整形して処理をシンプルにする方法を備えています。

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

この項は非規範的です。

このドキュメントは、リンクト・データを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 貢献

この項は非規範的です。

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

1.3 表記上の規定

この項は非規範的です。

この仕様では、表記に関して次の規定を用いています。

マークアップ
マークアップ(要素、属性、プロパティー)、機械が処理可能な値(文字列、文字、メディア・タイプ)、プロパティー名、またはファイル名は、赤橙色の等幅フォントです。
variable(変数)
疑似コードやアルゴリズムの記述内の変数は、イタリック体です。
定義
この仕様や他の仕様の他の場所で用いられている用語の定義は、太字のイタリック体です。
定義の参照
このドキュメント内の定義への参照は下線付きで表しており、それは定義自体へのアクティブ・リンクでもあります。
定義の参照のマークアップ
このドキュメント内の定義への参照は、参照自体がマークアップでもある場合は、下線付きの赤橙色の等幅フォントで表しており、それは定義自体へのアクティブ・リンクでもあります。
外部定義の参照
別ドキュメント内の定義への参照は、下線付きのイタリック体で表しており、それは定義自体へのアクティブ・リンクでもあります。
外部定義の参照のマークアップ
別ドキュメント内の定義への参照は、参照自体がマークアップでもある場合は、下線付きのイタリック体の赤橙色の等幅フォントで表しており、それは定義自体へのアクティブ・リンクでもあります。
ハイパーリンク
ハイパーリンクは、下線付きの青色です。
[参考文献]
ドキュメントの参考文献(規範的または参考情報)は角括弧で囲み、参考文献の項にリンクしています。
勧告以後の変更
以前の勧告から変更した項や表現は、§ 1.1 このドキュメントの読み方の機能を用いて強調表示できます。

注は、緑色の左枠線と緑色の「注」という見出しが付いた薄緑色のボックスに入っています。注は常に参考情報です。

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

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

1.4 用語

この項は非規範的です。

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

他の仕様からインポートした用語

ECMAScript言語仕様 [ECMASCRIPT]、JSON(The JavaScript Object Notation)データ交換フォーマット[RFC8259]、インフラ標準[INFRA]、およびWeb IDL[WEBIDL]からインポートした用語

array(配列)
JSONのシリアル化では、配列構造は0以上の値を囲む角括弧で表されます。値はコンマで区切ります。内部表現では、リスト(配列とも呼ばれる)は0以上の値の順序付きのコレクションです。JSON-LDはJSONと同じ配列表現を用いますが、コレクションはデフォルトでは順不同です。通常のJSON配列では順序は保持されますが、通常のJSON-LD配列では特に定義されていない限り保持されません(JSON-LD 1.1の集合とリストの項を参照)。
boolean(ブール)
2つの可能な状態のうちの1つを表すためのtruefalseの値。
JSON object(JSONオブジェクト)
JSONのシリアル化では、オブジェクトの構造は、0以上の名前/値のペア(またはメンバー)を囲む一対の中括弧として表されます。名前は文字列です。それぞれの名前の後にコロンを1つ付けて、名前と値を区切ります。1つのコンマで値と後続の名前を区切ります。JSON-LDでは、あるオブジェクト内の名前は一意でなければなりません。

内部表現では、JSONオブジェクトは、キー/値のペアを持つエントリーで構成されるマップ([INFRA]を参照)として記述されます。

API(Application Programming Interface)では、マップは[WEBIDL]のレコードを用いて記述されます。

null(ヌル)
JSON-LD内では、null値は値を無視したりリセットしたりするために用います。値や値の@idnullである場合の@context内のマップ・エントリーは、用語とIRIとの関連性を明示的に切り離します。値がnullであるJSON-LDドキュメントの本文内のマップ・エントリーは、マップ・エントリーが定義されていない場合と同じ意味を持ちます。@value@list、または@setが展開形式でnullに設定されていれば、JSONオブジェクト全体が無視されます。
number(数値)
JSONのシリアル化では、数値は、8進と16進の形式は用いず、先頭の0が許されていない点を除き、ほとんどのプログラミング言語で用いられているものに似ています。内部表現では、数値は、0以外の小数部があるかどうかに応じて、longdoubleのいずれかと同等です([WEBIDL]を参照)。
scalar(スカラー)
スカラーは、文字列数値truefalseのいずれかです。
string(文字列)
文字列は、0以上のUnicode(UTF-8)文字のシーケンスで、二重引用符で囲まれ、(必要に応じて)バックスラッシュ・エスケープを用います。文字は1つの文字列として表されます。

IRI(Internationalized Resource Identifiers)[RFC3987]からインポートした用語

IRI
スキームを、パスと、オプションであるクエリフラグメントのセグメントとともに含む絶対形式のIRI
IRI reference(IRI参照)
IRI(Internationalized Resource Identifier)の一般的な使用方法です。IRI参照は、絶対的または相対的でありえます。ただし、そのような参照の結果である「IRI」には絶対IRIのみが含まれます。任意の相対IRI参照は絶対形式に解決されます。
relative IRI reference(相対IRI参照)
相対IRI参照は、他のIRI(通常はドキュメントの基底IRI)に対して相対的なIRI参照です。プロパティー@typeの値、および語彙に対して相対的であると定義されている用語の値は、基底IRIではなく、語彙マッピングに対して解決されることに注意してください。

RDF 1.1概念および抽象構文[RDF11-CONCEPTS]、RDFスキーマ1.1[RDF-SCHEMA]、およびリンクト・データの設計上の課題[LINKED-DATA]からインポートした用語

base IRI(基底IRI)
基底IRIは、そのコンテキスト内で確立されるIRIであるか、JSON-LDドキュメントの位置に基づいています。基底IRIは、相対IRI参照IRIに変換するために用います。
blank node(空白ノード)
IRIでもリテラルでもないグラフノード空白ノードには、逆参照可能な識別子が含まれていません。これは、本質的に一時的なものであったり、リンクト・データ・グラフの外部からリンクする必要がある情報が含まれていなかったりするためです。JSON-LDでは、空白ノードには、_:という接頭辞で始まる識別子が割り当てられます。
blank node identifier(空白ノード識別子)
空白ノード識別子は、JSON-LDドキュメントの範囲内の空白ノードの識別子として使用できる文字列です。空白ノード識別子は、_:で始まります。
dataset(データセット)
きっかり1つのデフォルト・グラフと0以上の名前付きグラフが含まれているRDFグラフのコレクションを表すデータセット
datatype IRI(データ型IRI)
データ型IRIは、リテラル値に対する字句形式のマッピング方法を決定するデータ型を識別するIRIです。
default graph(デフォルト・グラフ)
データセットデフォルト・グラフは、名前のないRDFグラフであり、空でありえます。
graph name(グラフ名)
名前付きグラフを識別するIRIまたは空白ノード
language-tagged string(言語タグ付き文字列)
言語タグ付き文字列は、[BCP47]で定義されているとおり、文字列と空でない言語タグで構成されます。言語タグは、[BCP47]の2.2.9項 適合クラスに従った整形式でなければなりません。プロセッサは、言語タグを小文字に正規化できます。
Linked Data(リンクト・データ)
リンクト・データ・グラフまたはデータセットの表現を個々に含んでいるドキュメントの集合。
list(リスト)
リストは、IRI空白ノードリテラルの順序付きシーケンスです。
literal(リテラル)
文字列数値などの値として表されるオブジェクト。暗示的または明示的にデータ型IRIが含まれ、データ型がrdf:langStringである場合はオプションの言語タグが含まれます。
named graph(名前付きグラフ)
名前付きグラフは、IRIまたは空白ノードによって識別されるリンクト・データ・グラフです。
node(ノード)
RDFグラフノードで、少なくとも1つのトリプル主語および目的語のいずれか。同じトリプル内であっても、ノードグラフ内で両方(主語目的語)の役割を果たすことができることに注意してください。
object(オブジェクト)
オブジェクトは、少なくとも1つの入力エッジを持つリンクト・データ・グラフノードです。
property(プロパティー)
リンクト・データ・グラフの有向アークの名前。すべてのプロパティーには方向性があり、IRIまたは空白ノード識別子でラベル付けされています。プロパティーは可能な限り、IRIでラベル付けすべきです。
空白ノード識別子を用いたプロパティーのラベル付けは廃止されており、JSON-LDの将来のバージョンでは削除される可能性があります。
[RDF11-CONCEPTS]の述語も参照してください。
RDF graph(RDFグラフ)
ラベル付き有向グラフ、つまり、有向アークで接続されたノードの集合。リンクト・データ・グラフとも呼ばれます。
resource(資源)
世の中の事物(「論議領域」)を表すIRI空白ノード、またはリテラルで示される資源
subject(主語)
主語は、プロパティーを介して目的語のノードに関連付けられた、少なくとも1つの出力エッジを持つリンクト・データ・グラフノードです。
triple(トリプル)
主語述語、および目的語が含まれているRDFグラフの構成要素で、RDFグラフのノード-アーク-ノードのセグメントを表します。

JSON-LD固有の用語定義

active context(アクティブ・コンテキスト)
処理アルゴリズムの実行中に用語を解決するために用いられるコンテキスト
base direction(基本書字方向)
基本書字方向は、文字列に方向が直接関連付けられていない場合に用いる方向です。値が"ltr""rtl"nullのいずれかの文字列でなければならない@directionキーを用いてコンテキスト内で設定できます。規範的な記述については、JSON-LD 1.1のコンテキスト定義の項を参照してください。
compact IRI(短縮IRI)
短縮IRIは、接頭辞:接尾辞という形式を持ち、接頭辞で識別される共通する語彙に含まれているIRIごとに個別に用語定義を行う必要なくIRIを表す方法として用います。
context(コンテキスト)
JSON-LD 1.1のコンテキストの項で記述し、JSON-LD 1.1のコンテキスト定義の項で規範的に規定している、JSON-LDドキュメントを解釈するための一連の規則。
default language(デフォルトの言語)
デフォルトの言語は、文字列に言語が直接関連付けられていない場合に用いる言語です。値が[BCP47]言語コードまたはnullを表す文字列でなければならない@languageキーを用いてコンテキスト内で設定できます。規範的な記述については、JSON-LD 1.1のコンテキスト定義の項を参照してください。
default object(デフォルトのオブジェクト)
デフォルトのオブジェクトは、@defaultキーを持つマップです。
embedded context(組み込みコンテキスト)
組み込みコンテキストは、ノード・オブジェクト値オブジェクトグラフ・オブジェクトリスト・オブジェクト集合オブジェクト入れ子のプロパティーの値、展開用語定義の値のうちの1つの@contextエントリーとして現れるコンテキストです。その値はIRIとしての、または上記のいずれかを組み合わせた配列としての、コンテキスト定義マップでありえます。
expanded term definition(展開用語定義)
展開用語定義は、値が、関連付けられているIRIを定義するための1つ以上のキーワードのキーが含まれているマップである(これが、逆プロパティー、文字列の値に関連付けられている型、およびコンテナ・マッピングである場合)用語定義です。規範的な記述については、JSON-LD 1.1の展開用語定義の項を参照してください。
frame(フレーム)
マッチングと組み込みの規則を用いて別のJSON-LDドキュメントを変換するための形式が記述されているJSON-LDドキュメント。フレーム・ドキュメントでは、追加のキーワードと特定のマップ・エントリーを用いて、マッチングと変換の処理を記述できます。
frame object(フレーム・オブジェクト)
フレーム・オブジェクトは、入力のノード・オブジェクトまたは値オブジェクトのいずれかに一致するフレームの特定の部分を表すフレーム内のマップ要素です。規範的な記述については、JSON-LD 1.1のフレーム・オブジェクトの項を参照してください。
graph object(グラフ・オブジェクト)
グラフ・オブジェクトは、名前付きグラフノード・オブジェクト内のマップ・エントリーの値として表します。グラフ・オブジェクトは、展開した時に、@graphエントリーを持っていなければならず、@id@indexエントリーを持つことができます。シンプルなグラフ・オブジェクトは、@idエントリーを持っていないグラフ・オブジェクトです。ノード・オブジェクト@graphエントリーを持つことができますが、他のエントリーが含まれている場合には、グラフ・オブジェクトとは見なされないことに注意してください。@graphで構成される最上位のオブジェクトも、グラフ・オブジェクトではありません。ノード・オブジェクトは、他のプロパティーが含まれている場合は、名前付きグラフも表すことができることに注意してください。規範的な記述については、JSON-LD 1.1のグラフ・オブジェクトの項を参照してください。
id map(idマップ)
idマップは、@container@idに設定して定義した用語マップの値です。idマップの値はノード・オブジェクトでなければならず、そのキーは、関連付けられているノード・オブジェクト@idを表すIRIとして解釈されます。idマップの値に@idへと展開するキーが含まれている場合、その値はidマップの参照キーと同等でなければなりません。規範的な記述については、JSON-LD 1.1のIdマップの項を参照してください。
implicitly named graph(暗黙的な名前付きグラフ)
@container@graphに設定した展開用語定義を持つマップ・エントリーの値から作成される名前付きグラフ
included block(包含ブロック)
包含ブロックは、キーが@includedまたは@includedのエイリアスであり、値が1つ以上のノード・オブジェクトであるノード・オブジェクトエントリーです。規範的な記述については、JSON-LD 1.1の包含ブロックの項を参照してください。
index map(インデックス・マップ)
インデックス・マップは、@container@indexに設定して定義した用語マップの値であり、その値は文字列数値truefalsenullノード・オブジェクト値オブジェクトリスト・オブジェクト集合オブジェクト、上記の0以上の配列のいずれかでなければなりません。形式的な記述については、JSON-LD 1.1のインデックス・マップの項を参照してください。
JSON literal(JSONリテラル)
JSONリテラルは、関連付けられているデータ型IRIrdf:JSONであるリテラルです。値オブジェクトの表現では、@typeの値は@jsonです。JSONリテラルは、有効なJSON[RFC8259]である値を表します。規範的な記述については、JSON-LD 1.1のrdf:JSONデータ型の項を参照してください。
JSON-LD document(JSON-LDドキュメント)
JSON-LDドキュメントは、RDFデータセットのシリアル化です。形式的な記述については、JSON-LD 1.1のJSON-LD文法の項を参照してください。
JSON-LD internal representation(JSON-LDの内部表現)
JSON-LDの内部表現は、JSON構文構造を直接処理に適したコアなデータ構造(配列マップ文字列数値ブールnull)に変換した結果です。
JSON-LD Processor(JSON-LDプロセッサ)
JSON-LDプロセッサは、JSON-LD 1.1処理アルゴリズムとAPIで定義されているアルゴリズムを実行できるシステムです。形式的な記述については、JSON-LD 1.1 APIの適合性の項を参照してください。
JSON-LD value(JSON-LD値)
JSON-LD値は、文字列数値truefalse型付き値、または言語タグ付き文字列です。これは、RDFリテラルを表します。
keyword(キーワード)
JSON-LD 1.1の構文トークンとキーワードの項で記述し、JSON-LD 1.1のキーワードの項で規範的に規定している、JSON-LD固有の文字列
language map(言語マップ)
言語マップは、@container@languageに設定して定義した用語マップの値であり、そのキーは[BCP47]言語コードを表す文字列でなければならず、その値はnull文字列、上記の0以上の配列のいずれかの型でなければなりません。規範的な記述については、JSON-LD 1.1の言語マップの項を参照してください。
list object(リスト・オブジェクト)
リスト・オブジェクトは、@listキーを持つマップです。@indexキーを含むこともできますが、その他のエントリーを含むことはできません。規範的な記述については、JSON-LD 1.1のリストと集合の項を参照してください。
local context(ローカル・コンテキスト)
マップで指定されるコンテキスト@contextキーワードにより指定されます。
nested property(入れ子のプロパティー)
入れ子のプロパティーは、ノード・オブジェクト内のキーで、その値はノード・オブジェクトの値であるかのように扱われるエントリーを含んでいるマップです。入れ子のプロパティー自体は、セマンティック的に無意味であり、ノード・オブジェクト内にサブ構造を作成するためにのみ用います。規範的な記述については、JSON-LD 1.1のプロパティーの入れ子化の項を参照してください。
node object(ノード・オブジェクト)
ノード・オブジェクトは、JSON-LDドキュメントによってシリアル化されたグラフノードの0以上のプロパティーを表します。JSON-LDのコンテキストの外部に存在し、かつ次の場合に、マップノード・オブジェクトです。
  • @value@list、または@setのキーワードが含まれていない場合、または、
  • @graph@contextのみのエントリーで構成されるJSON-LDドキュメントの最上部のマップではない場合。
キーがキーワードではないノード・オブジェクトエントリーは、ノード・オブジェクトプロパティーとも呼ばれます。規範的な記述については、JSON-LD 1.1のノード・オブジェクトの項を参照してください。
node reference(ノード参照)
@idキーのみを持つノードを参照するために用いられるノード・オブジェクト
prefix(接頭辞)
接頭辞は、短縮IRIの最初の構成要素で、短縮IRIの接尾辞の前に付けるとIRIになる文字列にマッピングされる用語に由来します。
processing mode(処理モード)
処理モードは、JSON-LDドキュメントの処理方法を定義します。デフォルトでは、すべてのドキュメントがこの仕様に準拠していると見なされます。公開者は、コンテキスト内で@versionエントリーを用いて異なるバージョンを定義することで、JSON-LD 1.0[JSON-LD10]に準拠しているプロセッサが誤ってJSON-LD 1.1ドキュメントを処理し、異なる出力を作成する可能性がないことを保証できます。APIが処理モードjson-ld-1.0に設定するオプションを提供すると、JSON-LD 1.1の機能がアクティブ化されなくなったり、コンテキスト@versionエントリーが明示的に1.1に設定されている場合にエラーになったりします。この仕様は、json-ld-1.1処理モードによりJSON-LD 1.0を拡張したものです。
scoped context(範囲付きコンテキスト)
範囲付きコンテキストは、@contextエントリーを用いた展開用語定義の一部です。これは、組み込みコンテキストと同じ形式を有しています。用語を型として用いる場合は型の範囲付きコンテキスト(type-scoped context)を定義し、プロパティーとして用いる場合はプロパティーの範囲付きコンテキスト(property-scoped context)を定義します。
set object(集合オブジェクト)
集合オブジェクトは、@setエントリーを持つマップです。@indexキーを含むこともできますが、その他のエントリーを含むことはできません。規範的な記述については、JSON-LD 1.1のリストと集合の項を参照してください。
term(用語)
用語は、IRIへと展開できる、コンテキスト内で定義される短い単語です。規範的な記述については、JSON-LD 1.1の用語の項を参照してください。
term definition(用語定義)
用語定義はコンテキストのエントリーであり、そのキーは、マップ内でキー、型として使用できる、または文字列が語彙アイテムとして解釈される他の場所で使用できる用語を定義します。その値はIRIに展開される文字列(シンプルな用語定義)かマップ(展開用語定義)のいずれかです。
type map(型マップ)
型マップは、@container@typeに設定して定義した用語マップの値であり、そのキーは、関連付けられているノード・オブジェクト@typeを表すIRIとして解釈されます。その値はノード・オブジェクトまたはノード・オブジェクトの配列でなければなりません。@typeに展開される用語が値に含まれている場合、その値は展開時にマップの値と統合されます。規範的な記述については、JSON-LD 1.1の型マップの項を参照してください。
typed value(型付き値)
型付き値は、文字列である値と、IRIである型で構成されます。
value object(値オブジェクト)
値オブジェクトは、@valueエントリーを持つマップです。規範的な記述については、JSON-LD 1.1の値オブジェクトの項を参照してください。
vocabulary mapping(語彙マッピング)
語彙マッピングは、値がIRI短縮IRI用語、またはnullでなければならない@vocabキーを用いてコンテキスト内で設定されます。規範的な記述については、JSON-LD 1.1のコンテキスト定義の項を参照してください。

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以外の表層構文は、構文が同等のコアなデータ構造にマッピングされている場合に、同じアルゴリズムを用いて操作できます。

この仕様では論じていませんが、YAML(YAML Ain’t Markup Language)(YAML™)バージョン1.2[YAML]やCBOR(Concise Binary Object Representation)[RFC7049]などのバイナリ表現を用いた並行作業を、内部表現へのマッピング用に使用でき、それにより、JSON-LD 1.1 API[JSON-LD11-API]は、情報源がJSONドキュメントであるかのように動作できます。

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

この項は非規範的です。

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

:
短縮IRIを用いるJSONのキーと値の区切り記号。
@base
通常ならばドキュメントに対して相対的に解釈される相対IRI参照を解決するための基底IRIを設定するために用います。このキーワードについては、§ 4.1.3 基底IRIで説明しています。
@container
用語に対するデフォルトのコンテナ型を設定するために用います。このキーワードについては、以下の項で記述しています。
@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のすべてのキー、キーワード、および値は、大文字と小文字を区別します。

2. 適合性

非規範的と記している項と同じく、この仕様のすべての作成ガイドライン、図、例、注は、非規範的です。この仕様のその他の部分はすべて規範的です。

このドキュメントの「することができる/してもよい(MAY)」、「しなければならない(MUST)」、「してはならない(MUST NOT)」、「推奨される(RECOMMENDED)」、「すべきである/する必要がある(SHOULD)」、「すべきでない/する必要がない(SHOULD NOT)」というキーワードは、ここで示しているように、すべて大文字で表示されている場合にのみ、BCP 14[RFC2119] [RFC8174]で記述されているように解釈されるべきです。

JSON-LDドキュメントは、付録§ 9. JSON-LD文法の規範的なステートメントに従っていれば、この仕様に準拠しています。JSONドキュメントは、§ 6.1 JSONをJSON-LDとして解釈の規範的なステートメントに従うことで、JSON-LDとして解釈できます。便宜上、ドキュメントに関する規範的なステートメントは、多くの場合、ドキュメントのプロパティーのステートメントとして表されます。

この仕様では、次の名前空間接頭辞を用います。

接頭辞 IRI
dc11 http://purl.org/dc/elements/1.1/
dcterms http://purl.org/dc/terms/
cred https://w3id.org/credentials#
foaf http://xmlns.com/foaf/0.1/
geojson https://purl.org/geojson/vocab#
prov http://www.w3.org/ns/prov#
i18n https://www.w3.org/ns/i18n#
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns#
schema http://schema.org/
skos http://www.w3.org/2004/02/skos/core#
xsd http://www.w3.org/2001/XMLSchema#

これらは、このドキュメント内では、http://purl.org/dc/terms/titleを表すためのdcterms:titleなど、結果のIRIの省略形としての短縮IRIの一部として用います。

3. 基本概念

この項は非規範的です。

JSON[RFC8259]は、軽く、言語に依存しないデータ交換フォーマットです。解析も生成も容易です。しかし、データに他のデータ情報源と競合するキーが含まれうるため、様々な情報源のJSONを統合することは困難です。さらに、JSONには、ウェブの基本的な構成要素であるハイパーリンクに対する組み込み済みのサポートがありません。この項の残りの部分で用いることになる例を見てみましょう。

2: JSONドキュメントの例
{
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "image": "http://manu.sporny.org/images/manu.png"
}

データが「Manu Sporny」というname(名前)の人物に関するものであり、homepage(ホームページ)というプロパティーにその人物のホームページのURLが含まれていることは、人間には明らかです。機械にはそのような直感的な理解はできず、人間にとっても、そのような表現のあいまいさを解決することは困難な場合があります。この問題は、「名前」、「ホームページ」などのトークンの代わりに、明確な識別子を用いて異なる概念を示すことで解決できます。

リンクト・データやウェブ全般では、明確な識別のためにIRI([RFC3987]で記述されているInternationalized Resource Identifier)を用います。IRIを用いて、他の開発者が用いる可能性のあるデータに明確な識別子を割り当てるという考え方です。namehomepageなどの用語は、開発者が互いの用語を誤って用いないように、IRIに展開しておくと有益です。さらに、開発者と機械はこのIRIを用いて用語に移動し(例えば、ウェブ・ブラウザーを用いて)、用語の意味の定義を取得できます。この処理は、IRIの逆参照として知られています。

よく知られているschema.orgの語彙を活用すると、上記の例は次のように明確に表現できます。

上記の例では、すべてのプロパティーはIRIによって明確に識別され、IRIを表すすべての値は@idキーワードによって明記されています。これは、データに関して非常に具体的な、有効なJSON-LDドキュメントですが、ドキュメントがあまりにも冗長でもあり、人間の開発者にとっては扱い難いです。この課題に対処するため、JSON-LDは次の項で説明しているとおり、コンテキストという概念を導入しています。

この項では、JSON-LDの最も基本的な機能のみを扱っています。型付き値インデックス付きの値名前付きグラフなどのより高度な機能は、§ 4. 高度な概念にあります。

3.1 コンテキスト

この項は非規範的です。

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

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

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

4: 前項のドキュメントの例のコンテキスト
{
  "@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にどのようにマッピングするかを指定するだけでなく、homepageimageのプロパティーに関連付けられている文字列の値が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で相対的に見つかるでしょう。

6: 相対的なコンテキストの読み込み
{
  "@context": "context.jsonld",
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "image": "http://manu.sporny.org/images/manu.png"
}

コンテキストのURLに対する相対参照の解決は、それ自体に他のコンテキストへの参照が含まれている場合があるため、遠隔のコンテキスト・ドキュメントにも適用されます。

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に対して相対的に解決されます。

§ 1.1 このドキュメントの読み方で述べたように、IRIはURL(Uniform Resource Locators)と混同されることがよくあります。主な違いは、URLはウェブ上の資源の位置を指定し(locate)、IRIは資源を識別する(identify)という点です。資源の識別子を逆参照可能にすることは良い習慣ですが、これが現実的でない場合もあります。特に、UUIDなどのURN(Uniform Resource Name)の[URN]スキームに注意してください。UUIDの例は、urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6です。

プロパティー@typeの値、および語彙マッピングに対して相対的であると定義している用語定義を持つプロパティーの値は、相対IRI参照の形式を取ることがありますが、基底IRIではなく語彙マッピングを用いて解決されます。

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

8: @idの値はIRIとして解釈される。
{
  ...
  "homepage": { "@id": "http://example.com/" }
  ...
}

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

9: IRIは相対的でありえる。
{
  ...
  "homepage": { "@id": "../" }
  ...
}

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

10 : キーとしての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.4 JSONオブジェクトの使用

この項は非規範的です。

JSONには、構文として次の限られた数の構文要素しかありません。

JSON-LDデータ・モデルでは、RDFデータ・モデルに基づく、より豊かな資源の集合が可能です。データ・モデルについては、§ 8. データ・モデルでより完全に説明します。JSON-LDは、JSONオブジェクトを用いて、様々な資源を、その資源の間の関係性とともに記述します。

Node objects(ノード・オブジェクト)
ノード・オブジェクトは、リンクト・データ・グラフのノードを定義するために用い、入力エッジと出力エッジの両方を持つことができます。ノード・オブジェクトは、プロパティーを持つ資源を定義するための主要な構造です。規範的な定義については、§ 9.2 ノード・オブジェクトを参照してください。
Value objects(値オブジェクト)
値オブジェクトは、入力エッジのみを持つリンクト・データ・グラフのリテラルのノードを記述するために用います。JSONでは、一部のリテラルのノードはJSONオブジェクト(数値文字列ブールの値など)を用いずに記述できますが、展開形式では、すべてのリテラルのノードは値オブジェクトを用いて記述されます。詳細については、§ 4.2 値の記述を、規範的な定義については、§ 9.5 値オブジェクトを参照してください。
List Objects(リスト・オブジェクト)とSet objects(集合オブジェクト)
リスト・オブジェクトは、特殊なJSON-LDのマップであり、ノード・オブジェクト値オブジェクトとは異なり、@listキーの下でマップ配列をラップすることにより順序付きの値を表すために用います。集合オブジェクトは、統一性のために存在し、@setキーの配列の値と同等です。詳細については、§ 4.3.1 リスト§ 4.3.2 集合を参照してください。
Map Objects(マップ・オブジェクト)
JSON-LDは、より簡単にプロパティーの値にアクセスするための方法として、様々な形式のマップを用います。
Language Maps(言語マップ)
関連付けられている言語が異なる複数の値を言語タグでインデックス化できるようにします。詳細については、§ 4.6.2 言語のインデックス化を、規範的な定義については、§ 9.8 言語マップを参照してください。
Index Maps(インデックス・マップ)
関連付けられている@indexにより、複数の値(ノード・オブジェクトまたは値オブジェクト)をインデックス化できます。詳細については、§ 4.6.1 データのインデックス化を、規範的な定義については、§ 9.9 インデックス・マップを参照してください。
Id Maps(idマップ)
関連付けられている@idにより、複数のノード・オブジェクトをインデックス化できます。詳細については、§ 4.6.3 ノード識別子のインデックス化を、規範的な定義については、§ 9.11 idマップを参照してください。
Type Maps(型マップ)
関連付けられている@typeにより、複数のノード・オブジェクトをインデックス化できます。詳細については、§ 4.6.4 ノード型のインデックス化を、規範的な定義については、§ 9.12 型マップを参照してください。
Named Graph Indexing(名前付きグラフのインデックス化)
関連付けられているグラフ名により、複数の名前付きグラフをインデックス化できます。詳細については、§ 4.9.3 名前付きグラフのインデックス化を参照してください。
Graph objects(グラフ・オブジェクト)
グラフ・オブジェクトは、それが名前付きグラフを定義する点を除いて、ノード・オブジェクトによく似ています。詳細については、§ 4.9 名前付きグラフを、規範的な定義については、§ 9.4 グラフ・オブジェクトを参照してください。ノード・オブジェクトは、ノードで定義されている他のプロパティーに加えて、名前付きグラフを記述することもできます。顕著な違いは、グラフ・オブジェクト名前付きグラフのみを記述するという点です。
Context Definitions(コンテキスト定義)
コンテキスト定義はJSONオブジェクトの形式を用いますが、それ自体はリンクト・データ・グラフのデータではありません。コンテキスト定義には、同様にJSONオブジェクトを用いて表される展開用語定義を含むこともできます。詳細については、§ 3.1 コンテキスト§ 4.1 高度なコンテキストの使用を、規範的な定義については、§ 9.15 コンテキスト定義を参照してください。

3.5 型の指定

この項は非規範的です。

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

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

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

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

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

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

4. 高度な概念

この項は非規範的です。

JSON-LDには、上記のコアな機能性を超える機能性を提供する機能が多数あります。JSONを用いると、このような構造を用いたデータを表現でき、この項で説明している機能を用いると、様々なJSON構造をリンクト・データとして解釈できます。JSON-LDプロセッサは、提供されたコンテキストと組み込まれたコンテキストを用いて、様々な慣用的な方法でプロパティー値を解釈します。

値の記述

JSONにおける1つのパターンは、プロパティーの値を文字列にすることです。多くの場合、この文字列は、実際には、IRI、日付、特定の言語の文字列など、何らかの他の型付き値を表します。このような値の型を記述する方法に関する詳細については、§ 4.2 値の記述を参照してください。

値の順序付け

JSONでは、配列の値を持つプロパティーは順序を暗示します。JSON-LDの配列は、組み込み構造を用いたり、コンテキスト定義により定義しない限り、デフォルトでは含まれている要素の順序を伝えません。詳細な議論については、§ 4.3 値の順序付けを参照してください。

プロパティーの入れ子化

APIでよく見られる別のJSONの慣用表現は、中間オブジェクトを用いてオブジェクトの関連プロパティーをグループ化するというものです。JSON-LDでは、これは入れ子のプロパティーと呼ばれ、§ 4.4 入れ子のプロパティーで説明しています。

オブジェクトの参照

リンクト・データとは、要するに様々な資源間の関係を記述することです。この関係は、ウェブ上の様々なドキュメントで定義されている資源間の場合もあれば、資源が同じドキュメント内で記述されている場合もあります。

このケースでは、http://manu.sporny.org/aboutにあるドキュメントには、上記の例が含まれていて、同様の表現が含まれている可能性のあるhttps://greggkellogg.net/foafにある別のドキュメントを参照している可能性があります。

JSONの使用に見られる一般的な慣用表現は、JSON-LDでオブジェクトの組み込みと呼んでいる、他のオブジェクトの値として指定されているオブジェクトです。例えば、次のような、Person(人)のオブジェクト値として指定されている友人です。

これらの関係の詳細は、§ 4.5 組み込みを参照してください。

インデックス付きの値

JSONのもう1つの一般的な慣用表現は、中間オブジェクトを用いて、インデックス化によりプロパティー値を表すことです。JSON-LDでは、§ 4.6 インデックス付きの値で詳述しているように、様々な方法でデータをインデックス化できます。

逆プロパティー

JSON-LDは有向グラフをシリアル化します。つまり、すべてのプロパティーは、あるノードから別のノードを指し示します。しかし、§ 4.8 逆プロパティーで詳述しているように、逆方向にシリアル化することが望ましい場合もあります。

以下の項では、そのような高度な機能についてより詳細に説明します。

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 保護された用語定義を参照してください。

可能であれば、コンテキスト定義はJSON-LDドキュメントの最上部に置くべきです。それにより、ドキュメントが読みやすくなり、ストリーミング・パーサーの効率が上がります。最上部にコンテキストがないドキュメントも、適合JSON-LDです。

前方互換性の課題を回避するために、@という文字で始まり、1つ以上のALPHA文字([RFC5234]を参照)のみが続く用語は、JSON-LDの将来のバージョンでキーワードとして用いられる可能性があるため、避けるべきです。JSON-LD 1.1のキーワードではない@という文字で始まる用語は、その他の用語として扱われる、つまり、IRIにマッピングされていなければ無視されます。さらに、すべてのプログラミング言語が空のJSONキーを処理できるわけではないため、空の用語("")の使用は許されていません。

4.1.1 JSON-LD 1.1の処理モード

この項は非規範的です。

JSON-LD 1.1で定義している新機能は、処理モードjson-ld-1.0に設定されていない場合に使用できます。これは、APIのオプションにより設定できます。処理モードは、1.1という数値の値として設定されたコンテキスト@versionエントリーを用いるか、APIのオプションによって明示的にjson-ld-1.1に設定できます。処理モードを明示的にjson-ld-1.1に設定することにより、JSON-LD 1.0プロセッサが誤ってJSON-LD 1.1ドキュメントを処理することが禁じられます。

23: コンテキストで@versionを設定
{
  "@context": {
    "@version": 1.1,
    ...
  },
  ...
}

@versionが含まれているドキュメントを処理する際に、APIのオプションで明示的に定義されていなければ、最初に遭遇したcontextによってprocessing mode(処理モード)が決まります。つまり、@versionのないコンテキストを処理した後に"@version": 1.1に遭遇した場合、後者によって、その内部では"@version": 1.1が定義されていたものと解釈されます。

JSON-LD 1.0プロセッサがJSON-LD 1.1ドキュメントを誤って処理して異なる結果を生成するのを防ぐために、処理モードを明示的にjson-ld-1.1に設定することが推奨されます(RECOMMENDED)。

4.1.2 デフォルトの語彙

この項は非規範的です。

すべてのプロパティーと型が同じ語彙に由来する場合があります。JSON-LDの@vocabキーワードにより、作成者は、語彙マッピングとして用いられ、用語に一致せず、IRIでも短縮IRIでもない(つまり、コロンを含まない)すべてのプロパティーと型に用いられる共通の接頭辞を設定できます。

@vocabが用いられているけれども、マップ内の特定のキーを語彙IRIを用いて展開すべきではない場合は、コンテキスト内で用語を明示的にnullに設定できます。例えば、下記の例では、databaseIdエントリーIRIに展開されず、展開時にプロパティーが削除されます。

JSON-LD 1.1以降は、ローカル・コンテキスト語彙マッピングは、アクティブ・コンテキスト語彙マッピングに連結された相対IRI参照に設定できます(アクティブ・コンテキスト語彙マッピングがない場合に、これがどのように適用されるかについては、§ 4.1.4 デフォルト語彙に対するドキュメントの基底の使用を参照してください)。

次の例は、相対IRI参照を用いてプロパティーを展開した場合の影響を示したもので、下記の展開形(結果)のタブで示しています。

§ 9.15 コンテキスト定義で定義している@vocabの文法では、値を用語または短縮IRIにすることができます。@vocabの値で用いられている用語は、コンテキストの導入時に範囲内になければならず、それ以外の場合は、@vocabと同じコンテキストで定義されている他の用語との間に循環依存関係が存在するだろうということに注意してください。

4.1.3 基底IRI

この項は非規範的です。

JSON-LDにより、[RFC3986]の5.1項 基底URIの確立に従って、ドキュメントの基底に対して解決される相対形式でIRIを指定できます。基底IRIは、@baseキーワードを用いてコンテキストで明示的に設定できます。

例えば、JSON-LDドキュメントがhttp://example.com/document.jsonldから取得された場合、相対IRI参照はそのIRIに対して解決されます。

27: 相対IRI参照をノード識別子として使用
{
  "@context": {
    "label": "http://www.w3.org/2000/01/rdf-schema#label"
  },
  "@id": "",
  "label": "Just a simple document"
}

このドキュメントでは、ドキュメントの基底に対して解決される空の@idを用います。しかし、ドキュメントが別の場所に移動すると、IRIは変わります。IRIを用いずにこれを防ぐためには、コンテキスト@baseマッピングを定義し、ドキュメントの基底IRIを上書きできます。

@basenullに設定すると、相対IRI参照IRIに展開されるのを防ぐことができます。

@baseが外部コンテキストで用いられている場合には無視されることに注意してください。

4.1.4 デフォルト語彙に対するドキュメントの基底の使用

この項は非規範的です。

語彙の用語は、外部の語彙ではなく、ドキュメント自体の中で直接定義される場合もあります。JSON-LD 1.1以降は、ローカル・コンテキスト語彙マッピングは、相対IRI参照に設定できます。つまり、範囲に語彙マッピングがなければ、基底IRIに対して解決されます。これにより、ノード・オブジェクトのキーなど、語彙に対して相対的に展開される用語が基底IRIに基づいてIRIを作成するようになります。

29: 語彙マッピングとしての「#」の使用
{
  "@context": {
    "@version": 1.1,
    "@base": "http://example/document",
    "@vocab": "#"
  },
  "@id": "http://example.org/places#BrewEats",
  "@type": "Restaurant",
  "name": "Brew Eats"
  ...
}

このドキュメントがhttp://example/documentにあったとすれば、次のように展開されるでしょう。

4.1.5 短縮IRI

この項は非規範的です。

短縮IRIは、コロン(:)で区切られた接頭辞接尾辞を用いてIRIを表す方法です。接頭辞は、アクティブ・コンテキストから取得した用語であり、JSON-LDドキュメント内の特定のIRIを識別する短い文字列です。例えば、foafという接頭辞は、http://xmlns.com/foaf/0.1/というIRIを用いて識別される、FOAF(Friend-of-a-Friend)の語彙の省略形として使用できます。開発者は、任意のFOAF語彙用語を接頭辞の末尾に追加して、語彙用語に対するIRIの省略バージョンを指定できます。例えば、foaf:nameは、http://xmlns.com/foaf/0.1/nameというIRIに展開されます。

上記の例では、foaf:namehttp://xmlns.com/foaf/0.1/nameというIRIに展開され、foaf:Personhttp://xmlns.com/foaf/0.1/Personに展開されます。

値の形式がprefix:suffixの組み合わせとして表される短縮IRIであり、接頭辞アクティブ・コンテキスト内で定義されている用語と一致し、接尾辞が2つのスラッシュ(//)で始まっていなければ、接頭辞は展開されます。短縮IRIは、接頭辞にマッピングされているIRIを(空でありえる)接尾辞に連結することによって展開されます。接頭辞アクティブ・コンテキストで定義されていない場合や、接尾辞が2つのスラッシュで始まる場合には(http://example.comなど)、値はIRIとして解釈されます。接頭辞が下線(_)の場合には、値は空白ノード識別子として解釈されます。

次の例で示しているように、コンテキスト内で短縮IRIを用いることもできます。

JSON-LD 1.0互換用の処理モードで明示的に動作する場合、値がURI gen-delim文字(例えば、/#など。[RFC3986]を参照)で終わるシンプルな用語定義が用いられている場合に限り、短縮時に用語を短縮IRI接頭辞として選択できます。

JSON-LD 1.1では、値がURI gen-delim文字で終わるシンプルな用語定義が用いられている場合、またはその展開用語定義に値がtrueである@prefixエントリーが含まれている場合に限り、展開時または短縮時に用語を短縮IRI接頭辞として選択できます。シンプルな用語定義がURI gen-delim文字で終わっていない場合や、展開用語定義に値がfalseである@prefixエントリーが含まれている場合は、用語は短縮IRIの展開や短縮IRIへのIRIの短縮には使用されないでしょう。

ここで報告しているJSON-LD 1.0の誤植の結果として、1.0プロセッサの用語選択の動作が変更されました。これは、既存のJSON-LDドキュメントの処理の動作には影響しませんが、短縮IRIを用いたドキュメントの短縮時にわずかな変化が生じます。

短縮時の動作は、次の入力ドキュメントを展開形式で考えることで例示できます。

33: 短縮IRIの作成を例示するために用いられる展開されたドキュメント
[{
  "http://example.com/vocab/property": [{"@value": "property"}],
  "http://example.com/vocab/propertyOne": [{"@value": "propertyOne"}]
}]

property(プロパティー)に関連付けられているIRIが元のIRIをより多く捕捉する場合でも、1.0の処理モードで次のコンテキストを用いると、propertyではなくvocabという用語が選択されます。

34: 短縮IRI生成のコンテキスト(1.0)
{
  "@context": {
    "vocab": "http://example.com/vocab/",
    "property": "http://example.com/vocab/property"
  }
}

上記の展開された入力ドキュメントで前のコンテキストを用いて短縮すると、次の短縮結果になります。

元の[JSON-LD10]では、用語選択アルゴリズムによりpropertyが選択され、property:Oneという短縮IRIが作成されるでしょう。@prefixを用いて、元の動作を明示することができます。

36: 短縮IRI生成のコンテキスト(1.1)
{
  "@context": {
    "@version": 1.1,
    "vocab": "http://example.com/vocab/",
    "property": {
      "@id": "http://example.com/vocab/property",
      "@prefix": true
    }
  }
}

このケースでは、propertyという用語は、展開用語定義で定義されていることと、その@idgen-delim文字で終わっていないことの両方の理由により、通常は接頭辞として使用できません。"@prefix": trueを追加することで、短縮IRIであるproperty:Oneの接頭辞部分として使用できるようになります。

4.1.6 キーワードのエイリアシング

この項は非規範的です。

@contextを除く個々のJSON-LDのキーワードは、アプリケーション固有のキーワードにエイリアシングできます。この機能により、旧式ドキュメントの既存のJSONキーを再利用することで、旧式JSONコンテンツをJSON-LDで利用できます。この機能により、開発者はJSON-LDのコンテキストのみを用いたドメイン固有の実装を設計することもできます。

上記の例では、@id@typeキーワードにそれぞれurlaというエイリアスが指定されています。

@typeの場合を除き、用語がキーワードである展開用語定義のプロパティーはエラーになります。処理モードjson-ld-1.0に設定されていない場合は、@typeには例外もあります。詳細と使用例については、§ 4.3.3 @typeとともに@setを使用を参照してください。

処理モードjson-ld-1.0に設定されていない場合は、キーワードのエイリアスは、値がキーワードであるシンプルな用語定義か、@idエントリーと、オプションで@protectedエントリーを持つ展開用語定義のいずれかで、その他のエントリーは許されていません。上記のように、@typeのエイリアスには例外もあります。@protectedの使用の詳細については、§ 4.1.11 保護された用語定義を参照してください。

キーワードは再定義できないため、他のキーワードのエイリアスにすることもできません。

エイリアシングされたキーワードは、コンテキスト自体の中では使用できません。

すべてのキーワードの規範的な定義については、§ 9.16 キーワードを参照してください。

4.1.7 コンテキスト内のIRIの展開

この項は非規範的です。

一般的に、通常のIRIの展開規則は、IRIが予期される場所であればどこにでも適用されます(§ 3.2 IRIを参照)。コンテキスト定義内では、これは、循環依存関係がない限り、コンテキスト内で定義された用語はそのコンテキスト内でも使用できることを意味しえます。例えば、型付き値を定義する際には、xsd名前空間を用いるのが一般的です。

39: コンテキスト内のIRIの展開
{
  "@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"
    }
  },
  ...
}

この例では、xsd用語を定義しており、age(年齢)プロパティーの@type強制の接頭辞として用いています。

用語は、別の用語IRIを定義するときにも使用できます。

40: 用語を用いてコンテキスト内で別の用語のIRIを定義
{
  "@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"
    }
  },
  ...
}

短縮IRIIRIは、用語定義の左辺で使用できます。

41: 短縮IRIを用語として使用
{
  "@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"
    }
  },
  ...
}

この例では、短縮IRIの形式を2つの異なる方法で用いています。最初のアプローチでは、foaf:ageは、(短縮形を用いた)用語IRIと、用語に関連付けられた@typeの両方を宣言しています。2番目のアプローチでは、用語に関連付けられた@typeのみを指定しています。foaf:homepageの完全なIRIは、コンテキスト内でfoaf接頭辞を検索することによって決まります。

警告

短縮IRI用語として用いる場合は、展開した時に短縮IRIが自然と持つと考えられる値に展開されなければなりません。これは、用語が別のIRIに展開されて望ましくない結果になりえることを防ぐための元の1.0のアルゴリズムに対する変更点です。

42: 異なるIRIへの短縮IRIの不正なエイリアシング
{
  "@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"
    }
  },
  ...
}

IRIは、コンテキスト内のキーの位置でも使用できます。

43: コンテキスト定義とIRIの関連付け
{
  "@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"
    }
  },
  ...
}

上記のIRIが一致するためには、JSON-LDドキュメントIRIを用いる必要があります。また、foaf:homepagehttp://xmlns.com/foaf/0.1/homepageと同じではないため、foaf:homepage{ "@type": "@id" }という宣言を用いないことに注意してください。つまり、接頭辞の検索メカニズムが適用される前に、文字列を直接比較することによりコンテキスト内で用語が検索されます。

警告

IRI参照短縮IRIも、他の関係付けのないIRIに展開することはできません。これは、この動作は許されていたものの推奨はされていなかった、元の1.0のアルゴリズムに対する変更点です。

コンテキスト内で用語を用いる場合のその他の唯一の例外は、循環定義が許されないことです。つまり、term2term1に依存している場合は、term1の定義はterm2の定義に依存できません。例えば、次のコンテキスト定義は無効です。

44: コンテキスト内の用語の不正な循環定義
{
  "@context": {
    "term1": "term2:foo",
    "term2": "term1:bar"
  },
  ...
}

4.1.8 範囲付きコンテキスト

この項は非規範的です。

展開用語定義には@contextプロパティーを含めることができます。これは、その用語を用いて定義されたプロパティーのコンテキスト(範囲付きコンテキスト)を定義します。プロパティーに用いた場合、これはプロパティーの範囲付きコンテキストと呼ばれます。これにより、値は、値が含まれているノード・オブジェクトとは異なる用語定義基底IRI語彙マッピングデフォルトの言語を、コンテキストが値自体の中で指定されているかのように使用できます。

このケースでは、ソーシャル・プロファイルはschema.org語彙を用いて定義していますが、関心(interest)はFOAFからインポートされています。そして、それを用いて、プロパティーがFOAF語彙に由来するようになったManuの関心の1つを表すノードを定義しています。

このドキュメントを展開すると、外部コンテキストで定義されている用語と、プロパティーの範囲付きコンテキスト内でその用語に対して特別に定義されている用語の組み合わせが用いられます。

範囲付けは、@typeの値として用いられる用語を用いて実行することもできます。

@typeでの範囲付けは、異なる型のものを共通のプロパティーを用いて関連付ける場合に役立ち、その場合、異なるエンティティー内で用いられている語彙には、異なるコンテキストの範囲が必要です。例えば、hasPart/partOfはドキュメントで用いられる共通の用語でありえますが、コンテキストによって異なる意味になります。型の範囲付きコンテキストは、型が用いられているノード・オブジェクトに対してのみ有効です。以前の範囲内のコンテキストは、別のノード・オブジェクトにトラバースするときに再び有効になります。§ 4.1.9 コンテキストの伝播でさらに説明しているように、これは@propagateキーワードを用いて制御できます。

ノード・オブジェクトに導入されていたプロパティーの範囲付きやローカル・コンテキストは、別のノード・オブジェクトへとトラバースする場合にも有効です。

展開時には、@typeの各値は、その値が独自の型の範囲付きコンテキストを持つアクティブ・コンテキスト内の用語でもある場合に考慮されます(辞書順に順序付け)。その場合には、その範囲付きコンテキストアクティブ・コンテキストに適用されます。

@typeの値は順不同であるため、複数の型が列挙されている場合、型の範囲付きコンテキストが適用される順序は、辞書順です。

例えば、次のセマンティック的に同等な例について考えてみましょう。最初の例は、プロパティーと型が独自の範囲付きコンテキストを定義する方法を示しており、それは展開時に含まれます。

47: 組み込みコンテキストと範囲付きコンテキストを用いた展開
{
  "@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"
  }
}

コンテキストは、その定義方法に応じて処理されます。プロパティーの範囲付きコンテキストが最初に処理され、次に組み込みコンテキスト、続いて最後に型の範囲付きコンテキストが、適切な順序で処理されます。前の例は、論理的に次の例と同等です。

48: 組み込みコンテキストと範囲付きコンテキストを用いた展開(同等の組み込み)
{
  "@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"
  }
}

用語範囲付きコンテキストを定義していて、その用語が後で再定義された場合、以前の展開用語定義で定義されていたコンテキストの関連付けは、その再定義の範囲内では失われます。これは、§ 4.1 高度なコンテキストの使用で説明しているように、以前のあまり深く入れ子になっていなかった定義の以前の用語定義を上書きする用語の用語定義と整合性があります。

範囲付きコンテキストは、JSON-LD 1.1の新機能です。

4.1.9 コンテキストの伝播

この項は非規範的です。

一度導入したコンテキストは、型の範囲付きコンテキストを除き、@contextnullに設定したり用語を再定義したりすることにより、後続のコンテキストによって削除されるまで有効であり続け、次のノード・オブジェクトが入力されるまでそのコンテキストの効果を制限します。この動作は、@propagateキーワードを用いて変更できます。

次の例では、@propagatefalseに設定したコンテキストで定義されている用語が、新しいノード・オブジェクトへと伝わる際にどのように効果的に削除されるかを示しています。

JSON-LD 1.1処理アルゴリズムとAPIにおけるロールバックの定義方法のため、配列内に含まれるコンテキストはすべて@propagateに対して同じ値を持っていなければなりません。

4.1.10 インポートされたコンテキスト

この項は非規範的です。

JSON-LD 1.0では、有効なコンテキストを変更するためのメカニズムを導入しました。これには、遠隔のコンテキストを読み込んで処理した後で、新しいコンテキストを介してそれに変更を追加適用する機能が含まれていました。

しかし、JSON-LD 1.1の導入にあたっては、遠隔のコンテキスト、特に既存のJSON-LD 1.0のコンテキスト、を読み込み、処理前にJSON-LD 1.1機能を適用できることも望まれます。

コンテキスト@importキーワードを用いることにより、別の遠隔のコンテキスト(インポートされたコンテキストと呼ぶ)を処理前に読み込んで変更できます。変更点は、@importキーワードが含まれているコンテキスト(ラッピング・コンテキストと呼ぶ)で表されます。インポートされたコンテキストが読み込まれると、処理前にラッピング・コンテキストの内容がそれに結合されます。結合の操作により、ラッピング・コンテキスト内の個々のキー-値のペアは、ラッピング・コンテキストのキー-値のペアを優先して、読み込まれてインポートされたコンテキストに追加されます。

既存のコンテキストを再利用し、処理前にインラインで編集できるようにすることにより、コンテキスト全体のキーワードを適用して、インポートされたコンテキストのすべての用語定義を調整することができます。同様に、処理前に用語定義を置き換えることができ、それによって、例えば、用語定義を以前保護されていた用語と一致させたり、追加の型強制の情報を含めるなどの調整が可能になります。

次の例は、他の同様の変更を加えるための技術として、@importを用いてインポートされたコンテキストを読み込み、@propagatetrueに設定する、型の範囲付きコンテキストを表す方法を示しています。

https://json-ld.org/contexts/remote-context.jsonldというURLを介して遠隔で参照できる次のコンテキストがあったとします。

50: 型の範囲付きコンテキストにインポートされる遠隔のコンテキスト
{
  "@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",
    ...
  }
}

ラッピング・コンテキストを用いて、それを取得して変更できます。

51: 型の範囲付きコンテキスト内のコンテキストを取得し、伝播するように設定
{
  "@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
      }
    }
  }
}

結果は、インポートされたコンテキスト全体が型の範囲付きコンテキストにコピーされた場合と同じです。

52: 型の範囲付きコンテキスト内のコンテキストを取得し、伝播するように設定した結果
{
  "@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
      }
    }
  }
}

同様に、ラッピング・コンテキストは、用語定義を置き換えたり、インポートされたコンテキスト用語定義の処理方法に影響を与える可能性がある他のコンテキスト全体のキーワードを設定したりすることができます。

53: コンテキストを取得して@vocabと用語定義を変更
{
  "@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の定義が置き換えられます。
  }
}

この場合も、インポートされたコンテキスト全体がコンテキストにコピーされた場合と同じ結果になります。

54: コンテキストを取得して@vocabと用語定義を変更した結果
{
  "@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#"
  }
}

インポートされたコンテキストを読み込んだ結果は、IRI配列ではなく、コンテキスト定義でなければなりません。さらに、インポートされたコンテキストに@importエントリーを含めることはできません。

4.1.11 保護された用語の定

この項は非規範的です。

JSON-LDは、多くの仕様で規定のデータ形式として用いられています。しかし、JSON-LDのアルゴリズムを用いずに、一部のJSON-LDコンテンツをプレーンなJSONとして処理したいという要望もあります。JSON-LDは非常に柔軟性が高いため、元の形式の一部の用語は、組み込みコンテキストを用いてローカルで上書きされ、JSON-LDベースの実装では異なる意味を持つことがあります。一方、「プレーンなJSON」の実装は、これらの組み込まれたコンテキストを解釈できない場合があり、したがって、これらの用語を元の意味で解釈します。この解釈の相違を防ぐために、JSON-LD 1.1では用語定義を保護することができます。

保護された用語の定義(protected term definition)は、@protectedエントリーtrueに設定した用語定義です。一般的に、同じ用語の新しい定義を用いるか、 "@context": nullでコンテキストを消去することにより、それ以上のコンテキストによってこの用語の定義が上書きされることを防止します。このような試みを行うと、エラーが発生し、処理が中止されます(下記で説明している特定の状況を除く)。

55: 保護された用語の定義は一般的に上書き不可
{
  "@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"
  }
}

コンテキストのすべてまたは大部分の用語定義を保護する必要がある場合は、@protectedエントリーtrueに設定してコンテキスト自体に追加することができます。これは、それぞれの用語定義を個別に保護するのと同じ効果があります。一部の用語定義で@protectedエントリーfalseに設定して追加することにより、例外とすることができます。

保護された用語は一般的に上書きできませんが、この規則には2つの例外があります。最初の例外は、新しい定義が、保護されている用語の定義と同じである場合には(@protectedフラグを法として)、コンテキストは保護された用語を再定義できるというものです。原理は、新しい定義は、保護された用語のセマンティクスを変更しないため、保護に違反しないというものです。これは、@typeからtypeへのエイリアシングなど、いくつかのコンテキストで(保護された形式を含む)発生しえる広範な用語定義に役立ちます。

2番目の例外は、プロパティーの範囲付きコンテキストは保護の影響を受けないため、新しい用語の定義を用いるか、"@context": nullでコンテキストを消去するかのいずれかによって、保護された用語を上書きできます。

原理は、特定の仕様に依存している「プレーンなJSON」実装は、その仕様で定義されているプロパティーのみをトラバースするということです。指定されたプロパティーに属する範囲付きコンテキストは仕様の一部であるため、「プレーンなJSON」の実装では、それによって生じるセマンティクスの変更を認識していることが期待されます。その他のプロパティーに属している範囲付きコンテキストは、「プレーンなJSON」の実装で無視されるドキュメントの一部に適用されます。したがって、いずれの場合でも、JSON-LDに対応している実装と「プレーンなJSON」の実装との間で解釈が異なるリスクがないため、上書きが許されます。

用語の上書きを防ぐことにり、保護によって用語の調節(例えば、より詳細なデータ型を定義する、用語の使用をリストに制限するなど)もできなくなります。この種の調節は、一部の汎用的なコンテキストで頻繁に発生するため、保護によってユーザビリティーが妨げられるでしょう。そのため、コンテキストの公開者はこの機能を注意して用いる必要があります。

保護された用語の定義は、JSON-LD 1.1の新機能です。

4.2 値の記述

この項は非規範的です。

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

4.2.1 型付き値

この項は非規範的です。

型付き値としても知られる、型を関連付けられた値は、値を値の型を示すIRIに関連付けることによって示されます。JSON-LDでは、型付き値は次の3つの方法で表現できます。

  1. @contextセクション内で用語を定義する際に@typeキーワードを利用する。
  2. 値オブジェクトを利用する。
  3. 数値truefalseなどのネイティブなJSONの型を用いる。

最初の例では、@typeキーワードを用いて、@context内の特定の用語に型を関連付けています。

上記のmodified(変更)キーの値は、情報が@contextで指定されているため、自動的にdateTime値として解釈されます。例のタブは、JSON-LDプロセッサがデータをどのように解釈するかを示しています。

2番目の例では、JSON-LDドキュメントの本文に型情報を設定する展開形式を用いています。

上記のどちらの例でも、http://www.w3.org/2001/XMLSchema#dateTimeという型を持つ2010-05-29T14:17:39+02:00という値が生成されます。型の値を表すために、用語短縮IRIを用いることもできることに注意してください。

@typeキーワードは、ノードに型を関連付けるためにも用います。ノード型値型の概念は異なります。ノードに対する型の追加の詳細については、§ 3.5 型の指定を参照してください。

展開時に、用語定義内で定義されている@type文字列の値に関連付けて、展開された値オブジェクトを作成できます。これについては、§ 4.2.3 型の強制で説明しています。型の強制は文字列の値に対してのみ行われ、展開形式のノード・オブジェクト値オブジェクトなどのマップである値に対しては行われません。

ノード型は、人、場所、イベント、ウェブ・ページなどの記述されているものの型を規定します。値型は、整数、浮動小数点数、日付などの特定の値のデータ型を規定します。

61: @typeに対するコンテキスト依存性を示す例
{
  ...
  "@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"  ← これは値型です。
  }
  ...
}

最初の@typeの使用により、ノード型(http://schema.org/BlogPosting)が@idキーワードを用いて表されているノードに関連付けられます。2番目の@typeの使用により、値型(http://www.w3.org/2001/XMLSchema#dateTime)が@valueキーワードを用いて表されている値に関連付けられます。原則として、@value@typeが同じマップ内で用いられている場合、@typeキーワード値型を表します。それ以外の場合は、@typeキーワードノード型を表します。上記の例は、次のデータを表します。

4.2.2 JSONリテラル

この項は非規範的です。

JSON-LDとして解釈されないJSON-LD内にJSONを含めると便利な場合があります。一般的に、JSON-LDプロセッサはIRIにマッピングされていないプロパティーを無視しますが、これにより、そのプロパティーは、様々なアルゴリズム変換の実行時に除外されます。しかし、記述されているデータ自体がJSONである場合は、アルゴリズム変換を切り抜けて存続することが重要です。

警告

JSON-LDは、コンテキストを用いることにより、ネイティブなJSONを解釈できるようにすることを目指しています。JSONリテラルを用いると、解釈に使用できないデータのブロブ(blob)が作成されます。これは、JSONをJSON-LDとして表現できない稀なケースでのみ用います。

@type@jsonに設定して用語を定義すると、JSON-LDプロセッサは値をJSON-LDとして解釈するのではなく、JSONリテラルとして扱います。展開ドキュメント形式では、このようなJSONは、"@type": "@json"を持つ値オブジェクト内の@valueの値になるでしょう。

JSONリテラルは、RDFに変換すると、[JSON-LD11-API]の短縮アルゴリズムJSONデータ型で記述されているとおり、JSONの特定のシリアル化に基づく字句形式になります。

次の例は、プロパティーの値として含まれているJSONリテラルの例を示しています。RDFの結果では、正規化形式のJSONを用いて、異なるプロセッサ間の相互運用性を確保していることに注意してください。JSONの正規化については、[JSON-LD11-API]のデータ・ラウンドトリップで説明しています。

一般的に、JSON-LDプロセッサがnullに遭遇すると、関連付けられているエントリーや値は削除されます。しかし、nullは有効なJSONトークンであり、JSONリテラルの値として用いた場合は、nullの値は保持されます。

4.2.3 型の強制

この項は非規範的です。

JSON-LDは、特定のデータ型に対する文字列の値の強制をサポートしています。型の強制により、JSON-LDを展開している人が文字列のプロパティー値を用いて、IRIを展開された値オブジェクト表現の値に関連付けることにより、その値を型付き値として解釈させることができます。型の強制を用いると、個々のデータでデータ型を明示的に指定する必要なく、文字列の値の表現を使用できます。

型の強制は、@typeキーを用いて展開用語定義内で指定します。このキーの値はIRIに展開されます。または、@id@vocabキーワードを値として用いて、JSON-LDドキュメントの本文内で、@id@vocabに強制された用語文字列の値をIRIとして解釈することを示すこともできます。@id@vocabの違いは、値がIRIに展開される方法です。@vocabは、最初にそれを用語として解釈することによって値を展開しようとします。一致する用語アクティブ・コンテキスト内で見つからなければ、値にコロンがある場合はIRIまたは短縮IRIとして展開しようとします。それ以外の場合は、アクティブ・コンテキスト語彙マッピングがあれば、それを用いて値を展開します。対照的に、@idに強制された値は、コロンが存在する場合、IRI短縮IRIとして展開されます。それ以外の場合は、相対IRI参照として解釈されます。

用語定義を用いて値を強制する性能は、ノード・オブジェクトに1つ以上の型を設定することとは異なります。これは、前者ではグラフに新しいデータが追加されませんが、後者はグラフに関係を追加することによりノード型を管理するためです。

@typeキーの値として用いられる用語短縮IRIは、同じコンテキスト内で定義できます。つまり、xsdのような用語を指定した後で、同じコンテキスト定義内でxsd:integerを使用できます。

以下の例は、JSON-LDの作成者が値を型付き値IRIに強制する方法を示しています。

用語は、マップ・エントリーのキーや値など、語彙に対して相対的な(vocabulary-relative)位置の展開でのみ用いられることに注意することが重要です。@idの値はドキュメントに対して相対的(document-relative)であると見なされ、展開に用語定義を用いません。例えば、次について考えてみましょう。

予期しない結果として、「barney」は、どこで遭遇したかに応じてhttp://example1.com/barneyhttp://example2.com/barneyの両方に展開されます。関連付けられている用語定義のためにIRIとして解釈される文字列の値は通常、ドキュメントに対して相対的であると見なされます。場合によっては、用語定義"@type": "@vocab"を用いて規定されているこれらを、語彙に対して相対的に解釈することは理にかなっていますが、このような予期せぬ結果を招く可能性があります。

前の例では、「barney」は2回登場します。1回は常にドキュメントに対して相対的なIRIとして解釈される@idの値として登場し、もう1回は語彙に対して相対的であると定義されている「fred」の値(したがって、異なる展開値)として登場します。

これに関する詳細については、§ 4.1.2 デフォルトの語彙を参照してください。

@vocabの代わりに"@type": "@id"を用いている前の例のバリエーションは、ドキュメントに対して相対的に「barney」を解釈した場合の動作を示しています。

ex1:fred ex2:knows ex1:barney .というトリプルが2回出力されますが、重複するトリプルであるため、出力データセットには1回だけ存在します。

用語は、IRIまたは短縮IRIを用いて定義することもできます。これにより、シンプルな用語として表されていないキーに強制規則を適用できます。例えば、次のとおりです。

このケースでは、用語定義内の@idの定義はオプションです。これがある場合は、—接頭辞が定義されているか否かに関わらず—用語を表すIRIまたは短縮IRIは、常に@idで定義されているIRIに展開されます。

型の強制は常に展開されていないキーの値を用いて実行されます。上記の例では、型の強制はアクティブ・コンテキスト内でfoaf:ageを探して行われるのであって、対応する展開されたhttp://xmlns.com/foaf/0.1/ageというIRIで行われるのではないことを意味します。

コンテキスト内のキーは、展開および値の強制を目的とした用語として扱われます。その結果、同じ展開済みのIRIに対して複数の表現がありえます。例えば、dog(犬)とcat(猫)の両方をhttp://example.com/vocab#animalに展開するように指定することができます。これを行うことは、異なる型の強制や言語仕様の規則を確立するのに役立ちます。

4.2.4 文字列の国際化

この項は非規範的です。

文字列にその言語に関するアノテーションを付けることが重要な場合があります。JSON-LDでは、これは様々な方法で可能です。最初に、コンテキスト@languageキーを設定することにより、JSON-LDドキュメントのデフォルトの言語を定義できます。

上記の例では、jaという言語タグを花澄科学者の2つの文字列に関連付けています。言語タグは[BCP47]で定義されています。デフォルトの言語は、型の強制が行われていないすべての文字列の値に適用されます。

サブツリーのデフォルトの言語を消去するためには、次のとおり、範囲付きコンテキストなどの中間コンテキストで@languagenullに設定できます。

69: デフォルトの言語の消去
{
  "@context": {
    ...
    "@version": 1.1,
    "@vocab": "http://example.com/",
    "@language": "ja",
    "details": {
      "@context": {
        "@language": null
      }
    }
  },
  "name": "花澄",
  "details": {"occupation": "Ninja"}
}

次に、展開用語定義を用いて、言語を特定の用語に関連付けることができます。

70: 言語を用いた展開用語定義
{
  "@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",
  ...
}

上記の例では、忍者は指定されているデフォルトの言語タグであるjaに、Ninjaは言語タグenに、Nindžaは言語タグcsに関連付けられるでしょう。展開用語定義@languagenullにリセットされたため、name(名前)の値であるYagyū Muneyoshiはどの言語タグにも関連付けられないでしょう。

言語の関連付けは、プレーンな文字列にのみ適用されます。型付き値型の強制の対象である値には、言語タグは付与されません。

上記の例のとおり、システムは複数の言語でプロパティーの値を表す必要がある場合が多いです。通常、このようなシステムでは、開発者が言語固有のデータのデータ構造をプログラムで簡単にナビゲートできるようにしようとします。この場合、言語マップを利用できます。

71: 3つの言語でプロパティーを表している言語マップ
{
  "@context": {
    ...
    "occupation": { "@id": "ex:occupation", "@container": "@language" }
  },
  "name": "Yagyū Muneyoshi",
  "occupation": {
    "ja": "忍者",
    "en": "Ninja",
    "cs": "Nindža"
  }
  ...
}

上記の例は、前の例とまったく同じ情報を表しますが、すべての値を1つのプロパティーに統合しています。オブジェクト・プロパティーに対してドット表記法アクセサをサポートするプログラミング言語において特定の言語の値にアクセスするために、開発者はproperty.languageのパターンを使用できます(言語が主要言語のサブタグに限定されており、"en-us"などのその他のサブタグに依存していない場合)。例えば、英語で職業にアクセスするために、開発者はobj.occupation.enというコード・スニペットを用いるでしょう。

3番目に、値オブジェクトを用いてデフォルトの言語を上書きすることができます。

72: 展開された値を用いてデフォルトの言語を上書き
{
  "@context": {
    ...
    "@language": "ja"
  },
  "name": "花澄",
  "occupation": {
    "@value": "Scientist",
    "@language": "en"
  }
}

これにより、@languageタグを省略したり、値オブジェクトを用いて表現する際にnullに設定したりして、プレーンな文字列を指定できます。

73: 展開された値を用いて言語情報を削除
{
  "@context": {
    ...
    "@language": "ja"
  },
  "name": {
    "@value": "Frank"
  },
  "occupation": {
    "@value": "Ninja",
    "@language": "en"
  },
  "speciality": "手裏剣"
}

マッピングされている値の言語設定を行うための言語マップを用いた記述については、§ 9.8 言語マップを参照してください。

4.2.4.1 基本書字方向

この項は非規範的です。

文字列言語タグ付き文字列に、その基本書字方向のアノテーションを付けることもできます。言語と同様に、コンテキスト@directionキーを設定することにより、JSON-LDドキュメントのデフォルトの基本書字方向を定義できます。

上記の例では、ar-EGという言語タグと「rtl」という基本書字方向がHTML و CSS: تصميم و إنشاء مواقع الويبمكتبةという2つの文字列に関連付けられるでしょう。デフォルトの基本書字方向は、型の強制が行われていないすべての文字列の値に適用されます。

サブツリーでデフォルトの基本書字方向を消去するためには、次のとおり、範囲付きコンテキストなどの中間コンテキストで@directionnullに設定できます。

75: デフォルトの基本書字方向を消去
{
  "@context": {
    ...
    "@version": 1.1,
    "@vocab": "http://example.com/",
    "@language": "ar-EG",
    "@direction": "rtl",
    "details": {
      "@context": {
        "@direction": null
      }
    }
  },
  "title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
  "details": {"genre": "Technical Publication"}
}

次に、展開用語定義を用いて、基本書字方向を特定の用語に関連付けることができます。

76: 言語と方向性を用いた展開用語定義
{
  "@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",
  ...
}

上記の例では、次の3つのプロパティーが作成されます。

主語 プロパティー 言語 方向
_:b0 http://example.com/vocab/publisher مكتبة ar-EG
_:b0 http://example.com/vocab/title HTML و CSS: تصميم و إنشاء مواقع الويب ar-EG rtl
_:b0 http://example.com/vocab/title HTML and CSS: Design and Build Websites en ltr

基本書字方向の関連付けは、プレーンな文字列言語タグ付き文字列にのみ適用されます。型付き値型の強制の対象である値には、基本書字方向は付与されません。

3番目に、値オブジェクトを用いてデフォルトの基本書字方向を上書きすることができます。

77: 展開された値を用いてデフォルトの言語とデフォルトの基本書字方向を上書き
{
  "@context": {
    ...
    "@language": "ar-EG",
    "@direction": "rtl"
  },
  "title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
  "author": {
    "@value": "Jon Duckett",
    "@language": "en",
    "@direction": null
  }
}

基本書字方向のより深い議論については、ウェブ上の文字列: 言語と方向のメタデータ[string-meta]を参照してください。

4.3 値の順序付け

この項は非規範的です。

JSON-LDの作成者は、配列を用いることにより、コンパクトな形で複数の値を表現できます。グラフにはノード間のリンクの順序は記述されないため、デフォルトでは、JSON-LD内の配列は含まれている要素の順序を伝えません。これは、デフォルトで順序付けされている通常のJSON配列とは正反対です。例えば、次のシンプルなドキュメントについて考えてみましょう。

複数の値は、展開形式を用いて表すこともできます。

上記の例は、ステートメントを生成しますが、それにも固有の順序はありません。

プロパティーの複数の値は通常同じ型ですが、JSON-LDではこれに制限はなく、プロパティーは様々な型の値を持つことができます。

ステートメントとして見た場合、値には固有の順序はありません。

4.3.1 リスト

この項は非規範的です。

順序付きコレクションという概念はデータ・モデル化においてかなり重要であるため、特定言語のサポートがあると有用です。JSON-LDでは、次のように、@listキーワードを用いてリストを表すことができます。

これは、この配列の使用を順序付きとして記述しており、ドキュメントを処理する際に順序が維持されます。指定された複数の値のプロパティーが、いずれもリストを用いる場合は、コンテキスト@container@listに設定することで簡略化できます。

RDFにおけるリストの実装は、「ステートメント」タブで示しているように、リストの末尾をrdf:nilという資源として定義し、rdf:firstrdf:restのプロパティーを用いて匿名ノードを互いにリンク付けすることに依存しています。これにより、順不同の一連のステートメント内で順序を表すことができます。

JSON-LDとTurtleはどちらも、順序付きリストを表すための省略形を提供しています。

JSON-LD 1.1は、リスト・オブジェクトの値自体がリスト・オブジェクトでありえる、リストのリストを完全にサポートしています。

"@container": "@list"という定義は、リストの配列の値をそれ自体がリストであると再帰的に記述することに注意してください。例えば、GeoJSON形式([RFC7946]を参照)では、座標位置の順序付きリストであり、2つ以上の数値の配列として表されます。

83: GeoJSONで表された座標
{
  "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]
        ]
    ]
  }
  //...
}

これらの例では、bbox座標内で表されている値が順序を維持することが重要であり、組み込みリスト構造を用いる必要があります。JSON-LD 1.1では、適切なコンテキスト定義を追加するだけで、再帰リストを用いてこれを表現できます。

座標に3つのレベルのリストが含まれていることに注意してください。

@listコンテナに関連付けられている用語の値は、1つの値しかない場合や値がまったくない場合でも、常に配列の形式で表されます。

4.3.2 集合

この項は非規範的です。

@list順序付きリストの記述に用いますが、@setキーワードは順不同の集合の記述に用います。JSON-LDドキュメントの本文における@setの使用は、単なる糖衣構文であるため、ドキュメントの処理時に最適化によって削除されます。しかし、@setはドキュメントのコンテキスト内で使用すると有用です。@setコンテナに関連付けられている用語の値は、通常であれば短縮形式の配列でない形式に最適化される、値が1つしかない場合であっても、常に配列の形式で表されます(§ 5.2 短縮ドキュメント形式を参照)。これにより、配列に1つの値しか含まれていない場合でも、データは常に配列形式であるため、JSON-LDドキュメントの後処理が容易になります。

これは、この配列の使用は順不同であると記述しており、ドキュメントを処理する際に順序が変わる場合があります。値の配列は、デフォルトで順不同ですが、コンテキスト@container@setに設定することでそれを明示できます。

JSON-LD 1.1以降、@setキーワードは、展開用語定義内で他のコンテナ仕様と組み合わせ、同様に配列を用いてインデックスの短縮形の値を一貫して表すようにすることができます。詳細な議論については、§ 4.6 インデックス付きの値を参照してください。

4.3.3 @typeとともに@set使用

この項は非規範的です。

処理モードjson-ld-1.0に設定されていない場合は、@container@setに設定した展開用語定義内で@typeを使用できます。この展開用語定義内にその他のエントリーを設定することはできません。これは、@type(またはエイリアス)の値を常に配列で表すために短縮アルゴリズムで用います。

87: @typeに@container: @setを設定
{
  "@context": {
    "@version": 1.1,
    "@type": {"@container": "@set"}
  },
  "@type": ["http:/example.org/type"]
}

4.4 入れ子のプロパティー

この項は非規範的です。

多くのJSON APIは、中間オブジェクトを用いてプロパティーをエンティティーから分離します。JSON-LDでは、これを入れ子のプロパティーと呼びます。例えば、ラベルの集合を共通のプロパティー下でグループ化することができます。

@nestキーワードを用いてlabels(ラベル)を定義すると、JSON-LDプロセッサは、labelsプロパティーを用いて作成された入れ子を無視し、含んでいるオブジェクト内でそれが直接宣言されているかのようにコンテンツを処理します。この場合、labelsプロパティーはセマンティック的に無意味です。それを@nestと同等と定義すると、展開時に無視され、次と同等になります。

同様に、用語定義には、@nestへとエイリアス化された用語を参照する@nestプロパティーを含むことができ、それによって、そのプロパティーは短縮時にそのエイリアス化された用語下で入れ子になります。以下の例では、main_labelother_labelの両方が"@nest": "labels"で定義されており、これにより、短縮時にlabels下でシリアル化されます。

90: プロパティーの入れ子を定義 - 展開の入力
[{
  "@id": "http://example.org/myresource",
  "http://xmlns.com/foaf/0.1/homepage": [
    {"@id": "http://example.org"}
  ],
  "http://www.w3.org/2004/02/skos/core#prefLabel": [
    {"@value": "This is the main label for my resource"}
  ],
  "http://www.w3.org/2004/02/skos/core#altLabel": [
    {"@value": "This is the other label"}
  ]
}]
91: プロパティーの入れ子を定義 - コンテキスト
{
  "@context": {
    "@version": 1.1,
    "skos": "http://www.w3.org/2004/02/skos/core#",
    "labels": "@nest",
    "main_label": {"@id": "skos:prefLabel", "@nest": "labels"},
    "other_label": {"@id": "skos:altLabel", "@nest": "labels"},
    "homepage": {"@id": "http://xmlns.com/foaf/0.1/homepage", "@type": "@id"}
  }
}

入れ子のプロパティーは、JSON-LD 1.1の新機能です。

4.5 組み込み

この項は非規範的です。

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

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

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

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

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

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

4.5.1 空白ノードの識別

この項は非規範的です。

IRIノードを一意に識別できなくても情報を表現できる必要がある場合があります。この種のノードは、空白ノードと呼ばれます。JSON-LDでは、すべてのノードを@idを用いて識別する必要はありません。しかし、一部のグラフのトポロジーでは、識別子をシリアル化できる必要があります。例えば、ループが含まれているグラフは、組み込みのみを用いてシリアル化することはできず、@idを用いてノードを接続しなければなりません。これらの状況では、下線(_)をスキームとして用いたIRIのように見える空白ノード識別子を使用できます。これにより、ドキュメント内でローカルにノードを参照できますが、外部ドキュメントからノードを参照することはできなくなります。空白ノード識別子は、それが用いられているドキュメントを範囲とします。

上記の例には、IRIで識別できない2つの秘密のエージェントに関する情報が含まれています。空白ノード識別子を用いなくてもagent 1agent 2を知っていることを表すことはできますが、agent 2から参照できるように、agent 1に識別子を割り当てる必要があります。

処理中に空白ノード識別子を再びラベル付けできることは注目に値します。空白ノードを複数回参照することに開発者が気づいた場合は、他のドキュメントからも参照できるように、逆参照可能なIRIを用いてノードに名前を付けることを検討すべきです。

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.6.1 データのインデックス化

この項は非規範的です。

データベースは通常、データへのアクセスをより効率化するために用います。開発者はこの種の機能をアプリケーション・データに拡張して、同様のパフォーマンス向上を実現することがよくあります。このデータはリンクト・データの観点からは意味がないかもしれませんが、アプリケーションには有用です。

JSON-LDでは、より効率的にアクセスできる形式にデータを構造化するために使用できるインデックス・マップという概念を導入しています。データのインデックス化機能により、作成者は、キーをIRIにマッピングしないシンプルなキー-値マップを用いてデータを構造化できます。これにより、特定のアイテムを探すために配列をスキャンする必要なく、データに直接アクセスできるようになります。JSON-LDでは、このようなデータは、コンテキスト内で@indexキーワード@container宣言に関連付けることで指定できます。

上記の例では、athletes(アスリート)という用語インデックス・マップとして記述されています。catcher(キャッチャー)とpitcher(ピッチャー)のキーは、JSON-LDプロセッサによって、セマンティック的には無視されますが、構文的には保持されます。これをJavaScriptで用いると、開発者はobj.athletes.pitcherというコード・スニペットを用いて特定のアスリートにアクセスできるようになります。

データの解釈は、ステートメントの表で示しています。インデックスのキーがステートメントに表示されないことに注意が必要ですが、JSON-LDプロセッサを用いてドキュメントが短縮または展開される場合は(§ 5.2 短縮ドキュメント形式§ 5.1 展開ドキュメント形式を参照)、存在し続けるでしょう。

警告

RDFへのラウンドトリップ時にはデータのインデックスは保持されないため、この機能は慎重に用いるべきです。多くの場合、保持される、他のインデックス化方法のほうがより適切です。

@containerの値は、@index@setの両方が含まれている配列にすることもできます。これにより、短縮時にJSON-LDプロセッサがインデックスのすべての値に対して確実に配列形式を用いるようになります。

処理モードjson-ld-1.0に設定されていない場合は、@noneという特別なインデックスは、インデックスが関連付けられていないデータをインデックス化するために用いられ、正規化表現を維持するのに便利です。

4.6.1.1 プロパティー・ベースのデータのインデックス化

この項は非規範的です。

(上記の例のように)最もシンプルな形式では、データのインデックス化によってインデックス・マップのキーにセマンティクスは割り当てられません。しかし、オブジェクトのインデックス化に用いられるキーがそのオブジェクトにセマンティック的にリンクされていて、構文的にだけでなくセマンティック的にも保持すべきである場合もあります。

処理モードjson-ld-1.0に設定されていない場合は、用語の記述の"@container": "@index""@index"キーを付けることができます。そのキーの値は、各オブジェクトをそのキーにリンクしているセマンティックなプロパティーを識別するIRIにマッピングしなければなりません。

プロパティー・ベースのデータのインデックス化を用いる場合、インデックス・マップノード・オブジェクトでのみ使用でき、値オブジェクトグラフ・オブジェクトでは使用できません。値オブジェクトは特定のキーのみを持つように制限されており、任意のプロパティーをサポートしていません。

4.6.2 言語のインデックス化

この項は非規範的です。

複数の言語の文字列の値が含まれているJSONは、言語タグによってプロパティー値を容易にインデックス化できるように、言語マップを用いて表すことができます。これにより、特定のアイテムを探すために配列をスキャンする必要なく、言語の値に直接アクセスできるようになります。JSON-LDでは、このようなデータは、コンテキスト内で@languageキーワード@container宣言に関連付けることで指定できます。

上記の例では、label(ラベル)という用語言語マップとして記述されています。endeのキーは、JSON-LDプロセッサによってそれぞれの値に暗黙的に関連付けられます。これにより、開発者はobj.label.deというコード・スニペットを用いてドイツ語版のラベルにアクセスでき、これも、言語が主要言語のサブタグに限定されており、その他の"de-at"などのサブタグに依存しない場合にのみ適切です。

@containerの値は、@language@setの両方が含まれている配列にすることもできます。これにより、短縮時にJSON-LDプロセッサが言語タグのすべての値に対して確実に配列形式を用いるようになります。

処理モードjson-ld-1.0に設定されていない場合は、@noneという特別なインデックスは、言語のない文字列をインデックス化するために用いられます。これは、データ型のない文字列の値の正規化表現を維持するのに便利です。

4.6.3 ノード識別子のインデックス化

この項は非規範的です。

JSON-LDでは、インデックス・マップに加えて、データを構造化するためのidマップという概念を導入しています。IDのインデックス化機能により、作成者は、キーをIRIにマッピングしたシンプルなキー-値マップを用いてデータを構造化できます。これにより、特定のアイテムを探すために配列をスキャンする必要なく、関連付けられているノード・オブジェクトに直接アクセスできるようになります。JSON-LDでは、このようなデータは、コンテキスト内で@idキーワード@container宣言に関連付けることで指定できます。

上記の例では、post(投稿)という用語idマップとして記述されています。http://example.com/posts/1/enhttp://example.com/posts/1/deのキーは、ノード・オブジェクトの値の@idプロパティーとして解釈されるでしょう。

上記のデータの解釈は、JSON-LDプロセッサを用いた§ 4.6.1 データのインデックス化とまったく同じです。

@containerの値は、@id@setの両方が含まれている配列にすることもできます。これにより、短縮時にJSON-LDプロセッサがノード識別子のすべての値に対して確実に配列形式を用いるようになります。

@noneという特別なインデックスは、@idのないノード・オブジェクトをインデックス化するために用いられ、正規化表現を維持するのに便利です。@noneというインデックスは、以下の例で用いているnoneという用語のように、@noneに展開される用語にすることもできます。

idマップは、JSON-LD 1.1の新機能です。

4.6.4 ノード型のインデックス化

この項は非規範的です。

JSON-LDでは、idマップインデックス・マップに加えて、データを構造化するための型マップという概念を導入しています。型のインデックス化機能により、作成者は、キーをIRIにマッピングしたシンプルなキー-値マップを用いてデータを構造化できます。これにより、特定のノード・オブジェクト@typeに基づいてデータを構造化できます。JSON-LDでは、このようなデータは、コンテキスト内で@typeキーワード@container宣言に関連付けることで指定できます。

上記の例では、affiliation(提携)という用語型マップとして記述されています。schema:Corporationschema:ProfessionalServiceのキーは、ノード・オブジェクトの値の@typeプロパティーとして解釈されるでしょう。

@containerの値は、@type@setの両方が含まれている配列にすることもできます。これにより、短縮時JSON-LDプロセッサが型のすべての値に対して確実に配列形式を用いるようになります。

@noneという特別なインデックスは、@typeのないノード・オブジェクトをインデックス化するために用いられ、正規化表現を維持するのに便利です。@noneというインデックスは、以下の例で用いているnoneという用語のように、@noneに展開される用語にすることもできます。

idマップと同様に、@typeと一緒に用いると、@setコンテナにを含めて、キーの値が常に確実に配列に含まれるようにすることができます。

型マップは、JSON-LD 1.1の新機能です。

4.7 包含ノード

この項は非規範的です。

ノード・オブジェクトを別のノード・オブジェクトの一部として記載すると便利な場合があります。例えば、他の資源によって用いられている資源の集合を表すために。包含ブロックは、一次ノード・オブジェクトから参照できるそのような二次ノード・オブジェクトをまとめるためにも使用できます。例として、様々なアイテムのリストが含まれていて、その一部が共通要素を共有しているノード・オブジェクトについて考えてみましょう。

109: 包含ブロック
{
  "@context": {
    "@version": 1.1,
    "@vocab": "http://example.org/",
    "classification": {"@type": "@vocab"}
  },
  "@id": "http://example.org/org-1",
  "members": [{
    "@id":"http://example.org/person-1",
    "name": "Manu Sporny",
    "classification": "employee"
  }, {
    "@id":"http://example.org/person-2",
    "name": "Dave Longley",
    "classification": "employee"
  }, {
    "@id": "http://example.org/person-3",
    "name": "Gregg Kellogg",
    "classification": "contractor"
  }],
  "@included": [{
    "@id": "http://example.org/employee",
    "label": "An Employee"
  }, {
    "@id": "http://example.org/contractor",
    "label": "A Contractor"
  }]
}

これにより、フラット化時にemployee(従業員)とcontractor(請負人)の要素は、包含ブロックから外部の配列へと移動します。

包含される資源については、一部の一次資源に関連付けられている関連資源を含める方法として、JSON API[JSON.API]の関連資源の包含で説明されています。@includedは、JSON-LDでそれに似た可能性を提供します。

ノード・オブジェクト内での@includedの使用の副産物として、マップ@includedのみを含むことができ、§ 4.1 高度なコンテキストの使用で説明しているものと同様の機能を提供します。その場合、@graphは切断されたノードを記述するために用います。

しかし、@graphとは対照的に、@includedは同じマップ内に含まれる他のプロパティーとは相互作用を行いません。この機能については、§ 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.9.1 グラフ・コンテナ

この項は非規範的です。

JSON表現内で明示せずにデータを論理的に個別のグラフに分離すると便利な場合もあります。例えば、JSONドキュメントには、他のメタデータが言明されているデータを含むことができますが、@graphキーワードに関連付けられている構文オーバーヘッドなしに、名前付きグラフの概念を用いてデータ・モデル内でこのデータを分離すると便利です。

展開用語定義では、@graph@containerの値として使用できます。これは、この用語の値を名前付きグラフと見なすべきであることを示しており、そのグラフ名は、暗黙的な名前付きグラフを作成する自動的に割り当てられた空白ノード識別子です。展開した時に、これはシンプルなグラフ・オブジェクトになります。

別の例では、次のように、匿名の名前付きグラフを用いています。

上記の例は、ステートメントを作成する匿名の名前付きグラフを表します。デフォルト・グラフには、主語がそのステートメントを書いたと述べるステートメントが含まれています。これは、複数のステートメントを名前付きグラフに分離し、その名前付きグラフに含まれているステートメントについて言明を行う例です。

厳密に言えば、このような用語の値は名前付きグラフではなく、名前付きグラフに関連付けられたグラフ名であり、データセット内に別個に存在しています。

グラフ・コンテナは、JSON-LD 1.1の新機能です。

4.9.2 名前付きグラフのデータのインデックス化

この項は非規範的です。

インデックスによるノード・オブジェクトのインデックス化に加えて、グラフ・オブジェクトもインデックスによってインデックス化できます。@indexに加えて§ 4.9.1 グラフ・コンテナで紹介した@graphコンテナ型を用いることにより、そのようなプロパティーのオブジェクト値は、キーがIRIにマッピングされていないけれども、その値である名前付きグラフに関連付けられた@indexプロパティーから取得されるキー-値マップとして扱われます。これは、展開した時にシンプルなグラフ・オブジェクトでなければなりません。

次の例では、インデックス・マップを用いて複数の名前付きグラフを参照するデフォルト・グラフについて説明します。

インデックス・マップと同様に、@graphと一緒に用いると、@setをコンテナに含めて、キーの値が常に確実に配列に含まれるようにすることができます。

@noneという特別なインデックスは、@indexキーのないグラフをインデックス化するために用いられ、正規化表現を維持するのに便利です。しかし、@noneインデックスを用いて複数の識別子のない名前付きグラフが短縮されているドキュメントを短縮すると、それらのグラフの内容が統合されることに注意してください。これを防ぐには、個々のグラフに別個の@indexキーを指定します。

名前付きグラフ・データのインデックス化は、JSON-LD 1.1の新機能です。

4.9.3 名前付きグラフのインデックス化

この項は非規範的です。

識別子によるノード・オブジェクトのインデックス化に加えて、グラフ・オブジェクトもそのグラフ名によってインデックス化できます。@idに加えて§ 4.9.1 グラフ・コンテナで紹介した@graphコンテナ型を用いることにより、そのようなプロパティーのオブジェクト値は、キーがその値である名前付きグラフの識別子を表すキー-値マップとして扱われます。

次の例では、idマップを用いて複数の名前付きグラフを参照するデフォルト・グラフについて説明します。

idマップと同様に、@graphと一緒に用いると、@setをコンテナに含めて、キーの値が常に確実に配列に含まれるようにすることができます。

idマップと同様に、@noneという特別なインデックスは、@idのない名前付きグラフをインデックス化するために用いられ、正規化表現を維持するのに便利です。@noneというインデックスは、@noneに展開される用語にすることもできます。しかし、複数のグラフが@idなしに表されている場合、それらは展開時に統合されることに注意してください。これを防ぐには、@noneを慎重に用いて、グラフに独自の識別子を付けることを検討してください。

グラフ・コンテナは、JSON-LD 1.1の新機能です。

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

5. JSON-LDの形式

この項は非規範的です。

多くのデータ形式と同様に、JSON-LDでデータを正しく記述する方法は1つではありません。しかし、JSON-LDはグラフを記述するために用いられるため、リンクト・データとしての意味を変更せずに、特定の変換によってデータの形を変更できます。

展開ドキュメント形式
展開は、JSON-LDドキュメントを取得し、@contextが不要となるようにコンテキストを適用する処理です。この処理については、§ 5.1 展開ドキュメント形式で詳細に説明しています。
短縮ドキュメント形式
短縮は、提供されたコンテキストを既存のJSON-LDドキュメントに適用する処理です。この処理については、§ 5.2 短縮ドキュメント形式で詳細に説明しています。
フラット化ドキュメント形式
フラット化は、組み込まれているノードをJSONツリーの最上位レベルへと抽出し、その組み込まれているノードを参照に置き換え、必要に応じて空白ノード識別子を作成する処理です。この処理の詳細については、§ 5.3 フラット化ドキュメント形式で詳細に説明しています。
フレーム化ドキュメント形式
フレーム化は、JSON-LDドキュメントのデータを整形するために用います。これには、フラット化されたデータを一致させるためと、結果として得られるデータをどのように整形すべきかの例を示すための両方に用いられるフレーム・ドキュメントの例を用います。この処理については、§ 5.4 フレーム化ドキュメント形式で詳細に説明しています。

5.1 展開ドキュメント形式

この項は非規範的です。

JSON-LD 1.1処理アルゴリズムとAPI仕様[JSON-LD11-API]は、JSON-LDドキュメントを展開する方法を定義しています。展開とは、JSON-LDドキュメントを取得し、すべてのIRI、型、値が展開されるようにコンテキストを適用し、@contextが不要となるようにする処理です。

例えば、次のJSON-LD入力ドキュメントを想定してみましょう。

123: 展開される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入力ドキュメントを想定してみましょう。

125: 展開された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コンテキストを想定してみましょう。

126: コンテキストのサンプル
{
  "@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.2.1 IRIの短縮

この項は非規範的です。

展開されたJSON-LDドキュメントでは、IRIは常に絶対IRIとして表されます。多くの場合、相対IRI参照短縮IRI用語のいずれかのより短いバージョンを用いることをお勧めします。短縮では、コンテキスト内の要素の組み合わせを用いて、これらのIRIの短縮形が作成されます。詳細については、§ 4.1.2 デフォルトの語彙§ 4.1.3 基底IRI、および§ 4.1.5 短縮IRIを参照してください。

語彙マッピングは、語彙マッピングと一致するIRI接頭辞を削除することにより、語彙に対して相対的でありえるIRIを短縮するために使用できます。これは、IRIが語彙に対して相対的であると判断される場合、つまり、プロパティー@typeの値、または"@type": "@vocab"として記述された用語の値として用いられる場合に必ず行われます。

5.2.2 文字列としての値の表現

この項は非規範的です。

明確化のために、展開ドキュメント形式は常にノード・オブジェクト値オブジェクトを用いてノードと値を表します。さらに、プロパティー値は、値が1つしかない場合でも、常に配列内に含まれます。これはアクセスの統一性を維持するのに有用な場合がありますが、ほとんどのJSONデータは可能な限りシンプルな表現を用います。つまり、プロパティーは1つの値を持ち、文字列、またはノード・オブジェクトなどの構造化された値として表されます。デフォルトでは、短縮はシンプルな文字列である値を文字列として表しますが、値はIRI、日付、またはシンプルな文字列表現では情報が失われるその他の型付き値である場合があります。これを用語定義内で指定することにより、プロパティーとして用いられている用語の定義から文字列の値のセマンティクスを推測できます。詳細については、§ 4.2 値の記述を参照してください。

5.2.3 配列としてのリストの表現

この項は非規範的です。

§ 4.3.1 リストで説明しているように、JSON-LDには、@listキーワードを用いた、順序付きの値を表すための展開構文があります。JSON-LDの表現を簡略化するために、用語を"@container": "@list"で定義でき、それにより、この用語を用いているプロパティーのすべての値は順序付きであると見なされます。

5.2.4 ノード関係の逆

この項は非規範的です。

例えば、2人の人と、共通する1人の親との関係を記述する場合など、ノードに逆方向があると、2つのノードを関連付けるためのプロパティーをより適切に表現できる場合があります。詳細については、§ 4.8 逆プロパティーを参照してください。

逆プロパティーは、フレーム化と組み合わせるとさらに便利で、それにより、実際にノード・オブジェクトをドキュメントの最上位で定義して、組み込みノードにすることができます。JSON-LDは、用語定義内で適切な@container定義を定義することにより、そのような値をインデックス化する手段を提供します。

5.2.5 値のインデックス化

この項は非規範的です。

複数の値を持つプロパティーは通常、順不同の配列を用いて表されます。つまり、そのJSONの内部化された表現を扱うアプリケーションは、enという言語を用いた言語タグ付き文字列などの、特定のパターンに一致する値を見つけるために、配列の値を順に処理する必要があります。

データは、@id、@type、@language、@indexなどを含む、様々なキーでインデックス化できます。詳細については、§ 4.6 インデックス付きの値および§ 4.9 名前付きグラフを参照してください。

5.2.6 値をオブジェクトとして正規化

この項は非規範的です。

ドキュメントを短縮すると便利な場合がありますが、ノード・オブジェクトと値オブジェクトの表現は保持してください。このために、用語定義で"@type": "@none"と設定できます。これにより、値の短縮のアルゴリズムは常に値のオブジェクト形式を用いるようになりますが、その値の要素は短縮できます。

5.2.7 1つの値を配列として表現

この項は非規範的です。

一般的に、短縮時には、値が1つしかないプロパティーは文字列またはマップとして表され、複数の値を持つプロパティーは文字列またはマップの配列として表されます。つまり、このようなプロパティーにアクセスするアプリケーションは、どちらの表現も受け入れられるようにしておく必要があります。配列を用いて強制的にすべての値を表すためには、用語定義で"@container": "@set"と設定できます。さらに、@setは他のコンテナ設定と組み合わせて使用できます。例えば、§ 5.2.5 値のインデックス化の言語マップの例を見てください。

5.2.8 用語の選択

この項は非規範的です。

短縮時に、短縮アルゴリズムは、そのプロパティーの値がその用語定義@container@type、および@languageの仕様と一致する場合にのみ、プロパティーの用語を用いて短縮します。これにより、すべて同じIRIを持つ異なるプロパティー間で値を実際に分割することができます。一致する用語定義がない場合は、短縮アルゴリズムは、プロパティーの絶対IRIを用いて短縮を行います。

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

この項は非規範的です。

JSON-LD 1.1処理アルゴリズムとAPI仕様[JSON-LD11-API]は、JSON-LDドキュメントをフラット化する方法を定義しています。フラット化は、1つのマップ内のノードのすべてのプロパティーをまとめ、すべての空白ノード空白ノード識別子でラベル付けします。これにより、データの形が確保され、特定のアプリケーションでJSON-LDを処理するために必要なコードを大幅に簡略化できます。

例えば、次のJSON-LD入力ドキュメントを想定してみましょう。

137: フラット化される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フレームを想定してみましょう。

139: 図書館のフレームのサンプル
{
  "@context": {
    "@version": 1.1,
    "@vocab": "http://example.org/"
  },
  "@type": "Library",
  "contains": {
    "@type": "Book",
    "contains": {
      "@type": "Chapter"
    }
  }
}

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

フレーム要素と一致するフラット化されたオブジェクトの集合を用いる場合は、次の通りです。

140: フラット化された図書館オブジェクト
{
  "@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という型の最初のスクリプト要素フレームの検索に用いられるでしょう。

7. HTMLドキュメントにおけるJSON-LDの組み込み

この項では、HTMLスクリプト抽出をサポートしているdocumentLoaderで利用できる機能について説明しています。詳細については、遠隔のドキュメントとコンテキストの取得を参照してください。

JSON-LDコンテンツは、type属性をapplication/ld+jsonに設定してスクリプト要素に置くことにより、HTML[HTML]に容易に組み込むことができます。これにより、データ・ブロックが作成されます。

このようなデータの使用方法の定義は、この仕様の範囲を超えるものです。組み込まれているJSON-LDドキュメントはそのまま抽出されたり、例えば、RDFとして解釈されたりする可能性があります。

JSON-LDコンテンツがRDF[RDF11-CONCEPTS]として抽出される場合は、JSON-LDからRDFへの逆シリアル化アルゴリズム[JSON-LD11-API]を用いて、RDFデータセットに展開しなければなりません(MUST)。特定のスクリプトが対象でない場合は(§ 7.3 特定のJSON-LDスクリプト要素の位置指定を参照)、application/ld+jsonというtype(型)を持つすべてのスクリプト要素を処理し、同等の空白ノード識別子を別のスクリプト要素に含み、それらが1つのドキュメント内にあるかのように扱って、1つのデータセットに統合しなければなりません(MUST)(つまり、空白ノードが様々なJSON-LDスクリプト要素間で共有される)。

7.1 HTMLのbase要素からの基底IRIの継承

JSON-LDのスクリプト要素を処理する際に、[HTML]で定義されているように、含まれているHTMLドキュメントのドキュメントの基底URLを用いて、囲まれているJSON-LDコンテンツのデフォルトの基底IRIが確立されます。

HTMLでは、基底URLに対する動的な変更が許されています。この仕様では特定の動作を要求せず、すべてのシステムが基底IRIを同等に処理することを保証するために、作成者は、IRIを用いるか§ 4.1.3 基底IRIの定義のとおりに明示すべきです(SHOULD)。実装(特に[DOM]でネイティブに動作するもの)では、基底URLに対する動的な変更を考慮することができます(MAY)。

7.2 JSON-LDのscript要素のコンテンツに対する制限

この項は非規範的です。

HTMLの<script>要素のコンテンツに対する制限により、スクリプト要素に含まれるJSON-LDデータにエンコーディングの制限が追加適用されます。

作成者は、コメントの開始(comment-open)、スクリプトの開始(script-open)、コメントの終了(comment-close)、スクリプトの終了(script-close)と混同される可能性がある文字列を、HTMLに組み込まれたスクリプトで用いることを避けるべきです。

このようなコンテンツは、以下に示すようにエスケープすべきですが、JSON-LD API[JSON-LD11-API]による処理後もコンテンツはエスケープされたままになります。
  • &amp; → & (アンパサンド、U+0026)
  • &lt; → < (不等号(より小)、U+003C)
  • &gt; → > (不等号(より大)、U+003E)
  • &quot; → " (引用符、U+0022)
  • &apos; → ' (アポストロフィ、U+0027)

7.3 特定のJSON-LDスクリプト要素の位置指定

HTMLドキュメント内の特定のスクリプト要素の位置は、URLで指定されるHTMLドキュメント内のスクリプト要素の一意の識別子と一致するフラグメント識別子を用いて指定できます([DOM]を参照)。JSON-LDプロセッサは、指定されたデータ・ブロックの内容のみを抽出し、それを独立したJSON-LDドキュメントとして解析しなければならず(MUST)、その結果を同じHTMLドキュメントからの他のマークアップと統合してはなりません(MUST)。

例えば、http://example.com/documentにあるHTMLドキュメントを想定した場合、「dave」で識別されるスクリプト要素は、http://example.com/document#daveというURLを用いて対象にすることができます。

8. データ・モデル

JSON-LDは、JSONに基づくリンクト・データのシリアル化形式です。したがって、[RFC8259]のJSONで定義されている構文と、RDFデータ・モデル[RDF11-CONCEPTS]の拡張であるデータ・モデルを区別することが重要です。JSON-LDとRDFデータ・モデルがどのように関係しているかに関する正確な詳細は、§ 10. RDFとの関係で説明しています。

RDFモデルに慣れていない開発者が理解しやすいように、次のとおり、要約を提供します。

JSON-LDドキュメントには、上記で定義したデータ・モデルでは表現できないデータを含むことができます(MAY)。特に明記されていない限り、このようなデータは、JSON-LDドキュメントの処理中に無視されます。この規則の1つの結果として、IRI空白ノード、またはキーワードにマップされていないプロパティーは無視されます。

さらに、JSONのシリアル化形式は、リストマップ文字列数値ブール、およびnullの一般的な概念を用いてJSONドキュメントで表されるデータを記述する、JSON-LD内部表現を用いて内部的に表されます。

この画像は、デフォルト・グラフと2つの名前付きグラフを持つリンクト・データのデータセットを示しています。

1 リンクト・データのデータセットの図。
リンクト・データのデータセットの図の説明は付録にあります。SVGPNGの形式の画像を利用できます。

この図で説明しているデータセットは、次のように表すことができます。

最も外側のレベルで@graphを用いて、3つの最上位の資源(そのうちの2つは名前付きグラフ)を記述していることに注意してください。名前付きグラフは、@idに加えて@graphを用いて、グラフごとに名前を提供します。

9. JSON-LD文法

この項では、前の項で説明した構文規則をより形式的に説明します。

[RFC8259]で記述されているように、JSON-LDドキュメントは有効なJSONテキストであるか、有効なJSONテキストと同等のJSON-LD内部表現で表現できる形式でなければなりません(MUST)。

JSON-LDドキュメントは、1つのノード・オブジェクト@contextおよび/または@graphというエントリーのみで構成されるマップ、または0以上のノード・オブジェクト配列でなければなりません(MUST)。

JSONとは対照的に、JSON-LDでは、オブジェクト内のキーは一意でなければなりません(MUST)。

この文法でキーワードについて論じられている場合は常に、その言説はそのキーワードのエイリアスにも適用されます。

JSON-LDでは、キーワードをエイリアシングすることができます(詳細については、§ 4.1.6 キーワードのエイリアシングを参照)。例えば、アクティブ・コンテキスト@idという用語@idのエイリアスとして定義している場合、そのエイリアスを@idの代わりとして正当に使用できます。キーワードのエイリアスはコンテキストの処理中には展開されないことに注意してください。

9.1 用語

用語は、IRI空白ノード識別子、またはキーワードに展開される短縮形の文字列です。

用語は、@typeを除き、JSON-LDのキーワードと同じであってはなりません(MUST NOT)。

用語は、短縮IRI接頭辞として用いる場合は、IRIスキームと混同される接頭辞の潜在的な曖昧さを回避するために、[IANA-URI-SCHEMES]で定義されているURIスキームのリストから取得すべきではありません(SHOULD NOT)。同様に、短縮IRI用語の間の混同を避けるために、用語にはコロン(:)を含めるべきではなく(SHOULD NOT)、[RFC3987]で定義されているisegment-nz-ncの形式に制限すべきです(SHOULD)。

JSON-LDの将来のバージョンで追加のキーワードが導入される可能性があるため、前方互換性の問題を回避するために、用語は、1つ以上のALPHA文字([RFC5234]を参照)のみが後続する@という文字で始まるべきではありません(SHOULD NOT)。さらに、すべてのプログラミング言語が空のJSONキーを処理できるわけではないため、用語は空の文字列("")であってはなりません(MUST NOT)。

IRIへの用語のマッピングに関する詳細な議論ついては、§ 3.1 コンテキスト§ 3.2 IRIを参照してください。

9.2 ノード・オブジェクト

ノード・オブジェクトは、JSON-LDドキュメントによってシリアル化されたグラフ内のノードの0以上のプロパティーを表します。マップは、JSON-LDコンテキストの外部に存在し、かつ次の場合、ノード・オブジェクトです。

グラフ内のノードプロパティーは、ドキュメント内の様々なノード・オブジェクトに分散させることができます。その際には、様々なノード・オブジェクトのキーを統合して、その結果のノードのプロパティーを作成する必要があります。

ノード・オブジェクトマップでなければなりません(MUST)。IRI短縮IRIアクティブ・コンテキストで有効な用語、または下記のキーワード(または、そのようなキーワードのエイリアス)のうちの1つではないすべてのキーは、処理時に無視しなければなりません(MUST)。

ノード・オブジェクト@contextキーが含まれている場合、その値はnullIRI参照コンテキスト定義、またはこれらのいずれかで構成される配列でなければなりません(MUST)。

ノード・オブジェクト@idキーが含まれている場合、その値はIRI参照または短縮IRI(空白ノード識別子を含む)でなければなりません(MUST)。@idという値に関する詳細な議論については、§ 3.3 ノード識別子§ 4.1.5 短縮IRI、および§ 4.5.1 空白ノードの識別を参照してください。

ノード・オブジェクト@graphキーが含まれている場合、その値はノード・オブジェクトまたは0以上のノード・オブジェクト配列でなければなりません(MUST)。ノード・オブジェクト@idキーワードも含まれている場合、その値は名前付きグラフグラフ名として用いられています。@graphという値に関する詳細な議論については、§ 4.9 名前付きグラフを参照してください。特殊なケースとして、マップ@graph@context以外のキーが含まれておらず、マップがJSON-LDドキュメントのルートである場合、マップノード・オブジェクトとして扱われません。これは、接続されたグラフを形成しないノード・オブジェクトを定義する方法として用います。これにより、構成するすべてのノード・オブジェクトで共有されるコンテキストを定義できます。

ノード・オブジェクト@typeキーが含まれている場合、その値はIRI参照短縮IRI(空白ノード識別子を含む)、IRIに展開するアクティブ・コンテキストで定義された用語、またはこれらのいずれかの配列でなければなりません(MUST)。@typeという値に関する詳細な議論については、§ 3.5 型の指定を参照してください。

ノード・オブジェクト@reverseキーが含まれている場合、その値は逆プロパティーを表すエントリーが含まれているマップでなければなりません(MUST)。そのような逆プロパティーの個々の値は、IRI参照短縮IRI空白ノード識別子ノード・オブジェクト、またはこれらの組み合わせが含まれている配列でなければなりません(MUST)

ノード・オブジェクト@includedキーが含まれている場合、その値は包含ブロックでなければなりません(MUST)。包含ブロックに関する詳細な議論については、§ 9.13 包含ブロックを参照してください。

ノード・オブジェクト@indexキーが含まれている場合、その値は文字列でなければなりません(MUST)。@indexという値に関する詳細な議論については、§ 4.6.1 データのインデックス化を参照してください。

ノード・オブジェクト@nestキーが含まれている場合、その値はマップまたはマップ配列でなければならず(MUST)、値オブジェクトを含んではなりません(MUST NOT)。@nestという値に関する詳細な議論については、§ 9.14 プロパティーの入れ子化を参照してください。

キーワードではないノード・オブジェクト内のキーは、アクティブ・コンテキストを用いてIRIに展開できます(MAY)。IRIに展開されるキーに関連付けられる値は、次のうちの1つでなければなりません(MUST)。

9.3 フレーム・オブジェクト

フレーム化時には、フレーム・オブジェクトノード・オブジェクトを拡張して、フレーム化専用のエントリーを可能にします。

フレーム・オブジェクトの使用方法の説明については、[JSON-LD11-FRAMING]を参照してください。

9.4 グラフ・オブジェクト

グラフ・オブジェクト名前付きグラフを表し、それには明示的なグラフ名を含めることができます(MAY)。マップは、JSON-LDのコンテキストの外部に存在し、@graphエントリー(またはそのキーワードのエイリアス)を含み、JSON-LDドキュメントの最上部のマップではなく、@graph@index@idおよび@contextエントリーまたはこれらのキーワードのいずれかのエイリアスのみで構成されている場合、グラフ・オブジェクトです。

グラフ・オブジェクト@contextキーが含まれている場合、その値はnullIRI参照コンテキスト定義、またはこれらのいずれかで構成される配列でなければなりません(MUST)。

グラフ・オブジェクト@idキーが含まれている場合、その値は名前付きグラフの識別子(グラフ名)として用いられ、IRI参照または短縮IRI(空白ノード識別子を含む)でなければなりません(MUST)。@idという値に関する詳細な議論については、§ 3.3 ノード識別子§ 4.1.5 短縮IRI、および§ 4.5.1 空白ノードの識別を参照してください。

@idエントリーのないグラフ・オブジェクトシンプルなグラフ・オブジェクトであり、明示的な識別子のない名前付きグラフを表しますが、データ・モデルにはグラフ名がまだあり、これは暗黙的に割り当てられた空白ノード識別子です。

@graphキーの値は、ノード・オブジェクトまたは0以上のノード・オブジェクト配列でなければなりません(MUST)。@graphという値に関する詳細な議論については、§ 4.9 名前付きグラフを参照してください。

9.5 値オブジェクト

値オブジェクトは、型や言語を値に明示的に関連付けて型付き値または言語タグ付き文字列を作成するため、あるいは基本書字方向を関連付けるために用います。

値オブジェクトは、@valueキーが含まれているマップでなければなりません(MUST)。また、@type@language@direction@index@contextのキーを含めることもできますが(MAY)、@typeと、@language@directionのいずれかのキーの両方を同時に含めてはなりません(MUST NOT)。値オブジェクトには、IRIキーワードに展開されるその他のキーを含めてはなりません(MUST NOT)。

@valueキーに関連付ける値は、文字列数値truefalse、またはnullのいずれかでなければなりません(MUST)。@typeキーに関連付けられている値@jsonである場合、値は配列オブジェクトのいずれかでありえます(MAY)。

@typeキーに関連付ける値は、用語IRI短縮IRI語彙マッピングを用いてIRIに変換できる文字列、@json、またはnullでなければなりません(MUST)。

@languageキーに関連付ける値は、[BCP47]で記述されている字句形式か、nullでなければなりません(MUST)。

@directionキーに関連付ける値は、"ltr""rtl"のいずれか、またはnullでなければなりません(MUST)。

@indexキーに関連付ける値は文字列でなければなりません(MUST)。

値オブジェクトに関する詳細情報については、§ 4.2.1 型付き値§ 4.2.4 文字列の国際化を参照してください。

9.6 値のパターン

フレーム化時には、値のパターン値オブジェクトを拡張して、フレーム化専用のエントリーを可能にします。

9.7 リストと集合

リストは、順序付きの値の集合を表します。集合は、順不同の値の集合を表します。特に指定のない限り、JSON-LDでは配列は順不同です。そのため、@setキーワードは、JSON-LDドキュメントの本文で用いた場合には、ドキュメントの処理時に最適化によって削除される単なる構文糖衣を表します。しかし、ドキュメントのコンテキスト内で用いると非常に役立ちます。@setまたは@listのコンテナに関連付けられている用語の値は、ドキュメントが処理される際に、常に配列の形式で表されます—そうでない場合に短縮ドキュメントの配列でない形式に最適化される値が1つだけある場合でも。データは常に確定的な形式であるため、データの後処理がシンプルになります。

リスト・オブジェクトは、@list@index以外のIRIキーワードに展開されるキーが含まれていないマップでなければなりません(MUST)。

集合オブジェクトは、@set@index以外のIRIキーワードに展開されるキーが含まれていないマップでなければなりません(MUST)。@indexキーは処理時に無視されることに注意してください。

どちらの場合も、@list@setのキーに関連付けられる値は、次の型のうちの1つでなければなりません(MUST)。

集合とリストに関する詳細な議論については、§ 4.3 値の順序付けを参照してください。

9.8 言語マップ

言語マップは、プログラムが容易にアクセスできる方法で言語を値に関連付けるために用います。言語マップは、@container@languageに設定して用語が定義されている場合、または@language@setの両方が含まれている配列である場合に、ノード・オブジェクト内の用語の値として使用できます。言語マップのキーは、[BCP47]言語タグを表す文字列@noneというキーワード、または@noneに展開される用語でなければならず(MUST)、値は次の型のいずれかでなければなりません(MUST)。

言語マップに関する詳細な議論については、§ 4.2.4 文字列の国際化を参照してください。

9.9 インデックス・マップ

インデックス・マップでは、セマンティックな意味を持たないキーは許されていますが、それでもなお、そのキーは、JSON-LDドキュメントで用いるために保持すべきです。インデックス・マップは、@container@indexに設定して用語が定義されている場合、または@index@setの両方が含まれている配列である場合に、ノード・オブジェクト内の用語の値として使用できます。インデックス・マップエントリーの値は、次の型のうちの1つでなければなりません(MUST)。

このトピックに関する詳細情報については、§ 4.6.1 データのインデックス化 を参照してください。

インデックス・マップは、@graph@indexの両方が含まれていて、オプションで@setが含まれている配列に@containerを設定して用語が定義されている場合に、関連付けられている名前付きグラフにインデックスをマッピングするためにも使用できます。値は、参照キーを用いてインデックス化されている名前付きグラフ内に含まれているノード・オブジェクトで構成され、値に@idが含まれていない場合はシンプルなグラフ・オブジェクトとして、@idが含まれている場合は名前付きグラフとして表すことができます。

9.10 プロパティー・ベースのインデックス・マップ

プロパティー・ベースのインデックス・マップは、インデックスがプロパティー値としてグラフにセマンティック的に保持されているインデックス・マップの変種です。プロパティー・ベースのインデックス・マップは、@container@indexに設定して用語が定義されている場合、または@index@setの両方が含まれている配列である場合、そして@index文字列に設定して定義されている場合に、ノード・オブジェクト内の用語の値として使用できます。プロパティー・ベースのインデックス・マップの値は、ノード・オブジェクトまたはノード・オブジェクトに展開される文字列でなければなりません(MUST)。

展開時に、@indexの値に対する用語定義アクティブ・コンテキストに含まれている場合、この用語定義インデックス・マップのキーを展開するために用いられるでしょう。それ以外の場合は、キーはシンプルな値オブジェクトとして展開されるでしょう。インデックス・マップの展開された値の中の個々のノード・オブジェクトには、追加のプロパティー値が追加され、そのプロパティーは@indexの展開された値であり、その値は展開された参照キーです。

このトピックに関する詳細情報については、§ 4.6.1.1 プロパティー・ベースのデータのインデックス化を参照してください。

9.11 idマップ

idマップは、IRIを値に関連付け、プログラムが容易にアクセスできるようにするために用います。idマップは、@containerを@@idに設定して用語が定義されている場合、または@id@setの両方が含まれている配列である場合に、ノード・オブジェクト内の用語の値として使用できます。idマップのキーはIRI(IRI参照または短縮IRI(空白ノード識別子を含む))、@noneキーワード、または@noneに展開される用語でなければならず(MUST)、値はノード・オブジェクトでなければなりません(MUST)。

@idに展開されるプロパティーが値に含まれている場合、その値は参照キーと同等でなければなりません(MUST)。それ以外の場合は、値に由来するプロパティーは、展開時にノード・オブジェクトの値の@idとして用います。

idマップは、@graph@idの両方が含まれていて、オプションで@setが含まれている配列に@containerを設定して用語が定義されている場合に、その名前付きグラフグラフ名をマッピングするためにも使用できます。値は、参照キーを用いて名付けられる名前付きグラフ内に含まれるノード・オブジェクトで構成されます。

9.12 型マップ

型マップは、IRIを値に関連付け、プログラムが容易にアクセスできるようにするために用います。型マップは、@container@typeに設定して用語が定義されている場合、または@type@setの両方が含まれている配列である場合に、ノード・オブジェクト内の用語の値として使用できます。型マップのキーはIRI(IRI参照または短縮IRI(空白ノード識別子を含む))、用語、または@noneキーワードでなければならず(MUST)、値はノード・オブジェクトまたはノード・オブジェクトに展開される文字列でなければなりません(MUST)。

@typeに展開されるプロパティーが値に含まれており、参照キーと値の両方の適切な展開後の参照キーがその値に含まれている場合、ノード・オブジェクトには既に型が含まれています。それ以外の場合は、値に由来するプロパティーは、展開時にノード・オブジェクトの値の@typeとして追加されます。

9.13 包含ブロック

包含ブロックは、ノード・オブジェクトの集合を提供するために用います。包含ブロックは、@includedのキーか@includedのエイリアスのいずれかを持つノード・オブジェクトのメンバーの値として出現可能です(MAY)。包含ブロックは、ノード・オブジェクトノード・オブジェクトの配列のいずれかです。

展開時に、複数の包含ブロックが1つの包含ブロックに結合されるでしょう。

9.14 プロパティーの入れ子化

入れ子のプロパティーは、別個のマップ、または値オブジェクトではないマップ配列ノード・オブジェクトプロパティーを集めるために用います。これはセマンティック的には意識する必要はなく、展開の過程で削除されます。プロパティーの入れ子化は再帰的であり、入れ子のプロパティーのコレクションにさらに入れ子を含めることができます。

セマンティック的には、入れ子は、プロパティーと値が、含んでいるノード・オブジェクト内で直接宣言されているかのように扱われます。

9.15 コンテキスト定義

コンテキスト定義は、ノード・オブジェクトローカル・コンテキストを定義します。

コンテキスト定義は、キーが用語短縮IRIIRI、または@base@import@language@propagate@protected@type@version@vocabキーワードのうちの1つでなければならない(MUST)マップでなければなりません(MUST)。

コンテキスト定義@baseキーがある場合、その値はIRI参照またはnullでなければなりません(MUST)。

コンテキスト定義@directionキーがある場合、その値は"ltr""rtl"のいずれか、またはnullでなければなりません(MUST)。

コンテキスト定義@importキーワードが含まれている場合、その値はIRI参照でなければなりません(MUST)。@importからの参照として用いる場合、参照されるコンテキスト定義@importキー自体を含めてはなりません(MUST NOT)。

コンテキスト定義@languageキーがある場合、その値は[BCP47]で記述されている字句形式であるか、nullでなければなりません(MUST)。

コンテキスト定義@propagateキーがある場合、その値はtruefalseでなければなりません(MUST)。

コンテキスト定義@protectedキーがある場合、その値はtruefalseでなければなりません(MUST)。

コンテキスト定義@typeキーがある場合、その値は@containerというエントリーのみを@setに設定し、オプションで@protectedというエントリーを設定したマップでなければなりません(MUST)。

コンテキスト定義@versionキーがある場合、その値は1.1という値を持つ数値でなければなりません(MUST)。

コンテキスト定義@vocabキーがある場合、その値はIRI参照短縮IRI空白ノード識別子用語、またはnullでなければなりません(MUST)。

キーワードではないキーの値は、IRI短縮IRI用語空白ノード識別子キーワードnull、または展開用語定義のいずれかでなければなりません(MUST)。

9.15.1 展開用語定義

展開用語定義は、用語とその展開された識別子の間のマッピング、およびノード・オブジェクトでキーとして用いたときに用語に関連付けられる値のその他のプロパティーを記述するために用います。

展開用語定義は、@id@reverse@type@language@container@context@prefix@propagate、または@protectedの0以上のキーで構成されるマップでなければなりません(MUST)。展開用語定義には、その他のキーを含めるべきではありません(SHOULD NOT)。

関連付けられている用語が@typeである場合、展開用語定義@container@protected以外のキーを含めてはなりません(MUST NOT)。@containerの値は、@setという1つの値に限定されています。

定義されている用語がIRI短縮IRIでなく、アクティブ・コンテキスト@vocabマッピングがない場合は、展開用語定義@idキーが含まれていなければなりません(MUST)。

IRIまたは短縮IRIの形式のキーを持つ用語定義は、キー自体の展開以外のIRIに展開してはなりません(MUST)。

展開用語定義@idキーワードが含まれている場合、その値はnullIRI空白ノード識別子短縮IRI用語、またはキーワードでなければなりません(MUST)。

展開用語定義@reverseエントリーがある場合、@idまたは@nestエントリーが同時にあってはならず(MUST NOT)、その値はIRI空白ノード識別子短縮IRI、または用語でなければなりません(MUST)。@containerエントリーが存在する場合、その値はnull@set、または@indexでなければなりません(MUST)。

展開用語定義@typeキーワードが含まれている場合、その値はIRI短縮IRI用語null、または@id@json@none@vocabキーワードのうちの1つでなければなりません(MUST)。

展開用語定義@languageキーワードが含まれている場合、その値は[BCP47]で記述されている字句形式であるか、nullでなければなりません(MUST)。

展開用語定義@indexキーワードが含まれている場合、その値はIRI短縮IRI、または用語でなければなりません(MUST)。

展開用語定義@containerキーワードが含まれている場合、その値は@list@set@language@index@id@graph@typeのいずれか、またはnullか、これらのキーワードのいずれか1つを厳密に含む配列、または@setと、任意の順序の@index@id@graph@type@languageのいずれかとの組み合わせでなければなりません(MUST)。@containerは、@id@indexのいずれかとともに@graphを含み、オプションで@setを含む配列でもありえます。値が@languageである場合、用語@contextの外で用いられているときは、関連付けられている値は言語マップでなければなりません(MUST)。値が@indexである場合、用語@contextの外で用いられているときは、関連付けられている値はインデックス・マップでなければなりません(MUST)。

展開用語定義@contextエントリーがある場合、それは有効なcontext definition(コンテキスト定義)でなければなりません(MUST)。

展開用語定義@nestキーワードが含まれている場合、その値は@nest、または@nestに展開される用語のいずれかでなければなりません(MUST)。

展開用語定義@prefixキーワードが含まれている場合、その値はtruefalseでなければなりません(MUST)。

展開用語定義@propagateキーワードが含まれている場合、その値はtruefalseでなければなりません(MUST)。

展開用語定義@protectedキーワードが含まれている場合、その値はtruefalseでなければなりません(MUST)。

用語は循環的に用いてはなりません(MUST NOT)。つまり、ある用語の定義は、別の用語がその用語に依存している場合、その別の用語の定義に依存することはできません。

コンテキストに関する詳細な議論については、§ 3.1 コンテキストを参照してください。

9.16 キーワード

JSON-LDのキーワードについては、§ 1.7 構文トークンとキーワードで説明しており、この項では、個々のキーワードが様々なJSON-LD構造内のどこに出現するかについて説明します。

ノード・オブジェクト値オブジェクトグラフ・オブジェクトリスト・オブジェクト集合オブジェクト、および入れ子のプロパティー内では、@contextを除き、対応するキーワードの代わりにキーワードのエイリアスを使用できます(MAY)。@contextキーワードをエイリアス化してはなりません(MUST NOT)。ローカル・コンテキスト展開用語定義内では、キーワードのエイリアスは使用できません(MAY NOT)。

@base
エイリアス化されていない@baseキーワードは、コンテキスト定義でキーとして使用できます(MAY)。その値はIRI参照nullでなければなりません(MUST)。
@container
エイリアス化されていない@containerキーワードは、展開用語定義でキーとして使用できます(MAY)。その値は@list@set@language@index@id@graph@typeのいずれか、またはnullか、これらのキーワードのいずれか1つを厳密に含む配列、または@setと、任意の順序の@index@id@graph@type@languageのいずれかとの組み合わせでなければなりません(MUST)。値は、@id@indexのいずれかとともに@graphを含み、オプションで@setを含む配列でもありえます。
@context
@contextキーワードはエイリアス化してはならず(MUST NOT)、次のオブジェクトでキーとして使用できます(MAY)。 @contextの値は、nullIRI参照コンテキスト定義、またはこれらのいずれかで構成される配列でなければなりません(MUST)。
@direction
@directionキーワードはエイリアス化でき(MAY)、値オブジェクトでキーとして使用できます(MAY)。その値は"ltr""rtl"のいずれか、またはnullでなければなりません(MUST)。

エイリアス化されていない@directionは、コンテキスト定義でキーとして使用できます(MAY)。

詳細な議論については、§ 4.2.4.1 基本書字方向を参照してください。

@graph
@graphキーワードはエイリアス化でき(MAY)、ノード・オブジェクトまたはグラフ・オブジェクトでキーとして使用でき(MAY)、その値は値オブジェクトノード・オブジェクト、または値オブジェクトノード・オブジェクトのいずれかの配列でなければなりません(MUST)。

エイリアス化されていない@graphは、展開用語定義内で@containerキーの値として使用できます(MAY)。

§ 4.9 名前付きグラフを参照してください。

@id
@idキーワードはエイリアス化でき(MAY)、ノード・オブジェクトまたはグラフ・オブジェクトでキーとして使用できます(MAY)。

エイリアス化されていない@idは、展開用語定義でキーとして、または展開用語定義内で@containerキーの値として使用できます(MAY)。

@idキーの値は、IRI参照、または短縮IRI(空白ノード識別子を含む)でなければなりません(MUST)。

@idの値に関する詳細な議論については、§ 3.3 ノード識別子§ 4.1.5 短縮IRI、および§ 4.5.1 空白ノードの識別を参照してください。

@import
エイリアス化されていない@importキーワードは、コンテキスト定義で使用できます(MAY)。その値はIRI参照でなければなりません(MUST)。詳細な議論については、§ 4.1.10 インポートされたコンテキストを参照してください。
@included
@includedキーワードはエイリアス化でき(MAY)、その値は包含ブロックでなければなりません(MUST)。このキーワードについては、§ 4.7 内包ノード§ 9.13 包含ブロックで詳細に説明しています。
@index
@indexキーワードはエイリアス化でき(MAY)、ノード・オブジェクト値オブジェクトグラフ・オブジェクト集合オブジェクト、またはリスト・オブジェクトでキーとして使用できます(MAY)。その値は文字列でなければなりません(MUST)。

エイリアス化されていない@indexは、展開用語定義内で@containerキーの値として、そして展開用語定義でエントリーとして使用でき(MAY)、その値はIRI短縮IRI、または用語です。

詳細な議論については、§ 9.9 インデックス・マップ§ 4.6.1.1 プロパティー・ベースのデータのインデックス化を参照してください。

@json
@jsonキーワードはエイリアス化でき(MAY)、値オブジェクトまたは展開用語定義内で@typeキーの値として使用できます(MAY)。

§ 4.2.2 JSONリテラルを参照してください。

@language
@languageキーワードはエイリアス化でき(MAY)、値オブジェクトでキーとして使用できます(MAY)。その値は[BCP47]で記述されている字句形式文字列であるか、nullでなければなりません(MUST)。

エイリアス化されていない@languageは、コンテキスト定義でキーとして、または展開用語定義内で@containerキーの値として使用できます(MAY)。

§ 4.2.4 文字列の国際化§ 9.8 言語マップを参照してください。

@list
@listキーワードはエイリアス化でき(MAY)、リスト・オブジェクトでキーとして用いなければなりません(MUST)。エイリアス化されていない@listは、展開用語定義内で@containerキーの値として使用できます(MAY)。その値は次のうちの1つでなければなりません(MUST)。

集合とリストに関する詳細な議論については、§ 4.3 値の順序付けを参照してください。

@nest
@nestキーワードはエイリアス化でき(MAY)、ノード・オブジェクトでキーとして使用でき(MAY)、その値はマップでなければなりません。

エイリアス化されていない@nestは、シンプルな用語定義の値として、または展開用語定義でキーとして使用でき(MAY)、その値は@nestに展開される文字列でなければなりません(MUST)。

詳細な議論については、§ 9.14 プロパティーの入れ子化を参照してください。

@none
@noneキーワードはエイリアス化でき(MAY)、インデックス・マップidマップ言語マップ型マップでキーとして使用できます(MAY)。詳細な議論については、§ 4.6.1 データのインデックス化§ 4.6.2 言語のインデックス化§ 4.6.3 ノード識別子のインデックス化§ 4.6.4 ノード型のインデックス化§ 4.9.3 名前付きグラフのインデックス化、または§ 4.9.2 名前付きグラフのデータのインデックス化を参照してください。
@prefix
エイリアス化されていない@prefixキーワードは、展開用語定義でキーとして使用できます(MAY)。その値はtruefalseでなければなりません(MUST)。詳細な議論については、§ 4.1.5 短縮IRI§ 9.15 コンテキスト定義を参照してください。
@propagate
エイリアス化されていない@propagateキーワードは、コンテキスト定義で使用できます(MAY)。その値はtruefalseでなければなりません(MUST)。詳細な議論については、§ 4.1.9 コンテキストの伝播を参照してください。
@protected
エイリアス化されていない@protectedキーワードは、コンテキスト定義、または展開用語定義で使用できます(MAY)。その値はtruefalseでなければなりません(MUST)。詳細な議論については、§ 4.1.11 保護された用語定義を参照してください。
@reverse
@reverseキーワードはエイリアス化でき(MAY)、ノード・オブジェクトでキーとして使用できます(MAY)。

エイリアス化されていない@reverseは、展開用語定義でキーとして使用できます(MAY)。

@reverseキーの値は、IRI参照、または短縮IRI(空白ノード識別子を含む)でなければなりません(MUST)。

詳細な議論については、§ 4.8 逆プロパティー§ 9.15 コンテキスト定義を参照してください。

@set
@setキーワードはエイリアス化でき(MAY)、集合オブジェクトでキーとして用いなければなりません(MUST)。その値は次のうちの1つでなければなりません(MUST)。

エイリアス化されていない@setは、展開用語定義内で@containerキーの値として使用できます(MAY)。

集合とリストに関する詳細な議論については、§ 4.3 値の順序付けを参照してください。

@type
@typeキーワードはエイリアス化でき(MAY)、ノード・オブジェクトまたは値オブジェクトでキーとして使用でき(MAY)、その値は用語IRI参照、または短縮IRI(空白ノード識別子を含む)でなければなりません(MUST)。

エイリアス化されていない@typeは、展開用語定義でキーとして使用でき(MAY)、その値は@idまたは@vocabのいずれか、または展開用語定義内で@containerキーの値としても使用できます。

コンテキスト内では、@type展開用語定義のキーとして使用でき、そのエントリーは@container@protectedに限定されています。

このキーワードは、§ 3.5 型の指定§ 4.2.1 型付き値で詳細に説明しています。

@value
@valueキーワードはエイリアス化でき(MAY)、値オブジェクトでキーとして用いなければなりません(MUST)。その値のキーは、文字列数値truefalse、またはnullのいずれかでなければなりません(MUST)。このキーワードは、§ 9.5 値オブジェクトで詳細に説明しています。
@version
エイリアス化されていない@versionキーワードは、コンテキスト定義でキーとして使用できます(MAY)。その値は1.1という値を持つ数値でなければなりません(MUST)。このキーワードは、§ 9.15 コンテキスト定義で詳細に説明しています。
@vocab
エイリアス化されていない@vocabキーワードは、コンテキスト定義でキーとして、または展開用語定義@typeの値として使用できます(MAY)。その値はIRI参照短縮IRI空白ノード識別子用語、またはnullでなければなりません(MUST)。このキーワードは、§ 9.15 コンテキスト定義§ 4.1.2 デフォルトの語彙で詳細に説明しています。

10. RDFとの関係

JSON-LDは、[RDF11-CONCEPTS]で記述されている具象RDF構文です。したがって、JSON-LDドキュメントはRDFドキュメントでもJSONドキュメントでもあり、それに応じてRDFデータ・モデルのインスタンスを表します。しかし、JSON-LDは、RDFデータ・モデルを拡張して、オプションでJSON-LDが一般化RDFデータセットをシリアル化できるようにもします。RDFデータ・モデルに対するJSON-LDの拡張は次のとおりです。

プロパティーにラベル付けするための空白ノード識別子の使用は廃止されており、一般化RDFデータセットのサポートと同様に、JSON-LDの将来のバージョンでは削除される可能性があります。

要約すると、これらの違いは、JSON-LDがRDFのグラフデータセットをシリアル化できることを意味し、すべてではないものの、ほとんどのJSON-LDドキュメントは、RDF 1.1概念[RDF11-CONCEPTS]で説明されているように、RDFとして直接解釈できます。

作成者は、空白ノード識別子を用いてプロパティーにラベル付けしないようにすることを強くお勧めします。代わりに、次のいずれかの方法を検討してください。

JSON-LDをRDFとして解釈し、RDFをJSON-LDとしてシリアル化するための規範的なアルゴリズムは、JSON-LD 1.1処理アルゴリズムとAPI仕様[JSON-LD11-API]で規定されています。

JSON-LDはRDFデータセットをシリアル化しますが、グラフ情報源としても使用できます。その場合、利用者はデフォルト・グラフのみを用い、すべての名前付きグラフを無視しなくてはなりません(MUST)。これにより、サーバーはHTTP内容交渉を用いてTurtleやJSON-LDなどの言語でデータを公開できます。

データセットグラフの両方の構文をサポートしている公開者は、データセットをサポートしていない利用者が情報を処理できるように、一次データを確実にデフォルト・グラフに格納しなければなりません。

10.1 RDFのシリアル化/逆シリアル化

この項は非規範的です。

JSON-LDとしてのRDFのシリアル化、JSON-LDからRDFへの逆シリアル化の処理は、JSON-LD 1.1処理アルゴリズムとAPI仕様[JSON-LD11-API]のRDFシリアル化-逆シリアル化アルゴリズムで定義されているアルゴリズムの実行に依存します。これらのアルゴリズムに関するこれ以上の詳細な説明は、このドキュメントの範囲を超えていますが、処理について説明するために、必要な操作の概要を提供します。

JSON-LDドキュメントをRDFに逆シリアル化する手順には、次のステップが含まれます。

  1. JSON-LDドキュメントを展開し、コンテキストを削除します。これにより、プロパティー、型、値がIRIおよび展開された値として完全に表されます。展開については、§ 5.1 展開ドキュメント形式で詳細に論じています。
  2. ドキュメントをフラット化します。これにより、ドキュメントはノード・オブジェクトの配列に変換されます。フラット化については、§ 5.3 フラット化ドキュメント形式で詳細に論じています。
  3. ノード・オブジェクトを一連のトリプルに変換します。

例えば、次の短縮形式のJSON-LDドキュメントについて考えてみましょう。

151: 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の展開フラット化のアルゴリズムを実行すると、次の出力が生成されます。

152: 前の例をフラット化および展開した形式
[
  {
    "@id": "_:b0",
    "http://xmlns.com/foaf/0.1/name": "Dave Longley"
  }, {
    "@id": "http://manu.sporny.org/about#manu",
    "http://xmlns.com/foaf/0.1/name": "Manu Sporny"
  }, {
    "@id": "http://me.markus-lanthaler.com/",
    "http://xmlns.com/foaf/0.1/name": "Markus Lanthaler",
    "http://xmlns.com/foaf/0.1/knows": [
      { "@id": "http://manu.sporny.org/about#manu" },
      { "@id": "_:b0" }
    ]
  }
]

これをRDFに逆シリアル化することは、各ノード・オブジェクトを1つ以上のトリプルに変換するという簡単な処理となりました。これはTurtleでは次のように表現できます。

153: 展開/フラット化したドキュメントのTurtle表現
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

_:b0 foaf:name "Dave Longley" .

<http://manu.sporny.org/about#manu> foaf:name "Manu Sporny" .

<http://me.markus-lanthaler.com/> foaf:name "Markus Lanthaler" ;
    foaf:knows <http://manu.sporny.org/about#manu>, _:b0 .

RDFをJSON-LDとしてシリアル化する処理は、この最後のステップの逆と考えることができ、共通の主語を持っているすべてのトリプルに対する1つのノード・オブジェクトと、共通の述語も持っているそれらのトリプルに対する1つのプロパティーを用いて、RDFからのトリプルに非常に一致した展開されたJSON-LDドキュメントが作成されます。次に、[JSON-LD11-FRAMING]で記述されているフレーム化アルゴリズムを用いて結果をフレーム化し、望ましいオブジェクトの組み込みを作成できます。

10.2 rdf:JSONデータ型

RDFは、JSONコンテンツをリテラル値になり得るものとして提供します。これにより、リテラル値によるマークアップが可能になります。このようなコンテンツは、データ型をrdf:JSONに設定したリテラルを用いてグラフで示されます。

rdf:JSONというデータ型は次のように定義されています。

このデータ型を示すIRI
http://www.w3.org/1999/02/22-rdf-syntax-ns#JSONです。
字句空間
[RFC8259]の2項 JSON文法で記述されているJSON文法に準拠しているUNICODE[UNICODE]の文字列集合です。
値空間
[RFC8259]の2項 JSON文法で記述されているJSON文法に準拠し、さらに次の制約にも準拠しているUNICODE[UNICODE]の文字列集合です。
  • 不要な空白を含んではなりません(MUST NOT)。
  • オブジェクトのキーは、辞書順に並んでいなくてはなりません(MUST)。
  • ネイティブな数値は、[ECMASCRIPT]の7.1.12.1項に従ってシリアル化されていなければなりません(MUST)。
  • 文字列は、定義済みのJSON制御文字集合であるU+0008U+0009U+000AU+000CU+000D(それぞれ\b\t\n\f\rとしてシリアル化すべき(SHOULD))でない限り、小文字の16進Unicode表記法(\uhhhh)を用いて、U+0000からU+001FまでのUnicodeコードポイントでシリアル化しなければなりません(MUST)。その他のすべてのUnicode文字は、U+005C(\)とU+0022(")(それぞれ\\\"としてシリアル化すべき(SHOULD))を除き、「そのまま」シリアル化すべきです(SHOULD)。
課題
JSON正規化スキーム(JCS)[RFC8785]は、新しいJSON正規化の標準です。この仕様は、このような正規表現を必須とするように更新される可能性が高いです。このドキュメントの将来の改訂でシリアル化の仕様が変更される可能性があるため、RDFリテラルとしてのJSONリテラルの字句表現に依存しないように注意してください。
この値空間は、文字列集合として定義されていますが、既存の仕様での副作用を回避するために、xsd:stringの値空間とは異なるものと見なされます。
字句から値へのマッピング
字句空間の任意の要素を次の結果にマッピングします。
  1. [ECMASCRIPT]の24.5項 JSONオブジェクトで定義されているJSON.parse関数を用いて作成された[ECMASCRIPT]の表現と整合性がある内部表現へと解析し、
  2. 次に、上記の値空間の制約に準拠して、JSON形式[RFC8259]でシリアル化します。
正規マッピング
値空間の任意の要素を字句空間の同じ文字列にマッピングします。

10.3 i18n名前空間

この項は非規範的です。

i18n名前空間は、RDFリテラル言語タグ基本書字方向の組み合わせを記述するために用います。これは、[BCP47]のRDFリテラル言語タグ基本書字方向を記述するための代替メカニズム(それ以外の場合はxsd:stringrdf:langStringのデータ型を用いる)として用います。

この名前空間に基づくデータ型では、基本書字方向を用いたJSON-LDドキュメントのラウンドトリップが可能ですが、この方法は標準化されていません。

JSON-LDからRDFへの逆シリアル化アルゴリズムを、i18n-datatypeに設定したrdfDirectionというオプションとともに用いて、 i18nベースを用いてRDFリテラルを生成し、後に下線("_")、その後に@directionの値が続く@languageの値(ある場合は)をhttps://www.w3.org/ns/i18n#に追加することにより@directionを含んでいる値オブジェクトから、基本書字方向をオプションの言語タグ(小文字に正規化)とともにエンコードしたIRIを作成することができます。

相互運用性を向上させるために、データ型IRIの作成時に言語タグは小文字に正規化されます。

次の例では、i18n:ar-EG_rtlというリテラル値を持つ2つのステートメントを示しています。これは、ar-EGという言語タグと、rtlという基本書字方向をエンコードしています。

@prefix ex: <http://example.org/> .
@prefix i18n: <https://www.w3.org/ns/i18n#> .

# Note that this version preserves the base direction using a non-standard datatype.
[
  ex:title "HTML و CSS: تصميم و إنشاء مواقع الويب"^^i18n:ar-eg_rtl;
  ex:publisher "مكتبة"^^i18n:ar-eg_rtl
] .

文字列に対する基本書字方向の使用に関する詳細については、§ 4.2.4.1 基本書字方向を参照してください。

10.4 rdf:CompoundLiteralクラスおよびrdf:languagerdf:directionのプロパティー

この項は非規範的です。

この仕様はrdf:CompoundLiteralクラスを定義しており、これは、同じ主語上のrdf:valueの文字列の値に関連付けられる基本書字方向と可能な言語タグが含まれているRDFリテラルの値の記述に用いられるrdf:languagerdf:directionの定義域にあります。

rdf:CompoundLiteral
複合リテラルを表すクラス。
rdf:language
RDFプロパティー。プロパティーの値域はrdfs:Literalであり、その値は整形式の[BCP47]言語タグでなければなりません(MUST)。プロパティーの定義域はrdf:CompoundLiteralです。
rdf:direction
RDFプロパティー。プロパティーの値域はrdfs:Literalであり、その値は"ltr""rtl"のいずれかでなければなりません(MUST)。プロパティーの定義域はrdf:CompoundLiteralです。

JSON-LDからRDFへの逆シリアル化ゴリズムを、compound-literalに設定したrdfDirectionオプションとともに用いて、これらのプロパティーを用いてRDFリテラルを生成し、@directionとオプションで@languageを含んでいる値オブジェクトから、基本書字方向とオプションで言語タグ(小文字に正規化)を記述することができます。

相互運用性を向上させるために、データ型IRIの作成時に言語タグは小文字に正規化されます。

次の例は、ar-EGという言語タグと、rtlという基本書字方向を持つ文字列を表す複合リテラルが含まれている2つのステートメントを示しています。

@prefix ex: <http://example.org/> .

# Note that this version preserves the base direction using a bnode structure.
[
  ex:title [
    rdf:value "HTML و CSS: تصميم و إنشاء مواقع الويب",
    rdf:language "ar-eg",
    rdf:direction "rtl"
  ];
  ex:publisher [
    rdf:value "مكتبة",
    rdf:language "ar-eg",
    rdf:direction "rtl"
  ]
] .

文字列に対する基本書字方向の使用に関する詳細については、§ 4.2.4.1 基本書字方向を参照してください。

11. セキュリティに関する留意点

§ C. IANAに関する留意点セキュリティに関する留意点を参照してください。

この仕様の将来のバージョンでは、キャッシュされて取得されたコンテンツが遠隔サーバーから取得されたデータと一致することを保証する手段として、下位資源の完全性[SRI]が組み込まれる可能性があります。課題86を参照してください。

12. プライバシーに関する留意点

外部コンテキストの取得によりJSON-LDプロセッサの操作が公開され、中間ノードが、取得した資源のイントロスペクションを通じてクライアント・アプリケーションのフィンガープリントを行えるようになり([fingerprinting-guidance]を参照)、中間者攻撃の機会をもたらします。これを防ぐには、公開者は将来的な利用のために遠隔のコンテキストをキャッシュすることを検討するか、documentLoaderを用いてそのようなコンテキストのローカルなバージョンを維持すべきです。

13. 国際化に関する留意点

JSON-LDはRDFデータ・モデルを用いるため、左から右または右から左の方向の指標を有する文字列であるJSON-LD値を適切に記録する機能は、設計上制限されています。JSON-LDとRDFはいずれも、文字列に関連付けられている言語を指定する方法(言語タグ付き文字列)を提供していますが、文字列の基本書字方向を示す手段は提供しません。

Unicodeは、文字列内の方向を示唆するメカニズムを提供していますが(Unicode双方向アルゴリズム[UAX9]を参照)、文字列に、文字列の先頭では決定できない全体的な基本書字方向がある場合は、[HTML]のdir属性などの外部の指標が必要です。しかし、現在、RDFリテラルにはそれに相当するものはありません。

RDFで基本書字方向を適切に表すという課題は、それが制限であったりコアRDFデータ・モデルであったりするため、このワーキンググループで扱えるものではありません。このワーキンググループは、将来のRDFワーキンググループがこの問題を検討し、言語タグ付き文字列の基本書字方向を指定する機能を追加することを期待しています。

この仕様の将来のバージョンにおいてより包括的な解決策に対応できるようになるまで、公開者は、他の方法では文字列の内容に基づいて文字列の基本書字方向を正しく推測できない文字列を表す際に、この課題について考慮すべきです。ウェブで用いられる文字列の言語と基本書字方向を識別するためのベスト・プラクティスの議論については、[string-meta]を参照してください。

A. 画像の説明

この項は非規範的です。

A.1 リンクト・データのデータセット

この項は非規範的です。

この項では、§ 8. データ・モデルリンクト・データのデータセットの図について説明します。

画像は3つの破線のボックスで構成されており、それぞれ異なるリンクト・データ・グラフを示しています。各ボックスは、リンクト・データの関係を示す矢印でリンク付けされた図形で構成されています。

最初のボックスのタイトルは「default graph: <no name>」(デフォルト・グラフ: <名前なし>)で、http://example.com/people/alicehttp://example.com/people/bobの2つの資源(それぞれ、「Alice」と「Bob」を表している)が記述されており、2つの資源間の既知(knows)の関係を示すschema:knowsというラベルが付いた矢印で接続されています。さらに、「Alice」という資源は、次の3つの異なるリテラルに関連付けられています。

Alice
データ型や言語のないRDFリテラル。
weiblich | de
値が「weiblich」(女性)で言語タグが「de」(ドイツ語)の言語タグ付き文字列。
female | en
値が「female」(女性)で言語タグが「en」(英語)の言語タグ付き文字列。

2番目と3番目のボックスは、それぞれ「http://example.com/graphs/1」と「http://example.com/graphs/2」というグラフ名を持つ2つの名前付きグラフを示しています。

2番目のボックスは、schema:parentという関係によって関連付けられているhttp://example.com/people/alicehttp://example.com/people/bobの2つの資源で構成され、http://example.com/people/bobを「Bob」と名付けています。

3番目のボックスは、http://example.com/people/bobという名前の資源と、名前のない資源の2つの資源で構成されています。2つの資源は、schema:siblingという関係を用いて互いに関連付けられており、2番目の資源は「Mary」と名付けられています。

B. 他のリンクト・データ形式との関係

この項は非規範的です。

下記のJSON-LDの例は、JSON-LDを用いて、Turtle、RDFa、Microdataなどの他のリンクト・データ形式でマークアップしたセマンティックなデータを表現する方法を示しています。これらの項は、様々なリンクト・データのアプローチで表現できる内容に関して、JSON-LDの柔軟性が非常に高いことを示す証拠として提供しているに過ぎません。

B.1 Turtle

この項は非規範的です。

以下は、[Turtle]で表されているRDFをJSON-LDに変換する例です。

B.1.1 接頭辞の定義

JSON-LDのコンテキストには、Turtleの@prefix宣言に直接相当するのものがあります。

154: Turtleでシリアル化された一連のステートメント
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<http://manu.sporny.org/about#manu> a foaf:Person;
  foaf:name "Manu Sporny";
  foaf:homepage <http://manu.sporny.org/> .
155: JSON-LDでシリアル化された同じ一連のステートメント
{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/"
  },
  "@id": "http://manu.sporny.org/about#manu",
  "@type": "foaf:Person",
  "foaf:name": "Manu Sporny",
  "foaf:homepage": { "@id": "http://manu.sporny.org/" }
}

B.1.2 組み込み

[Turtle]とJSON-LDではどちらも組み込みが可能ですが、[Turtle]では空白ノードの組み込みのみが可能です。

156: Turtleにおける組み込み
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<http://manu.sporny.org/about#manu>
  a foaf:Person;
  foaf:name "Manu Sporny";
  foaf:knows [ a foaf:Person; foaf:name "Gregg Kellogg" ] .
157: JSON-LDにおける同じ組み込みの例
{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/"
  },
  "@id": "http://manu.sporny.org/about#manu",
  "@type": "foaf:Person",
  "foaf:name": "Manu Sporny",
  "foaf:knows": {
    "@type": "foaf:Person",
    "foaf:name": "Gregg Kellogg"
  }
}

B.1.3 ネイティブなデータ型の変換

JSON-LDでは、数値とブール値はネイティブなデータ型です。[Turtle]にはそのような値を表現するための省略構文がありますが、RDFの抽象構文では、数値とブール値を型付きリテラルとして表す必要があります。したがって、完全なラウンドトリップを可能にするために、JSON-LD 1.1処理アルゴリズムとAPI仕様[JSON-LD11-API]では、JSON-LDのネイティブなデータ型とRDFの対応するデータ型の間の変換規則を定義しています。小数が含まれていない数値xsd:integerという型付きリテラルに、小数が含まれている数値はxsd:doubleという型付きリテラルに、truefalseという2つのブール値はxsd:booleanという型付きリテラルに変換されます。すべての型付きリテラルは、正規字句形式です。

158: 数値とブール値にネイティブなデータ型を用いたJSON-LD
{
  "@context": {
    "ex": "http://example.com/vocab#"
  },
  "@id": "http://example.com/",
  "ex:numbers": [ 14, 2.78 ],
  "ex:booleans": [ true, false ]
}
159: 型付きリテラルを用いたTurtleの同じ例
@prefix ex: <http://example.com/vocab#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://example.com/>
  ex:numbers "14"^^xsd:integer, "2.78E0"^^xsd:double ;
  ex:booleans "true"^^xsd:boolean, "false"^^xsd:boolean .
この解釈は、2.78というリテラルがxsd:decimalに変換される[Turtle]とは異なることに注意してください。原理は、ほとんどのJSONツールが小数を含む数値を浮動小数点数として解析するため、RDFに戻して表すのにはxsd:doubleが最も適切なデータ型であることです。

B.1.4 リスト

JSON-LDと[Turtle]はどちらも、連続する値のリストを表すことができます。

160: Turtleの値のリスト
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<http://example.org/people#joebob> a foaf:Person;
  foaf:name "Joe Bob";
  foaf:nick ( "joe" "bob" "jaybee" ) .
161: JSON-LDの値のリストを用いた同じ例
{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/"
  },
  "@id": "http://example.org/people#joebob",
  "@type": "foaf:Person",
  "foaf:name": "Joe Bob",
  "foaf:nick": {
    "@list": [ "joe", "bob", "jaybee" ]
  }
}

B.2 RDFa

この項は非規範的です。

次の例は、3人の名前とホームページを個々にRDFa[RDFA-CORE]で記述しています。

162: 3人を記述しているRDFaの断片
<div prefix="foaf: http://xmlns.com/foaf/0.1/">
   <ul>
      <li typeof="foaf:Person">
        <a property="foaf:homepage" href="http://example.com/bob/">
          <span property="foaf:name">Bob</span>
        </a>
      </li>
      <li typeof="foaf:Person">
        <a property="foaf:homepage" href="http://example.com/eve/">
         <span property="foaf:name">Eve</span>
        </a>
      </li>
      <li typeof="foaf:Person">
        <a property="foaf:homepage" href="http://example.com/manu/">
          <span property="foaf:name">Manu</span>
        </a>
      </li>
   </ul>
</div>

1つのコンテキストを用いたJSON-LDの実装例を以下に示します。

163: JSON-LDによる同じ記述(ノード・オブジェクト間で共有されるコンテキスト)
{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "foaf:homepage": {"@type": "@id"}
  },
  "@graph": [
    {
      "@type": "foaf:Person",
      "foaf:homepage": "http://example.com/bob/",
      "foaf:name": "Bob"
    }, {
      "@type": "foaf:Person",
      "foaf:homepage": "http://example.com/eve/",
      "foaf:name": "Eve"
    }, {
      "@type": "foaf:Person",
      "foaf:homepage": "http://example.com/manu/",
      "foaf:name": "Manu"
    }
  ]
}

B.3 マイクロデータ

この項は非規範的です。

下記のHTMLマイクロデータ[MICRODATA]の例は、本の情報をマイクロデータのワーク・アイテムとして表しています。

164: マイクロデータを用いて本を記述しているHTML
<dl itemscope
    itemtype="http://purl.org/vocab/frbr/core#Work"
    itemid="http://purl.oreilly.com/works/45U8QJGZSQKDH8N">
 <dt>Title</dt>
 <dd><cite itemprop="http://purl.org/dc/elements/1.1/title">Just a Geek</cite></dd>
 <dt>By</dt>
 <dd><span itemprop="http://purl.org/dc/elements/1.1/creator">Wil Wheaton</span></dd>
 <dt>Format</dt>
 <dd itemprop="http://purl.org/vocab/frbr/core#realization"
     itemscope
     itemtype="http://purl.org/vocab/frbr/core#Expression"
     itemid="http://purl.oreilly.com/products/9780596007683.BOOK">
  <link itemprop="http://purl.org/dc/elements/1.1/type" href="http://purl.oreilly.com/product-types/BOOK">
  Print
 </dd>
 <dd itemprop="http://purl.org/vocab/frbr/core#realization"
     itemscope
     itemtype="http://purl.org/vocab/frbr/core#Expression"
     itemid="http://purl.oreilly.com/products/9780596802189.EBOOK">
  <link itemprop="http://purl.org/dc/elements/1.1/type" href="http://purl.oreilly.com/product-types/EBOOK">
  Ebook
 </dd>
</dl>

マイクロデータ情報のJSON-LD表現は、コンテキストを避け、代わりに完全なIRIによってアイテムを参照したいというマイクロデータ・コミュニティの要望に忠実であることに注意してください。

165: JSON-LDによる同じ本の記述(コンテキストを回避)
[
  {
    "@id": "http://purl.oreilly.com/works/45U8QJGZSQKDH8N",
    "@type": "http://purl.org/vocab/frbr/core#Work",
    "http://purl.org/dc/elements/1.1/title": "Just a Geek",
    "http://purl.org/dc/elements/1.1/creator": "Wil Wheaton",
    "http://purl.org/vocab/frbr/core#realization":
    [
      {"@id": "http://purl.oreilly.com/products/9780596007683.BOOK"},
      {"@id": "http://purl.oreilly.com/products/9780596802189.EBOOK"}
    ]
  }, {
    "@id": "http://purl.oreilly.com/products/9780596007683.BOOK",
    "@type": "http://purl.org/vocab/frbr/core#Expression",
    "http://purl.org/dc/elements/1.1/type": {"@id": "http://purl.oreilly.com/product-types/BOOK"}
  }, {
    "@id": "http://purl.oreilly.com/products/9780596802189.EBOOK",
    "@type": "http://purl.org/vocab/frbr/core#Expression",
    "http://purl.org/dc/elements/1.1/type": {"@id": "http://purl.oreilly.com/product-types/EBOOK"}
  }
]

C. IANAに関する留意点

この項は、IANAでのレビュー、承認、登録のためにIESG(Internet Engineering Steering Group)に提出しています。

application/ld+json

タイプ名:
application
サブタイプ名:
ld+json
必須パラメータ:
N/A
任意のパラメータ:
profile

[RFC6906]に従ってJSON-LDドキュメントに適用される特定の制約や規定を識別する、スペース区切りのURIの空でないリスト。プロファイルは、プロファイルの知識なしに処理された場合に資源の表現のセマンティクスを変更しないため、プロファイル対象の資源に関して、クライアントが知識を持っていてもいなくても同じ表現を安全に使用できます。profileパラメータは、クライアントが内容交渉の過程でプレファレンスを表すために使用できます(MAY)。プロファイルのパラメータが指定されていれば、サーバーは、認識したリスト内のプロファイルを尊重するドキュメントを返べきであり(SHOULD)、認識しないリスト内のプロファイルは無視しなければなりません(MUST)。プロファイルのURIは逆参照可能であり、そのURIで有用なドキュメントを提供することをお勧めします(RECOMMENDED)。詳細な情報と背景については、[RFC6906]を参照してください。

この仕様では、profileパラメータに対して6つの値を定義しています。

http://www.w3.org/ns/json-ld#expanded
展開JSON-LDドキュメント形式をリクエストまたは指定します。
http://www.w3.org/ns/json-ld#compacted
短縮JSON-LDドキュメント形式をリクエストまたは指定します。
http://www.w3.org/ns/json-ld#context
JSON-LDコンテキスト・ドキュメントをリクエストまたは指定します。
http://www.w3.org/ns/json-ld#flattened
フラット化JSON-LDドキュメント形式をリクエストまたは指定します。
http://www.w3.org/ns/json-ld#frame
JSON-LDフレーム・ドキュメントをリクエストまたは指定します。
http://www.w3.org/ns/json-ld#framed
フレーム化JSON-LDドキュメント形式をリクエストまたは指定します。

http://www.w3.org/ns/json-ldで始まるその他のすべてのURIは、JSON-LD仕様によって将来の使用のために予約されています。

他の仕様では、独自のセマンティクスを定義した追加のprofileパラメータURIを公開できます。これには、ファイル拡張子をprofileパラメータに関連付ける機能が含まれます。

HTTP Acceptヘッダー[RFC7231]でメディア・タイプ・パラメータ[RFC4288]として用いる場合、複数のプロファイルURIを組み合わせる場合に必要な空白などの特殊文字が含まれていれば、profileパラメータの値を引用符(")で囲まなければなりません(MUST)。

「profile」というメディア・タイプのパラメータを処理する場合、その値にはIRIではなく1つ以上のURIが含まれていることに注意することが重要です。したがって、[RFC3987]の3項 IRIとURIの関係で規定されているように、IRIとURIの変換が必要になる場合があります。

コード化に関する留意点:
RFC 8259の11項を参照
セキュリティに関する留意点:
RFC 8259の12項[RFC8259]を参照

JSON-LDは有向グラフの純粋なデータ交換フォーマットであることを意図しているため、シリアル化は、解析用のJavaScriptのeval()関数などのコード実行メカニズムを通すべきではありません(SHOULD NOT)。(無効な)ドキュメントには、実行時にシステムのセキュリティを危険にさらす予期しない副作用を引き起こす可能性のあるコードが含まれている場合があります。

JSON-LDドキュメントを処理する場合、通常、遠隔のコンテキストとフレームへのリンクが自動的に辿られるため、その結果、それぞれに対してユーザーの明示的なリクエストがなくてもファイル転送が行われます。遠隔のコンテキストを第三者が提供している場合、プライバシーの懸念につながるような利用パターンなどの情報を収集できる可能性があります。JSON-LD 1.1処理アルゴリズムとAPI仕様[JSON-LD11-API]で定義されているAPIなどの特定の実装では、この動作を制御するためのきめ細かいメカニズムを提供することができます。

HTTPなどの安全でない接続を介してウェブから読み込まれたJSON-LDコンテキストは、攻撃者によって変更される危険性があり、JSON-LDのアクティブ・コンテキストがセキュリティを危険にさらすようなものに変更される可能性があります。極めて重要な目的で遠隔のコンテキストに依存しているアプリケーションは、システムによる利用を許可する前に、その遠隔のコンテキストを検証しキャッシュすることをお勧めします。

JSON-LDでは長いIRIを短い用語に置き換えることができるため、JSON-LDドキュメントが処理時に大幅に展開され、最悪の場合、結果としてデータが受信者の資源をすべて使い切る可能性があります。アプリケーションは、十分な疑念を持ってデータを扱う必要があります。

JSON-LDは使用できるIRIスキームに制限を設けておらず、語彙に対して相対的なIRIはIRI解決ではなく文字列連結を用いるため、逆参照された場合に悪意を持って利用される可能性のあるIRIを構築することが可能です。

互換性に関する留意点:
n/a
公開済み仕様書:
http://www.w3.org/TR/json-ld
このメディア・タイプを使用するアプリケーション:
有向グラフの交換を必要とするプログラミング環境。JSON-LDの実装は、JavaScript、Python、Ruby、PHP、C++用に作成されています。
追加情報:
マジック・ナンバー:
n/a
ファイル拡張子:
.jsonld
マッキントッシュ・ファイル・タイプ・コード:
TEXT
詳細情報に関する連絡先
Ivan Herman <ivan@w3.org>
意図する使途:
汎用
使用上の制限:
N/A
著者:
Manu Sporny、Dave Longley、Gregg Kellogg、Markus Lanthaler、Niklas Lindstrom
改版管理者:
W3C

application/ld+jsonで用いられるフラグメント識別子は、RDF 1.1概念および抽象構文[RDF11-CONCEPTS]に従って、RDF構文と同様に扱われます。

この登録は、[JSON-LD10]のapplication/ld+jsonに関する元の定義の更新です。

C.1

この項は非規範的です。

以下の例は、プロファイルのパラメータを用いて様々な受け入れ可能な応答を記述する様々な方法を示しています。

166: 展開ドキュメントをリクエストするプロファイルがあるHTTPリクエスト
GET /ordinary-json-document.json HTTP/1.1
Host: example.com
Accept: application/ld+json;profile=http://www.w3.org/ns/json-ld#expanded

リクエストされた資源を展開ドキュメント形式のJSON-LDとして返すようサーバーにリクエストします。

167: 短縮ドキュメントをリクエストするプロファイルがあるHTTPリクエスト
GET /ordinary-json-document.json HTTP/1.1
Host: example.com
Accept: application/ld+json;profile=http://www.w3.org/ns/json-ld#compacted

リクエストされた資源を短縮ドキュメント形式のJSON-LDとして返すようサーバーにリクエストします。明示的なコンテキスト資源が指定されていないため、サーバーはアプリケーション固有のデフォルトのコンテキストを用いて短縮します。

168: 短縮コンテキストへの参照がある短縮ドキュメントをリクエストするプロファイルがあるHTTPリクエスト
GET /ordinary-json-document.json HTTP/1.1
Host: example.com
Accept: application/ld+json;profile="http://www.w3.org/ns/json-ld#flattened http://www.w3.org/ns/json-ld#compacted"

リクエストされた資源を短縮ドキュメント形式フラット化ドキュメント形式の両方でJSON-LDとして返すようサーバーにリクエストします。空白は2つのURIを区切るために用いられるため、二重引用符(")で囲まれていることに注意してください。

D. 未解決の課題

この項は非規範的です。

下記は、公開時点で未解決の課題のリストです。

課題108: メタデータを用いた参照によるコンテキストの検討defer-future-versionprivacy-trackersecurity-tracker

メタデータを用いた参照によるコンテキストの検討

課題191: 重要な接頭辞の用語定義に対する短縮IRI展開のサポートdefer-future-versionspec:enhancement

重要な接頭辞の用語定義に対する短縮IRI展開のサポート

課題280: 言語マップで別個の基本書字方向は許されていないdefer-future-version

言語マップで別個の基本書字方向は許されていない

課題328: JSON-LDコア構文の@contextの@defaultdefer-future-version

JSON-LDコア構文の@context@default

課題329: 「@prefix」に関する提案defer-future-version

@prefixに関する提案

課題335: 型強制/ノード変換: @coerceキーワード等defer-future-version

型強制/ノード変換: @coerceキーワード等

E. 2014年1月16日の1.0勧告以後の変更

この項は非規範的です。