kazeburo’s Neighborhood

2週間前になりますが、enNetforumの第2回EGMセミナーを聞いてきました。

特に面白いと思ったokdtこと岡田良太郎氏の発表は、資料を公開しないとのことだったのでどうにも感想など書けずにいたのですが、今日になって事務局から資料公開のお知らせが。見てみると、okdtさんの資料も公開されています。

ということで、okdtさんの資料「クラウドソーシング - 組織のポテンシャルを上げる“協業”のスタイル」の個人的な見どころ。

• 12～16ページの資料。McKinseyの"How businesses are using Web 2.0"などは未見で、探すために正式タイトルを知りたいと思ったところ。
• 21ページ。ここら辺は押さえておきたいというような有名企業例が列挙されてるのはおいしい。
• 26ページ。これを念頭に置くと、業務で作られるにグループはゲゼルシャフト、SNSなどが作るのはゲマインシャフト、「人の流動性が確保できてる」企業でも、SNSなどの導入はやはり人間関係の多様化につながるのだと確信できる。
• 29～32ページ。クラウドソーシングが有効な場面がまとまってる。ちなみにセミナー全体では「社員の隙間時間を集約して従来型生産」という話もあったけど、それは違う方向を向いているっぽい気がする。

全体に、このページ数ですごく良くまとまった資料だと思います。お薦め。

----
本エントリは2008年9月に社内SNSに書いたものを、2009年12月に転載しました。
また同じく第2回EGMセミナーでのTG情報ネット様の発表に着想を得て、「社内SNSの定着度を平均フレンド数で測る」というエントリをokilab.jpに書いています。併せてお読みいただければ幸いです。

西小倉さんという人がいて、この人が数年前にmindia（マインディア）というWikiサービスを立ち上げたのだけど、僕はずっと彼のやりたい事がわからずにいる。mindiaは一風変わったWikiだ。そこは分かる。そこに何かのこだわりがあるのは分かる。でもそのこだわりがなんなのかが分からないでいる。

久しぶりに会って、今日もmindiaのことを話してくれたので、そこから汲み取れたことだか勝手に想像したことだかをメモしておく。

■mindiaとは

mindiaは個人がWikiサイトを持つことが出来る「Wikiファーム」や「Wikiホスティング」と呼ばれるようなサービスだ。mindiaの「mind」は自分の心,マインドから着ていて、「dia」はWikipediaから、そして“d”を重ねてmindiaだという。その由来通り、自分の主観的な辞書というか用語集というか、そういうものを作ってくれたらな、という意図らしい。

mindiaが特徴的な点は二つある。一つ目はみんながバラバラな定義をする辞書だということ。むしろそれを推奨していて、例えば西小倉さんの「起業」というページを見ると彼の描いた起業の説明に続いて、「あなたにとって『起業』とは？」という質問が出てくる。さらにページの下に進むと、彼以外の人の、いろんな『起業』の説明が出てくる。そのバラバラさを楽しませるようでもある。

二つ目は、それが「◯◯さんの」「××さんの」というふうに、その人にとっての「起業」だということが強く表現されていることだ。Wikiではどちらかと言えば、個人の色合いを消して、みんなの意見の一致、合意形成、可能であれば客観的な記述を求めていくところがある。ところがmindiaでは「誰の」をはっきりと示し、これは「主観辞書だ」と強調してるみたいだ。まるで国土地理院の日本地図と借力のバカ日本地図を「どっちも日本地図じゃん」と言ってるみたいだ。

■mindiaとは何か

「あなたにとって『◯◯』とは？」という一言がmindiaの本質なのかも知れない。「◯◯とは何かをまとめる」サイトではなく、「◯◯について考える、そして書き出してみる」サイト。Wikiサイトではなく、Wikiのシステムを使った、何か別のサイトなのだ。これは。

西小倉さんと話していると、mindiaの面白さを力説してくれるのだけど、これがちょっと普通じゃないことに気づく（と思う）。彼にとってのmindiaの楽しさは、どうも「書くこと」にあるみたいなのだ。

「mindiaはパブリッシングツールである。Yes？」と聞くと「Yes.」と断言する。世の多くのWebパブリッシングツールは、blogしかり、twitterしかり、読んでもらうことやコミュニケーション、つまり他者とのインタラクティブを楽しみに挙げる。でも彼にmindiaの話を聞くと、「書くのが楽しい」「自分で読むのが楽しい」ということになる。そのことに特化した機能追加に本当に注力している。僕にはそう聞こえる。

書くために書いて、自分で読む。実はこういう楽しみを、僕たちはよく知っている。数千年前からよく知っている。これは日記を付けることによく似ているのだ。基本的には書くために書いて、自分だけが読む。書くことと自分で振り返ることに、もっとも意味があるのだ。mindiaでは。あるいは、tumblrで自分のスクラップブックを作る感覚にも似てるかも知れない。

■mindiaは何を促すか

「あなたにとって『起業』とは？」といった問い掛けは、ふと考えさせられてしまうものがある。言われてみると、さてなんだったろうな、と。

最近mindiaには「執筆依頼機能」というのがついて、西小倉さんからいくつかリクエストを貰ったのだけど、書きにくかったのでスルーしてしまった。ごめんね。しかしこれがWassrのお題やVoxのqotd（今日の質問）みたいに、直接僕宛じゃなくみんな宛の、ノッてもノらなくても良い日替わりのお題とかだったら、日によっては考えてしまうかも知れない。キーワードを「瞬！ワード」あたりで決定、「今日は〇〇が話題、インターネットには××のことらしいですが、あなたにとって『〇〇』とは？」みたいな内容だったらデイリーメールで受け取ってもいい。

