Dateninfrastrukturen

6.3. Dateninfrastrukturen#

Story

Die Forschungsdaten des Projekts wurden kuratiert, sinnvoll benannt und in einer passenden und nachvollziehbaren Ordnerhierarchie strukturiert. (vgl. hierzu Kapitel Kuratierung & Organisation ) Diese Struktur kann direkt für den Upload der Daten in einem Repositorium übernommen werden. Der nächste Schritt ist die konkrete Publikation: Wie erstelle ich ein Repository? Wie lade ich die Daten hoch? Und wie stelle ich sicher, dass der Datensatz zitierfähig, versioniert und langzeitverfügbar ist?

      Forschungsprojekt
             │
             ▼
 📁 Daten organisiert
 📄 Dokumentiert
 🏷 Lizenziert
             │
             ▼
  🚀 Upload ins Repository
             │
             ▼
 🌍 Forschungsdatenpublikation

Infrastrukturen#

Für die Publikation von Forschungsdaten stehen unterschiedliche Infrastrukturen bzw. Repositorien zur Verfügung, die unterschiedliche Zwecke erfüllen:

  • GitHub + Zenodo : Versionierte Publikation mit DOI-Vergabe; geeignet für aktiv gepflegte Datensätze sowie kollaborative Arbeit → der vom Projekt gewählte primäre Weg

  • Refubium: Institutionelles Repositorium der Freien Universität Berlin für Langzeitarchivierung; für FU-Projekte empfohlen; Kontakt über die Universitätsbibliothek

  • FID Media (früher: media/rep): Fachrepositorium für Medienwissenschaft, betrieben an der Universität Marburg; geeignet für die fachspezifische Sichtbarkeit des Datensatzes

Für das vorliegende Projekt wurde GitHub als primäre Publikationsplattform gewählt, kombiniert mit Zenodo für die DOI-Vergabe sowie als zweiter externer Speicherort für die Archivierung und Sichtbarkeit der wissenschaftlichen Arbeit. Das Refubium der FU Berlin soll für die institutionelle Langzeitarchivierung genutzt werden. Es wird ebenso eine Publikation auf FID Media angestrebt.

Die nachfolgenden Schritte zeigen praxisnah und reproduzierbar, wie ein Repository auf GitHub (+ Zenodo) erstellt und veröffentlicht werden kann.

Hinweis: Plattform-Accounts

Hierzu wird sowohl ein GitHub-Account als auch ein Zenodo-Account benötigt. Beide Plattformen sind kostenlos und in den Digital Humanities etabliert.

GitHub-Upload: Technische Voraussetzungen#

Git lässt sich direkt über die Kommandozeile bedienen, das ist technisch möglich, aber für die meisten Anwendungsfälle eher umständliche, denn: jede Änderung wird sofort zu einem sogenannten Commit, was bei mehreren kleinen Korrekturen (Tippfehler, Formatierungen) schnell zu einer unübersichtlichen Versionsgeschichte führt. Wer an Dateien weiterarbeiten und mehrere Änderungen bündeln möchte, ist mit einer grafischen Oberfläche besser bedient.

Was ist ein Commit auf GitHub?

Ein Git-Commit ist ein permanenter Speicherpunkt und zeichnet Änderungen an einer oder mehreren Dateien auf. Git weist jedem Commit eine eindeutige ID zu. Damit wird Folgendes identifiziert:

  • Die jeweiligen Änderungen

  • Der Zeitpunkt der Änderungen

  • Wer die Änderungen vorgenommen hat

Mehr Informationen finden sich in Schritt 5 sowie auf der Dokumentationsseite von GitHub.

Unsere Empfehlung: GitHub Desktop für die Versionskontrolle und Visual Studio Code (VS Code) für die Bearbeitung der Dateien. Beide Tools sind kostenlos plattformübergreifend verfügbar und schnell erlernbar.

Schritt-für-Schritt: Repository erstellen und befüllen#

Schritt 1: GitHub-Account und Organisation einrichten#

  1. GitHub-Account erstellen unter GitHub

  2. Eine Organisation anlegen (z. B. SFB1512-C05-climate-film) oder sich als Member/Owner einer bestehenden Organisation mit den entsprechenden Zugriffsrechten eintragen lassen; zum Erstellen einer neuen Organisation rechts auf den Profil-Button klicken und anschließend auf → Organizations → New organization

../_images/abb_k06_new_organization_git.png

Fig. 6.7 Neue Organisation in GitHub erstellen#

  1. In der Organisation: New repository → Name, Beschreibung und Sichtbarkeit (Public/Private) festlegen → Repository erstellen

../_images/abb_k06_new_repository_git.png

Fig. 6.8 Neues Repository auf GitHub erstellen#

Einstellungen verwalten

Die README-Datei sowie LICENSE können auch nachträglich hinzugefügt werden. Es wird empfohlen die beiden Häkchen deaktiviert zu lassen.

