leeper/data-versioning

(c)Thomas J.Leeper(2015),licensed CC-BY

バージョン管理は、再現可能な研究とオープンソースソフトウェア開発の大部分です。 バージョン管理は、いくつかのデジタルオブジェクト(ソフトウェアプログラム、研究プロジェクトなど)の完全な履歴を提供します。)そして、重要なのは、そのオブジェクトに加えられた変更、それらの変更がいつ行われたか、そして(適切なメタデータを使用して)それらの変更が行われた理由を追跡することを可能にすることです。 この文書は、データのバージョン管理についての私の現在の考え方のいくつかを保持しています。

背景コンテキスト

特に社会科学では、研究者は大規模な公共データセット(政治、政府の質、戦争の相関、ANES、ESSなど)に依存しています。)定量的研究のためのソース材料として。 これらのデータセットは通常、進化します(新しいデータは時間の経過とともに追加され、データ値が修正されますなど)。)と新しいリリースが定期的に公開されています。 場合によっては、これらのデータは複雑な共同作業(例えば、政府の品質を参照)であり、他のものは単一機関のデータ収集努力(例えば、ANES)の公開リリースである。 共同データセットは、バージョン管理のためのより明白なユースケースを作成しますが、単一機関のデータセットもバージョン管理によって改善され これは、これらの重要なデータセットの古いリリースはアーカイブされないことが多いため(ANESなど)、新しいリリースが発生した後に特定のANESデータセットの前 この投稿は、これらの種類のデータセットの作成、キュレーション、改訂、および普及を管理する方法について考えることを促進することを意図しています。 ここでのアイデアは、自分のデータを管理する方法にも適用されるかもしれませんが、データセットが本質的に完了または凍結された後のデータ使用よりも、データ作成の段階でより多く適用される可能性があります。

既存のツールとアプローチのレビュー

Open Data Instituteは、データのバージョン管理に標準のソフトウェア指向のバージョン管理ソフトウェア(すなわち、git)を使用する 主な問題は、ほとんどすべてのVCと同様に、gitがテキストファイル内の行の変更を監視するように設計されていることです。 これは、コードだけでなく、記事、テキストなどにも多くの意味があります。 しかし、線が意味のある単位ではないデジタルオブジェクトにはあまり意味がありません。 これは、コンマ区切り値(CSV)ファイルのようなバージョンを開始すると本当に明確になります(ODIの投稿で説明されているように)。 単一のデータフィールドを変更すると、実際に変更されたセルが1つだけであっても、フルラインの変更が発生します。 XML、JSON、またはその他のテキスト区切り形式でも同様の問題が発生します(ただし、Open Knowledge FoundationはJSONをストレージモードとして支持しているようです)。

linebreak\nを区切り文字として使用して、オブジェクトの変更を追跡すると、データに対して機能します。 daffは、その弱点を補うためにしようとするjavascriptツールです。 これは、セル固有の変更を強調表示することにより、多くのデータファイルの表形式構造を尊重するdiff(2つのファイルバージョンの比較)を提供します。 これは完全なバージョン管理システムではありませんが、gitの便利なアドオンとして役立つdiffツールです。

Open Knowledge Foundationブログの投稿では、標準のCSV(または表形式のデータファイル)は通常、単一の観測値を独自の行に記録するため、行ベースの変更セットにはいくつかのロジックがあると主張しています。 行ベースのバージョン管理は、観測値の変更を記録するために理にかなっています(したがって、列/変数よりも行/観測値を特権化します)。

datは”データのためのgit”になろうとすることを目指していますが、Githubではあまり活発な開発が行われていないため、プロジェクトの状況は少し不明です。 Open Data StackExchangeのQ/Aは、データに適したgitの代替手段のためのいくつかのさらなるリソースを指していますが、包括的なものはありません。

Universal Numeric Fingerprint(UNF)は、データのバージョン管理のための潜在的な戦略を提供します。 確かに、それは具体的にそれが行うように設計されたものです。 これはバージョン管理システム自体ではありませんが、データセットがいつ変更されたかを判断するのに役立つハッシュを提供します。 それはいくつかの素晴らしい機能を持っています:

  • ファイル形式に依存しない(MD5よりも優れている)
  • 列順序に依存しない(列がシャッフルされたデータセットは同じUNFハッシュを生成します)
  • 浮動小数点数を一貫して処理します(丸めと精度の問題は問題ありません)が、UNFは完璧ではありません。 問題は次のとおりです。
  • ソートに依存します(行ソートされた同一のデータセットは異なるUNFを生成します。
  • メタデータの処理はありません(例: 変数名はハッシュの一部ではありません)
  • データ構造に非常に敏感です(例えば、同じデータセットの”ワイド”と”ロング”表現は異なるUNFsを生成します)
  • バージョン管理システムではなく、変更が発生したことだけが変更されたかについての洞察を本質的に提供しません

これらのツールはすべて、関連するメタデータ(例えば、データを記述するコードブック)ではなく、データ自体に焦点を当てています)。 いくつかのデータ形式(例えば、Stataのような独自の形式。dtaとSPSSの。sav)このメタデータをファイル内で直接エンコードしますが、広くテキスト区切りのデータ構造の一般的な機能ではありません。 コードブックはデータ値とは無関係に変更されることもありますが、大規模な公開データセットがデータまたはコードブックの変更に関する詳細な情報を提

