XMLの屍を超えていく――セマンティックウェブの挑戦
データ構造の記述を統一する段階を超え、情報(それ自身)へのアクセスを統一する為の土台が整いつつある。
すでに多くの人が気がついているように、実のところXMLには大した再利用性が無い。もちろんただのCSVに比べればDOMやXSLTなどの統一されたAPIが用意されている分、データの扱いは楽だ。しかし、たとえば様々なXMLデータを自分の所に持ってきて、適当に混ぜ合わせて新しい物を作るといった用途には、XMLは向かない。言い換えれば、XMLはマッシュアップには不向きである。
CSVからXMLになって何が1番変わったかと言えば、データ構造へアクセスするためのAPI、――つまりDOMやXSLT、SAXなど――が統一されたことにある。それまでみんなで好き勝手にデータ構造を定義していた時代に比べれば、1回XSLTやDOMを覚えるだけでJavaでもPHPでもAdaでも同じ方法でデータ構造にアクセスできるようになったのは大きな進歩だ。だからこそ、一時のXMLブームにおいてはウェブサイトの文章から始まりRPCや数行の設定ファイル、さらには画像まで、とりあえず何かデータを記述するときはなんでもXMLで書くのがとても流行った。
ただ、ブームが一段落して冷静になると、大抵の人はあることに気がついた――XMLはちょっと複雑すぎる。
XMLはその柔軟性を得るために、大きな大きな仕様になっている。XHTMLのような文章のマークアップには、XMLがとても有効であるのは確かだが、一方ちょっとした用途、たとえば設定ファイルにはお世辞にも向いているとは言えない。ちょっと設定をいじるだけなのに、閉じタグを含めた文字をタイプするのは面倒だし、そもそも設定ファイルなどはそれを使用するアプリケーションが読み込むことが出来れば良いのだから、XMLほどのAPIの統一性は必要ない。
こういうニッチな市場を埋めるために生まれたのがYAMLとかJSON(これはちょっと違う経緯があるが)とかいった、もっと簡単に書けるフォーマットだ。XMLほどは柔軟じゃないけど、CSVよりは気が利いた記述が出来る。設定ファイルなどのちょこっとした用途ならこれで十分だ。
さて、これらのフォーマット――CSVもYAMLもXMLも――は実のところデータの再利用性という意味では目くそ鼻くそである。特に外部システムとの連携という点においては全く差がないといってもいい。ブーム中、「XMLを使用することでデータの再利用性が上がります」と言われ続けたせいで、知らない間にXMLがデータを再利用しやすいフォーマットだと思いこまされてしまったが、それはたぶん嘘である。次の2つのセリフを考えよう。
- 「CVSファイルの2カラム目が作者名です」
- 「XMLファイルのAuthor要素の内容が作者名です」
このセリフに違いがあるだろうか? わざわざ聞くと言うことは「無い」という答えを期待しているのだが――考えてみよう、このセリフはどういう文脈で語られるのだろうか? 恐らく、外部のサービスと連携するときに、その外部サービスの提供者が我々に説明を行ってくれているのだろう。ふむ、妥当に思える。では、もう1つの違うサービスの説明も聞いてみよう。
- 「弊社のサービスの場合、XMLファイルのcreator要素の内容が作者名です」
同じ情報を格納してあるにもかかわらず、さっきのサービスと要素名が違う。両方のサービスを使うならば、それぞれのサービスごとにデータのパース方法を変える必要があるのは明らかだ。
もう分かっただろう、XMLはデータの再利用性を向上させない。利用するサービスごとに説明を聞いてどこに何があるかを勉強し、その上で自分のサービスを構築する必要がある。サービスが増えれば増えるだけ、データの解析手順も増えるわけだ。統一されたAPI、たとえばDOMで簡単にアクセスできるので増えても苦にならない? そんな馬鹿な。
データの再利用性を向上させる為に必要な――そしてこれからこれから先最も重要に成るであろう――「何がどこに書かれているか」という点に関して、XMLはCSVから何も進化していないのだ。有る意味では、直線的すぎて表現できないデータがあったCSVをちょこっと改良しただけのフォーマットがXMLだと言ってもいい。
さて、事前に人間の言葉で説明されないかぎり、どこに何のデータが格納されているかが分からない、というのはこれからの時代全く持って役立たずだ。呼吸をするようにマッシュアップを行うためには、データ構造ではなく、情報それ自身へのアクセス方法が統一されている必要がある。そこで登場するのがSemanticWebのテクノロジー、つまりRDFとSPARQL(RDF用のクエリ言語)、そしてその上に構築されるさらに上のレイヤーとなる。
RDFは情報を全て(全てだ!)「主語・述語目・的語」で構成されたトリプルと呼ばれる単位で記述し、それぞれのリソースを一意なURIで表現することにより「何がどこに書かれているか」を統一する。そしてSPARQLはそうやって定義された情報を統一された方法で問い合わせる為の手段である。
早い話、「著者名を記述するにしてもサービスごとに名前が違うとかめんどいから、統一された名前にしよう。じゃぁそれはURIにしようそうしよう」という感じだ。そして、それを取得する方法を決めたのがSPARQLとなる(実際にはクエリ構文とHTTP経由でのRPCなどが定義されている)。
長くなってきたので詳しい説明は省略するが、XMLによる情報の入手が、サービスが増える度に拡張を必要とするN対Nの関係なのに対して、RDFとSPARQLによる情報の入手は1対Nの関係に収束する。たとえば映画『時をかける少女』観たければ、
- 映画館のリスト(そもそも映画館はどこにあるのか)
- そのうちの最寄りの館の上映時刻表
- 電車の時刻表(移動に必要)
- 映画館の位置情報(駅から何分かも分からないと)
- 天気情報(雨の日は嫌だ)
- 自分の予定表(すでに予定が入ってる日は無理)
- 友達の予定表(一緒に見に行きたい)
- 毎週見ているTV番組の放送時刻(絶対に家にいたい)
といった情報を元に最適な鑑賞日時を得るような問い合わせが、(うまくいけば)たった1つのSPARQLクエリで可能になる。従来ならば、「えーっと映画館のリストはこのスキーマで、上映時刻は…あ、ただのXHTMLだ。予定表のXMLファイルは、なんだこれ……。まぁとにかくDOMを書いて、ここはXSLTで……」みたいなことをしていたのに比べて、素晴らしい進歩である。
RDFはXMLより上のレイヤーなので、逆に言えばシリアライズ方法はたくさんある。XMLによりRDFを記述することも出来るし(RDF/XMLと呼ばれる)、もっと単純なテキストで書くことも出来る。
さて、長くなってしまったので今回はここで終了だ。なんとなくSemanticWebに興味が出てきただろうか。次回はmaicroformatsとRDFa(W3Cの放つ渾身のジョークのことだ)、GRDDLについて解説したいと思う。どれもXHTMLとSematicWebを結びつけるための重要なテクノロジーだ。