2 Jun
2010
2 Jun
'10
5:59 p.m.
Lieber Herr Heiligenhaus,
diese Lösung finde ich am besten. Aus Sicht des DFG-Viewers würde damit die Schwierigkeit
entfallen, die korrekte übergeordnete Einheit identifizieren zu müssen, zugleich würde
aber auch kein ungültiges MODS entstehen. Ich werde die Auswertung von
relatedItem[@type="host"] auf meine ToDo-Liste für die nächste Viewer-Version
setzen.
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: Mittwoch, 2. Juni 2010 17:17
An: dv-technik(a)dfg-viewer.de; technik(a)dfg-viewer.de
Betreff: Re: [DFG-Viewer] Anzeige von Zeitschriftenbänden
Lieber Herr Meyer, lieber Herr Kothe,
wir haben unser Beispiel mal umgebaut und die MODS-Daten der Zeitschrift in
das MODS des Bandes eingebettet:
http://s2w.visuallibrary.net/pk/oai/?verb=GetRecord&metadataPrefix=mets…
dentifier=24361
Das Ergebnis im Viewer ist aber gleich geblieben:
http://dfg-
viewer.de/v2/?set[image]=1&set[zoom]=default&set[debug]=0&set[double]=0
&set[mets]=http%3A%2F%2Fs2w.visuallibrary.net%2Fpk%2Foai%2F%3Fverb%3
DGetRecord%26metadataPrefix%3Dmets%26identifier%3D24361
Ich hatte ja schon vermutet, daß Sie weder die Bandinformationen (also
mods:part) noch die Informationen zur Überordnung (in mods:relatedItem)
auswerten. Das Beispiel aus Göttingen zeigt es: hier werden die Angaben aus
der Überordnung "einfach" mit den Angaben zum Band in einer MODS-
Struktur vermischt, was der Viewer dann natürlich prima anzeigt (abgesehen
jedoch von den Informationen in mods:part, die der Viewer schlicht ignoriert),
nur ist das MODS in dieser Form fehlerhaft. Der Band hat hier keinen eigenen
Titel und ein System, das die Göttinger Daten harvested - nicht um sie
anzuzeigen, sondern um sie zu indexieren - würde das dann fehlerhaft als
Bandtitel interpretieren.
Das ist m.E. nicht der Weisheit letzter Schluß. Ich könnte damit gut leben, die
Informationen im MODS des Bandes zu kapseln, dann aber eben MODS-
konform. Nur müßte der Viewer m.E. die im obigen Beispiel gelieferten
Informationen zu Band und Überordnung "korrekt" auswerten.
Was meinen Sie?
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 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/
>
> > -----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%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
> > 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=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
> >
> >