Liebe Kolleginnen und Kollegen, Gut, gut, ich gebe mich ja schon geschlagen. :) Trotzdem würde ich aber auch nicht formulieren, dass Downloads des Gesamtwerks _immer_ in der logischen Struktur verlinkt werden müssen. Bei PDFs hat das durchaus einen Sinn, vorstellbar sind aber beispielsweise auch ZIP-Archive der Images und das wäre eindeutig eine physische Struktur. Aus Sicht des Viewers sehe ich da auch kein Problem: wenn es Downloads der physischen und der logischen Gesamtstruktur gibt, werden eben beide zum Download angeboten (perspektivisch jedenfalls, bislang sind individuelle Downloads ja sowieso noch nicht implementiert). Wer dann in beiden Fällen dasselbe PDF verlinkt hat, findet selbiges eben zweimal im Viewer. In der jetzigen Form können wir ja definieren, dass die logische Struktur bevorzugt behandelt wird: ist dort ein PDF des Gesamtwerks verlinkt, wird dieses hinter den Button im Viewer gehängt, andernfalls wird in der physischen Struktur nach einem entsprechenden PDF gesucht. Das würde auch Einrichtungen wie uns die Möglichkeit geben, das Gesamt-PDF weiterhin als physische Struktur zu verlinken, solange wir darin keine Inhaltsverzeichnisse, Titelblätter oder Metadaten einbinden (denn dann ist es wirklich nicht mehr als die Sequenz der Einzelseiten und gehört nicht in die logische Struktur). Ein Problem gibt es da nur: in der logischen Struktur ist nicht eindeutig definiert, wie denn die relevante übergeordnete Struktur identifiziert werden kann, deren PDF-Version zum Download angeboten werden soll. Das oberste <div> kann es nicht sein, da das bei mehrbändigen Werken und Zeitschriften keine PDF-Entsprechung hat. Anhand des TYPE-Attributs lässt es sich auch nur bedingt unterscheiden, da ja nicht zwingend vorgeschrieben ist, dass pro Monographie, Band, Zeitschriftenheft, etc. eine eigene METS-Datei (mit entsprechendem Gesamt-PDF-Download) vorhanden sein muss. Manch einer steckt vielleicht jedes Kapitel einer Monographie in eine eigene METS-Datei mit entsprechendem Gesamt-PDF. Dann wäre die Identifizierung nach TYPE="monograph" nicht möglich. Außerdem würden wir damit die Strukturdatenunabhängigkeit des DFG-Viewers aufgeben, weil er Downloads dann nur noch verknüpfen könnte, wenn die Strukturen entsprechend der VD16/17-Typologie benannt wurden. In der physischen Struktur ist die Sache einfacher: dort ist es immer das oberste <div> der Hierarchie. Es ist kein Bug, sondern ein fehlendes Feature. :) Aber Sie haben recht: bislang zeigt der Viewer nur die persistenten Adressen des Gesamtwerks an. Perspektivisch sollte er natürlich auch die der aktuellen Einzelseite anzeigen. Wobei ich das nicht als Aufgabe des DFG-Viewers sehe, falls Sie das damit sagen wollten. Der Viewer sollte den Identifier schlicht anzeigen und gegebenenfalls mit den entsprechenden Resolvern verknüpfen. (Gibt es einen internationalen Resolver für URNs? Eine automatische Verknüpfung mit dem DNB-Resolver funktioniert doch nur bei URNs des deutschen Namensraums, oder?) Ja, das liegt an der mangelnden CSS2-Unterstützung des IE7: um semantisch korrektes Markup zu erzeugen, haben wir auf eine Tabelle verzichtet und dafür per CSS der Image-Ansicht und der Navigation jeweils das Verhalten von Tabellenspalten zugewiesen, damit sie nicht umbrechen. Leider interpretiert der IE7 das nicht korrekt. Unser Webdesigner weiß bescheid und brütet an einer Lösung. :) 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 Kay Heiligenhaus > Gesendet: Sonntag, 16. November 2008 13:09 > An: technik(a)dfg-viewer.de > Betreff: Re: [DFG-Viewer] zvdd/DFG-Viewer METS Profil - Version 2.0 > > Lieber Herr Funk, lieber Herr Meyer, liebe Kolleginnen und Kollegen, > > zunächst meinen besten Dank für die Erstellung des METS-Profils. Ich hatte > noch nicht die Zeit, mir das im Detail anzuschauen, liefere aber meine > Anmerkungen nach entsprechender Lektüre noch nach. Kurz aber zu den noch > offenen Fragen: > > > 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. > > Das haben wir analog gemacht und ich denke, das ist so auch sinnvoll. > > > 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? > > Die zvdd-Strukturtypen waren für den Viewer noch nie Pflicht. Wenn > Strukturtypen codiert werden, dann nach dem Schema, das unter > > http://dfg-viewer.de/profil-der-strukturdaten/ > > beschrieben und von den beteiligten Einrichtungen ja auch verabschiedet wurde. > zvdd muß diese Typen auf das eigene Typsystem mappen (die entsprechenden > Mappingregeln sind auf der o.g. Seite ja auch genannt). > > > 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. > > Nach meinem Verständnis müßten dann die unter o.g. Adresse angegebenen dt. > Bezeichnungen verwendet werden (wenn der Viewer gerade in einem anderen > "Sprachmodus" ist, müßten entsprechende Übersetzungen angezeigt werden). > > > 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. > > Sehe ich auch so. > > > (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. > > Eine metaphysische Frage. ;) - - - Nein, ich sehe das ebenfalls so. > > > 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) > > Da sehe ich noch etwas Diskussionsbedarf. Wir testen aber auch gerade, wie wir > unsere Daten modellieren, um ein gewünschtes Ergebnis zu erzielen. > > Kurz noch eine abschließende Frage: Wir hatten uns ja darauf verständigt, daß > auch Einzelseiten persistent adressiert werden _können_. Ein Beispiel hierfür > wäre: > > <mets:structMap TYPE="PHYSICAL" > > <mets:div ID="phys582" TYPE="physSequence" > > <mets:div ID="phys52047" TYPE="page" LABEL="[Seite 1]" > CONTENTIDS="urn:nbn:de:gbv:3-100002425-p0001-0" ORDER="1" > > ... > </mets:structMap> > > Wichtig fände ich in diesem Zusammenhang auch noch, daß dem Nutzer kurz > erläutert wird, was es mit solchen Identifiern auf sich hat. Es hat sich ja in > verschiedenen Diskussionskontexten gezeigt, daß das Konzept von URNs, PURLs > usw. in Nutzerkontexten (und auch in der bibliothekarischen Fachwelt) z.T. > weder bekannt noch verstanden worden ist. Hier ist wohl noch Aufklärungsarbeit > nötig. > > > Beste Grüße, > Kay Heiligenhaus