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/…
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.
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
Beste Grüße, Kay Heiligenhaus
-----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
--
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