- Angelegt von Franziska Schwab, zuletzt geändert am 10. Mai 2019
Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.
Unterschiede anzeigen Seitenhistorie anzeigen
« Vorherige Version anzeigen Version 2 Nächste Version anzeigen »
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.
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. 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.
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
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. |
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
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 |
Rechtliche Metadaten
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 |
Descriptive metadata
Descriptive metadata are recorded in the digital preservation system with the aim of being able to uniquely describe and identify objects in bibliographic terms. The bibliographical metadata delivered by the relevant TIB specialist teams are intended to ensure the long-term content-based assignment of objects. Descriptive metadata in the DC section of the ie.xml must be available as Dublin Core metadata (see Specifications for Archival Information Packages (AIP)). These metadata are indexed. Various metadata standards (MARC, Dublin Core, MODS, EAD, NISO, MIX) can be integrated in the source MD section of the ie.xml.
There are currently two methods of recording descriptive metadata:
- Enrichment with metadata from the Gemeinsamer Verbundkatalog (Union Catalogue, GVK)
- Recording of Dublin Core metadata also delivered by Leibniz Universität Hannover Institutional Repository via the OAI interface
Additional catalogue systems may be connected as required.
Enrichment with metadata from the Gemeinsamer Verbundkatalog
Librarians collect metadata on the objects according to the RDA cataloguing standard. Older catalogue records are available based on the RAK-WB standard.
CMS enrichment is conducted during the transition from operational to permanent archival storage. CMS enrichment involves querying metadata via the SRU interface of the Gemeinsamer Verbundkatalog and mapping the output to Dublin Core. Mapping governs the assignment of PICA+(only in german) fields to the relevant Dublin Core qualified elements, as well as the scope, structure and content of the descriptive metadata.
The metadata are written to a separate catalogue.xml and given an identifier; the identifier is written to the ie.xml. The metadata from the catalogue.xml are indexed.
Mapping table from PICA+ to Dublin Core
Dublin Core | Pica+ | Remark | Mandatory |
---|---|---|---|
Title | 036C/00 | Collective title of the multi-part monograph and the subcategorisations (in master form) | Yes, in combination with 021A |
isPartOf | 036C/00 | Collective title of the multi-part monograph and the subcategorisations (in master form) | No |
title | 021A | Main title, other title information, information on responsibilities | Yes |
alternative | 046B | Specification of parallel titles that are not on the title page | No |
Alternative | 021F* | Parallel titles | No |
Alternative | 046C* | Deviating titles | No |
Creator | 028A | Person/family as first creator (formerly: first author) | No |
Creator | 028B/.. | Second author and additional authors | No |
creator or contributor | 028C/00* | Person/family as additional creators, other contributing persons and families | No |
Creator | 029A | Body / first originator | No |
Contributor | 028M | Creator from superordinate C set | No |
Contributor | 028G-028L | Other person, dedicatee (old prints), censor (old prints), artistic contributor (old prints), other non-involved persons or persons named in the title (old prints) | No |
creator or contributor | 029F/00* | Secondary body, other bodies involved | No |
Contributor | 030F* | Congress | No |
Publisher | 033A* | Publication details (place of publication and publisher) | No |
Publisher | 037C* | Note in university publications | No |
Issued | 011@ | Publication date | No |
language | 010@ | Language codes | No |
identifier | 005A* | ISSN | No |
identifier | 004U* | Persistent identifier: URN | No |
identifier | 004V | Persistent identifier: DOI | No |
identifier | 004R* | Persistent identifier: Handle | No |
identifier | 004A* | ISBN | No |
identifier | 007F* | Report number | No |
identifier | 007G | ID number given by first cataloguing institution (EKI) | Yes |
identifier | 003@ | PICA production number (PPN) | No |
isPartOf | 036E* | Monographic series | No |
isPartOf | 036F* | Monographic series (link) | No |
isPartOf | 039B* | Link to larger entity (in the case of articles) | No |
Bibliographic Citation | 031A | Differentiating information about the source | No |
description | 032@ | Edition statement | No |
description | 032B | Reprint note | No |
Identifying metadata
Identifiers used
Internal-system identifiers at the object level
Rosetta creates and allocates various internal-system identifiers.
- Identifiers for objects: Rosetta-created internal-system identifiers for identifying IEs, representations, files and packages during deposit and SIP processing.
- Identifiers for events: a permanent Rosetta-assigned ID for processes, such as for an event or a process.
- Identifiers for rights: the ID of a policy, such as governing configured access rights, a retention period (retention policy) or a transfer licence.
- Identifiers for agents: the ID of an agent along the lines of PREMIS, such as a producer, a plug-in, a connected system or a user.
The internal-system identifiers are unique and permanent within the system.
If new policies or processes are defined by a user, the system assigns a new unique ID. Additional identifiers are recorded in the metadata.
Catalogue metadata
Another optional external identifier in the ie.xml is the catalogue identifier from the Gemeinsamer Verbundkatalog (Union Catalogue, GVK). By means of the SRU interface to the catalogue system, configured in Rosetta, the catalogue identifier is used to enrich the object with descriptive metadata.
The catalogue metadata of each individual object are deposited in a dedicated XML file, which is linked to the IE via metadata identifiers (mId)
Identifiers are allocated PREMIS-compliant for objects, agents, events and rights. The following table lists several examples of identifiers.
Examples of identifiers based on the PREMIS model
Object | Example |
---|---|
SIP ID | 539308 |
IE ID | IE2980431 |
REP ID | REP2980432 |
File ID | FL2980433 |
Identifier for the catalogue system | GBV881139254 |
mId | 1032839 |
Versioning | V9-IE1024027.xml |
Agent | |
Producer ID | 40030044 |
Producer agent ID | 2122740 |
Plug-in ID | 58638365 |
Catalogue system | TIB |
User ID | 2122740 |
Event | |
Material flow ID | 641084 |
Deposit ID | 548243 |
Event ID | 62 |
Process ID | 50532321 |
Rights | |
Boilerplate ID | TIB_OA_mit_CC |
Access right policy ID | 16728 |
Retention policy ID | NO_RETENTION |
External identifiers
External identifiers can be recorded in Dublin Core format, such as a DOI, a handle or a URN.
Allocation of identifiers
Internal-system identifiers are automatically allocated by the system as unique identifiers. The identifiers are given different additions, depending on the object type.
Structural metadata
Structural metadata are stored in the ie.xml as DNX and METS elements.
TIB stores 1-n representations per IE, each consisting of 1-n files. Representations are described using the DNX element “Preservation type”. Each ie.xml contains the IDs of all accompanying representations and files. Each representation refers to the IDs of the files belonging to it in the METS file section.
Structural metadata − assignment to METS and DNX elements
Metadatum | Element and metadata standard | Value |
---|---|---|
Representations | ||
Original files | Preservation type (DNX) | MASTER |
Modified copy of original files before ingest | Preservation type (DNX) | PRE-INGEST_MODIFIED_MASTER |
Modified copy of original files after ingest | Preservation type (DNX) | MODIFIED_MASTER |
Access copy | Preservation type (DNX) | DERIVATIVE_COPY |
Relationships | ||
Belonging of files to a representation | fileGrp (METS) | REP ID, File ID, storage path to the file |
Coherence of files within a representation | structMap (METS) | Representation ID, label structure, file ID |
Restoration of authentic data structure | ||
Original file name | fileOriginalName (DNX) | Original file name |
Original file path | fileOriginalPath (DNX) | Original file path |
The relationships between files within a representation are recorded in the “structMap” METS element. In addition, the original file name and path of every file are recorded in the metadata, documenting which directory structure a file was stored in during deposit.
Technical metadata
Technical metadata are captured in Rosetta as DNX metadata. DNX was specified by the software manufacturer Ex Libris and is based on PREMIS, but extends the standard by further elements. DNX documentation is publicly available. Updating of DNX is managed and monitored by the Rosetta user community.
The PREMIS standard defines a number of “basic concepts” as technical metadata in the semantic units ObjectCharacteristics, SignificantProperties, OriginalName and Storage. The relevant concepts of the unit are provided in the table below. In this case, the PREMIS concept is mapped to the DNX element, as well as information about at which point the concept can be allocated values and whether TIB has implemented the recording.
Technical metadata − mapping from PREMIS to DNX
PREMIS semantic unit / component from | DNX element | Method of recording | Used by TIB |
---|---|---|---|
ObjectCharacteristics | |||
compositionLevel | compositionLevel | Pre-ingest | No |
fixity | |||
messageDigestAlgorithm | fileFixty.fixityType | See K10 | Yes |
messageDigest | fileFixty.agent | See K10 | Yes |
messageDigestOriginator | fileFixity.fixityValue | See K10 | Yes |
size | generalFileCharacteristics.fileSizeBytes | Determined automatically during ingest | Yes |
format | |||
formatDesignation | |||
formatName | fileFormat.formatName | Automatically during ingest | Yes |
formatVersion | fileFormat.formatVersion | Automatically during ingest | Yes |
formatRegistry | |||
formatRegistryName | fileFormat.formatRegistry | Automatically during ingest | Yes |
formatRegistryKey | fileFormat.formatRegistryId | Automatically during ingest | Yes |
formatRegistryRole | fileFormat.formatRegistryRole | Automatically during ingest | Yes |
formatNote | fileFormat.formatNote | Manually by the technical analyst during ingest involving manual allocation to format | Yes |
creatingApplication | |||
Last name | creatingApplication.creatingApplicationName | As part of the pre-ingest process, manually via the web editor or automatically as part of a preservation plan | No
TIB does not use this semantic concept to capture the creatingApplication, but records the values – provided they can be recorded by the technical metadata extractor – under significant properties as part of the technical metadata |
Version | creatingApplication.creatingApplicationVersion | See above | See above |
dateCreatedByApplication | creatingApplication.dateCreatedByApplication | See above | See above |
creatingApplicationExtension | creatingApplication.creatingApplicationExtension | See above | See above |
inhibitors | |||
inhibitorType | inhibitors.inhibitorType | As part of the pre-ingest process or manually via the web editor | Yes |
inhibitorTarget | inhibitors.inhibitorTarget | See above | See above |
inhibitorKey | inhibitors.inhibitorKey | See above | See above |
significantProperties | |||
significantPropertiesType | significantPropertiesType | Metadata extraction in the validation stack | Yes |
significantPropertiesValue | significantPropertiesValue | See above | Yes |
significantPropertiesExtension | significantPropertiesExten | See above | Yes |
originalName | fileOriginalName | Automatically during ingest | Yes |
fileOriginalPath | Automatically during ingest | Yes | |
storage | |||
contentLocation | |||
contentLocationType | fileLocationType | Automatically during ingest (system – loading stage) | Yes |
contentLocationValue | fileLocation | Is not used by Rosetta at present. |
Logging of preservation actions
Defined events
Modifications to AIPs are recorded at the IE level as DNX metadata. The DNX schema was specified by the software manufacturer Ex Libris and is based on PREMIS, but extends the standard by additional elements. DNX documentation is publicly available. Updating of DNX is managed and monitored by the Rosetta user community.
Several examples of defined events are described in the table below. The complete list of defined events is documented in the Rosetta Configuration Guide.
Examples of events
Event ID | Description |
---|---|
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 |
A user with the role of “Administrator” can define which events from the list should be logged.
Logging of event metadata
The system automatically records the defined event metadata. Event metadata are written to the ie.xml for every defined event.
Administrative metadata
Defined administrative metadata
Administrative metadata are captured as DNX metadata at different levels in Rosetta. DNX was specified by the software manufacturer Ex Libris and is based on PREMIS, but extends the standard by further elements. DNX documentation is publicly available.
At the IE level, the standardised name of the applicable licence agreement is recorded as the Dublin Core element dctersm:license. The applicable licence text is deposited in Rosetta as a “boilerplate”; the text contains information about which actions may be performed on the object.
TIB understands administrative metadata to mean:
- Metadata that document the provenance of objects
- Legal metadata
- Metadata recorded for the purpose of organising objects
Provenance information
Provenance information | DNX element |
---|---|
Acquisition team responsible | producer |
| producerId |
| userIdAppId |
| defaultLanguage |
| authorativeName |
| firstName |
| lastName |
| middleName |
| address1 |
| address2 |
| address3 |
| address4 |
| zip |
| emailAddress |
| telephone1 |
Legal metadata
Legal metadata | Element |
---|---|
Access rights | accessRightsPolicy (DNX) |
policyId (DNX) | |
policyDescription (DNX) | |
Standardised name of applicable licence text | Dcterms:license (Dublin Core) |
Organisational metadata
Organisational metadata | DNX element |
---|---|
General object characteristics (at the IE representation and file level, respectively) | objectCharacteristics |
ObjectType | |
parentID | |
groupID | |
creationDate | |
createdBy | |
modificationDate | |
modifiedBy | |
owner | |
IE characteristics | generalIECharacteristics |
submissionReason | |
status | |
statusDate | |
Identification of object type | IEEntityType |
Identifier for the collection and production path | UserDefinedFieldA |
Preservation level | preservationLevel |
preservationLevelValue | |
Representation characteristics | generalRepCharacteristics |
label | |
preservationType | |
usageType |
- Keine Stichwörter