3.1 Aus Sicht der Wissenschaft

In der Anforderungsanalyse (zum methodischen Vorgehen vgl. Abschnitt 4.1) zu Beginn der Designphase wurden aus Sicht des HDC Nachhaltigkeit, Präsentation und Integration als maßgebliche Dimensionen identifiziert, aus denen sich weitere Anforderungen ableiten lassen und die den Forschungsdatenlebenszyklus[22] sowie die verschiedenen Aggregationsstufen von Daten[23] vollständig abdecken. Diese Dimensionen adressieren sowohl Datengeber bzw. Datenproduzenten, als auch Datennutzer. Die Anforderungen der Datennutzer übersteigen diejenigen der Datenproduzenten in dem Sinne, dass die öffentliche Bereitstellung von Forschungsdaten für eine möglichst unbeschränkte, disziplinübergreifende Nachnutzung auf Seiten der Datenproduzenten einen erheblichen Mehraufwand erforderlich macht. Dies bezieht sich vor allem auf die Einhaltung von Standards bei der Erzeugung und der Aufbereitung der Daten sowie die ausführliche Dokumentation aller nötigen Kontextinformationen, um die Daten verstehen und einordnen zu können. Datenzentren sollten sich angesichts dessen nicht auf die Rolle eines Anbieters technischer Infrastruktur zurückziehen, sondern Forschende im Sinne eines Kompetenzzentrums beim Datenmanagement beraten und unterstützen – von der Auskunft zu konkreten, einzelnen Fragen über die Bereitstellung von Informations- und Schulungsmaterialien bis hin zur Beteiligung an Projekten im Sinne des Embedded Data Managements.[24]

Insgesamt bleibt festzuhalten, dass die Geisteswissenschaftlerinnen und -wissenschaftler von Anfang an möglichst eng in die Erarbeitung sowohl der technischen als auch der forschungsbegleitenden Beratungs- und Schulungsangebote des Forschungsdatenzentrums einzubeziehen sind, da allein die Bereitstellung eines Angebots nicht ausreicht, um die Akzeptanz durch die potenziellen Nutzerinnen und Nutzer zu erzeugen.[25]

3.2 Weitere Anforderungen an ein Forschungsdatenzentrum

Neben den oben genannten wissenschaftlichen Anforderungen sind einige Teilaspekte der Anforderungen zu benennen, die im Interesse von Gedächtnisinstitutionen stehen, wie bspw. die Erstellung von Digitalisaten seltener Objekte zur Schonung der physischen Originale, die dann natürlich auch dementsprechend nachgewiesen und präsentiert werden müssen.[37] Zudem kann es im Interesse von Gedächtnisinstitutionen sein, Digitalisate oder genuin digitale Objekte nachhaltig aufzubewahren, die sie z.B. aus urheberrechtlichen Gründen (noch) nicht einer breiteren wissenschaftlichen Öffentlichkeit zur Verfügung stellen können. Dies kann zum einen der digitalen Bestandserhaltung[38] dienen oder sogar als ›Reservekopie‹ für den Fall des Verlusts des physischen Objekts. Exemplarisch seien hier der Einsturz des Historischen Archivs der Stadt Köln[39] und der Brand in der Herzogin-Anna-Amalia-Bibliothek in Weimar[40] genannt. In beiden Fällen sind viele Bücher und Dokumente unwiederbringlich verloren gegangen, die noch zur Verfügung stehen würden, wenn sie vorher digitalisiert geworden wären.

3.3 Umsetzungsbedingungen für ein Forschungsdatenzentrum aus Sicht eines Infrastrukturanbieters

Im Gegensatz zu einem Publikationsrepositorium[41], das sich sowohl bei den Formaten als auch bei den Metadaten nur auf eine vergleichsweise geringe Bandbreite an Formaten und Technologien einzustellen braucht, steht ein Forschungsdatenzentrum für geisteswissenschaftliche Daten vor einer größeren Herausforderung. Hier geht es – wie oben bereits ausführlich beschrieben (vgl. hierzu Abschnitt 2) – um die Archivierung und Erhaltung einer Vielfalt von Formaten sowie komplexer Datentypen. Die Formatvielfalt ist nicht zuletzt eine Folge der Diversität der in der geisteswissenschaftlichen Forschung eingesetzten digitalen Werkzeuge, unter denen sich momentan noch viele individuell an die konkrete Forschungsfrage angepasste Eigenentwicklungen befinden.

