In den vorangegangenen zwei Kapiteln wurden Hauptfaktoren bei der Erstellung, Leistungsfähigkeit und technischen Implementierung von Software-Emulatoren identifiziert und klassifiziert, welche die Reproduktion des dynamischen Objekts auf konzeptueller Ebene beeinflussen. Auch wurden Lösungen und Alternativen im Zusammenhang mit dem verbundenen Aufwand aufgezeigt, soweit es überhaupt Lösungsansätze geben kann.

Ansatzbedingt und im Rahmen organisatorischer Arbeitsprozesse in den OAIS-Teilbereichen Ingest (Transfer), Preservation Planing (Bewahrung) und Access (Zugang) existieren weitere Grenzen und Herausforderungen, die zwar nicht den Kern dieser Arbeit bilden, aber dennoch im Kontext der Emulationsstrategie betrachtet werden müssen. Die folgenden Betrachtungen bilden einen komprimierten Überblick aktueller Forschungsgegenstände, offenbaren weitere harte Grenzen sowie Herausforderungen der Emulationsstrategie und bilden im Rahmen der Langzeitbewahrung komplexer dynamischer Objekte Ansatzpunkte für weitere Forschungsfragen.

Hinweise auf offene Punkten sind wieder im Bereich der elektronischen Kunst zu finden, da diese sich oft mit „Grenzfällen“ beschäftigt. Besser^[1]Besser, H.: Longevity of Electronic Art. In: ICHIM (2001). beschreibt spezifische Probleme anhand charakteristischer Merkmale elektronischer Kunst. So besitzen elektronische Kunstwerke keine fixity (Beständigkeit) und sind in ihrer Zusammenstellung sehr dynamisch (z.B. bei Web-Werken). Die Werke ändern sich bei jeder Betrachtung und im Verlauf der Zeit. Auch sind die Grenzen des Werkes bei dynamischer Zusammenstellung nicht immer festschreibbar.^[2]vgl. ebenda, S. 267f. Auch stellt sich in diesen Fällen die Frage, welche Authentizitätskriterien für das Werk bestehen. Der Autor führt zudem an, dass gewisse elektronische Kunst Situations- und Interaktionsgebunden ist (vergleichbar mit einem Live-Konzert). Diese inhärente Flüchtigkeit kann nicht reproduziert werden.^[3]vgl. ebenda, S. 269.

Diese Beispiele verdeutlichen eine weitere implizite Bedingung der Emulationsstrategie. So wird von der „Geschlossenheit“ des dynamischen Objektes auf physischer und logischer Ebene ausgegangen. Ist nicht feststellbar, welche Komponenten Teil des dynamischen Objekts sind oder erfolgt diese Zusammenstellung ebenfalls dynamisch, so bricht die Verwendbarkeit der Bewahrungsstrategie zusammen. Es kommt zu einer Fragmentierung des Objekts, die bereits beim Ingest berücksichtigt werden muss. Dies ist verstärkt bei Internet-basierten Objekten zu beobachten, deren Verlinkung flüchtig und kontextgebunden ist.

5.1 Internet-basierte, fragmentierte dynamische Objekte

Internet-basierte Objekte, wie Webseiten oder Online-Spiele sind inhärent fragmentiert. Hyperlinks ermöglichen die Verschränkung mit weiteren Komponenten unabhängig von deren Speicherort. Online-Spiele benötigen neben dem Client-Programm auf dem Rechner die Verbindung zu einem oder mehreren externen Spielservern, auf dem weitere Ressourcen liegen und über den die Verbindung zu anderen Spielern hergestellt und gelenkt wird. Es ist somit keine klare Trennung der einzelnen Objektteile mehr möglich, die Grenzen der zu erfassenden logischen Objekte können nicht einfach ermittelt werden. Bei Webprojekten beispielsweise stellt sich die Frage, bis zu welcher Verlinkungstiefe externe Ressourcen erfasst und archiviert werden müssen bzw. technisch können und rechtlich dürfen.

Die Wichtigkeit der Bewahrung komplexer WWW-Artefakte wurde erkannt und es existieren diverse Forschungsprojekte und Fallstudien, hauptsächlich im Kontext des Sammlungsauftrags von Nationalbibliotheken. Einen Überblick auf Web-Bewahrungsinitiativen bietet Day.^[4]Day, M.: Preserving the fabric of our lives: a survey of Web preservation initiatives. In: Koch, T.; Sølvberg, I. T. (Hrsg.): Research and Advanced Technology for Digital Libraries, 7th European … Continue reading Als Herausforderungen werden vor allem technische und rechtliche Fragestellungen der Datenakquise (Ingest) genannt.^[5]vgl. ebenda, S. 464f. Bereits beim Ingest müssen Preservationsaktivitäten mitbedacht werden, die Manipulationssicherheit und Vollständigkeit des Archivs muss gewährleistet werden.^[6]ebenda, S. 469.

