要約

JSONはデータのシリアル化・送受信に便利なフォーマットである。この仕様はLinked Dataをシリアル化するためのJSONベースのフォーマットを定義する。 構文は既にJSONを使用して展開しているシステムに簡単に統合できるように設計され、JSONからJSON-LDにスムースにアップグレードするための機能を提供する。 Webベースのプログラミング環境中でのLinked Dataの使用、相互運用可能なWebサービスの構築、JSONベースのストレージ・エンジン内へのLinked Dataの格納においての利用を主に意図している。

この文書の位置づけ

この節では公開時点のこの文書の位置づけについて説明する。 他の文書がより優れたものとしてこの文書と入れ替わるかもしれない。 現在のW3C発行物と、 W3C 技術情報の最新版はhttp://www.w3.org/TR/の W3Cテクニカル・レポート・インデックス で得られる。

この文書は W3C会員・ソフトウェア開発者・他の W3Cグループ・利害関係者によって評価され、ディレクターによりW3C勧告として承認される。文書は安定したものとなり、参考資料として使用されたり他の文書から引用してもよいだろう。勧告作成上の W3Cの役割は仕様に注目を集め、普及を促進することである。これによりWebの機能と相互運用性を強化することが期待できる。

この仕様はレビュー・改善・勧告トラックに沿って発行されるために「RDF Working Group」に送られる前に「JSON for Linking Data Community Group」 によって開発された。 この文書は勧告案のレビュー中に受け取ったコメントによる小さな編集上の変更が含まれている。詳細は diff-markedバージョン を参照すること。

この仕様の独立した互換性のある実装がいくつかある。 2013年10月に 実装報告が公開されている。

この文書は勧告として RDF Working Groupによって発行された。 この文書に関するコメントを作成する場合は public-rdf-comments@w3.org ( subscribe, archives)へ送ること。 あらゆるコメントを歓迎する。

この文書は 2004年2月5日W3C特許政策の下でグループ作業によって策定された。 W3Cはグループの成果物に関して作成された あらゆる開示特許の公開リストを維持管理する。このリストには特許公開の手順も含む。特許について十分に知識のある人物が、仕様に Essential Claim(s) が認められると判断した場合は、 W3C 特許ポリシーの第6章に従い情報を開示する必要がある。

目次

1. 序論

この節は非規範的である。

Linked Dataは[LINKED-DATA] は、他のドキュメントおよびWebサイト間でコンピューターで解釈が可能なデータの標準的なネットワークを作成する方法である。これはアプリケーションが1つのLinked Dataで開始し、埋め込まれたリンクに従いWeb上の異なるサイトにホストされている他のLinked Dataを辿ることができる。

JSON-LDはJSON[RFC4627]でLinked Dataをシリアル化するための簡単な構文である。 それは既存のJSONを最小の変更でLinked Dataとして解釈させることが可能である。 JSON-LDはWebベースのプログラミング環境中におけるLinked Dataの使用、相互運用可能なWebサービスの構築、JSONベースのストレージ・エンジン内へのLinked Dataの格納においての利用を主に意図している。 JSON-LDはJSONと100%互換性があるため、現在公開されている大量のJSONパーサーやライブラリが再利用可能である。 JSONが提供するすべての機能に加えてJSON-LDは以下の機能を導入する。

JSON-LDはRDF[RDF11-CONCEPTS]の知識がなくてもそのままJSONとして使用できるように設計されている。また必要に応じてSPARQLのようなLinked Data技術と一緒に使用するためにRDFとして使用できるようにも設計されている。 以上の機能が必要かもしくはJSONベースの構文中にRDFグラフやRDFデータ・セットをシリアル化する必要がある開発者はJSON-LDに興味を持つだろう。RDFツールとともにJSON-LDを使用することを意図している方は、例えばTurtle[TURTLE]のような別のRDF構文としてJSON-LDを使用可能であることがわかるだろう。JSON-LDがどのようにRDFと関連するのかの完全な詳細は「9. RDFとの関係」節にある.

構文は既にJSONを使用して稼働しているシステムを妨げず、JSONからJSON-LDへスムースにアップグレードするためのパスを提供するように設計されている。そのようなデータの形状は大きく異なるので、JSON-LDはドキュメントを再形成し、処理しやすい確定的構造にするメカニズムを備えている。

1.1 この文書の読み方

この節は非規範的である。

この文書はJSONでLinked Dataをシリアル化するための詳細仕様である。この文書は主に下記の読者を対象にしている。

別冊文書としてJSON-LD処理アルゴリズムとAPI仕様[ JSON-LD-API] 共通のJSON-LD操作のための標準ライブラリインターフェースを提供することで高レベルなJSON-LDの扱い方を説明している。

この仕様の基本を理解するためにはまずJSONに精通していなければならない。JSONは[RFC4627]に詳細がある。

この文書はハイパーリンクを論じる場合用語として、ほぼIRI (Internationalized Resource Indicator) のみを使用する。 たいていのWeb開発者はURL (Uniform Resource Locator) に馴染みがある。この文書はほとんど稀ではあるがURI (Uniform Resource Indicator) を使用する。これらの用語はしばしば技術コミュニティー間で区別されずに使われるが、各用語間には実に重要な差異があるから、この仕様書ではすべての場合において適切な用語を使おうという労を惜しまない。

2. 設計目標と理論的根拠

この節は非規範的である。

JSON-LDは次の設計目標を満たしている。:

簡素さ
基本的にJSON-LDを使用するために特別な処理プログラムやソフトウェア・ライブラリを必要としない。 この言語は非常に容易な学習曲線を開発者に提供する。JSONとJSON-LD中の基本的な機能を使用するためには開発者は2つのキーワード (@context@id) だけ知れば十分である。
互換性
JSON-LDは常に有効なJSON文書である。これはすべての標準的なJSONライブラリがJSON-LDにおいてもシームレスに動作することを保証する。
表現力
構文は有向グラフをシリアル化する。ほとんどすべての現実世界のデータ・モデルを表現することを保証する。
簡潔さ
JSON-LD構文は開発者から可能な限り負担を減らすため、とても簡潔で人にとって読みやすい。
ほとんどの場合において修正不要
JSON-LDは、既存のJSONベースのシステムからのスムーズかつシンプルな移行を保証する。 多くの場合、JSONドキュメントは修正不要でHTTPレスポンスへ一行の追加で事足りる(「 6.8 JSON-LDとしてJSONを解釈する」節参照)。 これは巨大なJSONベースのインフラをすでに展開している組織が、日々のオペレーションを混乱させることなく組織の今の顧客にとって分かりやすい方法で、JSON-LDの機能を利用できるようにする。 しかしながら、JSONをグラフ表現にマッピングするのは複雑な作業になることもある。 これらの場合、複雑なユースケースをサポートするためにJSON-LDを拡張するのではなく、ユースケースをサポートしないことを選択する。修正不要であることは設計目標のひとつではあるが、言語に多大な複雑さを追加することなしに目標を達成できないことがあるためである。JSON-LDは可能な限り簡素さに焦点を当てている。
RDFとしての利用

JSON-LDはRDF[RDF11-CONCEPTS]を理解することなしに、慣用してきたJSONとして開発者によって利用可能である。また、JSON-LDはRDFとしても利用可能であり、RDFツールとともにJSON-LDを使おうとしている人は、他のRDF構文と同じように使えることがわかるだろう。JSON-LDがRDFとどのように関係しているかの完全な詳細は「9. RDFとの関係」節にある。

3. 用語

3.1 一般的な用語

このドキュメントはJSON[ RFC4627]中で定義されている次の用語を使用する。 正式な定義については[ RFC4627]中のJSON Grammar節を参照すること。

JSONオブジェクト
オブジェクト構造は、ゼロペア以上のキー・値ペアを囲む中括弧の対として表される。 キーは文字列である 。単一のコロンが値とキーを分離するためにキーの後に続く。 単一のコンマは、続くキーから値を分離する。JSONとは対照的にJSON-LDではオブジェクトのキーは一意である必要がある。
配列
配列は0個以上の値を囲む角括弧として表される。値はコンマによって分離される。 JSON中では配列は0個以上の値の順序付けられた列である。 一方、JSON-LDはJSONと同様の配列表現を使用しているが、配列集合はデフォルトでは順序付けられていない。 順序は正規のJSON配列では維持されるのに対して、特別に定義されない限り正規のJSON-LDは順序を維持しない(「6.11のセットとリスト」節を参照)。
文字列
文字列は0個以上のUnicode文字の列で、ダブルクォートで囲まれ、(必要であれば)バックスラッシュ・エスケープを使用する。
数値
数値は8進・16進フォーマットは使用せず、先行ゼロが許されていない以外は大抵のプログラミング言語で使用されるものと同様である。
truefalse
2つのブーリアン状態の1つを表現するために使用される値。
null
一般的にデータを消去もしくは忘却するためのnull値。例えば値がnullである@context中のキー・値ペアはIRI 用語 の関連を明確に切り離す。 値がnullであるJSON-LDドキュメント中のキー・値ペアは、キー・値ペアが定義されていないのと同じ意味である。 もし展開形式中で@value, @list, @setnullがセットされている場合はJSONオブジェクト全体が無視される。

3.2 データ・モデル概要

この節は非規範的である。

一般的に言えば、JSON-LDで使用されるデータ・モデルは名前付き有向グラフである。グラフは辺により接続されたノードを含んでいる。 ノードは通常 文字列数値・ (日付や時刻などの)型付き値IRIのようなデータである。 通常IRIのようなグローバル識別子を持たないデータを表現するために使用する 空白ノード と呼ばれる特別なノード・クラスがある。 空白ノード空白ノード識別子を用いて識別される。この簡素なデータ・モデルはとても柔軟かつ強力で、ほとんどどんな種類のデータでもモデル化が可能である。 データ・モデルのより深い説明については「7. データ・モデル」を参照すること。

Linked Data技術に精通している開発者はRDFデータ・モデルと同様にデータ・モデルを理解するだろう。 JSON-LDとRDFがどのように関連しているか深く知るためには「9. RDFとの関係」を参照すること。

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

JSON-LDは言語のコア部分となるいくつかの文法トークンとキーワードを定める。

@context
JSON-LD文書の全体で使用される省略名を定義するために使用する。 これらの省略名は 用語 と呼ばれ、開発者がコンパクトな方法で特定の識別子を表現する助けとなる。 @contextキーワードは「section 5.1 The Context」節で詳説する。
@id
IRI 空白ノード識別子 を用いてドキュメント中で記述されるを一意に識別するために使用される。 このキーワードは「5.3 ノード識別子」節で説明する.
@value
グラフ中の特定の プロパティ にまつわるデータを指定するために使用する。このキーワードは「6.9 文字列の国際化」節と「6.4 型付き値」節で説明する。
@language
特定の文字列値のための言語もしくはJSON-LDドキュメントのデフォルト言語を指定するために使用する。 このキーワードは「 6.9 文字列の国際化」節で説明する。
@type
ノード 型付き値 のデータ型を指定するときに使用する。このキーワードは「6.4 型付き値」節で説明する。
@container
用語のためのデフォルトの コンテナ型 を指定する。このキーワードは「6.11 セットとリスト」節で説明する。
@list
順序付けされたデータのセットを表現する。 このキーワードは「6.11 セットとリスト」節で説明する。
@set
順不同のデータセットを表現するためと、常に値が配列として表現されることを保証するために使用する。 このキーワードは「6.11 セットとリスト」節で説明する。
@reverse
逆プロパティを表現するために使用する。このキーワードは「6.12 逆プロパティ」節で説明する。
@index
コンテナが情報をインデクスするために使用されかつ処理がJSONデータ構造の奥深くで継続すべきときに指定する。 このキーワードは「6.16 データ索引」節で説明する。
@base
相対IRI が解決されるためのベースIRIを指定するために使用する。 このキーワードは「6.1 ベースIRI」節で説明する。
@vocab
共通のプリフィクス IRI を伴うプロパティと@type中の値を展開するために使用する。 このキーワードは「6.2 デフォルトの語彙」節で説明する。
@graph
グラフ を表現するために使用する。 このキーワードは「6.13 名前付きグラフ」節で説明する。
:
短縮IRIを使用するJSONキーと値のセパレータである。

JSON-LD中のすべてのキー、 キーワード、 値は大文字と小文字が区別される。

4. 適合性

