leeper / data-versioning

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

Versionskontrolle ist ein großer Teil der reproduzierbaren Forschung und Open-Source-Softwareentwicklung. Versionierung bietet eine vollständige Historie eines digitalen Objekts (z. B. eines Softwareprogramms, eines Forschungsprojekts usw.) und, was wichtig ist, ermöglicht es, zu verfolgen, welche Änderungen an diesem Objekt vorgenommen wurden, wann diese Änderungen vorgenommen wurden und (mit den entsprechenden Metadaten) warum diese Änderungen vorgenommen wurden. Dieses Dokument enthält einige meiner aktuellen Überlegungen zur Versionskontrolle für Daten.

Hintergrundkontext

Besonders in den Sozialwissenschaften sind Forschende auf große, öffentliche Datensätze angewiesen (z.B. Polity, Quality of Government, Correlates of War, ANES, ESS, etc.) als Quellenmaterial für quantitative Forschung. Diese Datensätze entwickeln sich normalerweise weiter (neue Daten werden im Laufe der Zeit hinzugefügt, Korrekturen an Datenwerten vorgenommen usw.) und neue Releases werden regelmäßig veröffentlicht. Manchmal handelt es sich bei diesen Daten um komplexe kollaborative Bemühungen (siehe z. B. Quality of Government), und bei anderen handelt es sich um öffentliche Veröffentlichungen von Datenerhebungsbemühungen einzelner Institutionen (z. B. ANES). Während kollaborative Datensätze einen offensichtlicheren Anwendungsfall für die Versionskontrolle darstellen, können Datensätze für einzelne Institutionen auch durch die Versionskontrolle verbessert werden. Dies ist besonders wichtig, da alte Versionen dieser wichtigen Datensätze häufig nicht archiviert werden (z. B. ANES), was bedeutet, dass es im Wesentlichen unmöglich ist, eine frühere Version eines bestimmten ANES-Datensatzes wiederherzustellen, nachdem eine neue Version aufgetreten ist. Dieser Beitrag soll das Nachdenken darüber lenken, wie die Erstellung verwaltet werden kann, Kuration, Revision, und Verbreitung dieser Art von Datensätzen. Während die Ideen hier auch für die Art und Weise gelten können, wie man über die Verwaltung seiner eigenen Daten nachdenkt, gelten sie wahrscheinlich eher in der Phase der Datenerstellung als bei der späteren Datennutzung, nachdem ein Datensatz im Wesentlichen vollständig oder eingefroren ist.

Überprüfung bestehender Tools und Ansätze

Das Open Data Institute hat einen schönen Beitrag veröffentlicht, in dem die Herausforderungen bei der Verwendung von standardmäßiger, softwareorientierter Versionskontrollsoftware (git) für die Versionskontrolle von Daten beschrieben werden. Das Hauptproblem ist, dass git, wie fast alle VCS, Änderungen an Zeilen in Textdateien überwachen soll. Dies ist sowohl für Code als auch für Artikel, Texte usw. sehr sinnvoll. Aber es beginnt weniger Sinn für digitale Objekte zu machen, wo eine Linie keine sinnvolle Einheit ist. Dies wird sehr deutlich, wenn wir anfangen, so etwas wie eine CSV-Datei (Comma-Separated Values) zu versionieren (wie im ODI-Beitrag beschrieben). Das Ändern eines einzelnen Datenfelds führt zu einer vollständigen Zeilenänderung, obwohl sich tatsächlich nur eine Zelle geändert hat. Ein ähnliches Problem tritt in XML, JSON oder anderen textgetrennten Formaten auf (beachten Sie jedoch, dass die Open Knowledge Foundation JSON als Speichermodus zu bevorzugen scheint).

Die Verwendung des Zeilenumbruchs \n als Trennzeichen zum Verfolgen von Änderungen an einem Objekt funktioniert für Daten. daff ist ein Javascript-Tool, das versucht, diese Schwäche auszugleichen. Es bietet einen Diff (Vergleich zweier Dateiversionen), der die Tabellenstruktur vieler Datendateien respektiert, indem zellspezifische Änderungen hervorgehoben werden. Dies ist jedoch kein vollständiges Versionskontrollsystem, sondern lediglich ein Diff-Tool, das als nützliches Add-On für Git dienen kann.