Jeder verlinkte Teil einer Webseite kann dynamisch generierte und/oder multimediale sowie interaktive Inhalte (wie Adobe Flash) besitzen, wodurch selbst statische Seiten im Gesamtzusammenhang eine dynamische Komponente erhalten. Um diese Klasse von Objekten in ihrem historischen Kontext zu betrachten sind Emulatoren notwendig, welche die Verbindungen zu externen Komponenten auf anderen Rechnersystemen ebenfalls nachahmen können. Der Diskurs um die Emulationsstrategie wurde bisher immer systemzentrisch geführt. Die Emulation der Netzwerkverbindungen zu externen Servern bildet hier eine neue Anforderung, da Interaktion mit anderen Systemen bis jetzt nicht im Fokus der Entwicklung stand und selten implementiert ist. Aktuelle Software-Emulatoren benötigen zudem ein geschlossenes logisches Objekt in Form von Abbildern (Images). Bei fragmentierten Objekten kann ein solches abgeschossenes Abbild nicht erstellt werden.

In Longs Arbeit werden erste Experimente zur Langzeitbewahrung von Webarchiven durch Emulatoren durchgeführt.^[7]Long, A. S.: Long-Term Preservation of Web Archives – Experimenting with Emulation and Migration Methodologies [= International Internet Preservation Consortium (IIPC) (Hrsg.): Report], … Continue reading Long beschreibt das komplexe Wechselspiel von zur Betrachtung von Webressourcen notwendiger Zusatzsoftware, Plug-Ins und Treibern, welche die Emulation erschweren.^[8]vgl. ebenda, S. 14ff. Zudem bereitete die korrekte Identifikation multimedialer und dynamischer Webkomponenten Probleme. Gängige Formatbibliotheken wie JHOVE^[9]JSTOR/Harvard Object Validation Environment, eine Formatdatenbank. Siehe Website unter http://jhove.sourceforge.net/. konnten nur 87,51% der untersuchten Dateien korrekt identifizieren.^[10]vgl. Long, A. S.: Long-Term Preservation of Web Archives – Experimenting with Emulation and Migration Methodologies [= International Internet Preservation Consortium (IIPC) (Hrsg.): Report], … Continue reading Hier ist weitere Forschungsarbeit notwendig.

Eine weitere Bewahrungsanforderung fügen sogenannte massively multiplayer online role-playing games (MMORPG, engl. für „Massen-Mehrspieler-Online-Rollenspiel“), virtuelle Welten und weitere Mischformen hinzu, da durch die gleichzeitige Mehrspieler-Bedienung komplexe Interaktionen entstehen, die entscheidend für das Spielerlebnis sind. Das Verhalten der anderen „Spieler“ sowie die soziale Interaktion sind Teil des Spiels und müssen bewahrt werden.^[11]vgl. uttenbrunner, M.; et al.: Keeping the Game Alive: Evaluating Strategies for the Preservation of Console Video Games. In: Internatio­nal Journal of Digital Curation, Volume 1, Issue 5, … Continue reading Das Objekt entsteht auf konzeptueller Ebene erst durch die Netzanbindung und Interaktion mit Rechnerexternen Ressourcen bzw. Spielern.

