![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
ゼミナールⅡ発表資料（α未満版）.ppt orz進捗報告6.ppt進捗報告5.ppt中間報告.ppt進捗報告4.ppt進捗報告3.ppt進捗報告2.ppt進捗報告1.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_v2.plで2つのサブコミュ二ティ(netファイル)をマージしてpajファイルを作成する．(3つのサブコミュニティをマージするときは伊原プログラムで)
↑は2つのサブコミュニティをマージするまでの工程．↓はコミュ二ティ媒介性をはかるための作業
- 4．makePajekMacro4calculateDegreeCentrality.plをもとにPajekで中心性を計算するためのマクロファイルを作成する．(ノード重み付きコミュニティ媒介性で必要)
↓- 5．Pajekでマクロファイルを読み込ませて中心性を計算する． ← すぐに値が取れる．
↓- 6．metricsWithNoWgt.pl，metricsWithEdgeWgt.pl，metricsWithNodeWgt.plを用いてそれぞれのコミュニティ媒介性を計算する．
- NoWgtCB(重みなしコミュニティ媒介性)
- EdgeWgtCB(エッジ重み付きコミュニティ媒介性)
- NodeWgtCB(ノード重み付きコミュニティ媒介性)
getRelationWithCluster.pl ← 修正済
入力：mboxファイル
3ヶ月分なら3つのmboxファイルが必要
e.g.) perl getRelationWithCluster.pl 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問題の解決
5．自己ループの削除 (Pajekで処理してもよかったけどめんどかったのでプログラムで処理した)
入力：マージしたい2つのNetファイル
e.g) perl mergeNetworksByName_v2.pl data1_***.net data2_***.net
出力：Pajファイル(merge_***.paj)
※注意事項
割り当てられるパーティション番号は引数の順番
Partition 1 : data1_***.net
Partition 2 : data2_***.net
Partition 3 : data1_***.netとdata2_***.netに共通して出現する人
batファイルの例
- perl mergeNetworksByName_v2.pl dev_200101.net user_200101.net > merge_200101.paj
- perl mergeNetworksByName_v2.pl dev_200102.net user_200102.net > merge_200102.paj
・
・
・
makePajekMacro4calculateDegreeCentrality.pl
makePajekMacro4calculateBetweennessCentrality.pl
※個人的に作ったので，他の人が使うときは編集して下さいm(_ _)m (特にディレクトリ名とか)
入力: OSSコミュニティ名，サブコミュ二ティ名，開始年月，終了年月
e.g) perl makePajekMacro4calculateDegreeCentrality.pl ○○ △△ □□ ××
○○ = OSSコミュニティ名 e.g.) apache,gimp,netscape など
△△ = サブコミュ二ティ名 e.g.) dev，user, merge など
□□ = 期間(開始年月) ： e.g.) 2000年7月からなら200007
×× = 期間(終了年月) ： e.g.) 2007年5月で終了なら200705出力：中心性を計算するためのマクロファイル(↑の例は次数中心性の場合)
重みなしコミュニティ媒介性 ： metricsWithNoWgt.pl
エッジ重み付きコミュニティ媒介性 ： metricsWithEdgeWgt.pl
ノード重み付きコミュニティ媒介性 ： metricsWithNodeWgt.pl
使い方: perl metricsWithNoWgt.pl merge_***.paj dev_***.net user_***.net
Partitionの割り当ては手動で(各プログラムの比較的上のほうに書いてある)，2番目，3番目の引数として与えたサブコミュニティ名に従って自分で編集すること．
↑の例では，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
・
・
・
※NodeWgtは，中心性の指標値が必要になるので，netファイル(subCommunity_1 subCommunity_2の順)の次に，vecファイル(subCommunity_1 subCommunity_2の順)を付け足す
アンドマン同士のメッセージのやりとりが開発者コミュニティで行われたものか，ユーザコミュニティで行われたものかまで調べた上で，アンドマンのメール送信回数をカウントするプログラム
入力: mergeしたpajファイルと2つのnetファイル
e.g.) perl countMailNum4Andman.pl merge_***.paj data1_***.net data2_***.net
出力：それぞれのサブコミュニティ参加者へのアンドマンのメール送信総数
e.g.) andman⇒subCommunity_1の参加者へのメール送信総数
andman⇒subCommunity_2の参加者への送信総数
andman⇒subCommunity_1&2の参加者への送信総数
同様に，プログラムの350行目(?)以降をコメントアウトすれば受信回数も分かる
ちょっと改良すればアンドマン個人個人の送信回数を求めることも可能．
※3-coordinator(3つのサブコミュニティに属する人のメール回数)については不可(要改良)
result.xlsmodel.zip■指標の限界
シミュレーションの結果，モデルＩの結果がもっともよいものとなった．(モデルＧ，Ｈ，Ｉは重み付きである分値が大きくなる)
モデルＧとＩはともに上（黄色）のコミュニティから８回のレスをもらっていて，回数的には同じだけど，モデルＧのほうが一見バランスよく幅広い人と交流をしているから良さ気に見えてしまう
※要するに単純に重みをかけ合わせるという点に少し疑問点が見つかった．
直感に合わないのは，ＩのほうがＧと比べ，取得している情報がコミュニティの一部の人の声だと感じてしまうからだ
幅広い人との交流を重視するのであれば，重みを考えず実質的な交流人数を表す次数だけ見ればいい
重みをどうしても考えたいのであれば，(恣意的な方法ではあるが)対処法は2通り考えられる
個人的には重み情報も重要な要素だと考えているので，単純に中心性を足し合わせていくのではなく，アンドマンの幅広い交流（2つのコミュニティの網羅率）を反映させる形にもっていったほうがいい気がする．
※ここではうまく説明できないけど，情報取得にしても，それがコミュニティ全体の声なのかごく一部の人の声なのかといった網羅率として考えたい．それに網羅率として考えれば，正規化できるし値域も0〜1にすることができる
開発にも積極的に取り組んで,ユーザの意見にも常に耳を傾け支援するめちゃくちゃしんどい人？
この場合媒介先のネットワークにどれだけ次数をはっているかをカウントして調べるだけでいい(実際に自分も議論に加わっているわけだから,つながっている先の重みとかはあまり必要ない．むしろ重みを考えると変にややこしくなる)
個人的には,開発の第一線でバリバリがんばっている人というよりかは,Documentation作成とか事務的な役割を追っている人がコーディネータになっていくような印象がある．(実際にApacheでは,コーディネータの何人かがDocumentationProjectに参加している人だったし・・・)
ネットワーク間を媒介するただの窓口(こんな意見をもらいましたよと単に伝達するだけ)になっている人？
この場合であれば，重みを考える必要がある．例えばネットワークA⇒Bの流れを考えたとき，Aでもらった意見をネットワークB内のノードNiが議論として取り上げているかは，Niの出次数を見れば何となく分かる(ような気がする)
ネットワークA⇒Bの流れを考えたとき，コーディネータとつながっているネットワークB内のノードNiが問題提起(要求)を投げかけたと考えると，このNiを中心に議論が行われれば出次数だけでなく入次数も多くなるはず． Input，OutputでなくAll(一度でも意見交流しとことのある人の数＝知り合いの数)で考えたほうがよいのでは？
例えばApacheのDeveloperとUserのネットワークで考えた場合，コーディネータとして多くのユーザと関わりを持っている(多くのユーザを支援し，多くの声に耳を傾ける)ことが好ましく，Developerに対しては，影響力のある(問題解決を図る上で問題に対して直接の関係者でかつリーダーシップがありそうな人につながっている)ことが好ましいと考えられる．
※極端なことを言えば，Linuxの開発ならエッジの数よりも開発リーダーで決定権のあるLinus Torvaldsにつながっているかどうかが重要になってくるだろうし・・・
ただ，バランスの悪いノード(入次数多で出次数少のノードとか)もいるわけだから，これらをタイプ別に分類(入・出次数の多少で4つのタイプに分類)して役割みたいなものを考えてみてもいいかも
次数のバランスからタイプ別に分類して，擬似的な役割みたいなもの(パーティション)を与えたときにネットワークがどう見えるのか？とかネットワークにおいてどのくらいの割合を占めているのかと見てみたら何か言えるのだろうか？
