FAIR in der Praxis – erster Beitrag
von Kerstin Jung
FAIR ist in aller Munde, wenn es um Forschungsdatenmanagement geht. Die Abkürzung steht für „Findable“ (auffindbar), „Accessible“ (zugänglich), „Interoperable“ (interoperabel) und „Reusable“ (wiederverwendbar) und basiert auf einer Publikation von Wilkinson et al. (2016) im Rahmen von FORCE11.
Es wird von FAIRen Daten, FAIRen Metadaten, FAIRen Services und FAIRem Vokabular gesprochen, und überall dort, wo diese Grundsätze umgesetzt werden sollen, die letztlich der Wiederverwendbarkeit, Überprüfbarkeit und Vergleichbarkeit von Datensätzen und Ergebnissen dienen, ist ein „FAIRification process“ im Gange.
In dieser Serie von Beiträgen möchten wir uns mit der Anwendung der Prinzipien in unserem Fachbereich beschäftigen und die Frage, die an uns herangetragen wurde, beantworten, wie man von Anfang an die richtigen Weichen stellt, um die FAIR-Aspekte in den eigenen Workflow einfließen zu lassen.
Dazu beginnen wir beim letzten Buchstaben der Abkürzung, beim R für Wiederverwendbarkeit. Während für die anderen Aspekte meistens im Laufe der Arbeit Entscheidungen getroffen oder Daten passend konvertiert werden können, spielt es für die Wiederverwendbarkeit eine essentielle Rolle, dass die Abläufe der Datenverarbeitung vom ersten Tag an dokumentiert werden. Wir beziehen uns hierbei auf Aspekt R1.2:
R1.2 (Meta-)Daten sind mit detaillierten Informationen über die Entstehung versehen.
Um wirklich zu wissen, ob ein Datensatz für die Nachnutzung bezüglich einer eigenen Forschungsfrage geeignet ist, oder ob die eigene Studie zu einer anderen vergleichbar ist, spielt es eine große Rolle, wie die Daten vor der Veröffentlichung der Datensätze oder Ergebnisse verarbeitet wurden.
Dabei spielen insbesondere die kleinen Entscheidungen, die man beim Umgang mit Daten tagtäglich trifft, eine wichtige Rolle, da eine Entscheidung, die für die eigene Forschungsfrage ohne Auswirkung auf die Ergebnisse beliebig getroffen werden kann, ggf. Einfluss auf die Verwendbarkeit in einem anderen Kontext haben kann.
Werden zum Beispiel zur Unterstützung der automatischen Verarbeitung eines großen Textkorpus Sätze ab einer bestimmten Länge gestrichen oder Rechtschreibfehler entfernt, ist es wichtig, dies vor der Nachnutzung zu wissen um keine statistischen Aussagen über Satzlänge oder Anzahl von Rechtschreibfehlern zu treffen, und Kontextanalysen nicht über Sätze hinweg durchzuführen.
Wichtig dabei ist, dass es nicht darum geht, dass die Erstellenden des Datensatzes sämtliche mögliche Nachnutzungszenarien erhalten, sondern dass Entscheidungen ausreichend dokumentiert werden, so dass potentielle Nachnutzende eigenständig entscheiden können, ob sich die Ressource für ihren Zweck eignet.
Es sind allerdings genau diese kleinen Entscheidungen, die selten dokumentiert werden und aus Platz- oder Fokusgründen nicht in Publikationen auftauchen.
Daher ist die konsequente und konstante Mitführung von Prozessmetadaten, d.h. Informationen über alle Verarbeitungsschritte im Detail, ein entscheidendes Prinzip auf dem Weg zu einer nachhaltigen Dokumentation.
Dabei sollte Folgendes für jeden Schritt dokumentiert werden:
- Informationen zu den Ausgangsdaten
- Auf Grundlage welcher Daten wird der Schritt durchgeführt?
- Auf welche Version des Ausgangsdatensatzes bezieht sich der Schritt?
- Informationen zur Operation auf den Ausgangsdaten
- Welche Operation wird durchgeführt? (Analyse, Selektion, Interpretation, …)
- Ist es eine manuelle, automatische oder semi-automatische Operation?
- Wer oder was führt die Operation aus?
- Im Fall von Person(en): Name / Kürzel / ID + Datenschutz bedenken
- Im Fall von Tool(s): Name / ID + Version + Einstellungen und Parameter + ggf. Information über Betriebssystem / Hardware, falls dies Einfluss auf die Ergebnisse haben könnte
- Welche zusätzlichen Komponenten werden genutzt?
- Komponentenbeschreibung (Annotationsrichtlinien, Lexikon, trainierte Modelle, etc.)
- Komponentenidentifikation: Name + Versionsnummer
- ggf. Zusammenhänge zu weiteren Ressourcen („Auf welcher Version welches Korpus wurde das Modell trainiert?“, etc.)
- Informationen zu neu entstandenen Daten
- Sind aus dem Schritt neue Daten entstanden? (Subkorpus, Annotationsebene, …)
- Falls ja, Identifikator (= Name und Version) anlegen, um diese Daten wiederum als Ausgangsdaten für weitere Schritte benennen zu können
Die Nutzenden sind natürlich frei in der Auslegung ihrer Schritte, z.B. was ein Schritt ist und was als mehrere Schritte betrachtet wird. Ebenso kann eine Komponente wie z.B. ein Lexikon auch als zusätzliches Ausgangsdatum betrachtet werden, auf dem der Schritt aufsetzt. Wichtig ist dabei nur, dass alle Datensätze, Tools und Komponenten eindeutig identifiziert werden können, was erfahrungsgemäß eine geeignete Versionierung einschließt, denn die wenigsten Schritte werden im Forschungsprozess wirklich nur einmal ausgeführt.
Des weiteren müssen natürlich nicht alle Daten aus den Zwischenschritten gespeichert und archiviert werden. Insbesondere, wenn sich Daten mit den gleichen Abläufen wiederherstellen lassen, kann eine gute Prozessdokumentation auch Speicherplatz für die Daten der Zwischenschritte einsparen.
Zu bedenken ist, dass Metadaten öffentlich sein sollten, dies gilt auch für Prozessmetadaten. Damit ist nicht gemeint, dass sie sofort veröffentlicht werden, sondern dass keine Informationen enthalten sind, die Zugangsrestriktionen unterliegen. Damit wird sichergestellt, dass man auch Informationen über Ressourcen nutzen kann, bei denen die eigentlichen Daten zugangsbeschränkt sind. Dies erhöht zum einen die Transparenz der Ergebnisse und ermöglicht zum anderen eine Vergleichbarkeit von Ergebnissen, wenn andere Forschende die gleichen Abläufe auf vergleichbaren Datensätzen ausführen.
Ein zweiter Punkt der Zugänglichkeit von Metadaten ist die Erwähnung von Personen. Bei der Angabe von Akteuren müssen sowohl Aspekte der Anerkennung von Leistungen als auch des Schutzes von Probanden oder Annotatoren berücksichtigt werden.
Ein wichtiger Aspekt, der unseren Fachbereich von vielen anderen unterscheidet, ist die Rolle von manuellen Verarbeitungsschritten. Selektion, Anreicherung, Explizitmachung und Interpretation sind wichtige Schritte, die im technischen Ablauf nicht automatisch Spuren hinterlassen, die von einem System mitgeschrieben werden können. Auf diese Schritte, deren Beschreibung durchaus über ein rein maschinenlesbares Metadatenformat hinausgehen kann, muss besonders geachtet werden.
Prinzipiell gibt es mehrere Schemata, mit denen man Prozessmetadaten abbilden kann. Auch in Objektmetadatenschemata wie dem TEI Header oder seiner Ausprägung für LAUDATIO können Teile der Prozessmetadaten abgelegt werden.
Ein von der W3C standardisiertes Schema ist das PROV Datenmodell, welches den Fokus auf die Entstehung eines bestimmten Objekts legt.
Liegt der Fokus auf den sich ggf. auch verzweigenden Abläufen, kann z.B. das RePlay-DH Prozessmetadatenschema verwendet werden.
Aber auch Metadaten aus anderen Fachgebieten können offen genug sein, um manuelle sowie automatische Schritte abzulegen. Vgl. z.B. EngMeta.
Eine automatische Unterstützung bei der Erfassung der Prozessmetadaten ist wünschenswert aber kann nicht immer alle Aspekte der Arbeitsabläufe abdecken. Idealerweise fragt ein System nach, wenn Daten erzeugt werden, für die kein automatisierter Schritt erkennbar ist.
Ein Tool in der Testphase ist der RePlay-DH Client, der obiges Schema verwendet und im Hintergrund mit einem git-System arbeitet.
Wer für die Arbeitsabläufe ein System wie z.B. GitLab oder GitHub verwendet, kann Vorlagen für „commit“-Nachrichten erstellen, so dass die Bearbeitenden bei jedem Einfügen neuer Daten(versionen) ein leeres Prozessmetadatenschema vorfinden, das sie bei Bedarf ausfüllen können.
Und wer sich nun letztlich fragt, ob die eigenen Prozessmetadaten ausreichen sind, kann als Leitfaden die Testfrage stellen, ob jemand, der das Projekt nicht kennt, mit den gespeicherten Angaben den Ablauf eigenständig durchführen könnte.
Wilkinson, M., Dumontier, M., Aalbersberg, I. et al. The FAIR Guiding Principles for scientific data management and stewardship. Sci Data 3, 160018 (2016). https://doi.org/10.1038/sdata.2016.18