25 Nov
2010
25 Nov
'10
12:48 p.m.
Am 25.11.2010 11:54, schrieb Kay Heiligenhaus:
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:
Diese Spezifikation ist nicht in Stein gemeißelt (nicht umsonst mit
Versionsinformation) und leitet sich aus den Implementierungsproblemen
ab und ist nicht Nutzer getrieben. Ich sehe kein Grund, warum in einer
Nachfolgeversion dieser Umstand nicht korrigiert werden könnte, ohne
inkompatibel zur Version 2.0 zu sein. Dass es in Version 2.0 noch hakt
dürfte ja offensichtlich sein, wenn ich sehe, dass wir nicht die
einzigen sind, die damit so ihre Probleme haben.
Die Frage an welcher Stelle sich die Größe der METS-Datei negativ
auswirkt, wurde ja schon (fragend) beantwortet. Hinzufügen möchte ich noch:
- beim Generieren (niemand wird für jeden METS-Austausch eine METS-Datei
im jeweiligen Anwendungsprofil vorhalten)
- beim Verstehen
- und ganz offensichtlich beim Erklären, warum das nötig ist
Die Gegenfrage soll gestattet sein, an welcher Stelle sich denn die
Größe positiv auswirkt. Spontan habe ich keine Eingebung.
Auch ich gebe Herrn Enders Recht, wenn er sagt:
"Ich sehe zumindest kein Problem, dem nicht mit etwas mehr
Resourcen beizukommen waere."
Nur würde ich das auf die Entwicklungsressourcen beim DFG-Viewer
beziehen, dann wären doch alle glücklich.
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
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.