In [McDonough u.a. 2010]^[12]McDonough, J.; et al.: Preserving Virtual Worlds – Final Report. 2010. findet sich ein detaillierter Bericht über die fehlgeschlagenen Versuche der Autoren, die virtuelle Welt Second Life zu archivieren und zu bewahren. Da Nutzer/-innen fast den gesamten Content der virtuellen Umgebung selbst erzeugen, bilden die sozialen, politischen und ökonomischen Aspekte der Aktivitäten eine zentrale Eigenschaft des Spiels. Demgegenüber muss die Bewahrung auf technischer Ebene realisiert werden. Da Linden Lab, der Hersteller des Systems, nicht über die notwendigen Ressourcen verfügt, die Langzeitbewahrung des Spiels zu realisieren, musste eine vom Hersteller unabhängige Lösung gefunden werden. Alle Komponenten der technischen verteilten Netzwerkumgebung (als zentral wurden u.a. benannt Login Server, User Server, Space Server, Data Server und weitere Simulatoren) müssen über Emulationsumgebungen zur Verfügung gestellt werden. Sämtliche Serverkomponenten sind jedoch nicht im Quellcode vom Hersteller verfügbar. Jegliche Bewahrung hätte eine Re-Implementierung des Serverkonzeptes zur Folge gehabt, was ökonomisch nicht leistbar war. Zudem gab es keine einfache Möglichkeit, den Spielinhalt von den jeweiligen Serverkomponenten zu extrahieren.^[13]vgl. ebenda, S. 89ff. Die Anbindung an proprietäre Komponenten und die Komplexität verteilter Online-Systeme müssen weiter erforscht und es müssen Schnittstellen zum Datenaustausch bzw. Datenexport für die Langzeitbewahrung geschaffen werden. Neuartige, rein digitale Distributionsmechanismen, wie spielinterne Käufe von virtuellen Gütern und nachladbaren Inhalten (Downloadable Content, DLC) führen zudem zur weiteren Fragmentierung des Spielobjekts. Die Frage der Einpflegung dieser Zusatzinhalte in ein Langzeitarchiv ist bisher ungeklärt.

Soziale Netzwerke

Eine ähnliche Klasse dieser Objekte stellen soziale Netzwerke wie Facebook oder der Kurznachrichtendienst Twitter da. Ihre Struktur entsteht ebenso durch die soziale Interaktion von Menschen über die Plattform und ist nicht statisch abbildbar. Veränderungen des Netzwerks durch die Nutzer erfolgen im Sekundentakt. Bei einer einfachen Sicherung der Datenbank geht dieser zentrale Aspekt jedoch verloren.^[14]vgl. McCown, F.; Nelson, M.: What happens when facebook is gone? In: Proceedings of the 9th ACM/IEEE-CS joint conference on Digital libraries, Austin, TX, U.S.A., 2009, S. 251–254. Eine Emulation des Systems ohne Nutzerbeteiligung würde nur einen statische „Momentaufnahme“ darstellen.

Da diese Netzwerkdienste von Firmen betrieben werden, welche die Daten der Nutzer kommerziell verwerten, ist eine Extraktion des gesamten Datenbestandes durch Dritte weder vorgesehen noch erwünscht. In [McCown und Nelson 2003]^[15]ebenda. wurden am Beispiel von Facebook Möglichkeiten untersucht, Daten aus geschlossenen sozialen Netzwerken zum Zwecke der Langzeitarchivierung zu extrahieren. Als Hindernis wurde die fehlende Möglichkeit gesehen, die Seiten mittels sogenannter Crawler technisch automatisiert zu durchsuchen, um Daten zu extrahieren. Für den eigenen Nutzeraccount sind keine Exportmöglichkeiten vorhanden. Die Terms of Use (Allgemeine Geschäftsbedingungen) von Facebook verbieten explizit die Benutzung von Data-Mining-Techniken wie Crawlern oder Robots^[16]vgl. ebenda, S. 251 f. Hier muss für die Nutzer Rechtssicherheit geschaffen werden, selbsterstellte Inhalte extrahieren zu können.

Die Autoren sehen zudem die Emulationsstrategie als notwendig an, um neben dem eigentlichen Inhalt (bestehend aus Texten, Bildern und Videos), das Look-and-Feel und die Interaktionsmöglichkeiten mit dem System zu bewahren.^[17]vgl. ebenda, S. 252.

Im Jahre 2010 hat die U.S.-amerikanische Library of Congress angekündigt, das gesamte Archiv des Netzwerkes Twitter erworben zu haben und einer Langzeitbewahrung zuzuführen.^[18]Siehe Nachricht auf LOC-Blog unter http://blogs.loc.gov/loc/2010/04/how-tweet-it-is-library-acquires-entire-twitter-archive/.

Im Januar 2013 wurde ein Report mit ersten Erkenntnissen von der Library of Congress veröffentlicht.^[19]Library of Congress (Hrsg.): Update on the Twitter Archive At the Library of Congress.Online-Report, January 2013. Das Archiv hat öffentlich zugängliche Nachrichten (genannt Tweets) von 2006 bis 2010 in einem Kernarchiv gesammelt. Privat geschaltete Tweets wurden nicht erfasst. Das Kernarchiv umfasst 21 Milliarden Tweets. Seit 2010 werden alle öffentlichen Tweets in regelmäßigen Intervallen in das Archiv eingefügt. Im Januar 2013 umfasste das Archiv bereits 170 Milliarden Tweets, welche 133,2 Terabyte Speicherplatz beanspruchen (als zwei komprimierte Kopien).

