Daten und Metadaten effektiv verwalten

Service Team Forschungsdaten: Herr Fischer, Sie sind Datenmanager am Graduiertenkolleg i.c.sens. Wie ist das Datenmanagement im Kolleg organisiert?

Colin Fischer: Wir veranstalten gemeinsame Experiment-Kampagnen, bei denen Daten für sämtliche Promotionsarbeiten anfallen. Der Gesamtaufwand für diese großen Experimente ist insgesamt sehr viel geringer, als mehrere einzelne Experimente durchzuführen. Die Daten werden zentral gesammelt und allen beteiligten Instituten zur Verfügung gestellt, und vor allem auch späteren Kohorten von Promovenden. Wir haben mittlerweile 200 separate Sensordatensätze aus vier verschiedenen Kampagnen, die von den Promovenden in der nächsten Kohorte direkt als Einstieg für ihre Promotionen genutzt werden können.

Service Team Forschungsdaten: Das heißt, für die Vorbereitung der Datenerhebung und später die Ablage und Dokumentation gibt es festgelegte Workflows?

Colin Fischer: Die Planung der Experimente obliegt den Wissenschaftlern, die die Daten für Ihre Promotionsvorhaben benötigen. Für die Datenaufzeichnung während des Experiments haben wir die technische Infrastruktur vor Ort. Die Transformation der Daten in vereinheitlichte Ablageformate wird von den Wissenschaftlern selbst durchgeführt. Die verarbeiteten Daten werden dann strukturiert dokumentiert und archiviert. Weil die Datenbasis so komplex ist, haben wir gewisse Anforderungen an die Datenablage. Wir haben hohe Kapazitätsanforderungen bei der physischen Speicherung, wir benötigen geeignete Schnittstellen für den Zugriff auf die Daten, sowie Mechaniken zur Dokumentation der Daten mit Metadaten.

Hierfür bin ich im Projekt als technischer Koordinator angestellt. Meine Funktionen im Graduiertenkolleg beinhalten die Administration der Hardware-Komponenten zur Speicherung der Daten, die Konzipierung der Datenablage und des Umgangs mit Metadaten und nachher auch tatsächlich die Realisierung der Ablage. Bei mir fließen die Daten alle zusammen, und ich stelle eine einheitliche Ablage sicher. Der Workflow wurde zu Beginn meiner Tätigkeit im ersten Jahr des Graduiertenkollegs konzipiert. In der bisherigen Laufzeit des Projektes haben wir Ansatzpunkte für Verbesserungen in einzelnen Komponenten des Systems identifiziert, die wir im weiteren Verlauf des Graduiertenkollegs umsetzen werden. Hierzu gehört unter anderem eine Verschriftlichung der bisher erarbeiteten Forschungsdatenmanagement-Prozesse, z.B. in Form eines Datenmanagementplans, um die Verantwortlichkeiten aller Akteure im Graduiertenkolleg klarer zu definieren: hierbei ist entscheidend, dass alle Hierarchieebenen im Projekt einbezogen werden und ihre jeweiligen Rollen bei der Qualitätssicherung von Datenablage und Dokumentation wahrnehmen.

Service Team Forschungsdaten: In einem eigenen Forschungsprojekt entwickeln Sie Methoden zur Aufbereitung von großen Forschungsdatensätzen im Kontext „autonomes Fahren“. Welche Methoden sind das? Und wie schätzen Sie die Übertragbarkeit dieser Tools und Methoden auf andere Datenarten ein?

Colin Fischer: Wir forschen an Sensoren, die in der Fahrzeugindustrie aktuell und in den kommenden Jahren zur aktiven Umgebungserfassung während der Fahrt eingesetzt werden. Das betrifft vor allem die Erkennung von anderen Verkehrsteilnehmern, Fahrzeugen und Fußgängern zur Risikominimierung z.B. im Zusammenhang mit autonomen Fahrmanövern. Wir haben dementsprechend hohe Anforderungen an die Genauigkeit und Integrität (Zuverlässigkeit) der Selbstlokalisierung. Daher kommt auch der Name des Projekts i.c.sens: Integrität - also Selbsteinschätzung - und Kollaboration - also das Zusammenschalten mehrerer Sensoren - von Multisensorsystemen. Wir integrieren Beobachtungen mehrerer Sensoren und erst durch diese Synthese generieren wir Mehrwert. Auch diese Informationen müssen neben den Rohdaten abgelegt werden. Die Kalibrierinformation bezieht sich zum Beispiel nicht auf einen einzelnen Sensor, sondern auf den Versuchsaufbau einer gesamten Messkampagne. Ohne diese Informationen wäre die Integration mehrerer Sensoren unmöglich.

