Datenmanagement bei der GWDG

In der Wissenschaft muss zunehmend dafür gesorgt werden, dass die Datenressourcen registriert und in geordneten Repositorien hinterlegt werden, deren Inhalte nicht verändert werden sollten und mithin referenzierbar und zitierfähig sind. Darüber hinaus müssen die Referenzen selbst stabil sein, wissend, dass digitale Repositorien „lebende Organismen“ sind und damit einer dauernden Migration auf verschiedenen Ebenen (Hardware/Software-Änderungen, Formatänderungen etc.) unterworfen.

Bei der GWDG sind derzeit von einem Gesamtspeichervolumen in Höhe von ca. 10 PetaByte etwa 1,5 PetaByte Forschungsdaten in sogenannten Dark Archives archiviert. Auch wenn diese Daten durch wirksame technische und organisatorische Maßnahmen vor dem Verlust bewahrt werden, ist die Qualität dieser Daten im Schnitt sehr gering, da für ihre Wiederverwendbarkeit bei der Speicherung keine Maßnahmen ergriffen wurden. Mit der ständig wachsenden Bedeutung und Menge von wissenschaftlichen Daten im Forschungsprozess und mit den oft hohen Kosten, die mit ihrer Entstehung, sei es durch Experimente oder durch Simulationen, verbunden waren, wird das Management der Qualität und des Lebenszyklus wissenschaftlicher Daten von der Entstehung über die Präsentation bis zur Archivierung immer bedeutsamer, um ihre Wiederverwendung zu ermöglichen.

1. Registrierung von Daten

Ein wesentlicher Schritt dabei ist die sogenannte Registrierung der Daten. Dies ist der Prozess, der aus einer Datei oder einem Ordner ein Datenobjekt macht, das durch zusätzliche Metadaten beschrieben wird und auf eine gesicherte Weise referenzierbar ist (siehe Abbildung 1). Vielfach wird die Registrierung der Daten gleichzeitig mit ihrer Hinterlegung in einem Repository einhergehen.

Registrierte Daten werden deshalb mit einem Persistent Identifier (PID) versehen, sodass Änderungen der Präsentation des Objektes transparent nachgeführt werden können. Typischerweise entschließt sich der Wissenschaftler zu einer Registrierung seiner Daten spätestens dann, wenn er ein Zitat auf die Daten für möglich hält oder eine potenzielle Nachnutzung durch andere ins Auge fasst. Aber auch für die eigene Nachnutzung ist eine Beschreibung durch Metadaten oft von hohem Wert. Im Datenmanagement-Konzept der GWDG ist daher ein Prozess für die Registrierung von Daten vorgesehen. Außerdem müssen die Hinterlegung der Daten im Repository und der Zugriff auf die Daten ermöglicht werden, was mit entsprechenden Autorisierungsregeln geschützt ist.

2. Modularisierung der Datenmanagement-Prozesse

Für Registrierung, Hinterlegung (auch ingest), Zugriff (auch access) und Suche (search) ist eine Schicht notwendig, die über verschiedene Protokolle Serviceanfragen und Datenobjekte entgegennimmt, wieder ausliefert und Modifikationen erlaubt. Diese Schicht sei im Folgenden API-Schicht (API = Application Programming Interface) genannt, auch wenn nicht alle Protokolle eine API im strengen Sinn zur Verfügung stellen. Diese Schicht stellt für den Wissenschaftler in seiner (virtuellen) Forschungsumgebung die Schnittstelle zur Nutzung der Datenmanagement-Lösung der GWDG dar, die unter dem Projektnamen CDSTAR (Common Data Storage Architecture) geführt wird (siehe auch Abbildung 2). Dieses Datenmanagement-System wird für Datenobjekte hoher Qualität bei der GWDG bereits für verschiedene Projekte produktiv eingesetzt.

Es können verschiedene Protokolle bereitgestellt werden, deren Realisierung vom Bedarf und von den Ressourcen abhängig gemacht werden muss. Eine REST-basierte (REST = Representational State Transfer) und eine Portallösung sind dabei diejenigen, deren Realisierung sichergestellt ist.

2.1 Serviceschicht

Die unmittelbar hinter der API-Schicht liegende Schicht repräsentiert die Services, die für das Management der Datenobjekte zur Verfügung stehen. Hier ist der PID-Service (s. u.) verankert, der bei der Registrierung eines Objektes zur Generierung eines PID angesprochen wird, sofern noch kein PID vorhanden ist und mitgeliefert wird. Ebenso wird beim Zugriff auf Daten der PID-Resolver angesprochen und eine Adresse zurückgegeben, falls über einen PID referenziert wird. Präsentiert werden die Daten direkt über eine Adresse oder alternativ über eine Landing-Page, die zunächst in einem allgemeinen Format verschiedene, dem System bekannte Metadaten-Inhalte sowie den tatsächlichen Datenpfad präsentiert.

In dieser Schicht werden auch weitere Services für das Datenmanagement und Repositorien implementiert, wie zum Beispiel umfassende Suchfunktionen, unstrukturiert auf den Roh- und strukturiert auf den Metadaten. Alle Funktionen dieser Schicht werden durch eine Authentifizierungs/Autorisierungs-Infrastruktur (AAI) vor unberechtigtem Zugriff geschützt, soweit notwendig.

2.2 Objektschicht

