目次


大規模なデータ統合

OSLC と Linked Data Platform

セマンティック Web テクノロジーがツールの統合を容易にする仕組みを理解する

Comments

コンテンツシリーズ

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

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

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

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

この連載では、さまざまなソースからのデータの統合を容易にする一連の標準テクノロジーを段階的に紹介してきました。第 1 回の記事「大規模なデータ統合: RDF を使用してデータの Web を作成する」では、情報の共有を容易にする、リソース指向のデータ・モデルについて説明しました。エンティティーと、エンティティー間の関係を表すために、標準 ID とグラフを使用することで、どのソースから来た情報であっても、その情報を流して保管することができます。続く第 2 回の記事「大規模なデータ統合: SPARQL を使用して RDF データに対してクエリーを実行する」では、共有情報に対してクエリーを実行するための標準クエリー・メカニズムについて説明しました。第 3 回の記事「大規模なデータ統合: Linked Data」では、それまでの記事で紹介したテクノロジーを使用して、おそらく数百にも及ぶソースの大規模な統合を可能にする方法を具体的な例で紹介しました。このように、これまでは RDF、SPARQL、および Linked Data によって実現できることを見てきたので、今回と次回の記事では、これらのテクノロジーをソフトウェア・ライフサイクル管理の分野に適用する例を紹介します。しかしその前にちょっと回り道をして、私がこれらのテクノロジーに関する記事を書くことに興味を持つきっかけとなった経験をいくつか紹介しておきます。

ツールとソフトウェア・ライフサイクル

私はソフトウェア開発者として、自分が行う日々の作業に役立つ優れたツールの価値を、常日頃から認識しています。そうしたツールとしては、変更管理 (CM) システム、ビルド・ツール、テスティング・ツール、そして最近では、継続的インテグレーションや継続的デリバリーのツールなどが挙げられます。しかし、ソフトウェア開発者の駆け出しだった頃は、ソフトウェア作成のビジネス的な側面のために設計されたツールには否定的な考えを持っていました。要件管理、テスト計画管理、プロジェクト管理などのツールは、真の価値をもたらすことのない高価なおもちゃであるように思えたのです。これらのツールは、常に高い目標を追いかけているだけで、決してプロジェクトの現状に最も近い状態を反映しているわけではなく、現実とかけ離れているように思えました (そのときも開発者は「現実」に取り組んでいたからです)。また、あるツールに取り込んだ情報を別のツールに取り込まれた情報と結び付ける手段もありませんでした。

そんな私の考えは、私の上司であった Number Six Software 社の Brian Lyons 氏が、Rational ソフトウェアのツール・スイートをすべて結合して見せてくれたことで、吹き飛ばされました。彼は Rational Rose をハブとして、Requisite Pro、Rose、ClearCase など、当時存在していた Rational のあらゆるテスティング・ツールを結合したのです。このツール・スイートに熟達している彼が実現した内容を理解すると、それは驚くべきものでした。彼は、要件をユース・ケースに結び付け、理解した内容をコード、テスト、テスト結果、そしてこれらの過程で生じるすべてのコード変更へと結び付けました。例えば、Lyons はテストのカバレッジとステータスを示すために、Rose の要素を色分けしました。この統合されたツール・スイートを使用すれば、ビジネス要件、要件の作成者、コード、そしてコードを作成した開発者を互いに結び付けることができます。

ソフトウェアに障害が発生した場合、障害が発生した箇所、そのコードを作成した開発者、そのコードに関連付けられている要件がわかります。このことから、ソフトウェアの障害は組織の問題であり、必ずしも一個人の落ち度ではないことが明らかになってきました。要件定義が十分でなければ、開発者が必要だと考えるものを設計して構築するときに混乱が生じます。障害の原因としては、要件の品質、コードの品質、あるいはその両方が考えられます。問題の原因を特定できることは、極めて価値のあることでした。こうしたことはすべて、ソフトウェア開発の歴史においてアジャイル開発が登場する以前の話しであるため、ビジネスと技術の境界をまたいで測定と統合を行うというのは、画期的で新しい考えでした。