Zur zentralen Datenablage benutzen wir einen Fileserver. Zusätzlich betreiben wir einen sogenannten Hadoop-Cluster, also einen Verbund von Rechnern, die optimiert sind für hochperformante parallele Verarbeitung großer Datenmengen. Hinzu kommt ein Server mit mehreren GPUs für Grafikkarten-Anwendungen, z.B. Training im Zusammenhang mit Deep Learning. Für diesen Rechner-Verbund nutzen wir den Server-Housing-Dienst des LUIS, um die Bandbreite bei der Datenkommunikation zwischen diesen Systemen zu maximieren. Die Projektteilnehmer verbinden sich per Remoteverbindung mit dem Fileserver, und können von dort sehr schnell Daten zwischen Datenablage und verarbeitenden Rechnern verschieben, Prozessierungen anstoßen und dann die Ergebnisse zurückschreiben auf den File Server.

Metadaten legen wir als XML-Files in einem selbstgewählten Schema ab, angelehnt an den Standard Dublin Core, erweitert um domänenspezifische Metadaten. Die Metadaten werden für jeden Datensatz manuell erfasst und zusammen mit den Daten abgelegt. Die Metadaten-XML-Files werden dann automatisiert in eine relationale Datenbank übertragen, wo die Assoziation zwischen dem aktuellen Speicherort aller Datensätze und ihrer Metadaten stattfindet. Auf dieser Datenbank können komplexere raum-zeitliche Anfragen auf Metadatenebene mit SQL durchgeführt werden. Darüber hinaus betreiben wir ein Web-Interface, über das Daten, Metadaten und die Metadaten-Datenbank per Browser direkt zugreifbar sind. Hier finden die Projektteilnehmer auch eine Karte, auf der die bisher erfassten Datensätze visualisiert werden.

Ich denke, die Grundidee ist gut übertragbar: jeder Datensatz besteht aus einer oder mehreren Dateien, die kommen in einen Ordner. Dazu kommen die Metadaten-Beschreibung in einer separaten Datei pro Datensatz. Wir exportieren die Informationen über diesen Datensatz automatisiert mit einem Skript in eine Datenbank. Die Datenbank weiß dann, an welcher Stelle der Datensatz liegt und welche Metadaten damit assoziiert werden, und in den Metadaten kann ich dann suchen. Die Visualisierung der Daten in einem Web-Interface macht für räumliche Daten Sinn.

Service Team Forschungsdaten: Wie ist Ihre Vision von einer idealen Arbeitsumgebung, also in Bezug auf Datenaufbereitung und -verwaltung, wie Sie vielleicht in einigen Jahren zur Verfügung stehen könnte?

Colin Fischer: Forschungsdatenmanagement muss widergespiegelt werden in den organisatorischen Strukturen des Projekts. Die Verantwortlichkeiten beim Forschungsdatenmanagement müssen für alle Akteure im Projekt klar definiert sein; die Einhaltung dieser Richtlinien muss von allen Akteuren im Projekt regelmäßig überprüft werden. Akteure auf höheren Hierarchieebenen müssen Qualitätsmanagement betreiben und entsprechende Forschungsdatenmanagement-Aufgaben delegieren und den Erfolg dieser Aufgaben überprüfen.

Ich könnte mir vorstellen, eine Art generischer Software zur allgemeinen Datenverwaltung zu haben. Wir haben die Publikationsplattform für die Forschungsdaten [das LUH-Datenrepositorium data.uni-hannover.de]. Im Prinzip, würde so etwas ja reichen, um eine ganz rudimentäre Verwaltung zu machen. Dort gibt es eine Ablage für Dateien, und ein paar Metadaten-Felder. Man kann sogar selbstdefinierte Felder vorgeben. Das ist sicher in einem kleinen Rahmen eine gute Lösung. Das hat natürlich immer diesen trade-off von Verallgemeinerbarkeit versus Domänen-Spezifizität. In einer sehr enggefassten Domäne kann man natürlich sehr viel spannendere Sachen machen, weil man sich auf bestimmte Eigenschaften der Daten verlassen kann. Je allgemeiner die Plattform ist, desto mehr verzichtet man auf spannende Funktionalitäten, die eigentlich möglich wären. Daher favorisiere ich eher fachspezifische Entwicklungen von Spezialsoftware.

Service Team Forschungsdaten: Oder wäre vielleicht eine Art modularer Aufbau denkbar, mit einem Kernmodul, das für so ziemlich alle Datenarten funktionieren kann, und dann angegliederter Spezialsoftware für ganz bestimmte Datenarten oder Anwendungsfälle?

