学位論文 執筆用 TeXセットを公開
久々の日記更新。
Twitterで「学位論文執筆用TeXasセットを公開しよう」
https://twitter.com/tksakaki/status/403043043202174976
とか呟いたら、2名ほど反応があったので、
せっかくなので公開。
https://www.dropbox.com/s/4myeovgmcjkzcyt/TeX_set_for_thesis.zip
どんな工夫がしてあるかというと
・概要、各章、謝辞がそれぞれ別々なファイルになっているので、長い論文を書く際に便利
※博士論文を１つのTeXファイルで書くと、長すぎて見直す気力が減るのを回避
・業績を書く際に、論文誌、国際学会、国内学会、解説記事、書籍をファイルを分けて書けて、ちゃんと目次に出てくる
※業績を書く際、面倒くさがりな自分がやると、往々にしてごっっちゃになる
という感じ。
なお、コンパイル手順がちょっとトリッキーなので、00readme.txtを
良くよんで欲しいす。
あと、お勧めのTeXエディタは、TexMakerです。
http://oku.edu.mie-u.ac.jp/~okumura/texwiki/?Texmaker
http://www.xm1math.net/texmaker/texmakertop.png
スクリーンショットを見ると分かるけど、章構成を見ながら
編集できます。
あと、左ウィンドウの各章・節をクリックすると、そこにジャンプ出来るのも便利。
Win版、OSX版、Linux版があるので、だいたいの環境で使えます。
その代わりインストールは・・・下記参照しながら頑張ってください。
OSX：
http://blog.livedoor.jp/kobakeiichi_exe/archives/65790913.html
Windows：
http://blog.livedoor.jp/kobakeiichi_exe/archives/65783993.html
東日本大震災ビックデータワークショップ メモ 後半
スライドの場所など
https://sites.google.com/site/prj311/event
https://docs.google.com/spreadsheet/ccc?key=0An9ZuZLxj12adE9tUmxJbWdPcGM0OEFnX25IelBSeXc#gid=0
メモは途中から。
・会津先生
ITデータは生の現場は違うので、一度現場に行くべき。
・賀沢さん
被災地に行くと「ITは何の役に立つのか？」と思う
自分の研究結果が否定されるかもしれないが、その痛みを乗り越えつつ、
「でも、ITのここは役立つ」をアピールしよう
・さくら 松本さん
背景：情報が欲しい人はどこにいたのか？が分かったり分からなかったりする
質問：各社・各人はどんな情報を持っていたのか？？
・津波を伝えることができなかった。必要な情報が他の情報に埋もれてしまった。
・取材クルーが逃げようとしたが、どこに逃げて良いのか分からない
・どこを取材すれば良いのか？どこを取材したのか？どこを取材してないのか？が把握できなくなる
・渡邊先生
ウェザーニュースのレポ-ーターによって、空白地帯が埋められる事例の話
・山崎さん
ジオタグやハッシュタグをつけてツイートはしない。仙台在住のエンジニアに色々質問していた
・賀沢さん
情報発信のリテラシーをあげないといけないよね→実際に、あげて高い効果が得られた事例があると説得力が増す（ウェザーニュースの例）
・ゼンリンマップ
誰の家があったか情報が津波で失われてしまった→ゼンリンの紙の地図を届ける
仮説住宅には手紙が届かない → ゼンリンが人力で仮説住宅の人の元々の住所を調べて、公的機関に提供した
阪神大震災の時も、過去の地図を求める例が多かった→今回のはその経験を活かして、すぐに増刷した。
・乾先生
我々が集めた情報や、今後の災害において個人から上がってくる情報をどうやって、地方自治体に届けていくのか？を考える必要がある
情報が電子化されればされるほど、紙の・生の情報が上に上がっていかない可能性があるのではないか？
いずれにせよ、収集した情報を自治体に届けることを考えつつ、さらにそれを主張していくべきである。
・会津先生
阪神大震災の時は、情報ボランティアが役立った。今回は機能しなかった。
次回、何かが起きたときに情報ボランティアを組織しなければならない。そのように努めなければならない。
○質問 by 賀沢さん
最終報告会で気仙沼、石巻の自治体の方をコメンテーターとして呼ぶ。
最終報告会で意見を聞きたい人・ディスカッションしたい人はいませんか？
○回答リスト
・首都圏交通事業者の人を呼びたい。
・クロネコヤマトさんに来てもらうのはどうか？
ロジスティクスの問題について
・通信インフラ屋さんを呼んでみてはどうか？→呼べる。現場復旧の人も呼べる
・Yahooの人を呼んでみては → 呼ぶ。
・災害支援NPOの人を呼んでみては？
質問：最後、運営方法について
おまけ：
○根性マイニングの話
みんな生データに目を通してみよう！！
東日本大震災ビックデータワークショップ メモ 前半
スライドの場所など
https://sites.google.com/site/prj311/event
https://docs.google.com/spreadsheet/ccc?key=0An9ZuZLxj12adE9tUmxJbWdPcGM0OEFnX25IelBSeXc#gid=0
１．早野先生
ゼンリンマップと放射性物質拡散による甲状腺リスク（ヨウ素濃度）のマッピング
２．渡邊先生
東日本大震災アーカイブをGoogle Earth上に表示する を仕事でやってる
早野先生のデータや交通履歴データをGoogle Earth上にマッピング
マスメディアカバレージマップ
情報空白地域がある
３．NHKプロジェクト
広域災害における情報空白地域の課題
3つの空白
・情報空白（通信インフラ遮断）
・取材空白（交通インフラ遮断）
・認識空白
可視化＝マスメディアカバレージマップ
特定化＝
生存可能性の高い72時間以内の情報抽出・システム開発
映像情報のメタデータ化→書き起こし
市町村名ツイート×被災地域により、情報空白地域
位置情報から被害規模が検出できないか？
ホンダデータ
混雑統計データ
高精細な可視化とスカイマップ連動
４．Project MM×SM（Mass Media ＆ Social Media）
濱岡・慶応大学商学部 計量経済学
分析１：ツイートにおけるメディアへの言及
分析２：TV報道内容の分析 みんなが同じ情報を放送していた
製油所関連ツイート数の推移と報道タイミング
５．ユーザニーズとメディアデータのカテゴライゼーション 日立研究所 柳瀬さま
NHK総合テレビのカテゴリ占有率
情報提供内容は、緊急性・重要度により変化
人と情報とのマッチングを助ける
Twitterデータからユーザが欲した情報を知る→「教えてください」でGrep検索277,927件
傾向：安否確認のツイートが多そう
検証１：「安否」でgrep → 35169件
６．東大空間情報科学研究センター 有川先生、相良先生
ウェブ空間ドキュメント管理共有サービス（WebSDMSS）の震災応用
WebSDMSS→ 地名や住所を自動抽出、地図化
地名語辞書とジオパーサ
地名語辞書もユーザが目的に合わせて整備
今回は朝日新聞記事7379件の地名抽出処理結果をWebSDMSSに喰わせた
→詳しくはデモセッション
７．乾・岡崎研究室 意味的解析による災害情報拡散の分析
イソジンの例
情報（言論）時空間の分析・可視化
→信憑性分析、デマ判定
今回やったこと
トレンド分析：キーワードの盛り上がり
RT分析による影響力分析
命題抽出：賛否の分かれる意見・内容を抽出
命題の一生：デマとデマを否定するツイートの時系列的変化
言論マップ：ある言論に関する「賛成意見・判定意見及びその根拠」を俯瞰できるシステム
イソジンで被曝を防ぐについて
８．ハッシュタグ分析 東工大 村井
ハッシュタグを元に情報検索がされるが・・
問題点
・既存ハッシュタグの網羅的に知ることは困難
・新しく作られたハッシュタグの周知が困難
#jjhelpme → RTの上位８つは「このハッシュタグを使ってください」で終わってしまい、機能しなかった
#save_fukushima問題 →別表記が複数存在してしまう。異表記率の高いタグ上位は非公式RTによる
内容の近いハッシュタグの視覚化
時間の経過と共に地域毎のまとまりができる
９．チーム田中 トレンドキーワード抽出システム
増加する部分文字列（n-gram）を抽出すれば
１０．東工大 村田先生
Mentionネットワークの構築
中心性の高いユーザの発言分析など
１１．NICT 鳥澤さん
情報のキュレーション、組織間の連携方法、ユーザの高いリテラシが必要
→ビッグデータの活用法、技術
→本ワークショップの様なものに期待
災害対応質問応答システムと言論マップ
１２．CHIDRI
自分のとこなので省略
１３．高安研究室
コスモ石油爆発に起因するデマの拡散と収束
デマとデマ訂正
時系列解析
○不安の定量化
・顔文字数変異による不安の定量か
・怖いの検索
・ユーザ投稿過程の可視化
・マスコミ効果の測定
・揺れの大きさと書き込み数の変化
○ネットワーク解析
震災前後のRTネットワーク分析
１４． 広島市立大学
ツイートからの避難経路の抽出
マップデータ等による信頼性の担保
LDAによるツイートの自動分類
１５．日立東日本ソリューションズ 森川さん＆高梨さん
被災地で必要とされた情報をGoogle Trendsから分析
Google Trends 電気／ガス
各メディア上の情報間の連携については今後議論していきたい
１６．チームECB 震災後の首都圏の人口動態
ZENRINによる混雑データの利用
東京は3次元的にマップされるために、場所によって面積あたりの収容人数が違う
収容人数がオーバーした場所：震災時の混雑
収容人数が大きく下回る場所：経済活動の停滞
新宿(深夜・オフィスアワー）：震災8日後に回復
新宿（アフターファイブ）：震災25日後に回復
１７．野良分析チーム 首都圏における帰宅困難者のモデリング
○機械学習による帰宅困難者の発生地域抽出
帰宅しようとした人の意思決定をモデル化
・なぜ職場学校に待機しなかったのか？
・なにが要因で着たくしようとしたのか
○位置情報付きｔｗからの情報抽出
位置関係と時間をもっと上手に扱うには？
ユーザの推移行動の抽出
１８．渋谷プロジェクト
主要ターミナルの例として渋谷がどうなっていたのかを分析
背景:主要ターミナルに帰宅者が集中
・エリアメールや掲示板などを組み合わせることで、
一番混雑している地域がこれ以上混雑しないように人を誘導していく
目標：そのとき活用できる情報を用いて「使える」情報を提供
・普段からのイメージトレーニングが重要
・そのときできることをベストエフォートで
１９ 渋谷プロジェクト つぶやきのテキストマイニング分析
路線や駅毎の呟き数・内容を抽出分析
危険情報・地震直後の情報について抽出・分析
これらの分析結果をシーズとして使って頂きたい
２０．災害時における情報分析と共有 さくらインターネット研究所 松本さん
インフラ事業者としての立場からの分析
通信不通域と情報の発生域
キャリア毎に異なる不通地域と被災
原発周りや火力発電所周りで、2，3日後に復旧してたりする
同時海底ケーブルの集中破損が発生していた
大規模な通信迂回があった模様
現場復旧へ向けた取り組み
２１． 大災害時における特別な支援ニーズを持った被災者に対する情報提供に関するプロジェクト
Team UD（Universal Design)
発達障害支援センターのサイトがどのように見られていたかをGoogle Analyticsで分析
○どのようにツイートが拡散していったかを分析 RT・MT
・配慮や支援を呼びかけるツイートの拡散
・困っている・助けて欲しいツイートの拡散
・具体的な情報源を提供するツイート
信頼性の高いツイートがSurviveするためには、どのようにツイートすべきか？
○複数の同じような情報を与えるツイート
これらは有効に拡がったのか
同じ人達の間でぐるぐる回っていたのでは無いのか？
２２．災害時に流れる医療情報 知の構造化センター 荒牧さん
○分析方法
様々な情報から医療情報を抽出
辞書としてWHOの疾病分類を利用
○震災に増加した症状
1位：PTSD 通常時の70倍
30位：アレルギー 2.6倍
50位：血栓塞栓症 1.5倍（エコノミー症候群）
○マイノリティの発言に注目したい 非常に少ないが確かに発言数は増えている
7位：下垂体機能低下症の皆様へ 6.9倍
55位：クローン病 1.4倍
難病はそもそも人口が少ない
→災害時の大量の除法に隠れて舞う
医療版：流言クラウド
【妄想】東京電力が夏に向けてやるべきこと
電力会社では、夏の7月上旬〜9月上旬までを「夏期対」と呼びます。
これは、「夏期供給特別対策期間」（うろ覚え）の略で、
この期間は、需要が供給を逼迫するので、故障の場合を除き、
基本的には電力搬送用設備について作業・点検は禁止されます。
というわけで、周知の通り、今年の「夏期対」はやばい
2003年も福島第一、福島第二、柏崎が全て停止したので、やばかったが、
今回は、もっとヤバイ。
福島第一と福島第一と似たような大規模出力の鹿島・広野火力発電所が全部停止。
それ以外の中規模火力発電所も一部停止しているからである。
そもそも、原子力を建築するときは、止まってもいいように同じ規模の
代替火力発電所を建設するので、原子力が全部止まっても
ギリギリ何とかなるけど、大規模火力が止まるともうお手上げである。
で、まあこの現状に対して、政府・東電を批判する人は多数居るけど、
自分の信条として
「批判は何も生まない。これからどうするかを考えるべきだ」
というのがあるので、もし自分が東電の経営陣だったらどうするかを、
自分が東電に在職していたころの知識から妄想してみた。
まずは、発電部門。正常に稼働している発電所部門は、
故障が発生する可能性の高い部品を調べて、それをがんがんメーカーに発注だ。
と同時に、今の時期から点検出来るところは点検しておけ。
止まっている発電所の内、夏までに動かせそうな所は、
夏までの稼働が絶望的な発電所から人を引っ張ってきてもいいから、とりあえず早く直せ。
送電・変電・配電・通信の電力搬送部門（託送供給部門）も同じだ。
故障が発生する可能性の高い部品を調べて、それをがんがんメーカーに発注だ。
と同時に、今の時期から点検出来るところは点検しておけ。
次に法人営業部門。ここ10年で人を増やしまくって第一〜第五営業部まで作ったんだから、
とりあえず、全員総出で全需要家を回ってくる。
で、各需要家の電気主任技術者と代表責任者と話して、
・営業時間をシフトすることが可能か?どの程度シフト可能か？
・営業（稼働）するのに最低限必要な電力供給はどのレベル
を聞いてくる。すぐは無理だから4月中に回答を出してもらう。
あと、PPS（独立電気事業者）と相談して、
そっちに回せる需要家は全部そっちに回してしまえ。
で、それらの回答を取りまとめて､系統運用部に報告だ。
次に生活営業部門。本店の生活営業部門はハウスメーカーの人と協力して、
一般家庭を構成人数や設備環境（オール電化か、オールガス化など）から
20パターンくらいに分けて、各パターンが最低限生活するのに必要な
電力を割り出せ。
東京電力管内の家庭をおおざっぱな割合でいいからそのパターンに割り振って、
各家庭からの最小必要電力量を算出して系統運用部に報告する。
と同時に、各家庭の最低電力×１２０％程度の定格のNFB（ブレーカ）を大量にメーカーに発注する。
支店・支社の生活営業部門・料金部門・技術サービス部門は総出で
契約電力の大きい家庭順に回って、家族の構成人数と各家庭の設備を調べてくる。
系統運用部は法人営業部・生活営業部からの報告と、
夏に稼働可能な発電所、および他電力会社からの
融通量を含めて、なんとか納めるように、需要家毎の操業時間と
各家庭パターン毎に割り振る電力量を決めてしまえ
それでも足りなければ、
命に関わらなくて、かつ大規模な需要家から順に１０〜２０％程度削ってしまえ
この辺は人手でやると死ぬから、データマイニングの得意な研究者・
コンサルタント・シンクタンクなどと
協力して（GoogleやYahooと協力してもいいから）、コンピュータで自動的に算出
→その後人手で全部データチェックをやる。
で、その系統運用部門の決定を受けて、
法人営業と生活営業・料金・技サグループが動く。
法人営業部は、再度全需要家を回って、
・決定した操業時間での操業をお願いする
・最低供給電力量を主任技術者に報告する
をやってくる。
生活営業・料金・技サ（＋料金徴収のおばさん）は
今度は全家庭を回って、各家庭が取るべき節電行動パターンをお願いしつつ、
契約電力量が、先に算出した最低電力量を大幅に上回っている家庭の
NFB（ブレーカ）を最低電力量×１２０％のものに全部取り替えてしまえ。
これを全社あげて、本店の人間も現場に戻してやれば、
7月上旬の夏期対開始日に間に合うんじゃないだろーか。
以上、この前から考えている妄想でした。
wikipediaとはてなキーワードをmecabに取り込む話し
表題のとおり。
http://tmp.blogdns.org/archives/2009/12/mecabwikipediah.html
http://deepneko.dyndns.org/kokotech/2009/06/mecabwikipedia.html
以下のページを参考にさせていただきました。
はてなキーワードは自分で収集。
Wikipediaはwikimediaのページからダウンロード。
http://download.wikimedia.org/jawiki/latest/
辞書コンパイル時に以下を実行。
/usr/local/mecab/libexec/mecab/mecab-dict-index -d /usr/local/mecab/lib/mecab/dic/ipadic/ -u 辞書名 -f utf-8 -t utf-8 もととなるCSVファイル
作成した辞書でmecabを実行してみたが、どーもうまくいかない
mecab -u 辞書名
出力されるエラー：
tagger.cpp(245): tokenizer.cpp(163): incompatible dictionary:
と思ったら、/usr/local/etc/mecabrc のdicdir設定を確認して -d オプションでの指定場所を変えたらうまくいった
/usr/local/mecab/libexec/mecab/mecab-dict-index -d /usr/local/lib/mecab/dic/ipadic/ -u 辞書名 -f utf-8 -t utf-8 もととなるCSVファイル
なんでipadicが2箇所に入ってるんだ・・・
あとこの辺も「UTF-8」と書くか、「utf-8」と書くかでエラーが出たり出なかったりするらしい。
>-f utf-8 -t utf-8
うーむ
あとは英単語や数字のみの単語を入れると精度が悪くなったのでそれは除去した。
ってかこのエラーに２〜３時間ハマった・・・・
>tagger.cpp(245): tokenizer.cpp(163): incompatible dictionary:
Twitterのstatus_id 64bitに
実は11月5日から代わってたのか・・・・2週間以上気づかなかったorz
10月30日時点
http://twitter.com/kanadeelec/status/29170753398
11月5日以降
http://twitter.com/bsphysics/status/1459405631528960
64bit扱いなので、DBやプログラムで変数の型をdoubleとかにしてた人が死んでるかも知れない。
Javascriptだと53bitまでしか扱えないので、死ぬらしい。
11月26日以降はidが53bit以上になるので要注意らしい
TwitterAPIでは、id_str と言う項目を使えば、文字列で取得可能とかなんとか
詳しくは以下で。
ICWSM fullpaper まとめ ２日目
2日目：全体感想
本日は、分析研究多し。
でもTwitterの選挙予想とか意見抽出は、自分の研究室でも似たような研究をやっているし、
自分も興味あるので、結構面白かった。あと、ローカルニュースのほうがTwitter上では伝わりやすい、
という研究も面白かった。
JureさんのSocial Media Governanceの研究とユーザーのLifespanの研究（どうやったら、ユーザーの参加を維持できるか）
は良くできていた。
自分のPoster準備が忙しくてあまりうまくまとめられてないけど。
○17 Predicting Elections with Twitter: What 140 Characters Reveal about Political Sentiment
目的・背景：Social mediaを使った選挙での成功
Twongree
1.Twitterはプラットフォームになるか？
2. どれだけ有権者の意見を正しく伝えてくれるか
3. 選挙を予測できるか？
手法：立候補者名と政党名でTwitterを検索 LIWCというソフトを利用
サンプル ドイツの選挙
結論：31%が@を含む
19%がRetweet
ユーザーを選挙呟き発言回数で、分類 50%が一回だけ
LIWCで各呟きの感情、評価を分析
Leading candidateはだいたい同じ特徴を持つ
各連立グループごとに類似度を計算ー与党が一番高い
Twitterの政党名・候補者名を含む呟きの割合と選挙結果 ーーかなり一致。（９０％以上）
ただし、ドイツの選挙は政党選挙で、各候補者の当落まで予想しているわけではない。、
○148 From Tweets to Polls: Linking Text Sentiment to Public Opinion Time Series
目的：Public opinionをtwitterから測定する
手法：Text sentiment analysisと電話による世論調査との比較
Topic keywordsでtweetを抽出 economy,jobs,job,Obama,McCain,
Sentiment analysis word counting
結論： Twitterの分析でも世論調査と同じ様な結果が得られる。
○75 Information Contagion: an Empirical Study of the Spread of News on Digg and Twitter Social Networks
目的：Social media上での情報伝播について
手法： digg、twitter+tweetmemeを利用 tweetmeme最もRTされたURLをトップに表示
結論： Digー大体ニュースがでてから20時間位で反応
Twitter ーニュースがでてから1時間くらいで反応
Information flow on networks
Dig. Voteが増えるにつれて伝播スピードがあがる
Twitter. RTに関係なく、伝播していく
Digの方が、密でよりconnectedなネットワーク
Dig ニュースの伝播スピード早いけど、twitterほど遠くまでは達しない
○30 Tweeting from the Town Square: Measuring Geographic Local Networks
目的・背景：ケネディ暗殺のニュース1時間で80%の人に拡がったらしい。
Local newsのTwitter上での伝播測定
近所の人ならニュースが伝わる？？
手法：ローカルニュースと普通のニュースの伝播速度、伝播ユーザー数を比較
結論： ローカルニュースを呟いてるユーザーのネットワークは、普通のhash tagネットワークと比べてhigh density
24時間以内だとより高い。大体5倍くらい
上記ネットワークのcentralityの高い人は、地理的にも中心っぽい。
ニュースソースになっているユーザーはどのあたりにいるか？
本当にみた人、地元のラジオで働いている人、地元のジャーナリスト
ただし、FOXニュースでみた人もいる。このあたりがbias
○142 Governance in Social Media: A case study of the Wikipedia promotion process
目的：Social mediaのGovernanceについて。どのようにGovernanceすべきかを調査
手法：Wikipedia communityのメンバーの投票による、promotion決定プロセスにより調査
どのように意思決定がなされたか
結論：Relative merit が重要
Indivisuals' response functionの多様性
候補者と投票者の特徴の相対的な関係でどちらに投票するかが決まる
投票者が投票する時間も、投票者がどちらに投票するかに影響する。
感想：さすがJureさんの研究。よくまとまっている。
どう応用するかが難しいかな、とも思ってしまったけど。
○10 Activity Lifespan: An Analysis of User Survival Patterns in Online Knowledge Sharing Communities
目的：ユーザーのSurvival anasisys
どうしたら、ユーザーのparticipationを長期に維持できるか？？
手法：長期間にわたる、communityの進化について測定
また、違うトピックに関するsub-communityの成長も測定
結論：Incentive design, much of high level answers, initial. InteractionがユーザーのParticipation維持に重要
○39 Responses to remixing on a social media sharing website
目的：User generated mediaにおいて、remixは盗作と見なされるか否か？
Plagiarism accusation, hinting plagiarism positive, negative
手法：ScratchというOnlineCommunity上においてデータ分析
Projectの類似性とそれに対する批判の相関性を比較。
目的： Projectの内容にかかわらず、Projectが類似しているときに糾弾されやすい
