Re: [DFG-Viewer] Frage zur Zweiseitigkeit

Hallo Markus,

Ein neues Attribut sollten wir nicht einführen, da gebe ich dir recht. Aber das LABEL-Attribut ist doch eine gute Idee. Das wird in der physischen <structMap> noch nicht verwendet und könnte genau diesem Zweck dienen, in dem es normiert belegt wird.

Viele Grüße Sebastian -- ___________________________________________________ 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 Enders, Markus > Gesendet: Mittwoch, 24. September 2008 13:54 > An: technik(a)dfg-viewer.de > Betreff: Re: [DFG-Viewer] Frage zur Zweiseitigkeit > > Hi Sebastian, > > >die Angabe in METS unterzubringen halte ich auch für die beste Lösung. > > Allerdings würde ich ungern für jede einzelne Seite eine eigene > Metadaten-Sektion einbauen müssen, nur um dort die recto/verso-Angabe > unterbringen zu können. Lieber wäre mir ein Attribut, das im <div>- > Element der physischen <structMap> vergeben wird. > > Es stellen sich hier zwei konkrete Fragen: > > a) wie verhaelt sich die Recto/Verso Geschichte zu den Seitenzahlen. > Ergeben sich hier nicht gewisse Redundanzen? Und damit sind natuerlich > auch Inkonsistenzen nicht weit. Wie verfahren wir / verfaehrt der > Viewer wenn diese auftreten? Welches koennen dies ueberhaupt sein? > > b) Wie speichern wir diese Daten? Ich wuerde sie in einer eigenen > Metadatensection speichern, einfach weil diese erweiterbar ist - wer > weiss welche Daten wir noch fuer Seiten speichern muessen. Und soviel > Attribute gibt es nicht wirklich. > > Was ich mir vorstellen koennte, um die Anzahl der descriptive > Metadaten-Sektionen klein zu halten, eine Sektion fuer verso und eine > fuer rector zu definieren und von mehreren Seiten auf diese eine > Sektion zu referenzieren. Leider aber immer noch fuer jede Seite. > > >Ich merke gerade bei der Umsetzung der Strukturnavigation des DFG- > > Viewers, dass es enorm aufwändig ist, die logische Struktur mit den > konkreten Images zu verknüpfen: > > Im Prinzip sind die ja alle ueber IDs verknuepft. Was ist daran > aufwendig? Das sind 4 einfachste XPATH Ausdruecke. Dauert das wirklich > so lange oder ist das so performance intensiv? > > > erst muss per <structLink> die Verknüpfung zwischen logischer und > > physischer Struktur hergestellt werden und dann von dieser wiederum auf > die Files geschlossen werden. Es müssen also vier Bereiche der METS- > Datei komplett geparst werden, um am Ende ein Array aller logischen > Strukturelemente mit deren Images zu haben. > > Wozu brauche ich das denn? Ich weiss nicht, wie der Viewer > funktioniert. Es hoert sich so an, als ob du die METS Datei parst und > intern in ein eigenes Datenmodell queschst. Sonst wuesste ich jetzt > nicht, wozu ich beim blaettern ein Array aller logischen > Strukturelemente und deren Images brauche. Das kann ich doch bei jedem > blaettern mittels einfacher XPATH Anfrage neu ermitteln.... > > Ich gebe Dir allerdings Recht, dass es richtig effizient vermutlich > erst funktioniert, wenn die Dinger in ner Art XML-Datenbank stecken > wuerden - al seine Art Cache vielleicht interessant. > > > Wenn ich nun auch noch zu jedem Image eine Metadatensektion auslesen > > müsste, um die recto/verso-Angabe zu bekommen, würde der Aufbau noch > länger dauern. > > Eine weitere XPATH-Abfrage.... > > >Den Anzeigetitel der logischen Strukturelemente haben wir ja auch als > > Attribut in den <div>s der logischen <structMap> untergebracht, um > nicht jedes Mal die Metadatensektion auslesen zu müssen. > > Yepp - nur leider gibt es nicht mehr soviele Attribute. Wir braeuchten > ein neues, es sei denn wir wuerden LABEL nutzen. Das ist m.W. fuer die > Seite noch nicht belegt, oder? > > Und ganz ehrlich glaube ich, dass es hier schwierig wird, die Leute > davon zu ueberzeugen das div Element um ein neues Attribut zu > ergaenzen. METS setzt ja eher auf ein abstrakteres Datenmodell, wozu > halt auch die Verwendung von extension schemas gehoert. Fuer jeden > Anwendungszweck nen neues Attribut einzufuegen steht dem leider > entgegen. > > Ciao > Markus > > *********************************************************************** > *** > > Experience the British Library online at www.bl.uk > > The British Library's new interactive Annual Report and Accounts > 2007/08 : www.bl.uk/knowledge > > Help the British Library conserve the world's knowledge. Adopt a Book. > www.bl.uk/adoptabook > > The Library's St Pancras site is WiFi - enabled > > *********************************************************************** > ** > > The information contained in this e-mail is confidential and may be > legally privileged. It is intended for the addressee(s) only. If you > are not the intended recipient, please delete this e-mail and notify > the postmaster(a)bl.uk : The contents of this e-mail must not be > disclosed or copied without the sender's consent. > > The statements and opinions expressed in this message are those of the > author and do not necessarily reflect those of the British Library. The > British Library does not take any responsibility for the views of the > author. > > *********************************************************************** > **