Colin Fischer: Die Idee von Plug-Ins ist natürlich toll. Zum Beispiel habe ich meine Metadatenverwaltung, jetzt nehme ich das Plug-In räumliche Daten, und plötzlich habe ich alles dazu, was räumliche Daten können. Was ich auch wieder aus unserer Domäne wichtig finde, ist eine stärkere Berücksichtigung von Versionierungen von Datensätzen. Wir haben teilweise Datensätze, die existieren in verschiedenen Aufbereitungsstufen. Wir haben die Rohdaten, wie sie aus dem Sensor kommen. Dann gibt es bei uns relativ früh bestimmte Standard-Prozessierungsschritte oder Transformationen, die dann ein komplexes Ergebnis erzeugen. Das ist es dann wert, abgelegt zu werden, weil es z.B. Ressourcen (Rechenzeit) oder Sachverstand gekostet hat. Es wäre dann notwendig, nachvollziehen zu können, aus welchen Quellen die erzeugten Daten stammen. Ich habe also die Ausgangsdaten und die erzeugten Daten, dazwischen findet eine Transformation statt, die heutzutage üblicherweise durch Code realisiert wird. Warum kann ich den Code nicht parallel dazu auch noch ablegen? Der Speicherbedarf hierfür ist Größenordnungen kleiner als der Speicherbedarf für die eigentlichen Daten.

Nochmal zwei praktische Aspekte, wenn wir von einer Vision sprechen. Wir haben für die großen Datenmengen, die wir heutzutage erzeugen können, noch nicht so viel Bandbreite, dass praktische Probleme bei der Übertragung der Daten kein Thema wären. Auf der anderen Seite brauchen die großen Datenmengen Speicherplatz, nicht nur zur Datenablage, sondern auch nochmal redundant für das Backup. In Großprojekten werden üblicherweise keine finanziellen Mittel für die reine Datenspeicherung eingeplant; diese Infrastruktur muss aus anderen Töpfen bezahlt werden. Es ist schade, wenn Forschungsergebnisse gelöscht werden müssen, weil benötigte Speicherkapazitäten nicht zur Verfügung stehen. Es wäre schön, wenn Speicherplatz nicht so ein großes Thema wäre, wie es jetzt bei uns gerade ist.

Service Team Forschungsdaten: Welche Herausforderungen sehen Sie bei der Umsetzung des Forschungsdatenmanagements? Und zwar insbesondere im Umfeld von Promotionen.

Colin Fischer: Stichwort „Promotionsrealität“: Die Idee vom Forschungsdatenmanagement ist ja toll. Man muss aber schauen, was im konkreten Fall der Promovend tatsächlich an Ressourcen zur Verfügung hat, um Forschungsdatenmanagement zu betreiben. In der Praxis sieht es häufig so aus, dass der Promovend sich nicht erst einmal zum Thema Forschungsdatenmanagement fortbildet und sich direkt am ersten Tag ein System zur Verwaltung seiner Forschungsdaten baut. Praktisch sieht es eher so aus, dass er irgendwie mit der eigentlichen Forschungstätigkeit anfängt. Dann hat er seinen Ordner mit Daten, macht vielleicht noch ein zweites Experiment und sagt: "Okay, ich habe das doch im Kopf, was da passiert ist." Aber in dem Moment, wo der Promovend sein Institut verlässt und irgendwer Daten und Ergebnisse nachvollziehen möchte, sieht es in der Praxis so aus, dass zumindest die Dokumentation der Datenablage mangelhaft ist und damit kaum nachvollziehbar für andere.

Wir sehen natürlich für Promovenden eine hohe Selbstverantwortlichkeit, Forschungsdatenmanagement zu betreiben, aber gleichzeitig wird es eigentlich sehr gering priorisiert. Bewertet werden nachher die schriftliche Ausarbeitung und das mündliche Kolloquium. Aber es gibt keine harten Kriterien, die sagen, dass Forschungsdaten auf eine definierte Weise organisiert sein müssen in irgendeiner bestimmten Form oder Qualität. Das heißt, da gibt es überhaupt keine Anforderungen, wodurch der Promovend gezwungen wäre, sich Gedanken zu machen über Forschungsdatenmanagement, vor allem nicht über seine eigene Promotion hinaus.

Es wäre wichtig, dass Forschungsdatenmanagement als essenzieller Bestandteil von Promotionen verstanden wird. Dass das Forschungsdatenmanagement als Ziel oder als Abgabekriterium von einer Dissertation definiert ist. Hierbei muss natürlich der zusätzliche Zeitaufwand von höherer Stelle anerkannt werden, aber im Gegenzug auch wieder die Qualität überprüft werden. In dem Zusammenhang wären die Institute, an denen die Promotionen stattfinden, natürlich auch gezwungen, sich mehr über Forschungsdatenmanagement Gedanken zu machen, also eigene Richtlinien zu verfassen (z.B. in Form von Datenmanagementplänen) und fachspezifische Lösungen zur Instituts-internen Datenablage zu finden. Hier entsteht aber gegebenenfalls ein neues Problem: jede fachspezifische Lösung stößt irgendwann an eine Grenze, wo sich ein Promovend mit einem neuen Thema mit strukturell ganz anderen Daten befasst, die dann nicht mehr sinnvoll im fachspezifischen System abgebildet werden können, weil z.B. die üblichen Metadaten nicht darauf zutreffen oder neue Metadaten benötigt werden.

