大規模なデータ統合

Linked Data

独立した大規模な Web データ・セットを関連付けるために原則を適用する

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: 大規模なデータ統合

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:大規模なデータ統合

このシリーズの続きに乞うご期待。

この連載の最初の 2 回の記事 (「RDF を使用してデータの Web を作成する」、「SPARQL を使用して RDF データに対してクエリーを実行する」) で、RDF (Resource Description Framework) と SPARQL (SPARQL Protocol and RDF Query Language) について学びました。この 2 つの W3C (World Wide Web Consortium) 標準に従うことで、移植可能でクエリーも実行できる、ネットワークに適したデータを作成することができます。さらに RDF のグラフ・モデルに従えば、1 つのトピックに関するさまざまなソースからの情報を簡単に蓄積することができます。また、ローカルでクエリーを実行するために HTTP を介して RDF データをプルする方法、関連性のないデータの転送を避けるためにクエリーを標準準拠のサーバーにプッシュする方法についても学びました。連載「大規模なデータ統合」の今回の記事では、RDF と SPARQL を Web のアーキテクチャーと結び付け、Linked Data データを作成および使用する方法を学びます。

Linked Data の原則

Web 上でデータを公開する方法に一貫性をもたらすために、Tim Berners-Lee 氏は次のように Linked Data の 4 つの原則を定義しました。

  1. モノの名前として URI (Uniform Resource Identifiers) を使用すること。
  2. モノの名前を調べられるように HTTP URI を使用すること。
  3. URI を調べると、標準 (RDF*、SPARQL) を使用して有用な情報が提供されること。
  4. さらに多くのモノを発見できるように、データの中に他の URI へのリンクを組み込むこと。

これらの原則の背後にある動機については、この連載で詳しく説明するまでのことはありませんが、明確にするために、ひと通り簡単に説明しておきます。

第一に、命名体系の目的は、共有されるコンテキストで参照できるようにすることです。これらの参照は、一貫していて曖昧でなく、衝突しないようにする必要があります。URI 標準は、命名体系のスキームを規定します。つまり、命名体系を作成する際のスキームです。URI を解析する方法、表現する方法、そして場合によってはシステムに保管する方法を知っている限り、URI 標準に従っているどのシステムの URI でも受け付けることができます。そのようなシステムには、URI に準拠した新しい名前への名前参照を将来的に受け付けるコードを、今日にでも作成してデプロイして含めることができます。

グローバル命名システムは URI の他にもあります。よく目にする体系は ISBN (International Standard Book Number) です。ISBN は、書籍への参照を標準化する上で長年にわたって不可欠な体系となってきました。この体系が成功した主な理由は、命名システムのサポートによって、書籍の出版市場と流通市場においてコストとエラーが削減されたことにあります。しかし残念ながら、ISBN によって参照されるのは書籍のみです。雑誌、楽譜、AV 製品 (映画、TV 番組、スポーツ・イベント番組) には、いずれも個別の ID 体系があります。書籍の表題は、デューイ十進分類法システムといった階層型の分類体系で指定することができますが、これも他のものには対応しない ID システムです。学術研究者を識別するには、ORCID という ID を使用できる一方、このような ID システムで学術以外に使用できるものはありません。これらのことから、ある書籍 (学術書) が特定の研究者によって既知のトピックについて書かれたものであることを示すには、それぞれに対応する 3 つの ID と、3 つの体系が必要になります。これらすべてのものを標準の命名体系で参照できるようにすることは、明らかに理にかなっています。

Berners-Lee 氏によるガイダンスでは、誰もが同じ URI を使用しなければならないと言っているわけではないことに注意してください。単に URI 標準を使用することによって、基本的な相互運用性を獲得できると言っているのです。人々がものの呼び方について同意すれば好都合ですが、必ずしも同意しなければならないわけではありません。このことは、RDF グラフのノード ID とリンク ID の両方について言えることです。

第二に、URI を認識するシステムであれば、外部データ・セットの中で URI を ID として参照している部分に対応することはできますが、システムのユーザーがその ID を認識しない可能性もあります。見慣れない ID には、それが何を指しているかを調べる手段が必要です。名前付きエンティティーに関する情報を検索する場合、そのエンティティーを取り込むシステムがそのような検索サービスに関する情報を持っているか、あるいはシステム自体に情報を検出する手段がなければなりません。したがって、コンシューマー・アプリケーションが特定の命名体系を使用するためにサポートしなければならない依存関係とカップリングが増えることになります。