話がそれたけど、つまりmindiaは「〇〇について考えてみる」「連想を働かせてみる」「考えたことを文章化してみる」ということを促すところに特徴があるんじゃないかと思う。コラボレーションツールやパブリッシングツールというより、むしろマインドマップやマンダラチャート、そういった思考ツールの一種なんじゃないかと思うのだ。何か目的があって考えるわけではないので、思考訓練や思考遊戯を促すというと、より近いかもしれない。

集団の構成員（従業員とか）からいろんなテーマで思考や発想を引き出すツールという切り口もあるかもしれない。「今日のお題」で会社の事業ドメインや強みスキルに近いキーワードを出していくと、アイデア収集になったり社員のその分野への感度アップにつながったりしそうだ。マインドマップなどの思考支援ツールというのは実はMindManagerなど商用製品（数万円する）がそれなりの市場を持っているようだ。システムASPにするなら、社内設置または社員限定にしてそう使うような、独特な市場もありうる気がする。

あるいは、今日はそもそも@naokis主催の私的勉強会だったのだけど、そこで「自分の考えを文章化するというのは練習が必要」という話が出た。そういう訓練にもなる。教育機関向けにWiki慣れ＆インタラクション慣れ＆文章化慣れのための学習環境とか、そういう切り口もあるのかもしれない。

■終わりに

という感じに今日は西小倉さんの話を理解してたのだけど、彼に「こう考えているんじゃないの」と水を向けてみると、すっきりしないようです。「あなたにとっての『西小倉さん/mindiaのコダワリ』は？」な文章なわけですね。実在の西小倉さんではなく、つかもとの主観的西小倉脳内ばなし。

誰か彼が何を考えているのか、mindiaというものが何なのか、うまく言葉を引きずり出して、教えてください。なんというか、何か独特で、まだ理解できていないのです。

Strawberry PerlはWindows向けのPerlディストリビューションです。このYet Another Win32 Perlの登場の経緯は「モダンPerlの世界へようこそ」第16回で紹介されていました。私自身は、CPANとPPMの両コマンドでモジュールをインストールでき、特にエラーが起きることなくインストールできるモジュールがActivePerlより多く感じることから、4月頃からStrawberry Perl 5.8.9.1を使うようになりました。

【Strawberry Perl 5.8.9.3でPPMが動かない】

先日、新規にStrawberry Perl 5.8.9.3をインストールした環境で、PPMによるモジュールインストールができませんでした。条件として環境変数“HOME”が設定設定されているときに発生し、以下のようにPPMパッケージを取得しただけでインストールせずに終了してしまいます。

C:\>ppm install Email::MIME::CreateHTML
Installing package 'Email-MIME-CreateHTML'...
Bytes transferred: 6112

C:\>

これはチケット#44584で5.10のバグとして報告されているものと同じように思えます。また、“C:\strawberry\perl\vendor\lib\PPM.pm”に以下の修正を行うことで、上記の条件下でもPPMインストールができるようになりました。

379a380
>     my $tarzip_dir;
381a383
>         $tarzip_dir = $1;
385a388
>         $tarzip_dir = $1;
387c390
<     chdir($1);
---
>     chdir($tarzip_dir);

このことはチケット#44584へのコメントとして報告しました。

【調査経緯】

380     if ($have_zip) {
381         $basename =~ /(.*).zip/i;
382    }
383    else {
384         $tarzip->extract($tarzip->list_files);
385         $basename =~ /(.*).tar/i;
386     }
387     chdir($1);

このため、tarまたはzipファイルが展開されたディレクトリに移動するはずが、chdir(undef)が行われてホームディレクトリに移動してしまい、インストール対象ファイルがそこにないのでインストールが行われずに終了していました。

またこれとは別に、調査中に気になったのですが、PPMのtraceオプションが動作していないように思われます。traceを1以上に設定したとき、「PPM.LOGに記録する」旨のメッセージが表示されるのですが、このファイルはどこに作られているのか結局見つけることができませんでした。もし分かる人がいれば、ぜひ教えてください。

【まとめ】

Strawberry PerlはCPAN及びPPMでスムーズにモジュールインストールできることの多いWindows向けPerlディストリビューションです。しかし5.8.9.3、そしておそらく5.10系でも、PPMでのモジュールインストールに問題があるようです。このエントリでは私なりに調べた調査結果と修正パッチを提示しました（どちらも報告済みです）。

ダメだし、感想、コメント等ありましたら、ぜひtwitterやwassrで声をかけてください。

「モダンPerlの世界へようこそ 第20回」でEmail::SenderやEmail::MIME系のモジュールを知って楽しんでます。で、今回はその中の一つ、モダンにHTMLメール（のEmail::MIMEオブジェクト）を作成してくれるEmail::MIME::CreateHTMLモジュールについて。

これを使うと，HTML部分に外部のCSSや画像が指定されている場合はネット上からダウンロードしたものを埋め込んでくれるようになります。 -- モダンPerlの世界へようこそ 第20回（2ページ目）

...ということで、リンクされているCSSや画像をダウンロードして、生成されるMIMEに含めて、HTML内のリンクはMIMEに含めた添付ファイルを参照するように書き換えるところまで面倒を見てくれる優れものです。これで作ったメールは、画像などが埋め込みだから受信しておいてオフラインですらすら読めて、すごく快適。メールのサイズが大きくなるけど。

【Email::MIME::CreateHTML 1.206版が動かない】

ただ何とかしたかった点が二つあって、まず現在最新の1.026版が動かないこと。多分use Email::MIME::CreateHTMLした時点でSyntax Errorになって、動かないと思います。

