[論文レビュー] A Dataset for GitHub Repository Deduplication: Extended Description

Diomidis Spinellis, Zoe Kotti+1 more|arXiv (Cornell University)|Apr 21, 2020

Software Engineering Research参考文献 32被引用数 3

ひとこと要約

この論文は、フォークやクローン操作を通じて同定された1060万件のGitHubプロジェクトのデータセットを紹介する。各プロジェクトは、1820万ノードと1200万エッジのノイズ除去済みグラフを介して、その最終親レポジトリにリンクされている。手法は6つの指標とパターンマッチングヒューリスティクスを用いてクラスターをフィルタリングし、連結成分を計算することで、主要な参照データセット内で3万件の重複を特定した。これは独立したデータセットと比較した場合、強い一致を示しながらも、差異も確認された。

ABSTRACT

GitHub projects can be easily replicated through the site's fork<br> process or through a Git clone-push sequence. This is a problem for<br> empirical software engineering, because it can lead to skewed results<br> or mistrained machine learning models. We provide a dataset of 10.6<br> million GitHub projects that are copies of others, and link each record<br> with the project's ultimate parent. The ultimate parents were derived<br> from a ranking along six metrics. The related projects were calculated<br> as the connected components of an 18.2 million node and 12 million<br> edge denoised graph created by directing edges to ultimate parents.<br> The graph was created by filtering out more than 30 hand-picked and 2.3<br> million pattern-matched clumping projects. Projects that introduced<br> unwanted clumping were identified by repeatedly visualizing shortest path<br> distances between unrelated important projects. Our dataset identified<br> 30 thousand duplicate projects in an existing popular reference dataset<br> of 1.8 million projects. An evaluation of our dataset against another<br> created independently with different methods found a significant overlap,<br> but also differences attributed to the operational definition of what<br> projects are considered as related.

研究の動機と目的

• 実証的ソフトウェア工学の研究や機械学習モデルに歪みをもたらすGitHubレポジトリの重複問題に対処すること。
• グラフベースのアプローチを用いて、1060万件の重複プロジェクトをその最終親レポジトリに同定・リンクすること。
• 30件の手動選択および230万件のパターンマッチングによるクラスタをフィルタリングすることで、プロジェクトのクラスタリングに起因するノイズを低減すること。
• 既存の180万件のプロジェクトから構成される参照データセット内で3万件の重複を検出することで、データセットの正確性を検証すること。
• 独立して作成されたデータセットと比較することで、一貫性および運用定義の差異を評価すること。

提案手法

• 6つのランク付け指標に基づいてエッジをプロジェクトからその最終親に方向付けることで、1820万ノード、1200万エッジのグラフを構築した。
• ノイズを低減するため、30件の手動選択および230万件のパターンマッチングによるクラスタリングプロジェクトを同定・フィルタリングした。
• 関係のない重要なプロジェクト間の最短経路距離の可視化を用いて、不要なクラスタを検出し、削除した。
• ノイズ除去済みグラフにおける連結成分を計算し、同じ最終親を持つプロジェクトをグループ化した。
• プロジェクトの特性に基づいて、各プロジェクトの最終親を特定するためのマルチ指標ランク付けシステムを適用した。
• 既存の180万件のプロジェクトから構成される参照データセット内で3万件の重複を検出することで、データセットを検証した。

実験結果

リサーチクエスチョン

• RQ1 フォークやクローンによって他のプロジェクトと重複するGitHubプロジェクトはどれくらいの数にのぼり、既存の参照データセットにどの程度含まれているか？
• RQ2 提案されたグラフベースの重複除去手法は、プロジェクトのクラスタリングに起因する誤検出をどの程度低減するか？
• RQ3 異なる運用定義を用いて作成された独立したデータセットと比較した場合、重複除去の結果はどの程度一貫しているか？
• RQ4 手動選択およびパターンマッチングによるクラスタのフィルタリングは、最終親の同定精度にどのような影響を与えるか？
• RQ5 180万件のプロジェクトから構成される大規模で現実世界の参照データセットにおいて、このデータセットは重複をどの程度うまく検出できるか？

主な発見

• 広く使われている180万件のプロジェクトから構成される参照データセット内で、3万件の重複プロジェクトが同定された。これは、顕著な重複率を示している。
• 本データセットと独立して作成されたデータセットとの間に顕著な重複が確認された。これは、重複関係の同定に高い堅牢性があることを示唆している。
• 重複の存在は認められたが、関連プロジェクトの定義が異なる運用定義の差異により、差異が観察された。
• 230万件のパターンマッチングおよび30件の手動選択クラスタのフィルタリングにより、重複除去プロセスのノイズが顕著に低減された。
• グラフベースのアプローチにより、ノイズ除去され、指標に基づいたネットワークを介して1060万件のプロジェクトがその最終親に正しくリンクされた。
• 関係のない重要なプロジェクト間の最短経路距離の可視化は、不正なクラスタの同定および削除に効果的であった。