Re: [DFG-Viewer] Strukturdaten für Zeitungen?

Lieber Herr Heiligenhaus, das ist ein guter Punkt. Aber ich bin mir sicher, dass auch der Spiegel (würde er METS verwenden) die Einteilung in Ressorts und die chronologische Einordnung der Artikel nicht in den Strukturdaten vornehmen würde. Allein schon deshalb, weil sie dann eine Vielzahl paralleler Strukturen abbilden müssten, denn jeder Artikel ist möglicherweise mehreren Ressorts zugeordnet und die Artikel eines Ressorts sind wiederum zu unterschiedlichen Zeiten erschienen. Der Spiegel müsste also eine structMap für die chronologische Einordnung erstellen und eine zweite für die Zuordnung zu Ressorts. Und dann fällt den Spiegel-Machern möglicherweise ein, dass sie auch noch die Struktur der Artikel im gedruckten Heft irgendwo abbilden möchten, und sie legen noch eine dritte logische structMap an... :) Ich stimme Ihnen zu, dass wir eine möglichst intuitive und übersichtliche Möglichkeit schaffen müssen, wie der Nutzer von einem ZDB-Katalogisat einer Zeitung zu einem konkreten Artikel in einer konkreten Ausgabe eines konkreten Jahres kommt. Und wir können uns sogar noch etliche andere Möglichkeiten des Zugangs überlegen - analog zu den Ressorts des Spiegels vielleicht auch eine thematische Ordnung der Artikel. Würden Sie dann für jeden dieser Zugänge eine eigene structMap bzw. ein eigenes Set auf einander verweisender METS-Dateien anlegen wollen? Das sind meines Erachtens Fragen, die das Recherche-System beantworten muss und nicht das Datenformat. Wenn der aktuelle ZDB-Katalog dazu nicht in der Lage ist, weil er natürlich primär die analoge Welt abbildet, dann muss ein System geschaffen werden, dass das kann (oder die ZDB entsprechend angepasst werden). Für den Bereich der Monographien soll ZVDD das leisten, für die Zeitschriften könnte man sich eventuell das Digizeitschriften-Projekt der SUB Göttingen zum Beispiel nehmen. Das Problem ist also nicht, dass das Datenformat unzureichend wäre, um solche Strukturen abzubilden, sondern dass es bislang kein System gibt, das die im Format durchaus vorhandenen Informationen entsprechend aufbereitet und visualisiert. Der Punkt ist, dass ich gerne vermeiden möchte, durch die Festschreibung der "äußeren" Navigationsstruktur in der structMap dem Recherche- und/oder Präsentationssystem eine bestimmte Art des Zugangs aufzuzwingen. Besser ist es aus meiner Sicht, eine Vielzahl von deskriptiven Metadaten zu erfassen (Erscheinungsjahr, -monat, -woche, -tag, Ressort, Thema, etc.) und es dem jeweiligen Zielsystem zu überlassen, aus diesen Informationen eine (oder mehrere!) geeignete Darstellungen zu erzeugen. Letztlich käme das auch dem Nutzer entgegen, weil er vielfältigere Möglichkeiten hätte. Wir sollten diese Diskussion meines Erachtens vom Kontext des DFG-Viewers lösen. Der Viewer ist ein reines Anzeigeinstrument und kein Recherche-Werkzeug. Entsprechend wird die Suche einer bestimmten Zeitungsausgabe aus 18.000 Ausgaben dort immer mühsam und umständlich sein, einfach weil man nicht umhin kommt, sich durch die gesamte Zeitung zu hangeln (ob nun über den "Umweg" der Jahre, Monate und Wochen oder "direkt" aus einer endlosen Liste von 18.000 Einträgen). Da haben Sie völlig recht. Auch die Praxis, übergeordnete Einheiten von Bänden in der logischen Struktur abzubilden, ist meines Erachtens unschön. Richtig fände ich auch hier, die Verknüpfung lediglich in den deskriptiven Metadaten über <mods:relatedItem type="host"> vorzunehmen. Dann kann der Viewer diese Verknüpfung aber nicht mehr auflösen, da er dort nur einen Identifier findet, aber keinen Hinweis darauf, in welchem Repository er diesen Identifier auflösen soll. Für ein Recherche-System (wie ZVDD) ist das dagegen kein Problem, da es die Verknüpfung systemintern auflösen kann. Um den Forderungen der DFG gerecht zu werden, haben wir uns mangels geeignetem Recherchesystem für diese Notlösung entschieden, ich würde sie nun aber ungern noch weiter ausweiten. Statt die Notlösung zu einer besseren Notlösung zu machen (und uns damit mittelfristig größere Probleme einzuhandeln), sollten wir lieber eine echte Lösung anstreben. :) 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, 24. Februar 2010 14:51 > An: dv-technik(a)dfg-viewer.de; technik(a)dfg-viewer.de > Betreff: Re: [DFG-Viewer] Strukturdaten für Zeitungen? > > Lieber Herr Meyer, > > > ich fürchte, dann habe ich Ihren Ansatz nicht richtig verstanden. Sie > > schreiben völlig richtig, dass die METS-Datei des "Anzeigers für das > > Havelland" gemäß des aktuellen DFG-Viewer-Schemas aus 18.000 DIVs vom > > Typ "issue" bestehen würde. So wie ich Ihren Vorschlag verstanden > habe, > > ändert sich daran aber doch nichts, außer dass zwischen "periodical" > und > > "issue" eben noch ein paar Hierarchie-Ebenen "year", "month", "week", > etc. > > kämen. Es würden also sogar noch mehr DIVs werden, nämlich zusätzlich > zu > > den 18.000 DIVs für die Ausgaben noch 59 DIVs für die > Erscheinungsjahre, > > 708 für die Monate der 59 Jahre und 3068 für die Wochen. > > Nein. Es wäre 59 DIVs im METS-Dokument der Zeitung. Diese verzeigern > dann zu 59 METS-Dokumenten der einzelnen Jahrgänge, welche wiederum zu > je 12 METS-Dokumenten für die Monate und schließlich zu je rd. 25 METS- > Dokumenten für die Tage verzeigern. Würde man das alles in eine METS- > Datei packen, würde es wahrscheinlich den Viewer zerlegen rsp. zu > Ladezeiten führen, die eine Reise nach Berlin nahelegen würden, wo man > die Zeitung schneller aus dem Regal geholt hätte, um sie endlich lesen > zu können. ;) > > > Richtig ist natürlich, dass die Navigation für den Besucher dadurch > > übersichtlicher wird, im Gegenzug wird sie aber auch (nicht zuletzt > auch für > > die Datenverarbeiter) umständlicher, da er nun mindestens viermal > klicken > > muss, bis er ein konkretes Heft zu Gesicht bekommt. > > Hm. Das verstehe ich nicht. Ganz gleich, wo ich klicken muß (im > Katalog, in einem lokalen Präsentationssystem, im Viewer): Wenn ich von > der Zeitung komme, brauche ich eine intuitive Struktur der Navigation. > > > Noch dazu stellt sich die > > Frage, ob Monate und Wochen nicht sogar auf derselben Ebene stehen > > müssten (da Monate ja nicht aus ganzen Wochen bestehen) und demnach > > wieder für zusätzliche Verwirrung sorgen würden. > > Darüber könnte man streiten. Es ist aber m.E. nicht der Kernpunkt. > > > Das ist aber ein Problem, dass wir meines Erachtens nicht mit dem > DFG- > > Viewer bzw. dem Datenformat adressieren sollten. Es ist in meinen > Augen > > Aufgabe des Katalogsystems, dem Nutzer einen möglichst komfortablen > und > > eingängigen Einstieg in das Werk zu bieten - der Viewer soll dann > lediglich das > > Ergebnis (also eine konkrete Ausgabe oder einen Artikel) > visualisieren. Dass > > er dabei den Kontext ebenfalls in gewissem Rahmen darstellt, ist ein > schönes > > Feature, aber meiner Ansicht nach nicht die primäre Aufgabe des > Viewers. > > Ich betrachte das sogar eher als Notlösung, um die aktuellen > > Unzulänglichkeiten der ZDB in diesem Punkt auszugleichen, aber nicht > als > > gewolltes Feature des Viewers. > > Wie müssen m.E. von der aktuellen Katalogisierungspraxis ausgehen. Und > die sieht nun mal vor, daß es in der ZDB nur Hauptansetzungen gibt und > der Erscheinungsverlauf in einem Feld summarisch beschrieben wird. Das > ist m.E. auch katalogisierungstechnisch korrekt. Wir haben hier mit > Titelaufnahmen zu tun - die "logischen Strukturen" spielen erst eine > Rolle, wenn man eine Zeitung auf den Scanner geknallt hat und > anschließend dem Nutzer die Möglichkeit geben möchte, die Ergebnisse > dieses Unterfangens im Netz zu bewundern. > > > Der Viewer ist - wie der Name schon sagt - ein reines Instrument zur > > Visualisierung eines konkreten Digitalisats und der Navigation > innerhalb > > desselben. Darüber hinaus ist er "blind". Er visualisiert also weder > etwaige > > Beziehungen zwischen Digitalisaten, noch deren Zugehörigkeit zu > > Kollektionen, Serien oder übergeordneten Einheiten. All das sollte > eigentlich > > ein Katalog- und Retrievalsystem wie ZVDD oder die ZDB abbilden. > > Korrekt. Aber es geht hier nicht um Sammlungskontexte, sondern um die > Forderung in den DFG-Praxisregeln, vom Katalogisat aus direkt ins > Digitalisat im Viewer zu kommen. Zudem stellt sich die Frage: Warum > bilden wir dann mehrbändige Werke und Zeitschriften im Viewer ab? Es > würde dann ja ebenfalls reichen, einfach nur vom Band aus zu verlinken > (der allerdings nur für monographische Werke im Katalog steht, nicht > für periodisch erscheinende). > > Beste Grüße, > Kay Heiligenhaus