レポート#51208にパッチがあって、これを適用すればOK。ただWindows＋ActivePerlな環境だとPatchコマンドとかないと思うので、とりあえずgist#251669にパッチ済みのコードを貼っておきます。これでperl\site\lib\Email\MIME\CreateHTML.pmの内容を書き換えてしまえばOK。もっとも、パッチもたかだか変更2行なので、手で書き換えちゃってもOKなんですけど。

【ログイン済みのUAを使わせたい】

もうひとつはCSSや画像を取得しに行くときに、使用されるLWP::UserAgent（を継承した）オブジェクトを指定したいな、ということ。例えばSNSの新着情報をメールで送ろうとした場合、SNSにログイン済みのWWW::Mechanizeオブジェクトか何かを指定して、これで画像取得に言って欲しいわけです。

Email::MIME::CreateHTMLではこうした外部ファイルの取得部分をリゾルバー（resolver）として独立させていて、デフォルトのEmail::MIME::CreateHTML::Resolverの代わりにカスタムのものを組み込めるようになっていました。ということでEmail::MIME::CreateHTML::Resolverのサブクラスで、LWP::UserAgentオブジェクトだけ指定されたものでおきかえるEmail::MIME::CreateHTML::Resolver::CustomUAを書いてみました。これもgist#251646に貼っています。

次のように、uaを指定してresolverを生成、create_htmlする時に明示的にこのresolverを使うように指定します。

use WWW::Mechanize;
use Email::MIME::CreateHTML;
use Email::MIME::CreateHTML::Resolver::CustomUA;

my $ua = WWW::Mechanize->new;
(...some staff with WWW::Mechanize...)

my $resolver = new Email::MIME::CreateHTML::Resolver::CustomUA({'ua' => $ua, ...});
my $email = Email::MIME->create_html(
        header => [
                From => 'me@address',
                To => 'you@address',
                Subject => 'Here is the information you requested',
        ],
        body => $html,
        resolver => $resolver,
);

【まとめ】

Email::MIME::CreateHTMLはHTMLメールを作る時の、画像やCSSも添付ファイルとして埋め込んでくれるモダンな頼れるモジュールです。このエントリでは(1)これの1.026版を使おうとするとエラーになる問題の対処、(2)画像やCSSの取得時にログインなどの準備を済ませたLWP::UserAgent（系）オブジェクトを使わせるための方法に挑戦してみました。

多分これでうまくいくんじゃないかと...。ダメだし、感想、コメント等ありましたら、ぜひtwitterやwassrで声をかけてください。

わさび漬け

2009120718430000.jpg

Perlのリハビリがてら、Cicadaというライブラリを書いてみました。Githubからダウンロードして、perl Makefile.pl、make、make test、make installでインストールできると思います。xsなどは使っていないので、libの中身をそのままコピーしてもいいはずです。

【Cicadaのモチベーション】

Cicadaを書いた動機は、GitHubのWikiのほうに書きました。

CicadaはWebクローラを作るためのツールキットです。 長期にわたって使用するWebクローラを作るためのフレームワーク、例えばPlaggerやGunghoのようなものではありません。一時的な用途のための短命なクローラを作るときに頻繁に使用するメソッド集のようなものです。

SYNPSISのコードを見て分るように、Webページを取得したり解析したりといったことは、WWW::MechanizeやWeb::Scraperといった便利なライブラリを使って、作成者が思うように作成するに任せます。そのかわりにCicadaは、データディレクトリを決める、タイムスタンプや処理済URLを記録する、HTTPレスポンスからコンテンツを伸張しデコードして取り出すといった定番作業を1行で行うためのメソッドを提供します。

今あなたの中にホットな目的があります。そのためのクローリングとスクレイピングのアイデア、そして「端的にいえばこういう風に処理したい」のだという手順があります。それをそのまま、コンパクトなコードに書き起こすのは楽しいでしょう？工夫のしどころがなく退屈な、お定まりの部分はCicadaに任せて、楽しくクローラを書いてください。Cicadaは、そのためのものでありたいと思っています。

【既存のPerlのWebクライアントライブラリ】

PerlのWebクライアントライブラリは、クローリング系のライブラリはHTTP::*を基礎に、LWPを経てWWW::Mechanizeへ、HTML解析系のライブラリはHTML::*ライブラリを基礎にHTML::TreeBuilderを経てHTML::TreeBuilder::XPathやWeb::Scraperへと進んできました。

そしてこれらをつかったアグリゲーションは、作業フェーズごとのプラグイン機構を提供し、コンフィギュレーションでプラグインを柔軟に組替えてプログラミングレスを実現する、PlaggerやGunghoといったフレームワークが提供されてきました。クローリングの半分は、こうしたアグリゲータの適する領域です。

再利用性の高い部品としてのプラグイン群と、再利用のきかないプログラミングを廃した、コンフィギュレーション指向といえそうな構成。私もPlaggerやGunghoは大好きです。

【Cicadaの位置づけ】

でもこの他に、例えば新しく購読を始めたブログの過去記事をすべて取得したい、ある観点からサイトをクローリングしてデータ作成をしたい、そうした一回からせいぜい1週間、1ヶ月の用途のための、その場限りの手作りのクローラが書かれる領域があります。各フェースの処理は今回の用途に特化しすぎていて、用途的に再利用性ゼロ。処理の流れは独特で、フレームワークの処理フロー、フェーズ分けとは相性悪。そんなクローラです。

