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

-----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 18:24 An: dv-technik(a)dfg-viewer.de; technik(a)dfg-viewer.de Betreff: Re: [DFG-Viewer] Anzeige von Zeitschriftenbänden Lieber Herr Meyer, prima. Ich drängle ja ungern, aber könnten Sie das auch als Hotfix umsetzen, da es ja letztlich ein Bug ist? Wir aktuell in einem Projekt der ULB Düsseldorf das Problem, daß wir die dort in einem laufenden DFG-Projekt digitalisierten Zeitschriften nicht freigeben können, da der Viewer sie nicht korrekt anzeigen kann. Da man strikt der DFG-Vorgabe folgt, die Projektergebnis primär im Viewer zu präsentieren, blockiert uns das aktuell sehr... Beste Grüße, Kay Heiligenhaus 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=m > > > et > > > > 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 > > > > > > > >