Lieber Herr Meyer, lieber Herr Schulze, vielen Dank für Ihr Feedback. Ihre Bauchschmerzen kann ich gut verstehen, aber ich frage mich dann schon, warum Sie keine Bauchschmerzen haben, mehrbändige Werke und Zeitschriften so zu modellieren, wie wir es aktuell im DFG-Viewer-METS-Profil tun [1]. Hier werden ebenfalls bibliographische Angaben des MODS-Datensatzes in die METS-Struktur gespiegelt (volume, issue), damit eine hierarchische Navigation im DFG-Viewer möglich wird - was schlicht daran liegt, daß der Viewer allein die METS-Struktur auswertet, um in über- und untergeordneten Elementen einer komplexeren Einheit zu navigieren. Die MODS-Daten spielen für diese Navigation keinerlei Rolle. Konkret: Wenn man es so modelliert, wie von Herrn Schulze beschrieben, führt das zu folgendem. Die METS-DIV-Struktur einer Zeitung wäre: newspaper -> issue -> article Konkret also: Anzeiger für das Havelland -> 12.11.1905 -> Aus dem Havellande Nun hat diese Zeitung einen Erscheinungsverlauf über 59 Jahre [2]. Wir hätten folglich - bei rd. 300 Erscheinungstagen (= issue) pro Jahr - rd. 18.000 "issue"-Strukturdaten im DFG-Viewer bei Aufruf dieser Zeitung z.B. aus der ZDB. Kann man das ernsthaft so darstellen? Wie sollte ein Nutzer damit sinnvoll interagieren können? Und das ist doch das Ziel unserer Überlegungen: Dem Nutzer nach dem Einsprung aus einem übergeordneten Nachweissystem (VD16/17/18, ZDB, Verbundkatalog, OPAC, ...) eine komfortable Möglichkeit zu bieten, sich in den entsprechenden bibliographischen Einheiten "bewegen" zu können, sprich: zu lesen. Zuletzt noch der Hinweis: Was die "logische Struktur" einer Zeitschrift oder Zeitung ist, lieber Herr Meyer, ist eine metaphysische Frage. Sie erinnern sich vielleicht, daß ich deshalb - es muß um eine Karnevalszeit herum gewesen sein - vorgeschlagen hatte, daß wir neben der physical- und logical-structMap noch eine metaphysical-structMap einführen, um auch diese strukturelle Ebene angemessen beschreiben zu können. ;) Beste Grüße, Kay Heiligenhaus [1] http://dfg-viewer.de/fileadmin/groups/dfgviewer/METS_Anwendungsprofil_2.0.p…, S. 17ff. [2] http://dispatch.opac.ddb.de/DB=1.1/CMD?ACT=SRCHA&IKT=8506&SRT=LST_t…

Lieber Herr Schulze, Sie haben halt nur die "Hauptansetzung" für die Zeitung in der ZDB. Wenn Sie also - den DFG-Praxisregeln folgend - von hier aus in den Viewer verlinken wollen/müssen, dann müssen Sie m.E. eine Darstellungsform finden, die für den Nutzer sinnvoll navigierbar ist. Von daher sind Ihre Überlegungen bzgl. des METS-Profils für Zeitungen sehr sinnvoll als Vorgabe für einen Dienstleister, der die entsprechenden Zeitungen _scannt_. Das hat aber rein gar nichts mit einer Modellierung für einen Nutzer zu tun, der die Zeitung anschließend im Web _lesen_ möchte. Beste Grüße, Kay Heiligenhaus

Lieber Herr Meyer, 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. ;) 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. SPIEGEL ONLINE beglückt uns ja auch nicht mit seiner vollen Pracht auf der Startseite, sondern läßt mich durch einzelne Ressorts navigieren oder chronologisch im Archiv stöbern. Darüber könnte man streiten. Es ist aber m.E. nicht der Kernpunkt. 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. 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

Lieber Herr Meyer, vorneweg: ich kann Ihre Argumente gut nachvollziehen, dennoch meine ich, daß wir auf halben Wege stehenblieben, wenn wir nicht auch für Zeitungen ein "Standardmodell" schafften, wie wir es bereits für Zeitschriften und mehrbändige Werke geschaffen haben. Ansonsten bliebe uns nämlich m.E. nur der Ausweg, das Modell für Zeitschriften auch für die Beschreibung von Zeitungen zu verwenden, bedeutet: es zu mißbrauchen. Kurz zu den konkreten Punkten: Das Argument ist gut, nur: es gilt analog auch für alle andere Materialien, die wir im Viewer darstellen. In Monographien könnten uns die Gedichte besonders interessieren oder die Illustrationen bestimmter Künstler über verschiedene Ausgaben hinweg. In wissenschaftlichen Zeitschriften wäre die Werbung evtl. interessant. Das alles läßt sich tatsächlich nur auf Portalebene sinnvoll lösen - evtl. geleitet von jeweils konkreten wissenschaftlichen Fragestellungen. Dennoch habe wir uns auf ein Standardmodell der einheitlichen Anzeige und Erschließung (über die verschiedenen Projekte und Portale und Techniken hinweg) verständigt, sozusagen auf den Standardaufbau einer Monographie, einer Zeitschrift, eines mehrbändigen Werkes. Sie arbeiten gerade mit an einem Standardmodell für Handschriften. Gesichtspunkte für diese Differenzierungen sind typologische Aspekte: Eine Handschrift ist anders aufgebaut als eine Monographie ist anders aufgebaut als ... Mein Frage ist nun: Ist eine Zeitung anders aufgebaut als eine Zeitschrift? Was unterscheidet die beiden? Wie könnte folglich der Aufbau einer Zeitung generalisiert beschrieben werden? Oh. Oh. Oh. Da klingeln bei mir alle Glocken. Mit gleichem Recht könnte man sagen: Weg mit den "klassischen Bibliothekskatalogen". Die sind für die analoge Welt und müssen nun angepaßt werden. Wir brauchen Strukturdaten in den Katalogen. Wir brauchen Volltexte in den Katalogen. Warum diskutieren wir noch über den Umstieg von MAB2 zu MARC21? Alles Schnee von gestern. Weg mit dem Quatsch. (Ernsthaft betrachtet ist das gar keine schlechte Überlegung. Die Trennung von Katalog und Repository könnte tatsächlich irgendwann ganz wegfallen. Aber wann ist dieses "Irgendwann"? Und sollen wir tatsächlich fordern, daß sich die Welt um uns herum ändern muß, damit wir auch Zeitungen im Viewer präsentieren können?) Hm. Also lösen ZVDD und DigiZeit die Kataloge als primäre Recherchequellen perspektivisch ab? Interessant. Das sag ich demnächst mal dem einen oder anderen Katalogisierer, den ich so kenne. ;) Das tut jede Modellierung. Und das ist auch der Sinn einer solchen. Das Metaphysische bei der Frage nach der "logischen Struktur" einer Zeitung ist doch: Was ist das Modell, das wir den konkreten Erscheinungsformen von Publikationen, die wir summarisch Zeitungen nennen, überstülpen, damit wir sie unter einem einheitlichen Gesichtspunkt erschließ- und präsentierbar machen? Für den Viewer konkretisiert: Wie wünschen wir uns eine Standardnavigation durch diese Ansammlung von tausenden von Seiten die über Jahrhunderte hinweg in sehr regelmäßiger Form erschienen sind? Hm. Das halte ich nicht für sinnvoll. Wir würden damit für einen Publikationstyp sagen: Das ist ein Haufen von Seiten in einem Haufen von Tagen. Anzeigen kann und will ich den nicht. Nein, das sehe ich nicht so. Wir haben Katalogisierungspraxis und digitale Präsentation zusammengebracht. Wie mir scheint, ist dieser Ansatz auf einen sehr fruchtbaren Boden gefallen. Das sieht man nicht zuletzt an der aktuellen Diskussion. Hintergrund meiner Frage ist ja ein konkretes Kundeninteresse. Dieser Kunde hat nämlich auf die Viewerseiten geschaut und gesagt: Hm. Zeitungen kann man so aber nicht darstellen. Was machen wir denn jetzt? Eine solche Frage kann man nur stellen, wenn man verstanden hat, was wir mit unserem Strukturdatenset erreichen wollen... ;) Unterm Strich würde ich sagen: Sollten wir uns nicht darüber verständigen, wie Zeitungen konkret zu modellieren sind, dann müssen wir m.E. einen neuen Strukturtyp einführen: "other". Dann steht es jeder Einrichtung frei, eine Modellierung zu finden, wie sie sie für richtig hält, wenn das Viewer-Set eben nicht paßt. Das ist m.E. besser, als zwanzig Jahre darauf zu warten, bis sich Katalogwelt und Repositorywelt zu einer Einheit verschmolzen haben. Sagte ich zwanzig Jahre? Beste Grüße, Kay Heiligenhaus

