SPARQL UpdateでRESTful SOAシナリオを完成する

作者 Thomas Bandholtz , 翻訳者 編集部 投稿日 2008年5月22日

セクション

設計/アーキテクチャ,

エンタープライズ・アーキテクチャ

トピック

REST ,

SOA ,

Semantic Web

タグ

RDF ,

Update ,

Collaborative Technologies ,

W3C ,

Web 2.0 ,

マッシュアップ

LinkingOpenData(source)コミュニティプロジェクトは、DBpedia(source)、Geonames(source)、MusicBrainz(source)、WordNet(source)、DBLP文献目録(source)、2000年の米国国勢調査(source)など、分散している供給者約50ヵ所からの20億を超える連結ステートメント（RDFトリプル）にアクセスを提供し、全世界的なRESTfulのSOAシナリオを達成した。すべてのデータはResource Description Framework（RDF）(source)フォーマットで公表されている。各データセットの構成は、単純なHTTP GETを使い「Cool URI」(source)でアクセスできる名前付きグラフになっている（私の前回の投稿(source)を参照のこと）。寄稿者向けの詳細なチュートリアルは、How to Publish Linked Data on the Web（Webで連結データを公表する方法）(source)で見つけられる。様々なソース間でデータセットが広く連結しているため、マシンが読める（巨大でないとしても）大規模なWebができあがる。供給者がSPARQL エンドポイントも実装しているなら、D2R Server(サイト・英語)のようなRDBMSベースのツールを使えば、クライアントはデータに対して強力なSPARQL Query Language for RDF(source)を使える。

FirefoxアドオンのTabulator(サイト・英語)のようなRDFブラウザを使えば、人間でもどんなものか見ることができる。 LinkedDataに関する最新の話題(PDF・英語)は、ドメイン特定のLinkedDataマッシュアップやモバイルのgeospatialエントリーポイント、セマンティック検索エンジン、データ融合、凝集ツールおよび掘り下げツールのように、いっそう高度なアプリケーションパターンに集中しており、間もなく必ずや登場してくるであろう。

しかし現在、深刻な限界がある。この魅力的なネットワークがリード・アクセス・オンリーになっていることだ。今のところ、次回のSPARQL Update(source)言語で対処することになっている。SPARQLクエリはW3C RDF Data Access Working Group（W3CのRDFデータアクセス作業部会）(source)が2004年から開発しており、ついに今年1月、W3C勧告まで到達したが、延期せざるを得なかった問題もあり、その中には集約関数とアップデート言語が入っていた。最近、Andy Seaborne （有名なJena(サイト・英語)開発者）と Geetha Manjunath （両者ともHPに在籍）は、RDFグラフ更新用言語(source)のバージョン5（別名「SPARUL」）を発表したが、バージョン５が発表されたことで、このトピックに話題が集まるかもしれない。この言語は草案で次の機能を提供する。

* RDFグラフに新規トリプルを挿入します。
* RDFグラフからトリプルを削除します。
* 単一アクションとして一群の更新オペレーションを実行します。
* Graph Storeに新規RDF Graphを作成します。
* Graph StoreからRDFグラフを削除します。

従ってこれは、連結データで欠けているPUT、POST、DELETEの実装に似ている。しかし、Graph Storeとは何か。定義では「ひとつのサービスで管理するRDFグラフのリポジトリ」となっており、あらゆるSPARQLステートメントが掲示されるエンドポイントの役割を果たす。各グラフは、それ自体がURIとして表されるべきRDFデータセットであることを思い出そう—では、なぜこの「Cool URI」に直接HTTP POST/PUT/DELETEを送らないのか。

HPの草案ではこの問題を提議していないし、答えてもいないが、SPARQL Update Wiki(source)のQ&Aにヒントが掲載されている。

SPARQLはリードオンリーであるため、Webアーキテクチャの原則多数に違反することなく、URI（と従ってGET）へとマップできます。
REST式のHTTPオペレーションは、名前付きグラフ全体の追加、更新、除去において、いっそう大きな役割を果たすことができるでしょう。
PUTとPOSTは一般に有用ですが、RESTとWebアーキテクチャのどちらも、「大型グラフへの原子的更新」をいっそう促進する可能性のある、他の方法の利用を妨げるものではありません。
Webサービスと同じ過ちを犯さないでください。アプリケーションプロトコルは「バインドされる」ようには作られていません。なぜなら、そうすると値の大半をマスキングしなければならなくなるからです。

リソースのコンセプトはRDFとRESTで異なるかもしれない。この件については2006年以来「バインディング」問題(source)で論じられており、RDFのないRESTが粗悪といっても、最終的結論を何ら示さずにセマンティックWebとWeb 2.0をRESTにブリッジングした(source)今年の2月までは、その粗悪さの程度はSOAPに比べてわずか半分ほどである(source)。なぜこれが重要なのか。

Linking Open DataのRESTful Webはこれまでのところ、確かにRESTful SOAに対して傑出した実ワールド・パターンを提供している—が、それはリードアクセスに限られている。企業が同じ方法で社内向けにデータを容易に公表でき、企業間でも同様のことが可能であると考えてみて欲しい（セキュリティ要件も満たされると仮定する）。Linking Open Dataのアップデートとなると、最大の可能性はSPARQL Updateの利用と考えられる。SPARQL Updateは言語であってアプリケーションプロトコルではなく、たとえば、Graphではなく、Graph Storeにアドレスすることにより、そうしたプロトコルの仮定をベースにしている。従って、「Webサービスと同じ過ちを犯さないようにすること」を尊重すべきなのかもしれない。

原文はこちらです：   http://www.infoq.com/news/2008/05/sparql-update-soa

• 次へ >