目次


大規模なデータ統合: RDF を使用してデータの Web を作成する

リソース指向の考え方がデータ統合にもたらすメリット

Comments

現在の世界におけるソフトウェアの基本的な目的の 1 つは、データを生成して利用することです。データ・モデルまたはスキーマを作成して、それをオブジェクト・モデルにマッピングし、コンテキストを共有する単一の受信者に合わせて外部化されたフォーマットでデータをシリアライズするのは簡単な作業です。しかし、これを複数のパートナーやコンテキストに広げるとなると、ソフトウェア作成者にとって難易度の高いタスクの 1 つとなります。このことから、私たちが取り組む統合プロジェクトは、投資に対する見返りが明らかなもののみとなりがちです。しかしそれでは、機会損失と体系的な非効率性が、適切なデータ・ソースに接続しないことによる機会費用に加わることになるかもしれません。

大規模なデータ統合に伴うのは、技術的な問題だけではありません。社会的な問題も伴います。情報を交換するには、その情報が何を意味するかについて同意する必要があります。この同意に関しても、小規模なポイント・ツー・ポイントでの交換であれば簡単な話ですが、もっと多くのエンティティーがデータ交換に参加するとなると、想像できないほど複雑になってきます。その場合、文化、言語、心理、認知、そして政治の制約に直面するからです。動的なドメインでは、要件の変更や、優先順位の変更、そしてより多くのパートナーとコラボレーションしたいという欲求が、事態をさらに困難にします。また、特定の時点でのスナップショットに依存する不安定なテクノロジーの世界 (リレーショナル・データベース・スキーマや XML スキーマ、そして既存のコード・ライブラリーなど) では、この不安定さが増幅されてほとんど制御できないほどになります。何らかの変更が追加でなされる前にソフトウェアを配布できるよう、ある程度の期間、ドメイン要素の名前と形、そして要素の相互関係に関する同意を維持する必要があります。

最近のビジネスに渦巻く混沌の中でコンセンサスを取る必要があることは、「ソフトウェア危機」という問題 (つまり、決められた時間内に高品質のソフトウェアを生産するのが難しいという事実) の主因の 1 つとなっています。この必要性に、本来必要な注意が向けられることはまれです。リレーショナル・テーブルのスキーマ、オブジェクト・リレーショナル・マッピング (ORM) ファイル、コード・ライブラリー、そしてサービス記述子の中で暗黙的または明示的に表現されたドメイン・モデルでは、ライフサイクルにあまりにも大きな依存性があるため、新機能を公開するのも、欠陥を修正するのも困難です。そのため、私たちは政治的な影響力が必要な肥大化する予算を使って、これまでになく大規模なチームを編成していますが、そのようなチームを別のチームに代えるのも再編成するのも容易ではありません。そこで、追跡可能な情報交換を促すために、マスター・データ管理 (MDM) プランとエンタープライズ・データウェアハウス (EDW) を作成して、ドメインの集団理解を統一、標準化、管理しようと努めているのが現状です。

ソフトウェア・ライフサイクル管理のドメインは、ソフトウェア危機という問題がいかに難しい問題となりうるかを示す代表例です。このドメインでは、多数のパートナーが提供しているツールを組み合わせて自前での実装とともに使用して、要件、ソフトウェア成果物、欠陥追跡、システム変更といった領域を管理しなければなりません。このソフトウェア・ライフサイクル管理というドメインの一部の側面は、これらの領域にまたがる可能性がありますが、それぞれの側面はもっと大きな問題を垂直方向に切り分けた 1 つのスライスでもあります。したがって、すべての利害関係者たちの間で、すべてのドメイン要素のすべての詳細を指定する方法についてコンセンサスに至ることは不可能でしょう。

この連載では、大規模なデータ統合の問題が新しい効果的な手段ではどのように対処されているかを説明し、各記事でソフトウェア・ライフサイクル・ドメインに対する画期的な手法である OSLC (Open Services for Lifecycle Collaboration) イニシアチブについて徐々に掘り下げていきます。OSLC のベースとなっているのは、REST (Representational State Transfer) アーキテクチャー・スタイルと、RDF (Resource Description Framework) および LDP (Linked Data Platform) などのセマンティック Web テクノロジーです。連載の最初から 3 回の記事では、OSLC の技術的基盤について説明します。その後の最後の 2 回の記事では、OSLC プロジェクトを紹介し、そのアプリケーションをデモンストレーションします。