Lieber Herr Meyer, Ich glaube, das kann man nicht alles in einen Topf schmeißen: Daß es verschiedene Verbund- und Lokalsysteme gibt, hat sehr vielfältige Gründe. Nicht wenige davon sind einfach Ergebnis gewachsener Strukturen (sein Bibliothekssystem wechselt man halt nicht täglich wie das Hemd). Und im Kern sind es eben Ergebnisse von Kauf- oder Entwicklungsentscheidungen über viele Jahre hinweg. So wie es Mercedes, Audi, Volkswagen, Land Rover, Fiat, ... gibt, so gibt es eben Aleph, PICA, SISIS, Allegro, ... Dann gibt es eben die konkreten Fragen der Erschließung und Darstellung bestimmter Medientypen. Mit RAK-WB und MAB2 kommen Sie halt bei Handschriften und Autographen nicht sonderlich weit. Dafür haben Sie auch keine komplexen Prozesse wie Erwerbung, Ausleihe usw. in diesen Bereichen zu lösen. Folglich macht es Sinn, für spezielle Medientypen ideale Erschließungswerkzeuge bereitzustellen. Der Traum, alles passe in einen Katalog, endet m.E. im Alptraum, daß wir darin nichts relevantes mehr finden, weil wir alle Differenzen plattgebügelt haben. Da verstehe ich Ihren Punkt noch nicht: Mit dem METS-Profil verfolgen wir doch den Anspruch, ein komplexes Dokumentenmodell zu etablieren für die Beschreibung digitalisierter Objekte. Unsere Bezugsgröße ist dabei das Katalogisat der Einheit, über die wir da Aussagen machen (Aussagen der Art: Das ist deine "physische Form", das ist deine "logische Form", in dieser Relation stehen diese beiden Formen zueinander usw.). Man darf sich hier aber von den Begrifflichkeiten nicht verwirren lassen: "physisch" bedeutet z.B. nicht, daß ein Buch physisch aus Einzelseiten bestünde. Üblicherweise bestehen Bücher aus Bögen von vier Druckseiten, die z.B. fadengeheftet sind. Oder von zwei Druckseiten, die in einen Einband geklebt werden. Über das alles wollen wir mit unserem Modell keine Aussage machen. Unser Ziel ist doch vielmehr, ein einheitliches Schema vorzugeben für die Digitalisierung, Strukturierung und Präsentation digitalisierter Medien, damit diese für einen Nutzer einheitlich nutzbar sind im Netz. Hm. Bei Zeitschriften läuft das eigentlich genau so. Ich habe einem bibliographischen Nachweis (zumeist aus einer wissenschaftlichen Publikation), der mit sagt: Du findest mich in "Zeitschrift für angewandte Typologie, Jg. 13 (1998), H. 2, S. 19-29". Mit dieser Information marschiere ich in die Bibliothek. Suche im OPAC. Bestelle eine Bindeinheit mit einer konkreten Signatur und lege das Teil anschließend auf den Kopierer. Genau das möchte ich auch in einer digitalen Bibliothek machen können. Nur heißt das hier: Suche in der ZDB (oder im OPAC). Klick auf den Link zum Viewer. Navigation zum entsprechenden Artikel. Download eines PDFs oder Lesen am Bildschirm. Es ist schlichtweg utopisch zu glauben, wir könnten alle historischen Zeitschriften tatsächlich irgendwann auf unselbständiger Ebene (also Artikelebene) katalogisiert und digitalisiert haben. Dann entfiele tatsächlich die "mühsame" Navigation zur Fundstelle. Bei Zeitungen ist es m.E. noch was anderes. Da interessiert mich vielleicht, was an meinem Geburtstag so in der Welt passiert ist. Oder wie die deutschen Tageszeitungen die Kriegsausbrüche 1914 und 1939 kommentiert haben. Was schrieb man über die Gründung des Kaiserreichs? Wie wurde der Einzug Napoleons in Berlin dargestellt? Zeitungen zeichnen sich schlichtweg durch ihren aktuellen Bezug zum Zeitgeschehen aus. Das gibt ihnen m.E. eben auch ihre Struktur. Es geht hier um Jahre, Monate, Tage. Darin strukturiert sich nämlich das Zeitgeschehen, über das berichtet wird. Sie vergessen dabei schlicht, daß moderne Bibliothekssysteme integrierte Systeme sind. Der OPAC ist dabei nur eine Funktionalität unter vielen. Ich sehe nicht, daß wir durch die Definition von weiteren Strukturdaten für einen Publikationstyp, der offensichtlich anders aufgebaut ist als diejenigen, mit denen wir uns bislang intensiver beschäftigt haben, mehr oder andere Festlegungen gemacht werden, als wir das bisher getan haben. Ich verstehe auf eine bestimmte Art die Diskussion nicht. Durch das generalisierte Navigationsmodell in _beliebigen_ Hierarchien haben wir im Viewer alle Voraussetzungen geschaffen, um auch das hier diskutierte Problem lösen zu können. Es geht hier doch schlicht um die Frage: Sollen wir weitere Strukturdaten ergänzen, um Zeitungen mit ihren Spezifika besser darstellen zu können? Es geht nicht darum, daß wir irgendwas am Viewer erweitern müßten, um dieses Ziel zu erreichen. Technisch ergeben sich hier keinerlei Anforderungen. Ich bin da ganz offensichtlich deutlich skeptischer, als Sie es sind. Daß es so viele spezialisierte Lösungen für unterschiedliche Medientypen gibt, halte ich eben nicht für das Ergebnis eines irrationalen Prozesses, sondern für das Ergebnis der Arbeit an spezifischen Problemlösungen, die den Materialitäten unserer Sammlungen geschuldet sind. Standards kann man nur da etablieren, wo es hinreichende Gemeinsamkeiten gibt. Oder eben da, wo man sich auf bestimmte Aspekte konzentriert. So ist z.B. die Darstellung von Metadaten im Viewer m.E. nur deshalb in Ordnung, wie wir sie sehr reduziert machen, weil es den Kataloglink gibt, über den ich mich als Nutzer über jeden Titel im Detail informieren kann, wenn ich das möchte. Ein letzter Aspekt noch: Wir hatten hier vor kurzem eine Diskussion über das Europeana-Datenmodell. Schaut man sich die ersten Importergebnisse von EuropeanLocal-D im Netz an, dann sieht man, daß wir das Problem der Darstellung von Zeitungen und Zeitschriften auch hier bekommen werden. Denn wenn wir das Problem so lösen würden, wie Sie es hier vorschlagen (das Nachweissystem soll die Hierarchie verstehen und abbilden, der Viewer dann nur noch die "Endknoten" darstellen können, mehr nicht), dann würde das für Europeana (und alle anderen Harvestingsysteme) ja analog gelten. Man käme nicht mehr von der "Hauptaufnahme" zum digitalisierten Gesamtobjekt, sondern eben immer nur in die konkreten Teilobjekte, deren Struktur im Nachweissystem beschrieben und navigierbar sein müßte. Die Krux dabei: EuropeanaLocal-D harvested die METS-Daten, die wir nach unserem Modell zur Verfügung stellen. Wenn sich die Informationen über das Gesamtobjekt aber nur aus einem noch zu schaffenden "Superkatalog" beziehen lassen, die Informationen über die Teilobjekte nur aus einem reduzierten Repository, dann könnte Europeana aktuell: gar nichts harvesten und gar nicht anzeigen von unserer digitalen Pracht. Bedeutet unterm Strich: Ihr "reduzierter Ansatz" (weg mit den Hierarchien im Modell) führte dazu, die Komplexität des Problems in zig weitere Systeme zu verlagern und nicht an einem Ort zu bündeln. Nehmen Sie als abschließendes Beispiel folgendes: http://www.europeana.eu/portal/full-doc.html?uri=http://www.europeana.eu/re… Das ist der Datensatz der Trierischen Chronik in der Europeana. Den Datensatz gibt es auch im Worldcat: http://www.worldcat.org/title/trierische-chronik/oclc/263724874 Sollen wir jetzt auch mit OCLC darüber diskutieren, daß Kataloge und Metakataloge digitalen Medien nicht gerecht werden, nachdem wir die ZDB/EZB-Verantwortlichen davon überzeugt haben? Nein, bei allem Nachdenken über Ihre Argumentation bleibe ich dabei, daß es m.E. sehr sinnvoll ist, wie wir es bislang angegangen sind. Und daß wir auf diesem Wege unser Ziel am besten erreichen: Hohe Sichtbarkeit digitalisierter Materialien auf Basis eines ausgesprochen flexiblen, aber durchaus komplexen Standardmodells. Beste Grüße, Kay Heiligenhaus

