Lieber Herr Heiligenhaus, wie gehen Sie denn dann mit Einzelseiten um, wenn Sie in der logischen StructMap verknüpfen? Das sind ja eindeutig keine logischen Strukturen. Verknüpfen Sie diese weiterhin in der physischen StructMap oder führen Sie jede Seite auch noch einmal in der logischen Struktur auf? Viele Grüße Sebastian Meyer

> -----Ursprüngliche Nachricht----- Von: dv-technik-bounces(a)dfg-viewer.de > [mailto:dv-technik-bounces@dfg- viewer.de] Im Auftrag von Kay > Heiligenhaus Gesendet: Dienstag, 11. November 2008 10:56 An: > technik(a)dfg-viewer.de Betreff: Re: [DFG-Viewer] Einzelseiten-PDF zum > Download > > Lieber Herr Meyer, > >> das Gesamt-PDF wird wie die Einzelseiten mit einer FILEID versehen und >> dann in der physischen StructMap nicht mit einer "page" verknüpft, >> sondern mit der gesamten "physSequence". > Das ist eine der metaphysischen Fragen, die sich aus dem komplexen > Dokumentenmodell ergeben. ;) Ich denke, für den aktuellen Zweck ist es > leidlich gleichgültig, ob man aus der log. structMap verknüpft oder aus > der phys. Für beides ließen sich auch hinreichende Gründe angeben. > Spätestens beim Download von Kapiteln, Abschnitten usw. würden man sich > aber eindeutig auf der log. Modellierungsebene befinden und folglich auch > von dort verknüpfen müssen. Da letzteres aber im Viewer nicht vorgesehen > ist (obgleich die DFG- Praxisregeln diese Möglichkeit explizit > nahelegen), stellen wir das dann entsprechend bei uns um. > > Beste Grüße, Kay Heiligenhaus

(1) Von wo aus werden die Dateien für die DOANLOAD Sektion verknüpft? Aus der logischen oder der physischen StructMap? Formulierung(en) prüfen. Mehrfachnennungen vermeiden. Ich habe sie aus der physischen StructMap verknüpft. Für die Einzelseiten geht es ja auch gar nicht anders, weil die keine Repräsentation in der logischen StructMap besitzen. Beim Download des Gesamtwerks scheiden sich die Geister: ich habe das als Sequenz von Einzelseiten interpretiert und entsprechend in der physischen Struktur verlinkt, Herr Heiligenhaus hat das PDF dagegen mit der logischen Struktur "Monographie" verknüpft. Wenn jemand Downloads von einzelnen Kapiteln anbietet, kann er diese wiederum ausschließlich in der logischen Struktur verknüpfen. Der Viewer sucht bisher übrigens nur in der physischen Struktur nach Downloads.

(2) Was ist mit den zvdd-Srukturtypen? Sind diese für den DFG-Viewer nicht mehr Pflicht wie in der letzten Version? Eigentlich sind sie für den DFG-Viewer tatsächlich nicht nötig. Der Viewer zeigt einfach für jedes Strukturelement das an, was im LABEL-Attribut steht, und wenn das nicht belegt ist, dann zeigt er direkt die Angabe im TYPE-Attribut an. Man könnte nun höchstens für die ZVDD-Strukturdatenliste beispielsweise intern alternative Bezeichnungen hinterlegen, so dass nicht der Inhalt des TYPE-Attributs als Fallback angezeigt wird, wenn kein LABEL existiert, sondern diese interne Bezeichnung. Ich halte die Strukturdatenliste aber dennoch für wichtig, weil sie die Ausgabe der verschiedenen OAI-Schnittstellen verschiedener Einrichtungen ein Stück weit standardisiert. Dadurch dass jede Einrichtung angehalten ist, ihre intern verwendeten Strukturdaten auf dieses Set herunterzubrechen, bevor sie sie per OAI in der Welt verteilt, liefern alle OAI-Schnittstellen ein vergleichbares Strukturdatenset.

(3) Darf es ein <div TYPE="page" /> in der logischen Structmap geben? Das war in einem der vorigen Beispieln so. Meinem Verständnis nach darf es das nicht geben, weil eine Seite keine logische Struktur ist.

(4) Gibt es evtl. Probleme mit anderen Page-Turnern, wenn wir keine MODS-Sektion für das erste <div> in der logischen StructMap haben (Zeitschriften/Mehrbändige Werke)? Was macht der Viewer, wenn bei einer Zeitschrift BEIDE <div> eine MODS-Sektion haben? Ich kann jetzt selbst nur raten, weil ich zu Hause den Quellcode nicht einsehen kann, aber ich würde vermuten, der Viewer würde den ersten MODS-Datensatz (den der Zeitschrift/des mehrbändigen Werks) ignorieren. Das würde ich zumindest von ihm erwarten, ob er es wirklich tut, habe ich ehrlich gesagt nie getestet. :o) Ob andere Pageturner ein Problem damit haben, weiß ich nicht.

Im letzeren Fall beanstandet er das Fehlen einer logical structMap. Herr Meyer, Sie hatten das in ihrem Beispiel so formuliert (mail v. 14.8): <mets:structMap TYPE="LOGICAL"> <mets:div ID="logical_276111435" DMDID="dmdSec_276111435" ADMID="amdSec_276111435" TYPE="multivolume" CONTENTIDS="http://digital.slub-dresden.de/ppn276111435 urn:nbn:de:bsz:14-ppn2761114353" LABEL="Tractatus Geometricus..."> <mets:div ID="logical_27611342X" TYPE="volume" LABEL="Band 1"> <mets:mptr LOCTYPE="URL" xlink:href="http://localhost/Band.xml"/> </mets:div> </mets:div> </mets:structMap> Verstehe ich nuun recht, dass alle untergeordneten Einheiten hier explizit genannt werden müssen?

Der Trigger für die Darstellung im Viewer ist vermutlich type=multivolume. Ist das so?

Programmiertechnisch muss ich also vorher alle in PICA verknüpften Sätze (z.B. über REL oder FAM) einsammeln und hier in dieser Form zusammenführen? In <mets:mptr LOCTYPE="URL" xlink:href="http://localhost/Band.xml"/> </mets:div> stuende dann ein OAI-Link zum jeweiligen Eintrag. Hmm.

Beim Beispiel von Herrn Funk zu den Zeitschriften (S.21) schwant mir Ungemach, wenn ich das aus PICA generieren soll (dort gibt es keine Band-Zwischenebene!), sondern nur Zeitschrift und Artikel. Geht das auch? Für den Viewer sicher kein Problem, wohl aber fuer zvdd.

