XML時代の終焉 ~ XMLから再びCoddへ

先日、ACM SIGMODの日本支部大会に招いていただいて、「Relational-Style XML Query (ACM Portal http://doi.acm.org/10.1145/1376616.1376650)」について講演をしてきました。Relational-Style XML Queryは、XMLという複雑な構造をもったデータに対して、SQLのようなテーブルデータへの検索に使われる言語で問い合わせする手法です。

この研究の肝は、木構造データといわれるXMLでも、実はそのほとんどがリレーション(Microsoft Excelのようなテーブル形式のデータ）の組み合わせと考えることができ、そのテーブル構造の情報（スキーマ）を使うと、検索が非常に簡単に書けるという点です。

Relational-Style XML Query @ SIGMOD-J 2008 Dec.

View SlideShare presentation or Upload your own. (tags: xml amoeba)

この応用例は広く、僕が日常的に構造を持ったデータを扱うプログラムを書くときに欠かせないツールになっています。例えば、

• XMLデータからObject へのマッピング (O-X Mapping) 。この際に、DTD, XML Schemaなどは必要ありません。Objectのクラス定義が、そのまま自動的にXMLクエリ(スライド中のrelation + FD) に対応するからです。
• RDBのようなテーブルデータも木構造データのサブセットなので、検索のアルゴリズムは同一のまま、直接O-R Mappingにも使っています
• 他にも、コンパイラを自作したときにでてくる構文木を、オブジェクトに手軽にmappingするときにも使います。これも、O-X Mappingの一部。
• JSON, YAML, CSV, Tab-separated dataなども、木構造データとしてXMLと同一に扱えます。これらのフォーマットへの対応はadapterを1つ書くだけで済んでしまいます

これらの技術は、日常的にデータベースの扱いが欠かせないバイオインフォマティクスの分野で活用しています。他にも現在研究中で、ここに紹介できるほどまとまってはいないのですが、それでも十分有用な応用というのも多数あります。今後、それらのC++/Javaなどによる実装は xerial.org （エクセリアルのサイト）を通して、追々公開してきたいと思います。僕自身、このおかげでSAX/DOMなどのプログラミングから解放されています。

XML・DB研究者の間では、XMLについて巷で言われているような「XMLがすべてを解決する」的な、XMLの利用価値についてはとても懐疑的です（ある日のTwitterでのTimelineより)。実際、XMLはXPath, XQuery, XSLT, DTD, XML Schemaなど関連技術の仕様が膨大で、学ぶのに非常に時間がかかるものでした。Relational-Style XML Queryが示す世界は、XMLをテーブル構造の組み合わせと考えることで、複雑そうに見えていたXMLが、実はとても簡単に扱えようになるというもの。

必要なのはちょっとした発想の転換です。XMLというデータありき、ではなく、最終的に扱いたいデータが、オブジェクトの形や、テーブル形式であるなら、それはもう巷で言われるようななんでも屋さんのXMLではなく、1970年代にCoddが提唱したrelational modelと同じ世界です。 そこでのXMLにはportableで便利なテキストフォーマットとしての価値しかありません（データを表現するための共通テキストフォーマットが確立したという意義は非常に大きいですが）。

1997年にXMLが登場して早10年。皆こぞって、Coddが提唱したrelational modelからXMLへの転換を試みてきました。けれど、そのようにもてはやされたXMLも再びCoddに帰って行くのです。

参考：A Web Odyssey:  from Codd to XML. Victor Vianu (PODS 2001)

XML、relational modelのどちらが技術的に優位か、という話ではありません。大事なのは、そのデータを扱うのは「人間」という視点です。その「人間」にとって結局、どちらが扱いやすいデータ構造なのか？ 僕自身は、この境目は非常に微妙なところだと考えています。Excelのように単一のテーブルだけだと心もとない、けれど構造が入り組みすぎても、扱いきれない。そして、このもどかしさと真正面に向き合うのが、データベース研究の世界なのです。

Gmailのショートカットキーが覚えられないときは

「?」キー（Shift+/)を押しましょう。ショートカットキー操作の一覧が出てきます。

この中で僕がよく使うのは、

