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を使用することである。 nameや homepageのような用語を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/" },
"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",
"image": {
"@id": "http://schema.org/image",
"@type": "@id"
},
"homepage": {
"@id": "http://schema.org/url",
"@type": "@id"
}
}
}
コンテキストが上で示したように、用語定義の値は単純な文字列、用語へのIRIのマッピング、JSONオブジェクトのいずれかにすることができる。
JSONオブジェクトが用語と結びつけられるとき、それは拡張用語定義と呼ばれる。上の例ではimageとhomepageの値は文字列であれば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と用語をどのように結びつけるかを特定するだけではなく、homepageとimageプロパティが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. 高度な概念」節中でカバーしている。
6. 高度な概念
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リンク・リレーションを使用することによって１つ以上の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指定している。
name値Yagyū 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"
}
},
...
}
短縮IRIとIRIは用語定義の左辺で使用することができる。
例 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がマッチするためには、絶対IRIはJSON-LD 文書中で使用される必要がある。
またfoaf:homepageはhttp://xmlns.com/foaf/0.1/homepageと同じではないので{ "@type": "@id" }宣言を使用することができないことに注意する。
すなわち、用語はプリフィクス検索メカニズムが適用される前に直接文字列比較を使用してコンテキスト内を検索する。
注
短縮IRIや絶対IRIを他の関連のない IRI (例えば foaf:nameをhttp://example.org/unrelated#speciesに拡張する)に拡張するように定義することができるとはいえ、そのような用法は強く非推奨である。
コンテキスト内で用語使用するときの唯一の例外は循環定義が許されていないことでである。
すなわち、 term2がterm1に依存している場合はterm1の定義はterm2の定義に依存することはできない。
例えば、次のコンテキスト定義は不正である。
例 41: 不正なコンテキスト内の用語の循環定義
{
"@context":
{
"term1": "term2:foo",
"term2": "term1:bar"
},
...
}
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。