Ein wesentliches Kennzeichen komplexer Datentypen ist, dass oft nur ein kleiner Kern standardisierbar ist, nämlich deskriptive, technische und administrative Metadaten. Hieraus folgt für die Gewährleistung der Langzeitarchivierung und Nachnutzbarkeit dieser Daten, dass in der Regel mehr oder weniger maßgeschneiderte Lösungen erforderlich sind. So muss zunächst die Struktur der komplexen Datenobjekte ermittelt werden, d.h. es muss untersucht werden, aus welchen einzelnen Daten und Anwendungen sie sich zusammensetzen. Dann müssen passende Archivierungsstrategien entwickelt, getestet und ggf. revidiert werden. Die Entwicklung und Durchführung derartiger individueller Lösungen erfordert einen hohen Ressourceneinsatz, dessen Umfang von Fall zu Fall erheblich variieren kann, was wiederum die Bestimmung der Kosten für die Langzeitarchivierung und -bereitstellung schwierig macht. Die geringe Standardisierung der Daten stellt auch für die Nachnutzung eine Herausforderung dar.

Die Rechercheoberfläche eines Forschungsdatenzentrums sollte zum einen möglichst intuitiv bedienbar sein, zum anderen aber ausreichend relevante Treffer und Möglichkeiten zur Ergebnisverfeinerung bieten. Hier wirft jedoch bereits der beschreibende Kern von Metadaten für die Entwicklung einer Suche über einen Bestand von Forschungsdaten die Frage auf, wie granular die beschreibenden Metadaten sein müssen bzw. sein können, denn Metadaten werden keine Suche in Volltexten ersetzen können. Eine weitere Frage in diesem Zusammenhang ist, wie die Interoperabilität der Metadatenschemata verschiedener Forschungsdatenzentren und Gedächtnisinstitutionen gewährleistet werden kann.[42]

Während Kosten aus Sicht der Wissenschaft idealerweise nur eine untergeordnete Rolle spielen, sind Infrastrukturanbieter dazu angehalten, ihre Angebote so kosteneffizient wie möglich bereitzustellen. Die Kosteneffizienz von Angeboten zur Erhaltung und Bereitstellung von Forschungsdaten wird für einen Infrastrukturanbieter vor allem durch die Faktoren Standardisierbarkeit und Skalierbarkeit beeinflusst:

• Standardisierbarkeit der Daten und Dienste: Diese ist vor allem mit Blick auf die Interoperabilität mit anderen Diensten und Anbietern sowie im Interesse effizienter Kurationsabläufe innerhalb des Forschungsdatenzentrums wünschenswert. Je standardisierter Daten übernommen werden können, desto weniger Aufwand entsteht für die Kuration und desto einfacher ist die Umsetzung von Mehrwertdiensten, bspw. ein übergreifendes Suchportal basierend auf dem Austausch von Metadaten per OAI-PMH.
• Skalierbarkeit der Dienste: Je standardisierter die Daten sind, desto besser skalieren die Dienste für ihre Archivierung und Bereitstellung. Die mit zunehmender Heterogenität der Daten und Abläufe abnehmende Skalierbarkeit der Dienste liegt nicht unbedingt im Interesse eines Infrastrukturanbieters.

Wie oben bereits angedeutet, führt jedoch die Heterogenität geisteswissenschaftlicher Forschungsdaten dazu, dass viele Dienste zu ihrer Archivierung und Bereitstellung nicht skalieren. Skalierbare Dienste sind noch am ehesten für einfache Objektklassen vorstellbar, da hier der Aufwand für den Ingest, d.h. die Überführung ins Datenzentrum, und die Bereitstellung nach einer gewissen Zeit auf Grund von Erfahrungswerten gut abgeschätzt und kalkuliert werden kann. Da es sich bei der Übernahme komplexer Datenobjekte jedoch voraussichtlich meist um Einzelfälle handeln wird, ergeben sich als Konsequenz schwer kalkulierbare Personalressourcen bzw. Kosten.

