Ewig Digital Repository Aggregation for Transfer

Living Document,

This version:
https://ewig.zib.de/METS-DRAFT.html
Editor:
(Zuse Institute Berlin (ZIB))

Abstract

Description of a METS specification for Submission Information Packages (SIP) destined for ingest by the EWIG digital preservation system.

1. Anforderungen an einen METS-Container für den Transfer nach EWIG

Dieses Dokument beschreibt die Anforderungen an den METS-Container (Digital Reporository Aggregation For Transfer = DRAFT) als Submission Information Package (SIP) für den Transfer von digitalen oder digitalisierten Objekten (z.B. Dokumente) als intellektuelle Einheiten (IE) aus Digitalisierungsworkflows.

Dieses Dokument ist keine Einführung in METS. Ein Grundverständnis wird vorausgesetzt. Einleitende Dokumente finden Sie hier: METS Homepage insbesondere der METS Primer

Die Vorbereitung eines Objektes zur Langzeitarchivierung soll die langfristige intellektuelle und maschinelle Nachnutzbarkeit sicherstellen. Dies bedeutet, dass das Objekt in der Regel erst im Moment des Zugriffs für einen Nutzer oder Nutzerkreis transformiert werden können muss, da gegenwärtig keine umfassende Einschätzung der zukünftigen Nutzungsszenarien möglich ist. Dies bedingt, dass Informationen semantisch ausgezeichnet und möglichst nicht redundant abgelegt werden, Verarbeitungsschritte aber dokumentiert werden. Beispielsweise ist es nicht notwendig, die Derivate, aus denen die OCR erstellt worden ist aufzuheben, sondern es reicht, die Verarbeitungsvorschriften, mit denen die OCR-Derivate erstellt wurden, zu archivieren.

Ein Transferpaket enthält außer den intellektuellen Einheiten administrative Metadaten (das Submission Manifest) zur Zuordnung des Datengebers (siehe Submission Guidelines).

Ein digitales Objekt in METS besteht mindestens aus

Weitere zwingend einzuhaltende Anforderungen sind zudem:

Die Metadaten verwenden soweit möglich veröffentlichte, nicht-proprietäre Vokabulare.

In diesem Dokument nicht beschriebene Bestandteile einer METS-Datei werden beim Ingest ignoriert, die Original-METS-Datei kann nach Absprache als Dokumentation archiviert werden.

Ziel des METS ist die Möglichkeit, die Vollständigkeit und Integrität von Transfers zu überprüfen, IEs zu identifizieren und die semantisch ausgezeichneten, strukturierten Datenströme mit ihren Metadaten in das EWIG linked data Datenmodell abzubilden.

Beispiel: Buchscan mit OCR vom Beginn des Digitalisierungsvorhabens an

Masterdigitalisate (mit eingebettetem Farbprofil) werden gemäß Digitalisierungs-Richtlinien als Primärdaten erstellt. Alle während des Digitalisierungsworkflows aus einfachen Bildtransformationen entstandenen Derivate werden als funktionale Parameter mit Bezug zu diesem Master dokumentiert. Zugeschnittene Einzelseitenbilder aus einem Doppelseitenscan werden z.B. nur als Bereiche der Masterdateien in der logischen Struktur vermerkt (s.u.). Colourtargets werden aus den Bildern herausgeschnitten und als Dokumentation verknüpft, die Bilder der Targets sind nicht Bestandteil der intellektuellen Einheit, sondern sind eine Art binäres Metadatum. Das Ergebnis einer OCR wird mit Angabe von verwendeten Werkzeugen und Konfidenzen verknüpft, und stellt somit eine valide weitere Repräsentation des Informationsinhalts der intellektuellen Einheit dar. Positionen beziehen sich dabei relativ auf die Zuschnittsbereiche des Masters; zugeschnittene Derivate zur Erstellung der OCR werden nicht mitgeliefert, da diese durch die Aktion Zuschneiden mit den Parametern der Bereiche rekonstruiert werden können. Zugriffsderivate, wie JPGs oder PDFs, werden derart gekennzeichnet und nicht ins erstellte Archiv Informationspaket (AIP) übernommen.

