スマトラ警備隊

by 相対性理論

2010.02.03

Lyon (France)に行きたい。世界中いろいろなところに好きな街はたくさんあるけれど、Lyonには不思議な懐かしさを感じる。一カ所に数年以上住んだ事がない僕にはよくわからないし、住んでいた土地以外への感覚としては適切ではないのだろうが、郷愁というのはこんな感じだろうか？なんだろう、西ヨーロッパのエッセンスを集めたような、そんな街だと思う。

一応約束していたタスクは一つ終了。去年の今頃のように予定の３倍ほど時間はかからなくなった（見積もりがまともになってきた）けれど、やっぱりまだ予定よりはビハインド。

修士の最終試験が終了。明日からのゼミ合宿が終われば今学期の作業としてはほぼ終了。

予言

2010.01.29

iPhoneを発表した時、Appleは自らが広めた「マウス」を使って計算機を操作するという概念を破壊した。

iPadによって、AppleはMacintoshで自ら作り上げた「パーソナルコンピュータ」という概念を再定義した。

そして、Appleは近々、自ら創造した「デスクトップ」と「Finder」というアナロジーをぬぐい去るだろう。２０年前からジョブスは言っていた。データはローカルに持つべきではないと。iTunes, iPhoto, iBooks, Youtube, Google Maps。これらのデータは通常の「ファイル」として「Finder」上に置かれていないばかりか、ウェブやMobileMeに存在しているものさえある。モバイルに、ユビキタスに。コンピュータを解き放つため、ジョブスは、Appleは、次にこれらを破壊してくれると思う。

そして、満を持してMacintoshにマルチタッチUIが載る日がやってくる。MacOS Xは、そのときに完成を見るだろう。

ワールズ・エンド・スーパーノヴァ

by くるり

2010.01.28

というわけでiPadがアナウンスされたわけだが、相変わらず書きますよ、現段階での総評。

まず、このプロダクトは、大きなiPod Touchでも、小さなMacintoshでもなく、"iPad"である、つまり、第三のラインナップであることを意識する必要がある。iPhone的に考えるとデカくて持ち歩きにくいだろうし、Macintosh的に見るとマルチタスクもないし自由度も低い。でも、iPadはそういう枠組みで考えるべきではない。

そして、iPadは読書のためのデバイスではないし、Kindleと比較するべきでもない。iPadでは本も読めるが、読書のためのデバイスではない。

ではiPadとは何か。僕の回答はこうだ。これは、新しい文房具。さらに別の言い方をすれば、iPadは「パーソナルコンピュータ」だ。

パーソナルコンピュータと言えば、iMacやMacBookなどをこれまでは指していた。でも、iPadはこれらを「ワークステーション」（仕事場）に新しく定義する。音楽を楽しむ、映画を見る、読書をする、絵を描く、写真を整理する、宿題をやる、ネットをブラウズする。そういうパーソナルライフに必要な作業を取り出し、恐ろしく効率的にまとめあげたデバイス。僕らは勘違いしていた。これまで存在していたものは「ワークステーション」であって、パーソナルコンピュータ（個人の計算機）というものは、2010年に産声をあげるものなのだ。

実際にKeynoteでジョブス達が触っている様子、その後続々とあがってくるHands-onの動画など、そしてそのUIを見れば、iPad上での音楽、動画、写真などを見たり聴いたりする作業、さらには本やウェブサイトを見る作業は、明らかにMacBookやiMacでマウスを用いてやるよりも直感的で自然だ。

iPadのインタフェースを見ていて、強烈にMacOS 7の頃のAt Easeを思い出した。アプリケーションの機能としては普通のMacOSと変わらない性能で、そこへのアクセスが恐ろしく容易。iPhoneOS 3.2でファイル共有機能ができて、Finderをリプレースする機能としてAt Easeが完成したと言えるだろう。そして、At Easeが狙っていたのは子供や教育市場だった。なるほど、iPadには教科書が見事に収まる。教育用アプリケーションも簡単に使える。コミュニケーションもできる。教育の現場にこれからウェブは不可欠だろう。さらに、PagesやKeynote、Numbersで宿題もできる。この価格だと、小中学校でiPadを使って授業が行われる風景が容易に想像できる。アメリカの学校だと、百科事典くらいの馬鹿みたいにデカイ教科書を何冊も持ち、関数電卓も持ち歩く。そういうのが全部iPadで直感的にできる。この直感性は、Macではできない。そして、iPod Touchじゃ小さ過ぎる。まさに、iPadにしかできない。

同様に、多くの人はMacをUNIXとしては使わない。シェルは開くことはない。大きなラップトップではなくてNetbookを買う。そういう人たちにとってみれば、iPadでやりたいことの全てが、他のどんな道具よりも簡単にできる。そして、何より安く買える。iPadのマーケットは広い。

