Lieber Herr Heiligenhaus,
der DFG-Viewer wertet derzeit immer nur genau eine MODS-dmdSec aus. Welche das ist, wird
anhand folgender Kriterien bestimmt: In der logischen Struktur wird die hierarchisch
oberste Einheit gewählt, die sowohl das Attribut @DMDID besitzt als auch in der
structLink-Sektion mit einer physischen Struktur verknüpft ist. (Wenn es keine physische
Struktur gibt, wird generell die hierarchisch höchste Einheit gewählt - auch das ist unter
Umständen problematisch.)
Die hierarchisch oberste logische Struktur in der METS-Datei Ihres Zeitschriftenbandes ist
die Gesamtheit, diese ist aber mit keiner physischen Struktur verknüpft. Deshalb wertet
der DFG-Viewer die darunterliegende Struktur aus, die sowohl ein @DMDID-Attribut als auch
eine Verknüpfung mit einer physischen Struktur besitzt. Die MODS-dmdSec dieser Struktur
weist aber weder einen Titel, noch Autor, Erscheinungsjahr und Erscheinungsort aus,
weshalb die entsprechenden Platzhalter im Viewer erscheinen.
Die Schwierigkeit besteht hier generell darin, innerhalb der logischen Struktur einer
METS-Datei genau die Einheit zu identifizieren, die für die Anzeige der Titeldaten
entscheidend ist. Ursprünglich war dies mal grundsätzlich die oberste Struktur in der
Hierarchie. Dann sind wir aber dazu übergegangen, dass Referenzen zu übergeordneten
Einheiten nicht nur in MODS (als relatedItem[@type="host"]), sondern auch in der
logischen METS-Struktur kodiert werden (was ich grundsätzlich auch gut und richtig finde).
Deshalb musste ich mir ein neues Verfahren ausdenken, wie ich die relevanten Titeldaten
eines darzustellenden Werks ermitteln kann. Das oben beschriebene Vorgehen schien mir da
geeignet, aber es funktioniert offenbar nicht, wenn die in der METS-Datei beschriebene
Einheit nicht selbst über die Pflichtmetadaten verfügt, sondern diese von einer
übergeordneten Einheit erbt.
Insofern handelt es sich wohl tatsächlich um einen Bug, wobei ich diesen fürchte ich nicht
ohne Weiteres beheben kann. Für Ihr Beispiel wäre das noch recht einfach: der Viewer
müsste wie oben beschrieben die oberste relevante Einheit ermitteln, dann aber darin
fehlende Pflichtangaben aus den Metadaten übergeordneter Einheiten ergänzen. Das
funktioniert aber auch nur, weil in Ihrem Beispiel der Band überhaupt eigene Metadaten
besitzt, hätte er keine eigene dmdSec (was ja denkbar wäre), würde der Viewer den Band gar
nicht erst als die relevante logische Einheit identifizieren. Außerdem ist in Ihrem
Beispiel der Schritt vom Band zur übergeordneten Einheit nicht sehr groß - aber das ist ja
nicht zwingend immer so, unter Umständen gibt es noch eine Reihe von
"Zwischenschritten", die ebenfalls ausgewertet werden müssten.
Problematisch wäre auch, wenn die Metadaten der übergeordneten Einheit gar nicht in der
METS-Datei des Bandes stünden. Aus METS-Sicht wäre das ja durchaus erlaubt. Dann müsste
der Viewer allerdings erst dem METS-Pointer zur METS-Datei der übergeordneten Einheit
folgen, um dann von dort die nötigen Metadaten zu beziehen. Unter Umständen müsste der
Viewer auf diese Weise sogar durch mehrere METS-Dateien iterieren, da ja nicht zwingend
gesagt ist, dass die direkt übergeordnete Einheit bereits alle nötigen Metadaten liefert -
der Viewer müsste also von der ermittelten relevanten Einheit aus die komplette darüber
liegende logische Struktur bis zum "Root-Element" durchgehen (wobei im
schlimmsten Fall jede Einheit wiederum eine eigene METS-Datei besitzt).
Technisch wäre das lösbar, aber ich fürchte, die Performance würde sehr darunter leiden.
Ich würde deshalb dafür plädieren, wir verstehen unsere Formulierung von Pflichtfeldern so
streng, dass die jeweils in einer METS-Datei beschriebene logische Einheit diese
Pflichtmetadaten _selbst_ mitbringen muss. Mit anderen Worten: wenn Sie für einen Band
eine METS-Datei anlegen, dann müssen Sie auch für diesen Band einen Titel vergeben (sowie
Autor, Erscheinungsjahr und Erscheinungsort, soweit bekannt). Wenn der Band keinen eigenen
Titel hat, müssten Sie eben den der Gesamtheit wiederholen. (So wird es doch meines
Wissens auch z.B. in der Verbundkatalogisierung gehandhabt?)
Ich sehe ein, dass das nicht schön ist, ich halte es aber für die einfachste und eine
durchaus vertretbare Lösung. Was meinen Sie?
Viele Grüße
Sebastian Meyer
--
Sebastian Meyer
Projekt-Mitarbeiter
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
01054 Dresden
Tel.: +49 351 4677-206
Fax: +49 351 4677-711
http://www.slub-dresden.de/
-----Ursprüngliche Nachricht-----
Von: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-
viewer.de] Im Auftrag von Kay Heiligenhaus
Gesendet: Dienstag, 1. Juni 2010 19:22
An: dv-technik(a)dfg-viewer.de
Betreff: [DFG-Viewer] Anzeige von Zeitschriftenbänden
Lieber Herr Meyer,
wir bereiten aktuell ein paar Beispiele vor, um die Diskussion über die
Navigation in periodischen Werken (also zunächst Zeitschriften und Zeitungen)
anhand konkreter digitalisierter Objekte weiterführen zu können. Dabei stellt
sich zunächst eine grundsätzliche Frage, bei der Sie mir vielleicht auf die
Sprünge helfen können. Hier zunächst das Beispiel einer Zeitschrift:
1) Zeitschrift im Viewer
http://dfg-
viewer.de/v2/?set[mets]=http%3A%2F%2Fs2w.visuallibrary.net/pk%2Foai%2F%
3Fverb%3DGetRecord%26metadataPrefix%3Dmets%26identifier%3D23303
2) Band im Viewer
http://dfg-
viewer.de/v2/?set%5Bimage%5D=1&set%5Bzoom%5D=default&set%5Bdebug
%5D=0&set%5Bdouble%5D=0&set%5Bmets%5D=http%3A%2F%2Fs2w.visuallib
rary.net%2Fpk%2Foai%2F%3Fverb%3DGetRecord%26metadataPrefix%3Dmets
%26identifier%3D24361
Wie Sie sehen können, sind die Metadaten des Bandes nicht ganz so, wie ich
mir das gedacht hätte. Anstelle der Angaben zu Zeitschrift und Band findet sich
"###TITLE### ###VOLUME######PLACE### ###DATE###" in der Titelzeile
des Viewers. Hier das zugrundeliegende METS/MODS des Bandes:
3) METS/MODS für Band
http://s2w.visuallibrary.net/pk/oai/?verb=GetRecord&metadataPrefix=mets…
dentifier=24361
Es finden sich folglich sowohl zur Zeitschrift (DMDID md23303) als auch zum
Band (DMDID sd24361) MODS-Daten, die m.E. korrekt in der METS-Struktur
referenziert werden. Allerdings scheinen Sie bei der Viewer-Implementierung
davon auszugehen, daß sich alle notwendigen Daten für die Anzeige
ausschließlich im MODS des Bandes finden - also auch die MODS-
Informationen zur Überordnung. Allerdings gehe ich nicht davon aus, daß Sie
Informationen aus einem relatedItem[@type='host'] auswerten, das ja hier
gebildet werden müßte zur Aufnahme der bibliographischen Informationen
der Zeitschrift.
Sehe ich das richtig und es handelt sich um einen "Bug"? Oder, falls nicht,
wie
müßte man es umsetzen, damit der Viewer die Daten versteht (und diese
weiterhin MODS-konform bleiben)?
Beste Grüße,
Kay Heiligenhaus