3.4 Zwischenresümee

Das Angebotsportfolio eines Forschungsdatenzentrums muss einen Kompromiss zwischen den Anforderungen der Wissenschaft und den Anforderungen bzw. Möglichkeiten des Infrastrukturanbieters finden. Eine naheliegende Option bildet ein Angebotsportfolio, das neben generischen, skalierenden Diensten für einfache Objektmodelle auch spezialisierte Angebote für die Erfassung, Archivierung, Präsentation und wissenschaftliche Nachnutzung komplexer Datenstrukturen bereitstellt und auf eine kooperative Ergänzung mit den Angeboten anderer Forschungsdatenzentren bzw. Arbeitsteilung ausgerichtet ist. Da sich angesichts der ohnehin unumgänglichen engen Zusammenarbeit mit den Wissenschaftlerinnen und Wissenschaftlern die Angebotsspezialisierung der verschiedenen Forschungsdatenzentren auf bestimmte Bereiche von Forschungsdaten anbietet, könnte so eine vermeintliche Schwierigkeit zu einer Stärke werden.

4.1 Vorgehensweise

Als Hilfsmittel bei der Angebotsgenese[43] und um einen sinnvollen Kompromiss zwischen den Anforderungen der Wissenschaft und der Infrastrukturanbieter zu finden, wurden in der HDC-Designphase sogenannte Forschungsdatentypen definiert, für die auf der Grundlage der im Konsortium vorhandenen Forschungsvorhaben und Erfahrungen entlang der weiter oben beschriebenen wissenschaftlichen Anforderungsdimensionen konkrete Angebote konzipiert wurden.

Hierfür wurden zunächst die heterogenen Datenbestände der an der HDC-Designphase beteiligten Konsortialpartner hinsichtlich möglicher Gemeinsamkeiten untersucht und zu Gruppen von Forschungsdatentypen zusammengeführt. Ziel war es, ausgehend von der Vielzahl der möglichen Datenmodelle einen gangbaren Weg zur Einengung des Feldes zu finden, der gleichzeitig zu der oben angesprochenen Arbeitsteilung zwischen verschiedenen Forschungsdatenzentren führen könnte. Unter einem Forschungsdatentypen wird im HDC-Projektkontext die idealtypische Repräsentation einer Gruppe von Forschungsdaten verstanden, die – bspw. hinsichtlich der Erhebungs-, Analyse- und Darstellungsweisen – technologische, methodische und informationswissenschaftliche Gemeinsamkeiten aufweisen.[44] Innerhalb des Konsortiums wurden folgende grundlegenden Forschungsdatentypen identifiziert:

• Datenbanken,
• digitale Editionen,
• Bildformate,
• Videoaufzeichnungen (von Interviews),
• Anwendungen zur interaktiven Visualisierung von Daten.

Sie wurden im Hinblick auf die folgenden Dimensionen untersucht, um daraus konkrete Anforderungen an die zu entwickelnde Infrastruktur abzuleiten:

• technische Ebene (bspw. Format, Anwendung),
• informationswissenschaftliche Ebene (Metadaten, Interoperabilität),
• fachwissenschaftliche Ebene (significant properties, wissenschaftlicher Gehalt).[45]

Im Folgenden werden drei Forschungsdatentypen anhand von konkreten Beispielen aus dem Konsortium genauer beschrieben.

4.2 Forschungsdatentyp: Datenbank

Der Begriff ›Datenbank‹[46] verweist im Kontext des HDC-Projekts nicht auf eine bestimmte wissenschaftliche Methode, sondern dient als abstrakte, zusammenfassende Bezeichnung für »(geordnete) Listen von (semi-)strukturierten Einträgen«[47]. Eine Datenbank kann das primäre Ergebnis eines Forschungsprojektes sein, sie kann aber auch ein Werkzeug sein, das z.B. lediglich als Hilfsmittel zur Texterschließung in einem Editionsvorhaben aufgebaut wird. In beiden Fällen ist sie jedoch ein wesentliches (Zwischen-)Ergebnis der Forschung. Der Forschungsdatentyp Datenbank wird am Beispiel der Berliner Klassik näher erläutert (vgl. Abbildung 1).

