25 Nov
2010
25 Nov
'10
1:56 p.m.
Lieber Herr Scheffler,
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.
Nun können Sie einwenden, dass Palimpseste keine Drucke sind, das Anwendungsprofil aber
explizit für Drucke gedacht ist. Allerdings sind derzeit analoge
Standardisierungsbemühungen auch für andere Medientypen (konkret: Handschriften und
Nachlässe) im Gang und dabei wird als gemeinsame Konstante die Verwendung von METS als
Container- und Strukturformat angestrebt. Auch vor diesem Hintergrund halte ich es für
sehr erstrebenswert, mit demselben Dokumentenmodell alle Medientypen behandeln zu können.
Und zwar nicht, damit ich bei der Implementierung der Formate im DFG-Viewer weniger Arbeit
habe, sondern damit überhaupt die Möglichkeit besteht, mit standardisierten Werkzeugen
unabhängig vom Medientyp arbeiten zu können (statt für jeden Medientyp eine eigene
Werkzeugsammlung zu benötigen).
Insofern halte ich den nur geringfügig höheren Implementierungsaufwand für
vernachlässigbar, egal für welchen Standpunkt er als Argument vorgebracht wird. Viel
schlagender finde ich das Argument, mit dem aktuellen Dokumentenmodell eine weitgehende
Standardisierung über die Medientypen hinweg zu erreichen.
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 11:39
An: dv-technik(a)dfg-viewer.de
Betreff: Re: [DFG-Viewer] Strukturelemente ohne Bilder werden in der
Navigation nicht angezeigt.
Am 25.11.2010 10:29, schrieb Kay Heiligenhaus:
Lieber Herr Scheffler, lieber Herr Hermann,
diesen Punkt hatten wir vor geraumer Zeit bereits hier auf der
Agenda. Herr Enders erläuterte damals, warum aus seiner Sicht eine
solche Modellierung sinnvoll und notwendig ist. Unsere interne
Diskussion (hier bei semantics) hat dann ergeben, daß wir es zwar
weiterhin anders (nämlich wie von Ihnen nun ebenfalls ausgeführt)
sehen, aber die Argumente für eine abweichende Modellierung
nachvollziehen können:
https://maillist.slub-dresden.de/pipermail/dv-technik/Week-of-Mon-
20100524/000476.html
So hatten wir es damals belassen. Mal schauen, ob sich bei der
erneuten Diskussion ein Beispiel wird finden lassen, aus dem
ersichtlich wird, warum diese "hochredundante Modellierung"
Gestaltungsspielräume bietet, die wir aktuell noch nicht sehen...
Da ist das Beispiel mit der Zeitung aus "UK", bei der der Artikel auf
der Rückseite losgeht und dann im Innenteil fortgesetzt wird.
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
Beste Grüße, Kay Heiligenhaus
--
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 -----Original Message----- From:
dv-technik-bounces(a)dfg-viewer.de
[mailto:dv-technik- bounces(a)dfg-viewer.de] On Behalf Of Thomas
Scheffler Sent: Thursday, November 25, 2010 10:08 AM To:
dv-technik(a)dfg-viewer.de Subject: Re: [DFG-Viewer] Strukturelemente
ohne Bilder werden in der Navigation nicht angezeigt.
Am 25.11.2010 09:28, schrieb Meyer, Sebastian:
Lieber Herr Hermann,
Sie haben die Frage eigentlich bereits selbst beantwortet: das
Strukturelement wird nicht angezeigt, weil ihm keine Bilder (und
auch kein Verweis in Form eines mptr oder fptr) zugeordnet sind.
Dadurch kann kein "Linkziel" für den Navigationspunkt ermittelt
werden und er wird folglich nicht angezeigt. In Ihrem Fall ist es
meines Erachtens auch falsch, der "Predigt" keine Images
zuzuweisen, denn sie besteht ja durchaus aus mehreren Images,
nämlich mindestens der Summe aller Images ihrer untergeordneten
Strukturelemente. Wenn Sie dies berücksichtigen, sollte die
"Predigt" auch in der Navigation erscheinen.
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