Die darunterliegende Schicht ist als eine Abstraktionsschicht gedacht, um die Objektrepräsentation der registrierten Daten auf die datei- und ordnerbasierte Implementierung des HSM-Backends (HSM = Hierarchical Storage Management) abzubilden. Diese Rolle übernimmt das iRODS-System, das mit seinem sehr flexiblen regelbasierten Microcode-Framework ideal geeignet ist, verschiedene Workflows und Virtualisierungen zu realisieren. Hier kann die interne Ablage der Daten zum Beispiel von der externen Präsentation als URL abstrahiert werden. Das spielt insbesondere bei der Organisation der Daten als Objekte in einem herkömmlichen Filesystem eine wichtige Rolle. Die zugehörigen Metadaten müssen in diesem Fall in einer  Weise abgelegt werden, die eine Rekonstruktion des Objektes allein aus den Informationen im Filesystem auch dann noch ermöglicht, wenn die darüber liegende Serviceschicht die Beziehung zwischen Daten und Metadaten nicht (mehr) abbilden sollte. Dies ist insbesondere für die Langzeitarchivierung eine wichtige Eigenschaft, weil die reine Erhaltung und Kuration der Bitstreams über Dateien in einem Filesystem realisiert wird, wodurch die Informationen im Filesystem, aber nicht die in der Serviceschicht dauerhaft erhalten bleiben. Aber es stellt auf die gleiche Weise auch eine wesentliche Komponente bei der Replikation von Datenpräsentationsschichten dar, die auf einer reinen Dateireplikation basieren.

iRODS besitzt einen eigenen Metadaten-Service (iCAT), der zur internen Verwaltung der Daten, aber auch zur Metadaten-Suche verwendet werden kann. Mit Rücksicht auf die Gesamtperformance des Systems repräsentiert die GWDG im iCAT lediglich die organisatorischen Metadaten. Der für diese Metadaten im iCAT verfügbare Suchdienst kann auch in der Serviceschicht bereitgestellt werden, für die Suche auf wissenschaftlichen Metadaten werden dort aber andere Lösungen (s. o.) angeboten.

2.3 Replikation

iRODS bietet neben seiner Möglichkeit zur Virtualisierung zusätzlich einen einfachen Replikationsservice an, der eine lokale Skalierung der Performance durch Verbreiterung der Serverbasis innerhalb einer sogenannten Zone ermöglicht, die sich um einen gemeinsamen iCAT-Server scharen. Darüber hinaus ist eine standortübergreifende Replikation durch den Aufbau einer sogenannten Föderation möglich. Hier werden die Daten gespiegelt unter verschiedenen iCAT-Servern abgelegt. Eine derartige standortübergreifende Datenreplikation mittels iRODS wird derzeit schon innerhalb verschiedener länderübergreifender Datenverbünde durchgeführt.

3. Persistent Identifier

Aufgrund der Veränderungen der Repräsentation der digitalen Objekte in Repositorien eignen sich die gegenwärtig weithin verwendeten URLs nicht zur dauerhaften Referenz auf die Daten, da sie physikalische Pfade und semantische Inhalte umfassen, die meist nach wenigen Jahren schon nicht mehr aktuell sind.

Die Wissenschaft benötigt also für die Referenzierbarkeit ihrer Primär- und Sekundärdaten andere Mechanismen, die Ressourcen eindeutig und zeit- und ortsunabhängig benennen, ähnlich wie eine ISBN-Nummer die Inkarnation eines Buches darstellt und nicht auf eine physikalische Kopie eines Buches verweist. Allerdings benötigt man für die Auflösung eines eindeutigen und persistenten Identifiers (PID) einen abgesprochenen Mechanismus. Aufgrund der enormen Bedeutung der Auflösung von Referenzen in aktuelle URLs für alle möglichen Aktionen müssen alle dafür eingesetzten Resolutionsservices ein hohes Maß an Robustheit, Zuverlässigkeit und Langfristigkeit erhalten.

Persistent Identifiers gehören als drittes Element, neben den Daten und Metadaten, zum Datenobjekt, und sie spielen dort eine besondere Rolle, weil sie sowohl eine Referenz auf den Datenstrom als auch auf die primären Metadaten geben (können).

Die Referenzierbarkeit der Daten ist allerdings über die PID nur gegeben, wenn die Referenz im PID im Falle einer Änderung der Zugriffsadresse nachgeführt wird. Die Verantwortung über die Aktualisierung der Referenz liegt im Allgemeinen bei der Institution, die für die Speicherung der Daten und damit für den Zugriffspfad zu den Daten verantwortlich ist.

Um für den PID-Service eine höhere Zuverlässigkeit und zusätzlich eine Verbreitung im europäischen Raum zu gewährleisten, gibt es seit Herbst 2009 mit EPIC (European Persistent Identifier Consortium, http://pidconsortium.eu) einen internationalen Zusammenschluss, in dem die Partner in einem Memorandum of Understanding die Bereitschaft erklärt haben, gemeinsam einen PID-Service-Dienst bereitzustellen und durch gegenseitige Redundanzstrukturen hochverfügbar zu machen. Dieser Zusammenschluss besteht derzeit aus den Institutionen GWDG, SARA (Amsterdam, Niederlande) und CSC (Helsinki, Finnland) sowie dem Deutschen Klimarechenzentrum (DKRZ) als Vollmitglieder, und GRNET (Athen, Griechenland) in dem Konsortium.