2 番目の原則は、データ交換に多大な価値を与えます。システムが URI を取り込むことができて、それらの URI が解決可能な URI (URL) であれば、(URI の参照先についてさらに情報を得るために) URI を他のあらゆる Web リソースと同じように扱って、URI に対して GET リクエストを実行することができます。別のサービスを検出する必要もなければ、HTTP とその統一インターフェースとは別の新しい依存関係も存在しません。名前は ID であると同時に、詳細を調べるために使用できるハンドルでもあります。

3 番目の原則が明らかにしているのは、標準データ・モデルの標準シリアライゼーションを可能にすると、解決側システムは (リソースが解決されたときに返されるようにしたい任意のカスタム・フォーマットのほかには) 何も知らなくても、結果として生成される構造を解析できるということです。システムは ID が何であるかを知らないとしても、2 番目の原則に従っていれば、追加の情報が必要な場合には常に ID を解決することができます。標準シリアライゼーションのフォーマットに加え、SPARQL プロトコルなどの標準クエリー・メカニズムをサポートすることで、クライアントはデータに対してクエリーを実行することができます。

これまで意のままにできたのがエンタープライズ・ソリューションやプログラミング言語関連のソリューションだけであったとしたら、Linked Data は、想像し難いほどの生産性、規模、柔軟性で機能する、根本的に異なるアプローチです。

最初の原則には、標準 ID を使用する必要はないため (必要なのは、標準 ID 体系を使用することだけです)、当然、複数の異なるデータ・セットに含まれる同じ項目に対して複数の名前が付けられる可能性が考えられます。この問題を解決する方法は数多くあります。それらの方法について時間をかけて詳しく説明することはしませんが、一般に、OWL (Web Ontology Language: Web オントロジー言語) による owl:sameAs といった高次のセマンティック関係を使用して、永続的に ID の同等性を表現することができます。その後は、OWL のセマンティクスを理解する推論システムを使用して、同等のリソースのいずれかに対してクエリーを実行すれば、そのすべてのリソースからプロパティーを取得することができます。ここでの要点は、このようなメカニズムは、用語を別の用語に結び付けるための手段になるということです。複数の用語を結び付けることにより、データが拡充され、データ・セット間で情報を見つけやすくなります。

概して、これらの原則はパブリック・データにもプライベート・データにも有効に適用されます。これらすべてのテクノロジーが、公開しても構わない無料のパブリック・データだけを対象としているとは考えないでください。結局のところ、これらのデータはすべて Web リソースであり、ファイアウォールの背後や有料コンテンツの中に配置したり、認証および許可モデルに含めたりする場合もあります。最終的な目標は、各種データ・ソースの情報を広範囲に機能するテクノロジーと結び付ける際に生じる問題の多くを克服することです。この目標を達成できれば、ネットワーク対応の標準をベースとしていない、コストと時間がかかる不安定なテクノロジーに比べ、統合にかかるコストをほぼゼロにすることができます。

これらの構想を大規模に実装している例を参照するには、Linking Open Data コミュニティー・プロジェクトを調べるだけで十分です。

Linking Open Data プロジェクト

2007年に、少人数のグループ (LOD (Linking Open Data) コミュニティー・プロジェクト) が一連のパブリック・データ・セットを結び付ける取り組みを開始しました。図 1 に、最初に結び付けられた 12 のデータ・セットを示します。この中には、DBpedia、GeoNames、US Census の情報が含まれています。

図 1. 2007年の Linking Open Data プロジェクトのクラウド
2007年の Linking Open Data プロジェクトのクラウド
2007年の Linking Open Data プロジェクトのクラウド

この後、DBpedia について詳しく説明しますが、ここでは Wikipedia から「オーバーン (カリフォルニア州)」という表題について抽出した情報を DBpedia から入手できるという事実からスタートします。この情報のほかにも、オーバーン (Auburn) については 2000年の米国国勢調査 (U.S. Census) で収集された情報もあれば、GeoNames プロジェクトから収集される情報もあります。これら 3 つのデータ・セットは、同じ情報 (オーバーン) に対してそれぞれ異なる ID を使用していますが、舞台裏を多少探ってみると、DBpedia では OWL sameAs 関係を利用して異なるデータ・セット内の用語を結び付けていることがわかります。そのため、OWL ベースの推論によってデータに対してクエリーを実行する場合、ID が異なる 3 つの用語のいずれかを使用すれば、すべての結果を取得できるというわけです (その方法と理由についても、この記事では説明しません)。

