Wie soeben dargestellt, kann für bestimmte Objekttypen mehr als ein View-Path vorliegen.
Das erhöht zwar einerseits die Wahrscheinlichkeit des langfristig erfolgreichen Zugriffs; dieses aber bei potenziell höheren Kosten. Ausgehend vom Objekttyp und der eventuell notwendi-gen Applikation ergeben sich schnell weitere View-Paths, die gleichfalls realisiert werden. Ein einfaches Beispiel wären die sogenannten Office-Pakete, Zusammenstellungen aus verschie-denen Applikationen: Sie können mit einer Vielfalt von Formaten umgehen – nicht nur mit den der enthaltenen Teilkomponenten, sondern darüber hinaus durch Importfilter mit einer Reihe weiterer Dateiformate. Diese Betrachtungen können helfen, eine zusätzliche
Referenz-Abbildung 6.6: Redundante View-Pathes zum Rendering/Ablaufenlassen eines digitalen Objekts (DO). Dieses kann im Beispiel von fünf verschiedenen Applikationen (A) geöffnet werden, die auf vier verschiedenen Betriebssystemen (OS) laufen können, wobei für ein OS kein geeigneter Emulator (E) bereitsteht.
plattform zu identifizieren, die nur für ein bestimmtes Objekt vorgehalten wird, das aber auf alternativen Wegen ebenfalls darstellbar ist. So muss beispielsweise zur Betrachtung eines PDFs nicht eine besonders seltene Plattform genutzt werden, wenn ein gleichwertiger Viewer auf einer mehrfach genutzten anderen Plattform, ebenfalls ablauffähig ist.
14Das konnte dazu führen, dass es absurde Preisunterschiede für das funktional gleiche Office-Paket in deutscher und englischer Sprache gab. Dieses ist in den meisten Fällen für die Darstellung der Primärob-jekte nachrangig, da sich üblicherweise unabhängig von der Benutzerlokalisierung Module zur Darstellung anderssprachlicher Objekte installieren lassen.
6.4. AGGREGATION VON VIEW-PATHS 157
Schwieriger wird jedoch die Aggregation, wenn von den alternativen View-Paths nicht bekannt ist, ob sie ebenfalls zu 100% das gefragte Objekt rekonstruieren. Ein typisches Bei-spiel ist der Import von Word-Dokumenten in einer anderen als der Erstellungsapplikation. An diesem Punkt könnten ebenfalls die im vorangegangenen Abschnitt vorgenommenen Überle-gungen zu Benutzerrückmeldungen in Betracht gezogen werden.
Auf der Ebene der Emulatoren und Virtualisierer lässt sich ebenfalls ein gewisser Austausch untereinander vornehmen. Die Kompatibilitätsmatrix in Abb. 6.7 zeigt, welche Versionen mit jeweils Containerformaten eines anderen Erstellers umgehen kann. So lassen sich
Zwischenup-Abbildung 6.7: Für bestimmte Szenarien kann es interessant sein oder notwendig werden, ”frem-de” Containerformate mit einem Virtualisierer oder Emulator zu öffnen. Darüber hinaus existieren Konverterprogramme zur Formatwandlung, die hier nicht berücksichtigt wurden.
dates überspringen oder alternative View-Paths für einige Szenarien eröffnen. Der Abschnitt 5.7 enthält zudem einige Betrachtungen zu multiplen View-Paths.
6.4.1 Ökonomie und Aufwand
Mit jedem View-Path sind bestimmte Kosten verbunden, die sich für jede Stufe abschät-zen lassen. Übersteigen sie eine gewisse Schwelle, könnten ökonomische Erwägungen an die Aufnahme von Primärobjekten in das Archiv15 und das Archivmanagement geknüpft werden.
So könnte je nach Situation oder Archiv hinterfragt werden, einen View-Path aufrecht zu erhalten, wenn gute Alternativen existieren. Liegt beispielsweise ein Primärobjekt nach dem PDF 1.0 Standard vor, welches mit einem Werkzeug in einer Windows 3.11 Nutzungsumge-bung erzeugt wurde, muss deshalb diese UmgeNutzungsumge-bung nicht zwingend erhalten werden. Unter folgenden Bedingungen kann ein Verzicht auf einen View-Path in Betracht gezogen werden:
• Es existiert eine ausreichende Anzahl weiterer, gleichwertiger und dabei einfacherer View-Paths.
15In solchen Fällen könnten bestimmte Datenformate abgelehnt werden, weil deren spätere Rekonstruktion zu hohe Kosten erwarten lässt.
• Wegen der guten und vollständigen Beschreibung des Formats ist es deutlich einfacher, einen Viewer für die jeweils aktuellen Host-Systeme zu migrieren, als alte Nutzungsum-gebungen durch Emulatoren zu sichern.
• Dieser Objekttyp ist der einzige, der eine Windows 3.11 Umgebung potenziell verlangt.
• Es gibt kein spezielles Interesse, diese Nutzungsumgebung aufrecht zu erhalten, da dieses nicht im Fokus der Institution liegt.
Dieses Vorgehen ließe sich auf andere View-Paths ausdehnen, die für eine Reihe von Daten-formaten und Applikationen Apple- oder alternativ Microsoft-Betriebssysteme voraussetzen.
Wenn beispielsweise kein gesondertes Bedürfnis speziell nach dedizierten Apple-Nutzungsum-gebungen16 existiert, könnte ein solcher Zweig im Archiv geschlossen werden.
Ähnlich liegt der Fall in der trivialen Vervielfachung der View-Paths durch unterschiedli-che Lokalisierungen. Während Open-Source-Betriebssysteme und Applikationen schon lange mehrere Sprachpakete in einer Installation erlauben, setzte dieses sich bei kommerziellen Sys-temen erst recht spät durch. Das Bedürfnis von einem Betriebssystem wie Windows 2000 alle verschiedenen Landesversionen aufzubewahren, lässt sich vermutlich besser in Koopera-tionen ähnlicher InstituKoopera-tionen17 über Landesgrenzen hinweg erreichen. Dieses würde zudem die Kosten und Aufwand für redundante Lizenzen reduzieren.
Durchaus anders kann der Fall liegen, wenn an anderer Stelle sekundäre Archivobjekte selbst ins Zentrum des Interesses rücken. So sind Computerspiele ganz eigene Zeugen ihrer Epoche oder man möchte nachvollziehen, wie sich die grafischen Oberflächen im Laufe einer bestimmten Periode entwickelt haben. Deshalb beeinflussen Institutionen und ihre Nutzer18 ebenfalls das Aussehen von View-Paths.
Einfacher und damit oft günstiger zu pflegendenden View-Paths kann der Vorrang vor anderen eingeräumt werden. Jedoch sind auch hier Voraussagen schwierig und es kann die Gefahr bestehen, dass sich mit dem Wandel der Referenzumgebungen die Kostenstrukturen erneut ändern. Andererseits ließen sich Vorkehrungen treffen, dass seltenere View-Paths zu-mindest an spezialisierten Institutionen mit besonderem Sammelauftrag und entsprechender Finanzierung weiter betreut werden.
Die verschiedenen Strategien der Langzeitarchivierung der Emulatoren (siehe Abschnitt 4.8.1 und 4.8.2) generieren unterschiedliche Kosten auf Seiten des Archivmanagements:
• Die geschachtelte Emulation sorgt für eher längere View-Paths bei geringem Migrati-onsbedarf. Der Aufwand entsteht beim zunehmend komplexer werdenden Zugriff auf das Primärobjekt.
• Die Migration von Emulatoren, UVMs und modulare Ansätze generieren eher kurze View-Paths bei einfacherem Zugriff auf das Primärobjekt. Jedoch liegt der Aufwand im regelmäßigen Update aller benötigter Emulatoren oder iher Teilkomponenten.
16Weil die Art der Benutzerinteraktion, das Aussehen der grafischen Oberfläche und der Applikation in dieser von eigenständigem Interesse sind. Besonders gut lässt sich dieses am OpenOffice veranschaulichen, welches für etliche kommerzielle und freie Unixes, wie BSD, Solaris oder Linux, Mac-OS X und selbstredend für die Windows-Betriebssysteme übersetzt wird.
17Vgl. Abschnitt 2.6: Inzwischen hat die Kooperation auf dem Gebiet der Langzeitarchivierung Tradition.
18Siehe Abschnitt 4.5.