Approver
Begriff aus Rosetta
Definition:
Approver ist eine Nutzerrolle in Rosetta. User mit der Rolle Approver arbeiten im Bereich Approve SIPs und evaluieren Submission Information Packages (SIPs), die technisch einwandfrei sind und die initialen Prüfungen (zum Beispiel auf Viren oder Dateiformatvalidität) beim Ingest erfolgreich durchlaufen haben. Der Schwerpunkt der Arbeit von Approvern liegt dabei auf dem finalen Absegnen (Approve) von SIPs, welche den Bereich Assessor bzw. Assess SIPs bereits durchlaufen haben. Approver nehmen eine intellektuelle Prüfung der SIPs und deren Inhalte vor und stoßen dann die Weiterverarbeitung der Pakete in den Permanentspeicher von Rosetta an, in dessen Verlauf die SIPs in Archival Information Packages (AIPs) umgewandelt und im Permanent Storage bzw. Archival Storage von Rosetta gespeichert werden. Damit haben die Intellectual Entities (IEs) den Ingestprozess vollständig durchlaufen.
Approver können nur komplette SIPs Absegnen (Approve), Ablehnen (Decline), zum Deposit-Bereich Zurücksenden (Return), nicht aber einzelne IEs, wie die Rollen Assessor und Arranger. Die Rolle Approver dient anders als Assessor oder Arranger also vor allem dazu, Einlieferungspakete in ihrer Gesamtheit zu beurteilen und zur Weiterverarbeitung freizugeben.
Assessor, Arranger, und Approver arbeiten in ihren jeweiligen Arbeitsbereichen unter Submissions → Approval.
Der Begriff Approver wird umgangssprachlich auch synonym für den Rosetta-Arbeitsbereich Approve SIPs verwendet. Dort können SIPs intellektuell evaluiert werden, bevor sie in den Permanentspeicher von Rosetta weitergeschoben werden. Welche Teilmenge eines Ingests zur Prüfung in den Assessor oder Approver abgelegt wird, ist von der Sampling Rate abhängig.
Synonyme:
Approve SIP
Archival Information Package (AIP)
Begriff aus dem Open Archival Information System (OAIS)
Definition:
Das Archival Information Package (AIP) ist ein Informationspaket. Dabei handelt es sich um den logischen Container für eine digitale Ressource in einem digitalen Langzeitarchiv. Ein AIP wird auf Grundlage des Submission Information Package (SIP) gebildet und beinhaltet Erhaltungsmetadaten, welche die Eigenschaften einer digitale Ressource sowie die Prozesse dokumentieren, die diese im Rahmen der Langzeitverfügbarkeit durchläuft.
In Rosetta repräsentiert ein AIP jeweils eine Intellectual Entity (IE), die im Permanent Storage von Rosetta gespeichert ist und über eine IE PID (z.B. IE7281) verfügt. Die Eigenschaften eines AIPs bzw. einer IE werden in einer Rosetta-METS-Datei als deskriptive, administrative, strukturelle und technische Metadaten beschrieben
Weitere Informationen dazu im Service Wiki-Artikel: Metadaten und Langzeitverfügbarkeit
Synonyme:
AIP, Archivinformationspaket
Archival Storage
Begriff aus dem Open Archival Information System (OAIS)
Definition:
Der Archival Storage beschreibt einen Funktionsbereich in einem digitalen Langzeitarchiv, der sich mit Fragen der langfristigen Speicherung und Wiederauffindbarkeit von digitalen Ressourcen auseinandersetzt, die als Archival Information Packages (AIP) langzeitarchiviert werden. Das Hauptaugenmerk in diesem Funktionsbereich liegt auf dem langfristigen Erhalt der Integrität von physischen Bitstreams (Bitstream Preservation). Aufgaben, die in diesen Funktionsbereich fallen, sind unter anderem die Verwaltung der verschiedenen Speichersysteme, redundante Speicherung der AIPs, der regelmäßige Austausch von Datenträgern, um drohender Obsoleszenz von Speichermedien zu begegnen (Datenmigration) und Maßnahmen zur Überprüfung der Datenintegrität (z. B. mittels Checksummen).
Im Kontext der durch das hbz betriebenen zentralen Rosetta-Infrastruktur fallen in diesen Funktionsbereich unter anderem Betrieb und Wartung dieser Infrastruktur in einem abgesicherten Rechenzentrum, die Konfiguration und Backups angebundener Server und Speicher sowie die Überwachung der Hardwarefunktionalität. Die Speicherinfrastruktur des LZV-Systems Rosetta selbst ist aufgeteilt in die Bereiche Deposit, Operational Storage und Permanent Storage .
Synonyme:
Archival Storage Functional Entity, Funktionseinheit Archivspeicher
Archivierung vs. Langzeitverfügbarkeit
Definition:
- Unter Archivierung wird die Aufbewahrung von Unterlagen für eine festgesetzte Dauer verstanden.
- angestrebte Erhaltung in der Entstehungsform (Identität), selbst wenn die einfache Lesbarkeit darunter leidet
- Unter dLZV (digitale Langzeitverfügbarkeit) wird keine archivarische Tätigkeit im eigentlichen Sinne verstanden, sondern die Umsetzung geeigneter konzeptioneller und technischer Maßnahmen zur Verfügbarhaltung des digitalen Wissens.
- Erhalt der intendierten Aussage (Authentizität), unabhängig von der Entstehungsform
Archivierung und digitale Langzeitverfügbarkeit unterscheiden sich durch
- Zielsetzung des zentralen Auftrags
- nutzungs- und urheberrechtliche Belange
- Erhalt bzw. Anpassung des jeweiligen digitalen Materials → begründet aus der jeweiligen Zielstellung
Weitere Informationen dazu im Service Wiki-Artikel: Archivierung und LZV
Arranger
Begriff aus Rosetta
Definition:
Arranger ist eine Nutzerrolle in Rosetta. User mit der Rolle Arranger arbeiten im Bereich Arrange SIPs und evaluieren SIPs, die technisch einwandfrei sind und die initialen Prüfungen (zum Beispiel auf Viren oder Dateivalidität) beim Ingest erfolgreich durchlaufen haben. Der Schwerpunkt liegt dabei auf dem Bearbeiten und Anordnen (Arrange) oder neu Anordnen (Rearrange) der Inhalte von Intellectual Entities (IEs), zum Beispiel deren Representations, Files oder Struct-Maps.
Arranger-User haben volle Rechte zum Absegnen (Approve), Ablehnen (Decline), zum Deposit-Bereich Zurücksenden (Return) von SIPs und IEs, sowie dem inhaltlichen Bearbeiten von IEs (Arrange). Der wesentliche Unterschied zur Rolle Assessor besteht beim Zuweisen von IDs von (externen) Content Management Systemen (CMS). Ein Assessor kann eine CMS ID immer nur einer einzelnen IE auf einmal zuweisen, während ein Arranger dies bei mehreren IEs gleichzeitig kann.
Assessor, Arranger, und Approver arbeiten in ihren jeweiligen Arbeitsbereichen unter Submissions → Approval.
Der Begriff Arranger wird umgangssprachlich auch synonym für den Rosetta-Arbeitsbereich Arrange SIPs verwendet. Dort können SIPs intellektuell evaluiert werden, bevor sie in den Permanentspeicher von Rosetta weitergeschoben werden. Welche Teilmenge eines Ingests zur Prüfung in den Assessor oder Approver abgelegt wird, ist von der Sampling Rate abhängig.
Synonyme:
Arrange SIPs
Assessor
Begriff aus Rosetta
Definition:
Assessor ist eine Nutzerrolle in Rosetta. User mit der Rolle Assessor arbeiten im Bereich Manuel Assessment bzw. Assess SIPs und evaluieren SIPs, die technisch einwandfrei sind und die initialen Prüfungen (zum Beispiel auf Viren oder Dateivalidität) beim Ingest erfolgreich durchlaufen haben.
Assessor-User haben volle Rechte zum Absegnen (Approve), Ablehnen (Decline), zum Deposit-Bereich Zurücksenden (Return) von SIPs und Intellectual Entities (IEs), sowie dem inhatlichen Bearbeiten von IEs (Arrange). Der wesentliche Unterschied zur Rolle Arranger besteht beim Zuweisen von IDs von (externen) Content Management Systemen (CMS). Ein Assessor kann eine CMS ID immer nur einer einzelnen IE auf einmal zuweisen, während ein Arranger dies bei mehreren IEs gleichzeitig kann.
Assessor, Arranger, und Approver arbeiten in ihren jeweiligen Arbeitsbereichen unter Submissions → Approval.
Der Begriff Assessor wird umgangssprachlich auch synonym für den Rosetta-Arbeitsbereich Assess SIPs verwendet. Dort können SIPs intellektuell evaluiert werden, bevor sie in den Approver weitergeschoben werden. Welche Teilmenge eines Ingests zur Prüfung in den Assessor oder Approver abgelegt wird, ist von der Sampling Rate abhängig.
Synonyme:
Assess SIPs, Manual Assessment
Bitstream Preservation
Definition:
Bitstream Preservation bezeichnet die Sicherstellung der physischen Integrität langzeitarchivierter digitaler Ressourcen durch den Erhalt ihres individuellen Bitstreams. Im Kontext der Langzeitverfügbarkeit ist Bitstream Preservation die physische Voraussetzung dafür, dass Dateien langfristig erhalten bleiben und vor ungewollter Veränderung geschützt werden. Bitstream Preservation ist damit auch die Voraussetzung für Logical Preservation (Erhalt der logischen Interpretierbarkeit) und Semantic Preservation (Erhalt der semantischen Interpretierbarkeit).
Bitstream Preservation wird unter anderem gewährleistet durch den regelmäßigen Austausch von Datenträgern, auf denen Dateien gespeichert sind (Datenmigration) und über regelmäßig durchgeführte Integritätsprüfungen von Bitstreams (z. B. durch Checksummen).
In Rosetta werden im Rahmen der Bitstream Preservation sogenannte Fixity Checks in den Speicherbereichen Deposit, Operational und Permanent durchgeführt. Diese basieren auf den automatisiert vom Rosetta-System generierten Checksummen SHA1, SHA-256, MD5 und CRC32.
Consumer
Begriff aus dem Open Archival Information System (OAIS)
Definition:
Nutzer eines digitalen Langzeitarchivs, an den die digitalen Ressourcen in Form von Dissemination Information Packages (DIPs) ausgegeben werden. Ein Consumer kann eine Person, aber auch ein technisches System wie eine an ein LZV-System angebundene Präsentationsplattform sein.
Synonym:
Endnutzer
Deposit
Begriff aus Rosetta
Definition:
Der Deposit ist ein Speicherbereich und ein Modul in Rosetta, in dem die Submission Information Packages (SIPs) entgegengenommen werden, die von einem Producer Agent in das LZV-System Rosetta eingeliefert werden. Der Ingest von neuen SIPs erfolgt im Deposit als sogenannte Deposit Activity. Die SIPs erhalten hier einen eigenen Identifier (SIP-ID).
Nach der erfolgreichen Einlieferung der SIPs in Rosetta werden diese im Operational Storage von Rosetta weiterverarbeitet und schließlich als AIP im Permanent Storage langzeitarchiviert.
Synonym:
Deposit Storage
Deposit Activity
Begriff aus Rosetta
Definition:
Der Begriff Deposit Activity beschreibt in Rosetta den Vorgang, bei dem Submission Information Packages in den Deposit Storage von Rosetta eingeliefert werden.
Derivative Copy
Begriff aus Rosetta
Definition:
Die Derivative Copy ist einer von drei Repräsentationstypen in Rosetta. Sie dient nur zur Anzeige des Objekts im Browser und wird daher nicht im Permanent Storage gespeichert, sondern im Operational Storage . In der AIP METS-Datei der IE ist die Derivative Copy ebenfalls nicht enthalten. Nur nach einem Export erscheinen Derivative Copies in der FileSec und StructMap der exportierten METS-Datei und werden ebenfalls exportiert. Anders als beim Preservation Master und Modified Master kann eine IE keine oder beliebig viele Derivative Copys enthalten. Liegen mehrere Derivative Copies vor, kann mithilfe des Representation Codes (High, Middle oder Low) zwischen ihnen unterschieden werden. Derivative Copies liegen in anderen, meist nicht langzeitstabilen, Dateiformaten vor als der Preservation Master. Auf Derivative Copies werden keinerlei Erhaltungsmaßnahmen angewandt.
Derivative Copies können entweder zusammen mit dem Preservation Master eingeliefert oder nachträglich hinzugefügt bzw. erstellt werden. Dafür gibt es verschiedene Möglichkeiten:
- Manuelles Hinzufügen einer extern vorhandenen Derivative Copy zu einer einzelnen IE mittels der Action Add Representation im Web Editor
- Hinzufügen von extern vorhandenen Derivative Copies zu einem Datenset aus mehreren IEs mittels eines Derivative Copy Jobs
- Automatisches Generieren einer Derivative Copy im Web Editor einer einzelnen IE, indem der Service Create Derivative Copy Representation ausgeführt wird
- Automatisches Generieren von Derivative Copies für mehrere IEs in einem Datenset mittels eines Prozesses
Weitere Services ermöglichen es außerdem, Derivative Copies zu löschen oder wiederherzustellen.
Synonyme:
Derivative Copy Representation, Nutzungskopie
Designated Community
Begriff aus dem Open Archival Information System (OAIS)
Definition:
Der Begriff Designated Community beschreibt die Zielgruppe(n) eines Digitalen Langzeitarchivs. Damit gemeint sind nicht nur aktuell existierende Nutzer*innen (Consumer) eines Digitalen Langzeitarchivs, sondern auch Personen und technische Systeme, die in Zukunft Zugriff auf die digitalen Ressourcen erhalten sollen.
Ein Digitales Langzeitarchiv muss die Bedürfnisse der Designated Community an den Erhalt digitaler Ressourcen stets im Blick haben (Community Watch) und seine Langzeitarchivierungsmaßnahmen danach ausrichten. Verändern sich im Laufe der Zeit die Bedürfnisse dieser Gruppe(n), muss das Digitale Langzeitarchiv darauf reagieren. Im Fokus stehen dabei die für die Zielgruppe(n) relevanten signifikanten Eigenschaften der digitalen Objekte.
Synonyme:
Zielgruppe, vorgesehene Zielgruppe
Digitales Langzeitarchiv
Definition:
Eine Organisation, die aus Personen und technischen Systemen besteht, die Verantwortung für die Langzeitverfügbarkeit von digitalen Informationen und deren Bereitstellung für eine vorgesehene Zielgruppe übernommen hat.
Vergleiche DIN-Norm 31644 - Kriterien für vertrauenswürdige digitale Langzeitarchive
Synonyme:
Digitales Archiv, Langzeitarchiv
Dissemination Information Package (DIP)
Begriff aus dem Open Archival Information System (OAIS)
Definition:
Das Dissemination Information Package (DIP) ist ein Informationspaket. Dabei handelt es sich um den logischen Container für eine digitale Ressource, die aus einem digitalen Langzeitarchiv an einen Consumer ausgegeben wird. Ein DIP wird auf Grundlage des Archival Information Packages gebildet.
Das durch das hbz als Dark Archive betriebene Rosetta-System sieht aktuell keine Direktausgabe von DIPs an die Nutzenden der Kooperationspartner des hbz vor. Autorisierte Mitarbeiter*innen der Kooperationspartner können allerdings direkt auf die digitalen Ressourcen und deren Metadaten zugreifen und sie im Rosetta-eigenen IE Viewer betrachten. Bei Bedarf können die Mitarbeiter*innen der Kooperationspartner digitale Ressourcen auch aus dem Rosetta-System exportieren und diese (unter Wahrung der jeweiligen Urheber- und Nutzungsrechte) über andere Plattformen für die Öffentlichkeit als Dissemination Information Packages zugänglich machen.
Synonyme:
DIP, Auslieferungsinformationspaket
DNX
Begriff aus Rosetta
Definition:
DNX (Domain-normalized XML) ist ein von ExLibris entwickeltes XML-Metadatenschema für Erhaltungsmetadaten, das auf dem abstrakten PREMIS-Modell basiert und die darin beschriebenen abstrakten Entitäten und deren Eigenschaften als XML-Elemente technisch spezifiziert.
In einem Rosetta-METS gibt DNX die Struktur und die Elemente innerhalb der Sektion für administrative Metadaten (mets:amdSec) vor. Mittels DNX werden digitale Ressourcen auf den Ebenen Intellectual Entity, Representation, File und Bitstream beschrieben. Das DNX-Profil beinhaltet dabei sowohl technische, als auch rechtliche Metadaten, Eventmetadaten und Source-Metadaten. Die DNX-Metadatenelemente sind in der Rosetta-Dokumentation im Rosetta AIP Data Model beschrieben.
Weitere Informationen dazu im Service Wiki-Artikel: Administrative Metadaten in Rosetta
DROID (Digital Record Object Identification)
Definition:
DROID ist eine von The National Archives UK entwickelte Software zur Dateiformatidentifizierung, die in Rosetta integriert ist.
DROID durchsucht bei der Dateiformatidentifizierung bestimmte Bereiche einer Datei hinsichtlich Dateiformat-typischer Eigenschaften. Diese gleicht DROID mit den Informationen der Dateiformatdatenbank PRONOM ab, in der Dateiformate registriert, beschrieben und mit einem Identifier (PRONOM Unique Identifier, PUID) versehen werden.
DROID greift bei der Dateiformatidentifizierung auf drei verschiedene Methoden zurück:
- Extension: Identifizierung auf Grundlage der Dateiendung: Dies liefert nicht immer ein verlässliches Ergebnis, da die Dateiendung leicht manipulierbar ist. Außerdem geben Dateiendungen keinen Aufschluss über die Version eines Dateiformats.
- Signature: Identifizierung auf Grundlage der File Signature (z. B. Magic Number): Die Formatidentifizierung erfolgt auf Grundlage von erkannten format- und versionsspezifischen Byte-Mustern innerhalb der Datei.
- Container: Identifizierung auf Grundlage eines Containers. Beispiel: Word-Dateien, die mit Microsoft Office 2007 erstellt worden sind, sind Container-Dateien (ZIP-Dateien), die mehrere XML-Dateien, Bilder usw. beinhalten. Durch die Container-Identifizierung und die Untersuchung der in dem Container eingebetteten Dateien kann die Datei als Microsoft Office 2007-Datei identifiziert werden und wird nicht nur als ZIP-Datei identifiziert.
Rosetta dokumentiert das Ergebnis der Dateiformatidentifizierung mittels DROID in den DNX- Metadaten zur digitalen Ressource, indem es u. a. den jeweiligen Identifier aus PRONOM hinzufügt. Kommt es zu Fehlermeldungen bei der Dateiformatidentifizierung mittels DROID innerhalb von Rosetta, werden die betreffenden SIPs in den Rosetta-Bereich Technical Issues verschoben, wo sie von einem Technical Analyst einer genaueren Prüfung unterzogen werden können.
Siehe dazu auch den Artikel: administrative Metadaten in Rosetta
Dublin Core
Definition
Dublin Core ist ein generischer Metadatenstandard zur inhaltlichen Beschreibung von analogen und digitalen Ressourcen, der von der Dublin Core Metadata Initiative (DCMI) entwickelt wird. Dublin Core existiert sowohl in einer einfachen Fassung mit allgemeinen Metadatenelementen (Simple Dublin Core) und in einer erweiterten Fassung (DCMI Metadata Terms), welche spezifische inhaltliche Beschreibungen von Ressourcen ermöglicht.
Simple Dublin Core bildet Eigenschaften digitaler Ressourcen über 15 Kern-Metadatenelemente (Properties) ab, darunter unter anderem dc:title, dc:creator, dc:identifier. DCMI Metadata Terms ergänzt einige dieser Kernelemente um sogenannte Unter-Eigenschaften (Sub-Properties), die zur differenzierten Beschreibung digitaler Ressourcen dienen. So lässt sich zum Beispiel das Kernelement Datum (dc:date) mittels DCMI Metadata Terms näher spezifizieren als Entstehungsdatum (dcterms:created) oder als Veröffentlichungsdatum (dcterms:issued).
Rosetta hat sowohl Simple Dublin Core als auch DCMI Metadata Terms als primären Standard für deskriptive Metadaten zur Beschreibung von Intellectual Entities und Files implementiert. In einer Rosetta-METS-Datei werden Dublin-Core-Metadaten in der Sektion für deskriptive Metadaten (mets:dmdSec) abgebildet und feldbasiert indexiert, wodurch eine genaue Recherche innerhalb von Rosetta ermöglicht wird. Zusätzlich können Dublin-Core-Metadaten auch als sogenannte Source-Metadata (sourceMD) in den administrativen Metadaten einer METS-Datei abgebildet werden, wo sie allerdings lediglich volltextbasiert indexiert werden.
Siehe dazu auch den Artikel: Deskriptive Metadaten in Rosetta
Siehe auch: https://dublincore.org/specifications/dublin-core/
Synonym:
DC
Erhaltungsmetadaten
Definition:
Bei Erhaltungsmetadaten handelt es sich um eine Teilmenge aus deskriptiven, administrativen, technischen und strukturellen Metadaten, die dazu benötigt werden, um digitale Ressourcen im Prozess der Langzeitverfügbarkeit vollständig zu beschreiben und um diesen Prozess nachvollziehbar zu dokumentieren.
Erhaltungsmetadaten gewährleisten unter anderem, dass Veränderungen an einer digitalen Ressource (wie z. B. Dateiformatmigrationen), die zum Zwecke der Langzeitverfügbarkeit durchgeführt worden sind, auf eine Weise protokolliert werden, dass diese Ressource auch weiterhin als authentisch gilt. Erhaltungsmetadaten bilden außerdem Informationen ab, die zur langfristigen inhaltlichen und technischen Interpretierbarkeit und zur langfristigen Rechtewahrung von digitalen Ressourcen benötigt werden. Im Kontext der Langzeitverfügbarkeit können Erhaltungsmetadaten daher als Mindestanforderung an die Metadaten zu einer digitalen Ressource betrachtet werden, um deren physischen (Bitstream Preservation), logischen (Logical Preservation) und semantischen Erhalt (Semantic Preservation) langfristig zu gewährleisten.
In Rosetta werden Erhaltungsmetadaten in dem auf PREMIS basierenden DNX-Metadatenschema abgebildet. Diese sind in der METS-Sektion für administrative Metadaten verortet.
Siehe dazu auch die Artikel Metadaten und Langzeitverfügbarkeit und Administrative Metadaten in Rosetta.
Synonym:
Preservation Metadata
Ingest
Begriff aus dem Open Archival Information System (OAIS).
Definition:
Unter dem Begriff Ingest werden alle Prozesse zusammengefasst, die zur Einlieferung und zur Weiterverarbeitung von digitalen Ressourcen nötig sind. Die Daten werden in Form von Submission Information Packages (SIPs) in ein Digitales Langzeitarchiv eingeliefert. Die Verarbeitung erfolgt zunächst mittels Producer-seitiger Prozesse zur Übermittlung von digitalen Ressourcen an ein digitales Langzeitarchiv, wie zum Beispiel das Sammeln der zu archivierenden Dateien, deren strukturierte Ablage (z. B. in einem Ordner-Verzeichnis), die Sammlung und Aufbereitung von Metadaten (z. B. durch Mappings auf ein Metadatenschema) sowie die Rechteklärung (z. B. Nutzungsrechte). Darüber hinaus gehören zum Ingest alle Prozesse seitens eines digitalen Langzeitarchivs, die dazu nötig sind, um aus einem SIP ein AIP zu bilden. Diese werden in Rosetta als Task Chain zusammengefasst.
Im Rosetta-Kontext wird anstatt von Ingest von Deposit und Submissions gesprochen. Im Deposit-Modul von Rosetta erfolgt das Producer-seitige Einliefern von Submission Information Packages in Rosetta. Im Submissions-Modul in Rosetta werden diese SIPs im Operational Storage weiterverarbeitet.
Synonyme:
Übernahme, Ingest Functional Entity, Funktionseinheit Übernahme, Deposit (Begriff aus Rosetta), Submission (Begriff aus Rosetta)
Intellectual Entity (IE)
Begriff aus dem PREMIS-Modell/Begriff aus Rosetta
Definition:
Eine Intellectual Entity (IE) ist im PREMIS-Modell eine Unterkategorie der abstrakten Entität Objects, die im Fokus der Langzeitverfügbarkeit steht. Bei einer IE handelt es sich um eine konzeptuelle Einheit, die von Menschen als in sich geschlossenes Werk wahrgenommen wird, z. B. um einen Roman. Dieses Werk kann gemäß PREMIS digital auf verschiedene Weise als Representation abgebildet werden. So ist es zum Beispiel möglich, ein Buch in Form einer oder mehrerer PDF-Dateien abzubilden oder in Form von einer oder mehreren Bild-Dateien (z. B. gescannte Buchseiten im TIFF-Format). Die IE muss im Kontext der Langzeitverfügbarkeit ausreichend beschrieben sein, damit sie langfristig als in sich geschlossene Informationseinheit wahrgenommen werden kann und inhaltlich interpretierbar ist (Semantic Preservation).
Im Rosetta-System wird eine Intellectual Entity als eine von vier Ebenen einer digitalen Ressource abgebildet: Die IE sowie die mit ihr verknüpften Representations, Files und Bitstreams werden mittels Metadaten in der Rosetta-METS-Datei als logisches AIP beschrieben. Mit der IE PID verfügen Intellectual Entities in Rosetta über einen eigenen Identifier (z. B. IE7281).
Synonyme:
IE, Intellektuelle Entität, Konzeptuelles Objekt, Intellektuelle Einheit, Conceptual Object
JHOVE (JSTOR/Harvard Object Validation Environment)
Definition:
Eine unter dem Dach der Open Preservation Foundation entwickelte Software zur Dateiformatvalidierung, die in Rosetta implementiert ist.
JHOVE durchsucht bei der Dateiformatvalidierung mehrere Bereiche einer Datei und prüft, ob deren Struktur und Inhalt konform zur jeweiligen Spezifikation des vorher bei der Dateiformatidentifizierung erkannten Dateiformats ist. In JHOVE sind verschiedene Module implementiert, mit denen Dateien verschiedener Dateiformate wie zum Beispiel PDF, TIFF und JPEG validiert werden können.
Kommt es innerhalb von Rosetta zu Fehlermeldungen bei der Dateiformatvalidierung mittels JHOVE, werden die betreffenden SIPs in den Rosetta-Bereich Technical Issues verschoben, wo sie von einem Technical Analyst einer genaueren Prüfung unterzogen werden können.
Siehe auch: https://jhove.openpreservation.org/
Langzeitstabilität
Definition:
Mit dem Begriff Langzeitstabilität werden Dateiformate beschrieben. Als langzeitstabil gelten dabei solche Formate, die in Zukunft wahrscheinlich nicht obsolet werden, und in denen Daten auch in Zukunft voraussichtlich fehlerfrei und authentisch dargestellt werden können.
Zur Beurteilung der Langzeitstabilität eines Dateiformats werden verschiedene Kriterien herangezogen, z. B. ob die Formatspezifikation öffentlich ist oder das Dateiformat proprietär ist. Diese Beurteilung ist keine einmalige Aufgabe, sondern muss wiederkehrend vorgenommen werden. Außerdem ist die Beurteilung nicht objektiv und allgemeingültig, sondern kann je nach Institution und Person unterschiedlich ausfallen.
Weitere Informationen dazu im Service Wiki-Artikel: Dateiformate und Langzeitverfügbarkeit
Eine Einschätzung des hbz zu langzeitstabilen Dateiformaten enthält die Interaktive Tafel gängiger Dateiformate.
Synonyme:
langzeitstabil
Levels of Digital Preservation
Definition:
Die Levels of Digital Preservation (LoP) sind ein 2013 unter Leitung der National Digital Stewardship Alliance (NDSA) entwickeltes Ebenen-Modell der Langzeitverfügbarkeit. Das Modell dient Institutionen, die im Bereich der Langzeitverfügbarkeit aktiv sind, als praktische Orientierungshilfe beim Auf- und Ausbau der eigenen LZV-Maßnahmen. Aufgrund seiner Praxisnähe findet das Modell breite Anwendung in der LZV-Community. Im Jahr 2020 wurden die Levels of Digital Preservation mit dem DPC Digital Preservation Award ausgezeichnet.
Die LoP liegen seit 2019 in einer überarbeiteten Version 2 vor. Sie bestehen aus einer Matrix mit 20 Praxisempfehlungen zur Durchführung hauptsächlich technischer LZV-Maßnahmen wie zum Beispiel redundante Speicherung digitaler Ressourcen. Die LoP definieren folgende fünf Handlungsbereiche der LZV: Storage, Integrity, Control, Metadata und Content. In diesen Handlungsbereichen können wiederum gemäß LoP diese vier Entwicklungsstufen (Levels) erreicht werden:
- Level 1: Know your Content (Inhalte kennen)
- Level 2: Protect your Content (Inhalte schützen)
- Level 3: Monitor your Content (Inhalte prüfen)
- Level 4: Sustain your Content (Inhalte pflegen)
Für seine Kooperationspartner hat das hbz die Services seines Rosetta-Angebots auf die Levels of Digital Preservation gemapped:
Weiterführende Infos dazu auf der hbz-Website: https://www.hbz-nrw.de/produkte/langzeitverfuegbarkeit/langzeitverfuegbarkeit-fuer-hochschulen/lzv-services
Weiterführende Infos (externer Link): https://ndsa.org/publications/levels-of-digital-preservation/
Synonyme:
LoP, NDSA Ebenen der digitalen Langzeitarchivierung
Logical Preservation
Definition:
Logical Preservation bezeichnet im Kontext der Langzeitverfügbarkeit den Erhalt der logischen Interpretierbarkeit einer digitalen Ressource, damit diese langfristig durch Hard- und Software richtig dargestellt und verarbeitet werden kann. Im Fokus steht hier die Datei, die aufgrund ihres Dateiformats eine bestimmte logische Ordnung aufweist, welche die Grundlage für die Interpretation durch technische Systeme ist (z. B. Anwendungsprogramme).
Zwei Maßnahmen zur Logical Preservation, die im Falle von veralteten oder obsolet gewordenen Dateiformaten durchgeführt werden, sind Dateiformatmigration und Emulation. Bei der Dateiformatmigration wird das Dateiformat einer Ressource in ein anderes umgewandelt, damit die Datei von aktueller Software auf die vorgesehene Weise dargestellt werden kann. Bei der Emulation wird die ursprüngliche, nicht mehr verfügbare technische Umgebung (z. B. ein Betriebssystem) simuliert.
Die Grundvoraussetzung zur Durchführung von Logical Preservation ist der Erhalt der physischen Integrität digitaler Objekte (Bitstream Preservation). Logical Preservation ist wiederum die Grundvoraussetzung für den langfristigen Erhalt der inhaltlichen Interpretierbarkeit von digitalen Ressourcen (Semantic Preservation).
Material Flow
Begriff aus Rosetta
Definition:
Ein Material Flow ist eine Reihe von miteinander verknüpften Konfigurationen innerhalb von Rosetta. Darin wird festgelegt, auf welche Weise Ingest s von Submission Information Packages durch einen Producer Agent durchgeführt werden müssen. Der Material Flow setzt sich aus den fünf Konfigurations-Komponenten Metadata Form, Submission Format, Content Structure, Access Rights Policies und Retention Periods zusammen. Diese müssen je nach Anwendungsfall unterschiedlich konfiguriert werden. Dementsprechend ist ein Material Flow immer individuell auf den entsprechenden Anwendungsfall angepasst.
In der zentralen Rosetta-Umgebung des hbz werden Material Flows zuerst in der Testumgebung (Sandbox) angelegt und dort erprobt. Nach erfolgreichen Test-Ingests werden die Konfigurations-Parameter des Material Flow manuell in die zentrale Rosetta-Produktionsumgebung des hbz übertragen.
Weiterführende Infos: https://knowledge.exlibrisgroup.com/Rosetta/Training/Rosetta_Essentials/B_-_Deposit_Module/3.1_Managing_Material_Flows_-_Introduction
METS (Metadata Encoding and Transmission Standard)
Definition:
METS (Metadata Encoding and Transmission Standard) ist ein auf XML basierender, weit verbreiteter Standard zum Austausch von Metadaten in Form einer XML-Datei, der von der Library of Congress verwaltet und weiterentwickelt wird. Eine METS-Datei ist eine XML-Datei, in der in verschiedenen Sektionen sowohl deskriptive als auch administrative, technische und strukturelle Metadaten zu digitalen Ressourcen abgebildet werden können.
In Rosetta wird der METS-Standard als Container für Metadaten zu den eingelieferten SIPs und den langzeitarchivierten AIPs genutzt. Die Bestandteile eines SIPs und eines AIPs (Intellectual Entity, Representations, Files und Bitstreams) werden vollständig innerhalb einer Rosetta-METS-Datei beschrieben und referenziert. Das vorgeschriebene Metadatenschema für deskriptive Metadaten innerhalb der Rosetta-METS-Datei ist Dublin Core. Administrative Metadaten werden in dem von ExLibris entwickelten Metadatenschema DNX beschrieben.
Siehe dazu auch den Artikel: Das METS-Metadatenaustauschformat in Rosetta
Weiterführende Infos: http://www.loc.gov/standards/mets/
Synonyme:
Metadata Encoding and Transmission Standard, METS-Container
Modified Master
Begriff aus Rosetta
Definition:
Der Modified Master ist einer von drei Repräsentationstypen in Rosetta und wird im Permanent Storage gespeichert. Er ist inhaltlich identisch mit dem Preservation Master, liegt aber in der Regel in einem anderen Dateiformat vor. Der Modified Master eines Retrodigitalisats kann zum Beispiel als eine einzige PDF-Datei vorliegen, während der Preservation Master jede Seite als einzelne TIFF-Datei enthält. Im Gegensatz zum Preservation Master muss eine IE keinen Modified Master enthalten. Die Anzahl der maximal möglichen Modified Master lässt sich nach Bedarf konfigurieren. Für alle am hbz betriebenen Rosetta-Institutionen ist eine maximale Anzahl von zwei Modified Mastern vorgesehen. Ein Modified Master kann zusammen mit dem Preservation Master eingeliefert oder nachträglich im Web Editor hinzugefügt, bearbeitet oder gelöscht werden. Außerdem können einzelne Dateien ergänzt, bearbeitet, ersetzt oder gelöscht werden.
Ein Modified Master liegt in der Regel in einem langzeitstabilen Dateiformat vor. Auf ihn können die gleichen regelmäßigen Erhaltungsmaßnahmen wie auf den Preservation Master angewandt werden, also z. B. Fixity Checks. Diese können für einzelne IEs im Web Editor durch Services angestoßen werden, oder für ein Set von IEs durch vorkonfigurierte Prozesse.
Synonyme:
Modified Master Representation
nestor
Definition:
Ein Kompetenznetzwerk zum Thema Langzeitarchivierung im deutschsprachigen Raum. Das hbz ist Kooperationspartner von nestor und als Mitglied im nestor-Steuerungsgremium und in der nestor-Koordinierungsrunde vertreten. Das hbz engagiert sich darüber hinaus in den nestor-Arbeitsgruppen "Personal Digital Archiving" und "Dokumentation der digitalen Langzeitarchivierung".
Weiterführende Infos: https://www.langzeitarchivierung.de
Object Summary
Begriff aus Rosetta
Definition:
Die Object Summary ist der erste Reiter im Web Editor von Rosetta und wird standardmäßig angezeigt, wenn auf Edit oder Editor geklickt wird, um ein Objekt in Rosetta anzusehen. Die Inhalte erscheinen in der Mitte des Bildschirms unterhalb der verschiedenen Reiter und zeigen eine kurze Zusammenfassung der jeweiligen Objektebene. Die Object Summary ist für alle Ebenen eines Objekts verfügbar, also für Intellectual Entity, Representation und File.
Die gezeigte Zusammenfassung enthält jeweils Daten wie Rosetta-Identifier (PID, REP ID, FILE ID, usw.), generelle Eigenschaften sowie je nach Objektebene auch spezifische Informationen, unter anderem Producer Agent, Anzahl der Representations auf IE-Ebene, Preservation Type auf REP-Ebene oder Dateiformat und Dateigröße auf File-Ebene.
Auf IE-Ebene befindet sich in der Object Summary außerdem der Button View Object, um sich die IE im Viewer anzusehen.
Synonyme:
Objektzusammenfassung
Open Archival Information System (OAIS)
Begriff aus dem Open Archival Information System (OAIS)
Definition:
OAIS steht für Open Archival Information System. Dabei handelt es sich um ein Referenzmodell zur allgemeinen Beschreibung eines digitalen Langzeitarchivs. Das Modell ist als ISO-Standard 14721 veröffentlicht und seine Terminologie im Kontext Langzeitverfügbarkeit weit verbreitet.
OAIS definiert ein Langzeitarchiv als eine organisatorische Einheit, die sich aus Personen und technischen Systemen zusammensetzt und verschiedene Aufgaben erfüllt. Die verschiedenen Aufgabenbereiche eines digitalen Langzeitarchivs werden im OAIS-Modell beschrieben als: Ingest, Preservation Planning, Data Management, Archival Storage, Administration und Access.
Digitale Ressourcen beschreibt das OAIS-Modell als Informationspakete, die durch Producer in ein Langzeitarchiv eingeliefert (Submission Information Package), dort archiviert (Archival Information Package) und bei Bedarf an Consumer ausgegeben werden (Dissemination Information Package).
Das OAIS-Modell ist agnostisch gegenüber verschiedenen Institutions- und Objekt-Typen sowie technischen Systemen. Es beschreibt keine rein technische Lösung für die Langzeitverfügbarkeit und ist in dem Sinne auch nicht technisch implementierbar. Allerdings orientieren sich LZV-Systeme wie Rosetta unter anderem an den im OAIS-Modell beschriebenen Aufgabenbereichen und nutzen seine Terminologie teilweise nach.
Die OAIS-Terminologie wird in Rosetta wie folgt umgesetzt:
Weiterführende Infos: https://www.dpconline.org/docs/dpc-technology-watch-publications/technology-watch-reports-1/1359-dpctw14-02/file sowie https://www.iso.org/standard/87471.html
Synonyme:
Open Archival Information System, Digitales Langzeitarchiv, Referenzmodell für ein Offenes Archiv-Informations-System
Operational Storage
Begriff aus Rosetta
Definition:
Der Operational Storage ist ein Speicherbereich in Rosetta, in dem Submission Information Packages zu Archival Information Packages weiterverarbeitet werden, nachdem sie von einem Producer Agent beim Ingest in den Deposit-Speicher überführt worden sind. Im Operational Storage verfügen die SIPs über einen eigenen Identifier (SIP ID), werden dort evaluiert und zu Archival Information Packages weiterverarbeitet. Auch AIP-Updates erfolgen im Operational Storage von Rosetta. Nach Bearbeitung der AIPs im Operational Storage werden diese im Permanent Storage von Rosetta langzeitarchiviert.
Synonym:
Operational
Permanent Storage
Begriff aus Rosetta
Definition:
Der Permanent Storage ist der Langzeit-Speicherbereich für logische Archival Information Packages in Rosetta, welche jeweils eine Intellectual Entity in Rosetta repräsentieren. Diese sind im Permanent-Speicher recherchier- und auffindbar. In Rosetta verfügen Intellectual Entities im Permanent Storage über einen eigenen Identifier (IE PID), z. B. IE7092.
Da der Permanent Storage in Rosetta für die langfristige Speicherung konzipiert ist, können darin befindliche AIPs bzw. IEs nicht verändert oder gelöscht werden. Soll ein Update von AIPs bzw. IEs in Rosetta erfolgen (z. B. durch Metadatenanreicherung), werden diese daher zuerst wieder in den Operational Storage verschoben und dort verarbeitet. Nachdem das Update durchgeführt worden ist, werden die entsprechenden IEs als neue Version wieder in den Permanent Storage überführt.
Synonyme:
Permanent, Permanent Repository, Permanentspeicher
Preservation Master
Begriff aus Rosetta
Definition:
Der Preservation Master ist einer von drei Repräsentationstypen in Rosetta. Die als Preservation Master eingelieferten Daten gelten als "Original" und somit per Definition erhaltungswürdig. Sie werden im Permanent Storage gespeichert. Der Preservation Master kann ein oder mehrere Files enthalten, die nicht das gleiche Dateiformat besitzen müssen: zum Beispiel einzelne Seiten eines Retrodigitalisats als Bilddateien und ein dazugehöriges Transkript als XML-Datei. Anders als beim Modified Master und der Derivative Copy muss und darf jede IE nur genau einen Preservation Master enthalten; dieser kann nicht gelöscht werden. Die einzelnen Dateien können aber im Web Editor bearbeitet, gelöscht, ersetzt oder ergänzt werden, wobei immer mindestens eine Datei vorhanden bleiben muss.
Das Dateiformat des Preservation Master muss nicht zwingend als langzeitstabil gelten. Regelmäßige Erhaltungsmaßnahmen wie zum Beispiel Fixity Checks können auf den Preservation Master angewandt werden. Diese können für einzelne IEs im Web Editor durch Services angestoßen werden oder für ein Set von IEs durch vorkonfigurierte Prozesse. Eventuell ist auch eine Dateiformatmigration notwendig, die mit Hilfe eines Preservation Plans durchgeführt wird.
Synonyme:
Preservation Master Representation, Master
Preservation Metadata Implementation Strategies (PREMIS)
Definition:
PREMIS ist ein Defacto-Standard im Bereich Erhaltungsmetadaten, der vom PREMIS Editorial Committee entwickelt wird. Das PREMIS Data Dictionary definiert die vier Entitäten Objects, Rights, Agents und Events. Die Beschreibung der Eigenschaften dieser Entitäten mittels Metadaten wird in PREMIS für den Kontext der Langzeitverfügbarkeit als maßgeblich angesehen. Diese Eigenschaften definiert PREMIS als abstrakte Konzepte (sogenannte semantische Einheiten), die auf unterschiedliche Weise in Metadaten abgebildet werden können. Das PREMIS Data Dictionary gilt daher nicht als ein Metadatenschema wie zum Beispiel Dublin Core oder als ein Metadatenformat wie METS, da PREMIS weder vorschreibt, wie einzelne Metadaten-Elemente benannt werden sollen, noch wie diese Metadaten technisch abgebildet werden sollen. Das PREMIS Data Dictionary ist daher technisch neutral und auf verschiedene Weise implementierbar.
Im Rosetta Datenmodell ist PREMIS als fester Bestandteil des Rosetta-METS technisch in XML implementiert. Unter anderem finden sich in Rosetta die vier Ebenen der PREMIS-Entität Object wieder, wodurch sich digitale Ressourcen und deren Bestandteile in Rosetta als Intellectual Entity, Representation, File und Bitstream beschreiben lassen. Darüber hinaus werden in Rosetta auch die PREMIS-Entitäten Agents (z. B. angebundene Tools wie DROID oder der Producer Agent), Events (z. B. AIP Update, abgebildet in der digiprovMD-Sektion des Rosetta-METS) und Rights (z. B. Access Rights, abgebildet in der rightsMD-Sektion des Rosetta-METS) mittels Metadaten in Rosetta abgebildet.
Weiterführende Infos: https://www.loc.gov/standards/premis/
Synonym:
PREMIS Data Dictionary for Preservation Metadata
Preservation Planning
Begriff aus dem Open Archival Information System (OAIS)
Definition:
Unter dem Begriff Preservation Planning werden alle Planungs- und Entscheidungsprozesse im Kontext der Langzeitverfügbarkeit zusammengefasst, die u. a. in Preservation Policies festgehalten werden. Darunter fallen zum Beispiel Absprachen mit den verschiedenen involvierten Akteur*innen (Producer, Consumer). Auch Planungen und Entscheidungen zur Übernahme und Verarbeitung von digitalen Ressourcen in ein digitales Langzeitarchiv sowie deren Ausgabe an Consumer fallen unter den Begriff Preservation Planning. Feste Bestandteile des Preservation Plannings sind ebenso das stetige Beobachten und die kontinuierliche Anpassung an die Ansprüche der Designated Community (Community Watch) und an aktuelle Entwicklungen in den Bereichen Hard- und Software sowie Dateiformate (Technology Watch). Auch signifikante Eigenschaften digitaler Ressourcen müssen beim Preservation Planning berücksichtigt werden.
Innerhalb von Rosetta beschreibt Preservation Plans ein Modul, das zum Sammeln von Informationen über Erhaltungsmaßnahmen und zur Evaluation von Risiken dient. In Rosetta werden damit nur ausgewählte technische Aspekte von Preservation Planning berücksichtigt.
Synonym:
Erhaltungsplanung
Producer
Begriff aus dem Open Archival Information System (OAIS).
Definition:
Der Begriff beschreibt Produzenten digitaler Ressourcen, welche diese in Form von SIPs beim Ingest in das digitale Langzeitarchiv überführen. Producer können sowohl Personen als auch Institutionen oder technische Systeme sein, die mit dem Langzeitarchiv interagieren.
Im zentral durch das hbz betriebenen Rosetta-System werden Datenquellen als Producer bezeichnet, aus denen die zu archivierenden digitalen Objekte stammen, z. B. ein bestimmtes Repositorium. Personen, die als Rosetta-User u. a. Ingest-Prozesse steuern, heißen Producer Agents.
Synonym:
Produzent
Producer Agent
Begriff aus Rosetta
Definition:
Ein Producer Agent ist eine zugewiesene Rolle an einen Rosetta-Nutzer, der im Auftrag eines oder mehrerer Producer die Überführung von digitalen Objekten nach Rosetta (Ingest/Deposit) und deren Weiterverarbeitung in Rosetta steuert.
Kooperationspartner des hbz entscheiden, welche ihrer Mitarbeiter*innen diesen Prozess steuern sollen. Diese bekommen vom hbz die Rolle Producer Agent zugewiesen.
PRONOM
Definition:
PRONOM ist eine Datenbank von The National Archives UK, in der Dateiformate registriert, beschrieben und mit einem Identifier (PRONOM Unique Identifier, PUID) versehen werden. In Rosetta ist PRONOM Bestandteil der Format Library. PRONOM dient hier als Wissensbasis zu Dateiformaten und als Grundlage für die Definition von Dateiformat-bezogenen Risiken im Kontext der Langzeitverfügbarkeit. Auch das Dateiformatidentifizierungstool DROID greift auf die PRONOM-Datenbank zu.
Weiterführende Infos: https://www.nationalarchives.gov.uk/PRONOM/Default.aspx
Prüfsumme
Definition:
Eine Prüfsumme oder Checksum, auch als "Fingerabdruck" einer Datei bezeichnet, ist ein eindeutiger Wert, mit dessen Hilfe die Integrität einer Datei überprüft werden kann. Eine Prüfsumme entsteht durch die Verarbeitung der Bits (des Bitstreams) einer Datei durch einen bestimmten Algorithmus. Eine einfache Methode, eine Prüfsumme zu errechnen, ist z. B. das Bilden einer Quersumme einer mehrstelligen Zahl (1234 → 10). Veränderte Eingabedaten können anhand eines solch einfachen Verfahrens jedoch nicht zuverlässig erkannt werden. Im Beispiel könnte ein Zahlendreher vorliegen und unentdeckt bleiben (2134 → 10). In der Datenverarbeitung werden daher üblicherweise Kryptographie-Algorithmen genutzt, die gleiche Prüfsummen bei unterschiedlichen Eingabedaten vermeiden sollen. Bereits die Änderung einer Stelle im Bitstream soll dazu führen, dass die Prüfsummen der Ausgangsdaten und der veränderten Daten nicht mehr übereinstimmen und die Dateiversionen somit als unterschiedlich erkannt werden. Zwei Beispiele für Kryptographie-Algorithmen sind die Merkle-Damgård-Konstruktion und der Secure Hash Algorithm. Die auf den verschiedenen Verfahren basierenden Algorithmen zur Berechnung von Prüfsummen unterscheiden sich hinsichtlich ihrer Komplexität und folglich auch ihrer Verlässlichkeit. Prüfsummen, die in Rosetta genutzt werden können, sind MD5, SHA-1, SHA-256, SHA-512 und CRC32.
Ein regelmäßig durchgeführter Prüfsummencheck ist eine der Grundlagen für die Bitstream Preservation. Zufällige Änderungen an den Daten, z. B. durch Übertragungsfehler oder andere technische Defekte ausgelöst, können damit zuverlässig erkannt werden. Für einige der bekannten Algorithmen existieren Angriffe, die auch bei veränderten Eingangsdaten die gleiche Prüfsumme erzeugen. SHA-256 und SHA-512 gelten nach wie vor als sicher.
Siehe auch: BSI - Was ist der Prüfsummencheck?
Synonyme:
Checksum
Representation
Begriff aus dem PREMIS-Modell/Begriff aus Rosetta
Definition:
Eine Representation ist im PREMIS-Modell eine Unterkategorie der abstrakten Entität Objects. Sie stellt eine digitale Abbildung der Ebene Intellectual Entity dar. Eine IE kann dabei durch eine oder mehrere Representations abgebildet werden, die sich wiederum aus einer oder mehreren Dateien zusammensetzen. Wenn es sich bei der IE um ein in sich geschlossenes literarisches Werk wie einen Roman handelt, kann dieser zum Beispiel sowohl in Form von einer oder mehreren PDF-Dateien, als auch in Form von einer oder mehreren Bild-Dateien (z. B. gescannte Buchseiten im TIFF-Format) digital dargestellt werden. Die Intellectual Entity hat demnach zwei Representations.
Im Rosetta-System wird eine Representation als eine von vier Ebenen einer digitalen Ressource abgebildet: Representations werden in der Rosetta-METS-Datei mittels Metadaten beschrieben und mit der jeweiligen IE verknüpft, die sie darstellen. Ebenso wird in der Rosetta-METS-Datei angegeben, aus welchen Files und Bitstreams sich die jeweilige Representation zusammensetzt. Mit der Representation PID verfügen Representations in Rosetta über einen eigenen Identifier (z. B. REP9823).
Es gibt in Rosetta drei Repräsentationstypen: Preservation Master, Modified Master und Derivative Copy.
Synonyme:
Repräsentation, REP
Rosetta Ressourcenstruktur
Definition:
Daten, die in Rosetta eingeliefert werden, sind gemäß des Datenmodells in Informationspaketen strukturiert. Der Aufbau der Objekte innerhalb der Pakete folgt der Rosetta Ressourcenstruktur. Diese basiert auf PREMIS und den dort definierten vier Ebenen von Objekten, die hierarchisch aufeinander aufbauen:
- Intellectual Entity (IE):
- eine konzeptuelle, gedachte Einheit
- von Menschen als in sich geschlossenes Werk wahrgenommen, z. B. ein Roman
- eine IE kann mehrere Repräsentationen haben, z. B. derselbe Roman als .pdf oder in Form eingescannter Einzelseiten als .tiff
- Representation (REP):
- eine digitale Abbildung der Intellectual Entity
- bildet ab, aus welchen konkreten Dateien die Repräsentation besteht
- gibt die korrekte Reihenfolge der Dateien an
- eine Repräsentation kann dabei aus 1-n Dateien bestehen
- grundsätzlich drei Typen: Preservation Master, Modified Master, Derivative Copy
- File:
- die konkreten Dateien, aus denen sich eine Repräsentation zusammensetzt
- Bitstream:
- die physische Grundlage von Dateien in Form einer Abfolge von Bits (Einsen und Nullen)
Der Aufbau dieser Struktur am Beispiel einer IE mit zwei Repräsentationen. Jede Repräsentation besteht dabei aus zwei Dateien.
Darstellung der Struktur in Rosetta. Der Bitstream wird dabei nicht dargestellt.
Sampling Rate
Begriff aus Rosetta
Definition:
Die Sampling Rate (deutsch etwa Stichprobenanteil / Messintervall) definiert, welcher Anteil eines Ingests zur manuellen Überprüfung bereitgestellt werden soll, wenn die automatischen Prüfungen auf Viren, Validität und Prüfsummen von Rosetta abgeschlossen sind.
Die Sampling Rate wird im Material Flow in Prozent angegeben. Steht die Sampling Rate zum Beispiel auf 30%, dann wird eine Stichprobe von 30% der SIPs eines durchgeführten Ingests in die Arbeitsbereiche unter Submissions → Approval weitergeleitet, wo die SIPs und IEs von Nutzer*innen mit den Rollen Assessor und Arranger nochmal inhaltlich geprüft und gegebenenfalls neu strukturiert werden, bevor ein User mit der Rolle Approver die SIPs final absegnet. Rosetta sichert die enthaltenen Intellectual Entities anschließend im Permanentspeicher. Damit haben die IEs den Ingestprozess vollständig durchlaufen.
Wenn die Sampling Rate auf 0% steht, werden alle Datenpakete, die technisch einwandfrei sind, automatisch in den Permanentspeicher verschoben, ohne dass eine manuelle Evaluation stattfindet.
Semantic Preservation
Definition:
Semantic Preservation bezeichnet im Kontext der Langzeitverfügbarkeit den Erhalt der inhaltlichen Interpretierbarkeit einer digitalen Ressource. Im Fokus steht hier das jeweilige Werk (Intellectual Entity), das digital abgebildet wird und langfristig für die jeweiligen Zielgruppen (Designated Community) verständlich sein soll.
Semantic Preservation wird durch ausreichend vorhandene Metadaten zur digitalen Ressource ermöglicht, die wichtige Kontext- und Strukturinformationen liefern. Die Metadaten stellen sicher, dass eine digitale Ressource (z. B. durch vergebene Schlagwörter) in ihrem inhaltlichen und zeitlichen Kontext verstanden werden kann sowie vollständig und sinnhaft dargestellt wird.
Die Grundvoraussetzungen zur Durchführung von Semantic Preservation sind der Erhalt der physischen Integrität (Bitstream Preservation) und der Erhalt der logischen Interpretierbarkeit digitaler Ressourcen (Logical Preservation).
In Rosetta wird im Rahmen von Semantic Preservation vordergründig der Metadatenstandard Dublin Core verwendet. Mittels Dublin Core werden inhaltliche Kontextinformationen als deskriptive Metadaten im Rosetta-System abgebildet und recherchierbar gemacht.
Signifikante Eigenschaften
Begriff aus dem PREMIS-Modell
Definition:
Signifikante Eigenschaften bezeichnen im PREMIS-Modell die Eigenschaften einer digitalen Ressource, die in einem digitalen Langzeitarchiv unbedingt erhalten werden sollen, um die Ressource so authentisch wie möglich bewahren zu können und sie langfristig technisch wie inhaltlich interpretierbar zu halten (Logical Preservation und Semantic Preservation). Signifikante Eigenschaften können dabei für die Ebenen Intellectual Entity, Representation, File und Bitstream festgelegt werden.
Alle Maßnahmen der Langzeitverfügbarkeit inklusive das Preservation Planning müssen deshalb danach ausgerichtet sein, die signifikanten Eigenschaften einer digitalen Ressource zu bewahren. Je nach den Bedürfnissen aktueller oder zukünftiger Zielgruppe (Designated Community), können sich die signifikanten Eigenschaften von Ressourcen unterscheiden. Demnach muss für jeden Anwendungsfall individuell evaluiert werden, welche signifikanten Eigenschaften im Kontext der Langzeitverfügbareit zu erhalten sind.
In Rosetta werden signifikante Eigenschaften auf File-Ebene in der Format Library festgelegt und automatisiert aus den Dateien extrahiert. Darüber hinaus können auch für die Ebenen Intellectual Entity, Representation und Bitstream signifikante Eigenschaften in den DNX-Metadaten von Rosetta abgebildet werden.
Synonym:
Significant Properties
Staging
Begriff aus Rosetta
Definition:
Staging ist der Bereich in Rosetta, in dem ein Submission Information Package (SIP) verschiedene Verarbeitungsschritte bzw. -stufen (Processing Stages) durchläuft. Der Begriff Staging kann dabei sowohl den entsprechenden Rosetta Bereich beschreiben, als auch die Verarbeitungsschritte, die darin durchgeführt werden.
Nach einem Ingest wird ein SIP vom Deposit Storage in die Staging Area verschoben und dort weiterverarbeitet, indem eine vorher definierte Task Chain angewendet wird. Die darin festgelegten Tasks (in Form eines Validation Stack) werden der Reihe nach abgearbeitet. Konnten alle Tasks ohne Fehler durchgeführt werden, wird das SIP nacheinander in einen oder mehrere der Approval-Bereiche (Assessor, Arranger und/oder Approver) verschoben. Sind technische Fehler aufgetreten, muss vorher eine Fehlerbehandlung im Technical Analyst erfolgen.
Je nach Konfiguration muss das Verschieben des SIP in die nächste Stage händisch angestoßen werden. Dies erfolgt über die Aktion Move to next stage. Im Technical Analyst gibt es dagegen die Aktion Move to next step, da Fehlerbehandlung nicht als Verarbeitungsschritt definiert ist, sondern eine Unterbrechnung des Staging darstellt, die solange besteht, bis alle Fehler behandelt sind, die den reibungslosen Durchlauf eines SIP durch die Staging Area verhindern.
Das Verschieben des SIP in die Staging Area, die zu nutzende Task Chain und die daraufhin angesteuerten Approval-Bereiche werden über die SIP Routing Rule und SIP Processing Configuration definiert. Nachdem ein SIP den Approval-Bereich durchlaufen hat, wird außerdem ggf. eine Enrichment Routine angewendet, sofern eine solche konfiguriert ist.
Das Staging endet, wenn das SIP in den Permanentspeicher verschoben wird. Das Verschieben des SIP von der Staging Area in den Permanentspeicher stellt dabei die letzte Stufe (Stage) in der Verarbeitung nach dem Ingest dar.
Synonyme:
Staging Area, Staging Server
Structural IE
Begriff aus Rosetta
Definition:
Structural IEs sind hierarchisch angeordnete Intellectual Entities. Sie dienen dazu, Überordnungen und Unterordnungen darzustellen. Structural IEs in Rosetta bestehen aus einer Structural-Ebene (Parent-IE) und untergeordneten Content-IEs (Child-IEs). Die Structural-Ebene erzeugt eine IE, die - wie z. B. in einem Bibliothekssystem - eine Reihe, Zeitschrift, usw. repräsentiert. Der Structural-Ebene sind keine Files zugeordnet, sondern untergeordnete Child-IEs. Die Child-IEs enthalten die Objekte (Ausgabe, Artikel usw.).
Der Ingest von Structural IEs ist sowohl mit METS als auch CSV möglich. Es stehen derzeit drei Wege zur Auswahl:
- eine leere Parent-IE erzeugen, indem Metadaten ohne Dateien eingeliefert werden
- eine Child-IE zu einem bestehenden Parent hinzufügen
- die Structural- und Content-Ebenen gleichzeitig als komplette Struktur einliefern
Außerdem können Collections in Rosetta in Structural IEs konvertiert werden.
Synonyme:
Nested IE
Submission Information Package (SIP)
Begriff aus dem Open Archival Information System (OAIS)
Definition:
Das Submission Information Package (SIP) ist ein Informationspaket. Dabei handelt es sich um den logischen Container, in dem digitale Ressourcen beim Ingest in ein digitales Langzeitarchiv eingeliefert werden. Die Container-Struktur eines SIP kann auf verschiedene Arten abgebildet werden.
In Rosetta werden SIPs durch eine bestimmte Ordnerstruktur abgebildet, in der sich digitale Ressourcen und deren Metadaten befinden. Rosetta kann durch diese Ordnerstruktur die verschiedenen Ebenen einer digitalen Ressource (IE, Representation, File, Bitstream) identifizieren, zueinander in Beziehung setzen und sie im Rosetta-System entsprechend abbilden. Submission Information Packages erhalten im Deposit-Speicher von Rosetta einen eigenen Identifier (SIP ID) und werden im Operational Storage weiterverarbeitet. Intellectual Entities innerhalb eines SIPs werden in Rosetta zu einzelnen logischen Archival Information Packages (AIP) weiterverarbeitet und in den permanenten Speicher (Permanent Storage) überführt.
Synonyme:
SIP, Übergabeinformationspaket, Einlieferungspaket
Submission Job
Begriff aus Rosetta
Definition:
Ein Submission Job in Rosetta ist ein Prozess, der zum halbautomatisierten und automatisierten Einliefern von Submission Information Packages (SIPs) dient. Der Submission Job ist das zentrale Verfahren für alle Ingests, unabhängig von dem gewählten Einlieferungsverfahren bzw. der Struktur der Metadaten (z. B. METS oder CSV).
Werden die einzuliefernden SIPs automatisch via OAI-Harvesting erstellt, ist der Submission Job der zweite Schritt dieses Einlieferungsverfahrens. Dabei greift der Submission Job auf das selbe Verzeichnis zu, in dem der Harvester zuvor die SIPs erzeugt hat. Dieser Speicherort wird im Material Flow im Submission Format festgelegt. Wird nicht via OAI-PMH geharvestet, müssen die SIPs anderweitig erzeugt und für Rosetta bereitgestellt werden. Hierfür stehen unterschiedliche Optionen zur Verfügung (wie z. B. der hbz I/O-Server).
Task Chain
Begriff aus Rosetta
Definition:
Als Task Chain (etwa: Aufgaben-Kette) wird eine Abfolge von Tätigkeiten (Tasks) zur Verarbeitung von Daten bezeichnet, die von Rosetta oder einem Plugin automatisiert ausgeführt werden können. Dazu gehören Aufgaben wie die Überprüfung der Prüfsumme, der Virencheck, das Erstellen einer Representation, das Hinzufügen zu einer Collection, aber auch das Löschen einer Representation oder Intellectual Entity (IE).
Damit Task Chains von Rosetta-Usern genutzt werden können, müssen diese aus einem oder mehreren Tasks erstellt werden. In der Task Chain werden ausgewählte Tasks in einer bestimmten Reihenfolge angeordnet und mit Parametern versehen.
Beim Erstellen einer Task Chain wird diese einer Gruppe zugeordnet. Die Gruppe bestimmt, an welcher Stelle in Rosetta die Task Chain genutzt werden kann. Eine Task Chain, die nur der Gruppe Validation Stack zugeordnet ist, kann z. B. nur während der Einlieferung genutzt werden. Auch ob eine Task Chain als Prozess oder Service im Webeditor verfügbar ist, wird durch ihre Gruppe festgelegt.
Ein Beispiel für eine Task Chain ist der sogenannte Validation Stack. Dieser übernimmt bei einem Ingest folgende Aufgaben: Überprüfen von Prüfsummen, Virenprüfung, Dateiformatidentifizierung, Dateiformatvalidierung, Extraktion technischer Metadaten sowie eine formatspezifische Risikoanalyse. Durch die Parameter wird bspw. bestimmt, welcher Prüfsummenalgorithmus und welches Virencheck-Plugin genutzt werden. Für jeden Prüfsummenalgorithmus muss also eine neue Task Chain angelegt werden.
Die Erstellung von Task Chains obliegt dem hbz und kann gerne bei uns via Ticket angefragt werden: https://support.hbz-nrw.de/
Weitere Informationen dazu im Service-Wiki-Artikel: Sets und Prozesse in Rosetta
Technical Analyst
Begriff aus Rosetta
Definition:
Technical Analyst ist eine Nutzerrolle in Rosetta. Technical Analysts arbeiten im Rosetta-Bereich Submissions →Technical Issues an SIPs, in denen bei den automatischen Prüfungen Fehler aufgetreten sind. Dabei gibt es verschiedene Fehlerkategorien in entsprechenden Reitern:
- Deposit: Kann auftreten wenn Objekte vom IO-Server in den Deposit Storage von Rosetta geladen werden und kann Deposit Activities vollständig betreffen
- Loading: Tritt auf, wenn Objekte vom Deposit Storage in das Staging-Modul von Rosetta geladen werden, wo das SIP weiterverarbeitet und in ein AIP umgewandelt wird. Loading Fehler können ganze SIPs betreffen
- Validation: Der häufigste Fehlertyp. Tritt auf, wenn im Rahmen der Einlieferung Fehler bei der Validierung oder Metadaten-Extraktion von Dateien erkannt werden. Für die Analyse kommen JHOVE, DROID (ggf. Siegfried) und der Virenscanner von Rosetta zum Einsatz. Validation-Fehler sind unterteilt in Virus Check Errors, Fixity Check Errors, Format Identification Errors, Format Validation Errors und Technical MD Extract Errors. Diese Fehler werden immer dateispezifisch erkannt.
- Bytestream: Fehler im Datenstrom von Dateien, Fehler betrifft einzelne Datei(en)
- Enrichment: Tritt bei einer potentiellen Anreicherung mit (technischen) Metadaten auf und betrifft einzelne Datei(en)
- To Permanent: Tritt auf wenn ein Objekt nicht von der Staging Area in den Permanentspeicher verschoben werden kann und betrifft individuelle Datei(en)
- System Error: Tritt auf wenn der Ingest vollständig fehlschlägt, z. B. bei Verbindungsabbrüchen zum Quellsystem
Technical Analysts sichten, analysieren und beheben diese Fehler, um die SIPs fehlerfrei in den Permanentspeicher verschieben zu können.
Der Begriff Technical Analyst wird umgangssprachlich auch synonym für den Rosetta-Arbeitsbereich Technical Issues verwendet. Dort können von Fehlern betroffene SIPs, IEs oder Dateien bearbeitet werden, bevor sie mit Move to next Stage in den Assessor, Approver oder Permanentspeicher weitergeschoben werden. Welcher Arbeitsbereich bzw. Speicher der nächste Schritt ist, hängt von der Sampling Rate ab.
Siehe dazu auch den Artikel: Fehler in Technical Issues/Technical Analyst
Synonyme:
TA, Technical Issues, Technical Analysis
Vollabzug
Begriff aus Rosetta
Definition:
Ein Vollabzug ist das vollständige Harvesten ("Ernten") aller Metadatensätze eines kompletten Datensets aus einem technischen System (z. B. aus einem Repositorium) oder der Metadatensätze aller Sets eines solchen Systems. Auch das Ergebnis eines solchen Harvests, also die entsprechende Datenmenge, wird als Vollabzug bezeichnet.
Durch einen Vollabzug kann z. B. ein gesamter Bestand aus einem Quellsystem in ein Langzeitverfügbarkeitssystem wie Rosetta übernommen werden, beispielsweise alle Dissertationen eines bestimmten Fachgebiets.
Ein Vollabzug und die nachfolgende Einlieferung nach Rosetta kann beispielsweise als zweischrittiger Prozess aus OAI-PMH-Harvesting und Submission Job strukturiert werden.
Web Editor
Begriff aus Rosetta
Definition:
Rosetta bietet unterschiedliche Möglichkeiten zur Interaktion mit den Daten (z. B. IEs). Neben APIs ist das insbesondere der browserbasierte Web Editor. Dieser kann beispielsweise über eine Objektsuche auf der Startseite im Reiter Preserved erreicht werden. Die Ergebnisliste dieser Suche enthält auf der rechten Seite zu jeder IE einen Link auf einen Editor. Aus dem Assessor ist der Editor per Edit IE erreichbar.
Der Web Editor bietet verschiedene Optionen zur Übersicht und Bearbeitung von Objekten, die auf verschiedene Reiter aufgeteilt sind. Dazu gehören die Object Summary, Metadata, Services zum Ausführen von vorkonfigurierten Prozessen, Collection und Versions. Wenn es sich bei einem Objekt um die Parent-Ebene einer Structural IE handelt, enthält der Web Editor zusätzlich das Tab Contents, in dem die Child-Objekte aufgelistet sind.
XML
Definition:
XML (Extensible Markup Language, auf Deutsch in etwa erweiterbare Auszeichnungssprache) ist ein textbasiertes Datenformat. Es ist für die Beschreibung, Speicherung und den Austausch strukturierter Informationen konzipiert. Es kann leicht von Menschen und Maschinen interpretiert werden und ist daher weit verbreitet. Eine XML-Datei ist aus Tags aufgebaut, die zwischen spitzen Klammern ("<", ">") stehen.
XML ist im LZV-Kontext relevant, da Dateien für das Metadatenaustauschformat METS in XML geschrieben werden. Daher enthalten alle SIPs (Submission Information Packages) für einen METS-Ingest immer eine ie.xml. Beim Harvesting mittels OAI-PMH werden ie.xml-Dateien mittels eines XSLT-Skriptes automatisch von Rosetta erzeugt. Auch bei einem Export von IEs oder Metadaten aus Rosetta werden die entsprechenden Metadaten-Dateien der AIPs als XML ausgeliefert.
Weitere Informationen dazu unter https://www.w3.org/XML/
Synonyme:
Extensible Markup Language