Netzliteratur in Archiven: Von der technischen Analyse zur Emulation: Unterschied zwischen den Versionen

Aus Netzliteratur
Wechseln zu: Navigation, Suche
 
(8 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 10: Zeile 10:
  
 
== Ablauf des Arbeitstreffens ==
 
== Ablauf des Arbeitstreffens ==
'''Das Protokoll befindet sich noch im Bearbeitungsstatus! Die endgültige Version wird am Freitag, 27.06., verfügbar sein!'''
 
  
 
*'''Beginn'''
 
*'''Beginn'''
 
**'''Begrüßung'''
 
**'''Begrüßung'''
**'''Präsentation des Projekts „Netzliteratur authentisch archivieren und verfügbar machen“: Stand der Arbeiten und Problemdarstellung'''
+
**'''[https://wwik-prod.dla-marbach.de/line/index.php/Datei:Projekt_Workshop_20140611.pdf Präsentation] des Projekts „Netzliteratur authentisch archivieren und verfügbar machen“: Stand der Arbeiten und Problemdarstellung'''
 
*:Das Projektteam stellt den Stand der Arbeiten vor. Laufende Arbeiten sind momentan die Rechteeinholung, die Katalogisierung und die Archivierung. Die Auswahl der Werke fand bereits statt. Angedacht sind drei Wege der Datenbeschaffung: Spiegelung/Screencast/Erhalt der (Quell-) Daten von den Autoren. Trotz der ständigen Weiterentwicklung von Crawlern in den lezten Jahren gibt es bisher immer noch Probleme bei der Archivierung von severseitigen Funktionen, von Deep-Web-Komponenten. von externen Datenquellen (z.B. Google Maps oder Youtube) und/oder von Javascript. Auch die Reproduktion von Systemanforderungen, sei es zu Archivierungs- oder Wiedergabezwecken, ist bisher nur zu einem geringen Teil möglich. Deshalb müssen "Momentaufnahmen" der funktionierenden Werke in Form von Screenshots und Screencasts angefertigt werden.
 
*:Das Projektteam stellt den Stand der Arbeiten vor. Laufende Arbeiten sind momentan die Rechteeinholung, die Katalogisierung und die Archivierung. Die Auswahl der Werke fand bereits statt. Angedacht sind drei Wege der Datenbeschaffung: Spiegelung/Screencast/Erhalt der (Quell-) Daten von den Autoren. Trotz der ständigen Weiterentwicklung von Crawlern in den lezten Jahren gibt es bisher immer noch Probleme bei der Archivierung von severseitigen Funktionen, von Deep-Web-Komponenten. von externen Datenquellen (z.B. Google Maps oder Youtube) und/oder von Javascript. Auch die Reproduktion von Systemanforderungen, sei es zu Archivierungs- oder Wiedergabezwecken, ist bisher nur zu einem geringen Teil möglich. Deshalb müssen "Momentaufnahmen" der funktionierenden Werke in Form von Screenshots und Screencasts angefertigt werden.
 
*:Das Ergebnis der Archivierung eines Werks muss somit in mindestens einer der folgenden Formen vorliegen: warc-Datei, Videodatei, Quell-Dateien. Damit bleibt das Problem der authentischen Widergabe. Der Screencast stellt das Werk in der zum Zeitpunkt der Anfertigung möglichst authentischen Form dar. Aus den Quell-Dateien kann bei genügender Beschreibung eine authentische Wiedergabe reproduziert werden. Doch die "klassische" Wiedergabe einer warc-Datei mittels der Wayback Machine ist nicht in jedem Fall authentisch, da die Wiedergabe in einem zeitgenössischen Browser mit zeitgenössischer Hardware stattfindet.
 
*:Das Ergebnis der Archivierung eines Werks muss somit in mindestens einer der folgenden Formen vorliegen: warc-Datei, Videodatei, Quell-Dateien. Damit bleibt das Problem der authentischen Widergabe. Der Screencast stellt das Werk in der zum Zeitpunkt der Anfertigung möglichst authentischen Form dar. Aus den Quell-Dateien kann bei genügender Beschreibung eine authentische Wiedergabe reproduziert werden. Doch die "klassische" Wiedergabe einer warc-Datei mittels der Wayback Machine ist nicht in jedem Fall authentisch, da die Wiedergabe in einem zeitgenössischen Browser mit zeitgenössischer Hardware stattfindet.
Zeile 23: Zeile 22:
 
*:Für den Umgang mit den erzeugten warc-Dateien hat das Projekt am DLA Software entwickelt. Diese werden im Laufe des Projekts auf Github publiziert. Siehe dazu [[Software]]
 
*:Für den Umgang mit den erzeugten warc-Dateien hat das Projekt am DLA Software entwickelt. Diese werden im Laufe des Projekts auf Github publiziert. Siehe dazu [[Software]]
 
**'''Vorstellung des BagIt-Formats als AIP'''
 
**'''Vorstellung des BagIt-Formats als AIP'''
*:Das [http://de.wikipedia.org/wiki/BagIt BagIt]-Format ist eine hierarchie Verzeichnisstruktur.  
+
*:Das [http://de.wikipedia.org/wiki/BagIt BagIt]-Format ist eine hierarchische Verzeichnisstruktur. Die vorgegebene Spezifikation wird am DLA um eine metadata.xml erweitert. Darüber hinaus muss am DLA zusätzlich zu den zu archivierenden Daten zwei Screenshots beigelegt werden.
***BagIt ist eine hierarchische Verzeichnisstruktur, für eine kurze Einführung siehe
+
*:Die den Bags beigelegten Metadaten werden nach dem Upload in SWBcontent interpretiert und eine Auswahl davon dargestellt werden.
***am DLA Erweiterung um Metadaten und Screenshots
+
*:Evtl. zu archivierenden Container-Dateien wird eine structMD beigegeben, welche die Struktur des entpackten Objekt beschreibt und die enthaltenen Objekte grundlegend beschreibt. Diese wird im Projekt als externe structMD.xml beigelegt und in den übergeordneten Metadaten als Objekt beschrieben. Sie hätte allerdings auch ebenso gut in die übergeordneten METS-Struktur eingebettet werden können.
***Interpretation der Metadaten durch das BSZ auf SWBcontent
+
*:Sollten für ein Werk mehrere Versionen archiviert werden so wird pro Version eine neue Bag angelegt und archiviert.
***StructMD: hätte auch in METS intengriert werden können, um alles kompakter zu halten
+
*:In der Diskussion kam die Frage auf, ob es angedacht ist, die warc-Datei zu mounten bzw. als Filesystem zu verwenden. Dies ist bisher nicht vorgesehen.
***für mehrere Versionen eines Werks werden jeweils neue Bags gepackt
+
*:An der DNB wird das BagIt-Format bisher nicht verwendet. Stattdessen wird das [http://kopal.langzeitarchivierung.de/downloads/kopal_Universelles_Objektformat.pdf Universelle Objektformat] verwendet, das auf METS basiert. Die British Library verwendet ebenfalls eine abgespeckte Variante von METS,
***warc-Datei mounten? Als Filesystem verwenden? (Kramski) -> nicht vorgesehen
+
*:Die im Projekt angedachte Beschreibung der Hard- und Softwareumgebung kann dem [[Projektpapiere|Application profile]] entnommen werden. Die Teilnehmer von bwFLA merkten an, dass die Beschreibung in manchen Punkten evtl. zu genau ist. Darüber hinaus fehlt ein Hinweis, wo Informationen zu Lizenzen bzw. Makefiles oder Informationen zur Konfiguration (z.B. Bildschirmauflösung) untergebracht werden sollen.
***BagIt wird in der DNB nicht verwendet, stattdessen kopal Format, basiert auch auf METS, BnF & Metadaten, British Library verwendet abgespecktes METS
+
*:Ebenfalls wurde die Idee formuliert, die nötige Hard- und Softwarebeschreibung an Hand von Zeitschnitten zu definieren und zu beschreiben. Werke, die in einer bestimmten Zeit entstanden sind, sind üblicherweise auch für die zu dieser Zeit gängigen Soft- und Hardware ausgelegt. Deshalb sollte für die meisten Werke das Entstehungsdatum in Kombination mit der Beschreibung der zu dieser Zeit üblichen technischen Uumgebung genügen. Dabei bleibt allerdings die Frage bestehen, ob eine solche Beschreibung die Beschreibung in den Metadaten zum Objekt ersetzen oder nur ergänzen kann. Dies würde zur Definition von verschiedenen Referenzumgebungen führen, die auch national standardisiert werden könnten. Die hieraus resultierende Umgebungsbeschreibung wäre evtl. genauer und könnte auch detaillierte Informationen zur Wiederherstellung der betreffenden Umgebung beinhalten (z.B. Installationsanleitungen oder Lizenzinformationen). Allerdings bleibt die Frage, wie mit Werken umgegangen wird, die nicht für eine solche Referenzumgebung entwickelt wurden und stattdessen Besonderheiten hinsichtlich der technischen Umgebung aufweisen.
***Beschreibung "environment" aus Application Profile
+
*:Für komplexe Objekte, die beispielsweise Datenbanken beinhalten müsste eine solche Umgebung manuell aufgebaut werden.
***Anmerkungen bwFLA: Beschreibung ist in manchen Punkten evtl. zu genau, aber wo werden Lizenz-Infos bzw. Makefiles untergebracht?
+
*:Anschließend wandte sich die Diskussion der Erstellung von Screencasts zu. Es war Konsens, dass hierfür ein möglichst verlustfreies Format ausgewählt werden soll. Es liegt bisher kein langzeitarchivierungsfähiges Videoformat vor. Die erstellte Video-Datei wird anschließend in das data-Verzeichnis der Bag gepackt und archiviert. Hr. Auer wies darauf hin, dass in Kanada auch Screencasts angefertigt werden. Das Drehbuch für einen solchen Screencast zu erstellen ist eine intellektuelle Leistung, die ein individuelles Herangehen an jedes einzelne Werk erfordert. Darüber hinaus ist es selbstverständlich ein stark subjektiver Ansatz der Archivierung. Screencasts sind auch im Bereich der Computerspiele ein gängiges Vorgehen.
***Anregung: Beschreibung der Umgebung an Hand von Zeitschnitten (Steinke), Idee auch: bwFLA -> macht das dann die Beschreibung der Umgebung in den Metadaten überflüssig?
+
**'''Zusammenfassung des Vormittags und Ausblick'''
****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?
+
*'''Mittagspause'''
****Konfigurations-Info fehlt bisher in Metadaten (Rechert)
+
**'''Zusammenfassung des Vormittags'''
****Vorgehen bei komplexen Objekten (z.B. Datenbanken) (Steinke) -> Umgebung manuell aufbauen
+
**'''Vortrag bwFLA - Emulation as a service'''
****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,
+
*:Emulation ist eine alternative Erhaltungsstrategie in der Langzeitarchivierung. Im Projekt bwFLA erhält der Nutzer einen interaktiven Zugang zum archivierten Werk in einer emulierten Umgebung. Die Bereitstellung erfolgt dabei on-Demand.
**Zusammenfassung des Vormittags und Ausblick
+
*:Die archivierende Institution erhält beispielsweise Zugang zu einem virtuellen Rechner mit einem funktionierenden Windows 98. Alle zusätzlichen Komponenten müssen selbst installiert werden. Das heißt, dass die vom Werk benötigte technische Umgebung manuell rekonstruiert wird. Die am Basis-System vorgenommenen Änderungen (genannt: Delta) können entweder lokal oder ausgelagert gespeichert und mittels Aufruf wieder auf das Basis-System angewendet werden. Die so erstellte Umgebung ist mittels einem Handle identifzierbar und auch zitierbar.
*Mittagspause
+
*:Zur Archivierung des E-Learning-Portals viamus.de erhielt bwFLA ein komplettes Image. Dieses wurde in die bwFLA-Umgebung eingebracht. Dabei wurden einige Abhängigkeiten festgestellt, an Hand derer das System angepasst werden musste (beispielsweise Netzwerk, DNS, Gateway). Durch die praktische Umsetzung dieser Netzwerk-Beschreibung wurde diese zitierbar und auch dokumentierbar.
**Zusammenfassung des Vormittags
+
*:Der 2009 abgeschaltete Freehoster wurde vor der Abschaltung noch durch das Internet Archive archiviert und die Daten zur Verfügung gestellt. bwFLA versucht nun die Geocities-Websites nun in authentischer Umgebung wieder darzustellen.
**Vortrag bwFLA - Emulation as a service
+
*:Emulation bietet punktuelle Lösungen für die "blinden Flecken" der "klassischen" Webarchivierung (Rechert)
***Vortrag wird noch hochgeladen?
+
*:In der Diskussion kam die Frage auf die benötigte Bandbreite. Nach Aussage von bwFLA ist eine relativ hohe Bandbreite nötig, besonders im upload. Allerdings tragen mögliche Verzögerungen wiederum zu einer authentischen Darstellung bei, da das "alte Internet" nicht sehr schnell war.
***Emulation als alternative Erhaltungsstrategie
+
*:Genrell ist eine größere Zahl an zeitgleichen Zugriffen auf das System möglich. Die Nutzer müssen sich die dafür nötigen CPUs aber selbst beschaffen (entweder Cloud oder lokal). Für die meisten Zwecke können zwei virtuelle Maschinen pro CPU betrieben werden
***Nutzer erhält interaktiven Zugang zu Werk in emulierter Umgebung
+
*:Beim Vorgehen von bwFLA wird die zur Rekonstruktion der Umgebung benötigte (Server-)Beschreibung selbst zur Archivalie.
***Bereitstellung erfolgt on-Demand
+
*:Im Katalog müsste der Katalogeintrag also auf den Emulator verlinken (anstatt wie bisher auf eine Spiegelung).
***der Nutzer erhält ein funktionierendes Windows98, der Nutzer muss alles selbst installieren und die Umgebung manuell anlegen
+
*:Um eine authentische Darstellung der Websites zu gewährleisten müssen die zeitgenössischen Browser unbedingt mit archiviert werden. Schon heute können Browser auf Tablets kein Flash mehr darstellen. Dies führte zu der Überlegung, ob der zugehörige Browser somit Teil des Archivobjekts wird. Dies wäre im Fall von bwFLA aber nur der Fall, wenn der Browser nicht Bestandteil der definierten Referenzumgebung ist.
***die Änderungen werden dann gespeichert und können wieder aufgerufen werden
+
*:DA Emulatoren "nur" eine Zwischenschicht zwischen dem Werk und unserer heutigen Hard- und Software darstellen wurde diskutiert, ob in Zukunft auch die bwFLA-Umgebung emuliert werden müsste. Die Teilnehmer von bwFLA äußerten sich zuversichtlich, dass auch in Zukunft aktuelle Emulatoren für alte Systeme entwickelt werden. Die Miration von Emulator zu Emulator sei relativ leicht zu bewerkstelligen.
***Die Unterschiede (Delta) können lokal oder ausgelagert gespeichert werden und wieder auf das Basis-Image angewendet werden
+
*:Die Bereitstellung bzw. Darstellung von Betriebbsystem-Images ist noch nicht rechtlich sicher!
***Jede Umgebung lässt sich per Handle identifizierbar und auch zitierbar
+
*:bwFLA verwendet ein eigenes Set an Metadaten. Dabei wird jede Maschine über eine ID identifiziert. Die Metadaten enthalten dabei eine Netzwerkbeschreibung, den Pfad zum Plattenimage, Angaben zu Mac-Adressen und Gateways, sowieVerweise auf weitere Maschinen.
**bwFLA & Webarchivierung
+
*:Die Integration von bwfLA in den Workflow des Projekt würde bedeuten, dass die bisher nur lokal erstellte Laborumgebung in bwFLA nachgebildet und erhalten würde.
***Beispiel: E-Learning Portal viamus.de -> bwFLA erhielt komplettes Image
+
*:In der Webarchivierung wird somit die Bindung an die Wayback Machine wird aufgelöst. Insbesondere, da nicht sicher gestellt ist, dass Spiegelungen in Zukunft darstellbar sein werden.
****war abhängig von Netzwerk, DNS, Gateways....
+
*:bwFLA Wiedergabe ist so gestaltet, dass sie Read-Only ist, es ist kein kopieren möglich.
****Beschreibung der Netzwerkstruktur erforderlich (IP-Adressen/Framework/...)
+
**'''Zusammenfassung des Tages'''
****Beschreibung wurde zitierbar
+
*:Die Clientumgebungen können relativ einfach gruppiert und archiviert werden. Serverseitige Funktionen sind hingegen um einiges schwieriger zu archivieren und zu gruppieren.
***Beispiel: Geocities
+
*:Man kann sich nicht darauf verlassen, dass die (nicht emulierte) Wiedergabe, die heute funktioniert, auch in Zukunft tragen wird (beispielsweise Wayback Machine).
****Darstellung von Geocities
+
*:Screencasts sollte in jedem Fall angefertigt werden, um die heutige Anzeige "einzufrieren"
****in authentischer Umgebung
+
*:Die DNB plant ebenfalls ein Emulationsprojekt in Zusammenarbeit mit Freiburg. Dabei soll es um die Entwicklung von Bereitstellungssystem auf Emulationsbasis mit Integration des KEEP-Frameworks gehen. Die Installation soll konkret im Lesesaal stattfinden und das Ergebnis des Projekts sein. Der Fokus liegt dabei klar auf Bereitstellung im Lesesaal.
***Emulation bietet punktuelle Lösungen für die "blinden Flecken" der "klassischen" Webarchivierung (Rechert)
+
*'''Ende'''
**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, klarer Fokus auf Bereitstellung im Lesesaal
 
***Anregung Steinke: Publikation auf Englisch für IIPC
 
*Ende
 

Aktuelle Version vom 22. Juli 2014, 07:49 Uhr

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

  • Beginn
    • Begrüßung
    • Präsentation des Projekts „Netzliteratur authentisch archivieren und verfügbar machen“: Stand der Arbeiten und Problemdarstellung
    Das Projektteam stellt den Stand der Arbeiten vor. Laufende Arbeiten sind momentan die Rechteeinholung, die Katalogisierung und die Archivierung. Die Auswahl der Werke fand bereits statt. Angedacht sind drei Wege der Datenbeschaffung: Spiegelung/Screencast/Erhalt der (Quell-) Daten von den Autoren. Trotz der ständigen Weiterentwicklung von Crawlern in den lezten Jahren gibt es bisher immer noch Probleme bei der Archivierung von severseitigen Funktionen, von Deep-Web-Komponenten. von externen Datenquellen (z.B. Google Maps oder Youtube) und/oder von Javascript. Auch die Reproduktion von Systemanforderungen, sei es zu Archivierungs- oder Wiedergabezwecken, ist bisher nur zu einem geringen Teil möglich. Deshalb müssen "Momentaufnahmen" der funktionierenden Werke in Form von Screenshots und Screencasts angefertigt werden.
    Das Ergebnis der Archivierung eines Werks muss somit in mindestens einer der folgenden Formen vorliegen: warc-Datei, Videodatei, Quell-Dateien. Damit bleibt das Problem der authentischen Widergabe. Der Screencast stellt das Werk in der zum Zeitpunkt der Anfertigung möglichst authentischen Form dar. Aus den Quell-Dateien kann bei genügender Beschreibung eine authentische Wiedergabe reproduziert werden. Doch die "klassische" Wiedergabe einer warc-Datei mittels der Wayback Machine ist nicht in jedem Fall authentisch, da die Wiedergabe in einem zeitgenössischen Browser mit zeitgenössischer Hardware stattfindet.
    Die Fragestellung lautet somit: Ist auf Grundlage einer warc-Datei in einer emulierten Umgebung eine authentische Wiedergabe möglich?
    Um dies überhaupt möglich zu machen werden in den Metadaten die für eine authentische Darstellung erforderliche Hard- und Softwareumgebung beschrieben.
    In der anschließenden Diskussion ergab sich die Anregung, dass zu allen archivierten Objekten unabhängig von der eigentlich angewendeten Archivierungsmethode ein Screencast angefertigt wird.
    Darüber hinaus wurde die Frage gestellt, wie beurteilt wird, ob ein Werk authentisch archiviert bzw. wiedergegeben wird. Das Projekt entwickelt hierfür Burteilungskriterien, die sich aber momentan noch im Entwicklungsstadium befinden. Diese orientieren sich an der Vollständigkeit der Wiedergabe. Zusätzlich wird hierbei eng mit den Autoren zusammengearbeitet, welche die archivierten Werke auf ihre Korrektheit und Authentizität überprüfen sollen. Auch das Freiburger Projekt bwFLA bereitet für ein zukünftiges solche Kriterien vor. Dafür formulieren sie Erwartungen an das Werk, die anschließend durch die Archivierung erfüllt werden müssen (ähnlich Significant Properties). Hierbei ist vor allem die Definition dieser Erwartungen an sich, aber auch Unterscheidung zwischen inhaltlichen und technischen Features schwierig.
    Für den Umgang mit den erzeugten warc-Dateien hat das Projekt am DLA Software entwickelt. Diese werden im Laufe des Projekts auf Github publiziert. Siehe dazu Software
    • Vorstellung des BagIt-Formats als AIP
    Das BagIt-Format ist eine hierarchische Verzeichnisstruktur. Die vorgegebene Spezifikation wird am DLA um eine metadata.xml erweitert. Darüber hinaus muss am DLA zusätzlich zu den zu archivierenden Daten zwei Screenshots beigelegt werden.
    Die den Bags beigelegten Metadaten werden nach dem Upload in SWBcontent interpretiert und eine Auswahl davon dargestellt werden.
    Evtl. zu archivierenden Container-Dateien wird eine structMD beigegeben, welche die Struktur des entpackten Objekt beschreibt und die enthaltenen Objekte grundlegend beschreibt. Diese wird im Projekt als externe structMD.xml beigelegt und in den übergeordneten Metadaten als Objekt beschrieben. Sie hätte allerdings auch ebenso gut in die übergeordneten METS-Struktur eingebettet werden können.
    Sollten für ein Werk mehrere Versionen archiviert werden so wird pro Version eine neue Bag angelegt und archiviert.
    In der Diskussion kam die Frage auf, ob es angedacht ist, die warc-Datei zu mounten bzw. als Filesystem zu verwenden. Dies ist bisher nicht vorgesehen.
    An der DNB wird das BagIt-Format bisher nicht verwendet. Stattdessen wird das Universelle Objektformat verwendet, das auf METS basiert. Die British Library verwendet ebenfalls eine abgespeckte Variante von METS,
    Die im Projekt angedachte Beschreibung der Hard- und Softwareumgebung kann dem Application profile entnommen werden. Die Teilnehmer von bwFLA merkten an, dass die Beschreibung in manchen Punkten evtl. zu genau ist. Darüber hinaus fehlt ein Hinweis, wo Informationen zu Lizenzen bzw. Makefiles oder Informationen zur Konfiguration (z.B. Bildschirmauflösung) untergebracht werden sollen.
    Ebenfalls wurde die Idee formuliert, die nötige Hard- und Softwarebeschreibung an Hand von Zeitschnitten zu definieren und zu beschreiben. Werke, die in einer bestimmten Zeit entstanden sind, sind üblicherweise auch für die zu dieser Zeit gängigen Soft- und Hardware ausgelegt. Deshalb sollte für die meisten Werke das Entstehungsdatum in Kombination mit der Beschreibung der zu dieser Zeit üblichen technischen Uumgebung genügen. Dabei bleibt allerdings die Frage bestehen, ob eine solche Beschreibung die Beschreibung in den Metadaten zum Objekt ersetzen oder nur ergänzen kann. Dies würde zur Definition von verschiedenen Referenzumgebungen führen, die auch national standardisiert werden könnten. Die hieraus resultierende Umgebungsbeschreibung wäre evtl. genauer und könnte auch detaillierte Informationen zur Wiederherstellung der betreffenden Umgebung beinhalten (z.B. Installationsanleitungen oder Lizenzinformationen). Allerdings bleibt die Frage, wie mit Werken umgegangen wird, die nicht für eine solche Referenzumgebung entwickelt wurden und stattdessen Besonderheiten hinsichtlich der technischen Umgebung aufweisen.
    Für komplexe Objekte, die beispielsweise Datenbanken beinhalten müsste eine solche Umgebung manuell aufgebaut werden.
    Anschließend wandte sich die Diskussion der Erstellung von Screencasts zu. Es war Konsens, dass hierfür ein möglichst verlustfreies Format ausgewählt werden soll. Es liegt bisher kein langzeitarchivierungsfähiges Videoformat vor. Die erstellte Video-Datei wird anschließend in das data-Verzeichnis der Bag gepackt und archiviert. Hr. Auer wies darauf hin, dass in Kanada auch Screencasts angefertigt werden. Das Drehbuch für einen solchen Screencast zu erstellen ist eine intellektuelle Leistung, die ein individuelles Herangehen an jedes einzelne Werk erfordert. Darüber hinaus ist es selbstverständlich ein stark subjektiver Ansatz der Archivierung. Screencasts sind auch im Bereich der Computerspiele ein gängiges Vorgehen.
    • Zusammenfassung des Vormittags und Ausblick
  • Mittagspause
    • Zusammenfassung des Vormittags
    • Vortrag bwFLA - Emulation as a service
    Emulation ist eine alternative Erhaltungsstrategie in der Langzeitarchivierung. Im Projekt bwFLA erhält der Nutzer einen interaktiven Zugang zum archivierten Werk in einer emulierten Umgebung. Die Bereitstellung erfolgt dabei on-Demand.
    Die archivierende Institution erhält beispielsweise Zugang zu einem virtuellen Rechner mit einem funktionierenden Windows 98. Alle zusätzlichen Komponenten müssen selbst installiert werden. Das heißt, dass die vom Werk benötigte technische Umgebung manuell rekonstruiert wird. Die am Basis-System vorgenommenen Änderungen (genannt: Delta) können entweder lokal oder ausgelagert gespeichert und mittels Aufruf wieder auf das Basis-System angewendet werden. Die so erstellte Umgebung ist mittels einem Handle identifzierbar und auch zitierbar.
    Zur Archivierung des E-Learning-Portals viamus.de erhielt bwFLA ein komplettes Image. Dieses wurde in die bwFLA-Umgebung eingebracht. Dabei wurden einige Abhängigkeiten festgestellt, an Hand derer das System angepasst werden musste (beispielsweise Netzwerk, DNS, Gateway). Durch die praktische Umsetzung dieser Netzwerk-Beschreibung wurde diese zitierbar und auch dokumentierbar.
    Der 2009 abgeschaltete Freehoster wurde vor der Abschaltung noch durch das Internet Archive archiviert und die Daten zur Verfügung gestellt. bwFLA versucht nun die Geocities-Websites nun in authentischer Umgebung wieder darzustellen.
    Emulation bietet punktuelle Lösungen für die "blinden Flecken" der "klassischen" Webarchivierung (Rechert)
    In der Diskussion kam die Frage auf die benötigte Bandbreite. Nach Aussage von bwFLA ist eine relativ hohe Bandbreite nötig, besonders im upload. Allerdings tragen mögliche Verzögerungen wiederum zu einer authentischen Darstellung bei, da das "alte Internet" nicht sehr schnell war.
    Genrell ist eine größere Zahl an zeitgleichen Zugriffen auf das System möglich. Die Nutzer müssen sich die dafür nötigen CPUs aber selbst beschaffen (entweder Cloud oder lokal). Für die meisten Zwecke können zwei virtuelle Maschinen pro CPU betrieben werden
    Beim Vorgehen von bwFLA wird die zur Rekonstruktion der Umgebung benötigte (Server-)Beschreibung selbst zur Archivalie.
    Im Katalog müsste der Katalogeintrag also auf den Emulator verlinken (anstatt wie bisher auf eine Spiegelung).
    Um eine authentische Darstellung der Websites zu gewährleisten müssen die zeitgenössischen Browser unbedingt mit archiviert werden. Schon heute können Browser auf Tablets kein Flash mehr darstellen. Dies führte zu der Überlegung, ob der zugehörige Browser somit Teil des Archivobjekts wird. Dies wäre im Fall von bwFLA aber nur der Fall, wenn der Browser nicht Bestandteil der definierten Referenzumgebung ist.
    DA Emulatoren "nur" eine Zwischenschicht zwischen dem Werk und unserer heutigen Hard- und Software darstellen wurde diskutiert, ob in Zukunft auch die bwFLA-Umgebung emuliert werden müsste. Die Teilnehmer von bwFLA äußerten sich zuversichtlich, dass auch in Zukunft aktuelle Emulatoren für alte Systeme entwickelt werden. Die Miration von Emulator zu Emulator sei relativ leicht zu bewerkstelligen.
    Die Bereitstellung bzw. Darstellung von Betriebbsystem-Images ist noch nicht rechtlich sicher!
    bwFLA verwendet ein eigenes Set an Metadaten. Dabei wird jede Maschine über eine ID identifiziert. Die Metadaten enthalten dabei eine Netzwerkbeschreibung, den Pfad zum Plattenimage, Angaben zu Mac-Adressen und Gateways, sowieVerweise auf weitere Maschinen.
    Die Integration von bwfLA in den Workflow des Projekt würde bedeuten, dass die bisher nur lokal erstellte Laborumgebung in bwFLA nachgebildet und erhalten würde.
    In der Webarchivierung wird somit die Bindung an die Wayback Machine wird aufgelöst. Insbesondere, da nicht sicher gestellt ist, dass Spiegelungen in Zukunft darstellbar sein werden.
    bwFLA Wiedergabe ist so gestaltet, dass sie Read-Only ist, es ist kein kopieren möglich.
    • Zusammenfassung des Tages
    Die Clientumgebungen können relativ einfach gruppiert und archiviert werden. Serverseitige Funktionen sind hingegen um einiges schwieriger zu archivieren und zu gruppieren.
    Man kann sich nicht darauf verlassen, dass die (nicht emulierte) Wiedergabe, die heute funktioniert, auch in Zukunft tragen wird (beispielsweise Wayback Machine).
    Screencasts sollte in jedem Fall angefertigt werden, um die heutige Anzeige "einzufrieren"
    Die DNB plant ebenfalls ein Emulationsprojekt in Zusammenarbeit mit Freiburg. Dabei soll es um die Entwicklung von Bereitstellungssystem auf Emulationsbasis mit Integration des KEEP-Frameworks gehen. Die Installation soll konkret im Lesesaal stattfinden und das Ergebnis des Projekts sein. Der Fokus liegt dabei klar auf Bereitstellung im Lesesaal.
  • Ende