Bisher ungeklärt ist, in welcher Form die Nachrichten für Bibliotheksnutzer/-innen und Forscher/-innen zur Verfügung gestellt werden können. Die Aufbereitung und Zugänglichmachung des Archivs ist im Vergleich zur Erzeugung, Speicherung und Verteilung von großen Datennmengen (Big Data) wenig fortgeschritten:

Zudem verbietet die Nutzungsvereinbarung mit Twitter eine zeitnahe Auswertung. Es dürfen nur Auszüge des Archivs – frühestens sechs Monate nach Einspeisung – und ausschließlich an “bona fide” researchers zu nicht-kommerziellen Zwecken zugänglich gemacht werden.^[21]ebenda, S. 2. Die Weiterveröffentlichung ist ebenfalls ausgeschlossen und ein entsprechendes Abkommen muss von interessierten Forscher/-innen bzw. Nutzer/-innen im Vorfeld unterzeichnet werden. Die Nutzungsmöglichkeiten des Archivs werden somit durch rechtliche Rahmenbedingungen empfindlich eingeschränkt. Die Bibliothek konstatiert nüchtern: “The Library cannot provide a substantial portion of the collection on its web site in a form that can be easily downloaded”.^[22]ebenda, S. 2.

5.2 Imageerstellung, Transfer vom ursprünglichen Speichermedium

Wie in Abschnitt 2.4.3 ausgeführt, müssen die physischen Datenobjekte zum Ingest in ein Archiv einer Datenmigration unterzogen werden. Die Daten müssen vom ursprünglichen Trägermedium extrahiert werden. Für die Emulation kommt die Umwandlung in ein für Emulatoren geeignetes logisches Format hinzu, dass ein Abbild (Image) des ursprünglichen Datenträgers repräsentiert. Es ist also eine Transformation des Objektes bei der Extraktion notwendig. Bereits hier können bei dynamischen Objekten wie Computerspielen unter Umständen Verluste auftreten. So sind ältere Spiele für Heimcomputer auf magnetischen oder optischen Datenträgern wie Disketten oder CDs häufig mit einem physischen Kopierschutz versehen. Bei CDs wurden an spezifischen Stellen winzige Löcher eingebracht, die beim Auslesen dieser Stelle einen Lesefehler produzieren. Dieses Loch (und damit der Fehler) kann von einem CD-Brenner jedoch nicht kopiert bzw. erzeugt werden. Bei jedem Start wird durch das Auslesen der betreffenden Stelle vom Spiel geprüft, ob der Fehler vorhanden ist. Gibt das System keinen Lesefehler zurück, so handelt es sich um eine Kopie und das Spiel wird beendet. Bei Disketten wurde mit Abweichungen der Leseparameter der Magnetspuren gearbeitet, die zwar von Diskettenlaufwerk des Heimcomputers gelesen, nicht jedoch erzeugt werden konnten.

Zur Bewahrung dieser Objekte müssen Datenformate für Images entwickelt werden, die in der Lage sind, diesen komplexen Sachverhalt abzubilden. Einen ersten Vorstoß stellt das Interchangeable Preservation Format (IPF) der Software Preservation Society dar. Dieses größtenteils Community-betriebene Projekt bietet mit dem selbst entwickelten KryoFlux-Diskettencontroller und dazugehöriger Software ein – allerdings kommerziell vertriebenes – Bewahrungswerkzeug für Archive und Bibliotheken an, welches in der Lage ist, solche Images von Disketten zu erzeugen.^[23]Siehe Produktwebsite unter http://www.kryoflux.com/.

Für Spielkonsolen, bei denen die Spiele auf ROM-Modulen bereitgestellt werden, stellt sich zusätzlich das Problem der Entwicklung geeigneter Geräte zum Auslesen und Transfer der enthaltenen Daten.