Das konkrete Beispiel beschreibt einen Doppelseitenscan mit OCR (Dateien master.tif und alto.xml).

2. Vorgaben

Die administrativen Metadaten aus dem Submission Manifest können entweder als eigenständige submission-manifest.txt geliefert werden, oder in die METS Datei eingebettet werden. Es wird empfohlen, die Submission Manifest Daten ins METS einzubetten, das als submission-manifest.xml im Wurzelverzeichnis des Transfers abzulegen ist.

2.1. Header (metsRoot/metsHdr)

Im metsHdr/@CREATEDATE sollte das Erzeugungsdatum (ISO 8601) zur Versionierung hinterlegt werden. Wird mets/@OBJID (z.B. für SubmissionName) verwendet, bitte auch @TYPE=" " für ein Transferpaket verwenden. Schemaversion (empfohlen wird \>1.11), mets und xlink Namensräume müssen im mets-Element deklariert werden. Wir empfehlen, andere Metadaten-Namensräume am besten dort zu deklarieren, wo sie benötigt werden (z.B. im mdWrap). Ferner sollte ein mets:agent Element im metsHdr dokumentieren, wer für dessen Erstellung verantwortlich ist (also etwa die Angaben zu TransferCurator und -Email aus dem Submission Manifest, aber auch das erzeugende Software-System):

Beispiel METS-Hdr
    <mets:agent ROLE="CREATOR" TYPE="INDIVIDUAL">      <mets:name>TransferCurator</mets:name>      <mets:note>mailto:TransferCuratorEmail</mets:note>    </mets:agent>

Note: Weitere Agents können enthalten sein.

2.2. Deskriptive Metadaten (dmdSec)

Deskriptive Metadatenabschnitte sind für den Ingest verpflichtend: Einer setzt sich aus den Angaben aus dem sog. Submission Manifest zur Verwaltung und Retrieval zusammen, die einheitlich für ein gesamtes Transferpaket mit potentiell mehreren IEs gelten. Hinzu kommt pro IE mindestens einer zur Beschreibung des Inhalts für ein Discovery.

Die administrative dmdSec wird über die erste Hierarchieebene der submission StructMap structMap[@TYPE="submission"]/div[@type="Transfer"]/@DMDID referenziert und muss einen Dublin Core Terms (dct) Metadatensatz mit folgenden Feldern (aus dem Submission Manifest) enthalten (\[\] schließen einzusetzendes Feld ein):

    <mets:dmdSec ID="dmdSec_1">      <mets:mdWrap MDTYPE="DC" LABEL="EWIG Administrative Metadata">        <mets:xmlData xmlns:dct="http://purl.org/dc/terms/" xsi:schemaLocation="http://purl.org/dc/terms/ http://dublincore.org/schemas/xmls/qdc/2008/02/11/dcterms.xsd">          <dct:conformsTo>http://ewig.zib.de/policies/SubmissionManifest/[SubmissionManifestVersion]</dct:conformsTo>          <dct:publisher>[SubmittingOrganization] <[OrganizationIdentifier]></dct:publisher>          <dct:accrualPolicy>[ContractNumber]</dct:accrualPolicy>          <dct:creator>[Contact], [ContactRole] <[ContactEmail]></dct:creator>          <dct:contributor>[TransferCurator] <[TransferCuratorEmail]></dct:contributor>          <dct:identifier>[SubmissionName]</dct:identifier>          <dct:description>[SubmissionDescription]</dct:description>          <dct:rightsHolder>[RightsHolder]</dct:rightsHolder>          <dct:rights>[Rights]</dct:rights>          <dct:license>[License]</dct:license>          <dct:accessRights>[AccessRights]</dct:accessRights>          <dct:source>[DataSourceSystem]</dct:source>        </mets:xmlData>      </mets:mdWrap>    </mets:dmdSec>

Für jeden Transfer muss der Datengeber einen eindeutigen Namen (den sogenannten SubmissionName) vergeben. Bedeutung und Erläuterungen hierzu wie auch zu allen übrigen Feldern sind in den Submission Guidelines nachzulesen.

