Am 25.11.2010 09:28, schrieb Meyer, Sebastian: Hallo, ich sehe das etwas anders und bemühe mal als Beispiel ein Dateisystem. Bei diesem stellen Ordner die logische Struktur dar. Jetzt kann es durchaus sein, dass ein Ordner weitere Unterordner enthält und selbst keine Dateien. Trotzdem enthält dieser Ordner jetzt implizit diese Dateien. Sie schlagen vor jede Datei auch noch einmal explizit in diesen Ordner zu kopieren, damit ein Dateimanager den Ordner dem Nutzer präsentiert. Genauso, wie das im Dateisystem ein Verschwendung von Speicherplatz wäre, bläht dies bei METS-Dateien diese nur unnötig mit redundanten Informationen auf. Es sollte eigentlich ein Leichtes für den DFG-Viewer sein, grundsätzlich die logische Struktur abzubilden, wie es einem Dateimanager möglich ist einen Ordner zu öffnen, der nur Unterordner aber keine Dateien enthält. Jetzt einfach den Ordner gar nicht mehr anzuzeigen halte ich für einen Fehler. Des weiteren halte ich die Begründung für nicht stichhaltig, das für ein logisches Strukturelement, das in der structMap nicht erwähnt wird, nicht ermittelt werden kann, welche Bilder zugeordnet sind. Es gibt doch für die Unterpunkte (ggf. rekursiv) Einträge in der structMap. Ein Klick auf den Oberpunkt wäre dann gleichbedeutend mit dem Öffnen des ersten Unterpunktes, der in structMap erwähnt ist. 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

Am 25.11.2010 10:29, schrieb Kay Heiligenhaus: Da ist das Beispiel mit der Zeitung aus "UK", bei der der Artikel auf der Rückseite losgeht und dann im Innenteil fortgesetzt wird. Hier gibt es einen grundsätzlichen Widerspruch. Die PHYSICAL structMap liefert die Reihenfolge der Digitalisate. Ggf. sollte dort mehrere physSequence Einträge für die einzelnen Artikel geben. Es kann aber nicht sein, dass physSequence obsolet wird durch die Reihenfolge in structLinks. Dort sollte die Reihenfolge keine Rolle spielen. Außerdem sollte der Spezialfall (UK-Zeitung) zwar berücksichtigt werden, aber doch effizient. Es kann doch nicht sein, dass der Regelfall einer Monographie oder einer Handschrift jetzt nur noch so kompliziert ausgedrückt werden kann, um 0,1% der Fälle abbilden zu können, von dem ich bezweifle, dass sie der DFG-Viewer sinnvoll darstellen kann. Statt Strukturinformationen zu ignorieren, wäre es mir lieber gewesen, dass grundsätzlich die Struktur dargestellt wird und dass dann mittels structLink die Dateien auf die Struktur abgebildet werden (Ist das nicht Sinn und Zweck dieser METS-Abschnitte?). Informationen die vorhanden sind, einfach vorzuenthalten, kann jedoch nicht im Interesse des Nutzers oder gar der Betreiber des DFG-Viewers sein. Hier den schwarzen Peter von den Entwicklern an die Nutzer zu verschieben halte ich für wenig angebracht: "[..] d.h. diese muessen implementiert werden. Das ist fuer viele Faelle sicherlich machbar, wenn auch kompliziert, wenn tiefere Strukturen als Seiten oder zusaetzliche Funktionalitaeten beruecksichtig werden. Derzeit muss die Software lediglich log/phys Relationen beruecksichtigen; Hierarchien in der log. Struktur koennen unberuecksichtigt bleiben." Da sollte man von der logische Seite an das Problem herantreten und nicht einfach sagen, dass es so einfacher zu programmieren war. Das verschiebt das Problem nur zum Nutzer und löst es nicht dort wo es auftritt - im DFG-Viewer. METS-Dokumente sollen Jahrzehnte halten, jetzt Implementierungsprobleme - die ich nicht sehe - als Argument anzubringen halte ich nicht für zweckdienlich. 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

