Deskriptive Metadaten

Im digitalen Langzeitarchivierungssystem werden beschreibende Metadaten mit dem Ziel erfasst, die Objekte eindeutig beschreiben und identifizieren zu können. Die beschreibenden Metadaten sollen langfristig die inhaltliche Zuordnung des Objekts gewährleisten und werden von den entsprechenden Fachteams der TIB erstellt, von den Datenproduzenten direkt an das Team Langzeitarchivierung abgeliefert oder vom Team Langzeitarchivierung von verschiedenen Datenquellen abgeholt. Beschreibende Metadaten in der DC-Sektion der ie.xml (siehe Spezifikation für Archivinformationspakete (AIP)) müssen als Dublin Core vorhanden sein. Diese Metadaten werden indexiert. In die Source MD-Sektion der ie.xml können verschiedene Metadatenstandards (MARC, Dublin Core, MODS, EAD, NISO, MIX und weitere) eingebunden werden.

Es gibt aktuell mehrere Verfahren für die Erfassung von deskriptiven Metadaten:

• die Anreicherung mit Metadaten aus dem Verbundkatalog K10plus
• die Erfassung von über die OAI-Schnittstelle mitgelieferten Dublin Core Metadaten vom Institutionellen Repositorium der Leibniz Universität Hannover
• die Erfassung von mitgelieferten Dublin Core Metadaten in der dc-Section der ie.xml
• die Erfassung von mitgelieferten Metadaten aus Quellsystemen als Source-Metadaten in der ie.xml

Weitere Katalogsysteme können bei Bedarf angebunden werden.

Anreicherung mit Metadaten aus dem Verbundkatalog K10plus

 
Bibliothekarinnen und Bibliothekare erfassen Metadaten zu den Objekten nach dem Katalogisierungsstandard RDA. Ältere Katalogisate liegen nach dem Standard RAK-WB vor.

Beim Übergang vom operativen Speicher in den permanenten Archivspeicher wird das CMS-Enrichment ausgeführt, das über die SRU-Schnittstelle des Verbundkataloges K10plus Metadaten abfragt und den Output auf Dublin Core mappt. Ein Mapping regelt die Zuordnung der PICA+-Felder zu den entsprechenden Dublin-Core-Qualified-Elementen sowie den Umfang, die Struktur und den Inhalt der beschreibenden Metadaten.

Die Metadaten werden in eine separate Katalog.xml geschrieben, mit einem Identifier benannt und der Identifier in die ie.xml geschrieben. Die Metadaten aus der Katalog.xml werden indexiert.

Mappingtabelle von PICA+ auf Dublin Core

Von Datenproduzenten abgelieferte oder von einer Plattform geharvestete Metadaten

Für vom Datenproduzenten mitgelieferte und von Plattformen abgeholte Metadaten hat das Team Langzeitarchivierung Minimalsets für unterschiedliche Publikationsformen in Dublin Core definiert. Metadaten, die nicht als Dublin Core vorliegen, können als Source Metadaten in das Archivpaket aufgenommen werden.

Monografien

Inhalt	erfasst in	Pflicht
Titel	dc:title
Autorennamen (wiederholbar)	dc:creator / dc:contributor
ISBN	dc:identifier xsi:type=”dcterms:ISBN"
DOI	dc:identifier xsi:type=”dcterms:URI"
weitere eindeutige Identifier	dc:identifier
Sprache	dc:language
Erscheinungsjahr	dcterms:issued
Beschreibung/Abstract	dcterms:abstract
Verlag/Herausgeber	dc:publisher

Zeitschriftenartikel

Inhalt	erfasst in	Pflicht
Artikeltitel	dc:title
Autorennamen (wiederholbar)	dc:creator / dc:contributor
Zeitschriftentitel ; Jahrgang/Volume , Issue , Jahr	dcterms:isPartOf	///
DOI	dc:identifier xsi:type=”dcterms:URI"
ISSN	dc:identifier xsi:type=”dcterms:ISSN"
Sprache	dc:language
Erscheinungsdatum/-jahr	dcterms:issued
Beschreibung/Abstract	dcterms:abstract

Identifizierende Metadaten

Eingesetzte Identifier

Systeminterne Identifier auf Objektebene

Rosetta erzeugt und vergibt verschiedene systeminterne Identifier.

• Identifier für Objekte: von Rosetta erzeugte systeminterne Identifier zur Identifizierung von IEs, Repräsentationen, Files und Paketen während des Deposits und der SIP-Prozessierung.
• Identifier für Eventtyp: von Rosetta fest vorgegebene ID für ein Eventkategorie (siehe Event).
• Identifier für Prozesse: von Rosetta vergebene ID für ausgeführte Prozesse, zum Beispiel eine Preservation Action (siehe Administrative Metadaten und Protokollierung von Erhaltungsmaßnahmen)
• Identifier für Rechte: die ID einer Policy, zum Beispiel eines konfigurierten Nutzungsrechts (siehe ), einer Aufbewahrungsfrist (Retention Policy) oder einer Ablieferungslizenz.
• Identifier für Agents: die ID eines Agenten im Sinne von PREMIS, zum Beispiel eines Producers, eines Plug-ins , eines angebundenen Systems oder eines Users.

Die systeminternen Identifier sind innerhalb des Systems eindeutig und dauerhaft.