リスト 1 では、GeoNames プロジェクトでのオーバーン (Auburn) の URI を、英語のコンテキストでの DBpedia リソース Auburn と同等として結び付けます。その上で、Freebase でのオーバーン (Auburn) の ID を DBpedia リソースに結び付けます。最後に、DBpedia での日本語のコンテキストと英語のコンテキストでのオーバーン (Auburn) の ID を結び付けた時点で、4 つの名前すべてがいずれも同等のものとして結び付けられます。この 4 つのいずれかを主語として指定したトリプルは、4 つすべてに当てはまることになります。

リスト 1. OWL を使用した ID の関連付け
# Connecting the DBpedia resource for Auburn, CA to three other
# resources using owl:sameAs

@prefix owl:   <http://www.w3.org/2002/07/owl#> .

<http://sws.geonames.org/5325223/>
  owl:sameAs  <http://dbpedia.org/resource/Auburn,_California> .
<http://rdf.freebase.com/ns/m.0r2rz> 
  owl:sameAs  <http://dbpedia.org/resource/Auburn,_California> .
<http://ja.dbpedia.org/resource/オーバーン_(カリフォルニア州)>
  owl:sameAs  <http://dbpedia.org/resource/Auburn,_California> .

ここで頭に入れておくとよいことは、これらのデータ・セットはさまざまな組織に由来していて、必ずしも LOD プロジェクトのメンバーが生成しているわけではないということです。それでも、これらのデータ・セットは標準に従って表現されているので、広範な種類のクライアントで使用できるよう、データをさまざまな形式にすることができます。データの中には RDF としてネイティブにファイルに保管されるものもあれば、トリプル・ストアに保管されるものもあります。また、リレーショナル・データベースに保管されて、必要に応じて RDF として提示されるデータもあります。Linked Data テクノロジーを使用しても、通常は情報のソースに負担を与えることはありません。これらのテクノロジーは、情報を解放して関連するコンテンツと容易に結び付けるための単なるパイプ役を果たすだけです。データ・セット間のリンクは、コンテンツの残りと同じように扱うことも、リンク・セットに分離しておくこともできます。

前回の記事で、SPARQL を使用すると、FROM キーワードで参照するだけで複数のデータ・ソースから情報をまとめてプルすることができたことを思い出してください。それを踏まえると、ソース・データはそのままの状態でも、リスト 1 のように ID のリンクをファイルに保管し、そのリンク・セットを SPARQL クエリーで参照できるはずです (リスト 2 を参照)。このクエリーでは、データの各ソースに含まれる用語間の関連付けをグラフに含め、推論ベースの統合に使用できるようにします。

リスト 2. データ・セットとリンク・セットを使用した SPARQL クエリー
SELECT variable-list
FROM dataset1
FROM dataset2
FROM linkset
WHERE {
   graph pattern
}

LOD プロジェクトの最初の 12 のデータ・セットは、このようにして関連付けられました。これを基に、次々とデータ・セットが追加されていきました。LOD プロジェクトが追加したデータ・セットの新しいクラスは、学術研究の引用、生命科学、政府機関が生成したデータ、俳優、監督、映画、レストランに関する情報などに関連しています。2014年までに 570 のデータ・セットが相互に関連付けられ、数十億もの RDF トリプルが表現されるようになっています。図 2 に、2014年の時点での LOD クラウドの要約図を示します。SVG 対応のブラウザーでは、さらに楽しくインタラクティブ・バージョンでこのクラウドを探ることができます。個々のデータ・セットをクリックすると、ほとんどの場合、そのデータ・セットに対応する Datahub ページが表示されます。

LOD の図は、CC-BY-SA ライセンスの下でリリースされていて、過去のさまざまな段階のクラウドを見ることができます。ここに示されている Linking Open Data クラウドの図は、2014年のもので、Max Schmachtenberg 氏、Christian Bizer 氏、Anja Jentzsch 氏、Richard Cyganiak 氏によって作成されました。