Dann ist mir jetzt erst bei dem Musterband von Herrn Meyer (http://dfg-viewer.de/v2/?set[mets]=http%3A%2F%2Fdigital.slub- dresden.de%2FBand.xml) aufgefallen, dass offenbar Strukturdateninformationen neben dem erwartbaren Paaren Type und Label auch in mods-Feldern untergebracht wurden (title). Das ist nach meiner Einschätzung falsch. Eine Zwischenüberschrift ist kein Titel: <mets:xmlData> <mods:mods> <mods:titleInfo> <mods:title>DAS EERSTE CAPITTEL. Lehret erkenen wie man mitt allen Linien in gemein handelen solle.</mods:title> </mods:titleInfo> </mods:mods> </mets:xmlData> Das sollten wir so nicht machen. Warum ist das nötig? Steht doch alles in Type + Label. Wenn wir Teile von Volltexten einbringen wollen (als solche könnte man Überschriften ja auffassen), könnte man auf TEI (Datei in File-Section) kodierte Texte verlinken (vgl. auch S.25f.). Bitte nicht in dmd-Sections.

Dann ist mir jetzt erst bei dem Musterband von Herrn Meyer (http://dfg-viewer.de/v2/?set[mets]=http%3A%2F%2Fdigital.slub- dresden.de%2FBand.xml) aufgefallen, dass offenbar Strukturdateninformationen neben dem erwartbaren Paaren Type und Label auch in mods-Feldern untergebracht wurden (title). Das ist nach meiner Einschätzung falsch. Eine Zwischenüberschrift ist kein Titel: <mets:xmlData> <mods:mods> <mods:titleInfo> <mods:title>DAS EERSTE CAPITTEL. Lehret erkenen wie man mitt allen Linien in gemein handelen solle.</mods:title> </mods:titleInfo> </mods:mods> </mets:xmlData> Das sollten wir so nicht machen. Warum ist das nötig? Steht doch alles in Type + Label. Wenn wir Teile von Volltexten einbringen wollen (als solche könnte man Überschriften ja auffassen), könnte man auf TEI (Datei in File-Section) kodierte Texte verlinken (vgl. auch S.25f.). Bitte nicht in dmd-Sections.

Lieber Herr Meyer, many thanks fuer die rasche Antwort auf meine längliche Mail. Entschuldigen Sei bitte, dass es wegen diverser Verpflichtungen so zeitversetzt kam. Ich mich dann mal ans Programmieren :-) Noch eine Frage: Gibt es schon ein Beispiel, dass alle oder doch fast alle Feature implementiert? Viele Gruesse, Ihr Th. Stäcker Meyer, Sebastian schrieb: > Lieber Herr Staecker, > >> Im letzeren Fall beanstandet er das Fehlen einer logical structMap. Herr >> Meyer, Sie hatten das in ihrem Beispiel so formuliert (mail v. 14.8): >> >> <mets:structMap TYPE="LOGICAL"> >> <mets:div ID="logical_276111435" DMDID="dmdSec_276111435" >> ADMID="amdSec_276111435" TYPE="multivolume" >> CONTENTIDS="http://digital.slub-dresden.de/ppn276111435 >> urn:nbn:de:bsz:14-ppn2761114353" LABEL="Tractatus Geometricus..."> >> <mets:div ID="logical_27611342X" TYPE="volume" >> LABEL="Band 1"> >> <mets:mptr LOCTYPE="URL" >> xlink:href="http://localhost/Band.xml"/> >> </mets:div> >> </mets:div> >> </mets:structMap> >> >> >> Verstehe ich nuun recht, dass alle untergeordneten Einheiten hier >> explizit genannt werden müssen? > > Richtig. Zumindest dann, wenn Sie möchten, dass im Viewer in der > Navigation eine Liste aller untergeordneten Einheiten angezeigt wird. > >> Der Trigger für die Darstellung im >> Viewer ist vermutlich type=multivolume. Ist das so? > > Nein, der Viewer behandelt jede METS-Datei absolut gleich, in sofern > braucht er keine Trigger. Sie können an beliebigen Stellen innerhalb > beliebiger Strukturen METS-Pointer verwenden. Das ist nicht auf die > Verknüpfung untergeordneter Einheiten in übergeordneten Einheiten > beschränkt. Sie können auch innerhalb einer Monographie ein einzelnes > Kapitel in eine eigene METS-Datei auslagern und diese per METS-Pointer > einbinden. Der Viewer sollte damit transparent umgehen können. > >> Programmiertechnisch >> muss ich also vorher alle in PICA verknüpften Sätze (z.B. über REL oder >> FAM) einsammeln und hier in dieser Form zusammenführen? In <mets:mptr >> LOCTYPE="URL" xlink:href="http://localhost/Band.xml"/> >> </mets:div> stuende dann ein OAI-Link zum jeweiligen >> Eintrag. Hmm. > > Richtig. > >> Beim >> Beispiel von Herrn Funk zu den Zeitschriften (S.21) schwant mir >> Ungemach, wenn ich das aus PICA generieren soll (dort gibt es keine >> Band-Zwischenebene!), sondern nur Zeitschrift und Artikel. Geht das >> auch? Für den Viewer sicher kein Problem, wohl aber fuer zvdd. > > Für den Viewer ist das tatsächlich unerheblich. Wenn es in Ihrer > METS-Datei keine Bandebene gibt, dann zeigt der Viewer eben auch keine > an, sondern unterhalb der Zeitschrift gleich die Artikel. > >> Dann ist mir jetzt erst bei dem Musterband von Herrn Meyer >> (http://dfg-viewer.de/v2/?set[mets]=http%3A%2F%2Fdigital.slub- >> dresden.de%2FBand.xml) >> aufgefallen, dass offenbar Strukturdateninformationen neben dem >> erwartbaren Paaren Type und Label auch in mods-Feldern untergebracht >> wurden (title). Das ist nach meiner Einschätzung falsch. Eine >> Zwischenüberschrift ist kein Titel: >> >> <mets:xmlData> >> <mods:mods> >> <mods:titleInfo> >> <mods:title>DAS EERSTE CAPITTEL. Lehret erkenen wie >> man mitt allen Linien in gemein handelen solle.</mods:title> >> </mods:titleInfo> >> </mods:mods> >> </mets:xmlData> >> >> >> Das sollten wir so nicht machen. Warum ist das nötig? Steht doch alles >> in Type + Label. Wenn wir Teile von Volltexten einbringen wollen (als >> solche könnte man Überschriften ja auffassen), könnte man auf TEI (Datei >> in File-Section) kodierte Texte verlinken (vgl. auch S.25f.). Bitte >> nicht in dmd-Sections. > > Da merkt man wieder, dass ich eigentlich nicht aus der Bibliothekswelt > komme. Darüber dass Kapitelüberschriften keine Titel von Kapiteln > sind, habe ich schlicht nicht nachgedacht. :) Sie haben natürlich > recht und ich werde das korrigieren. Danke für den Hinweis! > > Viele Grüße > Sebastian Meyer > > -- > ___________________________________________________ > > Sebastian Meyer > > Abteilung Informationstechnologie > Referat Entwicklung > > Sächsische Landesbibliothek - > Staats- und Universitätsbibliothek Dresden (SLUB) > 01054 Dresden > Besucheradresse: Zellescher Weg 18 > > Tel.: +49 351 4677-206 > Fax: +49 351 4677-711 > Mail: smeyer(a)slub-dresden.de > Web: http://www.slub-dresden.de/ > ___________________________________________________ > > >> -----Ursprüngliche Nachricht----- >> Von: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg- >> viewer.de] Im Auftrag von Dr. Thomas Staecker >> Gesendet: Montag, 24. November 2008 15:46 >> An: technik(a)dfg-viewer.de >> Betreff: Re: [DFG-Viewer] zvdd/DFG-Viewer METS Profil - Version 2.0 >> >> Lieber Herr Funk, liebe Kolleginnen und Kollegen, >> >> vielen Dank für das Update. Dazu unmittelbar auch noch einige >> Bemerkungen. >> >> Ich würde empfehlen die Identifierfrage etwas offener formulieren. >> >> Ihr Beispiel: >> >> <mets:xmlData> >> <!-- Der MODS-spezifische Metadatenblock beginnt hier --> >> <mods:mods> >> <!-- Eindeutige Identifizierung des entsprechenden <div> Elements --> >> <mods:identifier type="urn">urn:nbn:gbv-7- >> PPN481399712</mods:identifier> >> </mods:mods> >> >> sieht bei uns noch so aus: >> >> <mets:xmlData> >> <mods:mods xsi:schemaLocation="http://www.loc.gov/mods/v3 >> http://www.loc.gov/standards/mods/v3/mods-3-2.xsd" > >> <mods:recordInfo> >> <mods:recordIdentifier source="WDB_OPAC" >> >oai:diglib.hab.de:ppn_515681113</mods:recordIdentifier> >> </mods:recordInfo> >> <mods:location> >> <mods:physicalLocation>HAB Wolfenbüttel, A: 55.4° Hist. 2° >> </mods:physicalLocation> >> </mods:location> >> <mods:identifier type="purl" >> >http://diglib.hab.de/drucke/55-4-hist-2f/start.htm</mods:identifier> >> <mods:identifier type="urn" >> >urn:nbn:de:gbv:23-drucke/55-4-hist-2f3</mods:identifier> >> >> Will man diesen Reichtum unterdrücken ;-) >> >> Im Ernst, was mir in Ihrer Formulierung etwas unglücklich scheint, ist, >> dass Sie URN mit OAI zusammenbringen. Für OAI brauchen Sie keine URN, >> sondern einen nach OAI gültigen Identifier, innerhalb (!) dessen >> natürlich auch eine URN genutzt werden kann. Die Formulierung "der am >> zvdd-Portal aufgesetzte OAI-Harvester (schön zu hören, dass er jetzt >> kommt ;-) bedient sich der URN..." ist eigentlich nach OAI nicht ganz >> korrekt, weil er nicht mit dem OAI Identifier identisch ist. >> Formulierung dort >> (http://www.openarchives.org/OAI/openarchivesprotocol.html#UniqueIdentifier) >> >> "...requesting a record(!) in a specific metadata format from an item". >> Der Identifier hier bezieht sich auf das item, nicht auf den record, >> ergo ist er auch unmittelbar nicht mit dem OAI Identifier in eins zu >> setzen (die alten Subtilitäten;-) >> >> Ich rate deshalb - das ist definitiv eine Wiederholung - für die >> Nutzung von OAI einen recordIdentifier zu verwenden: >> >> <mods:recordIdentifier source="WDB_OPAC"> >> oai:diglib.hab.de:ppn_515681113</mods:recordIdentifier> >> </mods:recordInfo> >> >> Natürlich ist dei Verwendung eines zusätzlichen identifierers fuer die >> eigentliche ressource unbenommen. >> >> Die Fragen zur Mehrbändigkeit bzw. Unterordnungen konnte ich mir jetzt >> erstmals etwas gründlicher ansehen. Darf ich das einfach mal an Hand >> unsere Quellen rekapitulieren: >> >> Wir haben z.B. dieses enthaltene Werk: >> >> http://dbs.hab.de/oai/?repository=WDB_OPAC&verb=GetRecord&metadataP… >> >> identifier=oai:diglib.hab.de:ppn_561529892 >> >> das auf das übergeordnete verweist. Wir verweisen hier aber nicht vom >> übergeordneten auf das untergeordnete. Das habe ich hoffentlich richtig >> verstanden? >> >> Dann habe ich ein mehrbändiges Werk, dessen dritter Band so dargestellt >> wird: >> >> http://dbs.hab.de/oai/?repository=WDB_OPAC&verb=GetRecord&metadataP… >> >> identifier=oai:diglib.hab.de:ppn_517014696 >> >> >> <mods:relatedItem type="host" > >> <mods:recordInfo> >> <mods:recordIdentifier source="WDB_OPAC" >> >oai:diglib.hab.de:ppn_515997110</mods:recordIdentifier> >> </mods:recordInfo> >> <mods:titleInfo> >> <mods:title>Magnvm Theatrvm Vitæ Hvmanæ: Hoc Est, Rervm Divinarvm, >> Hvmanarvmqve Syntagma Catholicvm, Philosophicvm, Historicvm, Et >> Dogmaticvm</mods:title> >> </mods:titleInfo> >> </mods:relatedItem> >> <mods:part type="host" order="3" > >> <mods:detail> >> <mods:number>Tomvs Tertivs</mods:number> >> </mods:detail> >> </mods:part> >> >> Hier die Frage: Wenn ich nach Ihrem Muster <mods:detail type="volume"> >> statt nur <mods:detail> schriebe, müsste ich vermutlich irgendwie dem >> Datensatz entnehmen, dass es sich hierbei wirklich um ein "Volume" >> handelt. Technisch wird aber nur f/j erkannt (z.B. Oju oder Ofu), so >> dass ich nicht sicher sein kann, ob das Verhältnis wirklich durch den >> Begriff "volume" korrekt beschrieben ist. Soll das Pflicht sein? Anders >> gefragt, wofür brauchen Sie das type-Attribute? >> >> http://dbs.hab.de/oai/?repository=WDB_OPAC&verb=GetRecord&metadataP… >> >> identifier=oai:diglib.hab.de:ppn_515997110 >> >> ist dann der uebergeordnete Datensatz, der kein Digitalisat enthaelt. >> Der leere Datensatz bringt es mit sich, dass >> >> <dv:links> >> <dv:reference></dv:reference> >> <dv:presentation></dv:presentation> >> </dv:links> >> >> leer sind. Reference koennte man fuellen, ist aber aus meiner >> Programmierung heraus schwierig. Mal sehen. presentation muss >> logischerweise leer bleiben. >> >> http://dbs.hab.de/oai/?repository=WDB_OPAC&verb=GetRecord&metadataP… >> >> identifier=oai:diglib.hab.de:ppn_515997110 >> geht noch nicht im Viewer: >> >> weder dies: >> >> http://dfg- >> viewer.de/v1/?set[mets]=http%3A%2F%2Fdbs.hab.de%2Foai%2Findex.php%3Fverb%3DGet >> >> Record%26metadataPrefix%3Dmets%26identifier%3Doai:diglib.hab.de:ppn_515997110 >> >> >> noch dies: >> >> http://dfg- >> viewer.de/v2/?set[mets]=http%3A%2F%2Fdbs.hab.de%2Foai%2Findex.php%3Fverb%3DGet >> >> Record%26metadataPrefix%3Dmets%26identifier%3Doai:diglib.hab.de:ppn_515997110 >> >> >> Im letzeren Fall beanstandet er das Fehlen einer logical structMap. Herr >> Meyer, Sie hatten das in ihrem Beispiel so formuliert (mail v. 14.8): >> >> <mets:structMap TYPE="LOGICAL"> >> <mets:div ID="logical_276111435" DMDID="dmdSec_276111435" >> ADMID="amdSec_276111435" TYPE="multivolume" >> CONTENTIDS="http://digital.slub-dresden.de/ppn276111435 >> urn:nbn:de:bsz:14-ppn2761114353" LABEL="Tractatus Geometricus..."> >> <mets:div ID="logical_27611342X" TYPE="volume" >> LABEL="Band 1"> >> <mets:mptr LOCTYPE="URL" >> xlink:href="http://localhost/Band.xml"/> >> </mets:div> >> </mets:div> >> </mets:structMap> >> >> >> Verstehe ich nuun recht, dass alle untergeordneten Einheiten hier >> explizit genannt werden müssen? Der Trigger für die Darstellung im >> Viewer ist vermutlich type=multivolume. Ist das so? Programmiertechnisch >> muss ich also vorher alle in PICA verknüpften Sätze (z.B. über REL oder >> FAM) einsammeln und hier in dieser Form zusammenführen? In <mets:mptr >> LOCTYPE="URL" xlink:href="http://localhost/Band.xml"/> >> </mets:div> stuende dann ein OAI-Link zum jeweiligen >> Eintrag. Hmm. Lieber Herr Heiligenhaus, wie haben Sie das gemacht? Beim >> Beispiel von Herrn Funk zu den Zeitschriften (S.21) schwant mir >> Ungemach, wenn ich das aus PICA generieren soll (dort gibt es keine >> Band-Zwischenebene!), sondern nur Zeitschrift und Artikel. Geht das >> auch? Für den Viewer sicher kein Problem, wohl aber fuer zvdd. >> >> Dann ist mir jetzt erst bei dem Musterband von Herrn Meyer >> (http://dfg-viewer.de/v2/?set[mets]=http%3A%2F%2Fdigital.slub- >> dresden.de%2FBand.xml) >> aufgefallen, dass offenbar Strukturdateninformationen neben dem >> erwartbaren Paaren Type und Label auch in mods-Feldern untergebracht >> wurden (title). Das ist nach meiner Einschätzung falsch. Eine >> Zwischenüberschrift ist kein Titel: >> >> <mets:xmlData> >> <mods:mods> >> <mods:titleInfo> >> <mods:title>DAS EERSTE CAPITTEL. Lehret erkenen wie >> man mitt allen Linien in gemein handelen solle.</mods:title> >> </mods:titleInfo> >> </mods:mods> >> </mets:xmlData> >> >> >> Das sollten wir so nicht machen. Warum ist das nötig? Steht doch alles >> in Type + Label. Wenn wir Teile von Volltexten einbringen wollen (als >> solche könnte man Überschriften ja auffassen), könnte man auf TEI (Datei >> in File-Section) kodierte Texte verlinken (vgl. auch S.25f.). Bitte >> nicht in dmd-Sections. >> >> Auf S. 17 ist noch ein Rechtschreibfehler Attibt, statt Attribut. >> >> Ansonsten alles wunderbar. Danke für die Zusammenfassung. >> >> Viele Grüße, >> Ihr >> Th. Stäcker >> >> >> >>> >> =========================================================================== >> >>> == >>> FRAGEN == >>> =========================================================================== >>> >>> >>> (1) Von wo aus werden die Dateien für die DOANLOAD Sektion >>> verknüpft? Aus >>> der logischen oder der physischen StructMap? Formulierung(en) >>> prüfen. >>> Mehrfachnennungen vermeiden. >>> >>> (2) Was ist mit den zvdd-Srukturtypen? Sind diese für den DFG-Viewer >>> nicht >>> mehr Pflicht wie in der letzten Version? >>> >>> (3) Darf es ein <div TYPE="page" /> in der logischen Structmap >>> geben? Das >>> war in einem der vorigen Beispieln so. >>> >>> (4) Gibt es evtl. Probleme mit anderen Page-Turnern, wenn wir keine >>> MODS-Sektion für das erste <div> in der logischen StructMap haben >>> (Zeitschriften/Mehrbändige Werke)? >>> Was macht der Viewer, wenn bei einer Zeitschrift BEIDE <div> eine >>> MODS-Sektion haben? >>> >>> =========================================================================== >>> >>> == >>> FRAGEN == >>> =========================================================================== >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> zvdd/DFG-Viewer METS-Profil – Version 2.0 >>> >>> ------------------------------------------------------------------------ >>> >>> >>> XML Version des METS-Profils <./zvdd-dfgviewer-mets-profil-v2.xml> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> Abstrakt >>> >>> 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>. >>> >>> >>> URI >>> >>> ./zvdd-dfgviewer-mets-profil-v2.xml >>> >>> >>> Datum >>> >>> 2008-11-14T12:00:00 >>> >>> >>> Kontakt >>> >>> *Stefan E. Funk* >>> Niedersächsische Staats- und Universitätsbibliothek >>> Papendiek 14 >>> >>> >>> Weitere verknüpfte / benutzte Profile >>> >>> Dieses Profil ist eigenständig; keine anderen METS-Profile sind mit >>> diesem Profil verknüpft. >>> >>> >>> Benutzte "Extension Schema" >>> >>> Metadata Object and Description Schema (MODS) >>> http://www.loc.gov/standards/mods/ >>> >>> >>> Description Rules >>> >>> >>> Kontrollierte Vokabularien >>> >>> *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. >>> >>> >>> Strukturelle Anforderungen >>> >>> >>> Deskriptive Metadata Sektion >>> >>> >>> dmdSec Anforderung 1: Anzahl und Art der deskriptiven >>> Metadaten >>> >>> 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. >>> >>> >>> dmdSec Anforderung 2: MODS Metadaten für logische Objekte >>> >>> 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. >>> >>> >>> dmdSec Anforderung 3: Eindeutige Identifizierung des >>> Dokumentes mit <mods:identifier> >>> >>> 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. >>> >>> >>> Beispiel 1: Identifizierung eines <div>s >>> >>> >>> >>> <mets:mets> >>> <mets:dmdSec ID="DMD_00"> >>> <mets:mdWrap MDTYPE="MODS"> >>> <mets:xmlData> >>> <!-- Der MODS-spezifische Metadatenblock beginnt hier --> >>> <mods:mods> >>> <!-- Eindeutige Identifizierung des entsprechenden <div> >> Elements --> >>> <mods:identifier >>> type="urn">urn:nbn:gbv-7-PPN481399712</mods:identifier> >>> </mods:mods> >>> </mets:xmlData> >>> </mets:mdWrap> >>> </mets:dmdSec> >>> >>> <!-- Logische StructMap --> >>> <mets:structMap TYPE="LOGICAL"> >>> <mets:div DMDID="DMD_00" TYPE="Monograph" /> >>> </mets:structMap> >>> </mets:mets> >>> >>> >>> >>> >>> dmdSec Anforderung 4: Hierarchische Verknüpfung von >>> Dokumenten mittels MODS >>> >>> 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). >>> >>> >>> Beispiel 2: Hierarchische Verknüpfung zweier Dokumente >>> mittels MODS - nachfolgendes und übergeordnetes Element >>> >>> >>> >>> <!-- Nachfolgendes Element --> >>> <mets:mets> >>> <mets:dmdSec ID="DMD_01"> >>> <mets:mdWrap MDTYPE="MODS"> >>> <mets:xmlData> >>> <mods:mods> >>> <!-- Eindeutige Identifizierung des <div> Elements --> >>> <mods:identifier >>> type="urn">urn:nbn:gbv-7-PPN481399712</mods:identifier> >>> <!-- Identifizierung des Elements --> >>> <mods:recordInfo> >>> <mods:recordIdentifier >>> source="gbv-ppn">PPN481399712</mods:recordIdentifier> >>> </mods:recordInfo> >>> <!-- Verknüpfung zum übergeordneten Element --> >>> <mods:relatedItem type="host"> >>> <mods:recordInfo> >>> <mods:recordIdentifier >>> source="gbv-ppn">PPN515678759</mods:recordIdentifier> >>> </mods:recordInfo> >>> </mods:relatedItem> >>> </mods:mods> >>> </mets:xmlData> >>> </mets:mdWrap> >>> </mets:dmdSec> >>> >>> <!-- Logische StructMap --> >>> <mets:structMap TYPE="LOGICAL"> >>> <mets:div DMDID="DMD_01" /> >>> </mets:structMap> >>> </mets:mets> >>> >>> <!-- Ãœbergeordnetes Element --> >>> <mets:mets> >>> <mets:dmdSec ID="DMD_02"> >>> <mets:mdWrap MDTYPE="MODS"> >>> <mets:xmlData> >>> <mods:mods> >>> <!-- Eindeutige Identifizierung des <div> Elements --> >>> <mods:identifier >>> type="urn">urn:nbn:gbv-7-PPN515678759</mods:identifier> >>> <!-- Identifizierung des Elements --> >>> <mods:recordInfo> >>> <mods:recordIdentifier >>> source="gbv-ppn">PPN515678759</mods:recordIdentifier> >>> </mods:recordInfo> >>> </mods:mods> >>> </mets:xmlData> >>> </mets:mdWrap> >>> </mets:dmdSec> >>> >>> <!-- Logische StructMap --> >>> <mets:structMap TYPE="LOGICAL"> >>> <mets:div DMDID="DMD_02" /> >>> </mets:structMap> >>> </mets:mets> >>> >>> >>> >>> >>> dmdSec Anforderung 5: Reihenfolge der Strukturelemente in der >>> logischen Struktur >>> >>> 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. >>> >>> >>> Beispiel 4: Verweis auf die Bandnummer des übergeordneten >>> Werkes >>> >>> >>> >>> <mets:mets> >>> <mets:dmdSec ID="DMD_03"> >>> <mets:mdWrap MDTYPE="MODS"> >>> <mets:xmlData> >>> <mods:mods> >>> <!-- Eindeutige Identifizierung des entsprechenden <div> >> Elements --> >>> <mods:identifier >>> type="urn">urn:nbn:gbv-7-481399712</mods:identifier> >>> <!-- Verknüpfung zum übergeordneten Element --> >>> <mods:relatedItem type="host"> >>> <mods:recordInfo> >>> <mods:recordIdentifier >>> source="gbv-ppn">PPN515678759</mods:recordIdentifier> >>> </mods:recordInfo> >>> </mods:relatedItem> >>> <!-- Einordnung innerhalb des übergeordneten Elements >>> --> >>> <mods:part order="80"> >>> <mods:detail type="volume"> >>> <mods:number>Achte Theil</mods:number> >>> </mods:detail> >>> </mods:part> >>> </mods:mods> >>> </mets:xmlData> >>> </mets:mdWrap> >>> </mets:dmdSec> >>> >>> <!-- Logische StructMap --> >>> <mets:structMap TYPE="LOGICAL"> >>> <mets:div DMDID="DMD_03" /> >>> </mets:structMap> >>> </mets:mets> >>> >>> >>> >>> >>> Administrative Metadata Sektion >>> >>> >>> amdSec Anforderung 1: Metadaten zu Rechteinhaber und Urheber >>> >>> 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. >>> >>> >>> Beispiel 5: Metadaten zu Rechteinhaber und Urheber >>> >>> >>> >>> <mets:mets> >>> <mets:amdSec ID="ex05__AMD_00"> >>> <!-- rightsMD Sektion --> >>> <mets:rightsMD ID="ex05__RIGHTSMD_00"> >>> <mets:mdWrap MDTYPE="OTHER" OTHERMDTYPE="DFGRIGHTS"> >>> <mets:xmlData> >>> <!-- Hier wird der DFG-Namespace definiert; momentan >>> existiert >> noch kein Schema dafür --> >>> <dv:rights xmlns:dv="http://dfg-viewer.de/"> >>> <dv:owner>Digitalisierungszentrum der >>> Niedersächsischen >> Staats- und >>> Universitätsbibliothek Göttingen</dv:owner> >>> <dv:ownerLogo>http://gdz.sub.uni- >> goettingen.de/logo_gdz_dfgv.png</dv:ownerLogo> >>> <dv:ownerSiteURL>http://gdz.sub.uni- >> goettingen.de</dv:ownerSiteURL> >>> </dv:rights> >>> </mets:xmlData> >>> </mets:mdWrap> >>> </mets:rightsMD> >>> <!-- digiprovMD Sektion sieheh unten --> >>> </mets:amdSec> >>> >>> <!-- Logische StructMap --> >>> <mets:structMap TYPE="LOGICAL"> >>> <mets:div ADMID="ex05__AMD_00" TYPE="Monograph" /> >>> </mets:structMap> >>> </mets:mets> >>> >>> >>> >>> >>> amdSec Anforderung 2: Metadaten zu Herkunft und >>> Online-Präsentation >>> >>> 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. >>> >>> >>> Beispiel 6: Metadaten zu Herkunft und Online-Präsentation >>> >>> >>> >>> <mets:mets> >>> <mets:amdSec ID="ex06__AMD_00"> >>> <!-- rightsMD Sektion siehe oben --> >>> <!-- digiprovMD Sektion --> >>> <mets:digiprovMD ID="ex06__DIGIPROVMD_00"> >>> <mets:mdWrap MDTYPE="OTHER" MIMETYPE="text/xml" >>> OTHERMDTYPE="DVLINKS"> >>> <mets:xmlData> >>> <!-- Hier wird der DFG-Namespace definiert; momentan >>> existiert >> noch kein Schema dafür --> >>> <dv:links xmlns:dv="http://dfg-viewer.de/"> >>> <dv:reference>http://opac.sub.uni- >> goettingen.de/DB=1/PPN?PPN=394930762</dv:reference> >>> <dv:presentation>http://resolver.sub.uni- >> goettingen.de/purl?PPN394930762</dv:presentation> >>> </dv:links> >>> </mets:xmlData> >>> </mets:mdWrap> >>> </mets:digiprovMD> >>> </mets:amdSec> >>> >>> <!-- Logische StructMap --> >>> <mets:structMap TYPE="LOGICAL"> >>> <mets:div ADMID="ex06__AMD_00" TYPE="Periodical" /> >>> </mets:structMap> >>> </mets:mets> >>> >>> >>> >>> >>> Datei Sektion >>> >>> >>> fileSec Anforderung 1: File-Section >>> >>> 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. >>> >>> >>> fileSec Anforderung 2: File-Groups >>> >>> 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. >>> >>> >>> fileSec Anforderung 3: Files >>> >>> 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. >>> >>> >>> Beispiel 7: Definition von Inhaltsdateien in verschiedenen >>> File-Groups >>> >>> >>> >>> <mets:mets xmlns:xlink="http://www.w3.org/1999/xlink"> >>> <mets:fileSec> >>> >>> <!-- Enthält alle Images in der beim Start des Viewers >>> angezeigten >> Version --> >>> <mets:fileGrp USE="DEFAULT"> >>> <mets:file ID="ex07__FILE00_DEF" MIMETYPE="image/tiff" >>> SIZE="43630"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/default/image/00.tif" /> >>> </mets:file> >>> <mets:file ID="ex07__FILE01_DEF" MIMETYPE="image/tiff" >>> SIZE="63235"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/default/image/01.tif" /> >>> </mets:file> >>> <mets:file ID="ex07__FILE02_DEF" MIMETYPE="image/tiff" >>> SIZE="225434"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/default/image/02.tif" /> >>> </mets:file> >>> </mets:fileGrp> >>> >>> <!-- Enthält alle Images in einer kleineren Version. Diese >>> fileGrp >> muss genauso viele Images enthalten wie alle anderen fileGrps --> >>> <mets:fileGrp USE="MIN"> >>> <mets:file ID="ex07__FILE00_MIN" MIMETYPE="image/png" >>> SIZE="2356"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/smaller/image/00.png" /> >>> </mets:file> >>> <mets:file ID="ex07__FILE01_MIN" MIMETYPE="image/png" >>> SIZE="3976"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/smaller/image/01.png" /> >>> </mets:file> >>> <mets:file ID="ex07__FILE02_MIN" MIMETYPE="image/png" >>> SIZE="6472"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/smaller/image/02.png" /> >>> </mets:file> >>> </mets:fileGrp> >>> >>> <!-- Die weiteren (optionalen) fileGrps folgen hier --> >>> </mets:fileSec> >>> >>> <!-- Physische StructMap --> >>> <mets:structMap TYPE="PHYSICAL"> >>> <mets:div TYPE="physSequence" /> >>> </mets:structMap> >>> </mets:mets> >>> >>> >>> >>> >>> fileSec Anforderung 4: Dateigruppen >>> >>> 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. >>> >>> >>> Beispiel 8: Die vom DFG-Viewer unterstützten <FileGrp> >>> Elemente >>> >>> >>> >>> <mets:mets xmlns:xlink="http://www.w3.org/1999/xlink"> >>> <mets:fileSec> >>> >>> <!-- Enthält ALLE Images in der beim Start des Viewers >>> angezeigten >> Version --> >>> <mets:fileGrp USE="DEFAULT"> >>> <mets:file ID="ex08__FILE00_DEF" MIMETYPE="image/jpeg" >>> SIZE="51654"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/default/image/00.jpg" /> >>> </mets:file> >>> <mets:file ID="ex08__FILE01_DEF" MIMETYPE="image/jpeg" >>> SIZE="46566"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/default/image/01.jpg" /> >>> </mets:file> >>> </mets:fileGrp> >>> >>> <!-- Enthält ALLE Images in einer kleineren Version --> >>> <mets:fileGrp USE="MIN"> >>> <mets:file ID="ex08__FILE00_MIN" MIMETYPE="image/jpeg" >>> SIZE="23630"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/smaller/image/00.jpg" /> >>> </mets:file> >>> <mets:file ID="ex08__FILE01_MIN" MIMETYPE="image/jpeg" >>> SIZE="19233"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/smaller/image/01.jpg" /> >>> </mets:file> >>> </mets:fileGrp> >>> >>> <!-- Enthält ALLE Images in der größt möglichen Version --> >>> <mets:fileGrp USE="MAX"> >>> <mets:file ID="ex08__FILE00_MAX" MIMETYPE="image/jpeg" >>> SIZE="643630"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/bigger/image/00.jpg" /> >>> </mets:file> >>> <mets:file ID="ex08__FILE01_MAX" MIMETYPE="image/jpeg" >>> SIZE="591244"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/bigger/image/01.jpg" /> >>> </mets:file> >>> </mets:fileGrp> >>> >>> <!-- Enthält ALLE Images in einer kleinen Vorschau-Version --> >>> <mets:fileGrp USE="THUMBS"> >>> <mets:file ID="ex08__FILE00_THB" MIMETYPE="image/png" >>> SIZE="8234"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/thumb/image/00.png" /> >>> </mets:file> >>> <mets:file ID="ex08__FILE01_THB" MIMETYPE="image/png" >>> SIZE="8775"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/thumb/image/01.png" /> >>> </mets:file> >>> </mets:fileGrp> >>> >>> <!-- Enthält zum Download angebotenen Dateien, >>> beispielsweise PDF- >> oder TIFF-Dateien --> >>> <mets:fileGrp USE="DOWNLOAD"> >>> <mets:file ID="ex08__FILE00_DWL" MIMETYPE="application/pdf" >>> SIZE="12057"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/pdf/00.pdf" /> >>> </mets:file> >>> <mets:file ID="ex08__FILE01_DWL" MIMETYPE="application/pdf" >>> SIZE="13001"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/pdf/01.pdf" /> >>> </mets:file> >>> </mets:fileGrp> >>> </mets:fileSec> >>> >>> <!-- Physische StructMap --> >>> <mets:structMap TYPE="PHYSICAL"> >>> <mets:div TYPE="physSequence" /> >>> </mets:structMap> >>> </mets:mets> >>> >>> >>> >>> >>> Structural Map >>> >>> >>> structMap Anforderung 1: Bibliographisches Dokumentenmodell >>> >>> 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. >>> >>> >>> Beispiel 9: <structMap> beim Bibliographischen >>> Dokumentenmodell >>> >>> >>> >>> <mets:mets> >>> <mets:structMap TYPE="LOGICAL"> >>> <mets:div DMDID="DMD_00" TYPE="Monograph" /> >>> </mets:structMap> >>> </mets:mets> >>> >>> >>> >>> >>> structMap Anforderung 2: Seitenbasiertes Dokumentenmodell >>> >>> 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). >>> >>> >>> Beispiel 10: <structMap> der physischen Struktur >>> >>> >>> >>> <mets:mets> >>> <!-- Logische StructMap --> >>> <mets:structMap TYPE="LOGICAL"> >>> <mets:div DMDID="DMD_00" ID="ex10__LOG_00" TYPE="Monograph" /> >>> </mets:structMap> >>> >>> <!-- Physische StructMap --> >>> <mets:structMap TYPE="PHYSICAL"> >>> <mets:div ID="ex10__PHYS_00" TYPE="physSequence"> >>> <mets:div >>> CONTENTIDS="urn:nbn:de:gbv-7-gdz-12345678-ex10__PHYS_01" >>> ID="ex10__PHYS_01" ORDER="1" ORDERLABEL="I" TYPE="page" /> >>> <mets:div >>> CONTENTIDS="urn:nbn:de:gbv-7-gdz-12345678-ex10__PHYS_02" >>> ID="ex10__PHYS_02" ORDER="2" ORDERLABEL="II" TYPE="page" /> >>> <mets:div >>> CONTENTIDS="urn:nbn:de:gbv-7-gdz-12345678-ex10__PHYS_03" >>> ID="ex10__PHYS_03" ORDER="3" ORDERLABEL="III" TYPE="page" /> >>> <mets:div >>> CONTENTIDS="urn:nbn:de:gbv-7-gdz-12345678-ex10__PHYS_04" >>> ID="ex10__PHYS_04" ORDER="4" ORDERLABEL="1" TYPE="page" /> >>> <mets:div >>> CONTENTIDS="urn:nbn:de:gbv-7-gdz-12345678-ex10__PHYS_05" >>> ID="ex10__PHYS_05" ORDER="5" ORDERLABEL="2" TYPE="page" /> >>> </mets:div> >>> </mets:structMap> >>> </mets:mets> >>> >>> >>> >>> >>> structMap Anforderung 3: Komplexes Dokumentenmodell >>> >>> 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). >>> >>> >>> Beispiel 11: Verschachtelung der <structMap> Elemente der >>> logische Dokumentstruktur >>> >>> >>> >>> <mets:mets> >>> <mets:structMap TYPE="LOGICAL"> >>> <!-- Logisches Strukturelement für die Monographie --> >>> <mets:div CONTENTIDS="urn:nbn:de:gbv-7-gdz-12345678-" >>> DMDID="DMD_00" ID="ex11__LOG_00" TYPE="Monograph"> >>> >>> <!-- Logisches Strukturelement für das erste Kapitel mit >> Unterteilung --> >>> <mets:div >>> CONTENTIDS="urn:nbn:de:gbv-7-gdz-12345678-ex11__LOG_01" DMDID="DMD_01" >>> ID="ex11__LOG_01" TYPE="Chapter"> >>> <!-- Logisches Strukturelement für ein >>> Inhaltsverzeichnis --> >>> <mets:div >>> CONTENTIDS="urn:nbn:de:gbv-7-gdz-12345678-ex11__LOG_02" >>> ID="ex11__LOG_02" TYPE="Illustration" /> >>> <!-- Logisches Strukturelement für eine Textpassage --> >>> <mets:div >>> CONTENTIDS="urn:nbn:de:gbv-7-gdz-12345678-ex11__LOG_03" >>> ID="ex11__LOG_03" TYPE="TextSection" /> >>> </mets:div> >>> >>> <!-- Logische Strukturelemente für zwei weitere Kapitel ohne >> weitere Unterteilung --> >>> <mets:div >>> CONTENTIDS="urn:nbn:de:gbv-7-gdz-12345678-ex11__LOG_04" DMDID="DMD_02" >>> ID="ex11__LOG_04" TYPE="Chapter" /> >>> <mets:div >>> CONTENTIDS="urn:nbn:de:gbv-7-gdz-12345678-ex11__LOG_05" >>> ID="ex11__LOG_05" TYPE="Chapter" /> >>> </mets:div> >>> </mets:structMap> >>> </mets:mets> >>> >>> >>> >>> >>> structMap Anforderung 4: Behandlung von Zeitschriften und >>> Mehrbändigen Werken im DFG-Viewer >>> >>> 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. >>> >>> >>> Beispiel 12: Logische StructMap für einen Band und eine >>> übergeordnete Zeitschrift (der Ãœbersichtlichkeit halber >>> ohne CONTENTIDS) >>> >>> >>> >>> <!-- Logische StructMap für einen Band --> >>> <mets:mets xmlns:xlink="http://www.w3.org/1999/xlink"> >>> <mets:structMap TYPE="LOGICAL"> >>> <mets:div TYPE="Periodical"> >>> <!-- Der METS-Pointer referenziert die METS-Datei der >>> Zeitschrift >> / des Mehrbändigen Werkes --> >>> <mets:mptr LOCTYPE="URL" >>> xlink:href="http://link/to/mets/file/periodical" /> >>> >>> <!-- Hier beginnt die oben bereits besprochene >>> Beschreibung des >> einzelnen Bandes --> >>> <mets:div DMDID="DMD_00" ID="ex12__LOG_00" TYPE="Volume"> >>> <mets:div DMDID="DMD_01" ID="ex12__LOG_01" TYPE="Issue"> >>> <mets:div ID="ex12__LOG_02" TYPE="Article" /> >>> <mets:div ID="ex12__LOG_03" TYPE="Article" /> >>> </mets:div> >>> <mets:div DMDID="DMD_01" ID="ex12__LOG_04" TYPE="Issue" /> >>> <mets:div ID="ex12__LOG_05" TYPE="Issue" /> >>> </mets:div> >>> </mets:div> >>> </mets:structMap> >>> </mets:mets> >>> >>> <!-- Logische StructMap für eine übergeordnete Zeitschrift --> >>> <mets:mets xmlns:xlink="http://www.w3.org/1999/xlink"> >>> <mets:structMap TYPE="LOGICAL"> >>> <mets:div DMDID="DMD_00" ID="ex13__LOG0_00" TYPE="Periodical"> >>> <mets:div TYPE="Volume"> >>> <!-- Ein METS-Pointer auf den ersten Band der >>> Zeitschrift --> >>> <mets:mptr LOCTYPE="URL" >>> xlink:href="http://link/to/mets/file/1st/volume/mets.xml" /> >>> </mets:div> >>> <mets:div TYPE="Volume"> >>> <!-- Ein METS-Pointer auf den zweiten Band der >>> Zeitschrift --> >>> <mets:mptr LOCTYPE="URL" >>> xlink:href="http://link/to/mets/file/2nd/volume/mets.xml" /> >>> </mets:div> >>> <mets:div TYPE="Volume"> >>> <!-- Ein METS-Pointer auf den dritten Band der >>> Zeitschrift --> >>> <mets:mptr LOCTYPE="URL" >>> xlink:href="http://link/to/mets/file/3rd/volume/metx.xml" /> >>> </mets:div> >>> </mets:div> >>> </mets:structMap> >>> </mets:mets> >>> >>> >>> >>> >>> structMap Anforderung 5: Metadaten für Strukturelemente >>> >>> 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. >>> >>> >>> structMap Anforderung 6: Verweise auf Dateien aus der >>> physischen Struktur >>> >>> 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. >>> >>> >>> Beispiel 14: <structMap> der physischen Struktur >>> >>> >>> >>> <mets:mets xmlns:xlink="http://www.w3.org/1999/xlink"> >>> <!-- FileGroup als Beispiel für den FilePointer in der >>> physischen >> Structmap --> >>> <mets:fileSec> >>> <mets:fileGrp USE="DOWNLOAD"> >>> <mets:file ID="ex14__FILE00_Monograph" >>> MIMETYPE="application/pdf" SIZE="1643630"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/monograph.pdf" /> >>> </mets:file> >>> </mets:fileGrp> >>> </mets:fileSec> >>> >>> <!-- Physische StructMap --> >>> <mets:structMap TYPE="PHYSICAL"> >>> <mets:div TYPE="physSequence"> >>> <!-- FilePointer auf das PDF der physSequence / der >>> Monographie -- >>> >>> <mets:fptr FILEID="ex14__FILE00_Monograph" /> >>> >>> <!-- Aus jeder File-Group werden hier die verschiedenen >> Auflösungen / Formate eines jeden Files referenziert --> >>> <mets:div ID="ex14__PHY_00" ORDER="1" ORDERLABEL="I" >>> TYPE="page"> >>> <mets:fptr FILEID="ex08__FILE00_DEF" /> >>> <mets:fptr FILEID="ex08__FILE00_MIN" /> >>> <mets:fptr FILEID="ex08__FILE00_MAX" /> >>> <mets:fptr FILEID="ex08__FILE00_THB" /> >>> <mets:fptr FILEID="ex08__FILE00_DWL" /> >>> </mets:div> >>> <mets:div ID="PHYS09_01" ORDER="2" ORDERLABEL="II" >>> TYPE="page"> >>> <mets:fptr FILEID="ex08__FILE01_DEF" /> >>> <mets:fptr FILEID="ex08__FILE01_MIN" /> >>> <mets:fptr FILEID="ex08__FILE01_MAX" /> >>> <mets:fptr FILEID="ex08__FILE01_THB" /> >>> <mets:fptr FILEID="ex08__FILE01_DWL" /> >>> </mets:div> >>> </mets:div> >>> </mets:structMap> >>> </mets:mets> >>> >>> >>> >>> >>> structMap Anforderung 7: Verweise auf Dateien aus der >>> logischen Struktur >>> >>> 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. >>> >>> >>> Beispiel 15: StructMap der logischen Struktur mit Verweis >>> auf eine PDF-Datei eines Artikels >>> >>> >>> >>> <mets:mets xmlns:xlink="http://www.w3.org/1999/xlink"> >>> <!-- FileGroup als Beispiel für den FilePointer in der logischen >> Structmap --> >>> <mets:fileSec> >>> <mets:fileGrp USE="DOWNLOAD"> >>> <!-- Verweis auf die PDF-Datei des Kapitels --> >>> <mets:file ID="ex15__FILE01_Chapter" >>> MIMETYPE="application/pdf" SIZE="47676"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/chapter/01.pdf" /> >>> </mets:file> >>> </mets:fileGrp> >>> </mets:fileSec> >>> >>> <!-- Logische StructMap --> >>> <mets:structMap TYPE="LOGICAL"> >>> <mets:div TYPE="Periodical"> >>> <!-- Der METS-Pointer referenziert die METS-Datei der >>> Zeitschrift >> / des Mehrbändigen Werkes --> >>> <mets:mptr LOCTYPE="URL" >>> xlink:href="http://link/to/mets/file/periodical" /> >>> >>> <!-- Hier beginnt die oben bereits besprochene >>> Beschreibung des >> einzelnen Bandes --> >>> <mets:div DMDID="DMD_00" ID="ex15__LOG_00" TYPE="Volume"> >>> <mets:div DMDID="DMD_01" ID="ex15__LOG_01" TYPE="Issue"> >>> <mets:div ID="ex15__LOG_02" TYPE="Article"> >>> <mets:fptr FILEID="ex15__FILE01_Chapter" /> >>> </mets:div> >>> <mets:div ID="ex15__LOG_03" TYPE="Article" /> >>> </mets:div> >>> <mets:div DMDID="DMD_01" ID="ex15__LOG_04" TYPE="Issue" /> >>> <mets:div ID="ex15__LOG_05" TYPE="Issue" /> >>> </mets:div> >>> </mets:div> >>> </mets:structMap> >>> </mets:mets> >>> >>> >>> >>> >>> structMap Anforderung 8: Mehrfache Verknüpfungen aus einer >>> <div> Sektion >>> >>> 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. >>> >>> >>> structMap Anforderung 9: Verknüpfungen in Dateien >>> >>> 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. >>> >>> >>> Beispiel 16: Verweis in eine Datei mittels <mets:area> >>> >>> >>> >>> <mets:mets xmlns:xlink="http://www.w3.org/1999/xlink"> >>> <mets:fileSec> >>> <!-- Eine beispielhafte fileGrp zur Nutzung von <mets:area> --> >>> <mets:fileGrp USE="AREA"> >>> <mets:file ID="ex16__FILE00_ARE" MIMETYPE="text/xml" >>> SIZE="6523"> >>> <mets:FLocat LOCTYPE="URL" >>> xlink:href="http://link/to/xml/tei/file" /> >>> </mets:file> >>> </mets:fileGrp> >>> </mets:fileSec> >>> >>> <!-- Physische Structmap --> >>> <mets:structMap TYPE="PHYSICAL"> >>> <mets:div TYPE="physSequence"> >>> <mets:div ID="ex16__PHY_00" ORDER="3" ORDERLABEL="III" >>> TYPE="page"> >>> <!-- Verweis in eine Datei hinein. Dabei wird der >>> eigentliche >> Inhalt über die IDRef-Werte in den Attributen BEGIN und END >> definiert --> >>> <mets:fptr> >>> <mets:area BEGIN="TEIID_24" BETYPE="IDREF" END="TEIID_63" >>> FILEID="ex16__FILE00_ARE" /> >>> </mets:fptr> >>> </mets:div> >>> </mets:div> >>> </mets:structMap> >>> </mets:mets> >>> >>> >>> >>> >>> Strukturverknüpfungen (structLink) >>> >>> >>> structLink Anforderung 1: Verknüpfung der logischen und >>> physischen Struktur >>> >>> 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. >>> >>> >>> Beispiel 17: Verknüpfung zwischen logischer und physischer >>> Struktur >>> >>> >>> >>> <mets:mets xmlns:xlink="http://www.w3.org/1999/xlink"> >>> <!-- Logische StructMap --> >>> <mets:structMap TYPE="LOGICAL"> >>> <mets:div ID="ex17__LOG_00" TYPE="Monograph"> >>> <mets:div ID="ex17__LOG_01" TYPE="Chapter"> >>> <mets:div ID="ex17__LOG_02" TYPE="Chapter" /> >>> <mets:div ID="ex17__LOG_03" TYPE="Chapter" /> >>> </mets:div> >>> </mets:div> >>> </mets:structMap> >>> >>> <!-- Physische StructMap --> >>> <mets:structMap TYPE="PHYSICAL"> >>> <mets:div ID="ex17__PHY_00" TYPE="physSequence"> >>> <mets:div ID="ex17__PHY_01" ORDER="1" ORDERLABEL="III" >>> TYPE="page" /> >>> <mets:div ID="ex17__PHY_02" ORDER="2" ORDERLABEL="1" >>> TYPE="page" /> >>> <mets:div ID="ex17__PHY_03" ORDER="3" ORDERLABEL="2" >>> TYPE="page" /> >>> <mets:div ID="ex17__PHY_04" ORDER="4" ORDERLABEL="3" >>> TYPE="page" /> >>> <mets:div ID="ex17__PHY_05" ORDER="5" ORDERLABEL="4" >>> TYPE="page" /> >>> </mets:div> >>> </mets:structMap> >>> >>> <!-- Hier werden die logischen und die physischen >>> Strukturelemente >>> verknüpft --> >>> <mets:structLink> >>> <!-- Verknüpfung zwischen Monograph und Physical Sequence --> >>> <mets:smLink xlink:from="ex17__LOG_00" >>> xlink:to="ex17__PHY_00" /> >>> <!-- Verknüpfung zwischen Kapitel 1 und Seiten --> >>> <mets:smLink xlink:from="ex17__LOG_01" >>> xlink:to="ex17__PHY_02" /> >>> <mets:smLink xlink:from="ex17__LOG_01" >>> xlink:to="ex17__PHY_03" /> >>> <mets:smLink xlink:from="ex17__LOG_01" >>> xlink:to="ex17__PHY_04" /> >>> <mets:smLink xlink:from="ex17__LOG_01" >>> xlink:to="ex17__PHY_05" /> >>> <!-- Verknüpfung zwischen Kapitel 2 und Seiten --> >>> <mets:smLink xlink:from="ex17__LOG_02" >>> xlink:to="ex17__PHY_03" /> >>> <mets:smLink xlink:from="ex17__LOG_02" >>> xlink:to="ex17__PHY_04" /> >>> <!-- Verknüpfung zwischen Kapitel 3 und Seiten --> >>> <mets:smLink xlink:from="ex17__LOG_03" >>> xlink:to="ex17__PHY_04" /> >>> <mets:smLink xlink:from="ex17__LOG_03" >>> xlink:to="ex17__PHY_05" /> >>> </mets:structLink> >>> </mets:mets> >>> >>> >>> >>> >>> structLink Anforderung 2: Vererbung von >>> Strukturverknüpfungen >>> >>> 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. >>> >>> >>> Beispiel 18: Vererbung der Verknüpfungen auf physische >>> Strukturen für das Seitenbasierte Dokumentenmodell >>> >>> >>> >>> <mets:mets xmlns:xlink="http://www.w3.org/1999/xlink"> >>> <!-- Logische StructMap --> >>> <mets:structMap TYPE="LOGICAL"> >>> <mets:div ID="ex18__LOG_00" TYPE="Monograph" /> >>> </mets:structMap> >>> >>> <!-- Physische StructMap --> >>> <mets:structMap TYPE="PHYSICAL"> >>> <mets:div ID="ex18__PHYS_00" TYPE="physSequence"> >>> <mets:div ID="ex18__PHYS_01" ORDER="1" ORDERLABEL="III" >>> TYPE="page" /> >>> <mets:div ID="ex18__PHYS_02" ORDER="2" ORDERLABEL="1" >>> TYPE="page" /> >>> <mets:div ID="ex18__PHYS_03" ORDER="3" ORDERLABEL="2" >>> TYPE="page" /> >>> <mets:div ID="ex18__PHYS_04" ORDER="4" ORDERLABEL="3" >>> TYPE="page" /> >>> <mets:div ID="ex18__PHYS_05" ORDER="5" ORDERLABEL="4" >>> TYPE="page" /> >>> </mets:div> >>> </mets:structMap> >>> >>> <!-- Hier werden die logischen und die physischen >>> Structurelemente >> verknüpft --> >>> <mets:structLink> >>> <!-- Verknüpfung zwischen Monograph und physical Sequence --> >>> <mets:smLink xlink:from="ex18__LOG_00" >>> xlink:to="ex18__PHY_00" /> >>> </mets:structLink> >>> </mets:mets> >>> >>> >>> >>> >>> Technical Requirements >>> >>> >>> Inhaltsdateien (Content Files) >>> >>> >>> Images >>> >>> 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. >>> >>> >>> Volltexte >>> >>> 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.