New subject: zvdd/DFG-Viewer METS Profil - Version 2.0

25 Nov 2008

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

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