Für die EWIG interne Verarbeitung werden die wichtigsten deskriptiven Metadaten, die sich auf eine IE in ihrer Gesamtheit beziehen, auf Dublin Core (DCMI) Metadata Terms abgebildet. Neben Titel (dct:title) und Urheber/Autor (dct:creator) sollte auch eine Datierung mitgeliefert werden. Es wird dringend empfohlen, hierbei die qualifizierten Terme dct:created, dct:modified, dct:issued usw. anstelle von dct:date zu verwenden und nicht zu wiederholen.

    <mets:dmdSec ID="dmdSec_2">      <mets:mdWrap MDTYPE="DC">        <mets:xmlData xmlns:dct="http://purl.org/dc/terms/" xsi:schemaLocation="http://purl.org/dc/terms/ http://dublincore.org/schemas/xmls/qdc/2008/02/11/dcterms.xsd">          <dct:title>...</dct:title>          <dct:creator>...</dct:creator>          <dct:created>...</dct:created>        </mets:xmlData>      </mets:mdWrap>    </mets:dmdSec>

Die jeweilige dmdSec wird auf der zweiten Hierarchieebene per structMap[@type="submission"]/div/div[@TYPE="IntellectualEntity"][@label="_IE-Name_"]/@DMDID referenziert. Weitere deskriptive Metadaten der IE und ihrer Teile können folgen, wobei auch andere Metadatenschemata (MODS, EAD, LIDO ... siehe METS-Schema) verwendet werden können.

Diese Angaben beschreiben bei Digitalisaten das eigentliche Objekt. Angaben zur digitalen Repräsentation müssen in einem weiteren Satz Metadaten beschrieben werden, der mit dct:type <http://www.ics.forth.gr/isl/CRMdig/D1_Digital_Object> ausgezeichnet werden muss.

Verweise auf externe Metadatendateien per mdRef sind zugelassen, müssen dann aber ebenfalls in der fileGrp[@USE="http://ewig.zib.de/ontologies/vocab/use#metadataContainer"] referenziert werden.

Beispiel für verlinkte Metadatendatei
<mets:dmdSec ID="LIDO-fb263974">  <mets:mdRef LOCTYPE="URL" MIMETYPE="text/xml"      MDTYPE="OTHER" OTHERMDTYPE="http://www.lido-schema.org"      XPTR="xpointer(lido:lidoWrap/lido:lido[lido:lidoRecID/text()=DE-MUS-019910/12809])"      xlink:href="broehan_korres.xml"/></mets:dmdSec>

2.3. Administrative Metadaten (amdSec)

Administrative Metadaten sollten als PREMIS in die jeweiligen Sections eingebettet werden. Angaben zum Digitalisierungsworkflow zum Beispiel als digiprovMD.

2.4. Datenstromlisten (fileSec)

Alle mitgelieferten Dateien (Datenströme) müssen jeweils in einer fileGrp aufgeführt sein. Keine Datei darf zweimal referenziert werden. Die fileGrps klassifizieren die referenzierten Dateien zur Erzeugung von Erhaltungskopien oder Zugriffsderivaten. Alle fileGrp/@USE außer " " sind optional. Lesbarkeit bezieht sich auf Bitstream:

