-----Ursprüngliche Nachricht----- Von: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg- viewer.de] Im Auftrag von Thomas Staecker Gesendet: Donnerstag, 18. September 2008 07:42 An: technik(a)dfg-viewer.de Betreff: [DFG-Viewer] Frage zur Zweiseitigkeit Lieber Herr Meyer, ich habe noch einmal über die Frage der Zweiseitigkeit nachgedacht. Wenn wir unterstellen, dass alle Bücher einen Rand hätten und nicht beschnitten sind, könnte man auf der Basis der Tatsache, dass ein Buch zum Falz hin an die Bildgrenze anschliesst, doch eindeutig definieren, dass die Seite verso oder recto ist (Farbwert heller oder dunkler als der Rand). Ist der Falz links, ist es recto, ist der Falz rechts, ist es verso. So könnte man, wenn man zwei Bildschirmplätze für die rechte und linke Seite eines Buches vorsieht, immer eindeutig sagen, wo es hingehört. Wenn z.B. zwei linke Fälze aufeinander folgen (Eingeklebte Tafel, deren Rückseite nicht aufgenommen wurde), bliebe ein Bildschirmplatz leer. Halten Sie so etwas perspektivisch für machbar? Für WF würde ich es mal versuchen. Ich bin mir aber unsicher, ob man bei allen Einlieferern Rand um das Objekt unterstellen kann. Ist aber sicherlich nicht vordringlich. Viele Gruesse, Ihr Th. Stäcker

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.

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:

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.

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.

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.

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. > > *********************************************************************** > **

...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. >> >> *********************************************************************** >> **

Lieber Herr Staecker, prinzipiell sollte das machbar sein. Allerdings sehe ich zwei Probleme: Erstens teile ich Ihre Zweifel, ob wirklich jede Einrichtung unbeschnittene Images mit Rand liefert. Außerdem könnten Wasserzeichen, Fußleisten, Farbkeile, etc. die Analyse erschweren. Man wird kaum Bildkoordinaten definieren können, die bei jedem beliebigen Image zuverlässig den Rand treffen. Im schlimmsten Fall ergibt die Analyse vier verschiedene Farbwerte (oben wurde der Rand getroffen, links der Falz, unten die Fußleiste und rechts der Farbkeil) - welche Schlüsse soll der Viewer daraus ziehen? (Einmal abgesehen davon, dass die Ränder selten einfarbig sind, sondern meist Farbverläufe, Muster, Schatten, etc. beinhalten.) Zweitens müsste der DFG-Viewer dann jedes einzelne Image vor der Anzeige analysieren. Dazu müsste er jedes Image abrufen (was er jetzt ja nicht tut). Ich fürchte, das würde nicht performant genug funktionieren. Für lokale Präsentationssysteme sieht die Sache natürlich anders aus, denn da liegen die Images ja bereits vor und können ohne zusätzliche Übertragung analysiert werden. Viele Grüße Sebastian Meyer -- ___________________________________________________ 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/ ___________________________________________________