Web: 文書が相互にリンクされたスケーラブルなプラットフォーム

Web は、十分に理解された複数のテクノロジーをベースとしています。これらのテクノロジーが連動し、文書が相互にリンクされた、柔軟かつスケーラブルな 1 つのプラットフォームを形成します。Web の今ある形を初めから設計するとしたら、それはほぼ不可能だったことでしょう。特定の問題を解決するために設計された一連の標準が重なり合うことで、目標に向かって進化するこの素晴らしいエコシステムが実現したのです。

最初のテクノロジーは、URL (Uniform Resource Locator) です。この命名スキーム (現在は、URI (Uniform Resource Identifier) 仕様に基づいています) は、グローバルな情報空間内の任意のコンテンツを識別する役割、そしてこのコンテンツを要求するための手段として機能する役割の 2 つを兼ねています。文書とコンテンツを世界と共有するには、これらの ID を e-メール、ツイート、Wiki、TV 広告、バスの車体側面、さらにはナプキンにでさえも載せて公開します。これらの ID は、私たちが管理するドメイン名をベースにしているため、中央でのメディエーションと末端での自由のバランスが見事に取られています。ID にはグローバル・スコープがありますが、通常は特定のドメインに結び付けられるため、衝突を懸念することなく共有することができます。例えば、他の人が管理するドメイン内に私が ID を作成することはできません。その逆も然りですが、自分のドメイン内であれば、いくらでも ID を作成することができます。安定性、長い存続期間、柔軟性を実現するのにふさわしい URL 設計が推奨されるものの、臨機応変にコラボレーションを行うことを目的に、任意の名前を選んで他の人と共有することもできます

私たちが一般に見慣れている URL は、文書や Web アプリケーションに関連付けられていますが、REST アーキテクチャー・スタイルでは、URL を任意の情報リソースに適用することもできます。

私たちが一般に見慣れている URL は、文書や Web アプリケーションに関連付けられていますが、REST アーキテクチャー・スタイルでは、URL を任意の情報リソースに適用することもできます。例えば、http://example.com/account/id/12345 という ID でアカウントを参照したり、製品を http://example.com/product/id/sku/9823423 で参照したりするなどです。これは実質的に、ほぼ無限大の情報空間内にある任意の情報を特定していることになります。

リソースの状態にアクセスする場合や、リソースの状態を何らかの方法で操作する場合には、2 つ目の有用な Web テクノロジーとして、HTTP を関与させることができます。HTTP は、任意のリソースに対する一様のインターフェースを提供し、リソースの作成者も作成方法も問いません。情報のクライアントとしての私は、リソースがどのように実装されているかに関する情報を何も知りませんし、知る必要もありません。例えば、ある特定のリソースに対して GET リクエストを実行すると、その結果がデフォルトの表現で返ってきます。デフォルト以外の形式でリソースを取得したいとしたら、可能であればその形式でリソースを提供するようサーバーに要求することもできます。

Web を機能させるための主要なテクノロジーとして最後に挙げるのは、HTML です。Web リソースは一般に、ブラウザー・クライアントに HTML を返します。HTML は、要求されたリソースの表現と、そのリソースの現在の状態で実行できるすべての操作を提供します。操作の例には、別の文書へのリンクを辿ること、ログインしてフォームに適切な資格情報を提供するという方法で認証済みセッションを確立することなどが挙げられます。このシステムで結び付けられるのは、ブラウザーとサーバーではなく、ブラウザーとサーバーから返される表現です。サーバーがリソースをリロケート (別の場所に配置) して、実装テクノロジーを変更しても、ブラウザー・クライアントは次にリソースを要求したときに、引き続き適切に処理を行います。クライアントは、コンテンツがある場所と、そのコンテンツでユーザーが行えることを、サーバーから返された表現から理解するからです。クライアントに、サーバーに関する情報があるからではありません。

ここまで記載した Web に関する内容は広く理解されています。技術者以外のユーザーでも理解しているほどですが、考え方をわずかに変えることで、これと同じ概念をもっと広く情報にも適用することができます。適用する過程で、組織はデータ統合のコストを削減し、再利用の機会を増やすことができます。さらに、もっと大きな金銭面でのメリットを実現する新しい機会を作り出す方法で、データ・ソースへ接続するという柔軟性を得ることも可能です。

相互にリンクされた情報の Web を実現するための RDF

