Netzliteratur in Archiven: Von der technischen Analyse zur Emulation

Das Arbeitstreffen "Netzliteratur in Archiven: Von der technischen Analyse zur Emulation" wird am 24.06.2014 am Deutschen Literaturarchiv Marbach stattfinden.

Zielsetzung

Die Archivierung und Analyse von Netzliteratur stellt Archive digitaler Inhalte vor besondere Herausforderungen. Die Komplexität und enge Verknüpfung von Text und Technik benötigen durchdachte Strategien und nicht selten eine Zusammenarbeit mit den Autoren.

Das von der DFG geförderte Projekt „Netzliteratur authentisch archivieren und verfügbar machen“ im DLA Marbach beschäftigt sich seit Januar 2013 mit der Archivierung von Netzliteratur. Bei diesem Arbeitstreffen sucht das Projekt den Austausch mit Experten digitaler Archivierung und der Netzliteratur.

Zentrale Fragestellung des Projekts ist die möglichst authentische Darstellung der archivierten Werke in Zusammenhang mit den Archivierungsmethoden - besonders die Emulation komplexer Werke soll dabei eine Rolle spielen.

Ablauf des Arbeitstreffens

Das Protokoll befindet sich noch im Bearbeitungsstatus! Die endgültige Version wird am Freitag, 27.06., verfügbar sein!

• Beginn
  • Begrüßung (Fr. Bendt)
  • Präsentation des Projekts „Netzliteratur authentisch archivieren und verfügbar machen“: Stand der Arbeiten und Problemdarstellung
    • Stand der Arbeiten (Laufend: Rechteeinholung/Katalogisierung/Archivierung)
    • 3 Wege der Datenbeschaffung: Crawl/Daten aus anderen Quellen/Screencast
    • Probleme bei Crawls (Serverseitige Funktionen/Deep Web/externe Datenquellen/Javascript/Systemanforderungen)
    • Lösungsansätze: Quellcode beschaffen/Momentaufnahme/Screencast/Proxy
    • Ergebnis der Archivierung: warc/Videodatei/Quellcode
    • Problem bei warc: Wayback Machine gibt das Werk nicht authentisch wieder
    • Fragestellung: Kann man auf Grund von warc-Dateien eine Emulationsumgebung erstellen
    • Metadaten: Erfassung der Client- und Serverumgebung
    • Anregung: Anfertigen eines Screencast in jedem Fall! (Steinke, Auer)
    • Frage nach Beurteilungskriterien: Sind vorhanden, aber noch work in progress, bwFLA bereitet auch Kriterien vor
    • Alle Programme werden auf Github eingestellt, siehe dazu Software, es sind aber noch nicht alle Programme veröffentlicht
  • Vorstellung des BagIt-Formats als AIP
    • BagIt ist eine hierarchische Verzeichnisstruktur, für eine kurze Einführung siehe [1]
    • am DLA Erweiterung um Metadaten und Screenshots
    • Interpretation der Metadaten durch das BSZ auf SWBcontent
    • StructMD: hätte auch in METS intengriert werden können, um alles kompakter zu halten
    • für mehrere Versionen eines Werks werden jeweils neue Bags gepackt
    • warc-Datei mounten? Als Filesystem verwenden? (Kramski) -> nicht vorgesehen
    • BagIt wird in der DNB nicht verwendet, stattdessen kopal Format, basiert auch auf METS, BnF & Metadaten, British Library verwendet abgespecktes METS
    • Beschreibung "environment" aus Application Profile
    • Anmerkungen bwFLA: Beschreibung ist in manchen Punkten evtl. zu genau, aber wo werden Lizenz-Infos bzw. Makefiles untergebracht?
    • Anregung: Beschreibung der Umgebung an Hand von Zeitschnitten (Steinke), Idee auch: bwFLA -> macht das dann die Beschreibung der Umgebung in den Metadaten überflüssig?
      • Anwendung einer Referenzumgebung, Standardisierung national, Umgebungsbeschreibung wäre geauer (inklusive Informationen zur Wiederherstellung) -> Wie geht man mit den Werken um, die nicht mit den Referenzumgebungen wiedergegeben werden können?
      • Konfigurations-Info fehlt bisher in Metadaten (Rechert)
      • Vorgehen bei komplexen Objekten (z.B. Datenbanken) (Steinke) -> Umgebung manuell aufbauen
      • Screencast: Format möglichst verlustfrei, Datei wird in data-Verzeichnis der Bag gepackt, Kanada macht auch Screencasts (Auer), Drehbuch anfertigen ist intellektuelle Leistung, Computerspieler fragen (Suchodoletz), Ansatz ist selbstverständlich stark subjektiv,
  • Zusammenfassung des Vormittags und Ausblick
