Re: [DFG-Viewer] zvdd/DFG-Viewer METS Profil - Version 2.0 - DV-Technik - SLUB-Domäne

25 Nov 2008

Lieber Herr Meyer,

...
  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). 
Prima. Damit kann ich gut leben - und das bietet genau die Flexibilität, die wir m.E. an
dieser Stelle brauchen.

...
  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. 
Das stimmt. Aber ich schlage mich - wie Herr Funk - auch immer noch mit diesem
"obersten DIV" etwas herum. Spontan habe ich noch keinen rechten Vorschlag.
Vielleicht hat ja jemand anderes eine zündende Idee?

...
  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. 
Fände ich wichtig. Die Entwurfsfassung der Praxisregeln macht sich ja für dieses Konzept
berechtigt sehr stark. Soweit ich es überblicken kann, sehen das auch sehr viele Projekte
so, die entweder den URN-Granular-Ansatz hierzu aufgreifen oder eine PURL-basierte Lösung
für diesen Zweck nutzen. Unterm Strich kommt dabei, gleich welcher technische Ansatz
genutzt wird, das gleiche raus: Einzelseiten sind der Bezugspunkt der Referenzierung im
wissenschaftlichen Kontext. Wenn ein Projekt das liefern kann, sollte es der Viewer (als
primäre Anzeigeform von Digitalisaten aus DFG-Projekten) auch anzeigen können.

...
  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?) 
Tja, jetzt sind sie bei einem wichtigen Punkt, den die Nationalbibliotheken bislang noch
nicht gelöst haben: es gibt aktuell keinen Metaresolver und keine Resolving-Registry.
Soweit ich davon Kenntnis habe, arbeiten die Nationalbibliotheken aber an einer
entsprechenden Lösung - warten können wir darauf aber nicht. Mein Vorschlag wäre deshalb:
lösen Sie zunächst schlichtweg zum DNB-Resolver auf. Damit haben Sie Deutschland,
Österreich und die Schweiz "eingefangen" (deren Namensräume verwaltet die DNB).
Wenn dann - in zehn Jahren? - die ersten Digitalisate aus italienischen oder spanischen
Bibliotheken mit dem DFG-Viewer angezeigt werden sollen, haben sich die
Nationalbibliotheken hoffentlich bereits verständigt. ;) Wenn nicht, dann kann man die
Namensräume auch im Viewer pragmatisch nachziehen. Technisch aufwendig wäre das nicht.

...
  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. :) 
Tja, das Elend, wenn man Webseiten barrierefrei gestalten will. Da wünsche ich Ihrem
Designer: allen Erfolg!

Beste Grüße,
Kay Heiligenhaus