Re: [DFG-Viewer] Anzeige von Zeitschriftenbänden

-----Original Message----- From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik- bounces(a)dfg-viewer.de] On Behalf Of Meyer, Sebastian Sent: Wednesday, June 02, 2010 10:00 AM To: technik(a)dfg-viewer.de Subject: Re: [DFG-Viewer] Anzeige von Zeitschriftenbänden 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/ bounces@dfg- einer Zeitschrift: viewer.de/v2/?set[mets]=http%3A%2F%2Fs2w.visuallibrary.net/pk%2Foai% 2F viewer.de/v2/?set%5Bimage%5D=1&set%5Bzoom%5D=default&set%5Bdeb ug %5D=0&set%5Bdouble%5D=0&set%5Bmets%5D=http%3A%2F%2Fs2w.visual lib rary.net%2Fpk%2Foai%2F%3Fverb%3DGetRecord%26metadataPrefix%3Dme ts > %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 Bandes: > 3) METS/MODS für Band http://s2w.visuallibrary.net/pk/oai/?verb=GetRecord&metadataPrefix=met > s&i > 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 >