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

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/ ___________________________________________________ > -----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, 25. November 2008 18:04 > An: technik(a)dfg-viewer.de > Betreff: Re: [DFG-Viewer] zvdd/DFG-Viewer METS Profil - Version 2.0 > > Lieber Herr Meyer, > > ich muß meiner Antwort zwei Dinge vorwegschicken, denn Ihre Mail berührt nun > auch zwei Punkte, die m.E. nicht auf der Ebene des technischen Diskurses zu > verhandeln sind, sondern die Klärung dessen Voraussetzungen betreffen. > > 1. Mit dem ersten Punkt beschäftigt sich im allgemeinen die Philosophie, > vielleicht etwas spezieller die Erkenntnistheorie, traditionell gesprochen > aber die Hermeneutik: Was ist X? Im konkreten Fall: Was ist eigentlich eine > Typologie? Hierzu möchte ich zunächst aus einem Werk zitieren, das dem einen > oder anderen verrät, welche Position ich hierzu einnehme: > > "Das sollte sich an Diltheys Nachfolgern zeigen: Die pädagogisch- > anthropologischen, psychologischen, sozialogischen, kunsttheoretischen, > historischen Typenlehren, die sich damals ausbreiteten, demonstrierten ad > oculos, daß ihre Fruchtbarkeit jeweils von der geheimen Dogmatik abhing, die > ihnen zugrunde lag. An all diesen Typologien von Max Weber, Spranger, Litt, > Pinder, Kretschmer, Jaensch, Lersch usw. zeigte sich, daß sie einen begrenzten > Wahrheitswert hatten, aber denselben einbüßten, sowie sie die Totalität der > Erscheinungen erfassen, d.h. vollständig sein wollten. Solcher 'Ausbau' einer > Typologie ins Allumfassende bedeutet aus Wesensgründen ihre Selbstauflösung, > d.h. den Verlust ihres dogmatischen Wahrheitskerns. [...] Das Denkmittel der > Typologie ist in Wahrheit nur von einem extrem nominalistischen Standpunkt aus > legitimierbar." (Hans-Georg Gadamer: Hermeneutik II. Wahrheit und Methode. > Ergänzungen. Register. Tübingen 1993, S. 101) > > Ich würde mich dieser Position Gadamers in jeder Hinsicht anschließen. Sie > bedeutet übertragen auf unser hier diskutiertes Problem, daß ich den Angang, > den sie hier vorschlagen, sozusagen eine generische Typologie der Erschließung > der Welt formulieren zu können, für von Anfang an zum Scheitern verurteilt > halte. Diese Typologie wird nämlich m.E. dann gar nichts mehr unterscheiden > können (sie würde reduziert werden müssen auf genau einen Strukturtyp mit dem > Namen "Struktur") oder eben niemals fertig, weil sie sich in einer unendlichen > Diskussion aller denkbaren Unterscheidungen in einer haltlosen Liste von allen > möglichen Strukturen verlieren würde. > > 2. Bei dem zweiten Punkt dreht es sich um die Frage: Wer hat welche Beschlüsse > gefaßt? Wie war er dazu legitimiert? Welche Legitimation gibt es, diese > Beschlüsse wieder in Zweifel zu ziehen? Wer kann darüber befinden? > > Hier zitiere ich nicht, sondern versuche zunächst vorneweg noch mal in > Erinnerung zu rufen, daß sich im Rahmen der Vorbereitung der DFG-Viewer- > Umsetzung die fachlichen und technischen Vertreter von vier Bibliotheken (SLUB > Dresden, ULB Halle, BSB München, HAB Wolfenbüttel), die im VD16/17-Kontext mit > dem Thema "Massendigitalisierung" befaßten waren, ergänzt um die Vertreter der > SBPK Berlin und der SUB Göttingen, die solche Vorhaben vorbereiteten, auf eine > Strukturdatentypologie verständigten, die dann im Netz dokumentiert wurde und > ist. Alle diese Bibliotheken haben anschließend dann Maßnahmen ergriffen, ihre > jeweiligen Projekte auf diese Beschlüsse auszurichten, entsprechende Prozesse > und Schnittstellen einzurichten, die diese Beschlüsse auch bedienen konnten. > Nun führen wir eine Diskussion auf dieser _Technikliste_, angestoßen durch > eine Nachfrage von Herrn Kothe, die ganz offensichtlich zum Gegenstand hat, > diesen formalen Beschluß aufzuheben. Ungeklärt scheint mir dabei allerdings > die Frage: Ist das hier das richtige Gremium dafür? Wenn ja, wodurch ist es > legitimiert? Wenn nein, welches ist denn das entsprechende Gremium? Hinzu > kommt dann noch die Frage: Aus welchem Prozeß ist eigentlich das > Alternativmodell entstanden, der hier ganz offensichtlich zur Diskussion > gestellt wird? Welche Empirie liegt ihm zugrunde? Welche Gremien? > > Wie gesagt: Ich stelle beide Anmerkungen hier bewußt an den Anfang meiner > Mail. Ich halte es - das kann man anders sehen - eben für wichtig, sich die > "Bedingungen der Möglichkeit" seines Handelns ab und an explizit ins > Gedächtnis zu rufen, ansonsten kommt man bei bestimmten Fragen: schnell in > Treibsand. > > >> 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. >> > Genau: Mehr kann und will es zum aktuellen Zeitpunkt nicht sein. Und genau > unter diesen Voraussetzungen ist das auch so entschieden worden. > > >> 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. >> > Das ist wohl richtig. > > >> 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. >> > Nein, insoweit sind wir uns nicht einig. Ich glaube nämlich schlichtweg nicht > (s. meine Anm. 1), daß diese Aufgabe lösbar ist. Und ich glaube vor allem > nicht, daß diese Aufgabe, sollte sie doch lösbar sein, von den hier bislang > Beitragenden mit gegebenen Mitteln gelöst werden kann. > > >> 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. >> > Vollkommen richtig: zvdd ist ja schließlich auch die Abkürzung für 'Zentrales > Verzeichnis digitalisierter Drucke'. Ich halte das zvdd-Set zudem in keiner > Hinsicht für generisches, es ist einfach nur reduzierter. Zudem muß ich auf > einen Punkt aufmerksam machen, von dem ich weiß, daß er hier den wenigsten > wichtig sein wird: das zvdd-Set ist für mich allein dadurch schon mit einer > gewissen Zurückhaltung zu betrachten, daß es in formal ungenügender Form eine > Sammlung von Strukturtypen benennt: da steht 'TextSection' neben > "Announcement_Advertisement", da steht "TitlePage" neben "Imprint_Colophon". > Für einen Entwickler - dieser Hinweis sei mir in diesem Kreis gestattet - wäre > Sourcecode, der Variablen gemixt im C-Style und im Camel-Case-Style benennt, > schlichtweg ein Unding. Sowas deutet immer darauf hin, daß hier nach > unterschiedlichen Style-Guides gearbeitet wurde oder eben nachlässig mit > solchen Konventionen umgegangen wird. Wie gesagt, kein starkes Argument, aber > immerhin eine Auffälligkeit, was den Reifegrad der Dokumentation betrifft. > > >> 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. >> > Vollkommen ausgeschlossen aus meiner Sicht. Wenn Sie Handschriften im Blick > haben, mag das noch gehen. Bei Kirchenbüchern würden Sie schon in schleudern > kommen, bei sonstigen Archivmaterialien (Akten, Nachlässe, Bildsammlungen) > dann schon gänzlich und spätestens bei den Museen wäre sie zum Scheitern > verurteilt. Von daher halte ich es auch für denkbar unnötig, diesen Angang > überhaupt zu wählen. Aus meiner Sicht hat der Viewer, hat zvdd nur einen > Rahmen vorzugeben, in denen die Communities aus ihrer Fachkenntnis und > innerhalb ihrer Entscheidungsstrukturen kontrollierte Vokabularien zu > beschreiben hätten (TEI-Taxonomien, Herr Stäcker?). Für die VD16/16-Welt haben > diese das bereits getan. Aus meiner Erfahrung und Sicht taugt dieses Set auch > für das 18. bis 20. Jahrhundert. Was wollen wir zum aktuellen Zeitpunkt denn > mehr? > > >> 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. >> > Dem kann ich nicht folgen: diese Modelle richten sich gerade nicht an > unbedarfte Anwender, sondern an Leute, die sich fachlich mit der Sache > auskennen. Das aktuelle Modell wurde von ebendiesen Fachleuten ja auch mit > guten Gründen beschlossen. > > >> 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. >> > Wie gesagt: das "komplett generische Modell" gibt es aus meiner Sicht nicht. > > >> 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. >> > Der Aufwand würde vermieden, wenn man einen definierten Rahmen hätte, > innerhalb dessen die fachlich versierten Communities ihre Typologien > erstellen. Technisch halte ich das für den richtigen Angang, fachlich tue ich > das auch. Die von Ihnen vorgebrachten Argumente überzeugen mich nicht. Sie > stellen für mich auch keinen Blick über den Tellerrand dar, sondern einen > Sprung ins kalte Wasser, denn - ich wiederhole es nochmal - an der Entwicklung > einer generische Typologie haben sich schon ganz andere Leute die Finger > verbrannt. Und die wilde Mischung der Metaphern zeigt auch bereits, warum das > so ist... ;) > > Beste Grüße, > Kay Heiligenhaus >