Liebe Kolleginnen und Kollegen, da die Diskussion langsam ins Philosophische abgleitet, möchte ich nur kurz meine (sehr praktischen) Überlegungen mit einbringen. Ich bin wie Herr Meyer der Meinung, dass wir nicht die Unzulänglichkeiten der Nachweissysteme mit dem DFG-Viewer versuchten sollten auszubügeln. Allerdings sind unsere Nachweissyteme gar nicht so unbrauchbar. Sie basieren ja mittlerweile alle auf HTTP. Alles was wir brauchen ist eine sinnvolle Datenbasis der verfügbaren Digitalisate (so etwas wie das ZVDD oder etwas lokales), eine Schnittstelle und schon kann man sich zu einem bestimmten Titel einen kleinen Kalender in den OPAC zaubern. Da muss nicht ein neues Nachweissystem erfunden werden. Außerdem: Ich stelle mir vor eine Bibliothek digitalisiert eine Zeitung. Aus ihrem Nachweissystem heraus verweist sie von diesem Titel auf den DFG-Viewer, der es erlaubt in den Bänden, Ausgaben etc. zu navigieren, bis der Nutzer auf die gewünschte Ausgabe trifft, die dann im DFG-Viewer angezeigt wird. Die Navigationsstruktur wird über eine zeitungsspezifische METS-Datei bereitgestellt, die die verweisende Bibliothek lokal vorliegen hat und aus ihrem Digitalisierungsworkflow speist. Habe ich das richtig verstanden, oder liege ich falsch? Wenn das der Plan sein sollte, dann bekommt der Nutzer immer nur die Digitalisate, die lokal produziert werden. Schade! Ist doch eigentlich nicht nötig in der digitalen Welt. Außerdem müsste dauernd die METS-Datei aktualisiert werden, wenn ein neues Digitalisat hinzu kommt. Und die Datei soll wie groß werden? Man sollte mal darüber nachdenken, ob man nicht den DFG-Viewer nutzen möchte, um eine sinnvolle Datenbasis aufzubauen. Das "Instrument" ist auf jeden Fall dafür geeignet, die Daten sinnvoll auszulesen. Jeder "View" wäre ein Eintrag in eine Datenbank. Die Daten kann sich dann jeder über eine Schnittstelle abholen und wunderschöne Kalender zaubern, wie ich es oben beschrieben habe. Das wäre dann ein pragmatisches ZVDD. Gruß, Carsten Schulze -----Ursprüngliche Nachricht----- Von: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-viewer.de] Im Auftrag von Meyer, Sebastian Gesendet: Donnerstag, 25. Februar 2010 17:59 An: technik(a)dfg-viewer.de Betreff: Re: [DFG-Viewer] Strukturdaten für Zeitungen? Lieber Herr Heiligenhaus, ich hatte ja absichtlich am Anfang meiner Mail gewarnt, dass ich etwas ins Träumen geraten würde. :) Ich wage mal die ketzerische Behauptung, dass eine Handschrift sich von einer Monographie gar nicht so sehr unterscheidet, wenn man sie nicht mit den Augen eines Bibliothekars betrachtet. Das ist aber hier gar nicht die entscheidende Frage. Die Frage ist vielmehr: unterscheidet sich eine *digitalisierte* Handschrift so sehr von einem *digitalisierten* Druck? Nachdem ich nun die Vorschläge von Herr Schulze zur Kodierung von digitalisierten Zeitungen, von Herr Schaßan zur Kodierung von digitalisierten Handschriften und unsere eigenen Vorschläge zur Kodierung von digitalisierten Drucken und Zeitschriften kenne, behaupte ich guten Gewissens: so groß sind die Unterschiede gar nicht, als dass man sie nicht in ein einziges Format bringen könnte, ohne Granularität einzubüßen. Natürlich müsste ein geeignetes Format geschaffen werden und zwar nicht durch Generalisierung und Vereinfachung (dann hätten wir am Ende DublinCore), sondern durch Vereinheitlichung und Aggregation. Meines Erachtens machen wir nämlich den Fehler, unsere Digitalisate genauso behandeln zu wollen, wie wir die analogen Vorlagen behandeln. Und das wird dem (neuen) Medium nicht gerecht. Richtig, und dabei würde ich sogar soweit gehen, nicht nur Bögen und Druckseiten zu vernachlässigen, weil das Digitalisat nunmal nur noch aus Dateien besteht, sondern auch zu vernachlässigen, dass z.B. der "Titel" einer Handschrift eigentlich nicht "Titel" heißt. Letztlich ist es doch dasselbe, nämlich die wichtigste Form der verbalen Adressierung des vorliegenden Werks. Oder mit anderen Worten: so wie ich nicht die tatsächliche physische Struktur der Vorlage beschreibe, sondern im Grunde die Struktur des Digitalisats, so sollte ich mich auch in allen anderen Belangen auf das Digitalisat beziehen und lediglich eine Referenz auf die Vorlage als Quelle angeben. Was es zur Vorlage zu wissen gibt, steht schließlich schon im Katalog, dazu muss ich mir nicht das Digitalisat anschauen. Die grundsätzliche Frage ist: warum unterscheiden wir überhaupt zwischen "Digitalisat einer Handschrift" und "Digitalisat einer Monographie" und nicht zwischen "Handschrift", "Monographie" und "Digitalisat"? Das tun wir doch nur deshalb, weil wir das Digitalisat einer Handschrift genauso behandeln wollen wie eine Handschrift und das Digitalisat einer Monographie so wie eine Monographie. Wenn jemand eine Monographie handschriftlich abschreibt, wird das Ergebnis aber doch auch als Handschrift behandelt und nicht als Monographie. Warum gilt das nicht für die Digitalisierung? Warum nicht ein Digitalisat als eigenständigen Medientyp betrachten, dessen Erschließung sich natürlich an der Erschließung der Vorlage orientieren sollte, der aber flexibel genug ist, um Vorlagen jeden Typs abbilden zu können? Das ist natürlich eine sehr weitreichende Forderung, aber langfristig sehe ich das als das Ziel: Es zeichnet sich ja bereits ab, dass die Struktur eines Digitalisats unabhängig vom Typ der Vorlage weitgehend einheitlich in METS abgebildet werden wird. (Die Handschriften-Experten diskutieren ein METS/TEI-Format, bei den Nachlässen ist METS/EAD als eine Alternative im Gespräch.) Etwas ähnliches müsste doch auch für die deskriptiven Metadaten zu erreichen sein. Statt eines gemeinsamen Strukturdatensets könnte man doch auch ein gemeinsames Metadatenset über verschiedene Medientypen hinweg erstellen. Das Ziel muss ja nicht ein weitgehend generalisiertes und auf ein Dutzend Metadaten eingedampftes Set sein (wie etwa DublinCore), sondern darf ruhig etwas umfangreicher ausfallen, um eben nicht "alle Differenzen plattzubügeln". Ich bin mir aber sicher, dass (genau wie beim Strukturdatenset) bei näherer Betrachtung plötzlich erheblich mehr Gemeinsamkeiten ans Tageslicht kämen, als man vorher erwartet hätte. :) Ich sehe einfach die Notwendigkeit der Unterscheidung zwischen verschiedenen Vorlagentypen in der digitalen Welt nicht mehr. In der analogen Welt hat das alles seine Berechtigung, weil es dort keine Suchmaschinen "über alles" gibt und ich mich deshalb jedem Medium individuell nähern muss, um zum Ziel zu kommen. Letztlich hat die ganze Katalogisierung doch nur das Ziel, Unmengen analoger Medien in irgendeiner Form zu klassifizieren, damit sie findbar sind. In der digitalen Welt ist das aber doch viel einfacher. Um beim aktuellen Fall der Zeitung zu bleiben: in der analogen Welt muss ich die Signatur der Zeitung kennen, um überhaupt nur eine Chance zu haben, das zu finden was ich suche. Dort gibt es keinen anderen Weg zu der gesuchten Ausgabe zu kommen, als über diese Information - entsprechend müssen die Signatur im Katalog stehen und die Ausgaben im Regal ordentlich sortiert sein. In der digitalen Welt habe ich dagegen ein Recherchesystem, dass sämtliche Struktur- und Metadaten der digitalisierten Zeitung indiziert hat. Dort tippe ich einfach das Datum ein und bekomme alle Ausgaben des entsprechenden Tages zurückgeliefert. Dazu muss ich aber nicht die analoge Welt nachbilden, in dem ich die Sortierung nach Jahr, Monat, Tag in die Strukturdaten schreibe, sondern es reicht, wenn ich den Erscheinungstag jeder Ausgabe jeweils in die MODS-Metadaten der METS-Datei eben dieser Ausgabe schreibe. Das Problem ist also nicht, dass das Datenformat das "analoge Vorgehen" nicht abbildet, sondern dass es bislang kein Recherchesystem gibt, dass das "digitale Vorgehen" umsetzt - obwohl die Voraussetzungen dafür gegeben sind. Das ist auch genau die in meiner letzten Mail beschriebene Lücke: wir haben ein Katalogsystem für die analoge Welt und auf der anderen Seite ein Anzeigeinstrument für die digitale Welt. Das passt nicht zusammen. Statt nun aber das Anzeigeinstrument in die analoge Welt zu holen, sollten wir lieber einen Katalog für die digitale Welt schaffen. 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: Donnerstag, 25. Februar 2010 13:30 > An: dv-technik(a)dfg-viewer.de; technik(a)dfg-viewer.de > Betreff: Re: [DFG-Viewer] Strukturdaten für Zeitungen? > > Lieber Herr Meyer, > > > Wenn das ernsthaft betrachtet keine schlechte Überlegung ist, warum > > betrachten wir es dann nicht ernsthaft? :) Vielleicht brauchen wir > auch nicht > > Strukturdaten und Volltexte in den Katalogen der analogen Welt, > sondern > > analoge Medien in den Katalogen der digitalen Welt? Aktuell gibt es > zig > > Verbünde, unzählige Lokalsysteme und etliche Spezialverzeichnisse für > > diverse Medientypen - alles mit der Begründung, dass die jeweils > anderen > > Kataloge den Bedürfnissen des Medientyps nicht gerecht werden. > > Ich glaube, das kann man nicht alles in einen Topf schmeißen: Daß es > verschiedene Verbund- und Lokalsysteme gibt, hat sehr vielfältige > Gründe. Nicht wenige davon sind einfach Ergebnis gewachsener Strukturen > (sein Bibliothekssystem wechselt man halt nicht täglich wie das Hemd). > Und im Kern sind es eben Ergebnisse von Kauf- oder > Entwicklungsentscheidungen über viele Jahre hinweg. So wie es Mercedes, > Audi, Volkswagen, Land Rover, Fiat, ... gibt, so gibt es eben Aleph, > PICA, SISIS, Allegro, ... Dann gibt es eben die konkreten Fragen der > Erschließung und Darstellung bestimmter Medientypen. Mit RAK-WB und > MAB2 kommen Sie halt bei Handschriften und Autographen nicht sonderlich > weit. Dafür haben Sie auch keine komplexen Prozesse wie Erwerbung, > Ausleihe usw. in diesen Bereichen zu lösen. Folglich macht es Sinn, für > spezielle Medientypen ideale Erschließungswerkzeuge bereitzustellen. > Der Traum, alles passe in einen Katalog, endet m.E. im Alptraum, daß > wir darin nichts relevantes mehr finden, weil wir alle Differenzen > plattgebügelt haben. > > > Nun werden offensichtlich alle Kataloge den Bedürfnissen der > Digitalisate nicht > > gerecht, aber plötzlich sollen sich nicht mehr die Kataloge, sondern > die > > Digitalisate anpassen... > > Da verstehe ich Ihren Punkt noch nicht: Mit dem METS-Profil verfolgen > wir doch den Anspruch, ein komplexes Dokumentenmodell zu etablieren für > die Beschreibung digitalisierter Objekte. Unsere Bezugsgröße ist dabei > das Katalogisat der Einheit, über die wir da Aussagen machen (Aussagen > der Art: Das ist deine "physische Form", das ist deine "logische Form", > in dieser Relation stehen diese beiden Formen zueinander usw.). Man > darf sich hier aber von den Begrifflichkeiten nicht verwirren lassen: > > > Ich frage mich: wenn man es nicht einmal schafft, alle analogen > Medien > > einheitlich in einem einzigen Katalog zu verzeichnen, warum müssen > dann > > die Digitalisate zwingend in den OPAC, den Verbund oder die ZDB? > Natürlich > > ist das aus Nutzersicht besser als noch einen neuen Katalog neben das > > vorhandene Dutzend zu stellen. Aber dem Nutzer ist auch nicht > geholfen, > > wenn er dann im Katalog lediglich einen Eintrag für die gesamte > Zeitung > > findet und sich anschließend mühsam durch etliche Navigationsebenen > > hangeln muss, bevor er einen konkreten Artikel auf dem Bildschirm > hat. Und > > dabei muss immer vorausgesetzt werden, dass er bereits genau weiß, > > welche Ausgabe welchen Datums von welcher Zeitung er überhaupt > > betrachten will - andernfalls hilft ihm der Katalog und Ihre > Strukturierung > > nämlich auch nicht weiter. > > Hm. Bei Zeitschriften läuft das eigentlich genau so. Ich habe einem > bibliographischen Nachweis (zumeist aus einer wissenschaftlichen > Publikation), der mit sagt: Du findest mich in "Zeitschrift für > angewandte Typologie, Jg. 13 (1998), H. 2, S. 19-29". Mit dieser > Information marschiere ich in die Bibliothek. Suche im OPAC. Bestelle > eine Bindeinheit mit einer konkreten Signatur und lege das Teil > anschließend auf den Kopierer. Genau das möchte ich auch in einer > digitalen Bibliothek machen können. Nur heißt das hier: Suche in der > ZDB (oder im OPAC). Klick auf den Link zum Viewer. Navigation zum > entsprechenden Artikel. Download eines PDFs oder Lesen am Bildschirm. > Es ist schlichtweg utopisch zu glauben, wir könnten alle historischen > Zeitschriften tatsächlich irgendwann auf unselbständiger Ebene (also > Artikelebene) katalogisiert und digitalisiert haben. Dann entfiele > tatsächlich die "mühsame" Navigation zur Fundstelle. > > Bei Zeitungen ist es m.E. noch was anderes. Da interessiert mich > vielleicht, was an meinem Geburtstag so in der Welt passiert ist. Oder > wie die deutschen Tageszeitungen die Kriegsausbrüche 1914 und 1939 > kommentiert haben. Was schrieb man über die Gründung des Kaiserreichs? > Wie wurde der Einzug Napoleons in Berlin dargestellt? Zeitungen > zeichnen sich schlichtweg durch ihren aktuellen Bezug zum Zeitgeschehen > aus. Das gibt ihnen m.E. eben auch ihre Struktur. Es geht hier um > Jahre, Monate, Tage. Darin strukturiert sich nämlich das Zeitgeschehen, > über das berichtet wird. > > > In sofern sehe ich die Perspektive gar nicht so unrealistisch, dass > ZVDD u.ä. > > Systeme künftig tatsächlich die Rolle von primären Katalogsystemen > spielen > > werden - nur eben nicht für analoge Medien, sondern für Digitalisate. > Einfach > > deshalb, weil sie dem Nutzer all die Möglichkeiten anbieten, die wir > im > > Datenformat so mühsam angelegt haben: Volltexte, Strukturdaten, > > Beziehungen zwischen den Werken, etc. > > Sie vergessen dabei schlicht, daß moderne Bibliothekssysteme > integrierte Systeme sind. Der OPAC ist dabei nur eine Funktionalität > unter vielen. > > > Wie eine solche Standardnavigation aussieht, sollte aber nicht im > > Datenformat festgeschrieben werden, sondern dem Präsentationssystem > > überlassen werden (was nicht heißt, dass wir dazu nicht Empfehlungen > > formulieren können). Das Datenformat muss nur sicherstellen, dass > alle > > nötigen Informationen vorhanden sind. > > Ich sehe nicht, daß wir durch die Definition von weiteren Strukturdaten > für einen Publikationstyp, der offensichtlich anders aufgebaut ist als > diejenigen, mit denen wir uns bislang intensiver beschäftigt haben, > mehr oder andere Festlegungen gemacht werden, als wir das bisher getan > haben. > > > Es besteht offensichtlich eine Lücke zwischen einer Zeitung (die im > Katalog > > nachgewiesen ist) und ihren Ausgaben (die problemlos im Viewer > dargestellt > > werden können). Diese Lücke muss mit irgendeiner geeigneten Form von > > Navigation gefüllt werden, die es dem Nutzer erlaubt, vom Katalogisat > der > > Zeitung zur Anzeige einer Ausgabe dieser Zeitung zu gelangen. Diese > Lücke > > im Retrievalsystem ist aber genau das: ein fehlendes Feature der > Systeme > > und keine Unzulänglichkeit des Formats. Ich sehe das wie Herr Enders: > mit > > den aktuellen Mitteln kann eine Zeitung bereits modelliert werden, > dazu > > braucht es keine Erweiterung des Datenformats. Was erweitert werden > > muss, sind die Möglichkeiten der Recherche- und/oder > > Präsentationssysteme, um mit digitalisierten Zeitungen vernünftig > umgehen > > zu können. > > Ich verstehe auf eine bestimmte Art die Diskussion nicht. Durch das > generalisierte Navigationsmodell in _beliebigen_ Hierarchien haben wir > im Viewer alle Voraussetzungen geschaffen, um auch das hier diskutierte > Problem lösen zu können. Es geht hier doch schlicht um die Frage: > Sollen wir weitere Strukturdaten ergänzen, um Zeitungen mit ihren > Spezifika besser darstellen zu können? Es geht nicht darum, daß wir > irgendwas am Viewer erweitern müßten, um dieses Ziel zu erreichen. > Technisch ergeben sich hier keinerlei Anforderungen. > > > Vielleicht sollten wir tatsächlich nicht 20 Jahre warten, sondern es > selbst in > > die Hand nehmen? > > Gerade weil wir uns bei der Spezifizierung des Datenformats an der > > herrschenden Katalogisierungspraxis orientiert haben, könnten wir > jetzt > > einen Katalog schaffen, der allen Bedürfnissen der Digitalisate > gerecht wird > > und zugleich auch analoge Medien verzeichnen kann. Gleichzeitig > bemühen > > wir uns bei der Spezifizierung von Datenformaten für digitalisierte > > Handschriften, Nachlässe und Zeitungen aktuell um größtmögliche > > Kompatibilität zu den digitalisierten Drucken, so dass wir sogar die > > fürchterlich nutzer-unfreundliche Trennung der Medientypen aufheben > > könnten. Der Bedarf ist offensichtlich da, wie man an zahlreichen > Meta- > > Katalogen sieht, und die Voraussetzungen sind so günstig wie nie, > weil genau > > jetzt für viele Medientypen die Grundsteine zur Massendigitalisierung > gelegt > > werden (und damit entscheidende Katalogisierungs- und Formatfragen > > diskutiert werden). Wenn diese Entscheidungen erstmal wieder > zugunsten > > irgendwelcher medientypologischer Insellösungen getroffen wurden, > > können wir wirklich mindestens 20 Jahre warten, bevor da eventuell > wieder > > was passiert. :) > > Ich bin da ganz offensichtlich deutlich skeptischer, als Sie es sind. > Daß es so viele spezialisierte Lösungen für unterschiedliche > Medientypen gibt, halte ich eben nicht für das Ergebnis eines > irrationalen Prozesses, sondern für das Ergebnis der Arbeit an > spezifischen Problemlösungen, die den Materialitäten unserer Sammlungen > geschuldet sind. Standards kann man nur da etablieren, wo es > hinreichende Gemeinsamkeiten gibt. Oder eben da, wo man sich auf > bestimmte Aspekte konzentriert. So ist z.B. die Darstellung von > Metadaten im Viewer m.E. nur deshalb in Ordnung, wie wir sie sehr > reduziert machen, weil es den Kataloglink gibt, über den ich mich als > Nutzer über jeden Titel im Detail informieren kann, wenn ich das > möchte. > > Ein letzter Aspekt noch: Wir hatten hier vor kurzem eine Diskussion > über das Europeana-Datenmodell. Schaut man sich die ersten > Importergebnisse von EuropeanLocal-D im Netz an, dann sieht man, daß > wir das Problem der Darstellung von Zeitungen und Zeitschriften auch > hier bekommen werden. Denn wenn wir das Problem so lösen würden, wie > Sie es hier vorschlagen (das Nachweissystem soll die Hierarchie > verstehen und abbilden, der Viewer dann nur noch die "Endknoten" > darstellen können, mehr nicht), dann würde das für Europeana (und alle > anderen Harvestingsysteme) ja analog gelten. Man käme nicht mehr von > der "Hauptaufnahme" zum digitalisierten Gesamtobjekt, sondern eben > immer nur in die konkreten Teilobjekte, deren Struktur im > Nachweissystem beschrieben und navigierbar sein müßte. Die Krux dabei: > EuropeanaLocal-D harvested die METS-Daten, die wir nach unserem Modell > zur Verfügung stellen. Wenn sich die Informationen über das > Gesamtobjekt aber nur aus einem noch zu schaffenden "Superkatalog" > beziehen lassen, die Informationen über die Teilobjekte nur aus einem > reduzierten Repository, dann könnte Europeana aktuell: gar nichts > harvesten und gar nicht anzeigen von unserer digitalen Pracht. Bedeutet > unterm Strich: Ihr "reduzierter Ansatz" (weg mit den Hierarchien im > Modell) führte dazu, die Komplexität des Problems in zig weitere > Systeme zu verlagern und nicht an einem Ort zu bündeln. > > Nehmen Sie als abschließendes Beispiel folgendes: > > http://www.europeana.eu/portal/full- > doc.html?uri=http://www.europeana.eu/resolve/record/09428/8911A37D3E7AF > 6888E728A5D20F10C873352513F > > Das ist der Datensatz der Trierischen Chronik in der Europeana. Den > Datensatz gibt es auch im Worldcat: > > http://www.worldcat.org/title/trierische-chronik/oclc/263724874 > > Sollen wir jetzt auch mit OCLC darüber diskutieren, daß Kataloge und > Metakataloge digitalen Medien nicht gerecht werden, nachdem wir die > ZDB/EZB-Verantwortlichen davon überzeugt haben? > > Nein, bei allem Nachdenken über Ihre Argumentation bleibe ich dabei, > daß es m.E. sehr sinnvoll ist, wie wir es bislang angegangen sind. Und > daß wir auf diesem Wege unser Ziel am besten erreichen: Hohe > Sichtbarkeit digitalisierter Materialien auf Basis eines ausgesprochen > flexiblen, aber durchaus komplexen Standardmodells. > > Beste Grüße, > Kay Heiligenhaus