Die Frage nach einer geeigneten Abbildung der Trägermedien stellt sich insbesondere bei der Mischung digitaler und analoger Daten. So enthielten kommerziell vertriebene Datenkassetten des Atari 800 XL neben den digital gespeicherten Daten eine analoge Audio-Magnetspur, die auch mit einem normalen Kassettenrekorder wiedergegeben werden konnte. Diese Musik diente beim Laden des Programms gleichzeitig als „Wartemusik“ oder Titelmelodie für das enthaltene Spiel. Für die Datenkassetten des Atari existiert bisher kein Speicherformat, das in der Lage ist, die analogen und digitalen Komponenten des Mediums zu erfassen. Ähnlich verhält es sich mit den in Deutschland vor allem von Pioneer ab 1986 unter dem Namen „Laser-Disc“ (LD) vermarkteten Bildplatten (standardmäßig mit 30 cm, ferner mit 20 oder 12 cm Durchmesser), die auch eine gewisse Bedeutung für die Spieleentwicklung hatten (insbes. in Gestalt „interaktiver Filme“ wie Dragon’s Lair). Als Weiterentwicklung des von Philips 1982 eingeführten „Laser-Vision“-(LV-) Systems enthielten LaserDiscs zusätzlich zum analogen Videosignal eine digitale Audiospur. Es ist nicht trivial möglich, ein digitales Abbild (Image) dieses analog und digital codierten Systems zu erstellen.

Eine verwandte Problematik stellt die Verwendung von Mixed-Mode-CDs dar, die neben Daten- auch Audiotracks enthalten und u.a. bei PlayStation-Spielen eine große Verbreitung fanden. Obwohl hier die Daten vollständig in digitaler Form vorliegen, konnten bei diesem erweiterten Format viele Leseprogramme bzw. CD-Laufwerke die zur Erstellung eines exakten Abbilds notwendigen Zusatzinformationen (wie Pregap-Daten) oder die durch unterschiedliche logische Sektorenaufteilung der verschiedenen CD-Tracks entstandenen Fehlerkorrekturdaten nicht vollständig auslesen bzw. bereitstellen. Es bildeten sich daher verschiedene (teils inkompatible) Dateiformate inklusive emulatorspezifischer Eigenentwicklungen heraus (z. B. ISO-, BIN/ CUE- oder RAW-Format).

5.3 Emulator als dynamisches Objekt

Letztlich stellt sich die Frage nach dem Lebenszyklus eines Emulator-Programms, welches selbst ein komplexes dynamisches Objekt darstellt, das erhalten werden muss. Als solches ist die konkrete technische Implementierung an bestimmte Betriebssysteme und Plattformen gebunden – im Fall der Verwendung von dynamischer Rekompilierung (siehe Abschnitt 3.6.1) sogar an eine Rechnerarchitektur. Die Software unterliegt den gleichen Abhängig

keiten und Alterungsprozess-bedingten Interpretationsproblematik, wie alle digitalen Objekte. Thibodeau fasst die Problematik zusammen und nennt erste Strategien:

In der Tat wurden verschiedene Bewahrungsstrategien für Emulatoren vorgeschlagen, die entweder auf Migrationstechniken, Re-Implementierung oder ebenfalls auf Emulation und Emulationsplattformen basieren. Organisatorisch gehört die Bewahrung von Emulatoren zu den Bereichen Preservation Planing und Administration im OAIS-Modell. In [von Suchodoletz 2009] wird ein Überblick der verschiedenen Ansätze gegeben^[25]vgl. von Suchodoletz, D.: Funktionale Langzeitarchivierung digitaler Objekte. Dissertation, Freiburg: Albert-Ludwigs-Universität Freiburg, 2009, Kapitel 4.8 sowie konzentriert in van der Hoeven, … Continue reading Suchodoletz nennt Softwaremigration, „geschachtelte“ Emulation sowie die Entwicklung von Emulatoren für abstrakte Rechnerarchitekturen inklusive des Sonderfalls des Universal Virtual Computers als Strategien zur Langzeitverfügbarkeit von Emulatoren.

Die Softwaremigration befasst sich mit der Rekompilierung des Emulators auf die jeweils aktuelle Generation von Betriebssystemen und Rechnerarchitekturen. Eine Migration komplexer Software ist ökonomisch sehr aufwendig und steht im Widerspruch zu den in den Abschnitten 2.2 und 2.4.3 genannten Anforderungen und Machbarkeitskriterien. Dementsprechend kann die Strategie nur in sehr engem Rahmen und unter bestimmten Voraussetzungen diskutiert werden. Dirk von Suchodoletz nennt Vorbedingungen an den Software-Emulator. Das Programm muss die Zielplattform komplett nachbilden und darf keine direkte Nutzung von Funktionen oder Eigenschaften des Hostsystems (siehe Abschnitt 3.6.1) beinhalten.^[26]vgl. von Suchodoletz, D.: Funktionale Langzeitarchivierung digitaler Objekte. Dissertation, Freiburg: Albert-Ludwigs-Universität Freiburg, 2009, S. 105. Im Hinblick auf das Translationsproblem der Schnittstellenmigration, den daraus erwachsenen Zusatzfunktionen (siehe Abschnitt 4.2) sowie notwendiger Funktionserweiterung (siehe Abschnitt 3.3) muss jedoch bezweifelt werden, ob ein solcher Emulator überhaupt technisch umsetzbar ist. Eine weitere Voraussetzung ist das Vorliegen des Quellcodes für den Emulator, um eine Migration des Quelltextes überhaupt zu ermöglichen. Ebenfalls muss der Emulator in einer Programmiersprache geschrieben sein, für die auf dem Hostsystem ein geeigneter Compiler vorhanden ist und der alle benötigten Funktionen der Sprache adäquat umsetzen kann.^[27]vgl. ebenda, S. 105. Die Quelloffenheit ist bisher eines der wesentlichen Merkmale, das sich vorwiegend in Community-Emulatoren wiederfindet (siehe Abschnitt 4.3).