データバージョニングに対するもう一つの大きな課題は、既存のツールのバージョン管理が出所を処理するためにうまく設計されていないことです。 データが生成、保存、または変更された場合、ソフトウェア指向のバージョン管理システムには、データセット内の値が何であるのか、または特定の値に変更が加えられた理由を記録するための明確なメカニズムがありません。 コミットメッセージはこの情報を提供する場合がありますが、値が再び変更されるとすぐに、特定の値への変更履歴はデータファイル全体の広範な履歴で失われます。

だから、データのバージョン管理のための完全なツールは明らかに存在していません。

データバージョニングのいくつかの原則

データバージョニングの第一の原則は、データへの変更にはソースまたは説明があるということです。 データのバージョン管理システムでは、データ値、構造体、メタデータ(およびそれらの機能への変更)を、変数、観測値、またはファイルのレベルではなく、値レベル

第二の原則は、データのバージョン管理は、変数ベースまたは観測ベースではなく、値ベースでなければならないということです。 システムは、変数に対するオブザベーションまたは変数に対するオブザベーションに特権を与えることはできません。

データのバージョン管理の第三の原則は、データはその形式とは無関係に存在するということです。 CSVとJSONツリーのデータ値を変更した場合、それらはコンテンツと同等の変更です。 そのため、バージョン管理のシステムでは、データユーザーが基本となるデータストレージ形式を使用せずに、選択したファイル形式でデータを操作できるようにす

データバージョニングの第四の原則は、コラボレーションがデータ生成とキュレーションに不可欠であるということです。 データのバージョン管理のシステムは、データを生成および変更するユーザーをネイティブに共同で論理的に記録する必要があります。

データバージョン管理の第五の原則は、データ構造への変更は、データ値とは無関係に記録されるべきであるということです。 観測値の並べ替え順序、列/変数の配置、ケース対ケース年としての行の配置など (すなわち”広い”対”長い”配置)は、データセットの構造的特徴であり、データ自体の特徴ではありません。 これらは重要ですが、データのバージョン管理プロセスでは、データセットの内容への変更とデータセットの組織や構造への変更を区別でき、後者の場合は、2つの異なる方法で配置されたデータセットが同一であることを正しく認識できる必要があります。

データのバージョン管理の第六の原則は、メタデータが重要であるが、構造のように、データの変更とは別に処理する必要があるということです。 異なるメタデータを持つ2つの同一のデータセットは、コンテンツ同一として認識する必要があります。

暫定的な結論

データは、任意のキーが特定のデータ値を保持するキーと値の方法で格納する必要があります。 マッピングは、これらの特定のデータ値を観測値と変数の両方に接続するため、データへの変更の評価は形式に依存せず、構造に依存しません。 したがって、値への変更は、最初に値への変更として記録されますが、二次的に観測値と変数の両方への同時変更として認識することができます。

このようなキー-バリュー-ストアへのインターフェイスは、使い慣れた柔軟な形で提供されるべきであり、ユーザーは現在データを使用している方法(テキストエディタ、データ分析ソフト、スプレッドシートアプリケーションなど)を介してデータ-バージョン管理システムと対話する必要があります。). 変更は、任意のデータファイル形式(区切りファイル、スプレッドシート、XML、JSONなどを含む)からネイティブかつすぐにインポートおよびエクスポートできるマスターフ).

データバージョニングシステムは、現在のソフトウェア指向のバージョン管理システムよりも高度なコミットシステムを持っている必要があります。 特に、コミットは、データ値、構造、またはメタデータへの変更だけでなく、変更の理由、データ値のソース、変更の作成者など、その変更を説明する構造化情報も記録 本質的には、完全なデータの変更セットと状態の両方が完全に引用可能であり、引用関連のメタデータを保持する必要があります。

コメントを残す

メールアドレスが公開されることはありません。