こんなその場限りのクローリングのために、PlaggerやGunghoの流儀を思い出し、これらの処理の流れに自分のしたいことをはめ込んで機能分割し、取得対象をコントロールするカスタムフィード、取得後のデータ取得や追加取得を行うフィルター、保存等の処理を行うパブリッシュなどいくつのものモジュールを書くのは、ちょっと労力をかけすぎな気がします。PlaggerやGunghoを使わずに、コードの上から下に処理が流れていき、ファイル末尾にきたら処理が終了するような原始的なクローラを書きたいのです。

Cicadaはこうした、設定ファイルやフレームワークを必要としない、すべてがせいぜい数百行の1ファイルのコードに書かれている、原始的といえば原始的なクローラを書くことをサポートするものです。こうしたクローラは、WWW::MechanizeやWeb::Scraperのおかげで非常にコンパクトに気持ちよく書けるようになりました。Cicadaは、これらのモジュールがカバーしないロギング、データ保持、そういったところをコンパクトに済ませられるようにし、一層「テンポラリ」で「コンフィギュレーションレス、すべてがハードコーディング」なクローラ作りというニッチ領域を支援するものです。

【まとめ】

Perlには多くのすぐれたクローリング系のライブラリ、解析系のライブラリ、アグリゲータ系≒それらを使ってクローラアプリケーションを作るフレームワークライブラリがあります。

パーマネントなクローラはフレームワークを使ってきれいに機能分割して作れますし、テンポラリなクローラはクローリング系や解析系のライブラリのおかげでコンパクトに書けます。ただ前者ではフレームワークで吸収してくれるような「ユーティリティ」的な作業を、後者では自分で実装することになり、割く手間が大きすぎると感じていたので、そこを提供するライブラリを作成してみました。

私のPerlの技術や、Webクライアントライブラリについての認識は、1年以上前のこの時点のもので止まっています。ダメだし、感想、コメントなどがあれば、ぜひtwitterやwassrで声をかけてください。

slideshareに「Elastic MapReduceでお手軽Wikipediaマイニング」というスライドがあがっていることを、社内SNSで教えてもらった（OKIの社内SNSもなかなか侮れない）。ohkura.comの大倉さんという方が公開されたものらしい。

■ 分散処理×クラウド≒Amazon MapReduce

MapReduceはGoogleが開発した分散処理アルゴリズムで、オープンソースによるJava実装にHadoopがある。このアルゴリズムをうまく使うと、大量の処理を細かく分割して多数のマシンで並列処理し、短時間で終わらせることができる。

例えば、40万5千件ずつのTiffファイルおよびXMLファイルを100台のマシンで並列処理し、36時間で81万件のPNGファイルに変換したNew York Timesの例のようにだ。しかしそうはいっても、彼らは100台ものマシンをどこからかき集めてきたのか？それも明かされている。クラウドだ！100台もの仮想マシンを即座に提供してくれるクラウドサービス、Amazon EC2だ！

Amazonのクラウドサービスには、その後Hadoopによる処理に特化し、まさにそのために要したコンピュータリソース分だけしか課金されないAmazon Elastic MapReduceというサービスを発表している。僕が教えてもらったこの資料は、まさにこのAmazon MapReduceを利用して、Wikipediaの巨大なデータを解析しようというサンプルだ。

■ Elastic MapReduceとWikipedia研究

Wikimedia Conference Japan 2009で武田英明氏が指摘しているように、Wikipediaのダンプデータというのは大規模性と網羅性を満たし、入手性の高い、きわめて興味深い貴重なデータだ。一方ででは解析を行おうとすると、鈴木優氏の取り組んだ課題である、あまりに大きすぎるデータが簡単には賄えない計算コストを要求する。僕も「企業Wikiにシグネチャを」にあるsilubeプロトタイプを開発した際、この困難を痛感した。

もちろん解決方法は分かっている。スケールアップかスケールアウトだ。モンスターマシンか分散処理だ。個人が手を出せるのは、Amazon EC2×Hadoop=Amazon Elastic MapReduceだ。

僕は今、silubeプロトタイプを再構築しようと、しばらくの間になまらせてしまったPerlスキルのリハビリを始めている（silubeプロトタイプはPerlで書かれている）。それが済んだら、拙い理解力でおずおずとAmazon EC2とHadoopの学習に進むしかないだろう、と思っていた。これをインスタントに理解させてくれそうな、手を動かして入門できるサンプルがこのタイミングで公開されたのはとてもありがたい。

もちろん、誰かに先を越されるのは大歓迎。さぁ、みんな、クラウド×Wikipedia研究を始めよう！

慶応義塾大学オープンリサーチフォーラム内のセッション「創造するアーキテクチャ」を聞いてきました。話は多岐にわたって、楽しく聞いたのにもかかわらず、頭の中で整理できないので触れません。twitterの#afc2009を眺めるなどして内容は察してもらえれば。

（11月26日追記：「創造するアーキテクチャ2」の動画がYouTubeで公開されています。）

その中で出た話の一つに「個室都市東京」があったのですが、これがすぅっと背中を抜けるような怖さでした。見ていないのだけど、江渡さんの紹介が分りやすくて、特に声音を使うでもなく訥々と語られるのだけど怖い。舞台は個室ビデオ（を模した空間）。

『個室都市 東京』に訪れる観客は、その個室に設置された作品、ビデオ・インスタレーションを鑑賞することができる。その内容は、壁を一枚隔てた向こう側にいる、池袋西口公園に関わる人たちへのインタビュー映像となる予定。（個室都市東京 - 作品について）

その質問内容は「ほしいものは何ですか？」「マクドナルドにはよく行きますか？」「どこに住みたいですか？」「友達はいますか？」「日本についてどう思いますか？」「難民についてどう思いますか？」「天皇に会ったことがありますか？」「日本は労働力を受け入れるべきだと思いますか？」「生きがいは何ですか？」…などであり――最後の質問として「あなたは一体誰ですか？」と投げかけられ、インタビュイーがそれに答え一枚のDVDが終了する。（日常の想像力 - 出会ったのは誰か）

