Re: [DFG-Viewer] Frage zur Zweiseitigkeit

...tja, soviel zu METS ;-) Im Ernst, könnte das Problem nicht auch dadurch bedingt sein, dass mit PHP simple_xml statt mit DOM gearbeitet wird und hier dann alles in PHP arrays verschachtelt werden muss, was dann an besagte Grenzen stößt? Das Laden von DOM dauert zwar länger, dafür kann man aber hinterher mit den XPATH Ausdruecken, von denen Herr Enders spricht, in der Tat leichter und flexibler zugreifen (z.B. mit id()). In meinem ersten Entwurf des Viewers hatte ich das so gemacht. Das aber nur so als Gedanke.

Viele Gruesse, Th. Staecker Meyer, Sebastian schrieb: > Hallo Markus, > >>> 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? > > Es sind aber 4 XPATH-Ausdrücke pro logischem Strukturelement und > zusätzlich eine "Rückwärtsauflösung" des aktuellen Images zum > dazugehörigen Strukturelement. Ersteres brauche ich zum Aufbau der > Navigation, die jedes (nicht nur das aktuell betrachtete) logische > Strukturelement beinhalten und jeweils mit einem Image verknüpfen muss. > Zweiteres brauche ich, um in der Navigation das aktuelle Element > hervorheben zu können. Das ist trotz Caching bei mehreren parallelen > Zugriffen und umfangreichen Dokumenten ein ziemlicher Performance-Killer > (für ein einzelnes, durchschnittlich großes Dokument ist das natürlich > kein Problem, aber ein Webdienst sollte ja mehr als nur einen Nutzer > gleichzeitig bedienen können). > >> 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 erstelle kein eigenes Datenmodell, sondern erzeuge ein Array, in dem > die für die Navigation notwendigen Daten aus den verschiedenen > METS-Sektionen (logische und physische Strukturelemente, Image-Links, > Sortierung und Hierarchie, Anzeigetitel) enthalten sind. Das Array wird > dann in einer Session-Variablen gecached und daraus wird die Navigation > erzeugt. > >>> 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.... > > Naja, mindestens zwei weitere XPATH-Abfragen, wenn wir von einer > Doppelseitenansicht sprechen. Ich muss ja für beide in Frage kommenden > Images verifizieren, ob sie recto oder verso sind, und im Zweifel sogar > noch ein drittes Image einbeziehen. > >> 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? > > 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. >> >> *********************************************************************** >> **