この仕様はJSON-LD文書の適合性基準を記述する。この基準は作成者と作成ツール実装者に関連する。 非規範的とマークされた節と同様に作成ガイドライン、図、例、仕様中の注釈はすべて非規範的である。 この仕様の他のすべては規範的である。

JSON-LD文書 は付録「8. JSON-LD 文法」中の規範的記述に従う場合この仕様に準拠する。 JSON文書は「6.8 JSON-LDとしてJSONを解釈する」節中の規範的記述に従いJSON-LDとして解釈することができる。 便宜上、文書のための規範的記述がしばしば文書のプロパティ上の記述として表現される。

仕様中の MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, OPTIONALキーワードは [ RFC2119]で定義された意味を持つ。

5. 基本概念

この節は非規範的である。

JSON [ RFC4627] は軽量で言語独立なデータ交換フォーマットである。 JSONは解析が容易であり、生成も容易である。しかしながら、出自の異なるJSONを統合することは、データが他のデータソースと競合するキーを含みうるために困難である。さらにまたJSONはウェブ上の基礎的要素であるハイパーリンクの組み込みサポートがない。この節の残りを使用して例を見てみることにしよう。

例 1: JSON文書サンプル
{
    "name": "Manu Sporny",
    "homepage": "http://manu.sporny.org/",
    "image": "http://manu.sporny.org/images/manu.png"
}

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

Linked Data、そして一般的にWebでは、明確に識別するためにIRI[RFC3987]に記載されているInternationalized Resource Identifiers)を使用する。着想は他の開発者が使用するかもしれないデータへ明確な識別子を割り当てるためにIRIを使用することである。 namehomepageのような用語IRIへ展開することは、開発者が各々の用語を誤って使用しないために役立つ。さらに開発者やマシンはこのIRI (たとえばWebブラウザを使用することによって)を使用して、用語の情報に到達し、用語が何を意味しているのかについての定義を得ることができる。 このプロセスはIRIデリファレンスとして知られている。

ポピュラーなschema.org語彙の効力により、上の例は次のように明確に表現することができるだろう。

例 2: 用語の代わりにフルIRIを使用したJSON-LD文書のサンプル
{
    "http://schema.org/name": "Manu Sporny",
    "http://schema.org/url": { "@id": "http://manu.sporny.org/" },  ← '@id'キーワードは「この値はIRIである識別子」を意味する
    "http://schema.org/image": { "@id": "http://manu.sporny.org/images/manu.png" }
}

上記の例では、すべてのプロパティはIRIによって明確に識別され、IRIによって表現するすべての値は@idキーワードで印が付けられ明示されている。 これは、そのデータについてとても具体的な、正しいJSON-LD文書ではあるが、一方であまりに冗長で、人間である開発者にとって作業が困難である。この問題に対処するため、JSON-LD は次の節で説明しているようにコンテキストの概念を導入する。

5.1 コンテキスト

この節は非規範的である。

2人がお互いに対話するとき、対話は一般的に“対話コンテキスト”と呼ばれる共有環境で行われる。 この共有コンテキストの下では共通の知人のファースト・ネームのような短縮用語を各人が使用できるため、精度を落とすことなく迅速に対話できる。 JSON-LDのコンテキストもそれと同じ仕組みである。2つのアプリケーションが正確性を失うことなく他方と効率的にコミュニケートできるよう、短縮用語を使用できる。

簡単に言うと、コンテキスト用語IRIへ写すために使用される。 用語は大文字・小文字を区別し、JSON-LDキーワードとして予約されていない任意の文字列はすべて用語として使用することができる。

前の節のサンプル文書のコンテキストはこのようになる。