Nur unter diesen engen Voraussetzungen kann eine Migration überhaupt stattfinden. Eine erste Fallstudie wurde innerhalb des CAMiLEON-Projektes durchgeführt. Die testweise Migration eines Emulators schlug dabei aufgrund der Nichteinhaltung der o.g. Faktoren fehl.^[28]vgl. Holdsworth, D.; Wheatley, P.: Emulation, Pre­servation and Abstraction. CAMiLEON Project.In: RLG DigiNews, Volume 5, Issue 4, 2001. Zwar war der betreffende Emulator quelloffen, jedoch fehlte die notwendige Dokumentation, um Anpassungen für das Zielsystem vorzunehmen. Die Autoren kommen zu dem Schluss, dass das Konzept nicht praktikabel sei, sehen jedoch Verbesserungsmöglichkeiten durch eine verstärkte Abstraktion des Emulationsinterface zum Hostsystem und der Verwendung der Programmiersprache C.

Rothenberg versucht eine Verschiebung der Aufgabenstellung dieses Prozesses in die Zukunft, indem er eine abstrakte Emulatorspezifikation vorschlägt, aus der automatisiert Emulator-Programme generiert werden können (siehe Abschnitt 3.2.1). Würde dies gelingen, so wäre der Ansatz losgelöst von einer bestimmten Programmiersprache oder Rechnerarchitektur. Rothenberg selbst kann allerdings keine technische Umsetzung und Definition dieser ansatzbedingt allgemein und dauerhaft gültigen Beschreibungssprache nennen, die in der Lage ist, alle Facetten bestehender und künftiger Systeme in ausreichendem Maß zu erfassen. Er selbst setzt die Bedingung, dass sein vorgeschlagener Ansatz nur ökonomisch und pragmatisch sinnvoll ist, solange die Generierung des Emulators automatisiert aus der Spezifikation erfolgen kann.^[29]vgl. Rothenberg, J.: Using Emulation to Preserve Digital Documents. Den Haag: Koninklijke Bibliotheek (RAND-Europe), 2000, S. 40.

Einen Schritt in diese Richtung geht die Idee der Programmierung eines Emulators für eine abstrakte Rechnerarchitektur, technisch repräsentiert durch eine virtuelle Maschine.^[30]vgl. von Suchodoletz, D.: Funktionale Langzeitarchivierung digitaler Objekte. Dissertation, Freiburg: Albert-Ludwigs-Universität Freiburg, 2009, S. 105. Zentral ist wieder die Verschiebung des Arbeitsaufwands von der Re-Implementierung der jeweiligen Emulatorprogramme auf die theoretisch kostengünstigere Migration, Re-Implementierung bzw. Emulation der virtuellen Maschine. Obwohl der Fokus verlagert wird, bleiben die Probleme der Bewahrung komplexer dynamischer Objekte davon unberührt bzw. ebenso ungelöst. Das zu bewahrende dynamische Objekt ist in diesem Fall das Programm, welches die virtuelle Maschine technisch umsetzt oder emuliert. Diese zirkuläre bzw. rekursive Anwendung der Bewahrungsstrategien erkennt auch Rothenberg und sieht eine daraus resultierende ständig steigende Komplexität der Bewahrung.^[31]vgl. Rothenberg, J.: Using Emulation to Preserve Digital Documents. Den Haag: Koninklijke Bibliotheek (RAND-Europe), 2000, S. 41.