図 2. 2014年の LOD プロジェクトのクラウド
2014年の Linking Open Data プロジェクトのクラウド
2014年の Linking Open Data プロジェクトのクラウド

これらのデータ・セットの多くは、当然のことながら、相互にリンクされたデータを記述するための RDF 語彙、つまり VoID (Vocabulary of Interlinked Datasets) を使用して記述されています。データ・セットを作成したのは誰か、最後に更新されたのはいつか、どれくらいの大きさなのか、データを他のデータに関連付けているリンク・セットはどこにあるのかといった質問に、VoID 記述が答えを出してくれます。

データ・ソースの一例として、DBpedia について詳しく探ってみましょう。DBpedia は、Wikipedia から構造化メタデータを生成することを目指した、最初の試みのうちの 1 つです。リスト 3 に、DBpedia の VoID 記述に含まれるメタデータの例を記載します。

リスト 3. DBpedia の VoID 記述例
@prefix void: <http://rdfs.org/ns/void#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix wv: <http://vocab.org/waiver/terms/norms> .        
@prefix sd: <http://www.w3.org/ns/sparql-service-description#> .
@prefix : <#> .

:DBpedia a void:Dataset;
    dcterms:title "DBPedia";
    dcterms:description "RDF data extracted from Wikipedia";
    dcterms:contributor :FU_Berlin;
    dcterms:contributor :University_Leipzig;
    dcterms:contributor :OpenLink_Software;
    dcterms:contributor :DBpedia_community;
    dcterms:source <http://dbpedia.org/resource/Wikipedia>;

    dcterms:modified "2008-11-17"^^xsd:date;
    .
    
:DBpedia_Geonames a void:Linkset
    ...
    .
    
:FU_Berlin a foaf:Organization;
    rdfs:label "Freie Universität Berlin";
    foaf:homepage <http://www.fu-berlin.de/>;
.
.
.

この記述から、DBpedia は Wikipedia から抽出された情報であることがわかります。Wikipedia のほとんどのコンテンツは構造化されていませんが、このサイトには膨大な量の編集上制御された構造が含まれます。特に記事の Infobox は一貫しており、そこに含まれる情報は適切に構造化された形で出力することができます。その結果、1260 万を超える数のトピックが、119 ヶ国語にローカライズされたコンテキストによる 250 億の RDF トリプルを使用して一意に記述されています。これらのトピックには、以下のものが含まれます。

  • 830,000 の人
  • 640,000 の場所
  • 370,000 の創作作業
  • 210,000 の組織
  • 226,000 種の生物
  • 5,600 の疾病

これらのトピックのそれぞれが、固有の解決可能な ID を持つ単独のリソースです。Wikipedia サイトに記述されているトピックの大きさと多様性を考えるときには、このマルチドメイン・データ・セットがボランティアによって保守および精選されていることを忘れないでください。このサイトには 2500 万の画像へのリンク、2800 万の文書へのリンク、4500 万の他の RDF データ・セットへのリンクがあります。リソースの 4 分の 3 近くは、複数のオントロジーによるカテゴリー別に編成されています。

そして、リソースの 1 つひとつに、論理 ID、HTML でレンダリングされるページ、そして RDF/XML シリアライゼーションへの直接のリンクがあります。

http://dbpedia.org/resource/Auburn,_California     # logical identifier
http://dbpedia.org/page/Auburn,_California         # HTML-rendered page
http://dbpedia.org/data/Auburn,_California.rdf     # direct RDF link

論理リソースへのリンクを辿ると、HTML でレンダリングされたビューにリダイレクトされます。このようになるのは、そのリンクをクリックすると、ブラウザーがその優先ソースとして HTML によるレスポンスを要求するためです。DBpedia サーバーによって、レンダリングされたフォームにリダイレクトされるので、そのフォームからオーバーンの他のリソースとの関連付けを探ることができます。例えば、オーバーンの新聞オーバーンが属する郡オーバーンで生まれた著名人などといったリソースです。