ここで、あなたはどんな人ですか、そして深く深く掘り下げていった後で、あなたは誰ですかとインタビュイーが問われるのを目にする。これがだんだん、自分が問われたらという思いを掻き立ててきて、なにか恐くなると江渡さんは言う。そしてさらにツアーが続く。

この作品に訪れた観客は、オプションのメニューとして用意されたツアー等に参加することもできる。ツアーは池袋西口公園を基点として訪ね歩くことができる範囲のもので、参加者はナビゲーションに従いながら、東京に営む人々の日常生活を何らかの形で追体験するものとなる予定。（個室都市東京 - 作品について）

江渡「個室都市東京のツアー。出会い系カフェでマジックミラーの向こうにさっき個室DVDで見た人達(メイドやホームレス）がマクドナルド風の空間にいる。そして選んだ人と個室に入って、今度は自分が質問され、最後に「あなたは誰ですか」と質問される」（twitter - tokada）

個室DVDを出たあなたは（私は）その足で出会い喫茶（を模した空間）に足を運ぶ。テレビモニタの無効のマクドナルド風の空間に待機する人たち。それはDVDに出ていたその人であり、指名した彼ら、彼女らから実際に問われるのだ。あなたが（私が）、誰なのか、と。

個室ビデオ、出会い喫茶、あるいはマクドナルド。僕が感じたのは、都市の中でもっとも匿名的な存在であれる場所、シェルター的なそうした空間で、徹底的に匿名性が剥ぎ取られるのを目にし、そして体験するという恐さだ。そんなことになれば一体世界のどこに匿名性が残ることを許されるんだろう。シェルターを失い、剥き身の自分と向き合い続けなければいけない、「匿名性が消失」する恐怖を見せられてるんじゃないのか。体験しなかったイベントだけど、そうした恐さを感じた。

ちょうど一昨日ぐらいから、森見登美彦の「きつねのはなし」を読んでいる。中篇集だが、表題作である「きつねのはなし」から受けた恐さがこれに似ていた。逆か。「きつねのはなし」からうけて消化しきれずにいる恐さがあったから、個室都市東京の話から、そう印象を受けたのかも知れない。いろんなものを差し出し,多くのものを剥ぎ取られ、何も残っていない自分を見つけてしまうという可能性が恐い。表題作から一節引用しよう。

「夜遅くに起きていて、なんだか、わけもなく怖くなることがありませんか？」
「ときどき、あります」
「朝になれば、なぜあんなに不安だったのか分らなくなるでしょう。それと同じなのです。東京はいつも夜なのです」

昨日の「知の構造化センターシンポジウム」で楽しくなってしまって、今日のWikimedia Conference Japan 2009も行って来ました。ただ、朝は起きられなかったので、午後から。twitterの#wcj2009_Hに@argさんという方が投げている内容や、@mhatta氏のつぶやきを見ていると午前中の「辞書・事典とは何か」は必聴モノだったようで、そこはじわじわと後悔中。

テキスト解析好きなので、ずっと技術セッション＝第21回セマンティックウェブとオントロジー研究会を聞いていました。以下メモ。昨日のも同じだけど、僕がメモをミスってたり誤って理解している部分があるかもしれません。その点は考慮してお読みください。改めて見返すと、参加した人にしか分らないキーワードの羅列になってるし、読む人がいるのか分からないけど。

【Wikipediaと研究コミュニティ】（武田英明 国立情報学研究所）
http://www.slideshare.net/takeda/wikipedia-and-research-wcj2009

ソーシャルメディアとしてのWeb

創造とは
・創造は無から生じない（Collect)
・他者の仕事を知り、理解する（Create）
・他者へ自らの仕事をみせていく（Donate、一般にはPublishing）
・これがループ
・このループへの参加を一般人でも可能に、またループを加速したのがWeb

新しい創造のループ
・集まる（Relate）：三人寄れば文殊の知恵
・協働する（Collaborate）
・提示する（Present）
・情報を知ることは人を知ること、またその逆も
・情報を見せることは自らを見せること、またその逆も

ソーシャルメディア
・「社会的に広がりのある参加者によって構成され、参加者間のコミュニケーションによって成り立っているメディア」
・特徴：大規模な参加、何らかのコンテンツを生み出す、参加者間の相互作用がコンテンツ作成に影響を与える
　・相互作用＝コンテンツ：掲示板、Q&Aサイト
　・相互作用がコンテンツに影響：Wikipedia、ニコニコ動画
・例：初音ミク動画の協創プロセス

ソーシャルメディアとしてのWikipedia
・大規模性、網羅性、共同性
・データ入手性 … これが非常に大きいファクタ

Wikipediaと研究
・分析対象としてのWikipedia：“Wikipedia現象”の分析
　・なぜこれだけ大きくなったのか？だれが、何が、...。
　・合意形成のプロセス
　・集団性、社会性
・データとしてのWikipedia：Wikipediaデータの利用
　・知識の集合として
　・多言語の集合として
　・構造化文書の集合として
・Wikipediaの支援

編集プロセスに注目した研究
・ページのクオリティは編集者の数より、編集者のgini係数（≒一人の人の占める編集領域の割合の高さ）に相関
　→継続的に編集してくれる人の存在の方が重要
・「秀逸なページ」を「クオリティの高いページ」とみなした