唯一問題だったのは、カスタムのスクリプト言語で相互に関連付けられた、大規模かつ複雑なツール・スイートに関する専門家レベルの知識が必要だったことです。Lyons は自分の会社を共同で設立する以前は、Rational Software 社に所属していて、Rational のあらゆる製品を熟知していましたが、ほとんどの人にはそれだけの知識がありませんでした。私は、ソフトウェア開発の将来を垣間見たような感じがしましたが、現実はまだそこまでは至っていませんでした。

その数年後、私はあるカンファレンスのトラックで (後の IBM Rational の CTO である) Martin Nally 氏とともに司会を務めたときに、彼から IBM Rational が再びツールの統合を可能にしようとしているということを聞きました。今度は REST インターフェースと XML 構造を使用して統合するという試みです。その頃までに、私は Linked Data とセマンティック Web テクノロジーによる統合の強力な支持者になっていたので、カスタムの XML 文書フォーマットを使用するという話には失望しましたが、その一方、感心させられたのは、交換されるコンテンツのフォーマットについて、ツールの作成者同士が合意すれば、少なくとも理論上は、任意のツールで互いにやりとりできるようになるという点です。

この IBM Rational イニシアチブは、OSLC (Open Services for Lifecycle Collaboration) と名付けられました。OSLC について調べてみると、そのベースとなっているオープン・スタンダードが、RDF、HTTP、REST アーキテクチャーの原則、そして Linked Data を使用していることを知って嬉しい驚きを覚えました。OSLC グループはその活動の過程で、数々の組織の参加を募りました。現在、これらの標準ベースのツールによるデータを縦割りで生成および使用している組織の中には、金融機関、一流のテクノロジー企業、防衛企業、オープンソース・プロジェクト、政府機関、開発者が中心の新興企業などがあります。

複雑なコンセンサス主義の仕様イニシアチブのために、ツールの作成者を集めることはありそうにないことでした。軽量で柔軟性と拡張性を備えた標準ベースのアプローチが理に適っていたのです。

グループはどうやら、ALM (Application Lifecycle Management: アプリケーション・ライフサイクル管理) と PLM (Product Lifecycle Management: プロダクト・ライフサイクル管理) のツール・スイートのさまざまな側面について、すべての関係者のコンセンサスを得るのは難しいと判断したようです。ツール・スイート全体を組織に売ることについても然りです。平均的なソフトウェア開発チームは、すでに Git や Subversion などの CM システムに傾倒していて、多数の商用ツール、オープンソース・ツール、あるいはカスタム・ツールを統合していました。こうしたさまざまなツールの作成者をすべて、複雑なコンセンサス主義の仕様イニシアチブのために集めることに時間をかけるのも、ありそうにないことでした。結局は、軽量で柔軟性と拡張性を備えた標準ベースのアプローチが理に適っていたのです。そのアプローチに該当するのが、この連載ですでに紹介したテクノロジーです。これらのテクノロジーは Web 上で機能し、Web としても機能します。今回と次回の記事では、具体的な問題にこれらのテクノロジーを適用します。

OSLC の使命

OSLC コミュニティーは、統合ツールの一連の仕様を繰り返し作成してきました。現在 3.0 のステージにあるこのイニシアチブは、OASIS 標準化グループによって取り上げられて作業が進められています。OSLC が目標としているのは、OSLC がカバーする範囲を必要以上に拡張し、ツール同士がどのようにやりとりするかまで踏み込んで規定することではありません。むしろ、必要最低限の統合を行うという方法をとることを目指しています。この取り組みでベースとしているのは、Linked Data や HTTP などの標準、そして REST アーキテクチャー・スタイルなどのプラクティスです。このイニシアチブでは、個々のワークグループがそれぞれ別個のサブドメイン (要件管理、変更管理、構成管理、テスティングなど) に取り組んでいますが、コアとなる概念とスタイルの一式は、すべてのワークグループで共通のものをベースとすることで、すべてのサブドメインが相互運用可能な状態を保てるようにしています。

