Re: [DFG-Viewer] Strukturelemente ohne Bilder werden in der Navigation nicht angezeigt.

Lieber Herr Scheffler, Genau so macht es der DFG-Viewer ja auch: wenn Sie blättern oder über die Drop-Down-Navigation direkt eine Seite anspringen, dann liegt dieser Navigation die physische Reihenfolge der Images zugrunde (also die Reihenfolge, die sich aus der physischen structMap ergibt). Die Strukturnavigation auf der rechten Seite ist aber etwas anderes, denn hier navigieren Sie nicht durch die physische Struktur, sondern durch die logische Struktur. Und um das gewährleisten zu können, muss der DFG-Viewer wissen, auf welcher Seite die jeweilige Struktur beginnt (denn dorthin verlinkt er den Eintrag) und über welche Seiten sie sich erstreckt (denn der jeweilige Eintrag wird optisch hervorgehoben, solange der Nutzer sich auf einer dieser Seiten befindet). Diese Informationen können aber eben nur über die structLinks ermittelt werden, weshalb sie explizit für jede logische Struktur angegeben werden müssen. Meines Erachtens ist hier wichtig, dass der DFG-Viewer eine Implementierung des Anwendungsprofils darstellt und nicht umgekehrt, d.h. das Anwendungsprofil stellt eine allgemeine Einigung auf ein gemeinsames Datenformat dar und nicht bloß eine Schnittstellendokumentation des DFG-Viewers. Viele Grüße Sebastian Meyer -- Sebastian Meyer Referatsleiter Digitale Bibliothek Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) 01054 Dresden Telefon: +49 351 4677-206 Telefax: +49 351 4677-711 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 Thomas Scheffler > Gesendet: Donnerstag, 25. November 2010 14:34 > An: dv-technik(a)dfg-viewer.de > Betreff: Re: [DFG-Viewer] Strukturelemente ohne Bilder werden in der > Navigation nicht angezeigt. > > Am 25.11.2010 13:56, schrieb Meyer, Sebastian: > >> Hier gibt es einen grundsätzlichen Widerspruch. Die PHYSICAL > >> structMap liefert die Reihenfolge der Digitalisate. > > > > Das ist nicht ganz richtig. Die physische structMap gibt die > > _physische_ Reihenfolge der Seiten wieder, die aber nicht zwingend > > der _logischen_ Reihenfolge entsprechen muss. Um bei Herrn Enders > > Zeitungsbeispiel zu bleiben: in der physischen structMap stünde die > > letzte Seite an letzter Stelle, in der logischen Reihenfolge eines > > dort beginnenden und im Inneren fortgesetzten Artikels dagegen an > > erster Stelle. Deshalb unterscheidet sich die Reihenfolge in der > > physischen structMap mitunter durchaus von der der structLinks. Man > > kann also nicht generell die Reihenfolge immer der physischen > > structMap entnehmen. Ein weiteres (auch in Deutschland vorkommendes) > > Beispiel wären Palimpseste: hier haben Sie sogar zwei logische > > Strukturen auf derselben physischen Struktur und somit auch zwei > > unterschiedliche logische Seitenfolgen. Diese können Sie nicht in der > > physischen structMap abbilden, da diese naturgemäß für zumindest eine > > logische Ebene (nämlich die ältere) die falsche Reihenfolge > > wiedergibt. > > Sehr geehrter Herr Meyer, > > > Die Diskussion über die Reihenfolge scheint mir also eher akademischer > Natur zu sein und in der DFG-Viewer-Praxis nicht relevant (ich sehe > gerne ein Beispiel im DFG-Viewer zu den Palimpsesten) sollte jetzt aber > nicht ablenken von der Diskussion über zu viel Redundanz im DFG-Viewer > METS-Profil. Dort sollte der Standardfall elegant gelöst, die Ausnahmen > von der Regel aber möglich sein.Da sehe ich keinen Widerspruch. > Wieso kann es keine implizite Zugehörigkeit von Seite zu Buch geben? > Jedem Kind ist klar, dass eine Seite, die zu einem Kapitel gehört, sehr > wohl auch eine Seite des Buches ist, nur dem DFG-Viewer nicht. Das ist > einfach unverständlich. > > Mit freundlichen Grüßen > > Thomas Scheffler > > -- > Thomas Scheffler > Friedrich-Schiller-Universität Jena > Thüringer Universitäts- und Landesbibliothek > Bibliotheksplatz 2 > 07743 Jena > Phone: ++49 3641 940027 > FAX: ++49 3641 940022