まえしへの応援メッセージ†


↑

進捗†

↑

マイルストーン†

↑

進捗報告PPT†

↑

プログラムたち†

ろぎやまつしんが作ったプログラム

注意事項※

ファイルの命名規則は↓の通りです．***には年月(6桁)が入ります．命名規則に従っていない場合はプログラムは動作しません（きめうちなので）．

  • 開発者サブコミュニティ(略記:dev)　⇒　dev_***.net
  • ユーザサブコミュニティ(略記:user)　⇒　user_***.net
  • バグ報告者サブコミュニティ(略記:bug)　⇒　bug_***.net
  • 2つないし3つのサブコミュニティをマージしたもの(略記：merge)　⇒　merge_***.paj

分析に必要なデータ作成の大まかな流れ

  • 1．getRelationWithCluster.plでmboxからnetファイルを作成する．
    　　↓
  • 2．命名規則に従ってnetファイルをリネームする．(mboxから作成した段階では年月.netとなっているため)
    　　↓
  • 3．mergeNetworksByName.plで2つのサブコミュ二ティ(netファイル)をマージしてpajファイルを作成する．(3つのサブコミュニティをマージするときは伊原プログラムで)

↑は2つのサブコミュニティをマージするまでの工程．↓はコミュ二ティ媒介性をはかるための作業

  • 4．makePajekMacro4calculateDegreeCentrality.plをもとにPajekで中心性を計算するためのマクロファイルを作成する．(ノード重み付きコミュニティ媒介性で必要)
    　　↓
  • 5．Pajekでマクロファイルを読み込ませて中心性を計算する．　←　すぐに値が取れる．
    　　↓
  • 6．metricsWithNoWgt.pl，metricsWithEdgeWgt.pl，metricsWithNodeWgt.plを用いてそれぞれのコミュニティ媒介性を計算する．
    • NoWgtCB(重みなしコミュニティ媒介性)
    • EdgeWgtCB(エッジ重み付きコミュニティ媒介性)
    • NodeWgtCB(ノード重み付きコミュニティ媒介性)
↑

mboxからnetファイル(3ヶ月分)の作成†

filegetRelationWithCluster.pl　←　修正済

入力：mboxファイル

※3ヶ月分なら3つのmboxファイルが必要　e.g.) 200007 200008 200009

出力：netファイル

※↑の入力例だと200007.netというnetファイルができる

batファイルの例

  • perl getRelationWithCluster.pl 2000101 200102 200103
  • perl getRelationWithCluster.pl 2000102 200103 200104
    　　　　　・
    　　　　　・
    　　　　　・

修正・追加した点
1．mboxからメールアドレスを抽出するための条件の追加．　　e.g.)　 "名前 <メールアドレス　（名前）"　とかも取れるようにした
2．スパム対策の偽造（"@"が" at "になっている）部分の解除　←　特にGIMPの中期に多くある
3．↓のルールで同一人物を特定．(大文字は小文字に統一)

  • ルール1：メールアドレスが完全一致ならば，同一人物
  • ルール2：メールアドレスの@以前が一致　&&　From行にある名前が完全一致ならば，同一人物

4．ノード0問題の解決（たぶんf(^ ^;)）
5．自己ループの削除　(Pajekで処理してもよかったけどめんどかったのでプログラムで処理した)

↑

2つのnetファイルをマージするプログラム†

filemergeNetworksByName.pl

※このプログラムは特にいじっていない

入力：マージしたい2つのNetファイル

出力：Pajファイル(merge_***.paj)

batファイルの例

  • perl mergeNetworksByName.pl dev_200101.net user_200101.net
  • perl mergeNetworksByName.pl dev_200102.net user_200102.net
    　　　　　・
    　　　　　・
    　　　　　・
↑

中心性を計算するためのマクロファイル作成プログラム†

filemakePajekMacro4calculateDegreeCentrality.pl
filemakePajekMacro4calculateBetweennessCentrality.pl

※個人的に作ったので，他の人が使うときは編集して下さいm(_ _)m　(特にディレクトリ名とか)

使い方：perl makePajekMacro4calculateDegreeCentrality.pl ○○ △△ □□ ××

出力：次数中心性(ALL)を計算するためのマクロファイル

○○ = OSSコミュニティ名　e.g.)　apache,gimp,netscape など
△△ = サブコミュ二ティ名　e.g.)　dev，user, merge など
□□ = 期間(開始年月)　：　e.g.)　2000年7月からなら200007
×× = 期間(終了年月)　：　e.g.)　2007年5月で終了なら200705

↑

コミュニティ媒介性を計算するためのプログラム†

重みなしコミュニティ媒介性　：　filemetricsWithNoWgt.pl
エッジ重み付きコミュニティ媒介性　：　filemetricsWithEdgeWgt.pl
ノード重み付きコミュニティ媒介性　：　filemetricsWithNodeWgt.pl