もう一つ考えてみて欲しい。このサイズで、持ち運びが便利で、直感的。僕は、iPadは今までコンピュータを使うべきだけど使っていなかった世界にこそ広まると思う。例をあげよう。病院で毎朝、看護婦さんが入院している患者さんの血圧を測って回る。手にしているものはメモボード。これをiPadに置き換えてみよう。Dockコネクタから血圧計が繋がる。患者さんに話を聞きながら、タッチ操作で状態を電子カルテに入力。こういう近未来は映画などで描写されることがあるし、（子供達が使う電子教材としてのiPad同様）想像に難くないはずだ。スーパーのPOSレジのタッチパネルを置き換えることもできるかもしれない。メモボードは形も似ているし、これがiPadで置き換えられるのは必至だろう。そうだ、自動車教習所の教官が君の運転をチェックしながら手に持っているものもiPadかもしれない。

そう、だから、iPadは「ワークステーション」を置き換えるものではない。中途半端だし、MacBook Airの方がいいと考えるのは当たり前だ。それは「ワークステーション」であって、「パーソナルコンピュータ」ではないからだ。「パーソナルコンピュータ」はまだ産まれていない。「パーソナルコンピュータ」が使われるべき場面は、まだ「コンピュータ」が入り込んでいない世界なのだ。

iPadには大きな可能性がある。おそらく、「パーソナルコンピュータ」が僕らの思いも寄らぬ場所に入ってきて、驚かされる未来が１年から２年以内にくる。ユビキタスでパーソナルなコンピューティングがはじまろうとしている。

セントレイ

by サカナクション

2010.01.26

三倍界王拳（1日を3日にする方法）のやり方を発見した。迫り来る期限の中、どうしても時間がなかったので月曜早朝から発動。さすがにまだうまくコントロールしきれていないし、三日目はかなり身体に反動が表れて来ていたけれど、火曜朝の時点で三日分の仕事が終わっているので完全にタイムスリップした感覚。これはすごい。

一週間Twitterを使ってみて、やっとこれがサーバーレベルでどう実装されているかがある程度想像できてきた。なるほどねぇ、時代にあったいい設計だと思う。G-language ProjectではMarch/Cubeから発展した構想としてInsightというのがあるんだが（とはいえcoryくらいにしかちゃんとこれの中身について話したことはないんだが）、実装段階では参考にさせてもらおう。Twitterは、メリットもデメリットも、自分を強制的にパブリックスペースに置く事にある。よって、このツールの難しさも面白さも基本的にはパブリックスペースのそれと同じわけだ。まだあんまりたくさん有名人アカウントみてないけど、@masasonの使い方はもの凄く巧みだと思う。

ああ、そうか。Insightのベースになる考え方って、今の僕が考えるセマンティックウェブに欠けているものを補完する手段そのもので、チューリングテストを突破できる人工無能の構築に必要なハックともかぶる部分なのか。

例えば、今、箱根と銀座に行きたい。これを都心・温泉地の対照的な願望と見るか、神奈川県央在住者として、コスト（移動時間・必要なお金など）が同等な候補と見るか。この世界は相対的なものである。ただし、「デザイン」や「オントロジー」には絶対的な主観的観測点を置かなければならない。ではその観測点を効果的に設定するにはどうすれば良いか。一つは優秀なデザイナーが独断と偏見でデザインすること。そしてもう一つは、集合知のアトラクタを用いることではないかと思っている。そして、どちらか片方ではなく、これらを融合させることが大事。まぁ、それにはさらにもう一つの観測点としての強力なデザイナーが要求されるというパラドックスがあるが、その解決方法も僕は一応知っている。

ま、相変わらずプロトタイプがない段階であまり手の内を見せたくはないので、曖昧ですがこのへんで：）

Bullet in a Bible

by Green Day

2010.01.24

Green Dayライブ！海外の大物アーティストはライブの盛り上げ方が本当にうまい。Green Dayは特に観客の参加のさせ方が特徴的なんだけど、今回も埼玉スーパーアリーナが小さく感じるくらいの一体感。まぁ、Aブロックでモッシュされない程度に真ん中へんで陣取ってたので、実際ステージには結構近かったんだけど。あとで聞いたところによると、結構曲順は二日間のスケジュール全体で考えていたっぽい。そういう意味では（アジカンのゴッチが言うように）やはり二日目に言ってよかった。特に、Jesus of Suburbiaは今日だけだったらしい。エネルギー充填したし、また頑張るぞっと：）

Tweetの続きをこちらで。事前議論が結構密に進行中なのだけれど、DBCLS BioHackathon、3回目とあって議論が成熟して来ているのを感じる。解こうとしている問題の難しさを参加者が確実に共有してきている印象。1回目でその難しさを知り驚き、2回目で実感し、今に至っている様子。

生物情報のセマンティックウェブによる統合。端的にまとめると今回のテーマはこれだ。その上で、技術レベルの議論から応用レベルの議論に順に展開すると、考慮すべき点はおおよそ以下のようになると僕は考えている。