Am 25.11.2010 11:54, schrieb Kay Heiligenhaus: Diese Spezifikation ist nicht in Stein gemeißelt (nicht umsonst mit Versionsinformation) und leitet sich aus den Implementierungsproblemen ab und ist nicht Nutzer getrieben. Ich sehe kein Grund, warum in einer Nachfolgeversion dieser Umstand nicht korrigiert werden könnte, ohne inkompatibel zur Version 2.0 zu sein. Dass es in Version 2.0 noch hakt dürfte ja offensichtlich sein, wenn ich sehe, dass wir nicht die einzigen sind, die damit so ihre Probleme haben. Die Frage an welcher Stelle sich die Größe der METS-Datei negativ auswirkt, wurde ja schon (fragend) beantwortet. Hinzufügen möchte ich noch: - beim Generieren (niemand wird für jeden METS-Austausch eine METS-Datei im jeweiligen Anwendungsprofil vorhalten) - beim Verstehen - und ganz offensichtlich beim Erklären, warum das nötig ist Die Gegenfrage soll gestattet sein, an welcher Stelle sich denn die Größe positiv auswirkt. Spontan habe ich keine Eingebung. Auch ich gebe Herrn Enders Recht, wenn er sagt: "Ich sehe zumindest kein Problem, dem nicht mit etwas mehr Resourcen beizukommen waere." Nur würde ich das auf die Entwicklungsressourcen beim DFG-Viewer beziehen, dann wären doch alle glücklich. 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

Am 25.11.2010 13:02, schrieb Kay Heiligenhaus: Sehr geehrter Herr Heiligenhaus, Ich sehe nicht, warum das eine das andere ausschließen sollte. Das eine Mischung innerhalb eines METS-Dokuments nicht sinnvoll ist, ist klar, aber es ist auf einfache Weise feststellbar, in welcher Form das Dokument vorliegt: hoch redundant nach 2.0 oder effizient nach X.x. Wenn man das nicht entscheiden können muss (davon gehe ich aus), reicht auch der skizzierte Algorithmus aus einer meiner vorigen Mails: - erst Struktur aufbauen - dann Struktur mit verlinkten Daten füllen Der Prozess dauert nach 2.0 natürlich etwas länger, weil so viele Daten umsonst abgearbeitet werden müssen. Deswegen ist es gerade wichtig, diese Zöpfe eher gestern als heute abzuschneiden, damit sich die Basis an sinnlos aufgeblähten METS-Dokumenten nicht wegen des DFG-Viewers noch weiter vergrößert. Es war gut, auf viele etablierte Standards zu setzen, da hätte viel schief gehen können. Ich möchte auch nicht zu viel meckern, weil ich sonst ganz zufrieden bin, aber an dieser Stelle der Spezifikation drehte sich bei uns alles um und konnte bislang nicht entwirrt werden. Vielleicht wäre eine Stellungnahme aus Sicht der Verantwortlichen hier nützlich, solange können wir das hier abwarten. 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

Am 25.11.2010 13:56, schrieb Meyer, Sebastian: Sehr geehrter Herr Meyer, ich verstehe ihren Einwand, dass man dies ausdrücken können muss, glaube aber, dass bei der aktuellen Präsentation es sehr schwierig sein wird dies dem Nutzer nahe zu bringen, denn dann weiß er nicht, ob die Blätter-Navigationselemente dann in der physischen oder logischen Reihenfolge blättern. Deswegen war ich dafür an der Stelle grundsätzlich die physische Reihenfolge zu nehmen, weil die am wenigsten Verwirrung stiften sollte. 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

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