知識集合として
・広範で均質な知識源とみなして利用する
　・国内各研究
　・Yago：オントロジー作成。
　・DBpedia：オントロジー作成。上位クラスはYagoから、インスタンスの関係はInfobox（Wikipediaのページ右上に表示されるボックス）から。
・常識、日常知識の利用
　・PowerSet
・意外な知識の発見

Wikipediaの利用
・上記のようなさまざまなデータを外部から利用可能
・Linked Dataとは“Web of Data”（ティム・バーナーズ・リーの命名）
　・Linked Dataによるマッシュアップ≒Bing？（Bingはそのデータの選択が秀逸）

まとめ

Q&A
Q：興味どころは？
A：分散してるのは当たり前、その上でどう共創していくか、というところ

【Wikipediaからのオントロジー構築とその活用】（山口高平 慶応大学）
資料は後日、研究会のホームページに掲載

ODP（Ontlogy Developping Process）とOL（Ontlogy Lerning：機械学習等）
・Wikipedia2Onto→評価→応用

ODP：オントロジー開発プロセス
・determin scope（Swoogle、watson）
・consider reuse
・enumerate terms
・define classes
・define properties
・define constraints
・create instances

OL:オントロジー学習ツール
・実装は山のようにある
・Doodle-owlというものを作っている
　・関係性を、共起性を元にリコメンドし、人が決定する

スクレイピング（ごみを取る）
・一覧ページ
・カテゴリとカテゴリ階層 → is-aとhas-aの混在、InstanceとClassの混在

Is-aの抽出
・後方一致→is-a（空港→日本の空港）
・前方一致→is-a（日本のスポーツ選手→日本のゴルファー：スポーツ選手→ゴルファーというis-a）
・Infoboxのテンプレート

課題
・上位、注意概念が不足しがち
・間違った上下関係
・文字列照合から生じるハイブランチ構造

デモ
・ロボットの太極拳。オントロジー関係ないけどすごい。というかすごいけどオントロジー関係ないｗ

Q&A
Q：is-aとhas-aを区別しやすい、登録し分ける仕組みをWikipediaに提案することは有用化？利用者にとって便利になるか？
A：かなり利用目的によるところで、意味を調べるといったところ出にはあまり利さないので、デフォルトで提供すべきものではないと思う。

【MediaWikiと構造化知識の抽出】（中山浩太郎 東京大学 知の構造化センター）

Wikipediaの解析がなんの役に立つか
・翻訳辞書、連想シソーラス、Webオントロジ
・Wikipedia API
・セマンティックWeb

デモ
・Wikipedia Thesaurus（http://dev.wikipedia-lab.org/WikipediaThesaurusV3/）
・WikiVisiSL

データ復元編
・pages_articles.xml.bz2がお勧め
・実はダンプデータ間にタイムラグがあり、SQL版とXML版は微妙にデータが一致しない
・解析用であればMyISAMを使用（トランザクションログ不要なのでInnoDBを使わない）
・mwdumperを使用、-serverなどオプション重要

主なディレクトリ
・config：設定ファイル
・skins：スキン、テンプレート
・extensions：プラグイン
・maintenance：メンテナンス用スクリプト
・includes：クラスライブラリ

主なテーブル
・page：ページ構成
・langlinks：言語観リンク
・pagelinks：ページ間リンク
・categorylinks：カテゴリリンク
・text：本文（ページID、テキスト）

便利そうなスクリプト
・maintenanceディレクトリには全部で98のスクリプト
・changePassword.php
・dumpBackup.php
・dumpHTML.php
・updateSearchIndex.php：復元後の検索インデックス更新
・rebuildall.php：テキストインデックス、リンクテーブルの構築
・「php スクリプト」で実行できる。

クラスライブラリ
・解析で厄介なのが、例えば「Wiki構文の解析（除去）」→includes/Parser.phpのParseメソッドでOK、メモリリークすることがあるので注意
・Wiki、Article、Titleなどのクラスも便利

ユーティリティ
・Wikipedia Research Scriptを作っている

【Wikipediaにおけるキーパーソン抽出による信頼度産出精度および速度の改善】（鈴木優 京都大学大学院情報学研究科）
※発表資料が「第21回セマンティックウェブとオントロジー研究会」ページで公開されています。

結論
・ほとんどの記事の信頼度が低い。
・記事の信頼度の高い記事は少量

研究の目的
・Wikipediaの記事の質を産出
　・高い質の記事を読者に提供（質の低い記事を排除）するため
　・記述の不十分な記事を著者に提示するため
・二つの特徴
　・実用的な時間での信頼度産出
　・精度の高い信頼度産出

著者の信頼性の評価
・Adler et al. WikiSym '08, WWW 2007
・著者が他の部分のレビューを行ったから、残すべきところを残したという考え方

問題点
・時間がかかる。
・履歴はすべてで100万件弱、すべて1秒で処理したとしても...。

アプローチ
・80%の記事を書いている20%の著者（Ziphの法則）に絞って調べる
・キーパーソンを特定する
・編集量多い著者、編集した記事数の多い著者をチョイス

編集履歴と編集量順の相関
・順位の相関：スピアマンの順位の相関係数を使用

Q&A
Q：以降の編集回数より、移行の経過時間を評価するべきでは？
A：実際に時間を信頼性抽出に使用してみたところ、信頼性が低かった。

【Wikipediaにおける編集者の活動分析】（山崎由佳 慶応大学メディア研究科）
※発表資料が「第21回セマンティックウェブとオントロジー研究会」ページで公開されています。

・分析対象：bot、IPユーザ、ログインユーザから計100名
・編集回数が5回、25解

ネットワーク分析
・平均経路長とクラスタ係数を調べる
・再編集は経路長最小

平均経路長
・変種回数が増えるほど平均経路長が長い
・種別でみると、ボットは突出して平均経路長が長い