fileGrp/@USE Beschreibung Erhaltungsmaßnamen Beispiele
http://pcdm.org/use#OriginalFile Alle primären Datenobjekte einer IE. Diese werden identifiziert, validiert und im AIP gespeichert. Sie dienen bei Existenz oder Erzeugung von Erhaltungskopien durch Normalisierung oder Migration als authentische Datenströme. Lesbarkeit Masterdigitalisate als TIFF, Video in 4:2:2-YUV, .docx, FLAC
http://ewig.zib.de/ontologies/vocab/use#preservationDerivative Preservation-Derivative. Sind entweder gleich den Primärdaten oder werden gegebenenfalls aus diesen erzeugt. Werden vom Ingest erzeugt, nicht vom Datengeber Les- und Benutzbarkeit (maschinell, intellektuell) TIFF, WAV, ODF
http://ewig.zib.de/ontologies/vocab/use#submissionDocumentation Daten, die gegebenenfalls für das intellektuelle Nachvollziehen des Kontextes verwendet werden können. Lesbarkeit Scanprotokolle als Text, Emails, Fotodokumentation, Projektbeschreibungen als Worddatei etc.
http://pcdm.org/use#ServiceFile Primärobjekt-Derivate zur Erzeugung von Zugriffsderivaten. Wird noch nicht verwendet Lesbarkeit composited intermediate-state video with audio, ge-"stichte" Bilder (aus Einzelbildern)
http://ewig.zib.de/ontologies/vocab/use#accessDerivative Zugriffsderivate. Werden nicht ins AIP übernommen Keine PDF, JPEG, MP3
http://ewig.zib.de/ontologies/vocab/use#metadataContainer Metadatendateien, die entweder in dmdSecs lokal referenziert (mit MDREF) werden (können) oder komplexe, technische Metadaten Lesbarkeit lido-19851025.xml, ausgeschnittenes Bild vom Colortarget und zugehöriger Kalibrierungswertemessung (z.B. ASCII IT8)

Weitere Unterteilungen auf Ebene der intellektuellen Einheit sind möglich, also etwa unter fileGrp\[@USE="http://pcdm.org/use\#OriginalFile"\] weitere fileGrps wie folgt:

fileGrp/@USE Beschreibung Beispiele
http://pcdm.org/use#PreservationMasterFile Alle Datenobjekte einer IE, die nicht als alternative Repräsentation in einer der nachfolgenden fileGrps einzuordnen sind. Masterdigitalisate als TIFF, Video in 4:2:2-YUV, .docx, FLAC
http://pcdm.org/use#ExtractedText Maschinell erzeugte Transkription mit Koordinaten (ALTO-XML oder hOCR) als alternative Repräsentation eines Scans aus fileGrp[@USE=".../use#PreservationMasterFile"]. ocr-page1.xml
http://pcdm.org/use#Transcript Manuell erzeugte Transkription und Annotation z.B. in TEI. tei-fulldocument.xml

file/@CHECKSUM und file/@CHECKSUMTYPE müssen vorhanden sein, um die Integrität der Datenlieferung zu überprüfen.

Dateien sind grundsätzlich durch relative URLs (d.h. ohne Scheme-Anteil und ohne führenden /) ausgehend vom Ort der METS-Datei zu referenzieren und als FLocat/@LOCTYPE="URL" auszuzeichnen. Nichtrelative URLs und @LOCTYPE\!="URL" werden nicht unterstützt, da dies dem Prinzip "selfcontained information package" widerspricht. URIs dürfen als IDs oder LABELs verwendet werden, haben aber keine Funktionalität.

Beispiel für eine fileGrp
    <mets:fileSec>     <mets:fileGrp USE="http://pcdm.org/use#OriginalFile">       <mets:file GROUPID="Group-5f92d77e" ID="file-5f92d77e" ADMID="amdSec_3" SIZE="19851025" CHECKSUM="deadbeef" CHECKSUMTYPE="SHA-256">         <mets:FLocat xlink:href="images/master.tif" LOCTYPE="URL"/>       </mets:file>     </mets:fileGrp>     <mets:fileGrp USE="http://pcdm.org/use#ExtractedText">       <mets:file GROUPID="Group-5f92d77e" ID="file-5f92deee" ADMID="amdSec_4" SIZE="51025" CHECKSUM="cafebabe" CHECKSUMTYPE="MD5">         <mets:FLocat xlink:href="ocr/alto.xml" LOCTYPE="URL"/>       </mets:file>     </mets:fileGrp>    </mets:fileSec>

2.5. Strukturmetadaten (structMaps)