解決可能な ID を任意の情報に割り当てるという考え方に転換すると、相互にリンクされた情報の Web を思い描けるようになります。

解決可能な ID を任意の情報に割り当てるという考え方に転換すると、相互にリンクされた情報の Web を思い描けるようになります。例えば、ある記事の主題が日本という国であり、その記事の著者が Bob だとします。この場合、関連する事実とコンテンツを表現するために、任意のリソースからこの記事に関連する任意の情報を関連付けたいと思うことでしょう。人はある学校に通い、ある組織で働き、世界のある地域で生まれます。そして人には、家族や、ペット、友達などがいて、関心事があります。私たちは喜んで、こうしたことのすべてを「混ぜ合わせて結び付けられる (intertwingle)」(Ted Nelson 氏の言葉) ようにします。そのために必要なのは、柔軟なデータ構造と、これらすべてのことを競合することなく参照する方法です。

URI 標準によってすでに、任意のグローバル・スコープの ID を何にでも割り当てられるようになっています。今度は、この標準を文書やサービスではなく、「概念」に適用する必要があります。前の段落の例では、システムの「エンティティー」である文書、日本という国、Bob のそれぞれに ID が必要です。ここで、これまでと異なる新しいことは、「has subject (主語を持つ)」または「authorship (著者)」という関係の ID も必要となることです。文書の ID は、主語ノードになります。日本という国の ID と Bob の ID は、目的語ノードになります。関係の ID が名前を持つ有向アークとして、これらの主語を値に結びつけます。そして、こうした目的で使用する上で柔軟な構造をしているのがグラフです。データベースのテーブルや XML 文書のツリーとは異なり、グラフを使用すれば、随時、個々の関連情報を構造の残りの部分に影響を与えることなく追加することができます。

ほとんどのグラフ・システムは、グラフ全体を単一のストレージ・システムに保管しようとして失敗します。データが特定のサイズを超えている場合、そのような試みはうまく行かないのが常です。しかし、解決可能な Web の ID (URL) を使用すれば、Web をグラフにすることができます。これで、任意の大きな情報空間に拡大することが可能になります。Web をコンテナーに収容しようと考えているわけではありません。物事を Web に配置しようとしているのです。

あらゆる RDF システムは、座標のようなものがなくても、他の RDF システムから RDF を取り込むことができます。

RDF は、まさにこうした性質を持つ W3C 標準のデータ・モデルです。このエンティティーは URI (可能であれば解決可能な URL) を使用し、エンティティー同士は方向性のある関係によって互いに接続されます。方向性のある関係も同じく、この後説明するような方法で識別されます。エンティティーや関係は、自身を説明するために解決されるグローバル ID を使用して参照することができます。グラフを標準フォーマットにシリアライズすると、完全に移植可能なデータになります。あらゆる RDF システムは、座標のようなものがなくても、他の RDF システムから RDF を取り込むことができます。アプリケーションやユーザーは、データに対して何をすべきかを知らないとしても、少なくともデータを取り込んで、何を取り込んだのかを確認することはできます。

RDF がどのように機能するのかを明らかにするために、重要でないように思える例を用います。例えば、「私の誕生日は 5月 26日です」という 1 つの文を受け付けるようにシステムを変更するよう、皆さんにお願いしたとしても、それは無理な要求でしょう。システムのテーブルが人とその人の誕生日という概念を受け付けるようにセットアップされていなければ、この事実を格納する場所はありません。テーブルとクラス構造を変更するとなると、コストがかかり過ぎます。私の誕生日の情報を取り込むこと自体は重大な懸念ではありませんが、これと同じ問題はもっと重要なシナリオにも存在します。問題の一部は、私たちがエンティティーを、1 つの場所に保管される自己完結したものとして考える傾向があることです。私たちは、概念エンティティーに関する情報を複数のソースから得ようとは考えません。これが、閉ざされた世界のモデルと RDF の開かれた世界のモデルとの間の違いです。開かれた世界のモデルでは、誰もがあらゆることに関する事実を共有できるという事実を受け入れます。エンティティー、トピック、または主語についてすべてを把握することは決してないかもしれないという前提は、すべてを所有して管理しようとする IT 管理者を混乱させるかもしれませんが、この前提が、システムの柔軟性を維持し、あらゆるソースから任意の事実を取り込むことを可能にするのです。