• g, i と押して inboxに戻る（再読み込みにも使います）(Go to Inbox と覚えます）
  
• g, l (Go to Label) と押して、ラベルを検索
• /  で検索窓にフォーカスを合わせる
• メールを見ながら、「.」を押して、ラベルを付ける　（ラベルを選ぶときに、頭文字のキーを打ち続けると早く選べます）
  

などです。お試しあれ。

[講演案内] Relational-Style XML Query

講演の案内です。

第3回 先端的データベースと Web 技術動向講演会

（ACM SIGMOD日本支部第40回支部大会）

「VLDB2008 国際会議報告 および XML DBの最新動向」

2008年12月20日(土)に、「Relational-Style XML Query」の話題で、SIGMOD日本支部大会において講演を行います。申込期限は過ぎておりますが、まだ若干席が残っているようです。

Relational-Style XML Query
XMLのような階層構造を持ったデータに対して、フラットなSQLを用いて問い合わせを行う手法であるRelational-Style XML Query (SIGMOD2008で発表) について紹介します。

この内容を日本(語)で紹介するのは初めてですし、横田先生の案内によると、「どうしたらSIGMODに通るような論文を書けるか」についても期待されているご様子なので、その当たりの話も織り交ぜようかと考えています。乞うご期待。

Michael Crichtonの思い出

小説家として有名なマイクル・クライトン（Michael Crichton）が、先月11月4日に咽頭がんで亡くなっていたそうです。驚きでした。映画化もされた「ジュラシック・パーク」や、NHKで放送されていた海外ドラマ「ER」シリーズの原作者と聞けば、ご存じの方が多いのではないでしょうか。

彼の著作との出会いは、NHK FMの青春アドベンチャー。「ジュラシック・パーク」、「スフィア」などの作品がラジオドラマで放送されていました。緊迫する展開、スリラーという言葉をそこで覚え、本屋で洋書を手にとり、英語が十分に読めないにも関わらず、ドキドキしながら先が楽しみで読み進めていった記憶があります。

（話はそれますが、青春アドベンチャーでは、谷山浩子さんの「悲しみの時計少女」、村山由佳さんの「おいしいコーヒーのいれ方」なども面白かった記憶があります。）

「ジュラシックパーク」以降の彼の著作はほとんど読んでいます。でも、まさか最近読んだ「Next」（バイオサイエンスを題材にした小説）が最後になるなんて。（今月、彼の最後の遺作として「Untitled Crichton」（タイトルが未定のままの小説）が、出版されるようですが）

映画ももちろん面白く作られてはいるのですが、彼に関しては原作の方が断然お勧めです。恐竜の怖さを強調した映画「Lost World（ロスト・ワールド）」 (ジュラシックパークの続編）も、原作を読んだときの深さや迫力に比べると、全然物足りないものです。

惜しい人を亡くしました。謹んで哀悼の意を表します。

Googleで論文が書けるか？

Googleに入って論文が書けるか？ 中の人が答えています。

Official Google Research Blog: Can You Publish at Google?

A common question I get is "How hard is it to publish at Google?" I want to dispel the myth that it is hard. It is easy to publish, easy to put code into open source, easy to give talks, etc. But it is also easy for great research to become great engineering, and that is an incredible lure.　（よく受ける質問が、「Googleで論文を書くのは難しい？」というもの。実際難しくはないし、コードをオープンソースにしたり、発表したりするのも問題ない。それに、いい研究をいい製品にもしやすい。それがGoogleの魅力だ。）

察するに、論文を書くことができるか？という文字通りの意味ではYes。でも、論文を書くためのincentive（きっかけ、強い動機）が生まれるか、インパクトのある論文を書けるようになるか、という点では、ちょっとわからない。ここで解答している人も、Googleに入ってから筆頭著者（first author）で論文を書いているわけではないし、Papers written by Googlers に紹介されている論文も、僕が知っている分野に関しては、Googler(グーグルの社員）単独のものではなく、もとから論文を書ける力のある人がGoogleの中の人と共著になっていたりする。あるいは、論文を書いてからGooglerになった、という傾向。

同じようなコメントが日本のGooglerからも欲しいものです。少なくともPapers written by Googlersの日本版が。というのも、大学関係の人の間では、論文を書く力がつく前の人材（学部・修士課程を終えたばかり）が、プログラミングができるという理由で、日本のGoogleに青田買いされている現状を非常に懸念しています。「論文を書ける」人材が本当に欲しい場合、僕が人事担当なら、PhDを持った学生、あるいは自力でそこそこの論文誌・学会に採録される論文を書いた経験のある人しか採用しません。

大学のように入ってから中で鍛えるのならそれで良いですが、鍛える力を持った人、論文を書くことに強い意識を持った人が中にいないのなら絶望的です。青田買いされた人材が、論文に関しては青田のまま終わってしまいます。Google以外の会社や大学の研究室でも同じことが言えて、研究志向を持っていない（過去にあまり論文を書いていない）人が上司になるだけで、論文を書くことは相当難しくなると思います。

論文が自身のキャリアにおいて大事なら、「書ける」かどうかだけではなく、「書くために必要な要素（論文へのincentive、経験を持った師匠となるべき人）」が揃っているかどうかも、ぜひ確認しておきたいところです。

はてなブックマークレットのデザインを変更する

久々にIEを使ってこのブログを開いてみると、デザインが意図していたものと全然違っていて愕然。

デザインを修正し、ついでに、はてなブックマークレット（左に表示される注目・人気エントリー欄）のリンクも、淡い色に変えました。

以下はスタイルシート（CSS)の例。

.hatena-bookmark {
padding: 0;
text-align: left;
font-size: 12px;
}
.hatena-bookmark-widget-title a img {
display: none;
}
.hatena-bookmark-widget-footer {
display: none;
}
.hatena-bookmark-count a {
margin-left: 0.5em;
text-decoration: underline;
}
.hatena-bookmark-count em a {
font-weight: bold;
display: inline;
font-style: normal;
color: #0099CC;
}
.hatena-bookmark-count  strong a {
font-weight: bold;
font-style: normal;
display: inline;
color: #FF9090;
}

ちなみに、はてなブックマークレットは、

http://b.hatena.ne.jp/entrylist/widget?url=http://leoclock.blogspot.com/

のリンクから作成でき、上のような独自のCSSを使う場合には、テーマを「なし」として使います。

SQLite JDBC 3.6.6.2 リリース

SQLite JDBC 3.6.6.2をreleaseしました。

http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC

もともとのSQLite 3.6.6に混入されたバグの修正版です。