Lieber Herr Heiligenhaus, das ist genau der Punkt: die existierenden Nachweissysteme sind für "Periodika in der Form, wie sie nun mal aktuell katalogisiert werden" geeignet. Die Frage (und meine Behauptung) ist aber, ob diese aktuelle Katalogisierungspraxis für Digitalisate überhaupt noch angemessen ist oder ob man nicht die Praxis (und damit die Kataloge) an die digitale Welt anpassen müsste. Meiner Ansicht nach greift die Katalogisierung da nämlich viel zu kurz, in dem sie beispielsweise nur die Gesamtheit verzeichnet, nicht aber die Fülle an verfügbaren Struktur- und Metadaten (die ja ein Novum der digitalen Welt ist). Wir haben ja faktisch bereits einen anderen Erschließungsstandard für Digitalisate als für analoge Werke - beispielsweise ein Strukturdatenset und ein METS-Profil, das beschreibt wie die Strukturen abgebildet werden sollen. Die Praxis haben wir also bereits an die digitale Welt angepasst, nur die Kataloge nicht. Wir erschließen bei einem Digitalisat also viel mehr als bei einem analogen Werk, verzeichnen aber nicht mehr in den Katalogen, weil die Kataloge diese Informationen derzeit auch gar nicht aufnehmen könnten. Die zusätzlich erschlossenen Informationen gehen für den Nutzer praktisch wieder verloren und um den verschenkten Vorteil dieser Informationen auszugleichen, basteln wir dann digitale Äquivalente von analogen Regalen, vor denen der Nutzer steht und nach einem bestimmten Muster (Jahr, Monat, Tag) die richtige Ausgabe auswählen soll. Dabei könnte er dank der von uns erschlossenen Informationen eigentlich auch mit der Eingabe des gewünschten Datums im Katalog sofort zur gesuchten Ausgabe kommen, ohne sich manuell durch Jahre und Monate hangeln zu müssen - wenn es denn einen Katalog gäbe, der diese ja bereits vorhandenen Informationen indexiert. Mein Argument ist ja: ein Digitalisat ist etwas anderes als eine Zeitung und muss deshalb auch anders katalogisiert werden. Wobei die Katalogisierungspraxis einer Zeitung natürlich nicht falsch ist, sie ist lediglich nicht umfassend genug, um einem Digitalisat gerecht zu werden. Durch die Digitalisierung erzeugen wir Unmengen zusätzlicher Informationen, die es bisher zwar implizit auch schon gab (auch eine analoge Monographie ist ja in Kapiteln strukturiert), die jetzt aber über das Objekt hinaus nutzbar gemacht werden. Diese Informationen werden aber nicht in den Katalogen nachgeführt und bleiben damit weitgehend unsichtbar und vor allem unnutzbar. Das wäre so, als würde sich die Praxis durchsetzen, künftig bei Monographien die Papierdicke zu erfassen, diese Information aber weder im Katalog sichtbar noch recherchierbar zu machen (weil die Kataloge ja bereits "Monographien in der Form, wie sie nun mal aktuell katalogisiert werden" verzeichnen können und dabei eben kein Feld für die Papierdicke vorgesehen ist). Damit der Nutzer dann aber trotzdem an diese mühsam erschlossene Information gelangen kann, legt man in jede Monographie einen Zettel, auf dem die Papierdicke steht. Das wäre doch absurd: weshalb soll sich denn die Katalogisierungspraxis nach den Katalogen richten? Sollte es nicht umgekehrt sein? Wenn sich die Praxis ändert (und das hat sie im Fall der Digitalisate bereits), dann sollten sich auch die Kataloge dieser veränderten Praxis anpassen. 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/ ________________________________________ Von: dv-technik-bounces(a)dfg-viewer.de [dv-technik-bounces(a)dfg-viewer.de] im Auftrag von Kay Heiligenhaus [kay.heiligenhaus(a)semantics.de] 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