この重要でないように思える例では、「私」、そして誕生日との関係を識別する必要があり、さらには私の誕生日の日付をどのように表現するかを把握する必要があります。私は自分を参照する URL として、https://w3id.org/people/bsletten を選びました。この URL を、登録された ID の安定性を維持できるよう保障しているコミュニティーに登録します (現時点では、GitHub リポジトリーに登録されていますが、このリポジトリーをフォークして変更を加え、プル・リクエストを実行すれば、自分の ID を追加することができます)。

HTTP の「303 See Also」リダイレクトによって、「私」を記述するファイルにリダイレクトするよう、上記 ID を構成しました。現在、この動作は非情報リソースに関する W3C TAG (Technical Architecture Group) 勧告の 1 つとなっています。私は特にシリアライズに長けているというわけではないので、このリソースを要求しても、私の現在の状態の表現を取得することはできません。「私」への参照を、「私」に関する文書 (これは、逆参照して解決できる文書です) と区別するために、303 はクライアントに対し、リクエストは有効であったものの、直接その要求を満たすことはできないというアラートを出します。代わりに、レスポンスに Location というヘッダーを組み込み、このヘッダーで「私」を記述する文書を指します (このプロセスについては、次回の記事でもう一度取り上げます)。

「私」(文の主語) を参照する方法がわかったところで、次は、誰かが生まれた日として定義される誕生日を参照する用語が必要です。私独自の用語を選ばない理由はありません。例えば、http://bosatsu.net/ns/birthday のような URL が有効でしょう。この場所に用語の記述を配置すれば、誰でもプロパティー ID を解決して用語の意味を理解することができます。ただし幸いなことに、私が用語を選ぶ必要はありません。Friend of a Friend (FOAF) というコミュニティーが、Web に分散されているソーシャル・ネットワークおよびコミュニティーに関連する一連の用語についての合意を形成しているためです。この仕様には、誕生日を意味するために広く使われている用語が含まれています。それが、私が持たせたいと思っているとおりの意味を持つ、http://xmlns.com/foaf/0.1/birthday です。HTTP でこの URL にリクエストを送信すると、用語の集まりを記した文書が表示されます。この文書には、規定されているフォーマット (mm-dd) についての情報も含まれています。これで、1 つの事実に主語 (「私」)、述語 (http://xmlns.com/foaf/0.1/birthday)、値 (05-26) が伴うようになりました。この 3 つを組み合わせると、この文を反映する有向グラフは、図 1 のようになります。主語はノードで、述語はアークです。アークの反対側にあるのが値です。

図 1. 有向グラフとして表現された 1 つの事実
有向グラフとして表現された 1 つの事実
有向グラフとして表現された 1 つの事実

私の誕生日をマシンで処理可能な事実として公開するために必要なものはすべて揃いました。次は、この文をファイルに保管するために、N-Triples と呼ばれる単純な RDF シリアライゼーションを使用します。このフォーマットでは、各行に 1 つの事実を格納し、ピリオドで行を終了します。

<https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/birthday> "05-26" .

このファイルは、ファイルシステムに保管することも、Web 上に公開することもできます。その結果、あらゆる RDF システムはこの事実を取り込めるようになります。他のシステムのユーザーが、私が誰であるか知らないとしても、主語の ID を解決すれば詳しい情報を調べることができます。FOAF の誕生日の意味を知らない場合も、同じようにしてその意味を調べることができます。

フルネームも公開したほうが良いかもしれません。その場合、name という用語に対して自分の名前を作成することもできますが、その必要はありません。以下に示すように、FOAF にはすでに、この目的で広く使用されている用語があります。

<https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/name> "Brian Sletten" .

図 2 に、私に関するこの新しい事実が反映されたグラフを示します。

図 2. 有向グラフとして表現されたもう 1 つの事実
有向グラフとして表現されたもう 1 つの事実
有向グラフとして表現されたもう 1 つの事実

話が面白くなってくるのは、ここからです。2 つの事実が同じファイルに保管されているのか、それとも別々の 2 つのファイルに保管されているかに関係なく、プロパティーと値が同じモデルに読み込まれると、その 2 つが主語に対して蓄積されます (図 3 を参照)。それは、どちらの文も、同じ ID を持つ同じ主語を参照しているからです。

図 3. 有向グラフとして表現された 2 つの事実
有向グラフとして表現された 2 つの事実
有向グラフとして表現された 2 つの事実

以下に、N-Triples を使用して同じ主語に関する 2 つの RDF 事実を保管する方法を示します。