In einem Beitrag im Blog der Open Knowledge Foundation wird argumentiert, dass zeilenbasierte Änderungssätze eine gewisse Logik haben, da eine Standard-CSV (oder eine beliebige Tabellendatendatei) normalerweise eine einzelne Beobachtung in einer eigenen Zeile aufzeichnet. Eine zeilenbasierte Versionskontrolle ist dann sinnvoll, um Änderungen an Beobachtungen aufzuzeichnen (also Zeilen / Beobachtungen gegenüber Spalten / Variablen zu privilegieren).

dat möchte versuchen, ein „Git für Daten“ zu sein, aber der Status des Projekts ist etwas unklar, da Github nicht sehr aktiv entwickelt wurde. Ein Q / A zum Open Data StackExchange weist auf einige weitere Ressourcen für datengerechte Git-Alternativen hin, aber es gibt nichts Umfassendes.

Universal Numeric Fingerprint (UNF) bietet eine mögliche Strategie zur Versionskontrolle von Daten. In der Tat ist es genau das, wofür es entwickelt wurde. Es ist kein Versionskontrollsystem an sich, aber es bietet einen Hash, der nützlich sein kann, um festzustellen, wann sich ein Dataset geändert hat. Es hat einige nette Features:

  • Unabhängig vom Dateiformat (also besser als ein MD5)
  • Unabhängig von der Spaltenreihenfolge (ein Datensatz, in dem Spalten gemischt wurden, erzeugt denselben UNF-Hash)
  • Behandelt konsistent Gleitkommazahlen (Rundungs- und Genauigkeitsprobleme sind unproblematisch), Aber UNF ist nicht perfekt. Die Probleme umfassen:
  • Es ist sortierempfindlich (ein identischer Datensatz, der zeilensortiert ist, erzeugt eine andere UNF; daher werden Spalten / Variablen über Zeilen / Beobachtungen privilegiert)
  • Es gibt keine Behandlung von Metadaten (z., Variablennamen sind nicht Teil des Hashs)
  • Es ist sehr empfindlich gegenüber der Datenstruktur (z. B. „breite“ und „lange“ Darstellungen desselben Datensatzes erzeugen unterschiedliche UNFs)
  • Es ist kein Versionskontrollsystem und bietet im Wesentlichen keine Einblicke in das, was sich geändert hat, nur dass eine Änderung stattgefunden hat

Alle diese Tools konzentrieren sich auch auf die Daten selbst und nicht auf zugehörige Metadaten (z. B. das Codebuch, das die). Während einige Datenformate (z. B. proprietäre Formate wie Statas.dta und SPSS .2) kodieren Sie diese Metadaten direkt in der Datei, es ist kein gemeinsames Merkmal der meisten textgetrennten Datenstrukturen. Manchmal werden Codebücher unabhängig von Datenwerten geändert und umgekehrt, aber es ist wichtig zu sehen, dass große öffentliche Datensätze detaillierte Informationen zu Änderungen an den Daten oder am Codebuch bereitstellen, außer in gelegentlichen Releases.

Eine weitere große Herausforderung für die Datenversionierung besteht darin, dass die vorhandenen Tools Versionskontrolle sind nicht gut auf Provenance ausgelegt. Wenn Daten generiert, gespeichert oder geändert werden, verfügt ein softwareorientiertes Versionskontrollsystem über keinen offensichtlichen Mechanismus zum Aufzeichnen, warum Werte in einem Datensatz so sind, wie sie sind, oder warum Änderungen an bestimmten Werten vorgenommen werden. Eine Commit-Nachricht kann diese Informationen bereitstellen, aber sobald ein Wert erneut geändert wird, geht der Verlauf der Änderungen an einem bestimmten Wert im weiteren Verlauf der Datendatei als Ganzes verloren.

Es gibt also eindeutig keine vollständigen Tools zum Versionieren von Daten.

Einige Prinzipien der Datenversionierung

Das erste Prinzip der Datenversionierung ist, dass Änderungen an Daten Quellen oder Erklärungen haben. Ein System zur Datenversionierung muss in der Lage sein, Datenwerte, -strukturen und -metadaten (und Änderungen an diesen Features) mit Erläuterungen zu diesen Werten oder den Änderungen an Werten auf der Wertebene (und nicht auf der Ebene von Variablen, Beobachtungen oder Dateien) zu verbinden.