これらの URI はすべてリソース参照であり、各リソースは、Wikipedia から抽出された RDF を使用して記述されています。クリックして表示されるのは、そのリソースの Web ページではなく、HTML でレンダリングされた RDF データです。例えば、Auburn Journal には独自の Web ページがあります。このことは、この新聞のリソースに含まれる http://dbpedia.org/ontology/wikiPageExternalLink との関係を辿ることによってわかります。

DBpedia リソースの大半は、複数のオントロジーで分類されていると説明しましたが、これは具体的には、リソースはクラスのインスタンスであり、これらのクラスも同じく RDF リソースであることを意味します。オーバーンのリソース・ページを詳しく調べると、このリソースは、以下の複数のクラスからなる rdf:type であることがわかります。

これらのクラスは、それぞれ異なるスキーマによる別個のクラスであることに注意してください。理にかなった何かしらの要素との新しい rdf:type インスタンス関係をアサートすることにより、随時カテゴリーを追加できるようにする方法は、容易に理解できるはずです。ただし、これはセットとメンバーシップの関係です。つまり、そのセットのどのメンバーに対してでも (あるいは、そのクラスのどのインスタンスに対してでも) 要求できることを意味します。例えば、http://dbpedia.org/class/yago/CitiesInPlacerCounty,California カテゴリーをクリックすると、LoomisRocklinRoseville など、Placer 郡の他の都市が表示されます。つまりここには、同じ郡に属するという包含関係に基づいて互いに関連する一連の都市が表示されることになります。

http://dbpedia.org/class/yago/CountySeatsInCalifornia クラスには、さらに大きなセットが含まれます。これは、カリフォルニア州の郡の首都がまとめて分類されたクラスであり、この関係を通じて、カリフォルニア州のある郡の首都から、皆さんが知っている別の郡の首都にナビゲートすることができます。ナビゲートするリンクは、事実上、暗黙的な SPARQL クエリーであり、裏で処理されます。これに相当するクエリーは、以下のとおりです。

SELECT ?s WHERE {
 ?s a <http://dbpedia.org/class/yago/CountySeatsInCalifornia>
}

DBpedia では、前回の記事で紹介した SPARQL プロトコルがサポートされているため、上記のクエリーは直接リンクに変換することができます。拡張フォームは以下のとおりです。

http://dbpedia.org/snorql/?query=SELECT+%3Fs+WHERE+%7B%0D%0A+%3Fs+a+%3Chttp%3A \
%2F%2Fdbpedia.org%2Fclass%2Fyago%2FCountySeatsInCalifornia%3E%0D%0A%7D

これまでに説明したいくつかの要素を新しい 1 つのクエリーに結合すると、以下のようになります。

SELECT ?s ?page WHERE {
 ?s a <http://dbpedia.org/class/yago/CountySeatsInCalifornia> ;
 <http://dbpedia.org/ontology/wikiPageExternalLink> ?page .
}

上記では、その前に示したクエリーにもう 1 つの関係を追加しています。追加後のクエリーの内容は、「カリフォルニア州のすべての郡の首都と、それぞれの首都に関連付けられている外部 Web ページを表示する」というものです。これは、Wikipedia から自動的に抽出されたデータに対して実行可能な強力なクエリーです。このリンクをクリックすると、このクエリーの結果を確認することができます。

ここで、このクエリー内の単純な 1 つの要素を変更してみます。http://dbpedia.org/class/yago/CountySeatsInCaliforni クラスのメンバーとなっているリソースに対してクエリーを実行するのではなく、http://dbpedia.org/class/yago/CapitalsInEurope を使用します。

SELECT ?s ?page WHERE {
 ?s a <http://dbpedia.org/class/yago/CapitalsInEurope> ;
   <http://dbpedia.org/ontology/wikiPageExternalLink> ?page .
}

上記のクエリーの結果は、このリンクをクリックすると確認することができます。クラス名を変更しただけで、ヨーロッパ大陸の国々の首都と関連付けられた外部 Web ページが結果に反映されるようになりました。

リソースがこのように分類されてリンクされていると、検索対象の関係を変更するだけで、まったく別のクエリーを実行することができます。例えば、以下のクエリーで、外部リンクの代わりに緯度と経度の情報を要求します。

SELECT ?s ?lat ?long WHERE {
 ?s a <http://dbpedia.org/class/yago/CapitalsInEurope> ;
   <http://www.w3.org/2003/01/geo/wgs84_pos#lat> ?lat ;
   <http://www.w3.org/2003/01/geo/wgs84_pos#long> ?long .
}
ORDER BY ?s

