ちょっとしたメモ

RDBMSとRDFをマップすれば、両者の特徴を生かした「セマンティック・ウェブ的な応用」への道が開ける。しかし、RDFの背後にあるデータベースには、外部から直接SQLで問い合わせを行うことができない。ここをカバーするのがRDFのクエリ言語であるSPARQLだ。これは、"Web 2.0アプリケーション"にとってもキーになる可能性がある。少し古い記事だが、Kendall ClarkによるSPARQL: Web 2.0 Meet the Semantic Web を取り上げてみよう。

これは、SPARQLプロトコルの3回目の草案が出たことを受けて、2005年9月16日に書かれたO'Reilly Developer Weblogsの記事。10月の「Web 2.0 Conference 2005」を前に、"Web 2.0"への関心が一般にも高まっていたタイミングで、かなり注目されたものだ。冒頭で、セマンティック・ウェブと"Web 2.0"は重なり合う部分が非常に多いことを指摘した上で、SPARQLの話になる。

で、SPARQLだ。RDFはセマンティック・ウェブ（以下SW）の基本で、データモデルと形式的意味論と（XMLの）具象構文を備えている。これまでのところ欠けているのは、標準的なクエリ言語だ。SQLのない関係代数とRDBMSを考えてみよう。想像もつかないだろ。だから、SWも一種のSQLが必要だ。そこでData Access WGが設立され、20ヶ月ほどかけてSPARQL、すなわちRDFのクエリ言語とプロトコルが登場したというわけだ。

"Web 2.0"の方はどうだろう。REST/HTTPは広く使われているが、標準データ操作言語は、やはり存在しない。

大部分のWeb 2.0アプリケーションやサービスは、RESTのプロトコルかインターフェイスを採用している。言い換えれば、HTTP経由でリソースの表現（representation、多くの場合XMLだけれども、JSON、YAML、RDFなどだっていい）を操作することで、アプリやサービスを利用できる。

こういったアプリ/サービス構築法は、明示的にRPCスタイルをとるインターフェイスよりずっといいと思う。けれども、ちょっと問題もある。RESTは標準的な働き（GET, PUT, POST, DELETE）は提供してくれるが、標準データ操作言語のようなものはない。つまり、Web 2.0アプリケーションやサービスのデータに対して任意のクエリを実行して、リソースの表現を受け取るための標準的な方法は、存在しないということだ。

より端的に言えば、サービスもしくはアプリの提供者が明示的にサポートしなければならないのは、自分たちが一番役立つと考えているデータ操作手段だけだ。

それは、素晴らしいものではあるが、限界もある。

そこで、RDFの便利な機能を利用すればいいじゃないかというわけだ。SPARQLは"Web 2.0"がまさに必要としているものを提供してくれる。

RDFはデータの形式的表現のための手段として有用であり、さらに今度は同じように有用なクエリ言語が用意されたのだから、いっそう多くのWeb 2.0サイトが、いっそう多くの知恵と機能性を、RDFが属するところ、すなわちデータに与えることができるはずだ。RESTはパブリックなインターフェイスを概念化する（そしてHTTPが標準化する）；だがどちらも、その時々に、中央のコントロールなしに、他のところにあるデータの任意の断片とどうやってやり取りするかについては、標準手段を提供しない。

しかし、SPARQLがまさにそれを与えてくれる。相手側のデータが実際にはRDFでない場合でもだ。なぜなら、必要なのはSPARQLのクエリをサポートして、それをSQLなり関係代数なり、あるいはAtomStoreでもなんでも適当なものにマップすることだけだからだ。

というわけで、SPARQLはSWとWeb 2.0に、共通のデータ処理言語を、RDFデータモデルに対する表現力豊富なクエリの形で提供してくれる。Web 2.0には、まさにこうしたものが必要だ。（まったく協調していないWeb 2.0のサービスやアプリすべてに、同じSQLをサポートさせるという悪夢を考えてみたらいい。そりゃ全く不可能だ。あり得ないだろう。これらすべてが、SPARQLを実際のデータ保存方法にマップするというのも難しいかもしれない。あり得ないかもしれない。しかし可能性はあるし、すべてが同じRDBMSスキーマを使うということよりはずっと早いだろう。）

