Provenienz und Versionierung für kleine Datensätze

Ziel

Jeder in einem Bericht verwendete Datensatz soll drei Fragen beantworten: Woher stammt er, was wurde mit ihm gemacht, und welche genaue Version hat diese Zahl erzeugt?

Voraussetzungen

Ein Repository für den Code, ein Speicherort für Dateien, die dafür zu gross sind, und die Regel, dass Rohdaten niemals an Ort und Stelle bearbeitet werden. Das W3C-PROV-Datenmodell liefert das Vokabular: Entitäten (Dateien, Tabellen), Aktivitäten (der Lauf eines Bereinigungsskripts), Akteure (eine Person oder ein Programm) sowie Beziehungen wie wasGeneratedBy, used, wasAttributedTo und wasDerivedFrom.

Schritte

1. Rohdaten unveränderlich in einem Verzeichnis oder Bucket raw/ ablegen; Dateien nach Quelle und Abrufdatum benennen und die genaue Herkunft (URL, Abfrage, Exporteinstellungen, wer sie geliefert hat) in einem README daneben festhalten.
2. Für jede Rohdatei eine Prüfsumme berechnen und speichern; spätere Verweise zitieren die Prüfsumme, nicht nur den Namen.
3. Ableiten statt überschreiben: Jede Transformation ist ein Skript, das eine Version liest und eine neue Datei schreibt; das Skript und seine Parameter sind die Provenienz des Ergebnisses.
4. Die Daten zusammen mit dem Code versionieren. Dateien, die dafür klein genug sind, werden direkt committet; für grössere Dateien wird ein Verweis committet. Der Einstiegsleitfaden von DVC zeigt, wie dvc add data/data.xml eine kleine .dvc-Datei mit dem Hash der Datei erzeugt, die von Git verfolgt wird, während der Inhalt in einen Cache und ein konfiguriertes Remote wandert. Git LFS folgt demselben Prinzip: Die Projektseite beschreibt, wie grosse Dateien innerhalb von Git durch Textverweise ersetzt werden, während der Inhalt auf einem Remote-Server liegt.
5. Das Paket beschreiben: Ein datapackage.json-Deskriptor nach dem Data-Package-Standard listet die Ressourcen mit ihren Pfaden und Lizenzen auf und enthält für tabellarische Dateien ein Table Schema (Feldnamen, Typen, Constraints, fehlende Werte), sodass Werkzeuge die Dateien validieren können und klar ist, was eine Spalte bedeutet.
6. Den für einen Bericht verwendeten Stand taggen: ein Git-Tag oder Commit-Hash, der Code und Datenverweise umfasst; diese Kennung im Bericht angeben.
7. Pro abgeleiteter Datei eine kurze Provenienznotiz in PROV-Begriffen schreiben, zum Beispiel clean.csv wasDerivedFrom raw/export-2026-09-01.csv; wasGeneratedBy clean.py@abc123; wasAttributedTo <agent>. Fliesstext genügt; das Vokabular sorgt für Konsistenz über Projekte hinweg.

Erwartetes Ergebnis

Jede Zahl in einem Bericht lässt sich auf einen Commit, eine Datenprüfsumme und ein Skript zurückführen; ein korrigierter Rohexport erzeugt eine neue Version statt einer nicht nachvollziehbaren Änderung.

Grenzen und Prüfbasis

Personenbezogene Daten und Lizenzen schränken ein, was gespeichert und weitergegeben werden darf; Provenienzeinträge dürfen nicht selbst zu einer Kopie geschützter Daten werden. Sehr häufige Aktualisierungen (Streams) benötigen eine Datenbank mit Audit-Historie statt Dateien. Der Arbeitsablauf folgt den zitierten Spezifikationen und der zitierten Dokumentation; zu seinem Aufwand wird keine Messung behauptet.