25 Nov
2008
25 Nov
'08
12:44 p.m.
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