SPARQLは、クエリ言語だけでなくアクセスのためのプロトコルも定義している。

他に必要なものは？　アプリ/サービスとそのデータを利用したい他のコンピュータエージェントとの間で、これらのクエリとその結果をやり取りする方法だ。すなわち、SWとWeb 2.0はデータアクセスのプロトコルを必要としている。そしてSPARQLは、それも提供してくれるんだ。WSDL 2.0を使って、SPARQL Protocol for RDFは 一つの query オペレーションで、とてもシンプルなウェブサービスを記述する。HTTPでもSOAPでも利用できるから、これでSPARQLのクエリを他のサイトに送り、結果を取得することができる。そのHTTPバインディングはRESTフレンドリで（まあ、十分ではないかもしれない、というか、REST伝道者のMark Bakerはそう言うんだが）、簡単なSPARQLプロトコルのクライアントは、Pythonのコードなら10行か15行で書けてしまう。

ここで、Web 2.0 + SPARQLのシナリオを少し考えてみよう。“セマンティック・ウェブとWeb 2.0が出会う”というのはこんなイメージだ。

じゃあ、実際のところ、Web 2.0はSPARQLを使ってどんなことができるか？　考えてみてくれ、一つのクエリ言語と、一つのクライアントで、Flickr、delicious、Google、それに君のお気に入りの他のWeb 2.0サイト3つと、あらゆるFOAFファイルと、あらゆるRSS 1.0フィード（それに、たぶん、すべてのAtom 1.0フィードも）、さらにMusicBrainzとかいろいろのデータを、好きなように切り出せるとしたらどうだい。

おいおい、そりゃたくさんのデータっていうだけじゃない、人々がまさに関心のあるたくさんのデータなんだ。そいつは強力だ。

どれぐらい強力かって？　そう、じゃあこんなのを考えてくれ。Flickrに任意の制約（例えば、サイズ、タイトル、日付とタグ）を満たす写真があるかどうか問い合わせる；もしあれば、deliciousに同じタグと他に君が関心を持っているタグがつけられたURLがあるか問い合わせる；最後に、この別々のクエリ（全く調整されていないデータセットに対して発行されている）の結果をRSS 1.0のフィードに放り込む。そして、そうだな、これがPythonのif文2つと、SPARQLのクエリ3つでできる。

こいつぁクールだ。

もちろん、別のところにあるデータを持ってきて加工するというのは、"Remix"が得意な"Web 2.0"だってやっていることだが、それはアプリ/サービスごとの個別対応、1対1の作り込みにならざるを得ない。一つのクエリ言語とクライアントでこれを実現するというところが重要なのだ。とはいえ、いま直ちにこれらが可能というわけではなくて、"Web 2.0"でSPARQLを利用するためには、準備が必要。

何をする必要があるのか？　そう、Web 2.0のファンや開発者、それに伝道者たちは、SWのファンや開発者、伝道者たちともっと仲良くする（more love from）必要がある。それから、Web 2.0アプリ/サービスは、そのデータ周りのRDFインターフェイスをエクスポートする（あるいは外部が容易にラッパを作れるようにする）必要がある。それから、最近Leigh Doddsが言っていたように、JavascriptによるいいSPARQLクライアントと、クエリを構築したりやり取りするAJAXフレンドリな約束が欲しい。 AJAX上でSPARQLなんて、それだけでも頭痛がするほどクールだぜ！　最後に、SPARQLの実装が普及して成熟しなければならないが、これに関してはすでにとてもいいスタートをきっている。SPARQLのツールは、JavaやPythonや、その他の日々使われる言語で提供されている。

SPARQLのクエリ言語とプロトコルの仕様は、たぶん今年のうちにW3C勧告になるだろう。うまく利用できれば、"Web 2.0"の掲げる"Web as Platform"が、もっとスマートに実現するかも知れない。