Dec 15, 2005

Structured Bloggingについて思うこと

Structured Blogging的な話が盛り上がるのはとてもよいことだ。このエントリーではStructured Bloggingに関して私の思うところを述べる。ちなみに私はStructured Bloggingのコンテキストで述べられているような共通のデータ交換形式にはさほど興味がない。その試みは…多分またしても…思ったよりうまく行かない予感がする、XMLフィードに挿入するようなMicro Annotationを除けば。私が興味を持っているのは、Blogging SystemがStructured Dataを扱うことができるようになることでプラットフォームとしての機能を増すこと、である。

Structured Bloggingとは- at Syndicate - Speed Feed [ITmedia オルタナティブ・ブログ]

一年くらい前にSAKKに行ったときに平田さんとももっと構造のあるデータを扱いやすいようになれば(あるいはそのプラットフォームにMovable Typeがなれば)、ビジネス面でのBlogの利用価値がもっと向上するのではないか、とそういう話をしていたのを思い出した。いずれ向かう道としては非常に正しいと思う。

最近のMovable TypeのバージョンやWordPressではStructured Bloggingにあるプラグインが使えるし、宮川さんが紹介(RightFields - Turn your MT into Google Base!: blog.bulknews.net)しているようにRightFieldsというプラグインもある。CustomFieldsもあるけどね。また、Google Baseだってそのインプリメンテーションのひとつだという言い方ができる。

これらはいずれも、単にタグや位置情報やお天気情報をBlogの記事に付与するというだけのToyな「構造」だけでなく、本質的に「構造をもったデータ」として格納しておき、それらを加工して、Blogや他の形態での「ビュー」を与えられるということである。

さて、これらの共通の問題はスキーマの拡張性やデータベース機能がほとんど、あるいはまったくないということである。例えば、映画レビューBlogをStructured Dataとして格納したとして、後からスキーマに一個レビュー項目を追加したくなったらどうするのか。映画レビューBlogと俳優データBlogがあったとき、それらを連携したくなったらどうするのか。賃貸アパート・マンションBlogとレストランガイドBlogを連携したくなったらどうするのか。現状いずれにしてもその手段がない。

かなり構造データ指向であるはずのGoogle Baseだって事情はそんなに変わりがない。データベースを横断的にアクセスしようとしても、タグかラベルのような比較的ルーズな方法しか用意されていないように見える。また、スキーマに変更があれば再度バルクでアップロードし直してくれ、というアプローチのようだ。「タグやラベルで十分じゃん。アップロードし直しでいいじゃん。」という意見ももちろんあろう。しかし、従来のBlogやブックマークの場合にはたまたまタグ以外に構造データがなかったのでそれなりに使えるように見えていただけだとも言える。実際に特定のデータ型を持つ特定のフィールドをキーにexact matchを取れるのと比較すれば(あるいはspatialなデータのハンドリングなどを考えてもよい)、圧倒的に精度も信頼度も低いだろうことは想像に難くない。またFTPによるアップロードインタフェースはGoogleの産物とは思えないほどアナクロだ。

要するに私が言いたいのは、Structured Bloggingに現在本質的に不足しているのは結合演算や副問い合わせを含めたデータベース機能である、ということである。JOINすることができれば、別テーブルにスキーマの拡張分を定義すればよいだけだし(Alterしてもよいし)、複数の異なったStructured Blogを連携するのも実現できる。

もっとも外部からのアクセスメソッドをちゃんと定義してくれさえすれば、クライアントサイドで計算するという方法も選択肢としてはあり得るという意見もあろう。しかし、効率の点では圧倒的にサーバーサイドで計算する方が望ましい。また、Google Baseのようなリモートデータベースの場合には一般にクライアントサイドでの処理時間や消費メモリ量が予測できないので、できればやりたくないし、やるべきではない。

さらに言えば。「これからは『2.0』(括弧付き)の時代だぎゃ」「複数のサービスをMash-upするみゃ」とか言っている人たちともこの話は関わりがないこともない。まずサービスとは、入力メッセージに対して出力メッセージを返すプログラムであり、これは入力と出力のメッセージのペアの集合だと見なすことができる。このこと自体は別に新しい考え方でも何でもなく、プログラムの「関数」の数学的な意味を入出力のタプルの集合と考えるのは、Denotational Semanticsの伝統的な手法のひとつに過ぎない。

この抽象の下では、一つのサービスリクエストは一つの入出力データベースへの問い合わせを意味する。独立な二つのサービスを並行に利用する場合には実質的にJOIN演算を行っているのに等しいし、また連携させる場合にも実質的にやりたいことは、他データベースへの副問い合わせや複数の表の結合に帰着するだろう、と。

要は、Structured Bloggingと「2.0」(しつこく括弧付き)でやりたい、やろうとしていることは案外近い。そして両者がよりハッピーになる方法は単にアクセッサを公開することだけでなく、データ統合できるほどの粒度までインタフェースを公開して提供してしまうことなのだ、と思えるのだが…さて。

そこでグリッドの登場ですよ…(嘘つき!!)。

About Me

My Photo

つくばで働く研究者

Total Pageviews

Amazon

Copyright 2012 Ogawa::Buzz | Powered by Blogger
Design by Web2feel | Blogger Template by NewBloggerThemes.com