※かなり頭の悪い作りなっているので要注意．
Partitionの割り当ては手動で(各プログラムの比較的上のほうに書いてある)，2番目，3番目の引数として与えたサブコミュニティ名に従って自分で編集すること．
e.g.) perl metricsWithNoWgt.pl merge_***.paj dev_***.net user_***.net
subCommunity_1(dev) = 1, subCommunity_2(user) = 2, andman = 3 なので

  • $subCommunity_1 = 1;
  • $subCommunity_2 = 2;
  • $andman = 3;

もし，dev_***.netとuser_***.netを入れ替えるなら，

  • $subCommunity_1 = 2;
  • $subCommunity_2 = 1;
  • $andman = 3;

※defaultでは，subCommunity_1 = 1(dev), subCommunity_2 = 2(user) になってる．

batファイルの例　※NoWgtとEdgeWgtの場合

  • perl metricsWithNoWgt.pl merge_200101.paj dev_200101.net user_200101.net
  • perl metricsWithNoWgt.pl merge_200102.paj dev_200102.net user_200102.net
    　　　　　・
    　　　　　・
    　　　　　・

batファイルの例　※NodeWgtの場合

  • perl metricsWithNodeWgt.pl merge_200101.paj dev_200101.net user_200101.net dev_200101.vec user_200101.vec
  • perl metricsWithNodeWgt.pl merge_200102.paj dev_200102.net user_200102.net dev_200102.vec user_200102.vec
    　　　　　・
    　　　　　・
    　　　　　・

※netファイル(subCommunity_1 subCommunity_2の順)の次に，vecファイル(subCommunity_1 subCommunity_2の順)を付け足す

↑

アンドマンのメール送信回数カウントプログラム(伊原研究用)†

filecountMailNum4Andman.pl

アンドマン同士のメッセージのやりとりが開発者コミュニティで行われたものか，ユーザコミュニティで行われたものかまで調べた上で，アンドマンのメール送信回数をカウントするプログラム

使い方：perl countMailNum4Andman.pl merge_***.paj subCommunity_1_***.net

出力：それぞれのサブコミュニティ参加者へのアンドマンのメール送信総数

e.g.)　andman⇒subCommunity_1の参加者へのメール送信総数
andman⇒subCommunity_2の参加者への送信総数
andman⇒subCommunity_1&2の参加者への送信総数

同様に，プログラムの350行目以降をコメントアウトすれば受信回数も分かる
ちょっと改良すればアンドマン個人個人の送信回数を求めることも可能．

■提案モデルのいうバランスについて　※バランスの解釈

　●量的な意味でのバランスのよさ

　2つのコミュニティに対しての交流人数や投稿回数に偏りがなく参加しているかどうか

　●質的な意味でのバランスのよさ

　2つのコミュニティに対して，それぞれのコミュニティにおいて重要だと考えられる人(中心性の高い人)とつながっているかどうかという点から，それぞれのコミュニティにおけるアンドマンの重要性に偏りがあるかどうか（みたいな）

※質的なバランスは少しオーバーな解釈かもしれないけど，一方のコミュニティでは重要な人とつながっていても，もう一方では重要でない人(中心性の低い人)としかつながっていない場合，2つのコミュニティにとってアンドマンの重要さ(重要視のされ方？)に違いがあるとも考えられるのではないかという気がした．

提案モデルでは，つながっている人の重要さ(中心性の値)に着目しているから，こんなことも言えるんじゃないかなと思った．

↑

シミュレーション結果と今後の課題点†

■指標の限界
シミュレーションの結果，モデルＩの結果がもっともよいものとなった．(モデルＧ，Ｈ，Ｉは重み付きである分値が大きくなる)
モデルＧとＩはともに上（黄色）のコミュニティから８回のレスをもらっていて，回数的には同じだけど，モデルＧのほうが一見バランスよく幅広い人と交流をしているから良さ気に見えてしまう ※要するに単純に重みをかけ合わせるという点に少し疑問点が見つかった．

直感に合わないのは，ＩのほうがＧと比べ，取得している情報がコミュニティの一部の人の声だと感じてしまうからだ

幅広い人との交流を重視するのであれば，重みを考えず実質的な交流人数を表す次数だけ見ればいい
重みをどうしても考えたいのであれば，(恣意的な方法ではあるが)対処法は2通り考えられる

個人的には重み情報も重要な要素だと考えているので，単純に中心性を足し合わせていくのではなく，アンドマンの幅広い交流（2つのコミュニティの網羅率）を反映させる形にもっていったほうがいい気がする．
※ここではうまく説明できないけど，情報取得にしても，それがコミュニティ全体の声なのかごく一部の人の声なのかといった網羅率として考えたい．それに網羅率として考えれば，正規化できるし値域も0〜1にすることができる

↑

疑問・問題点†

トップ   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS