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

Lieber Herr Heiligenhaus! Vielen Dank für das Beispiel. Das sagt schon mehr als tausend Worte. Und gut - das ist eine funktionierende Lösung, die auch auf Zeitungen übertragen werden könnte. Nur kurz zwei Punkte, die wie ich denke bei Zeitungen bedacht werden müssen: 1. Zeitungen sind in der einzelnen Nummer ganz anders strukturiert als die üblichen Publikationsformen mit Vordeckel, Titelblatt, Inhaltsverzeichnis etc. Das Hauptstrukturkriterium sind die Artikel, die im Gegensatz zu Themen und Rubriken immer auftauchen. 2. Zeitungen haben von der Darstellung her sehr viel mehr Bedarf an Funktionalität, als es der DFG-Viewer zurzeit bietet -> einzelne Betrachtung von Artikeln ist besonders bei modernen Zeitungen ein Muss, ansonsten sucht man sich tot, wo denn nun der Artikel ist. In meinen Augen liegt das Hauptproblem also eher in der Darstellung der einzelnen Zeitungsnummer im DFG-Viewer. Ob man nun aus seinem Nachweissystem auf eine DFG-Viewer-Navigation verweist oder lieber auf die Darstellung in der eigenen digitalen Bibliothek mit allen Funktionen (oder beides) ist dann jedem selbst überlassen. Eine Navigationsstruktur würde ich mir übrigens so vorstellen: Titel -> Ausgabe A -> Jahr/Band -> Datum/Nummer -> Edition (Morgen-, Abendausgabe) -> Ausgabe B... So würde man maximal 5 Ebenen und minimal 3 Ebenen (ohne Ausgabe X und ohne Edition) zur Verfügung stellen. Und es gäbe etwa 300 Tage in der dritten/vierten Ebene zur Auswahl. Gruß, Carsten Schulze -----Ursprüngliche Nachricht----- Von: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-viewer.de] Im Auftrag von Kay Heiligenhaus Gesendet: Donnerstag, 25. Februar 2010 20:48 An: dv-technik(a)dfg-viewer.de; dv-technik(a)dfg-viewer.de Betreff: Re: [DFG-Viewer] Strukturdaten für Zeitungen? Lieber Herr Schulze, Die Philosophie ist halt hier und da Grundlage aller Praxis. ;) Ich verstehe weiterhin nicht, was an der bisherigen Katalogisierungspraxis unzulänglich sein soll. Das wird hier immer wieder in den Raum gestellt, aber allein: mir fehlt der Glaube rsp. die Überzeugung, daß diese Behauptung stimmt. Auch hatte ich ja bereits darauf hingewiesen, daß sich unsere Daten doch möglichst weit in der bestehenden (!) Welt verbreiten sollten, sprich: In der ZDB auftauchen, im Verbundsystem, im OPAC, im Worldcat, in ZVDD, in Europeana usw. usf. Alle diese Systeme kennen Periodika in der Form, wie sie nun mal aktuell katalogisiert werden. Und alle diese Systeme kann man mit den hier relevanten Metadaten versorgen und der Nutzer kommt so elegant dorthin, wo er hin möchte. Aber gut. Sie sitzen in Berlin und können vielleicht mal schnell zu den Kollegen von der ZDB gehen, anschließend dann zu den Kollegen von EuropeanaLocal-D an der ZLB. Anschließend können Sie die Gelegenheit nutzen, wenn mal wieder jemand von OCLC an der Staatsbibliothek auftaucht. Wenn Sie alle Einrichtungen überzeugt haben, daß wir ein Problem beim Nachweis und bei der Erschließung von periodischen Werken haben und anschließend alle drei Systeme (ZDB, Europeana, Worldcat) entsprechend Ihren Vorstellungen angepaßt sind, dann können wir diese Diskussion auf wirklich praktischer Basis weiterführen... ;) HTTP? Irgendeine Schnittstelle? Irgendeine zentrale Datenbasis? Das klingt alles nicht nach aktueller Praxis, sondern nach Philosophie oder Vision. ;) Ja. Und so sieht so was dann in der Praxis bereits aus: http://dfg-viewer.de/v2/?set%5Bimage%5D=1&set%5Bzoom%5D=default&set… BTW: Da fällt mir auf, lieber Herr Meyer, daß es im Viewer hier noch einen Bug gibt. Wenn in den MODS-Daten (für den Viewer relevante) "Pflichtelemente" nicht vorkommen, dann werden diese Platzhalter (###PLACE### ###DATE### ) eingesetzt. Im vorliegenden Fall haben wir aber schlicht keine Ortsangabe und keine Jahresangabe in den bibliographischen Daten, da es sich um einen Aufsatz in einer Zeitschrift handelt. Von daher sollten diese Platzhalter m.E. nicht gesetzt werden, da es sich hier eben um Pflichtfelder handelt, die nur besetzt werden, wenn es auch Daten dazu gibt. Tatsächlich wäre es perfekt, wenn man Periodika oder mehrbändige Werke virtuell zusammenfassen könnte auf einer zentralen Plattform. Ändert jedoch nichts daran, daß deren Teile wahrscheinlich dezentral gespeichert sind und gespeichert bleiben. Oder man schiebt alles in DigiZeit als der zentralen Plattform. Das macht nur wenig Sinn, wenn man die Zeitschriften in einem fachlichen Kontext präsentieren möchte (wie im Beispiel oben die ULB Sachsen-Anhalt die Zeitschriften im Kontext des SSG Orientalistik ins Netz stellt). Wie gesagt: das ist eine Dateihierarchie, die da entsteht. Und in der Tat: für jeden neuen Band müßte ein neuer Eintrag in der METS-Datei der Zeitschrift gemacht werden. Da zahlt es sich dann aus, wenn das METS dynamisch produziert wird oder man einen Aktualisierungsmechanismus für bereits bestehende METS-Exporte zur Verfügung hat. (Ich finde es in diesem Kontext allerdings etwas befremdlich, daß man diese notwendigen Synchronisationsmechanismen als problematisch sehen kann und dabei letztlich unterstellt: da kommt hinten irgendwann mal eine METS-Datei raus und die ist für immer und ewig festgenagelt.) Darüber hatte Herr Meyer auch schon mal nachgedacht. Ist eine witzige und gute Idee m.E. Beste Grüße, Kay Heiligenhaus