Service Team Forschungsdaten: So einheitlich wie möglich, so flexibel wie nötig oder umgekehrt...

Colin Fischer: Ja, genau. Selbst wenn jetzt ein Institut zum Beispiel ein existierendes System hat für Forschungsdaten, dann kann es zu jedem Zeitpunkt passieren, dass Daten anfallen, die wieder genau nicht in die Systeme reinpassen. Da müssen wir dann jedes Mal überlegen, wie erweitern wir das aktuelle System, oder finden wir ein neues System, das auch wieder alle Daten gleichzeitig integriert?

Bei der Promotion halte ich es fast für wichtiger, die Transformation, den Code und die Skripte zu dokumentieren als die eigentlichen Daten. Was wir in der Praxis häufig sehen: selbst, wenn Daten aus externen Quellen dokumentiert sind, reicht es nie aus, die Beschreibung von einer Webseite herzunehmen. Es braucht häufig noch direkten Kontakt mit dem Erzeuger der Daten, um die Details des Experiments zu erfragen. Ich habe noch kein System gesehen, das in der Lage ist, die vollständige Komplexität eines Experimentaufbaus oder die Komplexität von Daten wirklich zu repräsentieren. Ich denke, in der üblichen Promotion ist gar nicht genug Zeit eingeplant, um Forschungsdatenmanagement zu betreiben, und im Zweifelsfall wird der Promovend immer die Dinge, die er machen muss, priorisieren über die Dinge, die er vielleicht machen sollte.

Service Team Forschungsdaten: Sie haben ja inzwischen sehr viel Erfahrung gesammelt. Wenn Sie morgen als Datenmanager bei einem ganz neuen Verbundprojekt anfangen würden, was würden Sie wieder genauso machen und was vielleicht anders?

Colin Fischer: Ich würde verschiedene Sachen wieder sehr ähnlich aufbauen. Aber ich würde einmal komplett ein Resümee ziehen aus dem System, wie es jetzt ist. Identifizieren, was eigentlich noch fehlt, was in der Planungsphase beim ersten Mal nicht berücksichtigt wurde und ein komplett neues System bauen, das die in der bisherigen Projektlaufzeit identifizierten Möglichkeiten zur Verbesserungen umsetzt. In der Softwareentwicklung nennt sich das Spiralmodell: Ich mache eine Planung, dann baue ich ein System, dann evaluiere ich das System. Und dann baue ich eine zweite Version. Die erfüllt alle alten Anforderung plus die neuen, die mittlerweile aufgetreten sind. Dann bekomme ich ein immer besseres System. Aber da ich jedes Mal neu plane und neu implementiere, kann kein Wildwuchs in der Struktur herrschen.

Zum Beispiel ist der Bedienungskomfort beim Eintragen von Metadaten nicht toll. Je nachdem, wie viele Experimente durchgeführt wurden, muss eine Person vielleicht 20 sehr ähnliche XML-Dateien schreiben. Man müsste schauen, ob man das irgendwie komfortabler machen kann, zum Beispiel durch das automatische Eintragen gleicher Informationen in alle Dateien. Aber wir haben damals angefangen mit einem Template. Was ich damals nicht vorgesehen habe: Was ist denn, wenn ich jetzt global zum Beispiel einen Tag hinzufügen möchte, den ich rückwirkend anwenden möchte auf alle Daten, die jemals gesammelt wurden? Es wäre nicht schlecht, wenn man für das Template so eine Art Verwaltungssystem hätte, das diese Metadatendateien organisiert. Ansonsten muss ich nämlich viele Dateien einzeln anfassen.

Was auch wichtig ist: Dass man sich, wenn man so ein System plant, Gedanken darüber macht, welche Arten von Daten man eigentlich verwalten möchte, um bereits fachspezifische Zusatzfunktionen und Metadaten planen zu können. Nachträglich einbauen würde ich gerne auch noch eine Art Versionierungssystem mit Anbindung an ein Softwareversionierungssystem. Dafür müsste man einen eindeutigen Datensatz-Identifier einführen, die dann von anderen Metadaten referenziert werden können. Damit man weiß, aus welchen anderen Datensätzen durch welche Transformationen mit welchen Parametern (ggf. mit Verweis auf Code) die Daten erzeugt wurden.