Schritt 2: Repository klonen mit GitHub Desktop#

  1. GitHub Desktop öffnen und unter Settings mit dem GitHub-Account einloggen

  2. Anschließend auf File → Clone Repository gehen

  3. Unter dem Reiter GitHub.com das Repository auswählen (z. B. SFB1512-C05-climate-film/intervening-world-projections-dataset)

  4. Lokalen Speicherort wählen, z. B. ~/Documents/intervening-world-projections-dataset

  5. Auf Clone klicken

../_images/abb_k06_clone_repository_git.png

Fig. 6.9 Repository klonen mit GitHub Desktop#

Mehr Informationen und erste Schritte mit GitHub Desktop gibt es in der GitHub-Dokumentation.

Schritt 3: Ordnerstruktur anlegen in VS Code und Dateien hochladen#

Nach dem Klonen das Repository in VS Code öffnen (Open in Visual Studio Code in GitHub Desktop):

../_images/abb_k06_open_vs_code.png

Fig. 6.10 Das Repository in VS Code öffnen#

Dort sollte ebenfalls der GitHub-Account verknüpft werden. Hierzu links unten auf den Profil-Button klicken und einloggen.

Die Ordnerstruktur kann jetzt lokal angelegt werden, entweder durch Drag und Drop bereits vorbereiteter Ordner/Dateien oder durch Neuanlage direkt im Editor (vgl. Kapitel Kuratierung & Organisation zur empfohlenen Ordnerstruktur).

../_images/abb_k06_ordner_anlegen_vs_code.png

Fig. 6.11 Ordner und Dateien anlegen in VS Code#

Hinweis: Dateigrößen

GitHub ist keine Plattform für große Datenmengen. Die Obergrenze pro Datei beträgt 50 MB; Repositories sollten insgesamt 1 GB nicht überschreiten. Für größere Dateien (z. B. hochauflösende PNGs, Videos) gibt es zwei Alternativen:

  • Zenodo: Dateien direkt dort hochladen (max. 50 GB pro Record)

  • Git LFS (Large File Storage): Große Dateien über Git versionieren, ohne sie direkt im Repository zu speichern; erfordert jedoch zusätzliche Konfiguration!

Anschließend können die jeweiligen Dateien in ihre zugehörigen Ordner geladen werden.

Hinweis: Ordner für Bilder

Visualisierungen und Bilder, die Erklärungszwecken dienen, sollten in einen separaten Ordner, z. B. \assets, gelegt werden. So können sie von den eigentlichen Datensätzen getrennt werden.

Schritt 4: Dokumentationsdateien anlegen#

Einige Dateien werden von GitHub automatisch erkannt und besonders angezeigt, wenn sie im Wurzelverzeichnis (Root) des Repositories liegen und exakt so benannt sind:

  • README.md → wird als Startseite des Repositories gerendert (vgl. Abschnitt Dokumentation)

  • LICENSE → wird als Lizenzinformation erkannt und verlinkt (vgl. Abschnitt Lizenzierung)

  • CITATION.cff → wird als Zitationshinweis angezeigt (vgl. Abschnitt Daten zitierbar machen)

Für Dokumentationsdateien wie README.md oder LICENSE.md empfiehlt sich bei der Bearbeitung eine Live Preview im Editor. In VS Code lässt sich diese mit Cmd+Shift+V (macOS) bzw. Strg+Shift+V (Windows/Linux) öffnen. So ist sofort sichtbar, wie die Datei auf GitHub gerendert aussehen wird.

Schritt 5: Commit und Push#

Wenn alle Dateien bereit sind, können die Änderungen als Commit zusammengefasst und anschließend auf GitHub hochgeladen (Push) werden.

Wie bereits erwähnt, ist ein Commit ein gespeicherter Schnappschuss des Repositories zu einem bestimmten Zeitpunkt. Jeder Commit erhält eine kurze Beschreibung, die Commit Message, in der kurz und knapp dokumentiert werden sollte, was geändert wurde.

Der Commit kann entweder direkt über VS Code oder über GitHub Desktop durchgeführt werden.

Jeder Commit erhält eine kurze Beschreibung, die Commit Message, in der kurz und knapp dokumentiert werden sollte, was geändert wurde. In GitHub Desktop wird die Commit Message automatisch eingetragen, das Hinzufügen einer Beschreibung ist hier optional.

../_images/abb_k06_git_commit_message.png

Fig. 6.12 Commit Message über GitHub Desktop#

Über Commit to main können die Änderungen anschließend in das Repository auf GitHub übertragen werden.

In VS Code werden in der Quellcodeverwaltung die Änderungen angezeigt. Dort kann in der Spalte Änderungen die Commit Message eingetragen und mit Commit ausgeführt werden.

../_images/abb_k06_git_commit_message_vs_code.png

Fig. 6.13 Commit Message über VS Code#

Hinweis: Commit Message Konventionen

FÜr Commit Message empfiehlt sich die Verwendung oder Orientierung an Conventional Commits. Conventional Commits sind ein standardisiertes Verfahren zur Erstellung von Git-Commits.

Beispiele:

  • feat: add corpus metadata CSV

  • fix: correct country code for Geostorm

  • update: README.md with dataset description

Branches und Pull Requests#