<https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/birthday> "05-26" .
<https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/name> "Brian Sletten" .

主語に関する情報を知れば知るほど、ノードから伸びるアークが多くなります。あることについて知り得る情報に、実際の制限はありません。任意の事実を追加しても、グラフの残りの部分に影響することはありません。また、その事実のソースはどこであっても構いません。すべてを接続することができます。

プロパティーを使用することによって、誰でも任意のサブジェクトに関する任意の内容を記述できるというのは、非常に強力な仕組みです。その一方、リソースが表す情報のタイプに基づいて、リソースを編成できるようにする必要もあります。それには、クラス・セット・メンバーシップの観点で考えることができます。リソースが個人を参照しているとしたら、その個人は Person クラスのメンバーであると言えます (慣例として、クラス名の先頭文字には大文字を使用します)。この個人がエンジニアであるとしたら、この個人は Engineer クラスのメンバーにもなります。任意の数の語彙から、いくつのセットのメンバーにすることができるかについて、制限はありません。

スキーマを混在させるのは簡単ですが、今のところは信頼できる FOAF 語彙だけを使用します。FOAF の主な目標の 1 つは個人について表現することなので、この語彙には Person クラスが含まれています。この Person クラスを、この例で使用することができます。ここで必要となるのは、リソースがクラスのインスタンスであることを示す特殊な述語です。この述語は、表現する上で根本的に重要であるため、RDF には、このタイプの関係を表す http://www.w3.org/1999/02/22-rdf-syntax-ns#type という用語があります。このタイプの文には、これまで見てきたプロパティーの関係とは異なるセマンティクスがありますが、表現方法は以下のように同じです。

<https://w3id.org/people/bsletten> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
    <http://xmlns.com/foaf/0.1/Person> .

図 4 のグラフに追加されているアークは、これまでに見てきたアークと同様です。

図 4. 有向グラフでの instance-of 関係
有向グラフでの instance-of 関係

ご想像のとおり、引き続き N-Triples で表現された 3 つすべての文の組み合わせが蓄積されていきます。

<https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/birthday> "05-26" .
<https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/name> "Brian Sletten" .
<https://w3id.org/people/bsletten> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
                 <http://xmlns.com/foaf/0.1/Person> .

図 5 に、グラフとして表現された 3 つの事実を示します。

図 5. 有向グラフとして表現された 3 つの事実
有向グラフとして表現された 3 つの事実
有向グラフとして表現された 3 つの事実

この事例で今のところ目立っている特徴は、データ・モデルによって、この情報の増大という概念がサポートされることです。したがって、いつでも何か新しいことを学ぶことができます。標準のグローバル ID、標準のデータ・モデル、標準のシリアライゼーションを使用する場合、互換性のないデータという概念は適用されなくなり、事実上、まったく苦労することなく追加のデータを統合できるようになります。

RDF フォーマット間での変換

N-Triples は、とりわけ人間が読みやすいフォーマットとは言えません。このフォーマットは、構文解析しやすいように事実をダンプするには十分ですが、あらゆる繰り返しが、特定の主語に関連するコンテンツを理解しにくくします。そこで、Turtle という使いやすいフォーマットを紹介します。Turtle は、Terse RDF Triple Language (簡潔な RDF トリプル言語) の略です (その他にも使用できるフォーマットがいくつかあります。そのうちの 1 つは、煩雑な XML ベースの RDF/XML です)。

フォーマット間の変換は簡単です。その 1 つの手段として、Apache Jena プロジェクトから入手できる rdfcat というツールがあります。以下に、rdfcat を使用してトリプルを Turtle フォーマットに変換する方法を示します。

> rdfcat -out ttl basic.nt
<https://w3id.org/people/bsletten>
  a <http://xmlns.com/foaf/0.1/Person> ;
  <http://xmlns.com/foaf/0.1/birthday> "05-26" ;
  <http://xmlns.com/foaf/0.1/name> "Brian Sletten" .

ご覧のように、Turtle では各主語が一度だけ主語として記述されます (同じ ID が別の関係の目的語の位置に存在する可能性があるからです)。主語に関する事実は、それぞれセミコロンで区切られます。ピリオドは、このファイル内のこの主語に関して知っている事実を終了します。もちろん、他のソースから他の事実を学習することもできます。