Das Akademievorhaben Berliner Klassik (BBAW, Laufzeit 2000–2013) untersuchte die Kulturblüte in Berlin zwischen 1786 und 1815. Hierfür wurden künstlerische, wissenschaftliche und gewerbliche Leistungen erfasst. Neben schriftlichen Publikationen zählen zu den Forschungsergebnissen fünf Datenbanken, die sich der Darstellung der Vernetzung der Berliner Gesellschaft widmen. Die Datenbanken der Berliner Klassik dienten zunächst als Arbeitsinstrument, dann als Präsentationsinstrument. Vier der Datenbanken (die Personendatenbank, die Literaturdatenbank, die Nationaltheaterdatenbank und die Geselligkeitsdatenbank) sind momentan über ein gemeinsames Portal ansprechbar. Bei den erfassten Inhalten handelt es sich vor allem um Namen, Orte, bibliographische Angaben und Datumsangaben Durch die Verknüpfung der einzelnen Datenbanken haben sich zusätzliche Suchfunktionen ergeben, die bei Verlust der Verknüpfungen verloren zu gehen drohen.

Abb. 1: Vereinfachte Darstellung des Forschungsdatentyps Datenbank anhand der Berliner Klassik. Zitiert aus: Andreas Aschenbrenner et al.: Humanities Data Centre – Angebote und Abläufe für ein geisteswissenschaftliches Forschungsdatenzentrum. HDC-Projektbericht Nr. 1. O.O. 2015, S. 30. [online]

Da der Forschungsdatentyp Datenbank nur ungenau eingegrenzt werden kann und nicht alle projektinternen Ad-hoc-Lösungen in die LZA überführt werden müssen, ist eine genaue Abschätzung der Nachfrage momentan schwer möglich. In Zukunft erscheint es, wie auch bei den folgenden Forschungsdatentypen, wichtig, dass der Nachhaltigkeitsaspekt von Anfang an in die Planung und Umsetzung von Datenbanken durch die Projekte einbezogen wird, wobei der Beratung durch Datenzentren wie dem HDC eine zentrale Rolle zukommen kann (vgl. Abschnitt 6: generische Anwendungssysteme).

4.3 Forschungsdatentyp: Digitale Edition

Genauso wenig wie ›die‹ Datenbank, gibt es auch nicht ›die‹ digitale Edition.[48] Zum einen kann der Begriff digitale Edition unterschiedlich definiert werden,[49] zum anderen können bei der konkreten Umsetzung unterschiedliche Methoden zum Einsatz kommen. Auch wenn digitale Editionen zu Präsentationszwecken in Datenbanken abgelegt werden können, unterscheiden sie sich doch zumeist vom Forschungsdatentyp Datenbank dadurch, dass in ihnen literarische und historische Quellen vollständig erschlossen und in eine geeignete Darstellungsform überführt werden. Komplexe digitale Editionen, die unterschiedliche Repräsentationsebenen wie Bild, diplomatische Transkription, edierter Text, Erläuterungen und Sekundärtexte gleichzeitig anzeigen können, lassen sich nur unter Informationsverlust, d.h. Verlust eines mehr oder weniger großen Teils der Forschungsleistung, in eine lineare Darstellung oder in eine für den Druck geeignete Form überführen. Während sich für digitale Editionen auf der Ebene der Primärdaten Metadatenstandards und Standardformate wie XML TEI, XML MEI, TUSTEP oder TIFF etabliert haben, gestaltet sich die Umsetzung der interaktiven Darstellungsform recht unterschiedlich.[50]

Abb. 2: Vereinfachte Darstellung des Forschungsdatentyps digitale Edition anhand der Kant-Edition. Zitiert aus: Andreas Aschenbrenner et al.: Humanities Data Centre – Angebote und Abläufe für ein geisteswissenschaftliches Forschungsdatenzentrum. HDC-Projektbericht Nr. 1. O.O. 2015, S. 28. [online]

