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