Die StructMaps bilden zum Einen die physische Struktur (structMap\[@TYPE="submission"\]) von Dateien in einem hierarchischen Dateisystem bei Ablieferung ab und geben zum Anderen den Daten eine oder mehrere logische Strukturen (structMap/@TYPE). Bei Lieferung mehrerer IEs mit der Beschreibung durch ein METS-Dokument sind die von @TYPE="submission" verschiedenen structMaps jeweils derart einzubetten, dass die structMap einer IE zugewiesen werden kann. Dies muss durch die Verwendung der gleichen DMDID wie in der Submission-structMap im jeweiligen Wurzel-DIV geschehen.

Die access-StructMaps dienen perspektivisch der Erzeugung von Zugriffs- bzw. Anzeigeformaten. In der Langzeitarchivierung ist nicht absehbar, in welcher Form Daten angefragt werden. Eine generische Modellierung erlaubt es, z.B. PDFs, statische Webseiten oder auch IIIF-Manifeste zu erzeugen.

structMap/@TYPE structMap/@LABEL Beschreibung
submission Die Anordnung der enthaltenen Dateien und Verzeichnisse wie im Dateisystem bei Einlieferung.
logical original Es wird keine Struktur angenommen, die Structmap erlaubt aber die Verknüpfung von Metadaten im METS via DMDID.
access Struktur des Objektes für den Zugriff oder zur Anzeige
toc Inhaltsverzeichnis

Es muss genau eine structMap\[@TYPE="submission"\] geben, die sämtliche zum Transfer gehörigen Datenstromreferenzen enthält. Das oberste Abschnittselement repräsentiert den Transfer und referenziert per @DMDID die Metadaten aus dem Submission-Manifest. Die darunterliegende Ebene strukturiert die im Transfer enthaltenen Intelektuellen Einheiten und besteht aus einem oder mehreren div\[@TYPE="IntellectualEntity"\]-Elementen mit Verweisen auf die beschreibenden Metadaten (s.o.). Alle weiteren div-Elemente müssen mit einem @TYPE-Attribut mit dem Wert "Directory" oder "Item" versehen sein. Das Attribut @LABEL enthält den jeweiligen Namen im Dateisystem. Die Belegung der Attribute der div-Elemente ist in folgender Tabelle festgelegt:

div/@TYPE Ebene div/@LABEL div/@DMDID zulässige Kinder
"Transfer" 1 SubmissionName [Submission Manifest] div
"IntellectualEntity" 2 IE-Name [DC Mapping Metadaten] div
"Directory" >=3 Verzeichnisname div
"Item" >=3 Dateiname fptr

Die einzelnen logischen Strukturen haben die folgenden div/@TYPEs (auf den angebenen Hierarchieebenen). Eine Angabe von LABEL (und ggfls. ORDERLABEL) wird zur Anzeige empfohlen. Andere Typisierungen (wie z.B. "Chapter" oder "Section") sind als Zwischenhierarchien möglich.

structmap/@TYPE div/@TYPE Ebene 1 div/@TYPE Ebene >1 Anmerkungen
access physSequence Physische Abfolge der Digitalisate analog zum Original. Wie beim DFG Viewer.
page Physische Seite des Originals. Wie beim DFG Viewer. Ordnung mit @ORDER.
alternativeSequence Alternative Ansichten/Repräsentationen des Objektes.
variant Eine Darstellung des Objektes. Priorisierung mit @ORDER, Beschriftung mit @ORDERLABEL.
layeredSequence Eine Ebenendarstellung des Objektes.
layer Eine Ebene. Z-Index mit @ORDER, Beschriftung mit @ORDERLABEL.
parallelSequence Verschiedene Datenströme, die zusammengenommen eine Präsentation des Objektes ergeben. Z.B. Bildfolgen mit Audiospur
segment Ein Datenstrom mit sinnvollen Angaben wie @BETYPE o.ä. (siehe METS-Schema)

In gewissem Umfang können durch Verschachtelung der access-Sequenzen auch mehrdimensionale Datenobjekte strukturiert werden. Graphen oder Netzwerke hingegen können nicht dargestellt werden. Diese müssen als Datenobjekte übergeben werden (z.B. RDF-Graphen oder HDF5-Datensätze).