Aus pragmatischen Gründen wird für die Durchführung dieses Ansatzes in der Regel statt einer Eigenentwicklung bestehende Software in Form der Java Virtual Machine (JavaVM) verwendet. Java ist ein Produkt der Firma Oracle (ursprünglich entwickelt von SUN), das kostenlos angeboten wird und für dessen Spezifikation alternative Open-Source-Implementierungen existieren.^[32]Oracle selbst stellt nur den Quellcode der JavaVM bis Version 6 (im Rahmen einer Java Research License) zur Verfügung. Java bildet den de facto Standard für virtuelle Maschinen mit Implementierungen für alle derzeit populären Betriebssysteme. Die JavaVM kommt u.a. bei den Forschungsprojekten KEEP und PLANETS (siehe Abschnitte 3.2.3 und 3.2.4), Community-Emulatoren, wie JaC64 oder JPC (siehe Tabelle 1) sowie dem Forschungsemulator Dioscuri (siehe Abschnitt 4.3.5) als technologische Basis zum Einsatz. Generell existiert jedoch noch wenig langfristige Praxiserfahrung. Die verschiedenen, nur begrenzt abwärtskompatiblen^[33]Siehe Kompatibilitätsübersicht des Herstellers Oracle unter http://www.oracle.com/technetwork/java/javase/compatibility-137541.html. Versionen der JavaVM lassen jedoch einen ähnlich innovationsgetriebenen Verlauf ohne Berücksichtigung der Anforderungen für Langzeitarchive wie bei kommerziellen virtuellen Maschinen erkennen (siehe Abschnitt 4.3.4). Der Ansatz stößt durch die Abhängigkeit von der JavaVM-Software auf eine weitere ökonomische und pragmatische Grenze.

Eine Variante dieses Ansatzes und bisher einzige Eigenentwicklung stellt das von Lorie und der IBM vorgeschlagene Konzept des Universal Virtual Computers (UVC) dar.^[34]vgl. u. a. Lorie, R.: Long term preservation of digital information. In: JDCL ’01 Proceedings of the 1st ACM/IEEE-CS joint conference on Digital libraries, Roanoke, VA, U.S.A., 2001. Das Konzept basiert auf einer VM und stellt eine auf dieser Maschine ausgeführte Beschreibungssprache für die Dekodierung von Objekten zur Verfügung. Auch hier muss die VM auf künftige Hardwarearchitekturen migriert werden. Zur Interpretation und Darstellung des dynamischen Objekts auf dem UVC müssen spezielle Decoder-Programme in der Beschreibungssprache des UVC entwickelt werden, die essenzielle Eigenschaften eines Dateiformates logisch kodieren.^[35]vgl. ebenda, S. 11. Lorie ignoriert die Aspekte und Anforderungen an die Translation der Ein- und Ausgabemechanismen und konzentriert sich auf den CPU-Teil und die technische Spezifikation der Maschine. Er sieht das System als dokumentbasierten bzw. stark dokumentzentrischen Ansatz.^[36]vgl. ebenda, S. 12f. Der UVC-Ansatz setzt zudem voraus, dass Entwickler von (dynamischen) digitalen Objekten gleichzeitig einen Decoder für den UVC schreiben. Lorie sieht die Programmierer in der Pflicht: “[W]hoever creates a new data format needs to produce a UVC program to decode the data”^[37]ebenda, S. 15. Dieser Aufruf dürfte jedoch unter den Realweltbedingungen kommerzieller Softwareentwicklung ökonomisch kaum umsetzbar sein.

Dementsprechend führte Lorie erste Fallstudien mit selbst entwickelten Decoder-Programmen und nur einfachen statischen Objekten bzw. Dateiformaten durch.^[38]vgl. Lorie, R.: The UVC: a Method for Preserving Digital Documents – Proof of Concept. IBM/KB Long-term Preservation Study. Amsterdam, 2002. Bereits die Anforderungen dieser Formate machten eine Anpassung des Prototypen und der UVC-Architektur erforderlich.^[39]vgl. ebenda, S. 15. Die Erstellung eines Decoders für JPEG-Bilder (einem verlustbehaftet komprimierten Bildformat) brachte “serious challenges” und machte die Entwicklung neuer CPU-Befehle für den UVC notwendig. Auch stellte sich die Implementierung des Decoders im selbst entwickelten UVC-Assembler als umständlich, komplex und zeitaufwendig heraus.^[40]vgl. ebenda, S. 27.

Ein abschließender Forschungsbericht der ersten Fallstudien, Prototypen und Weiterentwicklungen des Systems kommt daher zum Schluss, das der UVC-Ansatz nur für einfache statische Objekte anwendbar sei und den Anforderungen multimedialer, dynamischer Objekte nicht genüge und daher für diese nicht anwendbar sei.^[41]vgl. Lorie, R.; van Diessen, R.: UVC: A universal virtual computer for long-term preservation of digital information. In: IBM Research Report, RJ 10338, 2005.