プロジェクトの最終目標は、以下の特徴を持つシステムを実現するための機能と語彙を作成することです。

  • シナリオ駆動: ユース・ケースと同じように、シナリオは、ツールによって統合される可能性があるアクティビティーを記述します。シナリオを使用すると、標準のアクティビティーが有意義なタスクに重点を置いたものとなり、構成メンバーの要件を十分にカバーするようになります。
  • 段階的: 標準への取り組みは、すべてを事前に揃えようとするのではなく、段階的にエコシステムに価値を追加していき、このやり方で追加したものをなるべく早めに検証するというのが本来の形です。
  • 疎結合: Web 対応で仕様に準拠したツールでは、クライアントがサーバーの実装の詳細を特別に考慮することがないようにします。こうすることで、ツールの作成者は、クライアントに影響を与えることなく、ツールに自由に変更を加えることができ、クライアントは、より広範なツールに対応できるようになります。
  • 最小主義: 標準は、合意済みのシナリオの要求を満たせば十分であり、それらの要求を上回るものにしようとする必要はありません。

OSLC は、特定のドメインの語彙としての用語とタイプの仕様に取り組む、個別の TC (Technical Committee) を編成しました。それぞれの TC では、その TC 独自の内容に焦点を絞ることができますが (例えば、品質管理ツールなど)、ドメインをまたがる統合で用語を再利用するのが妥当な場合には、用語を再利用することが奨励されます。これにより、複数のツールとシナリオの間で、最小主義ではありながらも十分な (必要最低限の) 統合を行う方法が継続されることになります。

OSLC コミュニティーは、初期の語彙の一部と ALM システムの成果物を表現する手段に取り組んだ後、これらの概念をその先に進めるためには、実際に動作するソフトウェアが必要なことに気付きました。統合用のアーキテクチャーの仕様を細かく指定し過ぎると、実装に与える影響を憂慮して、ツールの作成者は去っていってしまいます。一方で、統合用のアーキテクチャーの仕様に曖昧さがあると、ツールの間にあまりにも大きな違いが出て、情報を簡単かつ継続的に共有できなくなってしまいます。

このことから、OSLC は、特定のドメインの要素 (要件や変更など) に対する問題を個別に解決するだけにとどまるのではなく、さまざまなデータのタイプやその相互関係を管理するための再利用可能なプラットフォームがあれば有用だろうと判断しました。同じ頃、W3C (World Wide Web Consortium) では、リンクされたデータを管理するための読み書き可能なプラットフォームを要望しているというメンバーからのフィードバックを受け取るようになっていました。OSLC は、W3C といった他の団体に参加して、リファレンス実装を提供することで、その主要なコントリビューターになることに決めました。このリファレンス実装を提供するのに伴う議論は、最終的に LDP (Linked Data Platform) 仕様となった内容についての議論の基礎になりました。

OASIS OSLC の名の下には、以下の 4 つの中心となる TC があります。

  • OSLC Lifecycle Integration Core (OSLC Core): さまざまなシナリオでの要素の基本定義を管理します。そこには、LDP によって要素を作成、取得、リンク、更新する方法が含まれています。
  • OSLC Lifecycle Integration for Automation (OSLC Automation): 自動化ワークフローをサポートする REST エンドポイントと相互作用モデルを定義します。
  • OSLC Lifecycle Integration for Change and Configuration Management (OSLC CCM): アプリケーションおよび製品のライフサイクル全体にわたって変更管理、構成管理、アセット管理をするための要素を定義します。
  • OSLC Lifecycle Integration for Project Management of Contracted Delivery (OSLC PROMCODE): プロジェクト管理アクティビティーに関連する要素を定義します。

最終回の記事で実際の OSLC システムの詳細を探る前に、ツールを作成するベースとなるアーキテクチャーについて理解しておくと参考になります。

Linked Data Platform の概要

LDP は、REST の原則、Web、Linked Data に基づいて構築されていますが、互換性のあるコンテナー全体で動作を調整するためのさらなる構造を提供します。