例 3: 前節のサンプル文書のコンテキスト
{
"@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のマッピング、JSONオブジェクトのいずれかにすることができる。

JSONオブジェクトが用語と結びつけられるとき、それは拡張用語定義と呼ばれる。上の例ではimagehomepageの値は文字列であればIRIとして解釈されることを指定する。 拡張用語定義はまた用語を索引マップの使用および配列値がセットかリストとして解釈されるかどうかの指定を可能とする。 拡張用語定義はキーとして 絶対 もしくは 短縮IRIで定義され、主に型や言語情報を 絶対 もしくは 短縮IRI と結びつけるために使用される。

コンテキストは直接ドキュメントに埋め込まれるか、参照される。前の例のコンテキスト文書がhttp://json-ld.org/contexts/person.jsonldで検索できることができると仮定するなら、それは1行追加するだけで参照できJSON-LD文書を下の例で示すように一層簡潔に表現することが可能となる。

例 4: JSON-LDコンテキストの参照
{
    "@context": "http://json-ld.org/contexts/person.jsonld",
    "name": "Manu Sporny",
    "homepage": "http://manu.sporny.org/",
    "image": "http://manu.sporny.org/images/manu.png"
}

参照コンテキストはSchema.org中のIRIと用語をどのように結びつけるかを特定するだけではなく、homepageimageプロパティがIRI ( "@type": "@id", 詳細は「5.2 IRIs」参照)として解釈できるように結びつける文字列値を特定する。 この情報により開発者がサイト間においてデータの相互運用方法について合意形成することなしに互いのデータを再利用することが可能となる。外部JSON-LDコンテキスト文書は、定義された 用語についての文書化が文書中で定義されるような、@contextキーの外部にある特別な情報を含んでいてもよい。 @context値の外に含まれる情報は、文書が外部JSON-LDコンテキスト文書として使用されるときは無視される。

JSON文書は「6.8 JSON-LDとしてJSONを解釈させる」節に記載されているように、HTTPリンクヘッダを経由して コンテキストを参照することによって修正することなしJSON-LDとして解釈させることができる。 JSON-LD API [JSON-LD-API]を使用してカスタムコンテキストを適用することが可能となる。

JSON-LD文書中では コンテキストはインラインで指定する。これは文書がウェブへの接続がなくても処理できる利点がある。最終的には、これはモデリング上の決定であり、異なるユースケースでは異なるハンドリングを必要とするだろう。

例 5: インライン・コンテキスト定義
{
    "@context":
    {
        "name": "http://schema.org/name",
        "image": {
            "@id": "http://schema.org/image",
            "@type": "@id"
        },
        "homepage": {
            "@id": "http://schema.org/url",
            "@type": "@id"
        }
    },
    "name": "Manu Sporny",
    "homepage": "http://manu.sporny.org/",
    "image": "http://manu.sporny.org/images/manu.png"
}

この節はJSON-LDコンテキストの最も基本的な機能のみをカバーしている。 JSON-LDコンテキスト関するさらに高度な機能は「6. 高度な概念」節中でカバーしている。

5.2 IRI

この節は非規範的である。

IRI (Internationalized Resource Identifiers [ RFC3987]) は大部分のノードプロパティが識別される方法で、リンク・データの基本となる。 JSON-LD中ではIRIは絶対IRIもしくは相対IRIで表現される。 絶対IRIパス、オプションであるクエリ・セグメントおよびフラグメント・セグメントとともにスキームを含むものとして [RFC3987] で定義される。 相対IRI絶対IRIに対して相対であるIRIである。 JSON-LD中では相対IRIベースIRIに対して相対的に解決される。

文字列@idメンバーの値のときはIRIとして解釈される。

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

IRIとして解釈される値は、相対URLで表現することができる。 例えば次の文書がhttp://example.com/about/に位置していると仮定すると、相対IRI ../ はhttp://example.com/に拡張される(どこで相対IRIが使用することができるかの詳細は「8. JSON-LD構文」を参照)。

例 7: IRIは相対にできる
{
    ...
    "homepage": { "@id": "../" }
    ...
}

絶対IRIは下のようにキーの位置に直接表すことができる。

例 8: キーとしてのIRI
{
    ...
    "http://schema.org/name": "Manu Sporny",
    ...
}

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

用語から IRIへの拡張はキーが アクティブ・コンテキスト内で定義されている用語にマッチする場合に発生する。

例 9: 用語はコンテキスト定義から拡張される。
{
    "@context":
    {
        "name": "http://schema.org/name"
    },
    "name": "Manu Sporny",
    "status": "trollin'"
}

上の例のstatusのようなIRIに拡張されないJSONキーはリンク・データではないので処理時に無視される。

強制ルールが特定の用語やプロパティIRI用に@context中で指定されている場合、IRIが生成される。

例 10: 型強制
{
    "@context":
    {
        ...
        "homepage":
        {
            "@id": "http://schema.org/url",
            "@type": "@id"
        }
        ...
    }
    ...
    "homepage": "http://manu.sporny.org/",
    ...
}

上の例では値http://manu.sporny.org/がJSON 文字列として表現されているので、型強制ルールがデータ処理時にIRIに値を変換する。この機能についての詳細は「6.5 型強制」節を参照すること。

要約すると、IRIはJSON-LDで多様な異なる方法で表わされる。

  1. アクティブ・コンテキスト 中にマッピングされた用語を持つJSONオブジェクト・キーはIRI(コンテキスト定義の外側にのみ適用)に拡張する。
  2. @idもしくは@typeを使用して指定された文字列値についてIRIは生成される。
  3. @idもしくは@vocabの値がセットされている@typeキーを含む強制ルールのあるキーの文字列値についてIRIは生成される。

この節はJSON-LDのIRIに関連する最も基本的な機能についてのみカバーする。 さらにIRIに関連する高度な機能は「6. 高度な概念」中でカバーしている。

5.3 ノード識別子

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

グラフ中のノードが外部参照可能となるためにはノードが識別子を持つことが重要である。 IRIはリンク・データの基本的な概念であり、ノードが正しくリンクされるために、識別子の参照解除がノード表現の結果となるべきである。このことはアプリケーションがノードについての情報をさらに引き出すことを可能にする。

JSON-LDではノード@idキーワードを使用することによって識別される。

例 11: ノードの識別
{
    "@context":
    {
        ...
        "name": "http://schema.org/name"
    },
    "@id": "http://me.markus-lanthaler.com/",
    "name": "Markus Lanthaler",
    ...
}

上の例はIRIhttp://me.markus-lanthaler.com/によって識別されたノード・オブジェクトを含む。

この節はJSON-LD中のノード識別子に関連する最も基本的な機能のみカバーしている。 ノード識別子に関するさらに高度な機能は 「6. 高度な概念」節でカバーされている。

5.4 型指定

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

@typeキーワードを使用することによって特定のノードの型を指定することができる。 リンク・データ中では、型はIRIで一意に識別される。

例 12: ノードの型の指定
{
    ...
    "@id": "http://example.org/places#BrewEats",
    "@type": "http://schema.org/Restaurant",
    ...
}

ノードは配列によって1つ以上の型を割り当てることができる。

例 13: ノードに対して複数の型の指定
{
    ...
    "@id": "http://example.org/places#BrewEats",
    "@type": [ "http://schema.org/Restaurant", "http://schema.org/Brewery" ],
    ...
}

@typeキーの値はアクティブ・コンテキストで定義された用語でも差し支えない。

例 14: 型を指定した用語の使用
{
    "@context": {
        ...
        "Restaurant": "http://schema.org/Restaurant", 
        "Brewery": "http://schema.org/Brewery"
    },
    "@id": "http://example.org/places#BrewEats",
    "@type": [ "Restaurant", "Brewery" ],
    ...
}
この節はJSON-LD中の型に関連する最も基本的な機能のみカバーしている。 @typeキーワードノードの型を指定するだけではなく、型付けされた値(「6.4 型付き値」節で説明する) および型強制値(「6.5 型強制」節で説明する)も表現することは注目に値する。 特に、@typeノードの型を定義するためにコンテキスト中で使用できない。 相違点についての詳細は, 「6.4 型付き値」節を参照されたい。

6. 高度な概念

JSON-LDは、上記のコア機能を超える機能性を提供する多くの特徴を備えている。 次の項で、高度な機能について詳細に説明する。

6.1 ベースIRI

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

JSON-LDはIRIに[RFC3986]の5.1 ベースIRIの確立節に適合する文書ベースに対して解決される相対形式を指定することが可能である。 ベースIRI@baseキーワードを使用することによってコンテキストに明示的に設定することができる。

例えば、JSON-LD文書がhttp://example.com/document.jsonldから検索される場合、相対IRIがIRIに対して解決される。

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

この文書は文書ベースへ解決される空の@idを使用している。 しかしもし文書が異なる場所に移動した場合、IRIは変更される。 絶対IRIを使用せずIRIの変更を防止するには、コンテキストにこの文書のベースIRIを上書きするための@baseマッピングを定義する。

例 16: 文書の文書ベースを設定する
{
    "@context": {
        "@base": "http://example.com/document.jsonld"
    },
    "@id": "",
    "label": "Just a simple document"
}

@basenullを設定すると相対IRI絶対IRIへ拡張されることを防止する。

@baseは外部コンテキストで使用する場合は無視されることに注意すること。

6.2 既定の語彙

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

時々、すべてのプロパティおよび型は同じ語彙に由来する。JSON-LDの@vocabキーワードは、作成者が 短縮IRIでも絶対IRIでもない (すなわち、コロンを含まない)すべてのプロパティと型のために使用する共通プリフィクスの設定を行うことを可能にする。

例 17: 共通語彙プリフィクスの仕様
{
    "@context": {
        "@vocab": "http://schema.org/"
    }
    "@id": "http://example.org/places#BrewEats",
    "@type": "Restaurant",
    "name": "Brew Eats"
    ...
}

@vocabが使用されるがオブジェクト中の確実なキーが語彙IRIを使用して拡張されるべきでない場合、用語コンテキスト中でnullを確実に設定する。例えば、下の例中のdatabaseIdメンバーはIRIに拡張されない。

例 18: データを無視するためにnullキーワードを使用
{
    "@context":
    {
        "@vocab": "http://schema.org/",
        "databaseId": null
    },
    "@id": "http://example.org/places#BrewEats",
    "@type": "Restaurant",
    "name": "Brew Eats",
    "databaseId": "23987520"
}

6.3 短縮IRI

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

短縮IRIはコロン (:)によって分割されたプリフィクスサフィックスを使用することによってIRIを表現する方法である。 プリフィクスアクティブ・コンテキストから取り出した用語であり、 JSON文書中の特定のIRIを識別するための短い文字列である。 例えば, プリフィクスfoafIRIhttp://xmlns.com/foaf/0.1/を使用することによって識別されるFriend-of-a-Friend語彙の短縮形として使用される。 開発者は語彙用語の絶対IRIの短縮形を指定するプリフィクスの終端へ任意のFOAF 語彙用語を追加することができる。 例えば,foaf:nameIRIhttp://xmlns.com/foaf/0.1/nameに拡張される。

例 19: プリフィクス表現
{
    "@context":
    {
        "foaf": "http://xmlns.com/foaf/0.1/"
        ...
    },
    "@type": "foaf:Person"
    "foaf:name": "Dave Longley",
    ...
}

上の例ではfoaf:nameIRIhttp://xmlns.com/foaf/0.1/nameに拡張され、foaf:Personhttp://xmlns.com/foaf/0.1/Personに拡張される。

プリフィクスは、値の形式がprefix:suffixの組み合わせによって表現される短縮IRIであり、プリフィクスアクティブ・コンテキスト内で定義された用語に適合し、サフィックスが2つのスラッシュで始まらない(//)ときに拡張される。 短縮IRIプリフィクスがマップされたIRIと(空白可能な)サフィックスを連結することによって拡張される。 もしプリフィクスアクティブ・コンテキスト内で定義されていないかサフィックスが2つのスラッシュ(http://example.comのように)で始まっている場合は、値は絶対IRIとして解釈される。 もしプリフィクスがアンダースコア(_)の場合、値は空白ノード識別子として解釈される。

次の例の中に示されるようにコンテキスト内で短縮IRIを使用することが可能である。

例 20: 語彙の使用
{
    "@context":
    {
        "xsd": "http://www.w3.org/2001/XMLSchema#",
        "foaf": "http://xmlns.com/foaf/0.1/",
        "foaf:homepage": { "@type": "@id" },
        "picture": { "@id": "foaf:depiction", "@type": "@id" }
    },
    "@id": "http://me.markus-lanthaler.com/",
    "@type": "foaf:Person",
    "foaf:name": "Markus Lanthaler",
    "foaf:homepage": "http://www.markus-lanthaler.com/",
    "picture": "http://twitter.com/account/profile_image/markuslanthaler"
}

6.4 型付けされた値

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

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

  1. @contextセクション中で用語を定義するときに@type キーワードを用いる。
  2. 値オブジェクトを用いる。
  3. 数値truefalseのようにネイティブJSON型を使用する。

最初の例は@context中の特定の用語と型を関連付けるために@typeキーワードを使用する。

例 21: 型強制を伴う拡張用語定義
{
    "@context":
    {
        "modified":
        {
            "@id": "http://purl.org/dc/terms/modified",
            "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
        }
    },
    ...
    "@id": "http://example.com/docs/1",
    "modified": "2010-05-29T14:17:39+02:00",
    ...
}

上のmodifiedキーの値は情報が指定されているためdateTimeに自動的に型強制される。 JSON-LDプロセッサは上の例を以下のように解釈する。

対象 プロパティ 値型
http://example.com/docs/1 http://purl.org/dc/terms/modified 2010-05-29T14:17:39+02:00 http://www.w3.org/2001/XMLSchema#dateTime

2つ目の例はJSON-LD文書の本文中に型情報を設定する拡張形式を使用する。

例 22: 拡張された型を伴う値
{
    "@context":
    {
        "modified":
        {
            "@id": "http://purl.org/dc/terms/modified"
        }
    },
    ...
    "modified":
    {
        "@value": "2010-05-29T14:17:39+02:00",
        "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
    }
    ...
}

上の両方の例は 型http://www.w3.org/2001/XMLSchema#dateTimeの値2010-05-29T14:17:39+02:00を生成する。 用語もしくは型の値を表現するための短縮IRIを使用することが可能であることに注意する。

@typeキーワードは型とノードを関係づけるために使用する。 ノード型値型の概念は異なる。

ノード型は人・場所・イベント・Webページのように記述される物の型を指定する, 値型は整数・浮動小数・日付のような特定のデータ型の値を指定する。

例 23: コンテキスト依存な@typeのデモ
{
    ...
    "@id": "http://example.org/posts#TripToWestVirginia",
    "@type": "http://schema.org/BlogPosting",  ←これはノード型である。
    "modified":
    {
        "@value": "2010-05-29T14:17:39+02:00",
        "@type": "http://www.w3.org/2001/XMLSchema#dateTime"  ←これは値型である。
    }
    ...
}

1つ目の@typeノード型(http://schema.org/BlogPosting)を@idキーワードを使用することによって表現されるノードに関連付ける。 2つ目の@type値型(http://www.w3.org/2001/XMLSchema#dateTime) を@valueキーワードを使用することによって表現される値に関連付けている。 一般的なルールとして、 @value@typeが同じJSONオブジェクト中で使用されているとき、 @typeキーワード値型を表現する。 そうでない場合@typeキーワードノード型を表現する。 上の例は次のデータを表現する:

対象 プロパティ 値型
http://example.org/posts#TripToWestVirginia http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://schema.org/BlogPosting -
http://example.org/posts#TripToWestVirginia http://purl.org/dc/terms/modified 2010-05-29T14:17:39+02:00 http://www.w3.org/2001/XMLSchema#dateTime

6.5 型強制

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

JSON-LDは値の特定データ型への強制をサポートする。 型強制はJSON-LDを提供する人がデータ型IRI用語へマッピングすることで、入出力値を適切なデータ型に強制することが可能になる。 型強制を使用することで、値表現はデータのそれぞれの部分にデータ型を指定する必要なしに保持される。

型強制は@typeキーを使用し拡張用語定義内で指定する。 このキーの値はIRIに拡張される。 あるいは、キーワード@idもしくは@vocabがJSON-LD文書の本文内に示すための値として使用され、用語文字列値は@idもしくは@vocabIRIとして解釈されるように強制される。 @id@vocabの違いは値がどのように絶対IRIに拡張されるかである。 @vocabは最初に用語として解釈することによって値に拡張することを試みる。 適合する用語アクティブ・コンテキスト中に見つからなかった場合, 値中にコロンがある場合は短縮IRIもしくは絶対IRIに拡張を試み、さもなくばアクティブ・コンテキスト 語彙マッピングもしくは場合によっては相対IRIとして解釈することによって値を拡張する。 対照的に@idで強制された値はコロンがある場合は短縮IRIもしくは絶対IRIに拡張され、さもなくば相対IRIとして解釈される。

用語もしくは短縮IRIは同じコンテキスト内で定義される@typeキーの値として使用される。 これはxsdのような用語を指定し、それから同じコンテキスト定義内でxsd:integerを使用することを意味する。

下の例はJSON-LD作成者がどのように 型付けされた値IRIに値を強制することができるのかを説明している。

例 24: 型を伴う拡張用語定義
{
    "@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"
        }
    },
    "@id": "http://example.com/people#john",
    "name": "John Smith",
    "age": "41",
    "homepage":
    [
        "http://personal.example.org/",
        "http://work.example.com/jsmith/"
    ]
}

上の例は次表のデータの生成を表している。

対象 プロパティ 値型
http://example.com/people#john http://xmlns.com/foaf/0.1/name John Smith  
http://example.com/people#john http://xmlns.com/foaf/0.1/age 41 http://www.w3.org/2001/XMLSchema#integer
http://example.com/people#john http://xmlns.com/foaf/0.1/homepage http://personal.example.org/ IRI
http://work.example.com/jsmith/ IRI

用語は絶対IRIもしくは短縮IRIを用いて定義されている。 強制ルールを簡素な 用語として表現することなくキーに適用することが可能である。 例えば

例 25: 短縮もしくは絶対IRIを使用した用語定義
{
    "@context":
    {
        "foaf": "http://xmlns.com/foaf/0.1/",
        "foaf:age":
        {
            "@id": "http://xmlns.com/foaf/0.1/age",
            "@type": "xsd:integer"
        },
        "http://xmlns.com/foaf/0.1/homepage":
        {
            "@type": "@id"
        }
    },
    "foaf:name": "John Smith",
    "foaf:age": "41",
    "http://xmlns.com/foaf/0.1/homepage":
    [
        "http://personal.example.org/",
        "http://work.example.com/jsmith/"
    ]
}

この場合用語定義中の@id定義はオプションである。もしそれがない場合、用語として表現する短縮IRIもしくはIRIはプリフィクスが定義されているかいないかにかかわらず常に@idキーによって定義されるIRIによって拡張される。

型強制は常に拡張されないキーの値を使用することによって行われる。上の例では、型強制はアクティブ・コンテキスト中のfoaf:ageを探すことによって行われ、対応するものが見つからない場合、IRI http://xmlns.com/foaf/0.1/ageに拡張されることを意味する。

コンテキスト中のキーは拡張と型強制の目的のため用語としてみなされる。 ときどき、複数の表現が同じ拡張されたIRIの結果となることがある。 例えば、dogcatの両方ともhttp://example.com/vocab#animalに拡張されるように指定することができる。 これを行うことは異なる型強制もしくは言語指定ルールを確立する方法として役立つ。 それは 短縮IRI (もしくは同等な絶対IRI)を何か完全なものとして定義することを可能にする。 例えば、用語http://example.org/zoohttp://example.org/riverに拡張するように指定することができるが、この用法はJSON-LD文書を理解しようと試みる開発者間に多くの混乱をもたらすので推奨しない。

6.6 埋め込み

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

埋め込みプロパティ値としてノード・オブジェクト使用することを可能とするJSON-LDの機能である。 これは2つのノード間で親子関係を作成するときによく使われる。

下の例は最初のノードからプロパティによって関係づけられた2つのノードを表している。

例 26: 他のノードのプロパティ値としてのノード・オブジェクトの埋め込み
{
    ...
    "name": "Manu Sporny",
    "knows":
    {
        "@type": "Person",
        "name": "Gregg Kellogg"
    }
    ...
}

上で使われるようなノード・オブジェクトはJSON-LD文書の本文中の、どの位置の値でも使用することができる。

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

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

5.1 コンテキストではJSON-LDの動作の基本を紹介した。 この節はコンテキストの基本原則を拡張し、どのような高度なユースケースがJSON-LDによって達成されるのかを説明する。

一般に、コンテキストはJSONオブジェクトが定義されていればいつでも使用することができる。コンテキスト定義の内側でコンテキストを表現することができないことのみである。例えば、JSON-LD 文書はドキュメント中の異なる位置で一つ以上のコンテキストを使用することができる。

例 27: 複数のコンテキストの使用
[
    {
        "@context": "http://example.org/contexts/person.jsonld",
        "name": "Manu Sporny",
        "homepage": "http://manu.sporny.org/",
        "depiction": "http://twitter.com/account/profile_image/manusporny"
    },
    {
        "@context": "http://example.org/contexts/place.jsonld",
        "name": "The Empire State Building",
        "description": "The Empire State Building is a 102-story landmark in New York City.",
        "geo": {
            "latitude": "40.75",
            "longitude": "73.98"
        }
    }
]

重複したコンテキスト用語は、もっとも直近に定義されたものが有効となる機構を使用することよって上書きされる。

例 28: ノード・オブジェクト内のコンテキストの有効範囲
{
    "@context":
    {
        "name": "http://example.com/person#name,
        "details": "http://example.com/person#details"
    }",
    "name": "Markus Lanthaler",
    ...
    "details":
    {
        "@context":
        {
            "name": "http://example.com/organization#name"
        },
        "name": "Graz University of Technology"
    }
}

上の例では、name用語はさらに深い入れ子の詳細構造中で上書きされる。 これは良い作成者はめったに実践せず、JSONオブジェクトの特定の構造に依存する古いアプリケーションが動作する際に使用する典型である。 用語がコンテキスト内で再定義された場合、以前の定義に関連する以前のすべてのルールは取り除かれる。 もし用語nullで再定義された場合、用語アクティブ・コンテキスト中で定義された用語のリストから効率的に取り除かれる。

複数のコンテキストは順番に処理され、配列を使用して結合される。 特定のJSONオブジェクト内で定義されたコンテキストのセットはローカル・コンテキストとして参照される。 アクティブ・コンテキストは文書中の特定の位置にある範囲のローカル・コンテキストの蓄積を参照する。 ローカル・コンテキストnull設定するとアクティブ・コンテキストに空コンテキストを効率的に初期化する。 次の例は外部コンテキストを指定し、それから外部コンテキストの先頭に埋め込みコンテキストを配置する。

例 29:外部およびローカル・コンテキストの結合
{
    "@context": [
        "http://json-ld.org/contexts/person.jsonld",
        {
            "pic": "http://xmlns.com/foaf/0.1/depiction"
        }
    ],
    "name": "Manu Sporny",
    "homepage": "http://manu.sporny.org/",
    "pic": "http://twitter.com/account/profile_image/manusporny"
}

可能なら、コンテキスト定義はJSON-LD文書の先頭に置くべきである。 これは文書を読みやすくさせ、パーサーに効率的に処理させることができる。コンテキストを先頭に持たない文書はそれでもJSON-LDに適合している。

下位互換問題を避けるためには、@文字で始める用語はJSON-LDの未来のバージョンでキーワードとして使用されるかもしれないため避けること。 JSON-LD 1.0 キーワードでない@文字で始まる用語はその他の用語としてみなされる。すなわちそれらはIRIとしてマップされるまで無視される。 さらに空の用語 ( "")を使用することは、JSONキーがすべての言語で操作できるとは限らないため許可されていない。

6.8 JSON-LDとしてJSONを解釈する

通常のJSON文書はHTTPリンクヘッダー中のJSON-LDコンテキスト文書を参照することによってJSON-LDを解釈することができる. そうすることは開発者が文書に大幅な変更をすることなしに明確に機械が読み取り可能にすることができ、[ RFC6839]で定義されているようなapplication/jsonメディア・タイプもしくはメディア・タイプ+jsonサフィックスに依存する既存クライアントを破壊することなしに、既存インフラ用のアップグレード・パスを提供する。

通常のJSON文書で外部コンテキストを使用するためには、作成者はhttp://www.w3.org/ns/json-ld#contextリンク・リレーションを使用することによってHTTPリンク・ヘッダ [ RFC5988] に正しいJSON-LD 文書IRIを指定しなければならない(MUST)。 参照される文書はトップ・レベルJSONオブジェクトを持たなければならない(MUST)。 オブジェクト内の@contextサブツリーは参照文書のJSONオブジェクトトップ・レベルに追加される。 もし参照文書のトップ・レベルが配列でありかつ要素がJSONオブジェクトである場合は、@context サブツリーは配列のすべての要素に追加される。 参照ドキュメントの@contextサブツリーの外部に位置しているすべての特別な情報は破棄されなくてはならない( MUST)。 このことは事実上 アクティブ・コンテキストは外部参照コンテキストとともに初期化されることを意味している。 レスポンスはhttp://www.w3.org/ns/json-ld#contextリンク・リレーションを使用することによって1つ以上のHTTPリンク・ヘッダ[ RFC5988]を含んではならない(MUST NOT)。

次の例は通常のJSON文書と外部コンテキストの使用方法を示している。

例 30: HTTPリンクヘッダを通じてJSON文書からJSON-LDコンテキストを参照する。
GET /ordinary-json-document.json HTTP/1.1
Host: example.com
Accept: application/ld+json,application/json,*/*;q=0.1
====================================
HTTP/1.1 200 OK
...
Content-Type: application/json
Link: <http://json-ld.org/contexts/person.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"
{
    "name": "Markus Lanthaler",
    "homepage": "http://www.markus-lanthaler.com/",
    "image": "http://twitter.com/account/profile_image/markuslanthaler"
}

application/ld+json メディア・タイプで供給されるJSON-LD文書は 文書の本文内に外部コンテキストへの参照を含めたすべてのコンテキスト情報がなければならない(MUST)ことに注意されたい。 http://www.w3.org/ns/json-ld#contextHTTP リンク・ヘッダを通じてリンクされたコンテキストはそのような文書のために無視されなければならない(MUST)。

6.9 文字列の国際化

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

ときどき、言語のために文字列に注記することは重要である。 JSON-LDではさまざまな方法で可能である。 最初に、コンテキスト@languageキーを設定することによってJSON-LD文書のための既定言語を定義することが可能である。

例 31:JSON-LD文書の既定言語の設定
{
    "@context":
    {
        ...
        "@language": "ja"
    },
    "name": "花澄",
    "occupation": "科学者"
}

上の例は2つの文字列花澄科学者の言語コードをjaに関連付けている。 言語コードは[ BCP47]で定義されている。 既定の言語はすべての型強制されていない文字列値に適用される。

サブ・ツリーにおいて既定の言語をクリアするために、@languageは次のようにローカル・コンテキスト中にnullを設定することができる。

例 32: 既定言語のクリア
{
    "@context": {
        ...
        "@language": "ja"
    },
    "name": "花澄",
    "details": {
        "@context": {
            "@language": null
        },
        "occupation": "Ninja"
    }
}

2つ目に、拡張用語定義を使用して特定の用語に言語を関連付けることができる。

例 33: 言語を伴う拡張用語定義
{
    "@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指定している。 nameYagyū Muneyoshi拡張用語定義nullにリセットされているのでいずれの言語コードにも関連しない。

言語の関連付けはプレーン文字列のみ適用される。 型付けされた値もしくは型強制の対象である値は言語をつけられない。

上の例の通り、システムはしばしば複数の言語のプロパティ値を表すことを必要とする。 一般的に、そのようなシステムは、開発者が言語固有データのデータ構造操作のためのプログラム的に容易な手段を保証するか試みる。 このような場合、 言語マップが役にたつ。

例 34: 3つの言語のプロパティで表わされた言語マップ
{
    "@context":
    {
        ...
        "occupation": { "@id": "ex:occupation", "@container": "@language" }
    },
    "name": "Yagyū Muneyoshi",
    "occupation":
    {
        "ja": "忍者",
        "en": "Ninja",
        "cs": "Nindža"
    }
    ...
}

上の例はひとつ前の例と正確に同じ情報を表しているが、1つのプロパティにすべての値がまとめられている。 オブジェクト・プロパティのためのドット表記のをサポートするプログラム言語中で固有の言語にアクセスするために、開発者はproperty.languageパターン使用することができる。 例えば、英語の職業にアクセスするには、開発者は次のコードを使用する: obj.occupation.en

3つ目に、値オブジェクトを使用することによって既定の言語を再定義することができる。

例 35: 拡張された値を使用した既定の言語の再定義
{
    "@context": {
        ...
        "@language": "ja"
    },
    "name": "花澄",
    "occupation": {
        "@value": "Scientist",
        "@language": "en"
    }
}

@languageタグを省略するか値オブジェクトを使用して表す時にnullを設定することでプレーン文字列を指定することが可能である。

例 36: 拡張された値を使用した言語情報の除去
{
    "@context": {
        ...
        "@language": "ja"
    },
    "name": {
        "@value": "Frank"
    },
    "occupation": {
        "@value": "Ninja",
        "@language": "en"
    },
    "speciality": "手裏剣"
}

6.10 コンテキスト内のIRI拡張

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

一般的に、通常のIRI拡張ルールはIRIとして予想される(5.2 IRI節 参照)ところであればどこでも適用される。 コンテキスト定義内では、コンテキスト内で定義された用語は循環依存がない限りコンテキスト内で使用できることを意味する。 例えば、型付けされた値を定義するときxsd名前空間を使用することが一般的である。

例 37: 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を定義するときに使用することができる。

例 38: コンテキスト内の他の用語の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用語定義の左辺で使用することができる。

例 39: 用語として短縮IRIを使用
{
    "@context":
    {
        "foaf": "http://xmlns.com/foaf/0.1/",
        "xsd": "http://www.w3.org/2001/XMLSchema#",
        "name": "foaf:name",
        "foaf:age":
        {
            "@type": "xsd:integer"
        },
        "foaf:homepage":
        {
            "@type": "@id"
        }
    },
    ...
}

この例では, 短縮IRI形式は2つの異なる手段で使用される。 最初のアプローチは、foaf:age@type 用語に関連する@typeはもちろん用語 (短縮形式を使用して)のためのIRIの両方を宣言する。 2つ目のアプローチは、用語に関連する@typeのみを指定する。 foaf:homepageのフルIRIコンテキスト内でfoafプリフィクスを探索することによって決定する。

絶対IRIコンテキスト内のキー位置で使用できる。

例 40: 絶対IRIとコンテキスト定義の関連付け
{
    "@context":
    {
        "foaf": "http://xmlns.com/foaf/0.1/",
        "xsd": "http://www.w3.org/2001/XMLSchema#",
        "name": "foaf:name",
        "foaf:age":
        {
            "@id": "foaf:age",
            "@type": "xsd:integer"
        },
        "http://xmlns.com/foaf/0.1/homepage":
        {
            "@type": "@id"
        }
    },
    ...
}

上の絶対IRIがマッチするためには、絶対IRIJSON-LD 文書中で使用される必要がある。 またfoaf:homepagehttp://xmlns.com/foaf/0.1/homepageと同じではないので{ "@type": "@id" }宣言を使用することができないことに注意する。 すなわち、用語プリフィクス検索メカニズムが適用される前に直接文字列比較を使用してコンテキスト内を検索する。

短縮IRI絶対IRIを他の関連のない IRI (例えば foaf:namehttp://example.org/unrelated#speciesに拡張する)に拡張するように定義することができるとはいえ、そのような用法は強く非推奨である。

コンテキスト内で用語使用するときの唯一の例外は循環定義が許されていないことでである。 すなわち、 term2term1に依存している場合はterm1の定義はterm2の定義に依存することはできない。 例えば、次のコンテキスト定義は不正である。

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

6.11 セットとリスト

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

JSON-LD作成者は 配列を使用することによって簡潔な手法で複数の値を表すことができる。 グラフはノード間のリンクのための順序を記述することができないので、JSON-LD中の配列は既定では含まれている要素の順序づけを提供しない。 これは正規の既定では順序付けされるJSON配列と正反対である。 例えば次の簡単な文書を考えてみる。

例 42: 固有の順序を伴わない複数の値
{
    ...
    "@id": "http://example.org/people#joebob",
    "nick": [ "joe", "bob", "JB" ],
    ...
}

上で表される例では、各々は個別の値としてノードに関連付けられ、固有の順序がなく、 生成されるデータは次の結果となる。

対象 プロパティ
http://example.org/people#joebob http://xmlns.com/foaf/0.1/nick joe
http://example.org/people#joebob http://xmlns.com/foaf/0.1/nick bob
http://example.org/people#joebob http://xmlns.com/foaf/0.1/nick JB

複数値は拡張形式を使用することによって表現することが可能である。

例 43: 複数の値を設定するための拡張形式の使用
{
    "@id": "http://example.org/articles/8",
    "dc:title": 
    [
        {
            "@value": "Das Kapital",
            "@language": "de"
        },
        {
            "@value": "Capital",
            "@language": "en"
        }
    ]
}

上の例も固有の順序のない次のデータが生成される。

Subject Property Value Language
http://example.org/articles/8 http://purl.org/dc/terms/title Das Kapital de
http://example.org/articles/8 http://purl.org/dc/terms/title Capital en

順序付けされたコレクションの概念はデータ・モデリングではかなり重要であるとして、特別な言語サポートを持つことは有用である。 JSON-LDでは、リストは次のように@listキーワードを使用することによって表現することができる。

例 44: JSON-LDにおける順序付けされた値のコレクション
{
    ...
    "@id": "http://example.org/people#joebob",
    "foaf:nick":
    {
        "@list": [ "joe", "bob", "jaybee" ]
    },
    ...
}

順序付けされた配列を使用すると記述し、順序は文書を処理するときも維持される。 すべての複数値を与えられるプロパティがリストである場合、コンテキスト@container@listを設定することによって短縮することができる。

例 45: コンテキストに順序付けられたコレクションを指定する
{
    "@context":
    {
        ...
        "nick":
        {
            "@id": "http://xmlns.com/foaf/0.1/nick",
            "@container": "@list"
        }
    },
    ...
    "@id": "http://example.org/people#joebob",
    "nick": [ "joe", "bob", "jaybee" ],
    ...
}

リスト・オブジェクト形式のリストのリストは現在のバージョンのJSON-LDでは許されていない。 この決定はリストのリストを処理するとき複雑さが大量に追加されるためである。

@list順序付けられたリストを記述するために使用される一方、@setキーワードは順不同のセットを記述するために使用される。 JSON-LD文書の本文に@setを使用することは、それはちょうど糖衣構文のように、文書を処理するときに最適化により削除される。 しかしながら、@setは文書のコンテキスト内で使用するときには有益である。 @setもしくは@listコンテナに関連付けられた用語の値は通常であれば短縮形式 (section 6.18 短縮された文書形式参照)で配列でない形式に最適化され単一の値になる場合でも、常に配列の形式で表現される。 このことはたとえ配列がただ1つの値しか含まれなかったとしても、データがいつも配列形式であることでJSON-LD文書の後処理を容易にさせる。

6.12 逆プロパティ

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

JSON-LDは有向グラフをシリアル化する。 それはすべてのプロパティノードから他のノードへ向いていることを意味する。 しかしながら、ときとして、逆方向にシリアライズすることが望ましいことがある。 例えば親と子が文書に記載されるケースを考えてみてほしい。 使用する語彙がプロパティだけでなくプロパティも規定されない場合、すべての子を表現するノードは次のように親を指すプロパティを表現しなくてはならない。

例 46: 子供を親にリンクした文書
[
    {
        "@id": "#homer",
        "http://example.com/vocab#name": "Homer"
    },
    {
        "@id": "#bart",
        "http://example.com/vocab#name": "Bart",
        "http://example.com/vocab#parent": { "@id": "#homer" }
    },
    {
        "@id": "#lisa",
        "http://example.com/vocab#name": "Lisa",
        "http://example.com/vocab#parent": { "@id": "#homer" }
    }
]

そのようなデータの表現はJSON-LDの@reverseキーワードの使用でとても簡素になる。

例 47: 逆プロパティを使用した親子
{
    "@id": "#homer",
    "http://example.com/vocab#name": "Homer",
    "@reverse": {
        "http://example.com/vocab#parent": [
            {
                "@id": "#bart",
                "http://example.com/vocab#name": "Bart"
            },
            {
                "@id": "#lisa",
                "http://example.com/vocab#name": "Lisa"
            }
        ]
    }
}

また@reverseキーワードは次の例で示されるように拡張用語定義中で逆プロパティを定義し使用することができる。

例 48: 逆プロパティを定義するための@reverseの使用
{
    "@context": {
        "name": "http://example.com/vocab#name",
        "children": { "@reverse": "http://example.com/vocab#parent" }
    },
    "@id": "#homer",
    "name": "Homer",
    "children": [
        {
            "@id": "#bart",
            "name": "Bart"
        },
        {
            "@id": "#lisa",
            "name": "Lisa"
        }
    ]
}

6.13 名前付きグラフ

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

ときどき, 単一のノードよりもむしろグラフ自身の文を作成する必要がある。 これは@graphキーワードを使用することによってノードのセットをグループ化することによって行うことができる。 開発者は次の例で示すように@idキーワードとペアで@graphキーワードを使用することによってデータを命名することができる。

例 49: グラフについての文を作成し識別する
{
    "@context": {
        "generatedAt": {
            "@id": "http://www.w3.org/ns/prov#generatedAtTime",
            "@type": "http://www.w3.org/2001/XMLSchema#date"
        },
        "Person": "http://xmlns.com/foaf/0.1/Person",
        "name": "http://xmlns.com/foaf/0.1/name",
        "knows": "http://xmlns.com/foaf/0.1/knows"
    },
    "@id": "http://example.org/graphs/73",
    "generatedAt": "2012-04-09",
    "@graph":
    [
        {
            "@id": "http://manu.sporny.org/about#manu",
            "@type": "Person",
            "name": "Manu Sporny",
            "knows": "http://greggkellogg.net/foaf#me"
        },
        {
            "@id": "http://greggkellogg.net/foaf#me",
            "@type": "Person",
            "name": "Gregg Kellogg",
            "knows": "http://manu.sporny.org/about#manu"
        }
    ]
}

上の例はIRI http://example.org/graphs/73によって識別される名前付きグラフを表している。 グラフはManuとGreggについての文で構成されている。 グラフ自身のメタデータは、グラフがいつ生成されたかを指定するgeneratedAtプロパティで表現される。 上の情報の別の表現を以下の表で表わす。

グラフ 対象 プロパティ 値型
  http://example.org/graphs/73 http://www.w3.org/ns/prov#generatedAtTime 2012-04-09 http://www.w3.org/2001/XMLSchema#date
http://example.org/graphs/73 http://manu.sporny.org/about#manu http://www.w3.org/2001/XMLSchema#type http://xmlns.com/foaf/0.1/Person
http://example.org/graphs/73 http://manu.sporny.org/about#manu http://xmlns.com/foaf/0.1/name Manu Sporny
http://example.org/graphs/73 http://manu.sporny.org/about#manu http://xmlns.com/foaf/0.1/knows http://greggkellogg.net/foaf#me
http://example.org/graphs/73 http://greggkellogg.net/foaf#me http://www.w3.org/2001/XMLSchema#type http://xmlns.com/foaf/0.1/Person
http://example.org/graphs/73 http://greggkellogg.net/foaf#me http://xmlns.com/foaf/0.1/name Gregg Kellogg
http://example.org/graphs/73 http://greggkellogg.net/foaf#me http://xmlns.com/foaf/0.1/knows http://manu.sporny.org/about#manu

JSON-LD文書のトップレベル構造がオブジェクトプロパティ@graphとオプションの@context(IRIもしくはキーワードが無視されマップされないプロパティ)しか含まれない時, @graphは別な方法で暗黙に既定グラフを表現しているものとみなされる。 この仕組みは1つのノード が同じ コンテキストを共有するドキュメントのトップレベルに存在するとき、例えば、文書がフラットである場合に役にたつ。 @graphキーワードは配列 の中や共有コンテキストの使用が許されたノードのように集められる。

例 50:既定のグラフを明示的に表現するために@graphを使用
{
    "@context": ...,
    "@graph":
    [
        {
            "@id": "http://manu.sporny.org/about#manu",
            "@type": "foaf:Person",
            "name": "Manu Sporny",
            "knows": "http://greggkellogg.net/foaf#me"
        },
        {
            "@id": "http://greggkellogg.net/foaf#me",
            "@type": "foaf:Person",
            "name": "Gregg Kellogg",
            "knows": "http://manu.sporny.org/about#manu"
        }
    ]
}

この場合、埋め込みはそれぞれのノード・オブジェクト が他を参照するため動作しない。 これは配列中の複数のノード・オブジェクト使用し各ノード・オブジェクト内の@contextを定義することと等価である。

例 51: @graphが使用されていない場合コンテキストは重複する必要がある
[
    {
        "@context": ...,
        "@id": "http://manu.sporny.org/about#manu",
        "@type": "foaf:Person",
        "name": "Manu Sporny",
        "knows": "http://greggkellogg.net/foaf#me"
    },
    {
        "@context": ...,
        "@id": "http://greggkellogg.net/foaf#me",
        "@type": "foaf:Person",
        "name": "Gregg Kellogg",
        "knows": "http://manu.sporny.org/about#manu"
    }
]

6.14 空ノードの識別

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

たまに, IRIノードを一意に識別することなしに情報を表現することが必要になる。 このノード型は空ノードと呼ばれる。 JSON-LDはすべてのノードが@idを使用して識別する必要はない。 しかしながら、あるグラフ形態ではシリアライズ可能とするために識別子を必要とする。 ループを含むグラフは、例えば、埋め込みのみを使用してシリアライズできず、 @idがノードを接続するために使用されなければならない。 このようなとき、仕組みとしてアンダースコア( _)を使用したIRIに似た空ノード識別子を使用することができる。 これは文書内のローカルなノードへの参照することを可能にするが、外部文書からのノードの参照が不可能になる。 空ノード定義子はそれを使用する文書にスコープされる。

例 52: ローカル・空ノード識別子の指定
{
    ...
    "@id": "_:n1",
    "name": "Secret Agent 1",
    "knows":
    {
        "name": "Secret Agent 2",
        "knows": { "@id": "_:n1" }
    }
}

上の例はIRIで識別されない2人の秘密エージェントについての情報を含んでいる。 agent 1agent 2の知人であると表現することは空ノード識別子を使用しないで可能であるが、agent 2から参照できるようにするためにagent 1に識別子を割り当てる必要がある。

空ノード識別子が処理中に再度ラベル付けできることは注目に値しない。 もし開発者が1つ以上の空ノードを参照しているのを見つけたら、他のドキュメントから参照されるためにIRIを参照解除を使用するノードに命名することを考慮すべきである。

6.15 キーワードの別名

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

それぞれのJSON-LD キーワードは、@contextをのぞいて、アプリケーション固有のキーワードのために別名をつけることができる。 この機能により古いJSON-LDコンテンツを古い文書にすでに存在するJSONキーを再利用してJSON-LDに利用することを可能となる。 この機能はまた開発者がJSON-LDコンテキストのみで使用するドメイン固有の実装を設計することを可能にする。

例 53: 別名キーワード
{
    "@context":
    {
        "url": "@id",
        "a": "@type",
        "name": "http://xmlns.com/foaf/0.1/name"
    },
    "url": "http://example.com/about#gregg",
    "a": "http://xmlns.com/foaf/0.1/Person",
    "name": "Gregg Kellogg"
}

上の例では、@id@typeキーワード がそれぞれurlaという別名を与えられている。

キーワードは再定義することはできず、また他のキーワードを別名にすることもできない。

6.16 データの索引付け

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

データベースは一般的にはデータへのアクセスさらに効率的にするために使用される。 開発者は多くの場合、同じようなパフォーマンスの向上を提供するために、それらのアプリケーションデータにこの種の機能を拡張する。 このデータはリンクされたデータの観点では意味を持っていないが、アプリケーションには有用である。 JSON-LDは、アクセスをより効率的な形式にデータを構造化するために使用することができる索引マップの概念を導入した。データの索引付け機能は、作成者がキーがIRIにマップされていない単純なキーと値のマップを使用しデータを構造化することができる。 これは、特定のアイテムを求めるために配列をスキャンする代わりにデータへの直接アクセスを可能にする。 JSON-LDでは、このようなデータは、コンテキスト内@container宣言で@indexキーワードを関連付けることによって指定することができる。

例 54: JSON-LDのデータの索引付け
{
    "@context":
    {
        "schema": "http://schema.org/",
        "name": "schema:name",
        "body": "schema:articleBody",
        "words": "schema:wordCount",
        "post": {
            "@id": "schema:blogPost",
            "@container": "@index"
        }
        },
        "@id": "http://example.com/",
        "@type": "schema:Blog",
        "name": "World Financial News",
        "post": {
        "en": {
            "@id": "http://example.com/posts/1/en",
            "body": "World commodities were up today with heavy trading of crude oil...",
            "words": 1539
        },
        "de": {
            "@id": "http://example.com/posts/1/de",
            "body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
            "words": 1204
        }
    }
}

上記の例では、post用語は、索引マップとしてマークされている。endeキーは、意味的に無視されるが、JSON-LDのプロセッサによって、構文的に保存される。これにより開発者は次のコードスニペットobj.post.deを使用してpostのドイツ語版にアクセスすることができる。

上記のデータの解釈は以下の表に表される。 索引キーは、以下のリンク・データには表示されないが、文書がJSON-LDのプロセッサを使用して(6.18 圧縮された文書形式節と 6.17 拡張文書形式節を参照)圧縮されるか拡張された場合でも存在し続けることに注意すること。

Subject Property Value
http://example.com/ http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://schema.org/Blog
http://example.com/ http://schema.org/name World Financial News
http://example.com/ http://schema.org/blogPost http://example.com/posts/1/en
http://example.com/ http://schema.org/blogPost http://example.com/posts/1/de
http://example.com/posts/1/en http://schema.org/articleBody World commodities were up today with heavy trading of crude oil...
http://example.com/posts/1/en http://schema.org/wordCount 1539
http://example.com/posts/1/de http://schema.org/articleBody Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...
http://example.com/posts/1/de http://schema.org/wordCount 1204

6.17 拡張文書形式

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

JSON-LD処理アルゴリズムとAPI仕様[JSON-LD-API]はJSON-LDの文書を拡張 する方法を定義する。拡張とはJSON-LDドキュメントを取得し、すべてのIRI・型・値が@contextが不要となるまでに拡張されるように@contextを適用するプロセスである。

たとえば、以下のJSON-LDの入力文書を仮定する。

例 55: サンプル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拡張アルゴリズムを実行すると、次の出力結果となるだろう。

例 56: 前の例の展開形式
[
    {
        "http://xmlns.com/foaf/0.1/name": [
            { "@value": "Manu Sporny" }
        ],
        "http://xmlns.com/foaf/0.1/homepage": [
            { "@id": "http://manu.sporny.org/" }
        ]
    }
]

JSON-LDのメディア・タイプは、拡張文書形式を通知もしくは要求に使用できるプロファイル・パラメータを定義する。拡張文書形式を識別するプロファイルURIはhttp://www.w3.org/ns/json-ld#expandedである。

6.18 圧縮文書形式

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

JSON-LD処理アルゴリズムとAPI仕様[JSON-LD-API]はJSON-LD文書を圧縮するための方法を定義する。 圧縮は、用語のための短いIRIもしくは短縮IRIと拡張形式で文字列もしくは数値のような単純な値によって表現されたJSON-LD値に開発者が提供するコンテキストを適用するプロセスである。 圧縮文書はまた、一般的に人間にとって読みやすくなる。

例えば、次のJSON-LD入力文書を仮定する。

例 57: 拡張された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コンテキストを仮定する。

例 58: サンプル・コンテキスト
{
    "@context": {
        "name": "http://xmlns.com/foaf/0.1/name",
        "homepage": {
            "@id": "http://xmlns.com/foaf/0.1/homepage",
            "@type": "@id"
        }
    }
}

上で提供されたJSON-LD入力文書に対して上で提供されたコンテキストを与えられたJSON-LD圧縮アルゴリズムを実行すると以下の出力結果となるであろう。

例 59: サンプル・コンテキストが適用されたサンプル・ドキュメントの圧縮形式
{
    "@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のメディア・タイプは、圧縮文書形式を通知もしくは要求に使用できるプロファイル・パラメータを定義する。 拡張文書形式を識別するプロファイルURIはhttp://www.w3.org/ns/json-ld#compactedである。

6.19 フラット化文書形式

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

JSON-LD処理アルゴリズムとAPI仕様[JSON-LD-API]はJSON-LD文書をフラット化するための方法を定義する。 フラット化は、単一のJSONオブジェクト内のノードのすべてのプロパティを収集し、空白ノード識別子を持つすべての空白ノードにラベルを付ける。これは、データの形状を保証し、その結果特定のアプリケーションにおいてJSON-LDを処理するのに必要なコードを大幅に簡略化することができる。

例えば次のJSON-LD入力文書を仮定する。

例 60: 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フラット化アルゴリズムを実行すると次の結果が得られるだろう。

例 61: 前の例のフラット化と圧縮化形式
{
    "@context": {
        "name": "http://xmlns.com/foaf/0.1/name",
        "knows": "http://xmlns.com/foaf/0.1/knows"
    },
    "@graph": [
        {
            "@id": "_:b0",
            "name": "Dave Longley"
        },
        {
            "@id": "http://manu.sporny.org/about#manu",
            "name": "Manu Sporny"
        },
        {
            "@id": "http://me.markus-lanthaler.com/",
            "name": "Markus Lanthaler",
            "knows": [
                { "@id": "http://manu.sporny.org/about#manu" },
                { "@id": "_:b0" }
            ]
        }
    ]
}

JSON-LDのメディア・タイプは、フラット化文書形式を通知もしくは要求に使用できるプロファイル・パラメータを定義する。 フラット化文書形式を識別するためのプロファイルURIはhttp://www.w3.org/ns/json-ld#flattenedである。 それは拡張文書形式もしくは圧縮文書形式と組み合わせることができる。.

6.20 HTML 文書中のJSON-LDの埋め込み

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

HTMLスクリプトタグは、ドキュメント内のデータ・ブロックを埋め込むために使用することができる。 これによりJSON-LDのコンテンツは、type属性にapplication/ld+jsonを設定したscript要素を置くことで、HTMLに簡単に埋め込むことができる。

例 62: HTML中のJSON-LDの埋め込み
<script type="application/ld+json">
{
    "@context": "http://json-ld.org/contexts/person.jsonld",
    "@id": "http://dbpedia.org/resource/John_Lennon",
    "name": "John Lennon",
    "born": "1940-10-09",
    "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
</script>

HTML文書が配信される方法に応じて、特定の文字列をエスケープする必要があるかもしれない。

使用するデータがどのように定義できるはこの仕様の範疇を超える。 埋め込まれたJSON-LD文書はそのままの形で取り出されるか、例えば、RDFとして解釈される。

もしJSON-LDコンテンツがRDF [RDF11-CONCEPTS]として取り出された場合、JSON-LDをRDFへのデシリアライズ・アルゴリズム[JSON-LD-API]を使用してRDF データセットに拡張する必要がある。

7. データ・モデル

JSON-LDはJSONに基づいたリンク・データ用のシリアル化形式である。 したがって[RFC4627]中のJSONによって定義される構文とRDFデータ・モデル[RDF11-CONCEPTS]の拡張であるデータ・モデルを区別することが重要である。 JSON-LDがRDFデータ・モデルとどのように関連するかの正確な詳細は、9. RDFへの連携で与えられる。

RDFモデルに慣れていない開発者のための理解を容易にするために、以下の概要が提供されている。

JSON-LD文書は上記で定義されたデータ・モデルによって表すことができないデータを含むことができる(MAY)。特に断りのない限りJSON-LD 文書が処理されるとき、そのようなデータは無視される。このルールの結果は、IRI空白ノードもしくはキーワードにマッピングされていないプロパティは無視されるということである。

An illustration of the データ・モデル

図 1: データ・モデルのイラスト

8. JSON-LD構文

この付録では、前節で述べた構文規則をさらに正式に述べる。

A JSON-LD 文書は[ RFC4627]で記述されるような有効なJSON文書でなければならない(MUST)。

JSON-LD 文書はトップレベルにおいてシングル・ノード・オブジェクトもしくは要素それぞれがノード・オブジェクトである配列でなければならない(MUST)。

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

JSON-LDは、キーワードは(詳細については、section 6.15 キーワードの別名を参照)別名をつけることができる。 キーワードはこの文法で会話されるときはいつでも、文にそのキーワードの別名が適用される。 キーワードの別名はコンテキストの処理中は拡張されないことに注意すること。

8.1 用語

用語はIRIもしくは空白ノード識別子に拡張される短い文字列である。

用語いずれのキーワードと同じにしてはならない(MUST NOT)。

前方互換性の問題を回避するため、用語はJSON-LDの将来のバージョンが追加キーワードを導入できるように@文字で始めるべきではない(SHOULD NOT) 。 さらに、用語はプログラム言語のすべてが空のJSONキーを処理できるわけではないので空の文字列( "")にしてはいけない(MUST NOT)。

用語IRIへマッピングすることのさらに進んだ議論は5.1 コンテキスト5.2 IRIs節を参照せよ。

8.2 ノード・オブジェクト

ノード・オブジェクトJSON-LD 文書によってシリアル化されたグラフ中の0個以上のプロパティを表現する。 JSONオブジェクトはもしそれがJSON-LD コンテキストの外側に存在し、かつ:

場合、ノード・オブジェクトである。

グラフ内のノードプロパティは文書中の異なるノード・オブジェクトに分散されていてもよい。 これが発生すると、異なるのノード・オブジェクトのキーは、得られたノードのプロパティを作成するためにマージする必要があります。

ノード・オブジェクトJSONオブジェクトでなければならない(MUST)。 IRIでもなく、短縮IRIでもなく、アクティブ・コンテキスト中の有効な用語でもなく、次のキーワードのうちの1つでもない、キーはすべて処理時には無視されなければならない(MUST)。

ノード・オブジェクト@contextキーを含む場合、その値はnull絶対IRI相対IRIコンテキスト定義、もしくはこれらで構成された配列のいずれかでなければならない(MUST)。

ノード・オブジェクト@idキーを含む場合、その値は絶対IRI相対IRI短縮IRI ( 空白ノード識別子を含む)のいずれかでなければならない(MUST)。 さらに進んだ@id値の議論については5.3 ノード識別子節, 6.3 短縮IRI節、6.14 空白ノードの識別を参照すること。

ノード・オブジェクト@graphキーを含む場合、その値はノード・オブジェクトもしくは0以上のノード・オブジェクト配列でなければならない(MUST)。 ノード・オブジェクト@idキーワードを含む場合、その値は名前付きグラフのためのラベルとして使用される。 @graph値ののさらに進んだ議論については6.13 名前付きグラフ節を参照すること。 特別なケースとして、if a JSONオブジェクト@graph@context以外のキーを含まず、かつJSONオブジェクトがJSON-LD文書のルートである場合、JSONオブジェクトノード・オブジェクトとして取り扱われない。これは接続されたグラフ形式ではないノード定義を定義する手段として使用される。 これはすべての構成ノード・オブジェクトによって共有されるコンテキストを定義することを可能にする。

ノード・オブジェクト@typeキーを含む場合、その値は絶対IRI相対IRI短縮IRI (空白ノード識別子を含む)、絶対IRIで拡張されるアクティブ・コンテキスト中で定義された用語、これらのいずれか配列でなければならない(MUST)。@type値のさらに進んだ議論については5.4 型の指定節を参照すること。

ノード・オブジェクト@reverseキーを含む場合、その値は逆プロパティを表現するメンバーを含むJSONオブジェクトでなければならない(MUST)。 このような逆プロパティの値は絶対IRI相対IRI短縮IRI空白ノード識別子ノード・オブジェクトもしくはこれらを含む配列配列でなければならない(MUST )。

ノード・オブジェクト@indexキーを含む場合、その値は文字列でなければならない(MUST)。 @index値のさらに進んだ議論については6.16 データの索引付け節を参照すること。

キーワードではないノード・オブジェクトのキーはアクティブ・コンテキストを使用することによって絶対IRIに拡張することができる(MAY)。 絶対IRIキーで拡張された関連づけられた値は次のうちのいずれかでなければならない( MUST)。

8.3 値オブジェクト

A 値オブジェクトは明示的に型や言語に型付けされた値言語タグ文字列を生成するための値を結びつけるために使用される。

値オブジェクト@valueキーを含むJSONオブジェクトでなければならない(MUST)。 それはまた@type@language@index@contextキーを含めることができる(MAY)が、@type@languageキーを両方同時に含むことはできない(MUST NOT)。 値オブジェクト絶対IRIまたはキーワードに展開する他の任意のキーを含めることはできない。

@value キーに関連付ける値は文字列数値truefalse or nullのいずれかでなければならない(MUST)。

@typeキーに関連付ける値は用語短縮IRI絶対IRI相対IRInullでなければならない(MUST)。

@languageキーに関連付ける値は[ BCP47]に記述された語彙か、nullでなければならない(MUST)。

@indexキーに関連付ける値は文字列でなければならない(MUST)。

値オブジェクトの詳細については6.4 型付き値節と6.9 文字列の国際化節を参照すること。

8.4 リストとセット

リストは値の順序付けれられたセットを表現する。 セットは値の順不同のセットを表現する。 特に指定しない限り、配列はJSON-LDでは順不同である。 @setキーワードは、それ自体はJSON-LD文書の本体中で使用されるとき、文書の処理時に最適化により削除されないための糖衣構文として表現される。。 しかしながら、それは文書のコンテキスト中で使用されるときとても有用である。 @setもしくは@listコンテナに関連付けられた用語の値は文書が処理されるときつねに配列の形で表現される-たとえ圧縮文書形式で配列でない形に最適化されるであろう単一の値であったとしても。 これにより、データがいつも決まった形となるのでデータの後処理が簡素になる。

リスト・オブジェクト

セット・オブジェクト絶対IRIに拡張するキーでないか、@list@context@index以外のキーワードを含むJSONオブジェクトでなければならない(MUST)。 @indexキーは処理時には無視されることに注意すること。

@list@setキーに関連付ける値は両方とも、次の型のうちの一つでなければならない(MUST)。

セットとリストのさらに進んだ議論については6.11 セットとリストを参照すること。

8.5 言語マップ

言語マップはプログラムから容易にアクセスできるように言語と値を関連付けるために使用される。 もし@containerともに定義された用語が@languageを設定する場合、言語マップノード・オブジェクト内で用語の値として使用される。 言語マップにキーは[ BCP47] 言語コードで表現された文字列でなければならず(MUST)、値は次の型のうちの1つでなければならない(MUST)。

言語マップのさらに進んだ議論については6.9 文字列の国際化節を参照すること。

8.6 索引マップ

索引マップは意味的な意味を持たないが、JSON-LD文書中で使用されることで、何があっても維持されることを可能する。 @containerとともに定義される用語が@indexに設定される場合、ノード・オブジェクト内の用語値として使用することができる。 索引マップのメンバーの値は次の型のうちの1つでなければなたない(MUST)。

このトピック上のさらに進んだ情報については6.16 データの索引付け節を参照すること。

8.7 コンテキスト定義

コンテキスト定義ノード・オブジェクト中でローカル・コンテキストを定義する。

A コンテキスト定義はキーがMUST either be 用語短縮IRI絶対IRI、もしくは@language@base@vocabキーワードのいずれかでなければならないJSONオブジェクトでなければならない(MUST)。

コンテキスト定義@languageキーを持つ場合、その値は[ BCP47]中の語彙形式を持つかもしくはnullでなければならない(MUST)。

コンテキスト定義@base キーを持つ場合、その値は絶対IRI相対IRI、もしくはnullでなければならない(MUST)。

コンテキスト定義@vocabキーを持つ場合、その値は絶対IRI短縮IRI空白ノード識別子用語、もしくはnullでなければならない(MUST)。

キーワードでないキーの値は絶対IRI短縮IRI用語空白ノード識別子キーワードnull拡張用語定義でなけばならない(MUST)。

拡張用語定義ノード・オブジェクト中にキーとして使用されるとき用語に関連づける値の他のプロパティと同様に、用語と拡張された識別子間をマッピングを記述するために使用される。

拡張用語定義@id@reverse@type@language@containerから0以上のキーで構成されたJSONオブジェクトでなければならない(MUST)。 拡張用語定義はそれ以外の他のキーを含むべきではない( SHOULD NOT )。

拡張用語定義@reverseメンバーを持つ場合、同時に@idメンバーを持つことはできない(MUST NOT)。 @containerメンバーが存在する場合、その値はnull@set@indexのいずれかでなければならない(MUST)。

用語が短縮IRIもしくは絶対IRIで定義されておらずアクティブ・コンテキスト@vocabマッピングを持たない場合、拡張用語定義@idキーを含まねばならない(MUST)。

拡張用語定義@idキーワードを含む場合、その値はnull絶対IRI空白ノード識別子短縮IRI用語キーワードのいずれかでなければならない(MUST)。

拡張用語定義@typeキーワードを含む場合、その値は be an 絶対IRI短縮IRI用語null@idもしくは@vocab キーワードのうちの1つ、のいずれかでなければならない(MUST)。

拡張用語定義@languageキーワードを含む場合、その値は[ BCP47]中で記述されている語彙形式かnullを持たなければならない(MUST)。

拡張用語定義@containerキーワードを含む場合、その値は@list@set@language@indexnullのうちのいずれかでなければならない(MUST)。 もし値が用語@contextの外側で使用されるとき@languageである場合、関連付けれる値は be a 言語マップでなければならない。 用語@contextの外側で使用されるときに値が@indexである場合、関連付けられる値はMUST be an 索引マップでなければならない(MUST)。

用語は環状に使用することはできない(MUST NOT)。 用語の定義は他の用語が最初の用語に依存している場合、その他の用語の定義に依存できない。

コンテキストのさらに進んだ議論については5.1 コンテキストを参照すること。

9. RDFとの関係

JSON-LDは[ RDF11-CONCEPTS]中に記載されているような具体的なRDF構文である。 そのため、JSON-LD文書はRDF文書でもJSON文書でもあり、対応するRDFデータ・モデルの実体を表現する。 しかしながら、JSON-LDはまた任意にJSON-LDに汎用RDFデータセットをシリアル化できるようにRDFデータ・モデルを拡張する。 RDFデータ・モデルのためのJSON-LD拡張は

まとめると、これらの相違はJSON-LDがRDFグラフとデータセットのいずれもシリアル化する能力があり、すべてではないがほとんどのJSON-LD文書がRDF 1.1 概念 [ RDF11-CONCEPTS]で記述されているようなRDFとして直接解釈される。

RDFを逆シリアル化するとき空白ノードプロパティとして動作させる開発者と作成者のために、3つの可能性のあるアプローチが提案されている。

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

JSON-LDは汎用RDFデータセットをシリアル化するのであるが、RDFグラフ・ソースしても使用できる。 その場合、利用者は既定のグラフのみ使用できなければならず( MUST)、すべての名前付きグラフは無視される。 これはサーバーがコンテント・ネゴシエーションを使用するTurtleやJSON-LDのなどの言語でデータを公開することを可能にする。

データセットとグラフの構文両方をサポートする発行者はプライマリ・データが、情報を処理するためにデータセットをサポートしない利用者を可能とするようにデフォルト・グラフ中に格納されていることを確認しなければならない。

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

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

RDFをJSON-LDとしてシリアル化し、JSON-LDをRDFに逆シリアル化する処理は JSON-LD処理アルゴリズムとAPI仕様[ JSON-LD-API]中のRDF シリアル化-逆シリアル化 アルゴリズムに依存している。 これらのアルゴリズムのこれ以上の詳細についてはこの文書の範囲を超えているが、必要な操作の概要が処理を説明するために提供されている。

JSON-LD文書を逆シリアル化する手続きは次の手順を伴う。

  1. すべてのコンテキストを取り除き、JSON-LD文書を展開。これはプロパティ、型、値がすべて IRIと拡張された値として表現を与えられることを保証する。 拡張は6.17 拡張文書形式節で詳しく説明されている。
  2. 文書をノード・オブジェクトの配列に変えるためにドキュメントをフラット化する。 フラット化については6.19 Flattened Document Form節で詳しく説明されている。
  3. それぞれのノード・オブジェクトRDFトリプルの列に変換する。

例えば、次の圧縮形式のJSON-LD文書を考える。

例 63: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拡張およびフラット化を実行すると次の出力を得る。

例 64: 前のサンプル文書のフラット化および拡張形式
[
    {
        "@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つ以上のRDFトリプルに変換する簡単な処理となる。 これは次のタートルで表現することができる。

例 65: 拡張/フラット化文書のタートル表現
_:b0 <http://xmlns.com/foaf/0.1/name> "Dave Longley" .
<http://manu.sporny.org/about#manu> <http://xmlns.com/foaf/0.1/name> "Manu Sporny" .
<http://me.markus-lanthaler.com/> <http://xmlns.com/foaf/0.1/name> "Markus Lanthaler" ;
<http://xmlns.com/foaf/0.1/knows> <http://manu.sporny.org/about#manu>, _:b0 .

RDFをJSON-LDにシリアル化するプロセスは、最後のステップの逆、RDFトリプルを厳密にマッチする拡張されたJSON-LD文書を作成すること、共通の対象を持つすべてのトリプルのための1つのノード・オブジェクトおよび共通の述語を持つトリプルのための1つの プロパティを使用すること、と考えることができる。

A. 他のリンク・データ フォーマットとの連携

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

下のJSON-LDの例はどのようにしてJSON-LDがTurtle、RDFa、 Microformats、Microdataのようなリンク・データ フォーマット中でマークアップされているセマンティック・データを表現するために使用することができるのかを説明する。 これらの節は単に他の異なるリンク・データ アプローチを超える表現が可能であるJSON-LDが非常に柔軟であることの証拠として提供される。

A.1 Turtle

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

次はJSON-LDでTurtle [ TURTLE]で表現されたRDFをJSON-LDに変換する例である。

プリフィクス定義

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

JSON-LDコンテキストはTurtle@prefix宣言と等価である。

例 66: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/> .
例 67: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/" }
}

埋め込み

TurtleとJSON-LDの両方とも埋め込みは可能であるけれども、Turtleのみ空白ノードの埋め込みが可能である。

例 68: 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" ] .
例 69: 同じものの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"
    }
}

ネイティブ・データ型の変換

JSON-LD中の数値とブール値はネイティブ・データ型である。 Turtleはそのような値を表現する短縮構文を持っているとはいえ、RDFの抽象構文は数値とブール値は型付きリテラルとして表現される必要がある。 したがって、完全にやり取り可能にするために、JSON-LD処理アルゴリズムとAPI仕様[ JSON-LD-API]はJSON-LDのネイティブ・データとRDFの対応物間の変換ルールを定義している。 小数を除く数値xsd:integer型付きリテラルに、小数つき数値はxsd:double型付きリテラルに、2つのブール値truefalsexsd:boolean型付きリテラルに変換される。 すべての型付きリテラルは標準語彙形式である。

例 70: JSON-LDの数値とブール値用の型付き値の使用
{
    "@context":
    {
        "ex": "http://example.com/vocab#"
    },
    "@id": "http://example.com/",
    "ex:numbers": [ 14, 2.78 ],
    "ex:booleans": [ true, false ]
}
例 71: 同じものの型付きリテラルを使用した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 .

リスト

JSON-LDとTurtleの双方は値の連続的なリストを表現することができる。

例 72: 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" ) .
例 73: 同じものの 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" ]
    }
}

A.2 RDFa

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

次の例は[ RDFA-CORE]でそれぞれの名前とホームページとともに3人の人を記述している。

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

一つのコンテキストを使用したJSON-LD実装の例を以下に記述する。

例 75: 同じもののJSON-LD(コンテキストがノード・オブジェクト間で共有されている)の記述
{
    "@context":
    {
        "foaf": "http://xmlns.com/foaf/0.1/"
    },
    "@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"
        }
    ]
}

A.3 Microformat

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

次の例はどのようにMicroformat[ MICROFORMATS]がJSON-LDで表わされるのかを表現するために簡単なMicroformat hCardを使用している。

例 76:簡単なMicroformat hCardつきのHTMLの断片
<div class="vcard">
<a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
</div>

hCardの表現はコンテキスト中のMicroformat用語で表現され、urlfnプロパティについてはそれを直接使用する。 またMicroformatからJSON-LDへのプロセッサはhttp://tantek.com/のための生成された適切なURL型を持つことに注意すること。

例 77: 同じもののJSON-LDのhCard表現
{
    "@context":
    {
        "vcard": "http://microformats.org/profile/hcard#vcard",
        "url":
        {
            "@id": "http://microformats.org/profile/hcard#url",
            "@type": "@id"
        },
        "fn": "http://microformats.org/profile/hcard#fn"
    },
    "@type": "vcard",
    "url": "http://tantek.com/",
    "fn": "Tantek Çelik"
}

A.4 Microdata

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

下の例のHTML Microdata [ MICRODATA] はMicrodataワーク・アイテムとして本の情報を表している。

例 78: HTML fragments that describes a book using microdata
<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/terms/title">Just a Geek</cite></dd>
    <dt>By</dt>
    <dd><span itemprop="http://purl.org/dc/terms/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/terms/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/terms/type" href="http://purl.oreilly.com/product-types/EBOOK">
    Ebook
    </dd>
</dl>

Microdata情報のJSON-LDの表現はコンテキストを避け代わりにフルIRIによってアイテムを参照していることでMicrodataコミュニティの要望に忠実であることに注意すること。

例 79: Same book description in JSON-LD (avoiding contexts)
[
    {
        "@id": "http://purl.oreilly.com/works/45U8QJGZSQKDH8N",
        "@type": "http://purl.org/vocab/frbr/core#Work",
        "http://purl.org/dc/terms/title": "Just a Geek",
        "http://purl.org/dc/terms/creator": "Whil Wheaton",
        "http://purl.org/vocab/frbr/core#realization":
        [
            "http://purl.oreilly.com/products/9780596007683.BOOK",
            "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/terms/type": "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/terms/type": "http://purl.oreilly.com/product-types/EBOOK"
    }
]

B. IANAの考慮

この節はIANAにレビュー、承認、登録するためにInternet Engineering Steering Group (IESG)に提出された。

application/ld+json

タイプ名:
application
サブタイプ名:
ld+json
必須パラメータ:
None
オプション・パラメータ:
profile

[ RFC6906]に合致しJSON-LD文書に適合する特定の規約や制約を識別するための空でないスペースで区切られたURIのリスト。 プロファイルは、プロファイルの知識なしに処理するとき、プロファイルされたリソースの知識を持つもしくは持たない両方のクライアントが同じ表現で安全に使用できるように、リソース表現の意味を変更しない。 profileパラメータはコンテンツのネゴシエーション・プロセス中で設定を示すためにクライアントによって使用することが可能である(MAY)。 profileパラメータが与えられる場合、サーバーはサーバーによって認識されているリストでプロファイルを受け取り文書を返すべきである(SHOULD)。 それはプロファイルURIが参照解除可能であり、URIで有用な文書を提供することを推奨する( RECOMMENDED)。

この仕様では profileパラメータのために3つの値を定義する。 拡張JSON-LD文書形式を指定もしくは要求するために、URI http://www.w3.org/ns/json-ld#expandedを使用するべきである(SHOULD)。 短縮JSON-LD文書形式を指定もしくは要求するために、 URI http://www.w3.org/ns/json-ld#compacted を使用するべきである(SHOULD)。 フラット化JSON-LD文書形式を指定もしくは要求するために、 URI http://www.w3.org/ns/json-ld#flattenedを使用すべきである( SHOULD)。 [ HTTP11]に適合するために profileパラメータの値は特殊文字と複数のプロファイルの組み合わせされている場合は空白文字が含まれるため、クォート( ")で囲まれなければならないことに注意いただきたい。

"profile"メディア・タイプ・パラメータを処理するとき、その値が1つ以上のIRIでないURIを含むこのに注目することが重要である。 いくつかの場合、そのために[ RFC3987]の3 IRIとURI間の関係sに明示されているようにIRIとURIを変換する必要がある。

エンコーディングの考慮:
RFC 6839, 3.1. 節を参照せよ。
セキュリティの考慮:
[RFC4627]を参照せよ。

JSON-LDは有向グラフのための純粋なデータ交換フォーマットとして意図されているので、シリアル化は解析するためにJavaScriptのeval()関数のようなコード実行機構を通すべきではない(SHOULD NOT)。 実行時にコードを含む(不正な)文書はシステムのセキュリティを損なう予期しない副作用につながる可能性がある。

JSON-LD文書を処理するとき、リモート・コンテキストへのリンクは、一般的にはそれぞれのユーザーの明示的な要求なしにファイルの転送をもたらすことで、自動的に追跡される。 リモート・コンテキストがサード・パーティーによって提供される場合、それはプライバシーの問題につながるような情報や使用パターンを収集することが可能になる。 JSON-LD処理アルゴリズムとAPI仕様[ JSON-LD-API]中のAPIのような実装仕様は、このふるまいを制御するためのきめ細かい機構を提供する。

HTTPのように、セキュアでない接続を通じてWebからロードされるJSON-LDコンテキストはセキュリティを損なう方法でJSON-LD アクティブ・コンテキストを改ざんできるように攻撃者によって変更されるリスクとなる。 ミッション・クリティカルの目的においてリモート・コンテキストに依存するアプリケーションはそれをシステムが利用することを可能にする前にリモート・コンテキストを調査しキャッシュすることを勧める。

JSON-LDは長いIRIを短い用語に置き換えることができるとすれば、JSON-LD文書は処理するときに相当に拡張し、最悪の場合、結果データが受け取り側のリソースを消費しつくすかもしれない。 アプリケーションはしかるべき懐疑心をもってデータを取り扱うべきである。

相互運用の考慮:
該当せず。
発行仕様:
http://www.w3.org/TR/json-ld
このメディア・タイプを使用するアプリケーション:
有向グラフを交換する必要のあるプログラミング環境。 JSON-LDの実装はJavaScript、 Python、 Ruby、 PHP、 C++で作成されている。
追加情報:
マジック・ナンバー:
該当せず。
ファイル拡張子:
.jsonld
Macintoshファイル・タイプ・:
TEXT
さらに進んだ情報のための連絡先とメールアドレス:
Manu Sporny <msporny@digitalbazaar.com>
意図された使用法:
公衆
使用の制限:
なし
作成者:
Manu Sporny, Dave Longley, Gregg Kellogg, Markus Lanthaler, Niklas Lindström
変更管理者:
W3C

application/ld+jsonとともに使用されるフラグメント識別子は RDF 1.1 概念と抽象構文[RDF11-CONCEPTS]によりRDF構文として取り扱われる。

C. 謝辞

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

著者らはRDFjでの作業を通じてJSON-LDの基本概念に貢献した Mark Birbeckに敬意と深い感謝の意を表したい。 JSONデータを解釈するための環境を提供するための機構としてのコンテキストのように、JSON-LDはRDFj中で提出されたいくつかのコア概念を使用している。 Markはまた、同様にRDFaの作業にも熱中していた。 RDFjはその作業の上で構築された。JSON-LDは2004年、10年近く前から始められたアイデアと作業により存在している。

メーリングリストや週次の遠隔会議上でのたくさんの技術的課題を通して作業したJSON-LDコミュニティ・グループの皆さん - 特に François Daoust,Stéphane Corlosquet, Lin Clark, and Zdenko 'Denny' Vrandečić に 多大な感謝を表する。

David I. LehnとMike Johnsonはレビュー、そして使用の初期の実装を行うこといついて高く評価される。 またRDF/JSON上での作業についてIan Davisに感謝する。

この仕様の入力について、ファースト・ネーム順の、次の個人に感謝する: Adrian Walker, Alexandre Passant,Andy Seaborne, Ben Adida, Blaine Cook, Bradley Allen, Brian Peterson,Bryan Thompson, Conal Tuohy, Dan Brickley, Danny Ayers, Daniel Leja,Dave Reynolds, David Booth, David I. Lehn, David Wood, Dean Landolt,Ed Summers, elf Pavlik,Eric Prud'hommeaux, Erik Wilde, Fabian Christ, Jon A. Frost, Gavin Carothers,Glenn McDonald, Guus Schreiber, Henri Bergius, Jose María Alvarez Rodríguez,Ivan Herman, Jack Moffitt, Josh Mandel, KANZAKI Masahide, Kingsley Idehen,Kuno Woudt, Larry Garfield, Mark Baker, Mark MacGillivray, Marko Rodriguez,Marios Meimaris, Matt Wuerstl,Melvin Carvalho, Nathan Rixham, Olivier Grisel, Paolo Ciccarese, Pat Hayes,Patrick Logan, Paul Kuykendall, Pelle Braendgaard,Peter Patel-Schneider, Peter Williams, Pierre-Antoine Champin,Richard Cyganiak, Roy T. Fielding, Sandro Hawke, Simon Grant, Srecko Joksimovic,Stephane Fellah, Steve Harris, Ted Thibodeau Jr., Thomas Steiner, Tim Bray,Tom Morris, Tristan King, Sergio Fernández, Werner Wilms, William Waites。

D. 参照

D.1 引用規格

[BCP47]
A. Phillips; M. Davis. Tags for Identifying Languages. September 2009. IETF Best Current Practice. URL: http://tools.ietf.org/html/bcp47
[RDF11-CONCEPTS]
Richard Cyganiak, David Wood, Markus Lanthaler, Editors. RDF 1.1 Concepts and Abstract Syntax. 9 January 2014. W3C Proposed Recommendation (work in progress). URL: http://www.w3.org/TR/2014/PR-rdf11-concepts-20140109/. The latest edition is available at http://www.w3.org/TR/rdf11-concepts/
[RFC2119]
S. Bradner. keywords for use in RFCs to Indicate Requirement Levels. March 1997. Internet RFC 2119. URL: http://www.ietf.org/rfc/rfc2119.txt
[RFC3987]
M. Dürst; M. Suignard. Internationalized Resource Identifiers(IRIs). January 2005. RFC. URL: http://www.ietf.org/rfc/rfc3987.txt
[RFC4627]
D. Crockford. The application/json Media Type for JavaScript Object Notation (JSON) (RFC 4627). July 2006. RFC. URL: http://www.ietf.org/rfc/rfc4627.txt
[RFC5988]
M. Nottingham. Web Linking. October 2010. Internet RFC 5988. URL: http://www.ietf.org/rfc/rfc5988.txt

D.2 参考規格

[HTTP11]
R. Fielding et al. Hypertext Transfer Protocol - HTTP/1.1. June 1999. RFC. URL: http://www.ietf.org/rfc/rfc2616.txt
[JSON-LD-API]
Markus Lanthaler, Gregg Kellogg, Manu Sporny, Editors. JSON-LD 1.0 Processing Algorithms and API. 16 January 2014. W3C Recommendation. URL: http://www.w3.org/TR/json-ld-api/
[LINKED-DATA]
Tim Berners-Lee. Linked Data. Personal View, imperfect but published. URL: http://www.w3.org/DesignIssues/LinkedData.html
[MICRODATA]
Ian Hickson, Editor. HTML Microdata. 29 October 2013. W3C Working Group Note. URL: http://www.w3.org/TR/2013/NOTE-microdata-20131029/
[MICROFORMATS]
Microformats. URL: http://microformats.org
[RDF11-MT]
Patrick J. Hayes, Peter F. Patel-Schneider, Editors. RDF 1.1 Semantics. 9 January 2014. W3C Proposed Recommendation (work in progress). URL: http://www.w3.org/TR/2014/PR-rdf11-mt-20140109/. The latest edition is available at http://www.w3.org/TR/rdf11-mt/
[RDF11-SCHEMA]
Dan Brickley; R.V. Guha, Editors. RDF Schema 1.1. 9 January 2014. W3C Proposed Edited Recommendation (work in progress). URL: http://www.w3.org/TR/2014/PER-rdf-schema-20140109/. The latest edition is available at http://www.w3.org/TR/rdf-schema/
[RDFA-CORE]
Ben Adida; Mark Birbeck; Shane McCarron; Ivan Herman et al. RDFa Core 1.1 - Second Edition. 22 August 2013. W3C Recommendation. URL: http://www.w3.org/TR/rdfa-core/
[RFC3986]
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource 識別子(URI): Generic Syntax (RFC 3986). January 2005. RFC. URL: http://www.ietf.org/rfc/rfc3986.txt
[RFC6839]
Tony Hansen, Alexey Melnikov. Additional Media Type Structured Syntax Suffixes. January 2013. Internet RFC 6839. URL: http://www.ietf.org/rfc/rfc6839.txt
[RFC6906]
Erik Wilde. The 'profile' Link Relation Type. March 2013. Internet RFC 6906. URL: http://www.ietf.org/rfc/rfc6906.txt
[TURTLE]
Eric Prud'hommeaux, Gavin Carothers, Editors. RDF 1.1 Turtle: Terse RDF Triple Language. 9 January 2014. W3C Proposed Recommendation (work in progress). URL: http://www.w3.org/TR/2014/PR-turtle-20140109/. The latest edition is available at http://www.w3.org/TR/turtle/