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