Ein letzte diskutierte Möglichkeit bietet das Konzept der Emulator-Schachtelung. Unter der Annahme, dass zumindest für die jeweils letzte Generation von Rechnersystemen Emulatoren für dann aktuelle Systeme entwickelt werden, wird die Möglichkeit diskutiert, Emulatoren der vorletzten Generation als dynamisches Objekt innerhalb des Emulators für die letzte Rechnergeneration auszuführen. Diese Schachtelung in Schichten nach dem Zwiebelprinzip kann theoretisch unendlich fortgeführt werden. Bei Erfolg müsste für jede Rechnergeneration nur ein Software-Emulator bewahrt werden. Dieser Idealzustand ist jedoch von der Neuentwicklung eines Emulators für jede Plattform abhängig. Die Systemanforderungen von Software-Emulatoren setzten der Ausführungsgeschwindigkeit und damit der Schachtelungstiefe weitere praktische Grenzen.^[42]vgl. Rothenberg, J.: Using Emulation to Preserve Digital Documents. Den Haag: Koninklijke Bibliotheek (RAND-Europe), 2000, S. 39. Die Schachtelung von Emulatoren auf diese Weise wäre aufgrund des exponentiellen Ressourcenverbrauchs ineffizient. Ebenso ist die Schachtelungskette als einziges „großes“ dynamisches Objekt anzusehen, mit stetig wachsender Komplexität und dementsprechend sehr eingeschränkten Test- und Zugriffsmöglichkeiten, insbesondere für die inneren Schichten. Auch würden sich in jedem Programm vorhandene Softwarefehler (siehe Abschnitt 4.4) potenzieren und zu nicht vorhersagbaren Seiteneffekten führen. Es ist zu vermuten und statistisch wahrscheinlich, dass die Emulatorkette aufgrund der Implementierungsfehler ab einer gewissen Tiefe zusammenbricht und damit eine harte Schranke für die Dauer der Bewahrung darstellt, wie in Abschnitt 4.4.1 untersucht.

5.4 Zusammenfassung

Die vorangegangenen Betrachtungen haben weitere harte Grenzen und neue Fragestellungen im Rahmen der organisatorischen und technischen Arbeitsprozesse der Emulationsstrategie offenbart.

Durch die zunehmende Fragmentierung digitaler Objekte in Online-Systemen, und der Refokussierung auf Aspekte der gleichzeitigen sozialen Interaktion von Millionen von Menschen beispielsweise bei Online-Spielen oder in sozialen Netzwerken werden zentrale Prämissen des Emulationsansatzes unterwandert. An die Stelle einer Objekt- oder System-zentrischen bzw. technischen Sicht auf die Rezeptionsumgebung und das zu bewahrende Archivgut tritt eine neue, verbindungszentrische Sicht. Diese Verbindungen müssen künftig ebenso im Fokus der Bewahrung stehen. Eventuell zeigt sich hier eine weitere prinzipielle Schranke der Leistungsfähigkeit von Emulation als Bewahrungsstrategie. Die logischen Grenzen des „klassischen“ digitalen Objekts sind dabei nicht immer klar definierbar, mit Auswirkungen auf technische Bewahrungsprozesse. Beispielsweise ist nicht sofort erkennbar, durch welchen Inhalt das AIP von Twitter definiert werden und wie das komplexe Netzwerk an Verbindungen der Objekte untereinander innerhalb eines Langzeitarchivs bewahrt werden kann. Neuartige Distributionsmechanismen stellen weitere Hürden für Langzeitarchive dar.

Hierbei müssen von der Politik und dem Gesetzgeber wirtschaftliche Anreize und rechtliche Normen geschaffen werden, die Gedächtnisorganisationen den Zugang zu diesen Daten erleichtern. Für die Bewahrung des Emulators selbst stehen derzeit keine mittel- bis langfristig schlüssigen Strategien zur Verfügung. Sowohl Emulator-Schachtelung als auch die Migration bzw. Entwicklung für abstrakte Architekturen sind aus ökonomischen und technischen Gründen nicht beliebig iterativ durchführbar. Thibodeau zieht daher das Fazit, dass “[e]ither strategy adds complexity over time”^[43]Thibodeau, K.: Overview of technological approaches to digital preservation and challenges in coming years. In: The State of Digital Preservation: An International Perspective – conference … Continue reading Weitere Forschungsarbeit zur Komplexitätsreduktion bestehender sowie zur Entwicklung neuer Strategien ist vonnöten.