25 Nov
2008
25 Nov
'08
1:47 p.m.
Lieber Herr Meyer, liebe Kolleginnen und Kollegen,
Genau so verhält es sich! Nur wie soll zvdd "erkennen", welches Mapping hier
anzuwenden ist? Das scheint mir eigentlich die zentrale Frage zu sein, um die wir hier die
ganze Zeit rumschleichen: zvdd würde wohl am liebsten die Daten so bekommen, wie sie sie
intern abstrahieren: im zvdd-Format. Das war das Eingangsstatement von Herrn Kothe in
dieser Sache. Nun stellen wir aber übereinstimmend fest, daß die Projekte ihre Daten - je
nach Kontext - in anderen Typologien liefern, die sie für Materialadäquat befinden und für
die sie auch noch Mapping-Regeln auf das zvdd-Format ausgearbeiten. Nur fehlt zvvd aktuell
schlicht der explizite Hinweis, welches Mapping hier anzuwenden ist. Die Lösung des
Problems wäre folglich, daß wir die Art der verwendeten Typologie explizieren müssen,
damit a) der Viewer weiß, welche Übersetzungen er im konkreten Fall ggf. zu verwenden hat
und b) zvdd weiß, welches Mapping anzuwenden ist, um auf die interne (!) Generalisierung
zu schließen. Technisch bedeutete das: a) Wir müßten einen Hinweis auf die verwendete
Typologie im METS-Format unterbringen. b) Wir sollten uns auf eine formale
Beschreibungssprache einigen (Herr Stäcker hatte dazu bereits auf Möglichkeiten im
TEI-Format hingewiesen), die die verschiedenen Ansprüche automatisiert bedienen kann
(Übersetzungen für den Viewer, Mappings für zvdd). Damit hätten wir eine Lösung, die aus
meiner Sicht a) hinreichend generalisiert ist und b) vollkommen transparent zu
implementieren ist.
aber nur in sofern, dass er dafür interne
Übersetzungen bereithält, die
er statt des Wortlauts des TYPE-Attributs anzeigen kann, falls kein
anderslautendes LABEL-Attribut belegt ist. Das ließe sich prinzipiell
aber in gleicher Weise auch für das ZVDD-Strukturdatenset umsetzen.
Ich möchte nochmal auf die Formulierungen auf den offiziellen Viewer-Seiten im Netz
verweisen:
"Hier finden Sie eine standardisierte Liste von Strukturelementen und deren
internationalen Entsprechungen. Wenn Sie intern weitere Strukturdaten erfassen, bilden Sie
diese einfach auf allgemeinere Elemente dieser Liste ab. Die Tabelle liefert außerdem die
jeweiligen XML-Bezeichner für die Strukturdaten und deren Entsprechung im Zentralen
Verzeichnis Digitalisierter Drucke (ZVDD)."
(http://dfg-viewer.de/profil-der-strukturdaten/)
Wenn ich ihren Ausführungen hier richtig folge, dann sagen Sie in der Konsequenz:
"Wir regeln hier etwas, was wir eigentlich gar nicht regeln müßten. Dem Viewer ist
das technisch ziemlich gleich." Darum stellt sich mir die Frage: Warum schreiben wir
dann auf den Seiten überhaupt etwas dazu? Aus welchem Grund haben wir eine lange
Diskussion über die Normierung eines kontrollierten Vokabulars geführt, wenn sich zum
Schluß kein technisches System mit diesem Vokabular tatsächlich beschäftigt?
Ich halte das für kommunikativ etwas brisant: Der Leser, der ohne entsprechende
Hintergrundinformationen auf die Viewer-Seiten kommt und eine technische Architektur für
die eigene Datenmodellierung und Datenlieferung daraus ableitet, liest die o.z.
Ausführungen ganz anders. Und er liest sie wahrscheinlich auch so, wie wir es bei unseren
Abstimmungen darüber gemeint haben: 1. Modelliere Deine Daten nach eigenen Bedürfnissen.
2. Liefere Deine Daten auf Basis eines kontrollierten Vokalbulars, damit Dich auch jemand
anderes verstehen kann, der in ähnlichen Zusammenhängen arbeitet.
Ich persönliche halte das für eine wichtige und so auch gewollte Botschaft! Und wir
sollten m.E. nicht den Fehler begehen, die technische Implementierung, die sie nun gewählt
haben, zu verwechseln mit den Zielen, die wir bei der Konzeption m.E. verfolgt haben.
2. Projekte können weitere Strukturdaten
erfassen, müssen diese aber
auf die Viewer-Typologie mappen.
Von "müssen" kann hier doch keine Rede sein. Es ist vielmehr eine
Empfehlung, aber keine Verpflichtung. Dem Viewer jedenfalls ist es
völlig gleichgültig, wie Sie Ihre Strukturdaten nennen. :) 3. zvdd mappt die Viewer-Typologie für die
Indexierung auf das eigene Strukturdatenset. Die Mappingregeln sind
entsprechend angegeben.
Richtig. Und an dieser Stelle kommt ZVDD dann auch die Empfehlung aus
dem VD16/17-Kontext zugute. Dafür existiert nämlich ein Mapping, was
bei völlig frei vergebenen Bezeichnungen für Strukturdaten nicht der
Fall ist. Ich sehe das Problem nicht so richtig:
- Für den Viewer ist es egal, welche Strukturdaten Sie erfassen und wie
Sie sie nennen.
- Wenn Sie jedoch in ZVDD indiziert werden möchten, müssen Sie sich an
die entsprechende ZVDD-Typologie halten.
- Einzige Ausnahme: Wenn sie aus dem VD16/17-Kontext kommen, haben Sie
eine speziellere Typologie zur Verfügung, die ZVDD dank des Mappings
aber auch versteht.
Das habe ich aus dem Anfangsposting von Herrn Kothe anders gelesen: Hier kam der Wunsch
nach einem einheitlichen Format zum Ausdruck, das alle für alle Zwecke verwenden. Das
würde dann aber in der Tat bedeuten, daß wir uns auf ein gemeinsames verständigen (also
entweder das aktuelle Viewer-Format oder eben das zvdd-Format). Von einem Mapping war im
Posting von Herrn Kothe keine Rede. Die o.b. Implementierung könnte uns m.E. aus diesem
Dilemma befreien.
- Denkbar wären perspektivisch noch weitere
spezifische
Strukturdatentypologien anderer Digitalisierungsprojekte (im
Handschriftenbereich wird beispielsweise aktuell an einer eigenen
Strukturdatentypologie gearbeitet), die dann jedoch auch ein Mapping
auf die ZVDD-Typologie mitbringen müssen, wenn sie von ZVDD indiziert
werden sollen.
So ist es!
Ich sehe das ZVDD-Set als kleinsten gemeinsamen
Nenner, während das
VD16/17-Set eine speziellere Ausprägung für den Einsatz in einem
bestimmten Kontext darstellt. Um auf hohem Level kompatibel zu bleiben,
gibt es für das VD16/17-Set ein Mapping auf das allgemeinere ZVDD-Set.
Ich sehe da keinen Alleinstellungsanspruch des VD16/17-Sets, dafür ist
es auch viel zu speziell. In einem anderen Kontext wird es nicht
anwendbar sein, wie beispielsweise für Handschriften. Deshalb wird -
analog zur VD16/17-Liste - derzeit eine Strukturdatenliste für den
Kontext Handschriften erarbeitet. Das wird ebenfalls ein spezielles Set
sein, das aber prinzipiell ebenfalls auf das ZVDD-Set gemappt werden
kann (auch wenn das in diesem Fall unsinnig ist).
Vollkommen einverstanden! Wir verwenden z.Z. z.B. auch eine eigene Typologie für die
Erschließung von Kirchenbüchern aus Archiven. Da kann man mit der VD16/17-Typologie auch
leidlich wenig anfangen. Zieht man nun aber die m.E. richtigen Konsequenzen aus diesen
Umständen, dann landet man evtl. bei dem Vorschlag, den ich oben gemacht habe und den Sie
mir Ihrem Posting auch nahelegen.
Jetzt könnte uns Herr Stäcker noch bzgl., der TEI-Taxonomien (das ist irgendwie bei mir
hängegengeblieben) auf die Sprünge helfen...
Beste Grüße,
Kay Heiligenhaus