• Mittagspause
  • Zusammenfassung des Vormittags
  • Vortrag bwFLA - Emulation as a service
    • Vortrag wird noch hochgeladen?
    • Emulation als alternative Erhaltungsstrategie
    • Nutzer erhält interaktiven Zugang zu Werk in emulierter Umgebung
    • Bereitstellung erfolgt on-Demand
    • der Nutzer erhält ein funktionierendes Windows98, der Nutzer muss alles selbst installieren und die Umgebung manuell anlegen
    • die Änderungen werden dann gespeichert und können wieder aufgerufen werden
    • Die Unterschiede (Delta) können lokal oder ausgelagert gespeichert werden und wieder auf das Basis-Image angewendet werden
    • Jede Umgebung lässt sich per Handle identifizierbar und auch zitierbar
  • bwFLA & Webarchivierung
    • Beispiel: E-Learning Portal viamus.de -> bwFLA erhielt komplettes Image
      • war abhängig von Netzwerk, DNS, Gateways....
      • Beschreibung der Netzwerkstruktur erforderlich (IP-Adressen/Framework/...)
      • Beschreibung wurde zitierbar
    • Beispiel: Geocities
      • Darstellung von Geocities
      • in authentischer Umgebung
    • Emulation bietet punktuelle Lösungen für die "blinden Flecken" der "klassischen" Webarchivierung (Rechert)
  • Diskussion - bwFLA
    • benötigte Bandbreite: alte Systeme waren auch nicht schnell, ansonsten aber relativ hohe Bandbreite benötigt, besonders im Upload
    • große Zahl an zeitgleichen Zugriffen möglich (Freiburg besitzt 150 CPUs), Nutzer muss sich CPUs selbst besorgen
    • es sind auch zwei Maschinen pro CPU möglich
    • Umgebungsbeschreibung Server - Abhängigkeiten beschreiben -> Prozedere wird noch entwickelt, ist gewisser Aufwand, für Massenarchivierung weniger geeignet
    • Server-Image wird zur Archivalie
    • Objekt muss auf Emulator verlinken
    • Browser muss auch archiviert werden (siehe Tablets und Darstellung von Flash)
    • ist der Browser somit auch Teil des Archivobjekts? (Steinke) - nur wenn er nicht Bestandteil der Referenzumgebung ist (Suchodoletz)
    • muss die bwFLA-Umgebung in Zukunft auch emuliert werden? (Auer) - Die Images können relativ leicht von einem Emulator zum anderen migriert werden.
    • rechtliche Situation/Bereitstellung der Images (Sobotka) - Relativ. Nicht rechtlich sicher, aber vermutlich interessieren sich Apple/Microsoft nicht dafür - Darstellung der Images im Web bzw. im Emulator ist schon unsicherer
    • Aufbau der kann mit dokumentiert werden, dafür steht Interface bereit
    • KEEP/Metadaten (Kramski) - Metadaten bwFLA
    • Integration in Workflow (Schmidgall) - Laborumgebung zu erhalten, bisher war diese nur temporäre Lösung
    • Bindung an die Wayback Machine wird aufgelöst!
    • man könnte auch Referenzumgebungen für die Severumgebung machen (wichtig bei serverseitigen Werken)
    • genaue Dokumentation notwendig, um noch mehr Werke archivieren zu können - möglichst mit geringerem Aufwand
    • die meisten Werke sind "einfach" zu archivieren, nur wenige benötigen wirklich Aufwand
    • man kann sich nicht darauf verlassen, dass Spiegelungen auc in Zukunft verfügbar sind
    • Kopierbarkeit (Rechtlich) - bwFLA Wiedergabe ist so gestaltet, dass sie Read-Only ist, kein kopieren möglich
  • Zusammenfassung des Tages
    • Clientumgebungen können relativ einfach gruppiert und archiviert werden
    • man kann sich nicht darauf verlassen, dass die (nicht emulierte) Wiedergabe, die heute funktioniert, auch in Zukunft tragen wird
    • Screencasts sollte in jedem Fall angefertigt werden, um die heutige Anzeige "einzufrieren"
    • serverseitige Funktionen sind um einiges schwieriger zu archivieren und zu gruppieren
    • Die Frage bleibt, ob dies noch in das jetzige Projekt integriert werden kann oder ob dafür ein Folgeantrag gestellt werden sollte
    • Emulationsprojekt DNB: Bereitstellungssystem auf Emulationsbasis, KEEP-Framework, Zusammenarbeit mit bwFLA, konkrete Installation im Lesesaal als Ergebnis
• Ende