まず、データは同一フォーマットでatom単位で扱える（パースが不要）ことが望ましく、適切なセマンティクスがついていることが望ましい。そう考えると、現状ではセマンティックウェブは向うべき方向性としてpromisingである。一方で、RDFモデルはERモデルの上位概念であり、よって上位互換である。おそらく現存する全ての生命情報はERモデルで定義されている(RDBにストアされている）か、ERモデル互換(RDBにストアできる）ので、現存する全てのデータはRDF化が容易である。ERモデルのEntity定義に既存の（なければ新規の）セマンティクスをつけ、存在すれば（存在するだろうが）db_xrefを追加し、RDF tripleとして公開するproxyを用意すれば良いだけだ。これは一般的にSOAPサービスをREST化するよりも遥かに容易。やるつもりはないが、その気になれば僕のチームで１週間あれば世界中の主要な生命情報データベース（KEGG/NCBI/EBI/DDBJ）をドラフトRDF化するproxyは作れると思う。とはいえ、この単純な作業を行うこと、そしてそれを簡略化すること、優先すべきオントロジーの指針を与えること（実はこれが一番難しい）はやるべきタスクとしてあげられる。ちなみにCardioShareとConceptWebAllianceはこれ。

次に、RDFがあったとして、「何が」それを扱えるか、という問題。ここはMarkが主に議論している点で、分散クエリや、4storeやVirtuosoなどのDBMSに相当する部分で、非常にセマンティックウェブにspecificな技術的な問題。ここはもうその道の人(Markら）に進めて行ってもらうのが一番良い。

そして、そのようなRDFとそれを扱うDBMS、分散クエリができたとして、何をやるか、という話。いまのところあがっている話としては、RelFinderのようなネットワーク可視化（SADIにもある）みたいに、データが実際にどう得られて、従来のものに比べてどう広がりがあるかを見せる話、それから、Wolfram alphaのように、内部的なセマンティックなクエリ生成を行う話（Google-like queryというのもここの議論）。ただし、この段階の議論をする時には、実は、この段階の議論にはセマンティックウェブは必ずしも必要ないということを絶対に意識する必要がある。前述のとおり、現存する全ての生物情報はER-readyであり、よってquasi-RDF-readyである。おおざっぱに言って、dbgetとlinkdbを使うだけで生命情報用RelFinderのようなものは簡単に作れる。これはgenomenetだけじゃなく、EntrezでもEMBL-EBIでも当然然り。なので、この段階での議論と思考は、セマンティックウェブとは切り離さなければいけない。問うべき問題は、よって以下のようなものになる：「EntrezやEB-eyeやdbgetでは不十分な、解きたい生物学的問いとは何か。なぜEntrezやEB-eyeやdbgetではだめなのか、解きたい問いというクラスに共通する性質は何か」。敢えて繰り返す。この問いには、セマンティックウェブウェブがなくても解決できる。そして、セマンティックウェブがあれば、より効率的に解決ができる。それは、現存する生命情報が全てER-readyであり、よってquasi-RDF-readyであるからだ。

あまり手の内を明かしたくないので簡潔に書くが、僕の答えは、以上の問いへの答えは、class:RDFに含まれ、class:ERに含まれないものだと思う。そして、それは、１つの管理母体(KEGG/NCBI/EBIなど）に制限されないデータの、データベース間という関係だけでなくセマンティック関係を含めたrelation。これはRDF schema=ER、RDF=(RDF data RDF schema)なので、RDF - ER = RDF dataという関係から簡単に導くことができる。次に、そういった関係が大量に得られた場合、必要になってくるのがcurationとrankingだ。RDFモデルになってrelationが現在のERの比ではないほどになった時に、何が「見たい」relationなのかを選択できる必要がでてくる。RelFinderでもこの「選択」をうまくやらないと綺麗に可視化できない(PPI dataのgigantic fur ball化を見れば想像が容易か）わけだが、ここで丁寧なrelationのcuration、ないし、page rankのようなrank付けが必要になる。日本語で無理矢理まとめるなら、「興味がある対称に関する関連するあらゆる情報（現在では複数のステップを得る必要がある）が瞬時に手に入って欲しいが、その情報はノイズが少ないと嬉しい」ということになると思う。（詳細は省いたが、これが解きたい問いというクラスに共通する性質だと思う）

というわけで、僕は「RDFとそれを扱うDBMS、分散クエリができたとして、何をやるか」というところにフォーカスして、セマンティックウェブは使わずに、クライアントインタフェース（コードネーム：Cube、プロダクト仮称はopen-bio-staffにバラしましたがまだこちらでは非公開）を開発する予定です。解きたい問題は「興味がある対称に関する関連するあらゆる情報（現在では複数のステップを得る必要がある）が瞬時に手に入って欲しいが、その情報はノイズが少ないと嬉しい」。解くための方法のヒントは、インタフェース、生物学者とはどういう人たちかを理解すること、生物学者として、僕なら世界中のデータベースをどう評価するか。