METS allgemein

METS (Metadata Encoding & Transmission Standard) ist ein auf XML (Extensible Markup Language) basierender, weit verbreiteter Standard zum Austausch von Metadaten. METS wird von der Library of Congress verwaltet und weiterentwickelt. 

Eine METS-Datei ist eine XML-Datei, in der deskriptive, administrative, technische und strukturelle Metadaten in verschiedenen Sektionen abgebildet werden können. Diese Sektionen geben die allgemeine Struktur vor,  in der Metadaten in verschiedenen Schemata eingebettet werden können. 

METS-Struktur allgemein (Sektionen)

Eine METS-Datei gliedert sich in verschiedene Sektionen. Jede Sektion enthält dabei verschiedene Arten von Metadaten.

METS Header <metsHdr>

Der METS-Header enthält Metadaten, welche die METS-Datei selbst beschreiben. Dazu gehören der Urheber der METS-Datei, das Erstellungsdatum und das Datum der letzten Änderung, sowie der aktuelle Status der Datei. Auch verschiedenen Identifier können hier angegeben werden.

Descriptive Metadata Section <dmdSec>

Die Descriptive Metadata Section (dmdSec) enthält die deskriptiven Metadaten zu einer digitalen Ressource, die diese inhaltlich beschreiben, z. B. Titel, Thema etc.

Administrative Metadata Section <amdSec>

Die Administrative Metadata Section ist für administrative Metadaten vorgesehen, die technische Merkmale der digitalen Ressource sowie deren einzelne Bestandteile und Herkunft näher beschreiben. Untersektionen der Administrative Metadata Section sind: 

• <techMD> für technische Metadaten
• <rightsMD> für technische Zugriffsrechte
• <sourceMD> für Metadaten aus einem Quellsystem
  
• <digiprovMD> für Metadaten, welche die Herkunft einer digitalen Ressource näher beschreiben, z. B. erstellende Institution oder Programm, welches die Daten erzeugt hat

Anhand dieser administrativen Angaben lässt sich nachvollziehen, woher die digitale Ressource stammt, wie ihre technische Beschaffenheit ist und wer welchen Zugriff auf die Ressource hat.

File Section <fileSec>

In dieser Sektion werden die zur beschriebenen Ressource gehörenden Dateien referenziert, gruppiert und deren Speicherort aufgeführt. Die Sektion <fileSec> beinhaltet damit eine Übersicht über alle Dateien.

Structural Map Section <structMap>

In dieser Sektion wird die hierarchische Dateistruktur einer digitalen Ressource angegeben, d. h. in welcher Reihenfolge die einzelnen Dateien abgerufen werden müssen, um eine intellektuelle Einheit kohärent digital darzustellen. Wenn es sich bei der digitalen Ressource z. B. um ein digitalisiertes Buch handelt, das aus mehreren Scans von Einzelseiten besteht, wird in der Structural Map Section angegeben, welche Bilddatei die erste Seite ist, welche die zweite usw. Außerdem kann eine hierarchische Anordnung beschrieben werden, z. B. in Form von Kapitelüberschriften.

Structural Link Section <structLink>

Die Structural Link Section beinhaltet Hyperlinks zwischen den Dateien, die in der Structural Map Section beschrieben werden. Dies ist zum Beispiel relevant bei der Archivierung von Websites, bei denen verschiedene HTML-Dateien über Hyperlinks miteinander verknüpft sind. 

Behavior Section <behaviorSec>

Diese Sektion dient zur Beschreibung des Verhaltens der Teile einer digitalen Ressource, wenn sie ausgeführt werden. Dies ist insbesondere bei digitalen Ressourcen relevant, die Anwendungsprogramme sind und als solche über ausführbaren Code verfügen. 

METS in Rosetta

Das Rosetta-Datenmodell basiert auf dem oben beschriebenen allgemeinen METS-Standard und nutzt die METS-Struktur als Container für Metadaten zu den eingelieferten Submission Information Packages (SIPs) und den langzeitarchivierten Archival Information Packages (AIPs). Die Bestandteile eines SIPs und eines AIPs - Intellectual Entity (IE), Representations, Files - werden vollständig innerhalb einer Rosetta-METS-Datei beschrieben und referenziert. 

Rosetta verfügt mit dem Rosetta-METS über ein eigenes METS-Profil. Es verwendet das von Ex Libris entwickelte DNX-Schema, welches die Elemente für administrative Metadaten in der dazugehörigen Sektion definiert.