Als Beispiel soll hier die Online-Edition des Opus Postumum Immanuel Kants (BBAW, Laufzeit seit 2001, vgl. Abbildung 2) dienen, die eine Neuedition des Kant’schen Nachlasswerkes anstrebt. Die technische Struktur gliedert sich folgendermaßen:

1. Primärdatenschicht/Quellen: Die Primärdaten umfassen Texte inkl. Annotationen (in XML/TEI), damit verknüpfte Digitalisate (bspw. Bildformate) sowie Apparate und Register (in XML).
2. Transkriptionsschicht: In einer XML-Datenbank, basierend auf eXist, werden die Transkriptionen des Originals mit den entsprechenden Digitalisaten vernetzt.
3. Präsentationsschicht: Über eine webbasierte Publikationsschicht mittels XML-Datenbank und XSLT-Skripten, d.h. in einem herkömmlichen Browser, wird die Transkription in verschiedenen Darstellungsformen als HTML ausgegeben. Dabei wird »die Rohtranskription in wechselseitiger abschnittsweiser Verbindung mit den digitalisierten Faksimiles in der diplomatischen Abfolge des Manuskripts«[51] präsentiert.

4.4 Forschungsdatentyp: Datenvisualisierung

Im Kontext der HDC-Angebotsgenese wird der Forschungsdatentyp Datenvisualisierung[52] als eine auf Datenbanken beruhende, für das menschlichen Auge ansprechende, interaktive Präsentation von Forschungsdaten definiert. Im Mittelpunkt steht in diesem Fall das die Präsentation und Interaktion ermöglichende Werkzeug, nicht die der Visualisierung zugrunde liegenden Daten.[53]

Als konkretes Beispiel für eine interaktive Datenvisualisierung soll hier auf die am MPI MMG[54]entwickelte Anwendung Global Migration Flows[55] näher eingegangen werden, die Migrationsbewegungen zum Thema hat und die Zusammenstellung individueller Datensets zu Migrationsbewegungen zwischen 1970 und 2011 innerhalb eines herkömmlichen Browsers ermöglicht (vgl. Abbildung 3). Hierdurch können auf einfache und anschauliche Art und Weise Wanderungsgewinne oder -verluste veranschaulicht werden.

Da Datenvisualisierungen stark an ihre Präsentationsumgebung gebunden sind, müssen Langzeitarchivierungslösungen ihrer besonderen Mehrschichtigkeit Rechnung tragen, um ihren Mehrwert zu erhalten. In der Regel bestehen auf einer Browseranwendung beruhende Datenvisualisierungen aus mindestens drei Schichten:

1. Den aufbereiteten und normalisiert in einer Datenbank bereitgestellten Daten. Die Aufbereitung richtet sich nach dem Zweck der Datenvisualisierung und kann unterschiedlich komplex sein – das Spektrum reicht von einfachen Excel-Tabellen bis hin zu komplexen Datenbanken.
2. Einer Prozessierungsschicht (Middleware), die die normalisierten Daten übernimmt und an die Client-Anwendung des Nutzers oder der Nutzerin weitergibt.
3. Eine darauf aufsetzenden Präsentationsschicht als Nutzerschnittstelle. [56]

Abb. 3: Vereinfachte Darstellung des Forschungsdatentyps Datenvisualisierung am Beispiel der Global Migration Flows. Zitiert aus: Andreas Aschenbrenner et al.: Humanities Data Centre – Angebote und Abläufe für ein geisteswissenschaftliches Forschungsdatenzentrum. HDC-Projektbericht Nr. 1. O.O. 2015, S. 34. [online]

Aus dieser Mehrschichtigkeit ergeben sich verschiedene Konsequenzen. Im Unterschied zu Texten, Bildern oder Videos spielten digitale Datenvisualisierungen in bibliothekarischen oder archivarischen Kontexten bisher so gut wie keine Rolle. Aufgrund ihrer spezifischen Eigenschaften können sie auch nicht einfach in ein dateibasiertes Repositorium überführt werden, ohne an Informationswert zu verlieren, da sie meist nicht datei-, sondern datenbankbasiert sind und Beziehungen von Objekten zueinander darstellen.