Einzelne Seiten oder Ansichten können sich auf Teile von Medien oder XML-Dokumente beziehen und müssen nicht als jeweils eigene Datei referenziert werden.

submission:
    <mets:structMap ID="structMap_1" LABEL="SubmissionName" TYPE="submission">      <mets:div LABEL="[SubmissionName]" TYPE="Transfer" DMDID="dmdSec_1">        <mets:div LABEL="ie3625" TYPE="IntellectualEntity" DMDID="dmdSec_2">          <mets:div LABEL="images" TYPE="Directory">            <mets:div LABEL="master.tif" TYPE="Item">              <mets:fptr FILEID="file-5f92d77e"/>            </mets:div>          </mets:div>          <mets:div LABEL="ocr" TYPE="Directory">            <mets:div LABEL="alto.xml" TYPE="Item">              <mets:fptr FILEID="file-5f92deee"/>            </mets:div>          </mets:div>        </mets:div>      </mets:div>    </mets:structMap>
access/physSequence einer Doppelbuchseite (Scan-Image und OCR):
<mets:structMap ID="structMap_2" LABEL="Buch" TYPE="access">  <mets:div ID="book0000" TYPE="physSequence" DMDID="dmdSec_3">    <mets:div ID="page0001" TYPE="page" ORDER="1" ORDERLABEL="2">       <mets:par>         <mets:fptr>           <mets:area FILEID="file-5f92d77e" SHAPE="RECT" COORDS="100,100,2100,800"/>         </mets:fptr>          <mets:fptr>           <mets:area FILEID="file-5f92deee" BETYPE="IDREF" BEGIN="pageid-1"/>          </mets:fptr>       </mets:par>    </mets:div>    <mets:div ID="page0002" TYPE="page" ORDER="2" ORDERLABEL="3">       <mets:par>         <mets:fptr>           <mets:area FILEID="file-5f92d77e" SHAPE="RECT" COORDS="2300,100,3400,800"/>         </mets:fptr>          <mets:fptr>           <mets:area FILEID="file-5f92deee" BETYPE="IDREF" BEGIN="pageid-2"/>          </mets:fptr>       </mets:par>    </mets:div>  </mets:div></mets:structMap>

Abweichend vom DFG-Viewer-Anwendungs-Profil werden structLinks nicht unterstützt (zum gegenwärtigen Diskussionsstand auch nicht für Hyperlinks xlink:href). Dies ist auch bei anderen Langzeitarchiven wie z.B. der Bibliothèque nationale de France (BnF) oder auch Rosetta für AIPs üblich.

DFG-Viewer-Anwendungsprofil konforme structLinks sind nicht METS-Schema konform und können nicht erfolgreich validiert werden.

Seit dem METS Schema 1.5 (April 2005) wurden die smLink Attribute "to" und "from" von mets:to^^xsd:IDREF in xlink:to^^xsd:string geändert. Die Schemata und der Primer bilden dies richtig ab. Leider kann dies allein durch Schema-Validierung nicht erkannt werden.

Die verwendeten DFG-Viewer-METS-Anwendungsprofile und METS-Schemata beinhalten zwar xlink:to, verwenden sie aber nicht spezifikationsgemäß. In den Anwendungsprofilen ab 2.1 wird dann explizit auf eine METS Schemaversion \> 1.5 verwiesen. Dort verweisen die xlink:Attribute auf ein xlink:label in den structMaps und nicht auf die IDREFS, dies ist konsistent mit XLINK.

DFG-Viewer structlinks könnten durch Einfügen von xlink:labels in den structMaps und Konvertierung der Referenzen in xlink:to und xlink:from leicht Schema-konform transformiert werden, wenn dies gewollt ist.

2.7. Alternative Lieferung mehrerer IEs als einzelne METS-Dokumente

Sollen mehrere IE in einem Transfer zusammengefasst werden, so ist jede IE in einem eigenen METS-Dokument zu beschreiben. submission-manifest.xml ist ein rudimentäres METS, welches den Transfer beschreibt, und hat folgende Form: