25 Nov
2008
25 Nov
'08
8:15 p.m.
Lieber Herr Meyer,
mag sein, dass meine Vorstellung einer
Strukturdatentypologie für alle
DDB-relevanten Medien utopisch ist. Es ist aber nun auch nicht so, dass
ich damit "die ganze Welt" beschreiben will. In sofern trifft Ihr Zitat
die Sache auch nicht hundertprozentig. Natürlich sind Archivalien
anders als Museumsobjekte und anders als Drucke, Zeitschriften und
Handschriften aus Bibliotheken. Es geht hier aber nur um deren innere
Strukturen und die erscheinen mir als Laien doch - abgesehen von
abweichenden Bezeichnungen - sehr vergleichbar. Oder um wieder eine
Metapher zu bemühen: Zwar lassen sich Äpfel und Birnen äußerlich nicht
vergleichen, im Innern sehen sie aber doch gleich aus. :)
Eine schöne Erweiterung dieser bekannten Metapher. Ich hoffe, hier lesen keine Biologen
mit, die uns den Unterschied dann erklären. ;) Aber dennoch denke ich, daß es wichtig ist
festzuhalten: Wir werden es hier mit verschiedenen Typologien zu tun haben, die sich
strukturell vergleichbar gestalten, aber eben semantisch oder auch nur vom verwendeten
Vokabular jeweils anders. Das spricht dafür, auf Beschreibungssprachen zurückzugreifen,
die den jeweiligen Beschreibungsraum syntaktisch festlegen, die konkreten Ausprägungen
(und Mapping-Regeln) jedoch den Communities überlassen.
Aber lassen wir das, denn Sie haben recht damit, dass
wir weder das
Gremium sind, das solche Entscheidungen treffen müsste, noch derzeit
die akute Notwendigkeit besteht, hier überhaupt zu einem Ergebnis zu
kommen. Uns sollten nur zwei Dinge beschäftigen: der DFG-Viewer und die
VD16/17-Projekte. Für ersteren ist die ganze Debatte irrelevant, weil
der Viewer einfach anzeigt, was er bekommt (egal ob es auf
irgendwelchen Strukturdatenlisten steht oder nicht), und für letztere
ist die Sache bereits entschieden.
Richtig. Dennoch möchte ich nochmal kurz darauf hinweisen, daß die Strukturdatenliste dann
relevant wird, wenn keine LABEL geliefert werden. Denn der Viewer hat m.E. dann dafür zu
sorgen, daß die Typen auf konkrete Bezeichnungen gemapped werden und je nach Sprache, die
der Nutzer gewählt hat, eben so angezeigt. Habe ich das konzeptionell bislang falsch
verstanden?
Der entscheidende Punkt, um den es mir nun geht (da
die finale
Überarbeitung vor der Übersetzung ansteht), ist folgender: Soll die
DFG-Viewer-Webseite eine Arbeitsanleitung und Dokumentation für VD16/17
(und eventuell das kommende VD18) sein oder soll sie den DFG-Viewer als
unabhängigen Webservice für alle DFG-Projekte beschreiben? Meiner
Ansicht nach ist inzwischen letzteres der Fall. (Das war zu Anfang
unserer Treffen in Halle noch anders - die Gründe für den Wandel habe
ich in meiner letzten Mail bereits dargelegt.)
Da sind m.E. Ihre Argumente recht stark. Letztlich müßte hierzu aber derjenige etwas
sagen, der die Praxisregeln ausarbeitet. Herr Stäcker?
Wenn die Viewer-Webseite aber den Viewer dokumentieren
soll, dann wären
die Strukturdatensets dort eigentlich falsch, denn sie spielen für den
Viewer keine Rolle.
Wie gesagt, hier gilt aber m.E. weiterhin o.g. Fallbackvariante, sofern keine Labels
geliefert werden. Wir planen nämlich z.Z. konkret, keine Labels mehr bei Strukturdaten zu
liefern, die keine "Abschnitte" mit individuell erfaßter "Bezeichnung"
sind (also Titelseite, Inhaltsverzeichnis, Register usw.). Das genau aus dem Grund, um
hier eine mehrsprachige Anzeige überhaupt zu ermöglichen.
Und damit sind sie auch für Projektnehmer
unerheblich, die die Praxisregeln der DFG erfüllen müssen. Die brauchen
sich nämlich streng genommen um Strukturdatentypologien überhaupt nicht
zu kümmern. So wie während der Sitzungen in Halle also
berechtigterweise immer gefordert wurde, die ZVDD-Anforderungen in der
Dokumentation nicht mit den (geringeren) Anforderungen des Viewers zu
vermengen, damit für den Anwender die Praxisregel-Hürde so niedrig wie
möglich und die Anforderungen so klar wie möglich sind, so müssten wir
nun auch konsequenterweise fordern, die VD16/17-Anforderungen nicht auf
den Viewer zu übertragen.
Das sehe ich ebenfalls nicht ganz so. Ganz sicher - so zumindest mein Verständnis - werden
die Praxisregeln nicht alle Projekte darauf verpflichten, Strukturdaten zu erfassen. Wenn
aber Strukturdaten erfaßt werden, dann sollte dazu auch kontrollierte Vokabularien
verwendet werden. Für VD16/17 also eben die Typologie, die seit längerem vorliegt. Ich
sehe das sogar - basierend auf meinen Erfahrungen in anderen Projekten - für alle Projekte
so, die sich der Digitalisierung von Buchmaterialien zuwenden. Dafür ist das Set m.E.
bestens geeignet.
Der Viewer verlangt keine normierten
Strukturdaten, das tun nur VD16/17 und ZVDD - und der Viewer darf sie
auch gar nicht fordern, weil er sonst nicht mehr dem Anspruch des
primären Anzeigeinstruments für alle DFG-geförderten
Digitalisierungsprojekte gerecht werden kann.
Ja, mit der einen Implikation (Fallback), die ich genannt hatte.
Mein Vorschlag: wir nutzen die Viewer-Webseite als
Plattform, um dort
die verschiedenen Strukturdatensets gleichberechtigt zu sammeln und zu
dokumentieren. Wir sollten das aber deutlich von der eigentlichen
Viewer-Dokumentation trennen, denn damit hat es nichts zu tun.
Das finde ich einen guten Vorschlag. Technisch würde ich allerdings weiterhin erwarten,
daß das nicht in Textform geschieht (wie z.Z.), sondern in einer Form, die syntaktisch
geregelt ist. Das kann auf SKOS basiert sein, das kann auf TEI basiert sein. Hier müßten
man m.E. noch etwas nachdenken.
Beste Grüße,
Kay Heiligenhaus