Im Rosetta-METS-Profil wird zwischen drei grundlegenden Arten von Metadaten unterschieden, die in verschiedene Sektionen aufgeteilt sind:

• Deskriptive Metadaten beschreiben inhaltliche Informationen zu IEs und zu Dateien. Im Rosetta-METS wird hier als Standard das Metadatenschema DC (DC) verwendet. 
  
• Administrative Metadaten werden größtenteils von Rosetta erstellt und dienen der Verwaltung von Ressourcen innerhalb von Rosetta. Sie beinhalten sowohl technische Angaben als auch Zugriffsrechte zu den langzeitarchivierten digitalen Ressourcen.  
• Strukturelle Metadaten beschreiben die Beziehungen zwischen den einzelnen Komponenten einer digitalen Ressource. 

Die folgende Tabelle stellt die verschiedenen Metadaten-Sektionen einer Rosetta-METS-Datei pro Objekt-Ebene in Rosetta dar. 

	Descriptive	Administrative	Structural Map
IE
Representation
File

Rosetta-METS Struktur allgemein (Sektionen und Wrapper)

Ein Rosetta-METS ist in folgende Sektionen aufgeteilt:

• Descriptive Metadata Section: <dmdSec>
• Administrative Metadata Section: <amdSec>
  • Technical Metadata Section: <techMD> 
  • Rights Metadata Section: <rightsMD> 
  • Source Metadata Section: <sourceMD>
    
  • Digital Provenance Metadata Section: <digiprovMD>
• Content File Section: <fileSec> 
• Structural Map: <structMap> 

Die Sektionen METS Header, Behaviour und Structural Links des allgemeinen METS-Profils werden im Rosetta-METS-Profil nicht verwendet.

In den einzelnen Sektionen werden zueinander gehörende Metadaten von sogenannten Wrappern <mets:mdWrap> umschlossen. Dadurch lassen sich verschiedene Metadaten voneinander abgrenzen, zum Beispiel Metadaten verschiedener Representations, die zu einer IE gehören. 

Ob eine METS-Datei valide ist, kann bereits außerhalb von Rosetta überprüft werden, s. a. Validierung einer METS-Datei.

Das folgende Beispiel zeigt den groben Aufbau einer METS-Datei in Rosetta. Am Beispiel der Administrative Metadata Section wird hier detailliert dargestellt, wie technisch-administrative Metadaten einer Representation in die METS-Datei integriert werden.

Der Inhalt der anderen Sektionen (<dmdSec>, <fileSec> und <structMap>) ist aus Gründen der Übersichtlichkeit in diesem Beispiel nur mit Platzhaltern dargestellt ( [...] ).

Descriptive Metadata: <mets:dmdSec>

Deskriptive Metadaten werden in der Sektion <dmdSec> gespeichert, die sowohl auf der IE-Ebene als auch auf der File-Ebene vorkommen kann. In Rosetta können also IEs und Files inhaltlich beschrieben werden, aber keine Representations. Auf IE-Ebene muss es eine <dmdSec> geben, auf File-Ebene ist dies optional.  

Das Metadatenschema für deskriptive Metadaten in Rosetta ist DC. DC-Elemente, die in der <dmdSec> aufgeführt sind, werden von Rosetta feldbasiert indexiert. Das bedeutet, dass über diese Metadaten innerhalb von Rosetta recherchiert werden kann. Wenn im ursprünglichen Quellsystem der digitalen Ressourcen keine Metadaten in DC, sondern in einem anderen Metadatenschema vorliegen, sollten diese bei der Einlieferung nach Rosetta auf DC gemapped werden. Rosetta unterstützt sowohl Simple DC als auch DCMI Metadata Terms (DCTERMS).

Deskriptive Metadaten aus dem ursprüngliche Quellsystem können als sogenannte Source Metadata in die <amdSec> des Rosetta-METS integriert werden (s. u.). 

Administrative Metadata: <mets:amdSec>

Administrative Metadaten beschreiben Eigenschaften von IEs, Representations und Files, die zur Verwaltung digitaler Ressourcen in Rosetta benötigt werden. Diese Metadaten befinden sich im Rosetta-METS in der Sektion <amdSec> und sind in vier Untersektionen aufgeteilt. 

• <mets:techMD>: Sektion für technische Metadaten zu einer Ressource, z. B. die Dateigröße. Die Metadaten dieser Sektion liegen im DNX-Schema vor.
  
• <mets:rightsMD>: Sektion für Zugriffsrechte zu einer Ressource. Die Metadaten dieser Sektion liegen im DNX-Schema vor.
  
