25 Nov
2010
25 Nov
'10
11:54 a.m.
Lieber Herr Scheffler,
da haben Sie leider die Spezifikation des DV-METS-Profils nicht auf Ihrer Seite:
"Eine Verknüfung auf eine physische Struktur bezieht sich auch immer auf alle
unterliegenden Strukturelemente. Eine Verknüpfung von der
obersten logischen Struktureinheit (bspw. Monographie) auf die physische Sequenz
(physSequence) impliziert also auch alle
Verknüpfungen auf die einzelnen Seiten, die dem physischen Sequenz untergeordnet sind.
Eine explizite Verknüpfung zwischen
Monographie und den einzelnen Seiten sind nicht notwendig.
Dagegen werden Verknüpfungen auf logischer Struktur NICHT vererbt. Das heißt für jedes
logische <div> Element sind alle Verknüpfungen
erneut wieder aufzuführen. Die Gesamtheit aller unterliegenden <div> Elemente muss
jedoch nicht zwangsläufig alle Verknüpfungen des
übergeordneten <div> Elements enthalten.
Dies bedeutet, dass für das Seitenbasierte Dokumentenmodell, welches vom DFG-Viewer
implementiert wird, lediglich eine Verknüpfung
von der obersten logischen Dokumentstruktur auf die physSequence notwendig ist. Die
definierten Seiten müssen nicht aus der logischen
Struktur heraus verknüpft werden. Der DFG-Viewer ist in der Lage, den impliziten
Verknüpfungen zu folgen. " [1]
Wie gesagt, ich würde Ihren Argumenten in jeder Hinsicht folgen, da wir eben mit ganz
ähnlichen Argumenten die aktuelle Modellierung und Implementierung ebenfalls in Zweifel
gezogen haben. Aber, Spezifikation ist Spezifikation. Und folglich haben wir uns
entschieden, das Profil eben in genau der vorliegenden Form zu implementieren. Da hat dann
m.E. Herr Enders in der Konsequenz recht:
Entsprechend ausfuehrliche und grosse METS Dateien
automatisiert zu
generieren scheint mir da das kleinere Uebel zu sein. An welcher Stelle wirkt
sich denn die Groesse der METS Datei nachteilig aus? Beim parsen?
uebertragen?
Ich sehe zumindest kein Problem, dem nicht mit etwas mehr Resourcen
beizukommen waere.
Beste Grüße,
Kay Heiligenhaus
[1] http://dfg-viewer.de/fileadmin/groups/dfgviewer/METS_Anwendungsprofil_2.0.p… - S.
25.
-----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 11:39 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 10:29, schrieb 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
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-2010
0524/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.
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