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パッケージを取得しただけでインストールせずに終了してしまいます。 これはチケット#44584で5.10のバグとして報告されているものと同じように思えます。また、“C:\strawberry\perl\vendor\lib\PPM.pm”に以下の修正を行うことで、上記の条件下でもPPMインストールができるようになりました。 このことはチケット#44584へのコメントとして報告しました。 【調査経緯】C:\>ppm install Email::MIME::CreateHTML
Installing package 'Email-MIME-CreateHTML'...
Bytes transferred: 6112
C:\>379a380
> my $tarzip_dir;
381a383
> $tarzip_dir = $1;
385a388
> $tarzip_dir = $1;
387c390
< chdir($1);
---
> chdir($tarzip_dir);
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でのモジュールインストールに問題があるようです。このエントリでは私なりに調べた調査結果と修正パッチを提示しました（どちらも報告済みです）。
「モダン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で声をかけてください。
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分とかからず近いんですね。
- 「多様な意見」はなぜ正しいのか
- コミュニティの知識創造：コミュニティが、コンテキストをつくり、コンテンツ（意味のある情報）を生み出す
- 19世紀のエジソン：専門知の勉強、膨大な試行錯誤／これからのエジソン：ネットで呼びかけ
- 投資家（エンジェル）集団Common Angelsの巧みなコミュニケーション・プロセスの設計
- 新時代のナレッジツール（○○力）7種
技術評論者様からWeb Site Expert #27を献本いただいた。感謝。特集は「クラウドコンピューティングで変わる？あなたの仕事（ビジネス）」で、今の私にとって非常にタイムリーでありがたい。
IT Leaders「国産クラウドの実力」のPaaS比較表(PDF)を見ると「利用に『発注』行為があって利用開始や構成変更まで5日」みたいなサービスも結構あるようで でもそれクラウドじゃないでしょ？ とAmazon EC2ユーザな人に言われたり、やっぱりEC2な人である横田氏がつぶやいた それはクラウドではなく、ただのVPSですよね？ を見るなりして、なんとなくクラウドと非クラウドの境界ということが、もやもやと頭の中に引っかかってた。クラウディに。 ● 仮想化すればクラウドということはなく、仮想化を基盤にしたデータセンターがクラウドでもない。それは運用者、提供者にとって大きな変化だけど、利用者にとってはこれまでと何も変わらないからだ。単なるデータセンタの効率化だ。
「サーバ設置型｣ということで、ハウジングを起点とする。専用サーバホスティングは、サーバの調達の手間や持込設置の必要がないという点でハウジングより身軽で、OSから上は好きにいじれるという点でWebホスティングなどよりずっと自由度が高かった。1台のハードウェアをパーティショニングで分割したVPS（バーチャルプライベートサーバ)は、エクスペリエンスという点では専用サーバホスティングとほぼ同様だったが、個人が手を出せる価格で提供された。
ではクラウド型PaaSは？これがパーティショニングではなく、いわゆる仮想マシンを提供するサービスだったとしても、それだけではユーザにとって「ただのVPSですよね？」ということだ。ただし、自由に組んだ仮想ネットワーク上に複数台の仮想マシンを配して一つのプラットフォームにできるようになると、「ほほう、仮想ハウジングですね」となる。VPSが専用サーバホスティングより廉価に提供されたように、仮想ハウジングはハウジングより廉価に提供でき（るはずだ）、調達の手間や持込設置の必要がなく身軽だ。
さて、ではこれが「発注や変更以来から5日」とか言わない、即時利用開始、即時構成変更されるDIYなシステムになると？このAmazon EC2のような形態になると、Try&Errorやタイムリーな（その分タイトに切り詰められる）りソース調達が可能になる。New York Timesがやったように、現実的な費用で36時間だけジャブジャブのリソースを使うこともできるようになる。はっきりと、利用の仕方そのもの、ユーザー･エクスペリエンスが変わる。
●
ユーザー･ベネフィットといってしまうとダウンタイムがどうとか、細かい数字の比較になってしまって、でもそれが何なのという感じだ。それよりもはっきりとしたクラウドでしかできないユーザー･エクスペリエンスがあるか。データセンタ側のことなんか知ったことじゃなくて
それはクラウドではなく、ただのVPSですよね？
とか
それはつまるところただのハウジングですよね？
と聞かれたときに、「ユーザーの使い方がこんなに変わるんだ」と答えられるかということが、案外、本質的なクラウドと非クラウドの境界かも知れない。
「仮想化の明後日と未来(前編)」の続きだ。もう少しだけ、未来というよりは明日に属するぐらいの、すぐ先のことを予想してみる。
