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 descriptive metadata is intended to ensure the long-term assignment of the object's content and is created by the relevant TIB specialist teams are intended to ensure at TIB, delivered directly to the long-term content-based assignment of objectsarchiving team by the data producers or collected from various data sources by the long-term archiving team.. Descriptive metadata in the DC section of the ie.xml must be available as Dublin Core metadata (see 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

• the capture of supplied Dublin Core metadata in the dc section of ie.xml

• the capture of supplied metadata from source systems as source metadata in ie.xml

Additional catalogue systems may be connected as required.

Enrichment with metadata from the

union catalogue K10plus

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

Metadata delivered by data producers or harvested by a platform.

For metadata supplied by the data producer and harvested by platforms, the Long-Term Preservation team has defined minimum sets for different forms of publication in Dublin Core. Metadata that is not available as Dublin Core can be included in the archive package as source metadata.

Monographs

Content	captured in	mandatory
title	dc:title
author names (repeatable)	dc:creator / dc:contributor
ISBN	dc:identifier xsi:type=”dcterms:ISBN"
DOI	dc:identifier xsi:type=”dcterms:URI"
other unique identifiers (repeatable)	dc:identifier
language	dc:language
publication year	dcterms:issued
abstract	dcterms:abstract
publisher	dc:publisher

Journal articles

Content	captured in	mandatory
article title	dc:title
author names (repeatable)	dc:creator / dc:contributor
journal title; volume , issue , publication year	dcterms:isPartOf	///
DOI	dc:identifier xsi:type=”dcterms:URI"
ISSN	dc:identifier xsi:type=”dcterms:ISSN"
language	dc:language
publication year	dcterms:issued
abstract	dcterms:abstract

Identifying metadata

Identifiers used

Internal-system identifiers at the object level

Rosetta creates and allocates various internal-system identifiers.

• Identifiers

  Identifier for objects:

  Rosetta-created internal-system identifiers for identifying

  system internal identifier generated by Rosetta to identify IEs, representations, files and

  packages

  packets during deposit and SIP processing.

• Identifiers for events: a permanent Rosetta-assigned ID for processes, such as for an event or a process.

• Event type identifier: Rosetta-defined ID for an event category (see Event).

• Identifier for Processes: ID assigned by Rosetta for executed processes, for example a Preservation Action (see ADM and Event).

• Rights identifier

  Identifiers for rights

  : the ID of a policy,

  such as governing configured access rights

  for example, a configured usage right (see ), a retention

  period (retention

  policy

  )

  , or a

  transfer licence

  delivery license.

• Identifiers

  Identifier for agents: the ID of an agent

  along

  in the

  lines

  sense of PREMIS,

  such as

  for example, 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

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.

Anker
SMD SMD

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 In the File Group, files are assigned to a file ID via their path, and each file ID is also assigned to a representation ID. In the StructMap the files per representation are put into a logical order, which can be passed to a viewer.

Structural metadata − assignment to METS and DNX elements

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. 

Anker
TMD TMD

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

Anker
Event Event

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

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. 

Anker
ADM ADM

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

Anker
AR AR

Legal metadata

Organisational metadata