Ich sehe zwischen den unterschiedlichen Reihenfolgen keinen Widerspruch. Es gibt nunmal die physische Reihenfolge, die dadurch gepraegt ist, dass jemand mal die Seiten in eine bestimmte Reihenfolge gebunden hat - ueblicherweise in der Reihenfolge die durch die aufgedrucken Seitennummern vorgegeben wird (allerdings muss auch das nicht immer so sein). Wenn man durch ein Buch blaettert (bspw. um etwas zu finden, zu einer Seite gezielt zu springen etc...) navigiert man durch genau diese Struktur. Zum zweiten gibt es die logische Reihenfolge - diese ist zwar ueblicherweise identisch mit den physischen Reihenfolge. Zwangslaeufig ist das jedoch nicht: - die UK-Zeitung war nur ein Beispiel - Logische Einheiten werden auch in anderen Zeitungen immer wieder unterbrochen: Artikel startet auf Seite 1 und wird auf Seite 5 fortgesetzt. Die Reihenfolge stimmt hier zwar; allerdings kann man nicht annehmen, dass alle Seiten zwischen 1 und 5 auch zum jeweiligen Artikel gehoeren - Bindefehler und fehlerhafte Paginierungen gibt es immer mal wieder Es spricht einiges dafuer, die logische Reihenfolge und die physische Reihenfolge zu trennen. Ds beruecksichtigt das Datenmodell des DFG-Viewer METS Profils. Dieses Modell sollte im Sinne eines allgemein gueltigen Profils fuer ALLE seitenbasierten Medientypen hinweg anwendbar sein. Daher macht das METS Profil eigentlich genau das, was sie vorschlagen: Es stellt grundsaetzlich beide Strukturen da: die logische Struktur und die physische Struktur. Die structLink Section verknuepft diese beiden Strukturen (auf Dateien wird dabei gar nicht verwiesen; der Verweis auf Dateien geschieht erst in der physischen Struktur). Bei einer komplizierten logischen und physischen Struktur fuehrt das zu einer recht grossen Anzahl an Verknuepfungen; vor allem dann. Daher wurde versucht die gespeicherten Informationen zu weit zu reduzieren, dass Redundanzen vermieden werden ohne dabei das Datenmodell zu simplifizieren. Letztlich fuehrte das dazu, dass das METS Profil das Vererben der Verknuepfungen auf physischer Seite erlaubt. Eine Verknuepfung der Monographie und der physischen Sequenz fuehrt automatisch dazu, dass aller der physischen Sequenz untergeordneten Seiten ebenfalls der Monographie zugeordnet werden. Wuerde man dieses Prinzip auf unerliegende Strukturelement wie bspw. Spalten uebertragen fuehrt das zu einer erheblichen Einsparung (dieser Satz ist ausdruecklich im Konjuktiv gehalten, weil der METS Profil derzeit keine kleineren Einheiten als Seiten unterstuetzt). Ihr Vorschlag ist nun, ein aehnliches Prinzip auf logischer Strukturebene einzufuehren. Das ist prinzipiell natuerlich moeglich; aendert aber IMHO das Dokumentenmodell. Wie oben erlaeutert lassen sich einige Dinge so nicht mehr abbilden. Das Dokumentenmodell wird simplifiziert. Es geht bei der METS Datei ja gerade darum, ein Digitalisat soe reichhaltig und explizit als moeglich zu beschreiben. Es ist auch nicht vorgesehen unterschiedliche METS Dateien fuer unterschiedliche Arten der Navigation durch ein Dokument vorzuhalten. Das sollte schon alles in einer METS Datei enthalten sein. Ich sehe auch nicht, wieso da irgendein Aufwand an den Nutzer verschoben wird. Es geht lediglich darum, Informationen explizit zu speichern, um keine Annahmen zu treffen - naemlich die Annahme das logische und physische Reihenfolge identisch sind. Denn genau das ist das Problem des von Ihnen genannten Beispiels: Die Information ist gerade nicht vorhanden; zumindest nicht explizit. Es gibt ebend keine Verknuepfung zwischen der Predigt und den jeweiligen Seiten. Gaebe es die, wuerde vermutlich auch die Navigation im DFG Viewer funktionieren. Natuerlich kann man das Profil ueberarbeiten. Das ist IMHO jedoch nur sinnvoll, wenn dem DFG Viewer neue Funktionalitaeten implementiert werden sollen, die auf weitere Daten angewiesen sind. Ein moeglicher use-case dafuer waere bspw. die Anzeige von Zeitungen. Dazu waeren naemlich im DFG Viewer einige andere Erweiterungen moeglich - bspw. die Erweiterung einen Artikel (-logische Struktureinheit) auch in der logisch richtigen Reihenfolge lesen zu koennen. (Abgesehen von der der Untestuetzung frei zoombarer Images ;-) ) Derzeit stellt sich mir allerdings eher die Frage, in weit der DFG-Viewer ueberhaupt noch weiterentwickelt werden wird. Aber dazu koennen sicherlich andere Personen etwas sagen. Ggfs. ist das ganze auch nur ein Kommunikationsproblem. Da das METS Profil unabhaengig vom DFG Viewer entwickelt wurde, geht es auch gerade NICHT darauf ein, wie bestimmte Elemente durch den DFG Viewer benutzt werden; bzw. welche Informationen durch den DFG ueberhaupt benoetigt werden. Ciao Markus -----Original Message----- From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-viewer.de] On Behalf Of Thomas Scheffler Sent: 25 November 2010 10:39 To: dv-technik(a)dfg-viewer.de Subject: Re: [DFG-Viewer] Strukturelemente ohne Bilder werden in der Navigation nicht angezeigt. Am 25.11.2010 10:29, schrieb Kay Heiligenhaus: Da ist das Beispiel mit der Zeitung aus "UK", bei der der Artikel auf der Rückseite losgeht und dann im Innenteil fortgesetzt wird. Hier gibt es einen grundsätzlichen Widerspruch. Die PHYSICAL structMap liefert die Reihenfolge der Digitalisate. Ggf. sollte dort mehrere physSequence Einträge für die einzelnen Artikel geben. Es kann aber nicht sein, dass physSequence obsolet wird durch die Reihenfolge in structLinks. Dort sollte die Reihenfolge keine Rolle spielen. Außerdem sollte der Spezialfall (UK-Zeitung) zwar berücksichtigt werden, aber doch effizient. Es kann doch nicht sein, dass der Regelfall einer Monographie oder einer Handschrift jetzt nur noch so kompliziert ausgedrückt werden kann, um 0,1% der Fälle abbilden zu können, von dem ich bezweifle, dass sie der DFG-Viewer sinnvoll darstellen kann. Statt Strukturinformationen zu ignorieren, wäre es mir lieber gewesen, dass grundsätzlich die Struktur dargestellt wird und dass dann mittels structLink die Dateien auf die Struktur abgebildet werden (Ist das nicht Sinn und Zweck dieser METS-Abschnitte?). Informationen die vorhanden sind, einfach vorzuenthalten, kann jedoch nicht im Interesse des Nutzers oder gar der Betreiber des DFG-Viewers sein. Hier den schwarzen Peter von den Entwicklern an die Nutzer zu verschieben halte ich für wenig angebracht: "[..] d.h. diese muessen implementiert werden. Das ist fuer viele Faelle sicherlich machbar, wenn auch kompliziert, wenn tiefere Strukturen als Seiten oder zusaetzliche Funktionalitaeten beruecksichtig werden. Derzeit muss die Software lediglich log/phys Relationen beruecksichtigen; Hierarchien in der log. Struktur koennen unberuecksichtigt bleiben." Da sollte man von der logische Seite an das Problem herantreten und nicht einfach sagen, dass es so einfacher zu programmieren war. Das verschiebt das Problem nur zum Nutzer und löst es nicht dort wo es auftritt - im DFG-Viewer. METS-Dokumente sollen Jahrzehnte halten, jetzt Implementierungsprobleme - die ich nicht sehe - als Argument anzubringen halte ich nicht für zweckdienlich. 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