• <mets:digiprovMD>: Sektion für Provenienzmetadaten zu einer Ressource, darunter auch Events wie z. B. Validierungsprüfungen. Die Metadaten dieser Sektion liegen im DNX-Schema vor.
  
• <sourceMD>: Sektion für Metadaten aus dem Quellsystem, z. B. deskriptive Metadaten im MARC-Schema, oder technische Metadaten im MODS-Format. 
  • Achtung: Diese Metadaten werden nicht feldbasiert in Rosetta indexiert! 

Das folgende Beispiel zeigt den groben Aufbau einer <amdSec> und deren Untersektionen <techMD>, <rightsMD>, <digiprovMD> und <sourceMD> innerhalb einer METS-Datei in Rosetta. Die Angaben in dem Beispiel beziehen sich auf die Representation mit der ID "rep1".

Content File Section: <mets:fileSec>

In der Content File Section werden die Eigenschaften der Dateien detailliert beschrieben. Dabei beschreibt jeder als <mets:fileGrp> gekennzeichnete Abschnitt die Dateien, die sich zu jeweils einer Representation zusammensetzen. Verfügt eine IE z. B. über zwei verschiedene Representations, finden sich in der Content File Section der METS-Datei jeweils zwei File Groups <mets:fileGrp>. Die in diesen Abschnitten beschrieben Dateien verfügen jeweils über einen eigenen Identifier. Der Speicherort der Dateien wird über den Tag  File Location <FLocat> referenziert.

Das folgende Beispiel zeigt den groben Aufbau einer <fileSec> innerhalb einer METS-Datei in Rosetta. Die Angaben in dem Beispiel beziehen sich auf die Representations mit den IDs "rep1" und "rep2". 

Structural Map: <mets:structmap>

In einer Structural Map Section wird eine bestimmte Representation über die dazugehörige ID referenziert, z. B. "rep1". Die Structural Map selbst hat ebenfalls einen eigenen Identifier, z. B. "rep1-1". Durch sogenannte File Pointer <fptr> werden die zur Representation gehörenden Dateien referenziert. Für jede Representation kann es mehrere Structural Maps geben. 

Die Representations und Files können ein oder mehrere Labels haben, die sich in den generischen Containern <mets:div> befinden. Labels sind optionale Attribute der einzelnen DIV-Container. Sie dienen dazu, die Struktur der Dateien menschenlesbar zu machen. Die Verwendung von Labels kann besonders bei komplexen Structural Map Sections sinnvoll sein. Wird kein Label auf File-Ebene angegeben, steht hier automatisch der Dateiname.

Es gibt zwei verschiedene Typen von Structural Maps: Physical und Logical. Bei einer Physical Structural Map werden die Dateien in Rosetta ohne Hierarchien in der Reihenfolge, in der sie in der Structural Map Section angegeben sind, dargestellt. Die Logical Structural Map hingegen beschreibt die intellektuelle Anordnung der Nutzdateien nach Kapiteln etc. Bei der Logical Structural Map können die Dateien hierarchisch angeordnet sein.

Im unten aufgeführten Beispiel ist eine Logical Structural Map für eine Representation dargestellt, die sich aus zwei Files (FL123 und FL321) zusammensetzt. Die XML-Tags <mets:div LABEL="..."> beinhalten weitere Infos zur Representation wie z. B. den Preservation Type.

Sonderfall Limited METS in Rosetta

Limited METS allgemein

Über die Einlieferung einer Limited METS-Datei haben User die Möglichkeit, einen vergleichsweise unkomplizierten METS-Ingest von IEs mit jeweils nur einer Representation in Rosetta durchzuführen. Ein Limited METS gilt als unvollständig, da es nicht über alle Sektionen eines METS-Files verfügt, kann aber von Rosetta verarbeitet werden. Außerdem enthält eine Limited-METS-Datei ausschließlich Metadaten auf IE-Ebene. Eine Limited METS-Datei kann ohne viel Vorwissen von Usern erstellt werden. Nach erfolgtem Ingest in Rosetta wird das Limited METS automatisch um weitere Angaben zu einer vollständigen und Rosetta-kompatiblen METS-Datei ergänzt.

Im unteren Beispiel ist die Struktur eines Limited METS dargestellt. Es enthält eine Descriptive Metadata Section <mets:dmdSec>, Source Metadata <mets:sourceMD ID="ie-amd-source-dc"> und administrative Metadaten im DNX-Schema in der <mets:techMD ID="ie-amd-tech">.