Das Thema wissenschaftliche Datenvisualisierung gewinnt vor dem Hintergrund der Digitalisierung der Forschung und der einfacheren Zugänglichkeit (im Sinne von Bedienbarkeit und Standardisierung) von Werkzeugen zur Aufbereitung und Darstellung von digitalen Forschungsdaten sowie der immer besseren Verfügbarkeit (großer Mengen) digitaler Daten zunehmend an Bedeutung. Durch den Einsatz neuer Technologien und der Möglichkeit zur Erschließung und Vernetzung verteilter Datenbestände werden attraktive Darstellungen von Zusammenhängen – gerade auch für eine interessierte Öffentlichkeit – möglich. Visualisierungen können textgebundene Publikationen anreichern und qualitativ aufwerten und entsprechen so einer Nachfrage von Wissenschaftlerinnen und Wissenschaftlern und Fördereinrichtungen. Derzeit ist für die Umsetzung von Visualisierungen noch sehr spezielle IT-Expertise notwendig, aber es ist wahrscheinlich, dass es in Zukunft Werkzeuge geben wird, mit denen auch informationstechnische Laien relativ einfach Visualisierungen erzeugen können.[57] Somit müssen Forschungsdatenzentren in der Lage sein Langzeitarchivierungslösungen für diesen Forschungsdatentyp anzubieten und ggf. über generische Anwendungssysteme für die Wissenschaftlerinnen und Wissenschaftler zur Nutzung zur Verfügung zu stellen.

5.1 Teilergebnisse: Berliner Klassik

Am Beispiel der Berliner Klassik wurde im Projektverlauf der Versuch unternommen, eine bestehende Anwendung technologisch auf neue Füße zu stellen und dabei die signifikanten Eigenschaften zu erhalten. Hierfür wurden die Daten aus der über die Jahre hinweg etwas wildwüchsig geratenen Struktur einer PostgreSQL-Datenbank testweise in eine dokumentenbasierte Datenbank (Mongo-DB, JSON) überführt und das Zope-basierte Frontend der Anwendung auf Basis eines neuen Webframeworks (Express.JS) reimplementiert.

Ziel dieses Experiments war eine Bestimmung des Migrations- und Reimplementierungsaufwands in der Hoffnung, perspektivisch den längerfristigen Betrieb einer ganzen Reihe einfacherer Datenbankanwendungen auf einem einheitlichen Software-Stack sicher betreiben zu können und die Auslotung von Möglichkeiten für einen generischen Viewer, also einer vereinfachten, generischen Präsentationsumgebung für Datenbanken in entsprechend standardisierter, normalisierter Form (vgl. Abschnitt 5.2). Obwohl die Überführung manuell durchgeführt wurde und sich komplex gestaltete, hielt sich der Aufwand mit ein bis zwei Personenmonaten dennoch in Grenzen. Wenngleich der Prototyp individuell auf die Anforderungen der Berliner Klassik zugeschnitten war, deutet die einfache Übertragbarkeit von einer Datenbank auf eine andere prinzipiell darauf hin, dass generische Datenmodelle und Systemstrukturen entwickelt werden können. Im Bereich der geisteswissenschaftlichen Datenbanken zeichnet sich derzeit noch keine Best Practice in der Community ab.

Aus informationswissenschaftlicher Sicht galt es vor allem, bei der Überführung die Verknüpfungen zwischen den Datensätzen und bestimmte Suchfunktionalitäten zu erhalten, die Art der Darstellung im Webinterface spielte eine nachgeordnete Rolle. Die Bewertung des ersten Prototyps durch Fachwissenschaftlerinnen und Fachwissenschaftler fiel jedoch gemischt aus. Dies lag vor allem daran, dass der ursprünglichen Darstellung einschließlich aller Suchfunktionen und Details ein hoher Wert beigemessen wurde, diese aber bei Überführung in einen generischen Viewer nicht vollständig erhalten werden konnten. Das Problembewusstsein für das Thema Langzeitverfügbarkeit der gesamten Anwendung stand hinter diesen Gesichtspunkten zurück. Der Sinn des Migrationsversuchs verstand sich daher nicht von selbst. Erst eine intensive und individuelle Auseinandersetzung im Gespräch konnte eine gewisse Akzeptanz für das Ergebnis erzielen. Erforderliche Nachbesserungen des Prototypen stellten in der Regel weniger eine technische als vielmehr eine kommunikative Herausforderung dar, weil es oft um Änderungen der Darstellung im Detail ging, deren Bedeutung für Fachfremde nicht unmittelbar ersichtlich ist. Selbst wenn das globale Layout der Darstellung nahezu beliebig verändert werden kann, kommt bestimmten Teilaspekten wie Gliederung oder Interpunktion unter Umständen dennoch eine große Bedeutung zu.