Werden neue Policies oder Prozesse von einem User definiert, vergibt das System dafür eine eindeutige ID. In den Metadaten werden weitere Identifier erfasst.

Katalogmetadaten

Ein weiterer optionaler externer Identifier in der ie.xml ist der Katalog-Identifier aus dem K10plus. Mittels in Rosetta konfigurierter SRU-Schnittstelle zum Katalogsystem wird der Katalog-Identifier zur Anreicherung des Objekts mit deskriptiven Metadaten genutzt.

Die Katalogmetadaten eines jeden Objekts werden in einer eigenen XML-Datei abgelegt, welche mittels Metadaten-Identifier (mId) mit der IE verknüpft ist.

Identifier werden PREMIS-konform für Objects, Agents, Events und Rights vergeben. Die folgende Tabelle listet exemplarisch Beispiele für Identifier auf.

Beispiele für Identifier anhand des PREMIS-Modells

Externe Identifier

Externe Identifier können im Dublin-Core-Format aufgenommen werden, zum Beispiel ein DOI, ein Handle oder eine URN.

Vergabe von Identifiern

Systeminterne Identifier werden vom System als Unique Identifier automatisch vergeben. Je nach Objekttyp erhalten die Identifier verschiedene Zusätze.

Strukturelle Metadaten

Strukturelle Metadaten werden in der ie.xml als DNX- und METS-Elemente erfasst.

Die TIB erfasst pro IE 1-n Repräsentationen, die aus 1-n Dateien bestehen. Repräsentationen werden mit dem DNX-Element „Preservation Type“ beschrieben. Jede ie.xml beinhaltet die IDs aller zugehörigen Repräsentationen und Files. In der File Group werden Files via ihres Pfades einer File-ID zugeordnet, zusätzlich wird jede File-ID einer Repräsentations-ID zugeordnet. In der StructMap werden die Files pro Repräsentation in eine logische Reihenfolge gebracht, die an einen Viewer übergeben werden kann.

Strukturelle Metadaten - Zuordnung zu METS- und DNX-Elementen

Die Beziehungen der Dateien innerhalb einer Repräsentation werden in dem METS-Element „structMap“ erfasst.Zusätzlich wird von jeder Datei der Originaldateiname und -pfad in den Metadaten erfasst und so dokumentiert, in welcher Verzeichnisstruktur eine Datei beim Deposit abgelegt war.

Technische Metadaten

Technische Metadaten werden in Rosetta als DNX-Metadaten erfasst. DNX wurde vom Softwarehersteller ExLibris spezifiziert und basiert auf PREMIS, erweitert den Standard jedoch um weitere Elemente. Die Dokumentation von DNX ist öffentlich einsehbar. Die Fortschreibung von DNX wird von der Rosetta User Community gesteuert und überwacht.

Der PREMIS-Standard selbst definiert eine Reihe von „Basiskonzepten“ als technische Metadaten in den Semantischen Einheiten ObjectCharacteristics, SignificantProperties, OriginalName und Storage. Die entsprechenden Konzepte der Einheit sind in nachstehender Tabelle aufgeführt. Es erfolgt hier ein Mapping des PREMIS-Konzepts auf das DNX-Element sowie die Angabe, an welcher Stelle das Konzept mit Values versehen werden kann und der Hinweis, ob die Erfassung aktuell von der TIB umgesetzt ist.

Technische Metadaten - Mapping von PREMIS auf DNX

Protokollierung von Erhaltungsmaßnahmen

Definierte Events

Änderungen an AIPs werden auf IE-Ebene als DNX-Metadaten erfasst. Das DNX-Schema wurde vom Softwarehersteller ExLibris spezifiziert und basiert auf PREMIS, erweitert den Standard jedoch um weitere Elemente. Die Dokumentation von DNX ist öffentlich einsehbar. Die Fortschreibung von DNX wird von der Rosetta User Community gesteuert und überwacht.

Einige Beispiele für definierte Events sind in der folgenden Tabelle beschrieben. Die vollständige Liste mit definierten Events ist im Rosetta Configuration Guide dokumentiert.

Beispiel-Events

Ein User mit der Rolle „Administrator“ kann definieren, welche Events aus der Liste protokolliert werden sollen.

Protokollierung von Eventmetadaten

Die definierten Eventmetadaten werden automatisiert vom System erfasst. Zu jedem definierten Event werden Eventmetadaten in die ie.xml geschrieben.

Administrative Metadaten

Definierte administrative Metadaten

Administrative Metadaten werden in Rosetta auf verschiedenen Ebenen als DNX-Metadaten erfasst. DNX wurde vom Softwarehersteller ExLibris spezifiziert und basiert auf PREMIS, erweitert den Standard jedoch um weitere Elemente. Die Dokumentation von DNX ist öffentlich einsehbar.

Auf IE-Ebene wird der standardisierte Name des geltenden Lizenztextes als Dublin-Core-Element dctersm:license erfasst. Der geltende Lizenztext wird als sogenanntes Boilerplate in Rosetta hinterlegt und beinhaltet die Informationen, welche Aktionen am Objekt vorgenommen werden dürfen.

Die TIB versteht unter administrativen Metadaten:

• Metadaten, die die Provenienz der Objekte dokumentieren
• rechtliche Metadaten
• Metadaten, die zum Zweck der Organisation der Objekte erfasst werden

 Provenienzinformation

Rechtliche Metadaten

Organisatorische Metadaten