Dieses METS Profil beschreibt das Datenformat f��r den DFG-Viewer und definiert dar��ber hinausgehende Erweiterungen f��r das zvdd-Portal. Dokumente, die diesem Profil entsprechen, k��nnen sowohl durch den DFG-Viewer angezeigt als auch durch das zvdd-Portal verarbeitet und indexiert werden. Zu beachten ist, dass s��mtliche enthaltene Beispiele das jeweilige METS-Dokument nur auschnittsweise wiedergeben. Einige komplette Beispiele finden sich in der XML-Version des Profils am Ende des Abschnitts <Appendix>.
./zvdd-dfgviewer-mets-profil-v2.xml
2008-11-14T12:00:00
Stefan E. Funk
Nieders��chsische Staats- und
Universit��tsbibliothek
Papendiek 14
Dieses Profil ist eigenst��ndig; keine anderen METS-Profile sind mit diesem Profil verkn��pft.
Metadata Object and Description Schema (MODS)
http://www.loc.gov/standards/mods/
ISO 639-2
International Standard Organization
http://www.iso.ch/
S��mtliche Sprachangaben innerhalb des MODS-Extension Schemas erfolgen gem���� ISO 639-2
Sprachcodes. Dies betrifft das Element <mods:languageTerm>.
zvdd Strukturdatentypologie
zvdd - Zentrales Verzeichnis Digitalisierter
Drucke
http://zvdd.gdz-cms.de/dokumentation/datenformate_im_ueberblick/strukturdaten/
F��r zvdd verf��gen s��mtliche <div> ��ber ein TYPE Attribut, dessen Wert der
Strukturdatentypologie entsprechen muss.
zvdd MODS Anwendungsprofil
zvdd - Zentrales Verzeichnis Digitalisierter
Drucke
http://+++ link fehlt noch +++
Das zvdd MODS Anwendungsprofil muss mit
dem zvdd/DFG-Viewer METS Profil verwendet werden.
Jedes Strukturelement (das hei��t jedes <div>) kann eine oder mehrere deskriptive Metadatensektionen <dmdSec> besitzen. Der Typ einer Metadatensektion muss im MDTYPE Attribut eines jeden <mdRef> oder <mdWrap> Elements angegeben sein. Sowohl der DFG-Viewer als auch das zvdd-Portal unterst��tzten lediglich deskriptive Metadatensektionen vom Typ MODS. Diese m��ssen in das METS Dokument eingebunden sein und sich innerhalb von <mdWrap> befinden. Ferner wird lediglich die erste Metadatensektion des Typs ber��cksichtigt. Sollten also mehrere MODS Sektionen existieren, wird lediglich die Sektion ber��cksichtigt, dessen Identifier an erster Stelle im entsprechenden DMDID Attribut des <div> Elements steht.
Das oberste <div> Element aus der logischen <structMap> muss einen entsprechenden MODS Metadatensatz besitzen, da dieser unter anderem Informationen zur eindeutigen Identifizierung und Indexierung der Resource sowie zur Anzeige in entsprechenden Page-Turnern ��� wie dem DFG-Viewer ��� enth��lt. Handelt es sich beim obersten Element um ein <div> eines ��bergeordnetes Werkes (beispielsweise eine Zeitschrift), das keinen MODS Metadatensatz referenziert, muss das Kind-Element einen solchen besitzen.
Weitere Metadatensektionen k��nnen vorhanden sein, um bspw. weitere Metadatenformate wie DublinCore aufzunehmen oder aber mittels <mdRef> auf den entsprechenden Metadatensatz im lokalen OPAC zu verweisen. Sowohl der DFG-Viewer als auch das zvdd-Portal ignorieren entsprechende Sektionen.
MODS Metadaten k��nnen aufgrund ihres Detailierungsgrades f��r die Indexierung eines Dokuments ��� konkret eines jeden <div> Elements ��� genutzt werden. Dies entspricht im wesentlichen der Verwendung durch das zvdd-Portal.
Die MODS Metadaten des obersten <div> Elements (bzw. die des ersten Kind-Elements) werden durch den DFG-Viewer zur Anzeige der bibliographischen Daten genutzt. Informationen ��ber die MODS Felder, deren Nutzung und deren Vorhandensein (Pflichtfelder, optionale Felder) finden sich im separaten MODS Profil.
Jedes Dokument bzw. jede Dokumentstruktur wird mittels des Wertes, welches im <mods:identifier> Element gespeichert wird, eindeutig identifiziert. Es k��nnen beliebige, unterschiedliche Identifier f��r ein <div> Element vorhanden sein. So k��nnen neben lokalen bibliotheksinternen Identifiern auch allgemein gebr��uchliche Identifier wie bspw. die ISBN in diesem Feld gespeichert werden. F��r das oberste <div>-Element (bzw. f��r dessen erstes Kind-Element) in der logischen <structMap> ist das Vorhandensein eines entsprechenden Identifiers Pflicht.
zvdd fordert an dieser Stelle einen weltweit eindeutigen Identifier wie z.B. URN, PURL, DOI, Handle oder ARK. F��r den Kontext der digitalen Bibliothek hat die URN in den vergangenen Jahren an Bedeutung gewonnen. Daher wird die URN als persistenter Identifier vom zvdd-Portal empfohlen.
Der DFG-Viewer ben��tigt f��r die Anzeige eines Werkes keine solche URN. Es wird trotzdem empfohlen eine solche URN in den MODS Metadaten zu speichern, da anhand eines solches Identifier weitere Services denkbar sind, die mittels der URN angesprochen werden k��nnen. Sie k��nnte bspw. zur Verkn��pfung zwischen DFG-Viewer und dem zvdd-Portal dienen.
Aufgrund der Eindeutigkeit kann die URN auch als Identifier f��r das OAI-PMH genutzt werden. Das hei��t der am zvdd-Portal aufgesetzte OAI-Harvester bedient sich der URN, um die entsprechenden OAI-Records eindeutig zu identifizieren. Dabei wird jedes <div> Element, welche eine URN besitzt als eigenst��ndiger OAI-Record betrachtet.
Neben der g��ngigen METS-internen M��glichkeit, Teile von Dokumenten hierarchisch miteinander zu verkn��pfen (siehe Erl��uterungen zur optionalen logischen Dokumentstruktur), existieren auch hierarchische Verkn��pfungen zwischen Dokumenten. Ein Beispiel f��r eine solche Verkn��pfung ist die Beziehung zwischen einem Mehrb��ndigen Werk und seinen einzelnen ihm untergeordneten B��nden. ��blicherweise werden s��mtliche B��nde eigenst��ndig digitalisiert, so dass f��r jeden der B��nde eine eigene METS-Datei generiert wird. Um die B��nde zu gruppieren und deren Zusammengeh��rigkeit abzubilden, wird f��r das Mehrb��ndige Werk eine separate METS-Datei erzeugt. Diese enth��lt keine Verweise auf Image-Dateien, sondern nur auf die untergeordneten B��nde. Diese hierarchische Verkn��pfung gilt analog f��r alle anderen <div> Elemente, die auf ein ��bergeordnetes Element verweisen ��� also bspw. auch f��r eine Verkn��pfung zwischen Zeitschriftenband und Zeitschrift.
In zvdd wird eine solche Verkn��pfung in MODS abgelegt. Das <relatedItem> Element vom Typ "host" speichert einen Verweis auf das ��bergeordnete Werk. Dazu enth��lt es ein Unterelement vom Typ <mods:recordInfo><mods:recordIdentifier>, das einen zur Laufzeit innerhalb des liefernden Repositories g��ltigen Identifier enth��lt. Persistenz wird nicht gefordert. Hierbei ist zu beachten, dass eine solche Verkn��pfung an dieser Stelle grunds��tzlich immer nur auf die ��bergeordnete Einheit erfolgt.
Der DFG-Viewer nutzt f��r die Navigation durch hierarchische Strukturen jedoch METS-Pointer <mptr>, die jeweils direkt auf ��ber- und auch auf untergeordnete METS-Dateien verweisen, so kann in beide Richtungen navigiert werden. Beispielsweise kann von einem Zeitschriften-Element auf alle B��nde verwiesen werden und von den einzelnen B��nden zum ��bergeordneten Zeitschriften-Element (siehe structMap Anforderung: Behandlung von Zeitschriften und Mehrb��ndigen Werken).
Innerhalb eines METS Dokuments wird die Reihenfolge der <div> Elemente durch deren Anordnung in der logischen <structMap> bestimmt. Im Fall einer Verkn��pfung mittels <relatedItem> muss die entsprechende Information jedoch an anderer Stelle im MODS Datensatz abgespeichert werden, da f��r diese Ebene keine verschachtelten <div> Elemente existieren. Vielmehr sind die einzelnen <div> Elemente in unterschiedlichen METS-Dokumenten abgelegt.
Unter MODS dient das <mods:part> Element dazu, konkrete Informationen ��ber einen einzelnen Teil und dessen Zugeh��rigkeit zu einer gr����eren Gesamtheit zu speichern. In einer METS-Datei f��r einen Band sollte an dieser Stelle die Bandnummer sowohl f��r die Anzeige als auch f��r die Sortierung des Inhaltsverzeichnisses gespeichert werden. Diese Informationen werden sowohl durch den DFG-Viewer (Anzeige von Bandnummer als bibliographische Information) als auch durch das zvdd-Portal (Sortierung des Inhaltsverzeichnis des Mehrb��ndigen Werks) genutzt.
Das <mods:part> Element muss ��ber ein ORDER Attribut verf��gen, das die Reihenfolge des jeweiligen <div>s innerhalb der ��bergeordneten Einheit angibt. Der Wert dieses Elements muss ganzzahlig sein. Informationen zur Anzeige der Bandnummer werden innerhalb des <part> Elements unter <detail><number> gespeichert. Das <number> Element enth��lt s��mtliche Informationen als Text, das hei��t <number> darf bspw. Zahlenw��rter oder sonstige beliebige Angaben zur Nummerierung enthalten.
Das <mods:detail> Element muss ��ber ein TYPE Attribut verf��gen, das f��r zvdd einem Typ der zvdd Strukturdatentypologie entsprechen muss. F��r den DFG-Viewer sollte es einem der in der MODS Dokumentation der Library of Congress vorgeschlagenen Typen entsprechen: volume, part, issue, chapter, section, paragraph oder track.
Innerhalb des <part> Elements m��ssen immer beide Felder (ORDER Attribut und <number> Element) vorhanden sein. Sollte die Information zur Anzeige identisch mit denen zur Sortierung sein, m��ssen entsprechende Informationen dupliziert und in beiden Feldern angegeben werden.
Um im zvdd-Portal sowie bei der Anzeige durch den DFG-Viewer den Rechteinhaber bzw. den Urheber eines Digitalisats zu erw��hnen, muss diese Information innerhalb eines <rightsMD> Element gespeichert werden. Innerhalb dieses Elements kommt ein eigenes Schema zur Anwendung, welches weiter unten erl��utert wird.
Da entsprechende Urheber-/Rechteinfromationen in aller Regel f��r eine komplette Resource gelten, kann die entsprechende <amdSec> nur von dem obersten logischen <div> Element (oder von dessen ersten Kind-Element) einer METS-Datei verkn��pft werden. Das <admSec> Element muss daher also ��ber ein Attribut ID verf��gen. Das <rightMD> muss gem���� METS-Spezifikation zwar vorhanden sein, wird jedoch nicht aus dem ADMID Attribut des <div> Elements heraus verlinkt.
Die entsprechenden Rechte-Metadaten m��ssen innerhalb des <mdWrap> Elements gepeichert sein. Eine Referenzierung der Metadaten ist nicht zul��ssig. Das MDTYPE Attribut des <mdWrap> Elements muss den Wert "OTHER" besitzen. Dieser Typ wird im OTHERMDTYPE Attribut konkret spezifiziert. Dieses muss den Wert "DVRIGHTS" besitzen.
Innerhalb des <mdWrap> Elements kommt ein eigenes Rechte-Schema zur Anwendung, welches seinen Inhalt in ein umschlie��endes <dv:rights> Element schreibt. Innerhalb dieses Elements gibt es folgende drei Unterelemente, die jeweils nur genau einmal vorkommen d��rfen und m��ssen.
owner ��� Der Urheber des Digitalisats
logo ��� Eine URL des Logos des Urhebers; dieses Logo wird durch den DFG-Viewer sowie das zvdd-Portal entsprechend angezeigt.
homepage ��� Eine URL der Homepage des Urhebers.
Weitere Rechteinformationen k��nnen in separaten <rightsMD> Elementen innerhalb derselben Administrativen Metadatensektion abgelegt werden. Diese m��ssen jedoch andere Rights-Schemata verwenden und diese in den Attributen MDTYPE und OTHERMDTYPE des <mdWrap> Elements dokumentieren.
Informationen zu Herkunft und Pr��sentation eines Digitalisats werden innerhalb eines <digiprovMD> Elements in der <amdSec> gespeichert.
Analog zu den Metadaten zu Rechteinhaber und Urheber m��ssen die entsprechenden Herkunfts-Metadaten innerhalb des <mdWrap> Elements gepeichert sein. Eine Referenzierung der Metadaten ist ebenfalls nicht zul��ssig. Das MDTYPE Attribut des <mdWrap> Elements muss den Wert "OTHER" besitzen. Dieser Typ wird im OTHERMDTYPE Attribut konkret spezifiziert. Dieses muss hier den Wert "DVLINKS" besitzen.
Innerhalb des <mdWrap> Elements kommt ein eigenes Herkunfts-Schema zur Anwendung, welches seinen Inhalt in ein umschlie��endes <dv:links> Element schreibt. Innerhalb dieses Elements gibt es folgende zwei Unterelemente, die jeweils nur genau einmal vorkommen d��rfen und m��ssen.
reference ��� Eine URL auf den Katalogeintrag des Digitaslisats
presentation ��� Eine URL auf die Online-Pr��sentation des Digitalisats.
Weitere Herkunftsinformationen k��nnen in separaten <digiprovMD> Elementen innerhalb derselben Administrativen Metadatensektion abgelegt werden. Diese m��ssen jedoch andere Links-Schemata verwenden und diese in den Attributen MDTYPE und OTHERMDTYPE des <mdWrap> Elements dokumentieren.
In der File-Section <fileSec> sind alle Inhaltsdateien aufgef��hrt, aus dem das Dokument besteht. Inhaltsdateien sind Dateien, die den semantischen Inhalt der Resource enthalten. Dateien, die bspw. Metadaten zu diesem Dokument enthalten, werden nicht aus der File-Sektion heraus verlinkt.
Die Dateien selber k��nnen in unterschiedliche Gruppen gegliedert sein. Jede Gruppe beinhaltet Dateien ��hnlichen Typs zu ��hnlichen Verwendungszwecken. In einem METS-Dokument muss mindestens eine Gruppe existieren. Die Anzahl der Gruppen ist nicht beschr��nkt. F��r die Nutzung der METS-Datei im DFG-Viewer sind jedoch mindestens zwei der unten stehenden Dateigruppen zu implementieren.
Jede FileGroup wird durch ein <fileGrp> Element deklariert und ist direkt dem <fileSec> Element untergeordnet. Untergruppen sind nicht m��glich, das hei��t ein <fileGrp> Element darf keine weiteren <fileGrp> Elemente enthalten.
Existieren mehrere FileGroups, so ist jedes <fileGrp> Element mit einem Attribut USE zu versehen, das Informationen ��ber die Verwendung enth��lt.
Jede Datei wird durch ein <file> Element deklariert. Dieses <file> Element ist Kind-Element eines <fileGrp> Elements, das hei��t jede Datei muss zu genau einer Gruppe geh��ren. Die Zugeh��rigkeit einer Datei zu mehreren Gruppen ist nicht m��glich.
Der eigentliche Inhalt der Datei (der Bytestream) wird au��erhalb des METS-Dokumentes gespeichert, jedoch so persistent mit der METS-Datei mittels <FLocat> verkn��pft, dass der DFG-Viewer die Datei bei Bedarf aus dem urspr��nglichen Repository laden und anzeigen kann. Dazu muss das <file> Element als einziges Kind-Element ein <FLocat> Element enthalten, welches mittels einer URL, die in dem Attribut xlink:href gespeichert ist, referenziert wird. Das Attribut LOCTYPE muss daher den Wert "URL" besitzen. F��r die G��ltigkeit der in der METS-Datei enthaltenen URL ist das Repository verantwortlich, welche die METS-Datei produziert und in Umlauf gebracht hat. In die METS-Datei eingebetteter Content unter Verwendung des <FContent> Elements wird nicht unterst��tzt.
Jedes <file> Element enth��lt ein Attribut ID, welches als eindeutiger Verweis innerhalb des METS-Dokumentes dient. Diese IDs werden von den <fptr> Elementen in <structMap> referenziert und weisen den <div> Elementen das entsprechende <file> Element zu.
Jedes <file> muss ein MIMETYPE Attribut beinhalten, welches den Mime-Type der Inhaltsdatei enth��lt. Als weitere technische Metadaten sollten CHECKSUM, CHECKSUMTYPE und SIZE vorhanden sein. Sie beinhalten einen Hashwert des Content-Files bzw. entsprechende Informationen zu dem verwendeten Algorithmus sowie die L��nge der Datei in Bytes. Diese Informationen sind vor allem f��r den DFG-Viewer hilfreich, um die Authentizit��t der gelieferten Contentdateien vor der Anzeige zu beurteilen.
Derzeit werden keine technischen Metadaten f��r einzelne Dateien unterst��tzt. Sollten dies gew��nscht sein, k��nnen sie in einer separaten administrativen Metadatensektion (admSec) abgespeichert werden und mittels des ADMID Attributs des <file> Elements verkn��pft werden. Die Verwendung von technischen Metadaten ist also optional.
Die Verwendung unterschiedlicher Dateigruppen hat den Zweck, Dateien mit ��hnlichen Merkmalen unter dem Aspekt identischer Nutzung zusammenzufassen. Auf den DFG-Viewer ��bertragen bedeutet dies, dass Imagedaten mit identischer Imagebreite zu einer Gruppe zusammengefasst werden. Hierbei ist zu beachten, dass alle Dateien dieser Gruppen Derivate der Originaldateien sind, die zur Anzeige in verschiedenen Gr����en berechnet wurden. Daher muss eine Dateigruppe auch immer ein komplettes Set an Imagedaten enthalten ��� f��r jede Seite muss in jeder Dateigruppe genau ein Image existieren.
Der DFG-Viewer kann diese unterschiedlichen Derivate entsprechend ihrer Imagebreite ordnen. Entsprechend der vorhandenen Imagebreiten stellt der DFG-Viewer die Images in unterschiedlichen Zoomstufen dar. Zu diesem Zweck gibt das Attribut USE des <fileGrp> Elements die Pixelbreite der enthaltenen Images an. Die m��glichen Werte des USE Attributs sind f��r den DFG-Viewer standarisiert. Dateigruppen mit abweichenden Werten werden vom DFG-Viewer ignoriert und k��nnen so bspw. Verweise auf Volltextdaten oder lokale Dateien enthalten. Die m��glichen Werte f��r den DFG-Viewer sind:
DEFAULT ��� enth��lt Imagedateien mit einer Breite zwischen 1000 und 1500 Pixel. Dies ist die Bildgr����e, die beim ersten Aufruf des Dokumentes im DFG-Viewer angezeigt wird.
MIN ��� enth��lt Imagedateien mit einer Breite zwischen 600 und 1000 Pixel. Diese Bildgr����e wird angezeigt, wenn im DFG-Viewer aus dem Dokument herausgezoomt wird.
MAX ��� enth��lt Imagedateien der gr����tm��glichen online verf��gbaren Aufl��sung. Diese Bildgr����e wird angezeigt, wenn im DFG-Viewer in das Dokument hineingezoomt wird.
THUMBS ��� enth��lt alle Seiten als kleines ��bersichtsbild mit genau 150 Pixel Breite oder 150 Pixel H��he. Bei Hochkant-Bildern ist also die H��he auf 150 Pixel beschr��nkt, bei Querformat-Bildern dagegen die Breite. Die jeweils andere Gr����e sollte so gew��hlt werden, dass die Proportionen erhalten bleiben. Das Bildformat f��r die Thumbnails muss entweder PNG oder JPG sein. Daraus wird der DFG-Viewer zuk��nftig eine ��bersicht aller Seiten erstellen. Daher ist es wichtig, dass diese <fileGrp> ein entsprechendes verkleinertes Derivat eines jeden Seitenimages enth��lt.
DOWNLOAD ��� enth��lt Dateien, die f��r den Download vorgesehen sind. Zu beachten ist hier die korrekte Angabe des entsprechenden MIMETYPE Attributs der <file> Elemente, bei einer PDF-Datei muss beispielsweise der Wert "application/pdf" angegeben sein. Die einzelnen Dateien k��nnen sowohl physischen wie auch logischen Strukturelementen zugeordnet werden. Der DFG-Viewer verarbeitet bislang nur Verweise aus der physischen <structMap>, m��glich sind dann Downloads von Einzelseiten wie ein Download des gesamten Werkes. Eine Zuordnung zu logischen Strukturelementen zur Verlinkung von Kapiteln oder Heften ist ebenfalls m��glich.
Es m��ssen mindestens die entsprechenden FileGroups f��r die Aufl��sungen "MIN" und "DEFAULT" in der METS-Datei enthalten sein, alle weiteren File-Groups sind optional.
Wird ein Dokument gem���� des Bibliographischen Dokumentenmodells erfasst, existiert lediglich eine logische <structMap>. Daher muss das TYPE Attribut des einzigen <structMap> Elements den Wert "LOGICAL" besitzen. Die logische <structMap> enth��lt bei Monographien lediglich ein einziges <div> Element, welches das jeweilige Werk repr��sentiert. In diesem Modell existieren keinerlei <div> Elemente als Kind-Elemente.
Demzufolge ist dem <div> mindestens ein MODS Metadatensatz zugeordnet. Entsprechend hat das DMDID Attribut des <div> Elements einen Eintrag. Das TYPE Attribut muss einen Wert aus der zvdd-Strukturdatentypologie enthalten.
Da keine entsprechenden Seiten definiert sind, ist dieses Modell f��r den DFG-Viewer NICHT geeignet. Es existiert lediglich als notd��rftige L��sung f��r das zvdd-Portal, um Dokumente, die lediglich als PDF vorliegen und zu denen rudiment��re Metadaten existieren, in das Portal aufnehmen und dort indexieren zu k��nnen.
Das Seitenbasierte Dokumentmodell ist das Minimalmodell, welches vom DFG-Viewer unterst��zt wird. Es definiert einzelne Seiten, die durch den DFG-Viewer angezeigt werden k��nnen. Zu jeder dieser Seiten m��ssen mindestens zwei entsprechende Dateiverweise existieren (einer in die FileGroup "DEFAULT" und einer in die FileGroup "MIN").
Das Seitenbasierte Dokumentenmodell zeichnet sich durch zwei <structMap> Elemente aus. Ein <structMap> Element enth��lt die logische Struktur, dessen TYPE Attribut besitzt den Werk "LOGICAL". Das andere <structMap> Element enth��lt die physische Struktur, das TYPE Attribut hat den Wert "PHYSICAL". Weitere <structMap> Elemente d��rfen nicht existieren. Die <structLink> Sektion muss in diesem Modell vorhanden sein und entsprechende logische und physische Strukturen verkn��pfen. Dabei muss jedes <div> Element aus der physischen Struktur mindestens einem <div> Element aus der logischen Struktur direkt oder indirekt zugeordnet sein. Als Ausnahme gilt lediglich das erste logische <div> Element eines Mehrb��ndigen Werkes oder einer Zeitschrift, da dieses das ��bergeordnete Werk bezeichnet und kein physisches Strukturelement daf��r existiert. Weitere Informationen zur Verkn��pfung der logischen und physischen Struktur sind dem <structLink> Abschnitt zu entnehmen.
Innerhalb des physischen <structMap> Elements wird die Seitenstruktur durch <div> Elemente wiedergegeben, die einem obersten <div> Element untergeordnet sind. Das oberste <div> Elemente repr��sentiert die gebundene Einheit. Daher muss dessen TYPE Attribut immer den Wert "physSequence" besitzen.
Die darunterliegenden Strukturelemente repr��sentieren die Seiten bzw. den Einband. Einband und Seiten werden auf derselben hierarchischen Ebene angesiedelt. Im Fall einer Seiten-Repr��sentation enth��lt das jeweilige <div> Element den Wert "page" im TYPE Attribut. Eine weitere Verschachtelung bspw. zum Abbilden von Seitenbereichen wie Spalten etc. ist ebenfalls denkbar und k��nnen als den Seiten untergeordnete <div> Elemente implementiert werden. Der DFG-Viewer ber��cksichtigt entsprechende <div> Elemente unterhalb der Seitenebene jedoch nicht.
Jedes <div> Element innerhalb der physischen Struktur muss ��ber ein ID Attribut verf��gen, welches einen eindeutigen Wert besitzt. Die Eindeutigkeit dieses Wertes gilt f��r das komplette METS-Dokument.
Obwohl es auf Seitenebene sinnvoll erscheint, die <div> Elemente in derselben Reihenfolge anzuordnen, wie die Seiten innerhalb der gebundenen Einheit angeordnet sind, muss diese Reihenfolge im ORDER Attribut eines jeden <div> Elements auf Seitenebene explizit angegeben werden. Das ORDER Attribut darf lediglich einen ganzzahligen Wert (Integer) enthalten, der auf Ebene der Seiten eindeutig sein muss. F��r die Reihenfolge der Seiten sind einzig die Werte der ORDER Attribute ausschlaggebend; die Reihenfolge der <div> Elemente bleibt unber��cksichtigt. F��r den Seiten untergeordnete Strukturelemente wird die Verwendung des ORDER Attributs ebenfalls empfohlen.
Besitzt eine Seite eine aufgedruckte Seitenzahl, so ist diese in Vorlagenform im ORDERLABEL Attribut des <div> Elements zu speichern. Seiten, die nicht in der Paginierung ber��cksichtigt sind (ungez��hlte Seiten) ben��tigen kein ORDERLABEL Attribut. Das Ausf��llen des LABEL Attributs ist optional m��glich. Der DFG-Viewer benutzt den Wert des ORDERLABEL Attributs zur Anzeige und Navigation (gezieltes Anspringen von Seiten), wenn das Attribt vorhanden ist.
Das Attribut CONTENTIDS gibt einen (oder mehrere) persistente Identifier f��r jede einzelnen Seite des Dokuments an und besteht aus einer URI oder einer Liste von URIs. Diese werden vom DFG-Viewer als persistente IDs f��r die jeweilige Seite angezeigt und k��nnen als dauerhafter Link f��r Zitationen direkt auf die entsprechende Seite genutzt werden.
Mit Hilfe des File-Pointers <fptr> k��nnen Dateien f��r den Download referenziert werden. In der physischen StructMap ist dies f��r einzelne Seiten und f��r das Gesamtdokument m��glich, siehe auch Beispiel 14 (Verweise auf Dateien aus der physischen Struktur).
Das Komplexe Dokumentenmodell erweitert das Seitenbasierte Modell um weitere Strukturinformationen auf logischer Ebene. F��r die physische Struktur (<structMap TYPE="PHYSICAL">) gilt im Komplexen Dokumentenmodell all jenes, was bereits oben f��r das Seitenbasierte Modell beschrieben wurde.
Der DFG-Viewer nutzt die zus��tzlichen Strukturinformationen, um das Inhaltsverzeichnis zu erstellen und erm��glicht eine Navigation in der Struktur. Das zvdd-Portal verarbeitet die logischen Strukturdaten und nutzt sie zur Indizierung und zur Suche.
Die oberste logische Struktureinheit ist das bereits im Bibliographischen Dokumentenmodell erw��hnte <div> Element, welches die bibliographische Einheit repr��sentiert. Diesem <div> werden weitere <div> Elemente untergeordnet, so dass sich durch die verschachtelten Elemente die logische Struktur des Dokumentes abbildet. Die Tiefe der Verschachtelung ist nicht beschr��nkt. In der logischen Struktur gibt die Reihenfolge der <div> Elemente die tats��chliche Reihenfolge der zu repr��sentierenden Strukturen wieder. Es ist nicht notwendig, das ORDER oder ORDERLABEL Attribut zu benutzen; deren Werte werden im Kontext des DFG-Viewers sowie des zvdd-Portals ignoriert.
Jedes <div> Element innerhalb der logischen Struktur muss ebenfalls ��ber ein ID Attribut verf��gen, welches einen eindeutigen Wert besitzt. Die Eindeutigkeit dieses Wertes gilt f��r das komplette METS-Dokument.
Jedes <div> Element innerhalb der logischen Struktur muss ��ber ein TYPE Attribut verf��gen, das f��r zvdd einem Typ der zvdd Strukturdatentypologie entsprechen muss. F��r den DFG-Viewer sollte es einem der in der MODS Dokumentation der Library of Congress vorgeschlagenen Typen entsprechen: volume, part, issue, chapter, section, paragraph oder track.
Mit dem Attribut CONTENTIDS k��nnen auch in diesem Modell persistente Identifier f��r alle logischen Elemente angegeben werden, beispielsweise f��r die gesamte Monographie oder f��r einzelne Kapitel. Diese werden ebenfalls vom DFG-Viewer als persistente IDs f��r Zitationen angezeigt.
Zus��tzlich zu den Download-Referenzen in der physischen StructMap k��nnen auch in der logischen StructMap Dateien per <fptr> referenziert werden, beispielsweise PDF-Dateien von Artikeln oder Kapiteln. Der DFG-Viewer wertet diese Referenzen zur Zeit nicht aus, siehe auch Beispiel 15 (Verweise auf Dateien aus der logischen Struktur).
Band��bergreifende Navigation im DFG-Viewer wird erm��glicht, indem die B��nde und ihre ��bergeordnete Struktur mittels METS-Pointern untereinander verkn��pft werden. Dies geschieht ��ber eine weitere METS-Datei, die nur die Zeitschrift oder das Mehrb��ndgie Werk beschreibt. Hier sind nur die Metadaten der Zeitschrift sowie eine logische <structMap> enthalten, in der alle <div> Elemente der B��nde verzeichnet sind. Die Reihenfolge der <div> Elemente entspricht der Reihenfolge der B��nde. Es sind keine Inhaltsdateien von dieser Datei aus verlinkt.
Die Verkn��pfung zwischen den METS-Dateien der Zeitschrift und den METS-Dateien der B��nde erfolgt mittels METS-Pointer Elementen <mptr>, die den einzelnen <div> Elementen untergeordnet sind. Aus der METS-Datei des Bandes weist ein METS-Pointer auf die METS-Datei der Zeitschrift und von der METS-Datei der Zeitschrift weist jeweils ein METS-Pointer auf die zugeh��rige METS-Datei eines jeden Bandes.
Grunds��tzlich k��nnen jedem <div> Element ein oder mehrere Metadatensektionen zugeordnet werden. Dies ist unabh��ngig davon, ob sich das Element in einer logischen oder einer physischen Struktur befindet. Sowohl das zvdd-Portal als auch der DFG-Viewer nutzen allerdings lediglich deskriptive Metadaten gem���� der in der Sektion "Deskriptive Metadaten" genannten Bedingungen (siehe MODS-Metadatenschema), die von der logischen <structMap> aus referenziert werden. Andere Metadatensektionen werden ignoriert.
Um von einem <div> Element auf zugeh��rige Dateien zu verweisen, wird das FilePointer Element <fptr> benutzt. Dieses Element ist daher immer Kind-Element des <div> Elements, f��r welches es die Dateien verlinkt. Jedes <div> Element kann einen oder mehrere FilePointer besitzen.
Ein FilePointer verweist immer auf eine Datei, die in der File-Sektion an beliebiger Stelle aufgef��hrt ist; das hei��t, die Dateien k��nnen in verschiedenen FileGroups enthalten sein. Die Verkn��pfung erfolgt ��ber das FILEID Attribut. Jedes <fptr> Element muss ein FILEID Attribut besitzen.
Dateien, die lediglich den Inhalt einer Seite wiedergeben (bspw. Seiten), werden nur aus der physischen Dokumentenstruktur heraus verlinkt ��� konkret: nur aus den <div> Elementen heraus, die die jeweilige Seite repr��sentieren. Durch die hierarchische Struktur wird eine Verkn��pfung der den Seiten zugeordneten Dateien (Seitenimages) zur gebundenen Einheit implizit ausgedr��ckt. Den unterliegenden Strukturen (bspw. Seiten) zugeordneten Dateien d��rfen den ��berliegenden Strukturen nicht explizit ein weiteres Mal zugeordnet werden.
Generell d��rfen nur <file> Elemente verlinkt werden, Verkn��pfungen zu <fileGrp> Elemente sind unzul��ssig. Damit der DFG-Viewer entsprechende Seiten anzeigen kann, m��ssen zu jedem <div> vom Typ "page" mindestens zwei Verkn��pfungen vorhanden sein. Eine Verkn��pfung muss jeweils auf je eine Datei aus den beiden Pflichtdateigruppen "DEFAULT" und "MIN" erfolgen. Wenn weitere File-Groups vorhanden sind, werden auch diese hier verlinkt.
Ebenso wie aus der physischen Struktur k��nnen Verkn��pfungen auf Dateien aus der logischen Struktur heraus gesetzt werden. Eine aus der logischen Struktur heraus verkn��pfte Datei muss jedoch den kompletten Inhalt der entsprechenden logischen Dokumentstruktur enthalten. Beispiel f��r eine solche Verkn��pfung k��nnte bspw. der Link auf eine PDF-Datei sein, die eine komplette Monographie oder ein einzelnes Kapitel derselben enth��lt. Es ist nicht erlaubt, Verweise auf mehrere Dateien, die erst als Sequenz den kompletten Inhalt der logischen Struktur wiedergeben f��r dieses <div> Element zu setzen.
Sinnvoll ist ein solcher Verweis immer dann, wenn die verkn��pfte Datei nicht granular genug adressiert werden kann, um sie aus der physischen Struktur heraus zu verlinken; bspw. wenn keine entsprechenden Seitenumbr��che in der Datei enthalten sind oder diese den Download kompletter logischer Strukturen erm��glicht.
Der DFG-Viewer nutzt gezielt die Verkn��pfungen von logischen Strukturelementen auf Dateien der FileGroup vom Typ DOWNLOAD, um den Download einzelner Kapitel und kompletter Werke zu erm��glichen. Die entsprechenden Dateien m��ssen innerhalb der <fileSec> definiert sein und dessen <file> Elemente m��ssen ��ber entsprechende MIMETYPE Attribute verf��gen. Pro logischer Struktureinheit wird nur eine ��� die erste ��� Verkn��pfung mit einer Datei unterst��tzt. Eine solche Verkn��pfung ist f��r den DFG-Viewer optional, wenn das Dokument das Seitenbasierte oder das Komplexe Dokumentenmodell implementiert. Wird das Bibliographische Dokumentenmodell implementiert, ist ein solcher Link verpflichtend, da er die einzige Verkn��pfung zum Inhalt darstellt.
Inhalte d��rfen entweder direkt aus der logischen Struktur heraus oder aber indirekt ��ber eine Verkn��pfung der logischen Struktur mit der physischen Struktur verkn��pft werden. Eine Redundanz der Verkn��pfung auf eine Datei aus beiden Strukturen heraus ist auf alle F��lle zu vermeiden. Eine Verkn��pfung auf einzelne Seiten-Images f��r ein logisches <div> ist nicht erlaubt, wenn bereits von einem physischen Strukturelement (bspw. einer Seite) auf dasselbe Seitenimage verwiesen wird. Stattdessen ist das logische <div> Element mit der Seite ��ber die <structLink> Sektion zu verkn��pfen und von der Seite auf das entsprechende Image zu verweisen.
F��r das Bl��ttern der Seiten im DFG-Viewer ist eine entsprechende Verkn��pfung nicht relevant. Jedoch k��nnte der DFG-Viewer dem Benutzer ein Link auf das PDF im Originalrepository anbieten.
Werden mehrere Dateien aus einem <div> Element heraus verkn��pft, so m��ssen diese Dateien denselben semantischen Inhalt beinhalten. Die Darstellungsform kann jedoch unterschiedlich sein. Dazu ist es notwendig, dass sich die verkn��pften Dateien in unterschiedlichen FileGroups befinden. Somit lassen sich f��r ein <div> unterschiedliche Aufl��sungen ein und dergleichen Seite in unterschiedlichen <file> Elemente speichern und dieser Seite zuordnen.
Parallel oder in sequentieller Reihenfolge darstellbare Dateien werden nicht unterst��tzt, das hei��t <par> und <seq> Elemente d��rfen in der METS-Datei nicht enthalten sein.
Teilweise unterscheidet sich die Granularit��t des Dokumentes von der Granularit��t der einzelnen Content-Files. So kann es sinnvoll sein, Dokumente in der logischen oder physischen Struktur feiner granuliert zu erfassen, als dies f��r eine Speicherung der Inhalte sinnvoll ist. Als Beispiel ist hier die Speicherung von Volltexten zu nennen. In aller Regel werden Volltexte gem���� der TEI-Spezifikation immer komplett f��r ein Dokument in einer XML-Datei gespeichert, das hei��t der Volltext umfasst mehrere Seiten, die innerhalb des Textes markiert sind. Daher stellt METS M��glichkeiten bereit, direkt in eine solche Datei hinein zu verweisen, um den Start und das Ende des jeweiligen Inhalts des <div> Elements in der Inhaltsdatei zu markieren.
Mittels einer solchen granularen Verkn��pfung kann das zvdd-Portal Volltexte seitenbasiert indexieren und den Volltext entsprechenden Strukturelementen (<div>s) zuordnen. Der DFG-Viewer k��nnte in sp��teren Versionen in der Lage sein, neben reinen Images auch Volltexte seitenbasiert dazustellen bzw. mittels solcher Information Suchtreffer in den Images zu markieren. Die Unterst��tzung von Volltext ist generell sowohl im DFG-Viewer als auch im zvdd-Portal optional.
Eine solche Verkn��pfung erfolgt ��ber das <area> Element, welches als Kind-Element des jeweiligen File-Pointes (<fptr> Element) existiert. Ist ein <area> Element vorhanden, so wird von diesem Element mittels des FILEID Attributs auf die Inhaltsdatei verwiesen. In diesem Fall darf das <fptr> Element selber kein FILEID Element besitzen.
Als erste Verweisart wird der Verweis in Imagebereiche unterst��zt. Hierbei enth��lt der Verweis Pixelkoordinaten, um einen Bereich innerhalb des referenzierten Images zu markieren, welcher den Inhalt des jeweiligen <div> Elements wiedergibt. Ein solcher Verweis muss folgende Attribute f��r das <area> beinhalten:
SHAPE ��� Die Form des Bereiches: "RECT", "CIRCLE" oder "POLY".
COORDS ��� Die Koordinateninformation des Bereichs gem���� HTML 4.0.
Als zweite Verweisart wird der Verweis in XML-Dateien hinein unters��tzt. Ein solcher Verweis wird mittels ID Attributen durchgef��hrt. Das hei��t in der Ziel-Datei m��ssen XML-Elemente existieren, die ��ber ID Attribute mit den angegebenen Werten verf��gen. In diesem Fall muss das <area> Element die Attribute BETYPE mit dem Wert "IDREF" enthalten und die Attribute BEGIN und END m��ssen die jeweiligen Werte der ID Attribute der Volltextdatei enthalten. Soll nur auf ein einzelnes Element verwiesen werden, so enthalten die BEGIN und END Attribute denselben Wert.
Andere Verweisarten bspw. ��ber Timecode oder Bin��r-Offsets d��rfen in der METS-Datei nicht vorkommen.
Jedes METS-Dokument, welches sowohl eine logische als auch eine physische <structMap> besitzt, muss eine <structLink> Sektion haben. Dies betrifft also alle METS-Dokumente, die entsprechend des Seitenbasierten sowie des Komplexen Dokumentmodells erstellt wurden.
Die <structLink> Sektion speichert Verkn��pfungen zwischen logischer und physischer Struktur. F��r jede einzelne Verkn��pfung wird ein eigenes <smLink> Element genutzt. Jedes dieser Elemente verf��gt ��ber xlink:from and xlink:to Attribute, welche die Werte der ID Attribute der jeweiligen <div> Elemente aus der logischen und physischen Struktur beinhalten.
Es wird immer von der logischen Struktur auf die physische Struktur verwiesen. Dies bedeutet, dass das xlink:from Attribut den ID-Wert eines <div> Elements aus der logischen Struktur enthalten muss; xlink:to beinhaltet demzufolge also den Wert des ID Attributs eines <div>s aus der physischen Struktur.
Eine Verkn��fung auf eine physische Struktur bezieht sich auch immer auf alle unterliegenden Strukturelemente. Eine Verkn��pfung von der obersten logischen Struktureinheit (bspw. Monographie) auf die physische Sequenz (physSequence) impliziert also auch alle Verkn��pfungen auf die einzelnen Seiten, die dem physischen Sequenz untergeordnet sind. Eine explizite Verkn��pfung zwischen Monographie und den einzelnen Seiten sind nicht notwendig.
Dagegen werden Verkn��pfungen auf logischer Struktur NICHT vererbt. Das hei��t f��r jedes logische <div> Element sind alle Verkn��pfungen erneut wieder aufzuf��hren. Die Gesamtheit aller unterliegenden <div> Elemente muss jedoch nicht zwangsl��ufig alle Verkn��pfungen des ��bergeordneten <div> Elements enthalten.
Dies bedeutet, dass f��r das Seitenbasierte Dokumentenmodell, welches vom DFG-Viewer implementiert wird, lediglich eine Verkn��pfung von der obersten logischen Dokumentstruktur auf die physSequence notwendig ist. Die definierten Seiten m��ssen nicht aus der logischen Struktur heraus verkn��pft werden. Der DFG-Viewer ist in der Lage, den impliziten Verkn��pfungen zu folgen.
Alle Images, die in den vom DFG-Viewer genutzten File Groups als Content-File referenziert werden, m��ssen in einem Format vorliegen, welches direkt durch einen Web-Browser darstellbar ist. Als solche Formate gelten derzeit JPG, GIF und PNG. Andere Formate werden nicht unterst��zt. Eine Ausnahme bilden all jene Dateien, die in der File-Group vom Typ DOWNLOAD enthalten sind. Hierbei handelt es sich ��berwiegend um Dateien, die dem Nutzer zum Download angeboten werden, beispielsweise PDF.
Derzeit existiert noch keine Beschreibung eines standarisierten Formats f��r den Volltext zur Pr��sentation im DFG-Viewer oder zur Indexierung im zvdd-Portal. Entsprechend wird Volltext, so er denn als Content-File referenziert wird, durch beide Applikationen nicht ber��cksichtigt.