Insgesamt zeichnete sich ab, dass eine solche Migrationsstrategie schon bei Anwendungen geringerer Komplexität einen hohen Aufwand seitens des Datenzentrums erforderlich macht, um zu einem für die Wissenschaftlerinnen und Wissenschaftler akzeptablen Ergebnis zu führen. Die Abwägung zwischen Anpassungsaufwand und Zusatznutzen führte zu einer Entscheidung zugunsten einer Konservierung der unveränderten Anwendung in Form einer Virtualisierung (auf einem abgesicherten Server) als Bestandteil des Angebotsportfolios. Diese sogenannte Anwendungskonservierung wird ohne tiefergehende technische Eingriffe solange betrieben, wie in der aktuellen Umgebung die Funktionalität der einzelnen Komponenten gewährleistet ist – auch unter Berücksichtigung von Sicherheitsaspekten.

5.2 Teilergebnisse: Opus Postumum (Kant-Edition)

Das Opus Postumum Immanuel Kants stand dem HDC exemplarisch für den Forschungsdatentyp digitale Edition zur eingehenden Analyse zur Verfügung. Darüber hinaus treiben mit BBAW und SUB zwei der HDC-Konsortialpartner größere digitale Editionsprojekte voran, so dass sich gute Möglichkeiten für einen Austausch ergaben. Abstrakt bekannt, aber erst durch konkrete Beispiele wirklich erfassbar, war das folgende Dilemma: Mit der in XML-TEI ausgezeichneten Transkription liegen einerseits hochgradig strukturierte Daten vor, die einen enormen Aufwand bei der Erfassung bedeuten und prinzipiell vielfältige Möglichkeiten der technischen Verarbeitung bieten. Andererseits ist TEI ein Standard der in hohem Maße darauf ausgelegt ist, die Auszeichnung an die individuellen Erfordernisse eines Projektes anpassen zu können. Schon auf Ebene der verwendeten Auszeichnungskonventionen ergeben sich somit Inkompatibilitäten zwischen verschiedenen Editionsprojekten.

Ein Ziel der Arbeit am Prototypen Kant-Edition war die Klärung der Umsetzungsmöglichkeiten für sogenannte generische Viewer (nicht nur für Editionsprojekte). Dahinter steht die Idee, verschiedene Editionen nach der Überführung in ein Forschungsdatenzentrum in einer generischen Umgebung anzeigen zu können. Der DFG-Viewer[58] zur Anzeige von Digitalisaten kann als bereits umgesetztes Instrument gut zur Illustration der grundsätzlichen Möglichkeiten herangezogen werden. Ebenso wie bei der Berliner Klassik stellte sich aber heraus, dass mittelfristig wohl nur eine Anwendungskonservierung eine breitere Akzeptanz bei den Nutzerinnen und Nutzern erlangen kann, wenn es um die Langzeitverfügbarkeit einer digitalen Edition als Webanwendung geht. Die Idee des generischen Viewers wird weiterverfolgt, aber aufgrund der begrenzten Projektressourcen vorerst zurückgestellt.