クラスタ係数
・クラスタ係数は大きなばらつきが見られない
・種別でみると、人間はクラスタ係数が高く、ぼっとは極小

分類
A.狭範囲、少編集：特定分野の編集に興味、IPユーザ？
B.広範囲、少編集：閲覧記事が気になり編集、ログインユーザ？
C.広範囲、多編集：bot
D.狭範囲、多編集：いなかったけど、あえて言えば荒らし？

※ここで抽出したクラスタとカテゴリの関係性は？
※広範囲、多編集、記事系統に偏りのあるログインユーザを見つけると、ダンドリストタイプかも？

Q&A
Q：IPユーザは同一人物とは限らないが、それがノイズにならないか？
A：そこは懸念点、何かいい方法はないか？
　※逆にIPユーザが個人なのかグループなのか、などの分析ができそう？
Q：平均経路長にリンク関係などを考慮したらどうか？
A：やりたいと思っている。例えば記事間のホップ数を考慮したいと思っている。

【ウィキペディア記事閲覧回数の特徴分析】（山名早人 早稲田大学）
※発表資料が「第21回セマンティックウェブとオントロジー研究会」ページで公開されています。

取得データ
・ダンプデータ
・閲覧回数データ → これも信頼性や貢献度を定量化するのには有用では？

閲覧回数データ
・Domas Mituzas氏が公開している（http://dammit.ly/wikistats）
・1時間ごとのデータで、言語コード、記事名、閲覧回数、バイト数。
・転送時は転送元、転送先療法でカウントされる。
・pagecountsの他にprojectcountsもある

編集回数との比較
・UUを調査
・IPユーザは一人のユーザとしてカウント
・編集回数・UU数が多いものは閲覧回数・UU数が多い
・編集回数・UU数が少ないものは閲覧回数・UU数は広く分布
・Spearmanの順位相関係数は低い
　→逆に編集回数からは分らない情報が閲覧回数には含まれているかも知れない

検索エンジンでのヒット回数（≒語の有名度）との比較
・正の相関：順位相関係数0.53

Q&A
Q：月間編集回数より累積編集回数のほうが質に関係があって閲覧数と相関しそうに感じる。なぜ月間の編集回数なのか？
A：そこは特に検討していない。
※月間の編集回数の変化と閲覧回数は相関するかも（減衰が早い＝早く誤りがなくなる、枯れていく傾向）

【Wikipediaカテゴリネットワークからの意外性のある関連性の抽出】（野田洋平　東京大学）
※発表資料が「第21回セマンティックウェブとオントロジー研究会」ページで公開されています。

オープンコーラ
・Wikipedia上にあるが、あまり知られていない
・「オープンソース」と「コーラ」から辿れる
　→オープンソースとコーラの意外な関連

アプローチ
・グラフネットワーク構造から特徴量抽出
・カテゴリ間の関連性の意外性が高い＝共通小項目が少ない、カテゴリ同士が遠い
・カテゴリA、カテゴリB、共通インスタンス（記事）の関係性をすべて取得し、その中から以外性のある関係性を発見する

【多言語に展開するWikipediaの特徴の比較調査】（森竜也 東京電機大学）
※発表資料が「第21回セマンティックウェブとオントロジー研究会」ページで公開されています。

言語観の差異
・言語間では、ある言語にはあり、ある言語にはないというページがある
・文化、歴史、etc.が違うのだからあって当然
　→積極的に個々を調べるべき
・あるカテゴリに対する言語版ごと下位エントリの数を比較する
　※あるエントリのサイズを比較しても面白いかも知れない

方法
・XMLを直接解析
・Luceneインデックスとして保存

問題
・ここでもカテゴリ間の上下関係に不適切なものがある（イスラム教→...→オリンピック競技など）
・タイトルをbigramで比較し、閾値0.25で切るようにした。
・結果を見ると第二次世界大戦と太平洋戦争の間が切られているなど、よくないものがある

例
・言語版の違いが大きい例：江戸時代、キリスト教、第一次世界大戦
・言語版の違いが小さい例：データ構造

※これで何をすることをゴールにしてるんだろう？
※スコアの増加傾向の比較をすると、将来予測（Wikipediaでの動向からして○○文化圏ではこれから××分野が熱くなりそうだ）に使えるかも知れない

【総合討論】

-- Wikipediaの「信頼度を測る」という話題が多かったが、信頼できなさをどこに感じるか？
武田：ある水準まで信頼性は達していると思うが、極論すれば専門家による信頼度に及ばない部分は出ると思う。その意味で、逆に信頼度の低い記事を排除するというアプローチはありだと思うし、そこは機械的な手法が効く部分だと思う。
山口：オントロジーの構築をコストレスでできないかということを考えてきた。電力分野を調べたことがあるのだが、意外と電力分野は専門的な知識までしっかり書かれている。そこにある知識をそのまま実地に適用していいかというと創ではないが、最初の手がかりとしては有効だと、これは電力の専門家と話していて出てきた。最初に使える資源としては有用だと思うし、そう使う手法を開発していった方がいい。
中山：Wikipediaの信頼性を語るときに、ツールがいいのかというと、それ以上にソーシャルのパワーがいいものだと思う。その意味で、ソーシャル、個々人が判断しやすい情報を提示する方向性がいいと思う。