Lieber Herr Schulze, Ich bin davon ausgegangen, daß Sie die Modellierung, die wir für Zeitschriften verwenden, bereits kennen. Ich hatte in einem meiner Postings zum Thema ja bereits auf [1] hingewiesen. Aber vielleicht ist das untergegangen oder es fehlte schlicht die korrespondierende Anschauung (auf den Viewerseiten wird das Thema bislang auch noch nicht mit konkreten Beispielen hinterlegt, was wir m.E. mal angehen sollten demnächst). Ja. Das sehe ich auch so. Aber auch bei Zeitschriften geht es primär um die einzelnen Artikel. Daneben finden sich aber ebenfalls Strukturelemente wie "Nachrichten", "Vermischtes", "Korrespondenz" usw. Ich denke aber ebenfalls nicht, daß wir für alle diese denkbaren Elemente eigene Strukturdaten schaffen müssen. Aber mein Beispiel zeigt doch, wie man auf einzelne Aufsätze (hier in einer Zeitschrift) direkt verlinken kann. Das funktionierte bei Zeitungen ganz analog. Ich interpretiere die Anforderungen hier eher so, daß _grundsätzlich_ auf den Viewer verlinkt werden sollte, ganz gleich, auf was man zeigen möchte (das Periodikum in seiner Gesamtheit, ein einzelner Jahrgang, ein Artikel). Ziel des Viewers ist doch, daß man als Nutzer immer in einer einheitlichen Umgebung landet und sich nicht mit der jeweiligen "Hausphilosophie der Darstellung" rumschlagen muß. Warum das so wichtig ist? Hier ein passendes Zitat aus dem aktuellen SPIEGEL dazu: "Doch macht es wenig Vergnügen, in der Europeana zu stöbern. Die Funde erscheinen nur mit briefmarkengroßen Vorschaubildchen. Und wer sich durchklickt, um einen Überblick zu gewinnen, wird von jedem Bild zum jeweiligen Institut weitergeschaltet. Bald irrt der Suchende ratlos herum auf einem Dutzend verschiedener Websites von Museen und Bibliotheken [...]. Sollte die DDB ebenfalls der Eitelkeit der beteiligten Institute nachgeben, droht ein babylonischer Bau mit 30000 angeschlossenen Häusern. Wer hätte die Ausdauer, sich mit deren 30000 höchsteigenen Web-Angeboten herumzuschlagen?" [2] Der Viewer ist angetreten, dieses Babylon zu verhindern. Aber irgendwie scheint dieser, m.E. eben zentrale Aspekt in der aktuellen Diskussion nicht wirklich zur Kenntnis genommen zu werden. Oder die Diagnose im SPIEGEL ist schlichtweg korrekt: Eitelkeit. Das könnte man dann aber abbilden, wie es Herr Enders bereits vorgeschlagen hat: periodical -> [Ausgabe A/B/C] -> volume -> issue -> [Edition A/B/C] -> article. Die beiden Strukturelemente in eckigen Klammern kämen neu hinzu. Den Rest kennen wir bereits (da wir bereits "periodical" als generalisiertem Oberbegriff haben, können wir uns m.E. "journal" und "newspaper" usw. schenken). Im genannten konkreten Projekt, mit dem ich mich gerade beschäftige, spielen Ausgaben und Editionen wahrscheinlich keine Rolle. Wir werden folglich wohl bei dem Modell bleiben, das wir auch schon jetzt im Viewer verankert haben: periodical -> volume -> issue Was Herrn Meyer wiederum freuen dürfte: Wir müßten rein gar nichts machen im Viewer, nicht mal zwei Strukturelemente ergänzen, die mir anfangs so im Sinn waren. Von meiner Seite auf jeden Fall vielen Dank für die sehr anregende Diskussion über das Thema! Beste Grüße, Kay Heiligenhaus [1] http://dfg-viewer.de/fileadmin/groups/dfgviewer/METS_Anwendungsprofil_2.0.p…, S. 17ff. [2] Manfred Dworschak: Babylonischer Bau. In: DER SPIEGEL 6/2010, S. 142-144, hier S. 144.

Liebe Kollegen, das sollten wir auf jeden Fall machen, finde ich. Zu besprechen gibt es tatsächlich genug. Trotz meiner anfänglichen Begeisterung für Aachen würde ich inzwischen auch Berlin vorziehen. Nicht weil ich meine Meinung über Aachen geändert hätte, sondern weil Berlin einfach näher liegt und ich faul bin. :-) Wenn ich mich recht entsinne, ist Ende April der nächste EoD-Workshop, aber ansonsten habe ich im April noch keine festen Termine. Einem Treffen nach Ostern steht also meinetwegen nichts im Weg. 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/ ________________________________________ Von: dv-technik-bounces(a)dfg-viewer.de [dv-technik-bounces(a)dfg-viewer.de] im Auftrag von Federbusch, Maria [Maria.Federbusch(a)sbb.spk-berlin.de] Gesendet: Montag, 1. März 2010 14:25 An: dv-technik(a)dfg-viewer.de Betreff: [DFG-Viewer] Treffen nach Ostern? Liebe Kollegen, Habe interessiert Ihre Diskussion verfolgt, konnte aber leider aus Zeitgründen nicht mit einsteigen. Eine Frage rein organisatorischer Art ist bei mir noch offen geblieben: Wie man ja auch an dieser Diskussion sieht, ist ja einiges zu besprechen. Wollen wir uns treffen, und wenn ja, wann? Herr Meyer hatte ja sogar Vorschläge für eine Tagesordnung gemacht. Lose war bereits die Zeit nach Ostern im Gespräch ... Die Orte Aachen und Berlin waren vorgeschlagen worden... Wie denken Sie darüber? Beste Grüße auf die Schnelle aus Berlin Von M. Federbusch