結果は、このリンクをクリックすると表示されます。

このようなクエリーによって情報を取得して、その情報を Google マップに表示することも、想像に難くないでしょう。その場合の結果を図 3 に示します。ここをクリックすると、この結果を操作することができます。ヨーロッパの国々の首脳が生まれた場所を検索して可視化する場合、どれだけのコードを変更しなければならないと思いますか? (ヒント: ほとんどゼロです)。

図 3. DBpedia によるヨーロッパの首都
DBpedia によるヨーロッパの首都のスクリーンショット
DBpedia によるヨーロッパの首都のスクリーンショット

仕組みはこれで整ったので、任意のドメインに関する他の種類のクエリーを実行する方法も想像に難くはありません。私が気に入っている DBpedia のクエリー (Bob DuCharme 氏によるクエリー) は、「ザ・シンプソンズ」のすべてのエピソードから、あらゆる黒板ギャグを見つけるというものです。そのリンクを辿るときには、すべてのエピソードもリソースであり、エピソードの監督、特別ゲスト、登場人物などへのリンクが含まれることを念頭に置いてください。各エピソードは、特定の年の一連の TV 番組のメンバーとして分類されています。これらのクラスへのメンバーのリンクを辿ることで、だいたい同じ時間に放映された他のTV 番組のエピソードも見つけることができます。

ここから先は制限なく、DBpedia に対してあらゆる種類のクエリーを実行することができます。また、DBpedia は、LOD クラウドを構成する、ほぼ 600 近くのデータ・セットのうちの 1 つでしかないことも忘れないでください。Linked Data は、人が比較的少ない作業をするだけで、素晴らしい結果を出してくれます。

まとめ

たった 1 つの新しいデータ・ソースを統合するのに、組織にどれだけの時間がかかるのか考えてみてください。これまで問題に対して意のままにできたのがエンタープライズ・ソリューションやプログラミング言語関連のソリューションだけであったとしたら、Linked Data は、想像し難いほどの生産性、規模、柔軟性で機能する、根本的に異なるアプローチです。このアプローチでは、一般公開されたデータに対する適用性を制限するものはありません。ファイアウォールの背後でも、同じアイデアを簡単に適用することができます。

Linked Data は魔法ではありませんが、標準データ・モデルの標準シリアライゼーションに解決される標準 ID は、(おそらく直感的ではないにしても) 理解しやすい概念のセットです。しかし、Web で公に SPARQL プロトコルをサポートするのは、エンジニアリングの観点からすると、かなり難しいことです。任意の個人がどのような負荷をサーバーにかけるかを予測するのは、簡単なことではありません。DBpedia を利用可能な状態に維持するために、これまで多大な努力が払われてきました。その過程は、Web サイトで詳しく説明しています。

次回の記事では、これらのアイデアに基づくソフトウェア・プラットフォームを紹介し、このプラットフォームを実現するために選ばれた OSLC (Open Services Lifecycle Collaboration) テクノロジーに話題を移します。


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


関連トピック

  • Linked Data: LOD プロジェクトの約 600 のデータ・セットについて、それらのデータがどこからのもので、どのようにして生成され、どのように関連付けられているかを読んで理解してください。
  • Linked Data Fragments: クライアントがリモートで情報に対してクエリーを実行するための、負荷の軽い方法について読んで理解してください。
  • DBpedia: Wikipedia から抽出されたデータ・セットを調べてください。
  • Wikidata: Wikipedia には、DBpedia の成功に端を発する、Wikipedia 固有のデータ・ソースがあり、現在は Wikipedia が所有する SPARQL エンドポイントを提供しています。
  • Linked Data: Webをグローバルなデータ空間にする仕組み』(Tom Heath、Christian Bizer 共著、近代科学社、2011年): Linked Data の原則と Linked Data Project に関する最初の包括的な書籍に目を通してください。
  • Linked Data』(David Wood 他共著、Manning Publications、2014年): Linked Data の概念に関するシステムを構築するためのもう 1 つの書籍を調べてください。

コメント

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Web development, XML
ArticleID=1014061
ArticleTitle=大規模なデータ統合: Linked Data
publish-date=09032015