Versionen im Vergleich
Schlüssel
- Diese Zeile wurde hinzugefügt.
- Diese Zeile wurde entfernt.
- Formatierung wurde geändert.
Inhalt
Inhalt | ||||||
---|---|---|---|---|---|---|
|
Weiterführende Informationen
Archivinformationspakete (AIP)
Erhaltungsplanung (Preservation Management)
Rosetta Produktdokumentation: Rosetta DNX Profile im Rosetta AIP Data Model
Deskriptive Metadaten
Im digitalen Langzeitarchivierungssystem werden beschreibende Metadaten mit dem Ziel erfasst, die Objekte im bibliographischen Sinne eindeutig beschreiben und identifizieren zu können. Die von entsprechenden Fachteams der TIB gelieferten bibliographischen Metadaten sollen langfristig die inhaltliche Zuordnung des Objekts gewährleisten. 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) eingebunden werden.
Es gibt aktuell zwei Verfahren für die Erfassung von deskriptiven Metadaten:
- die Anreicherung mit Metadaten aus dem Gemeinsamen Verbundkatalog
- die Erfassung von über die OAI-Schnittstelle mitgelieferten Dublin Core Metadaten vom Institutionellen Repositorium der Leibniz Universität Hannover
Weitere Katalogsysteme können bei Bedarf angebunden werden.
Anreicherung mit Metadaten aus dem Gemeinsamen Verbundkatalog
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 Gemeinsamen Verbundkataloges (GVK) 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
Dublin Core | Pica+ | Bemerkung | Pflicht |
---|---|---|---|
Title | 036C/00 | Gesamttitel der mehrteiligen Monografie und der Untergliederungen (in Vorlageform) | ja, Kombination mit 021A |
isPartOf | 036C/00 | Gesamttitel der mehrteiligen Monografie und der Untergliederungen (in Vorlageform) | nein |
title | 021A | Haupttitel, Zusätze, Verantwortlichkeitsangabe | ja |
alternative | 046B | Angabe von Paralleltiteln, die nicht auf der Haupttitelseite stehen | nein |
Alternative | 021F* | Paralleltitel | nein |
Alternative | 046C* | abweichende Titel | nein |
Creator | 028A | Person/Familie als 1. geistiger Schöpfer (früher: 1. Verfasser) | nein |
Creator | 028B/.. | 2. und weitere Verfasser | nein |
creator oder contributor | 028C/00* | Person/Familie als weitere geistige Schöpfer, sonstige beteiligte Personen und Familien | nein |
Creator | 029A | Körperschaft/1. Urheber | nein |
Contributor | 028M | Verfasser aus übergeordnetem C-Satz | nein |
Contributor | 028G-028L | sonstige Person, Widmungsempfänger (alte Drucke), Zensor (alte Drucke), künstlerischer Beiträger (alte Drucke), sonstige Nichtbeteiligte bzw. im Titel genannte Personen (alte Drucke) | nein |
creator oder contributor | 029F/00* | Sekundärkörperschaft, sonstige beteiligte Körperschaft | nein |
Contributor | 030F* | Kongress | nein |
Publisher | 033A* | Veröffentlichungsangabe (Erscheinungsort und Verlag) | nein |
Publisher | 037C* | Hochschulschriftenvermerk | nein |
Issued | 011@ | Erscheinungsdatum | nein |
language | 010@ | Sprachcodes | nein |
identifier | 005A* | ISSN | nein |
identifier | 004U* | Persistent Identifier: URN | nein |
identifier | 004V | Persistent Identifier: DOI | nein |
identifier | 004R* | Persistent Identifier: Handle | nein |
identifier | 004A* | ISBN | nein |
identifier | 007F* | Reportnummer | nein |
identifier | 007G | Identnummer der erstkatalogisierenden Institution (EKI) | ja |
identifier | 003@ | PICA-Produktionsnummer (PPN) | nein |
isPartOf | 036E* | monografische Reihe | nein |
isPartOf | 036F* | monografische Reihe (Verknüpfung) | nein |
isPartOf | 039B* | Verknüpfung zur größeren Einheit (bei Aufsätzen) | nein |
Bibliographic Citation | 031A | differenzierende Angaben zur Quelle | nein |
description | 032@ | Ausgabebezeichnung | nein |
description | 032B | Reprintvermerk | nein |
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 Events: von Rosetta fest vorgegebene ID für Prozesse, zum Beispiel für ein Event oder einen Prozess.
- Identifier für Rechte: die ID einer Policy, zum Beispiel eines konfigurierten Nutzungsrechts, 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 GVK. 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
Object | Beispiel |
---|---|
SIP-ID | 539308 |
IE-ID | IE2980431 |
REP-ID | REP2980432 |
File-ID | FL2980433 |
Identifier zum Katalogsystem | GBV881139254 |
mId | 1032839 |
Versionierung | V9-IE1024027.xml |
Agent | |
Producer-ID | 40030044 |
Producer Agent ID | 2122740 |
Plug-in-ID | 58638365 |
Katalogsystem | TIB |
User-ID | 2122740 |
Event | |
Material Flow-ID | 641084 |
Deposit-ID | 548243 |
Event-ID | 62 |
Prozess-ID | 50532321 |
Rights | |
Boilerplate-ID | TIB_OA_mit_CC |
Access Right Policy-ID | 16728 |
Retention Policy ID | NO_RETENTION |
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.
Anker | ||||
---|---|---|---|---|
|
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. Jede Repräsentation verweist in der METS File Section auf die IDs der Files, die zu ihr gehören.
Strukturelle Metadaten - Zuordnung zu METS- und DNX-Elementen
Metadatum | Element und Metadatenstandard | Wert |
---|---|---|
Repräsentationen | ||
Originaldateien | Preservation Type (DNX) | MASTER |
Modifizierte Kopie von Originaldateien vor dem Ingest | Preservation Type (DNX) | PRE-INGEST_MODIFIED_MASTER |
Modifizierte Kopie von Originaldateien nach dem Ingest | Preservation Type (DNX) | MODIFIED_MASTER |
Nutzungskopie | Preservation Type (DNX) | DERIVATIVE_COPY |
Beziehungen | ||
Zugehörigkeit von Dateien zu einer Repräsentation | fileGrp (METS) | REP-ID, File-ID, Speicherpfad zur Datei |
Zusammenhang von Dateien innerhalb einer Repräsentation | structMap (METS) | Repräsentations-ID, Labelstruktur, File-ID |
Wiederherstellung der authentischen Datenstruktur | ||
Originaldateiname | fileOriginalName (DNX) | Originaldateiname |
Originaler Dateipfad | fileOriginalPath (DNX) | originaler Dateipfad |
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.
Anker | ||||
---|---|---|---|---|
|
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
PREMIS Semantic Unit / Component aus | DNX-Element | Erfassungsmethode | Von TIB genutzt |
---|---|---|---|
ObjectCharacteristics | |||
compositionLevel | compositionLevel | Pre-Ingest | nein |
fixity | |||
messageDigestAlgorithm | fileFixty.fixityType | siehe K10 | ja |
messageDigest | fileFixty.agent | siehe K10 | ja |
messageDigestOriginator | fileFixity.fixityValue | siehe K10 | ja |
size | generalFileCharacteristics.fileSizeBytes | automatisch im Ingest ermittelt | ja |
format | |||
formatDesignation | |||
formatName | fileFormat.formatName | automatisch im Ingest | ja |
formatVersion | fileFormat.formatVersion | automatisch im Ingest | ja |
formatRegistry | |||
formatRegistryName | fileFormat.formatRegistry | automatisch im Ingest | ja |
formatRegistryKey | fileFormat.formatRegistryId | automatisch im Ingest | ja |
formatRegistryRole | fileFormat.formatRegistryRole | automatisch im Ingest | ja |
formatNote | fileFormat.formatNote | manuell von Technischem Analyst im Ingest bei manueller Zuweisung zu Format | ja |
creatingApplication | |||
Name | creatingApplication.creatingApplicationName | als Teil vom Pre-Ingest, manuell über Web-Editor oder automatisch als Teil eines Preservation Plans | nein Die TIB nutzt zur Erfassung der creatingApplication nicht dieses Semantic Concept, sondern erfasst die Values – insofern vom technischen Metadata Extractor erfassbar – als Teil der technischen Metadaten unter Significant Properties |
Version | creatingApplication.creatingApplicationVersion | siehe oben | siehe oben |
dateCreatedByApplication | creatingApplication.dateCreatedByApplication | siehe oben | siehe oben |
creatingApplicationExtension | creatingApplication.creatingApplicationExtension | siehe oben | siehe oben |
inhibitors | |||
inhibitorType | inhibitors.inhibitorType | Als Teil vom Pre-Ingest oder manuell via Web-Editor | Ja |
inhibitorTarget | inhibitors.inhibitorTarget | siehe oben | siehe oben |
inhibitorKey | inhibitors.inhibitorKey | siehe oben | siehe oben |
significantProperties | |||
significantPropertiesType | significantPropertiesType | Metadatenextraktion im Validation Stack | Ja |
significantPropertiesValue | significantPropertiesValue | siehe oben | Ja |
significantPropertiesExtension | significantPropertiesExten | siehe oben | Ja |
originalName | fileOriginalName | automatisch im Ingest | ja |
fileOriginalPath | Automatisch im Ingest | ja | |
storage | |||
contentLocation | |||
contentLocationType | fileLocationType | automatisch im Ingest (System – Loading stage) | ja |
contentLocationValue | fileLocation | Wird aktuell von Rosetta nicht genutzt. |
Anker | ||||
---|---|---|---|---|
|
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
Event-ID | Beschreibung |
---|---|
23 | Started Validation Stack Stage |
24 | Virus check performed on file |
25 | Format Identification performed on |
27 | Fixity check performed on file |
147 | Arranger ‐ Decline IE |
164 | Object viewing is denied due to Access Rights restrictions |
165 | Technical Metadata extraction performed on file |
166 | Completed Validation Stack Stage |
167 | Metadata enrichment (CMS fetching) |
217 | Failed MD Validation Stage |
339 | Preservation plan has been created |
372 | Manually Set Format Library ID on File |
380 | Representation has been added |
381 | Risk identification performed on file |
397 | METS Validation Failed |
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
Provenienzinformation | DNX-Element |
---|---|
Zuständiges Erwerbungsteam | producer |
| producerId |
| userIdAppId |
| defaultLanguage |
| authorativeName |
| firstName |
| lastName |
| middleName |
| address1 |
| address2 |
| address3 |
| address4 |
| zip |
| emailAddress |
| telephone1 |
Anker | ||||
---|---|---|---|---|
|
Rechtliche Metadaten | Element |
---|---|
Nutzungsrecht | accessRightsPolicy (DNX) |
policyId (DNX) | |
policyDescription (DNX) | |
standardisierter Name des geltenden Lizenztextes | Dcterms:license (Dublin Core) |
Organisatorische Metadaten
Organisatorische Metadaten | DNX-Element |
---|---|
allgemeine Objekteigenschaften (jeweils auf IE- Repräsentations- und Dateiebene) | objectCharacteristics |
ObjectType | |
parentID | |
groupID | |
creationDate | |
createdBy | |
modificationDate | |
modifiedBy | |
owner | |
IE-Eigenschaften | generalIECharacteristics |
submissionReason | |
status | |
statusDate | |
Kennzeichnung der Objektart | IEEntityType |
Kennzeichnung für die Sammlung und den Produktionsweg | UserDefinedFieldA |
Preservation Level | preservationLevel |
preservationLevelValue | |
Repräsentationseigenschaften | generalRepCharacteristics |
label | |
preservationType | |
usageType |