Bei kollaborativer Arbeit an einem Repository, wenn also mehrere Personen gleichzeitig Änderungen vornehmen, empfiehlt sich die Arbeit mit sogenannten Branches und Pull Requests.

Ein Branch ist eine parallele Version des Repositories (quasi eine Abzweigung), in der Änderungen vorgenommen werden können, ohne das Hauptrepository (also main) zu beeinflussen. Ist die Arbeit abgeschlossen, so kann der Branch über einen Pull Request in den Hauptzweig zurückgeführt werden, jeweils immer mit der Möglichkeit, die Änderungen vorher zu überprüfen und zu kommentieren.

Zum Erstellen eines Branches im Repository den Reiter Branches öffnen und anschließend New branch auswählen. Nach Abschluss der Arbeiten im neuen Branch kann ein Pull Request erstellt werden. Hierzu entweder den Button Compare & pull request nutzen (dieser wird angezeigt, sofern Änderungen gegenüber main vorliegen) oder über Pull requests → New pull request den entsprechenden Branch auswählen und den Pull Request anlegen.

../_images/abb_06_branch_pull_request.png

Fig. 6.14 Ablauf: Branch und Pull Request erstellen auf GitHub#

Achtung: Aktuellen Stand überprüfen

Insbesondere bei einer kollaborativen Arbeit am Repository ist es ratsam, vor Beginn einer neuen Arbeitssitzung sicherzustellen, dass das lokale Repository dem aktuellen Stand des sogenannten Remote-Repositorys, also dem Repository auf GitHub, entspricht. Über GitHub Desktop kann hierzu zunächst die aktuelle Branch (z. B. main) ausgewählt und anschließend über Fetch origin geprüft werden, ob zwischenzeitlich Änderungen veröffentlicht wurden. Liegen Aktualisierungen vor, können diese über Pull origin in das lokale Repository übernommen werden, bevor die weitere Bearbeitung in VS Code erfolgt.

Weiterführende Links

Detaillierte Informationen zu Branches und Pull Requests gibt es auf den Dokumentationsseiten von GitHub:

​​Schritt 6: Release, Versionierung und DOI#

Wenn der Datensatz publikationsreif ist, wird ein Release erstellt, also eine benannte und getaggte Version des Repositories zu einem bestimmten Zeitpunkt. Releases folgen den Konventionen von Semantic Versioning (SemVer): MAJOR.MINOR.PATCH (z. B. v1.0.0, vgl. hierzu den Abschnitt Versionierung).

Anschließend kann über die Zenodo-GitHub-Integration auf Zenodo automatisch ein DOI für den Release vergeben werden.

  1. Zenodo-Account mit GitHub verknüpfen (hierzu in Zenodo neben dem Profil auf den Drop-Down-Pfeil klicken und in dem sich öffnenden Menü GitHub auswählen)

  2. Repository in Zenodo aktivieren

  3. Auf GitHub einen Release erstellen:

    • Im Repository Tags öffnen → Create a new release auswählen; dann bei Select a tag die Option Create a new tag wählen und einen Versions-Tag (z. B. v1.0.0) vergeben

    • Einen aussagekräftigen Titel sowie Release Notes hinzufügen, denn diese dokumentieren die wichtigsten Änderungen gegenüber vorherigen Versionen; für die Strukturierung der Release notes können beispielsweise Empfehlungen wie Keep a Changelog oder Conventional Commits herangezogen werden

../_images/abb_k06_new_release_git.png

Fig. 6.15 Einen neuen Release auf GitHub erstellen und taggen#

  1. Den Release anschließend veröffentlichen. Ist das GitHub-Repository mit Zenodo verknüpft, wird für den Release automatisch ein DOI generiert

  2. Den DOI in README.md, CITATION.cff eintragen

Schritt 7: Langzeitarchivierung und Fachrepositorien#

Wie bereits erwähnt, empfehlen sich nach der Erstpublikation auf GitHub und Zenodo die Inanspruchnahme weiterer Publikationsorte für die fachspezifische Sichtbarkeit sowie die Langzeitverfügbarkeit nach den FAIR-Prinzipien und den DFG-Leitlinien (Aufbewahrung mind. 10 Jahre):

  1. Institutionelles Repositorium, sofern von der Hochschule eines zur Verfügung gestellt wird

  2. Für film- und medienwissenschaftliche Forschungsdaten kann auf FID Media (früher media/rep) verwiesen werden. Es ist geeignet für die fachspezifische Auffindbarkeit des Datensatzes. Was bei der Einreichung beachtet werden sollte und welche Schritte hierfür nötig sind, kann in der Handreichung für Autor:innen – in fünf Schritten zur Publikation auf FID Media Publish eingesehen werden.

Weitere fachspezifische Repositorien können auf Repositorien-Findern wie re3data – Registry of Research Data Repositories sowie RIsources – Portal für Forschungsinfrastrukturen der DFG gesucht werden. Eine detailierte Auflistung von relevanten Repositorien und Repositorien-Findern in der Film- und Medienwissenschaft gibt es im Kapitel Ressourcen und Entscheidungshilfen.

Checkliste: Workflow Datenpublikation#

Fortschritt: 0 von 16