Das zweite Prinzip ist, dass die Datenversionierung wertebasiert sein sollte, nicht variabel oder beobachtungsbasiert. Ein System kann Beobachtungen nicht über Variablen oder Variablen über Beobachtungen privilegieren; Eine Änderung einer Beobachtung ist notwendigerweise eine Änderung einer Variablen und umgekehrt.

Das dritte Prinzip der Datenversionierung ist, dass Daten unabhängig von ihrem Format existieren. Wenn Sie einen Datenwert in einer CSV-Datei im Vergleich zu einer JSON-Struktur ändern, handelt es sich um inhaltsäquivalente Änderungen. Daher sollte jedes Versionskontrollsystem es Datennutzern ermöglichen, mit Daten in jedem von ihnen gewählten Dateiformat zu interagieren, ohne notwendigerweise das zugrunde liegende Datenspeicherformat zu verwenden.

Das vierte Prinzip der Datenversionierung ist, dass die Zusammenarbeit für die Datengenerierung und -pflege unerlässlich ist. Ein System zur Datenversionierung muss nativ kollaborativ sein und logisch aufzeichnen, wer Daten generiert und ändert.

Das fünfte Prinzip der Datenversionierung ist, dass Änderungen an der Datenstruktur unabhängig von Datenwerten aufgezeichnet werden sollten. Sortierreihenfolge der Beobachtungen, die Anordnung der Spalten / Variablen und die Anordnung der Zeilen als Fälle im Vergleich zu Falljahren usw. (also., „breite“ versus „lange“ Anordnungen) sind strukturelle Merkmale eines Datensatzes, nicht Merkmale der Daten an sich. Diese sind wichtig, aber ein Datenversionierungsprozess sollte in der Lage sein, eine Änderung des Inhalts eines Datensatzes von einer Änderung der Organisation oder Struktur eines Datensatzes zu unterscheiden und im letzteren Fall einen Datensatz, der auf zwei verschiedene Arten angeordnet ist, korrekt als identisch zu erkennen.

Das sechste Prinzip der Datenversionierung ist, dass Metadaten wichtig sind, aber wie die Struktur getrennt von Änderungen an Daten behandelt werden sollten. Zwei identische Datensätze mit unterschiedlichen Metadaten sollten als inhaltlich identisch erkannt werden.

Vorläufige Schlussfolgerungen

Daten sollten in einer Schlüssel-Wert-Weise gespeichert werden, wobei ein beliebiger Schlüssel einen bestimmten Datenwert enthält. Eine Zuordnung verbindet dann diese bestimmten Datenwerte sowohl mit Beobachtungen als auch mit Variablen, sodass jede Bewertung von Änderungen an Daten formatunabhängig und strukturunabhängig ist. Als solches wird eine Änderung eines Werts zuerst als Änderung eines Werts aufgezeichnet, kann aber sekundär als gleichzeitige Änderung sowohl einer Beobachtung als auch einer Variablen erkannt werden.

Jede Schnittstelle zu einem solchen Schlüsselwertspeicher sollte in einer vertrauten und flexiblen Form vorliegen: Benutzer sollten mit einem Datenversionierungssystem über die Art und Weise interagieren, in der sie derzeit Daten verwenden (z. B. einen Texteditor, eine Datenanalysesoftware, eine Tabellenkalkulationsanwendung usw.). Änderungen sollten in einer Masterdatei aufgezeichnet werden, die nativ und sofort aus jedem Datendateiformat (einschließlich getrennter Dateien, Tabellenkalkulationen, XML, JSON usw.) importiert und in dieses exportiert werden kann.).

Datenversionssysteme müssen über ein ausgefeilteres Commit-System verfügen, als es von aktuellen, softwareorientierten Versionskontrollsystemen bereitgestellt wird. Insbesondere sollten Commits nicht nur die Änderung eines Datenwerts, einer Struktur oder Metadaten aufzeichnen, sondern auch strukturierte Informationen, die diese Änderung erklären, einschließlich des Grunds für die Änderung, der Quelle (n) des Datenwerts und des Autors der Änderung. Im Wesentlichen sollten sowohl Changesets als auch Zustände der vollständigen Daten vollständig zitierfähig sein und zitierrelevante Metadaten enthalten.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.