Hallo, Ich denke wir sind uns alle einige darueber, dass das jeweilige Heft die Ebene ist auf der wir die Daten managen. D.h. das Heft (issue) ist die kleinste Ebene auf der METS Dateien bereitgestellt werden. Diese METS Datei enthaelt logische als auch physische Struktur und ist der eines Bandes eines Mehrbaendigen Werkes sehr aehnlich. Analog dazu muesste also die Zeitschrift genauso wie das Mehrbaendige Werk modelliert werden koennen. Die entsprechende METS Datei saehe genauso aus und wuerde ein <div> fuer jedes einzelne Heft enthalten. Dieses Modell greift im allgemeinen bei Zeitungen jedoch zu kurz. Schliesslich muessen be Zeitungen auch noch verschiedenste Ausgaben (Editions) beruecksichtigt werden. Ausgaben koennen sich sowohl regional als auch zeitlich unterschiedlich sein. Regional: Obwohl das Zeitungsheft im wesentlichen identisch ist, werden 2 oder 4 Seiten je nach Region (Stadtteil etc.) getauscht. Zeitlich: Das gleiche Zeitungsheft kann je nach Tageszeit leicht unterschiedlich sein. Artikel koennen updates erfahren oder aber Fehler/Typos koennen korrigiert sein. Ausgaben sollten auf alle Faelle in das Modell mit einbezogen werden. Ob dies in der Serialisierung nun durch ein eigene METS Datei sein muss oder ob entsprechende relationen (explizit oder implizit) in dem MODS Datensatz hergestellt werden muesste dann diskutiert werden. An der BL verzichten wir auf die Erfassung der Edition als eigenstaendiges Objekt. Ich habe die letzte Version eines METS Profils mal angehangen (bitte nicht weiterverteilen). Dieses findet derzeit bei der Datenmigration von aelteren Digitalisaten Verwendung (kann sein, dass sich im praktischen Betrieb leichte Anpassungen ergeben haben). Fuer die serialisierung koennte man sich durchaus einen aehnlichen "Trick" vorstellen wie dies bei Zeitschriften durchaus ueblich ist: Alle Zeitschriftenhefte eines Jahres werden ueblicherweise zu einem Band zusammengefasst. Auch wenn dieser als solches nie eigenstaendig publiziert wurde liesse sich so das Problem ewig langer METS Dateien umgehen. Eine feinere Untergliederung in Monate oder Wochen halte ich fuer unnoetig. Sollte eine Navigationsstruktur entsprechend angeboten werden sollen, muesste man auf die MODS Metadaten fuer das jeweilige Heft (issue) zurueckgreifen. Dies halte ich fuer legitim. Ich denke nicht, dass die Navigationsstruktur einfluss auf die Art und Weise haben sollte, wie METS Dateien erzeugt, gemanagt oder generiert werden. Die Untergliederung in "Volumes" ist lediglich ein Workaround, um technische (Performance-) Probleme zu vermeiden. Volumes werden sicherlich nirgendwo katalogisiert werden. Bitte weder METS Profil noch die Beispiel-XML Datei weiterveteilen. Ciao Markus -----Original Message----- From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-viewer.de] On Behalf Of Kay Heiligenhaus Sent: 24 February 2010 13:51 To: dv-technik(a)dfg-viewer.de; technik(a)dfg-viewer.de Subject: Re: [DFG-Viewer] Strukturdaten für Zeitungen? Lieber Herr Meyer, 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. ;) 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. SPIEGEL ONLINE beglückt uns ja auch nicht mit seiner vollen Pracht auf der Startseite, sondern läßt mich durch einzelne Ressorts navigieren oder chronologisch im Archiv stöbern. Darüber könnte man streiten. Es ist aber m.E. nicht der Kernpunkt. 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. 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