-- 各国語版の中で日本語版はポップカルチャーが多い。その偏りがあるということは良いことか悪いことか？それを生かす方法は？
中山：ページ間のパスを調べていると、英語ではうまくいく場合でも日本語ではポップカルチャー的なところにバイアスがかかることはある。そこで言語観で解析時にはバイアスがかからないような指標を取り入れたりする。しかし偏りがあること自体は、それが文化だと思うので、悪いとは思わない。
武田：私もむしろそういうところにある種の知の集積ができた、フォーカスのあたるところが見えてきたという価値だと思う。それがわからないという問題が解決してきたと捉えられるし、それをもっと可視化したらいいと思う。ドイツ語版Wikipediaで製本をしたときに偏りのないものにする取り組みがあったという話を聞いて、それはそれで面白いと思うけど、僕はむしろ偏りがわかるように作るのが面白いと思うし、そうすることがポジティブなフィードバックを生むと思う。
山口：私の立場では、結局Wikipediaに頼るべきではないというところ。それはそれとして、例えばポップじゃない電力分野が充実していたり、私としては文句はない。

-- Wikiepdiaの課題としてカテゴリとして小さいところがあり、本当に小さいのか手薄なのかわからない。裏番組の相互オントロジーではどんな話を？
橋田（会場から）：総合概念のオントロジーを構築して提供しようという話。ITハンドブックでは小項目主義を採り、36分科会にふり、ドメインによるコントロールで粒をそろえた。Wikiepdiaではドメインによるコントロールをするものではなく、そうした形になってないのだと思うし、それはそれで結構なことだと思う。ただ一つ気がかりなのは、一般の市民から知りたい専門知識のリクエストが上がっていながら、専門家が答えられていないといったことがあれば、それは残念。
田中（東京大学）：400にもなるプロジェクトはあるようだが、そこまではいっていないし、研究者としてそういうところはサポートしていければなあ、と思う。
（会場）：Wikipediaに深く関わっているが、例えば2ちゃんねるのようなファンの多い分野にはプロジェクトが多いが、伝統芸能といったところをどうしていくかという問題は残る。

-- 不足分野があったときに、専門家を巻き込むような仕組みの事例はないのでしょうか？
武田：アメリカでは大学や図書館で編集方法を教えるといったワークショップのようなものはあったらしい。

（会場）：Wikipediaのルールに「独自研究を載せない」というものがあって、それがどうなのかな、というものがある。
武田：Wikipediaで言っているのは、factを書けという風にとるべき。自分の研究を書いてはいけない、という意味に取る必要はない。
（会場）：過去にWikipedianとして活動したが、文献の少ない項目で、どうしようもなく自分の文献を参照している。また、学会ジャーナルの編集部などが、適切なリファレンスだと思えばパブリシティを高める上で積極的に記述と参照をしていってもいいと思う。
武田：ファクトとして書くのであれば、それはファクトに基づいて反論すればいいので、ありではないかと思う。

（会場）：Wikiベースでオントロジーを作るというアプローチは？
武田：セマンティックウィキという例がある。
（会場）：今のアプローチでは、コミュニティに対して一方通行で、例えばインスタンスであればコミュニティで作れるなどの方向はあると思う。

信頼性を図る上でのディスカッションページの自然言語的な解析など、あってよいはずなのに手薄な分野というのはあると思う。Wikipedia研究の薄い部分は？
中山：他のリソースとの融合。ボトムアップが得意な分野とトップダウンが適する分野があるのだから、そうした外部の例えばワードネットとの融合など、そうしたところをやっていくことが重要になるように思う。他のウェブ情報とのダブルチェックなど
山口：実際に非常にシャロウな処理しかしていない。もっとディープな言語処理を持ち込んでいったら、例えば前に座られている松尾先生などが入っていただけたら、すごい進むと思う。もう一段深い世界に至れると思う。
武田：情報系の人が喜ぶようなデータは出しているが、社会系の人と組んだような研究はまだ少ないように思って、どちらから入ってくるのかわからないがそこができたらまたいい研究ができるのではないかと思う。

【クロージングセッション】

-- A会場のセッションがまだ終わらないので、急遽ウィキペディアQ&A
Q: ウィキペディアで管理者が非常に足りないと聞く。アンサイクロペディアにのびた君制度というのがあって、そういった取り組みをしたらどうか？
A: いくつかあって、インターン制度などの話も進んでいる。

Q: 実際に自分で書いてみたりして、やりがいとか嬉しかったことなどは？
A: ...えーと、ここで答えようとしている二人は、あまり書いていないので...。
A: オープンソースの世界では「かゆいところに手を」ということがあるが、ウィキペディアでもそういう人が多い。また「キャリアに役立つんだ」というOSS開発者も多いが、ウィキペディアでは創は履歴書にかけないというか、隠す人が多い。それでも利用者ページをみると、自分で勉強してまとめて発表するというプロセスが楽しい、あるいはコミュニティ内部でのインタラクションが楽しいといった手ごたえだと思う。
A: もめたりとかして利用者ページに「しばらく休みます」と書くと「がんばってください」とコメントが入ったりというのはみます。

■ 終わってみて

Wikiepedia研究というのは、こんなに多くに人が取り組んでいるのだな、というのが何よりの感想。Wikiばなというのはそれなりに多くのWikiフェイバリットが参加してくれていたと思うのだけど、Wikipedia界隈とも、こうしたWikipedia研究者とも重なる部分が少なくて、もっと、融合する必要はないにしても異文化のまま接点というか交流があってもいいんじゃないかな、と。

あと懇親会は話をできた人たちが面白くていろいろ聞けたし、クロージングあたりでいろいろいいこと言ってると思ったりしたのだけど、懇親会は参加した人の楽しみということで僕のメモはなし。

知の構造化センターシンポジウム

マイニングなどの話もある「知の構造化センターシンポジウム」というイベントがあると知っていってきました。東大。赤羽からだと、南北線で15分とかからず近いんですね。