Ewig Digital Repository Aggregation for Transfer

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

• deskriptiven Metadaten bezogen auf die gesamte IE für die Auffindbarkeit,

• Provenienz-Angaben (abliefernde Institution, aber auch verwendete Software),

• digitalen Inhalten (Bilder, Texte, etc.; nicht per FContent im METS eingebettet),

• relativen Referenzen auf die Datenströme der digitalen Inhalte sowie

• zumindest einer Struktur (structMap) aus den im Objekt enthaltenen Bestandteilen mit Verknüpfungen zu deskriptiven und administrativen Metadaten.

Weitere zwingend einzuhaltende Anforderungen sind zudem:

• jeder Datenstrom, der im METS in der File Section referenziert wird, ist mit Checksummen ausgestattet und der relative Pfad zur Datei ist gültig,

• es existieren keine nicht-referenzierten Dateien im Transfer (außer der METS-Datei und gegebenenfalls einer Textdatei submission-manifest.txt gemäß Submission Guidelines),

• es existieren keine Referenzen zu externen Datenströmen,

• alle intra-METS-Referenzen sind auflösbar.

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.

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):

    <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.

<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:

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

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.

    <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.

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:

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.

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.

    <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>

<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>

2.6. Links

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:

• Für das Wurzelelement gilt: mets/@TYPE=" ".

• Es gibt genau eine dmdSec mit den Daten des SubmissionManifests.

• Es gibt genau eine structMap mit @TYPE="transfer".

• Pro IE gibt es genau ein div-Element (auf der zweiten Ebene unter structMap) mit @TYPE="IntellectualEntity", @LABEL=" " und child::mptr/@xlink:href=" ".