Interview mit Robin Lenz vom Leibniz Institut für Polymerforschung Dresden, dem Preisträger 2024.
Den größten Nutzen von gut gemanagten Daten haben wir also vermutlich selbst. Unsere Daten anschließend offen zugänglich zu machen, ist dann kaum Mehraufwand.
Worum ging es bei Ihrem eingereichten Datensatz?
Eingereicht habe ich einen Datensatz und -viewer zur spektroskopischen Charakterisierung von in der marinen Umgebung natürlich verwitterten Polymeren. Sie gehören zum JPI Oceans: microplastiX-Projekt, das Auswirkungen von Mikroplastik in Meeresökosystemen untersucht.
Gab es Schwierigkeiten bei der FAIRen Speicherung der Daten?
Keine unerwarteten. Ich hatte mich vorher schon mit dieser Thematik beschäftigt. Für mich ist es der beste Weg zu arbeiten, in neuen Projekten werden wir auf jeden Fall von Anfang an FAIR planen.
In der Vergangenheit habe ich an einem Projekt mitgearbeitet, das nicht FAIR angefangen hat und es auch nicht notwendig war, das war im Endeffekt aber anstrengend. Wir hatten damals am Ende viele unübersichtliche Versionen von Excel-Dateien und Word-Dokumenten und ich habe gemerkt, dass es schwierig wird, so zu einem guten Ende zu kommen.
Im jetzt eingereichten Projekt haben hier Daten-Sammlungen von mehreren Instituten. Das kann man nicht einfach zusammenwerfen: zuerst muss alles auf einen Stand gebracht werden. Und wenn ich das schon für mich machen muss, um einen Überblick über die Daten zu bekommen, dann kann ich es auch gleich so machen, dass es für alle nachvollziehbar ist.
Warum haben Sie sich für GitHub als Repositorium entschieden?
Ich arbeite sehr viel mit Python, um Visualisierungen zu machen, Daten zu formatieren und vieles weitere. Dabei habe ich zum einen sehr viele CSV-Dateien mit den Dateninhalten, und daneben viele Python-Skripte, die etwas mit diesen CSV-Dateien tun.
Da bietet es sich an, die Software-Entwicklungsschiene der Git-Technologie zu nutzen. Außerdem wollte ich die Daten am Ende gerne auf Zenodo stellen, was gut mit GitHub integriert ist.
Aufgrund des Umfangs ist es aber gar nicht mehr meine bevorzugte Variante, Code und Daten gemeinsam in einem Repository zu hosten.
Was wäre Ihre Lieblingsvariante?
Zukünftig möchte ich das getrennt halten. Bei diesem Projekt habe ich die rein chemischen Daten, also Spektren mit ihren Beschreibungen und Metadaten, später auf RADAR4Chem deponiert, weil sie da unabhängig vom Code auffindbar sind für die chemische Community und so vielleicht auch weiter genutzt werden können.
Sinnvoller wäre, es gleich von Anfang an so zu verfolgen: die Daten in einem chemischen Repositorium und den Code in einem GitHub-Repository, was dann auch über Zenodo versioniert sein kann, sodass man sich auf eine bestimmte Version beziehen kann.
Außerdem würde es auch gar nicht mehr anders gehen, wenn das Projekt deutlich größer wäre, mit mehr CSV-Dateien oder großen Messdaten, die Gigabyte füllen. Das kann man nicht mehr sinnvoll in einem Code-Repository mitführen.
Da bin ich gerade am Puzzeln, wie man das sinnvoll verbinden kann, so dass in dem Moment, wenn man den Code ausführt, dieser die Abfrage auf dem chemischen Repository ausführt und sich die Daten dort holt, anstatt dass sie als Kopie beim Code liegen. Darüber habe ich auch mit den Leuten von RADAR4Chem gesprochen. So eine Abfrage scheint technisch etwas aufwendiger, sollte aber prinzipiell möglich zu sein. Dann hätte man für jede Art von Daten, also Code und chemische Daten einen eindeutigen Ort, das wäre die sauberste Lösung.
Verwenden Sie im Team Datenmanagementpläne (DMP)?
In dem Projekt, aus dem diese Veröffentlichung entstanden ist, gab es einen, ja. Generell nutzen wir ein elektronisches Labnotebook (ELN), hier im Institut ist das LabArchives. Und wir haben ein zentrales Rohdaten-Laufwerk und Festlegungen, was wo gespeichert wird. Insofern gibt es eine technische Infrastruktur und gruppeninterne Routinen, die man in einen DMP schreiben könnte.
Entschieden wird dann projektbezogen je nach den Erfordernissen, ob ein DMP-Dokument verfasst wird oder nicht.
Warum haben Sie sich auf den FAIR4Chem-Preis beworben?
Die Info über die Ausschreibung kam von einem Data Scout hier am Institut. Wir waren eigentlich noch nicht so weit, die Daten waren auch noch unter Embargo. Aber dann habe ich nachgefragt, die Freigabe bekommen und eingereicht. Anschließend hatte ich es wieder aus den Augen verloren und war dann ganz überrascht, als die E-Mail kam, dass wir tatsächlich gewonnen haben.
Haben Sie eine Empfehlung für andere Forschende, die noch nicht FAIR speichern, warum und wie sie damit anfangen sollten?
Nach dem FAIR-Data-Prinzip zu arbeiten ist sinnvoll! Man kann es aus verschiedenen Gründen tun: Zum einen aus einer altruistischen Haltung. Möglichst alle sollen nutzen können, was produziert wurde, meist ja auch oft aus öffentlichen Geldern finanziert.
Genauso kann ich es aber auch aus einer „faulen“ oder egoistischen Perspektive betrachten und fragen: „Wer wird denn den größten Nutzen davon haben, dass diese Daten offen und klar strukturiert zur Verfügung stehen?“
Höchstwahrscheinlich bin ich das in der Zukunft selbst, weil ich dann vermutlich vergessen habe, was ich mir heute dabei gedacht und wo ich was hingelegt habe, Computer verschwinden, Sticks sind nicht mehr auslesbar und so weiter.
Den größten Nutzen von gut gemanagten Daten haben wir also vermutlich selbst. Unsere Daten anschließend offen zugänglich zu machen, ist dann kaum Mehraufwand bzw. keine große Umstellung. Auch aus dieser Perspektive ist es also gut und sinnvoll, nach den FAIR-Prinzipien zu arbeiten.
Wie ich schon sagte, bin ich in dieses Projekt gekommen, als es bereits lief. Ich stand vor einem Haufen von Daten, in die ich mich selbst einarbeiten und Skripte schreiben musste, die sie standardisiert einlesen – damit sie alle auf einem Level sind und ich sie überhaupt verstehen kann. Dann dachte ich mir, „Jetzt habe ich das eh schon geschrieben, dann kann ich das auch online stellen, inklusive App und Visualisierung, und alle können das nachvollziehen.” Das war praktisch kein Mehraufwand zu dem, was ich sowieso für mich machen musste.