理論上、参照する必要のあるリソースは、HTTP に精通したコンテナーでホストすることができます。疎結合された Web によってもたらされる主要なメリットの 1 つは、クライアントがサーバーの実装について何も把握する必要がないことです。しかし、相互運用可能なツールのコミュニティーを新しく作り出すことを望んでいる OSLC のようなコミュニティーにとっては、Linked Data リソースの管理に関する動作について、もう少し詳しい仕様が必要になります。そこで登場するのが、LDP (Linked Data Platform) です。LDP は、REST の原則、Web、Linked Data に基づいて構築されていますが、互換性のあるコンテナー全体で動作を調整するためのさらなる構造を提供します。ツールのベンダーが一貫してこれらの標準を理解し、サポートすれば、さらに連携しやすいエコシステムになるはずです。リソース指向の動作がサポートされていれば、実際の実装の詳細は相変わらず大部分がクライアントには無関係となります。

Linked Data Platform は主に、LDPR (Linked Data Platform Resource) の状態管理を目的としています。LDPR は、LDPC (Linked Data Platform Container) に格納できる任意のリソースです。これらのコンテナーは、Web サーバーやデータベースと同じではありません。LDP のインスタンス内では、複数のコンテナーをホストすることができます。これらのコンテナーは、リソースを保管する任意の論理コンテナーであると見なせます。リソースの一般的な例には、ユーザーの連絡先リスト、プロジェクトとそのプロジェクトに関連する欠陥、チームとそのメンバーなどが挙げられます。