Lieber Herr Heiligenhaus, nur ganz schnell noch: Haben wir sowas nicht schon als "section"? Was Sie beschreiben wollen, ist doch ein Abschnitt der Zeitung, nämlich alle Ausgaben eines Monats. 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/

Ja. Das müßte man m.E. wirklich berücksichtigen im Modell. Wobei ich sagen würde, daß diese Modellierungsebene tatsächlich nur in sehr spezialisierten Projekten eine Rolle spielen wird. Sie werden an der BL ja auch Gründe gehabt haben, diesen Aspekt nicht in Ihrer Modellierung zu berücksichtigen. Ja, da ließen sich noch viele, schöne Funktionalitäten ersinnen. Da würde ich aber sagen: Das ist Viewer 4.0. ;) Ja, ich bin da auch kein Freund von. Deshalb auch meine Anfrage hier in die Runde. Nach weiterem Nachdenken über das Thema scheint mir meine erste Überlegung jedoch nicht so abwegig zu sein - wobei ich weiterhin denke, daß das noch nicht der Weisheit letzter Schluß ist. Mein Punkt war aber der: Zeichnen sich Zeitungen nicht gerade durch ihren zeitlichen Bezug (durch ihre Aktualität) aus gegenüber (wissenschaftlichen) Zeitschriften? Bildet dieser zeitliche Bezug folglich nicht das Modell für die "logische Modellierung" einer Zeitung? Ja. Das sehe ich auch so. Es ist aber eine Frage, ob man diese Funktionalität ebenfalls dem Viewer anlasten sollte. Ja. Das sollte man wirklich mal tun. Dennoch betrachte ich das auch unter ergonomischen Gesichtspunkten. Es macht m.E. überhaupt keinen Sinn, eine Liste mit 18.000 issue-Einträgen im Viewer anzubieten. Das mag in Zeiten von Hochgeschwindigkeitsnetzen technisch gut übertragbar sein. Und auch aktuelle Browser werden damit zurande kommen. Dennoch wäre das vergleichbar mit dieser Bestellung in einer Bibliothek: Ich brauche die FAZ vom 18.2.2009. Ich recherchiere im OPAC und finde die Signatur Z38799/B. Auf meine Bestellung hin fährt ein Gabelstapler zur Ausleihe und ich werde aufgefordert, aus den 18.000 angelieferten Kisten mal die entsprechende Ausgabe rauszusuchen. Technisch alles machbar (wenn wir Gabelstapler 2.0 in Bibliotheken für die Ausleihe einführen). Aber nicht das, was ich unter Service in einer Bibliothek verstehe. ;) Beste Grüße, Kay Heiligenhaus