Die zugrunde liegenden Daten, im Falle der Kant-Edition also TEI-kodierte Transkriptionen und Annotationen sowie die Digitalisate des Manuskripts, können aber auch über die Lebensdauer einer Anwendungskonservierung hinaus einen Wert an sich darstellen. Eine objektbasierte Archivierung dieser Daten wird daher seitens des HDC im Rahmen des Angebots Repositorium angestrebt und an geeigneten Verfahren gearbeitet. Insbesondere sollen die Möglichkeiten von TEI, aber etwa auch des im LZA-Kontext gebräuchlichen Standards METS[59] ausgereizt werden, um die abschnittsweise Verknüpfung zwischen Transkription und Faksimile abzubilden. Im Rahmen eines Beratungsangebots des HDC böte sich perspektivisch die Gelegenheit, darauf hinzuwirken, dass bei künftigen Editionsprojekten etwaige Verknüpfungen möglichst konsequent innerhalb der Daten abgebildet und nicht erst über die Anwendungslogik hergestellt werden.

5.3 Teilergebnisse: Global Migration Flows

In der HDC-Designphase wurde die Überführung der oben beschriebenen Anwendung Global Migration Flows in eine virtuelle Maschine getestet. Hierfür wurde die Server-Client-Struktur auf Seiten des Datengebers vorbereitet, d.h. um überflüssige und unerwünschte Bestandteile bereinigt und um eine für die Überführung ausreichende Dokumentation der technischen Spezifikationen ergänzt. Danach wurde die Umgebung geklont und auf eine den Spezifikationen entsprechende virtuelle Maschine überführt.

Im Rahmen dieser Testüberführung zeigte sich, dass sich aus der Mehrschichtigkeit von Datenvisualisierungen für ein Datenzentrum zwei Herausforderungen ergeben. Zum einen besteht die Notwendigkeit zur Überführung der vollständigen Server-Client-Struktur. Dies schließt auch Abhängigkeiten von externen Anwendungen wie etwa Geoinformationssystemen (GIS), Normdateien (wie bspw. die GND) oder Schriftarten ein. Der hierfür in Betracht zu ziehende Arbeitsaufwand ist stark davon abhängig, wie aufwendig sich die Bereinigung beziehungsweise Anpassung der Server-Client-Struktur im Einzelfall gestaltet. Prinzipiell handelt es sich hierbei um eine Aufgabe im Verantwortungsbereich des Datengebers, nicht des Infrastrukturanbieters, der idealerweise im Vorfeld die für die Überführung notwendigen Anpassungen vornehmen müsste, um den Ingest-Spezifikationen zu entsprechen. Zum anderen ist es unklar, für wie lange die Bereitstellung seitens des Datenzentrums garantiert werden kann, wobei vor allem die Bereitstellung der konservierten Anwendung nach außen kritisch ist. Früher oder später kommen diesbezüglich aufgrund veraltender Komponenten IT-spezifische Sicherheitsfragen zum Tragen. Hier ist dann ggf. auch eine Authentifizierungsschicht notwendig.

5.4 Schlussfolgerungen

Aus den exemplarischen Testübernahmen während der HDC-Designphase lassen sich folgende Schlussfolgerungen für die Angebotsgestaltung geisteswissenschaftlicher Forschungsdatenzentren ziehen:

Angesichts der zunehmend komplexer werdenden Datenstrukturen in den Geisteswissenschaften sind seitens eines Forschungsdatenzentrums Angebote gefragt, die über objektbasierte Lösungen, wie bspw. ein Repository, hinausgehen. Lösungen für komplexere Archivierungsfälle gehen meist mit einem größeren Aufwand für die Infrastrukturanbieter, etwa bezüglich des Ingests und der Kuration, einher, ebenso aber auch im Bereich der IT-Sicherheit, wenn es bspw. um die Konservierung von Umgebungen zu einem bestimmten Zeitpunkt geht.

Für die Entwicklung generischer Viewer (z.B. für digitale Editionen oder Datenbanken), die den wissenschaftlichen (Detail-)Anforderungen der datengebenden und der datennutzenden Wissenschaftlerinnen und Wissenschaftler entsprechen, sind eine enge Zusammenarbeit mit der Community und ein erheblich höherer Mitteleinsatz als ursprünglich geschätzt notwendig.

Forschungsdatentypenspezifische Angebote müssen durch zielgerichtete, individuelle Beratungs- und Unterstützungsangebote hinsichtlich einer möglichst effizienten Überführung der Daten in ein Forschungsdatenzentrum abgerundet werden, um die Wissenschaftlerinnen und Wissenschaftler auf diesem Gebiet zu entlasten.