クライアントは、LDPR を作成、取得、更新、または削除するために、HTTP とこれらの操作を行うための HTTP のメソッドを使用して LDPC とやりとりすることができます。LDP のかなりの部分を占めるのは、リソースのディスカバリーです。リソースのディスカバリーによって、クライアントは、コンテナー内にあるリソースと、リソース同士の関係を学習します。LDP には、この概念を適用したどの場合にも再利用可能な語彙の用語に関連付けられた名前空間 (http://www.w3.org/ns/ldp#) があります。以降の例で ldp: プレフィックスが使用されている場合、それが参照先の名前空間です。

LDP 実装をインストールする

LDP を試せるように、LDP の実装をインストールしてください。いくつかの選択肢がありますが、ここでは LDPjs を選びました。LDPjs は、使いやすい Node ベースのバージョンです (「参考文献」のリンクを参照すると、Java ベースの実装を試すこともできます)。まず、gitNode.jsMongo をインストールします (まだインストールされていない場合)。Mongo を起動してから、以下のコマンドで LDPjs コードを取得します。

> git clone https://github.com/spadgett/LDPjs.git
Cloning into 'LDPjs'...
remote: Counting objects: 495, done.
remote: Total 495 (delta 0), reused 0 (delta 0), pack-reused 495
Receiving objects: 100% (495/495), 256.19 KiB | 158.00 KiB/s, done.
Resolving deltas: 100% (293/293), done.
Checking connectivity... done.

以下のコマンドで、サーバーを起動します。

> npm install
... npm output
> node server.js
configuration:
{ listenHost: 'localhost',
  listenPort: 3000,
  scheme: 'http',
  host: 'localhost',
  port: 3000,
  context: '/r/',
  appBase: 'http://localhost:3000',
  ldpBase: 'http://localhost:3000/r/',
  mongoURL: 'mongodb://localhost:27017/ldp' }
App started on port 3000
Connected to MongoDB at: mongodb://localhost:27017/ldp

基本コンテナーに関する情報

この時点で、基本コンテナー (config.json ファイルで定義されているコンテナー) が http://localhost:3000/r/ にあることがわかります。HTTP クライアント (この例では、httpie) を使用して基本コンテナーにアクセスすると、LDPC はその基本情報を明らかにします。

> http get http://localhost:3000/r/
HTTP/1.1 200 OK
Accept-Post: text/turtle,application/ld+json,application/json
Allow: GET,HEAD,DELETE,OPTIONS,POST
Connection: keep-alive
Content-Type: text/turtle
Date: Sat, 13 Jun 2015 21:50:52 GMT
ETag: W/"eb95ad12674f4327408681c918a91f51"
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type",
  <http://localhost:3000/constraints.html>;
     rel="http://www.w3.org/ns/ldp#constrainedBy",
  <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"
Transfer-Encoding: chunked
Vary: Accept
X-Powered-By: Express

<http://localhost:3000/r/> a <http://www.w3.org/ns/ldp#Resource>,
   <http://www.w3.org/ns/ldp#RDFSource>,
   <http://www.w3.org/ns/ldp#Container>,
   <http://www.w3.org/ns/ldp#BasicContainer>;
   <http://purl.org/dc/terms/title> "LDP.js root container".

ご覧のように、コンテナー ID は単なる 1 つのリソースに過ぎないので、あらゆる HTTP ベースのリソースとやりとりする場合と同じ方法で、コンテナー ID とやりとりすることができます。以下に、コンテナー情報について注目すべき重要な点を説明します。

  • LDPC に新しいリソースを追加するには、LDP 仕様で定義されているように、POST を使用して、リソースを Turtle (text/turtle)、JSON-LD (application/ld+json)、または JSON (application/json) として追加します。

    Accept-Post: text/turtle,application/ld+json,application/json
    Allow: GET,HEAD,DELETE,OPTIONS,POST

    コンテナー自体に対して POST 以外の HTTP メソッドを実行することもできます。もう 1 つの要件として、クライアントがリソースに対して実行可能な操作を判別できるように、OPTIONS メソッドをサポートする必要があります。

  • LDPC は、デフォルトで、リソースを Turtle 表現で返します。LDP 仕様では、ETag タグの変更をクライアントが検出できるよう、このタグのサポートも要件としています。

    Content-Type: text/turtle
    Date: Sat, 13 Jun 2015 21:50:52 GMT
    ETag: W/"eb95ad12674f4327408681c918a91f51"
  • Turtle がデフォルトの表現となってはいますが、LDPC はコンテンツ・ネゴシエーションもサポートしなければなりません。以下の例では、JSON-LD 表現のリクエストが成功しています。

    > http get http://localhost:3000/r/ Accept=application/ld+json
    HTTP/1.1 200 OK
    Accept-Post: text/turtle,application/ld+json,application/json
    Allow: GET,HEAD,DELETE,OPTIONS,POST
    Connection: keep-alive
    Content-Type: application/ld+json
    ...
    {
    
        "@context": {
            "dcterms": "http://purl.org/dc/terms/",
            "foaf": "http://xmlns.com/foaf/0.1/",
            "ldp": "http://www.w3.org/ns/ldp#"
        },
        "@id": "http://localhost:3000/r/",
        "@type": [
            "ldp:Resource",
            "ldp:RDFSource",
            "ldp:Container",
            "ldp:BasicContainer"
        ],
        "dcterms:title": "LDP.js root container"
    }
  • レスポンスのヘッダーの中に、RFC 5988 準拠のリンクがいくつかあります。2 つのリンクで rel 関係が type に設定されており、コンテナーが LDP Resource と LDP BasicContainer のインスタンスであることを示しています。これは、当然のことです。コンテナーはリソースなので、コンテナーの説明を取得することができ、またコンテナーであることから、要素を追加することができます。コンテナーにはいくつかの異なるタイプがありますが、そのうち BasicContainer は、単純な相互作用と包含関係をサポートします。type は、RDF 自体には重要な関係である一方、リンク・レスポンスによって、他のドメイン固有の関係を表現することもできます。以下の例には、constrainedBy という LDP 固有の関係も示されています。このリンクが指すドキュメントを自由に構成要素へと分解することで、この LDPC と LDP の特定の実装に適用される制約の種類を調べることができます。

    Link: <http://www.w3.org/ns/ldp#Resource>; rel="type",
        <http://localhost:3000/constraints.html>;
           rel="http://www.w3.org/ns/ldp#constrainedBy",
        <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"
  • レスポンス・ヘッダー Vary について簡単に説明しておきます。

    Vary: Accept

    サーバーは、クライアントがコンテンツ・ネゴシエーションを使用して、同じリソースを別のフォーマットで要求することを許可することから、キャッシングの問題を回避するには、この事実を中間プロセスにアドバータイズすることが非常に重要です。そのため、サーバーは上記のように Accept ヘッダーに基づいて、そのレスポンスを変えるということをアナウンスします。これは忘れがちなステップですが、これを見過ごすと、苛立つほどのデバッグ・セッションに陥る可能性があります。

  • 最後に注意する点として、コンテナー・リソース自体の表現は、Turtle と JSON-LD の両方で表示することができます。

    <http://localhost:3000/r/> a
      <http://www.w3.org/ns/ldp#Resource>,
      <http://www.w3.org/ns/ldp#RDFSource>,
      <http://www.w3.org/ns/ldp#Container>,
      <http://www.w3.org/ns/ldp#BasicContainer>;
      <http://purl.org/dc/terms/title> "LDP.js root container" .

    上記では、レスポンス・ヘッダーでアドバータイズされた内容の一部が繰り返されています。無駄に思えるかもしれませんが、RFC 5988 ヘッダーが持つ価値の一部は、返された情報を構文解析する方法を知らない可能性のあるクライアントに、有用な情報を提供することにあります。上記では、コンテナーのタイトルが示されていることに加え、コンテナーを他のいくつかのタイプとして認識できることがわかります。どのように表現するかは、その実装次第であり、またその実装がどのようにセットアップされたかによります。ほとんどの LDPC では LDP の用語を使用しますが、これらの用語を使用しなければならないというわけではありません。

LDPjs の HTML インターフェース

空のコンテナーには、それほど面白味はありません。POST を使用して新しいリソースをコンテナーに追加できると説明しましたが、お楽しみとして、LDPjs サーバーでもサポートされている HTML インターフェースを調べてみましょう。サーバーが起動されると、図 1 に示されているように、サーバーの場所が http://localhost:3000 であることがアドバータイズされます。ユーザー・インターフェースには、コンテナーの中身が簡潔に視覚化されて表示されますが、現在は空の状態です。これが、/r/ というラベルが付いた小さいフォルダーが表現する内容です。

図 1. LDPjs 実装の HTML インターフェース
LDPjs 実装の HTML インターフェースのスクリーンショット
LDPjs 実装の HTML インターフェースのスクリーンショット

コンテナー URL のすぐ上にある POST リンクを選択すると、UI が切り替わり、Turtle で表現されたサンプル・バグ・レポートが表示されます (図 2 を参照)。まず、記述されている対象が識別されていないことに注目してください。クライアントはこの対象を何と呼べばよいか認識していないため、Turtle で名前が付けられていないノードになっています。この対象がコンテナーに追加されると、サーバーは ID を割り当てて、その名前がクライアントにわかるようにします。

図 2. コンテナーに新規リソースを追加する
コンテナーに新規リソースを追加する画面のスクリーンショット
コンテナーに新規リソースを追加する画面のスクリーンショット

次に、Turtle が任意の名前空間と語彙を使用して、作成対象のリソースを記述していることに注目してください。これは、LDP の価値提案の 1 つです。いずれかの語彙を使用する任意のタイプの任意のリソースを、LDPC に保管して管理できるようになっています。POST をクリックすると、この Turtle がサーバーに送信されて、コンテナーに保管されます。遠慮なく、偽のバグに関するメタデータをさらに追加して、この方法がいかに柔軟であるか確かめてください。

バグを追加すると、/r/ フォルダーと新規リソースの間のリンクが表示されます。視覚的な表現だけでなく、この接続は、コンテナーに関するデータでもアドバータイズされます。現時点で、Turtle はリスト 1 に示すような内容になっています。新規リソースへのリンクには、contains 関係が使用されることに注意してください。大きなコンテナーの場合、そこに含まれるすべてのリソースを送り返すとなると、膨大な量のリソースに対処しなければならなくなるので、オプションのページネーション拡張機能を LDP に使用することで、クライアントが必要に応じてコレクション全体の中を簡単に動けるようにしています。

リスト 1. 新規リソースを反映した LDPC
<http://localhost:3000/r/> a <http://www.w3.org/ns/ldp#Resource>,
   <http://www.w3.org/ns/ldp#RDFSource>,
   <http://www.w3.org/ns/ldp#Container>,
   <http://www.w3.org/ns/ldp#BasicContainer>;
   <http://purl.org/dc/terms/title> "LDP.js root container";
   <http://www.w3.org/ns/ldp#contains>
        <http://localhost:3000/r/res1434238382253>.

私の LDP インスタンス内の新規リソースは、http://localhost:3000/r/res1434238382253 として既知になっています (皆さんのリソースには、別の ID が含まれているはずです)。ご想像のとおり、このリソースが検出された後は、リソースを操作する方法を特別に認識する必要はなくなります。他のあらゆるリソースと同じく、リソースを要求するには、GET リクエストを実行します (リスト 2 を参照)。この時点で、リソースに関する情報として、リソースが何であるか (http://www.w3.org/ns/ldp#Resource)、リソースに対してどんな操作を実行できるか、そしてドメインに固有の表現が得られることになります。

リスト 2. 新規リソースを要求する
> http get http://localhost:3000/r/res1434238382253
HTTP/1.1 200 OK
Allow: GET,HEAD,DELETE,OPTIONS,PUT
Connection: keep-alive
Content-Type: text/turtle
Date: Sat, 13 Jun 2015 23:54:23 GMT
ETag: W/"2d1e900102c0c08e6d6a5a558c41b1e8"
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type",
   <http://localhost:3000/constraints.html>;
   rel="http://www.w3.org/ns/ldp#constrainedBy"
Transfer-Encoding: chunked
Vary: Accept
X-Powered-By: Express

<http://localhost:3000/r/res1434238382253> a
   <http://example.org/vocab/bugtracker#Bug>;
  <http://purl.org/dc/terms/title> "Product C crashes when shutting down.";
  <http://example.org/vocab/bugtracker#isInState> "New".

まとめ

LDP については説明することがまだたくさんありますが、LDP のさらなる要件がこのエコシステムに対してどのようなことを行うのかについて、感覚をつかめるだけの十分な内容をここまでで示しました。どのような種類のリソースでも必要なものは、任意の用語を使って自由に作成できるようになっています。FOAFDublin Core などの一般に使用されている語彙を (問題、要件、テストなどの) よりドメインに固有の概念と組み合わせることができます。このチュートリアルで重点を置いたのは、RDF ベースのリソース (LDP-RS) ですが、LDPC では画像、スプレッドシート、ドキュメントなどといった非 RDF ベースのリソース (LDP-NR) も保管することができます。

この機能の組み合わせは、組織、組織の従業員、ソフトウェア要件、成果物、コード、テスト、テスト結果を互いに結び付けられるようにします。これらの要素をすべて、標準に従い、任意のツールとクライアントを使用して、結び付けることができるのです。この連載の最後のチュートリアルでは、これまでに説明した概念を使用または拡張して、OSLC の用語、ワークフロー、アクティビティーの単純なワーキング・サンプルを実際にデモンストレーションします。


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


関連トピック

  • OSLC Resources: OSLC (Open Services for Lifecycle Collaboration) のテクノロジー、メンバー、チュートリアル、プロジェクトについて読んでください。
  • Linked Data Platform: リンクされたデータの集合を読み書きするためのプラットフォームを定義する W3C 仕様を読んでください。
  • Linked Data Platform のチュートリアル: LDP と LDP4J に関する最近の ESWC2015 カンファレンスのチュートリアルを詳しく調べてください。
  • LDPjs: Linked Data Platform の Node.js および Mongo ベースの実装です。
  • LDP4j: Linked Data Platform の Java ベースの実装です。

コメント

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

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