「私」に関する追加の事実が含まれる別の Turtle ファイルを Web 上に公開するとします。このファイルでは http://xmlns.com/foaf/0.1/depiction プロパティーを使用して、私の画像が Web 上で公開されていることを示します。このプロパティーは、同様のフォーマットになっていますが、表しているのはただ 1 つの事実です。

> http get http://bosatsu.net/turtle/brian.ttl
HTTP/1.1 200 OK
Accept-Ranges: bytes
Access-Control-Allow-Origin: *
Content-Length: 124
Content-Type: text/turtle
Date: Mon, 10 Mar 2015 04:56:39 GMT
ETag: "1049e7-7c-50fd9f13a4140"
Last-Modified: Tue, 24 Feb 2015 18:46:53 GMT
Server: Apache/2.2.16 (Debian)

<https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/depiction>
               <http://bosatsu.net/images/briansletten.jpg> .

そろそろ見えてきたと思いますが、ローカル・ファイルのデータとリモート・ファイルのデータを共通モデルにマージするのは簡単です。両方の場所で同じ ID を使っていることから、当然、データは統合されます。

> rdfcat -out ttl basic.nt http://bosatsu.net/turtle/brian.ttl
<https://w3id.org/people/bsletten>
        a       <http://xmlns.com/foaf/0.1/Person> ;
        <http://xmlns.com/foaf/0.1/birthday> "05-26" ;
        <http://xmlns.com/foaf/0.1/depiction>
                <http://bosatsu.net/images/briansletten.jpg> ;
        <http://xmlns.com/foaf/0.1/name> "Brian Sletten" .

rdfcat は、標準を扱って複数のソースからデータをマージする方法を認識している、数あるツールとライブラリーの 1 つに過ぎません。これらの標準を使用することによって、データ統合のコストはほとんど無いに等しくなります。例えば、販売スプレッドシートのコンテンツを、販売された製品の評価が格納されているサード・パーシーのデータ・ソースに接続した場合、そのメリットは想像できるはずです。これらのソースを組み合わせることで、評価の低い製品を数多く販売していることがわかり、サポート部門の強化が即座に必要であることが明らかになる可能性も考えられます。

まとめ

RDF は、信じられないほど強力なデータ・モデルです。その可能性については、この連載の以降の記事でさらに詳しく説明しますが、今のところは任意のデータ・ソースを利用する際の単純さと柔軟性を理解していれば十分です。OSLC イニシアチブが各種の製品や参加者からの情報をまとめて統合し、互いにリンク可能にすることを目的としている理由は、理解できたはずです。慎重なプランニングを少し行えば、要件を表すリソースをそれらの要件を満たすコードに結び付けることができます。コードのテストを、そのテストの実行結果に結び付けることもできます。ソース・コードに対する特定の変更を特定のイベント、さらには担当する個人に結び付けることさえ可能です。

URI とグラフ・モデルを使用すると、単純な JSON のキー/値ペア・フォーマットによって、開発者の懸念事項のいくつかが理解しやすくなります。さらに複雑にならないよう保証するのではなく (ここで話題としているのは、1 つ以上のオブジェクトの単純なシリアライゼーションではなく、相互にリンクされたデータのグラフです)、複雑になることが懸念事項にならないようにしてください。JSON-LD のような標準によって、JSON と RDF を簡単に橋渡しして、両方の長所を活かせるようになります。

今後も、興味深く驚異的かつ強力な新事実を楽しみにしてください。この連載では引き続き、リソース指向の考え方が Web や OSLC プロジェクトでのデータ統合にもたらすメリットを探っていきます。


ダウンロード可能なリソース


関連トピック

  • RDF: W3C セマンティック Web の wiki で RDF のページを調べてください。
  • OSLC: OSLC プロジェクトのコミュニティー Web サイトにアクセスしてください。このプロジェクトでは、ソフトウェア・ライフサイクル・ツールを使用してデータの共有を容易かつ実用的に行えるようにする標準を開発しています。現在は OASIS Open Standards Network の一部となっている OSLC は、IBM とそのパートナーによって立ち上げられました。
  • N-Triples: RDF グラフ用のライン・ベースの構文である N-Triples について詳しく学んでください。
  • Turtle: RDF 用の Turtle 構文を調べてください。
  • Apache Jena: rdfcat を使用するには Jena が必要です。

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Web development, Information Management, Open source
ArticleID=1007347
ArticleTitle=大規模なデータ統合: RDF を使用してデータの Web を作成する
publish-date=06112015