Lieber Herr Scheffler,

Noch einmal: es geht hier nicht darum, ob sich die von Ihnen angeregte Vererbung innerhalb der logischen Struktur technisch im DFG-Viewer umsetzen ließe. Das wäre natürlich möglich.
Ausschlaggebend ist aber nicht der Viewer, sondern das Anwendunsprofil, dem der Viewer folgen muss. Dort müsste die Vererbung also als Grundannahme definiert werden. Weshalb das nicht getan wurde, haben Herr Enders, ich und andere Kollegen versucht darzulegen.
Im Klartext: es handelt sich _nicht_ um ein technisches Problem oder ein Problem der Implementierung, sondern um eine Frage der medientypologischen Freiheit des Formats und der Kompatibilität zu anderen METS-Implementierungen. Dazu ist es meines Erachtens sinnvoll, so viel wie möglich im Format explizit auszudrücken und nicht implizit über verabredete Grundannahmen. Im Idealfall sollte das Format auch dann eindeutig interpretierbar sein, wenn man das Anwendungsprofil (und damit eventuelle implizite Annahmen) nicht kennt.

Viele Grüße
Sebastian Meyer

-- 
Sebastian Meyer
Referatsleiter Digitale Bibliothek

Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek (SLUB)
01054 Dresden
Telefon: +49 351 4677-206
Telefax: +49 351 4677-711
Web: http://www.slub-dresden.de
Von: Thomas Scheffler
Sent: Freitag, 26. November 2010 08:05
An: dv-technik@dfg-viewer.de
Betreff: Re: [DFG-Viewer] Strukturelemente ohne Bilder werden in der Navigation nicht angezeigt.
Am 25.11.2010 16:55, schrieb Meyer, Sebastian:
> Lieber Herr Scheffler,
>
>> 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.
>
> 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).

Dann haben wir uns gehörig in der Diskussion über physische und logische
Reihenfolge verzettelt. Wie gesagt man kann dem Nutzer nur eines
sinnvoll darstellen und das ist die physische Reihenfolge.

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

Muss man eben genau nicht. Um festzustellen, was die erste Seite eines
logischen Strukturelementes ist bedient man sich des Mittels der Rekursion:

1.) Die gesuchte Seite ist im aktuellen Strukturelement (bisheriger
Fall), wenn nicht:
2.) Das Strukturelement befindet sich im ersten Kind (Überprüfung
mittels Schritt 1), wenn nicht
3.) Für alle weiteren Kinder prüfe nach Schritt 1

Das ganze lässt sich so extrem trivial implementieren, dass es um die
Diskussion schon schade ist.

Umgekehrt funktioniert das auch für Strukturzugehörigkeit von Seiten:

1.) Finde Zugehörigkeit von Seite mittels smLinks zu Struktureinheiten
2.) Markiere alle Elternelemente als aktiv.

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

Tut er ja nicht! So wird die logische Reihenfolge ja nirgendwo
berücksichtigt, sie ist für den Viewer irrelevant. Gleichzeitig werden
aber einfache Annahmen nicht getroffen, die die METS-Dokumente sehr viel
verständlicher machen würden. Der gezeigte Algorithmus arbeitet korrekt
für alle bisherigen von ihnen genannten Sonderfällen und zusätzlich in
dem von uns beschriebenen Standardfall. Wenn dies also möglich ist, dann
ist es auch möglich das zugrunde liegende Format zu beschreiben, so dass
alle Fälle abgedeckt sind - widerspruchsfrei.

Die bisherigen Reaktionen zeigen mir, dass wir zwar Recht haben, weil in
all den Mails dieses Threads - und der Vordiskussion mit semantics -
kein einziger Grund genannt worden ist, wieso so ein Verhalten nicht
umsetzbar ist. Die Folgerung muss sein: Weil es keinen Grund gibt.
Trotzdem muss ein gewisser Wille zu Kooperation schon auf beiden
Projektseiten vorhanden sein, damit man sich insgesamt verbessern kann.
Meine Wahrnehmung ist leider, dass dies in der aktuellen Konstellation
nicht möglich zu sein scheint.

Es ist müßig hier weiter zu diskutieren. Die Argumente sind ausgetauscht
und wenn es auf Seiten des DFG-Viewers nicht den Wunsch gibt, sich
sukzessive zu verbessern und auf das Feedback der Nutzer nicht
eingegangen wird, dann ist dem Projekt auch von unserer Seite nicht zu
helfen.

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