Re: [DFG-Viewer] zvdd/DFG-Viewer METS Profil - Version 2.0

Lieber Herr Heiligenhaus, da scheint es wohl verschiedene Vorstellungen davon zu geben, welches Ziel unser Strukturdatenset primär verfolgt. Für mich stellt das Strukturdatenset in erster Linie einen Konsens der VD16/17-Projekte dar und ist entsprechend für diese verpflichtend. Darüber hinaus ist es eine starke Empfehlung an vergleichbare Projekte, die sich in diesem Set wiederfinden. Mehr kann es aber nicht sein. Es gibt unzählige Projekte, die dieses Strukturdatenset nicht verwenden können, weil es ihren Anforderungen nicht gerecht wird. Sie nennen selbst ein Beispiel: die Kirchenbücher. Ich denke, da müssen wir uns mit dem DFG-Viewer deutlich aus dem VD16/17-Kontext lösen. Natürlich ist er vor diesem Hintergrund entstanden (und viele Formulierungen auf der Webseite sind auch nur vor diesem Hintergrund zu verstehen), aber er hat sich inzwischen aus diesem Kontext emanzipiert. Diese Liberalisierung wurde nicht zuletzt von der DFG selbst ausgelöst, in dem sie den Viewer in den Entwurf der Praxisregeln aufgenommen hat. Denn die Praxisregeln gelten schließlich für alle Digitalisierungsprojekte der DFG und nicht nur für solche im VD16/17-Kontext. Der Viewer muss künftig also all diesen Projekten gerecht werden. Deshalb haben wir den Eigenheiten der Zeitschriften-Katalogisierung Rechnung getragen und deshalb müssen wir uns aber nun auch in Fragen der unterstützten Strukturdaten so generisch wie möglich verhalten. Der DFG-Viewer ist eben nicht mehr nur das primäre Anzeigeinstrument des VD16/17, sondern auf dem besten Weg zum primären Anzeigeinstrument aller DFG-geförderter Digitalisierungsprojekte. Nicht ganz: ich sage nicht, dass wir etwas regeln, das wir gar nicht regeln müssten. Sondern ich sage, dass wir diese Regeln, die wir für einen begrenzten Kontext (nämlich VD16/17) aufgestellt haben, nun nicht ohne Weiteres auf den viel größeren Kontext aller den DFG-Praxisregeln unterworfenen Projekte übertragen können. Wir müssen die Regeln entweder generell anpassen oder seperate Regeln für jeden einzelnen Kontext entwerfen. Mit anderen Worten: entweder wir finden ein Strukturdatenset, das den Bedürfnissen aller Digitalisierungsprojekte der DFG gerecht wird, oder wir entwerfen für jedes dieser Projekte (oder zumindest jeden größeren Kontext) ein eigenes Strukturdatenset. Bislang gehen wir den zweiten Weg (1 Set für VD16/17, 1 Set für Handschriften, 1 Set für Kirchenbücher, etc.). Nun wäre _ein_ Standard als Austauschformat aber natürlich erstrebenswert. Soweit sind wir uns glaube ich einig. Uneinigkeit herrscht dann in der Frage, welches Set diesen generischen Standard darstellen könnte und wie wir ihn kommunizieren. Das VD16/17-Set kann das nicht leisten, da es zu speziell ist. Das ZVDD-Set ist schon deutlich generischer, aber auch immer noch medientypologisch auf Drucke ausgerichtet. Denkbar wäre aus meiner Sicht jedoch, dass ZVDD-Set um wenige Strukturdaten anderer Medientypen zu ergänzen, um ein solches generisches Standard-Set zu erzeugen. Das sollte möglich sein, ohne mehr als ca. zwei Dutzend Strukturdaten benennen zu müssen. Die Frage der Kommunikation wäre dann: Wieviele Optionen bieten wir dem Anwender an? Eine oder mehrere? Modell 1: Jeder Anwender verwendet nach Herzenslust Strukturdaten und führt ein Mapping auf eines von mehreren allgemeineren Sets durch (je nach Anforderungen seines Projekts), bevor er seine Daten weitergibt. Bei Bedarf werden diese Strukturdaten dann wiederum auf ein noch allgemeineres Set gemappt (durch ZVDD zum Beispiel). Das ist das aktuelle Modell, wie es auf der Viewer-Webseite beschrieben ist. Nachteile: Es gibt eine Vielzahl von Sets, die den unbedarften Anwender irritieren und von Zielsystemen wie ZVDD und DDB mit einem Mapping unterstützt werden müssen. Modell 2: Jeder Anwender verwendet nach Herzenslust Strukturdaten und führt ein Mapping auf ein komplett generisches Set durch, bevor er seine Daten weitergibt. Dieses Set muss dann nicht weiter gemappt werden, sondern stellt gewissermaßen einen offenen Standard als Austauschformat dar, den jedes Zielsystem beherrscht. Vorteile: ZVDD braucht nur ein einziges Mapping, um daraus sein internes Format zu erzeugen, und auch kommende Anwendungen wie die DDB könnten das Format nachnutzen, da es generisch genug ist, um auch deren Anforderungen zu genügen (in dem es beispielsweise nicht nur Drucke berücksichtigt). Aus meiner Sicht ist das das erstrebenswertere Modell. Ich gebe Ihnen völlig recht, dass wir in jedem Fall eine Standardisierung anstreben sollten - auch im Bereich der Strukturdaten. Wir müssen dabei aber über den Tellerrand schauen, denn der DFG-Viewer soll nicht mehr nur die Bedürfnisse des VD16/17 bedienen. Inzwischen kann er auch mit Zeitschriften umgehen und perspektivisch soll die Präsentation von Handschriften möglich sein, denn auch deren Digitalisierung ist Gegenstand von DFG-Projekten, für die wiederum die Praxisregeln gelten. Das ist eine Entwicklung, die wir damals in Halle noch nicht absehen konnten, als wir die Strukturdatenliste vereinbart haben. Nun ist die Frage, wie wir auf die neue Situation reagieren. Ein Beharren auf alten Entscheidungen ist da nicht unbedingt der richtige Weg, auch wenn ein Umdenken natürlich wieder mit Aufwand verbunden ist. Da müssen wir nun Aufwand und Nutzen abwägen. Meine persönliche Meinung dazu ist, dass der Nutzen den Aufwand in jedem Fall rechtfertigt, zumal wir langfristig mit der Pflege und Implementierung verschiedener Strukturdatensets auch eine Menge Aufwand hätten. Viele Grüße Sebastian Meyer -- ___________________________________________________ Sebastian Meyer Abteilung Informationstechnologie Referat Entwicklung Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) 01054 Dresden Besucheradresse: Zellescher Weg 18 Tel.: +49 351 4677-206 Fax: +49 351 4677-711 Mail: smeyer(a)slub-dresden.de Web: http://www.slub-dresden.de/ ___________________________________________________