24 Nov
2008
24 Nov
'08
4:40 p.m.
Liebe Kolleginnen und Kollegen,
1. Der Viewer bedient sich des
Strukturdatensets, das die beteiligten Projekte untereinander abgestimmt
haben.
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.
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.
- 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.
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).
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: Mittwoch, 19. November 2008 12:43
An: technik(a)dfg-viewer.de
Cc: Stockmann, Ralf; Migl, Joachim
Betreff: Re: [DFG-Viewer] zvdd/DFG-Viewer METS Profil - Version 2.0
Lieber Herr Migl, liebe Kolleginnen und Kollegen,
mich wundert etwas, daß diese Diskussion nun nochmals aufflammt, nachdem wir
sie m.E. im beschriebenen Sinne doch bereits abgeschlossen hatten. Das
Ergebnis findet sich deshalb auch seit geraumer Zeit dokumentiert unter der
schon zitierten Adresse http://dfg-viewer.de/profil-der-strukturdaten/ und
führt nichts anderes aus als: 1. Der Viewer bedient sich des
Strukturdatensets, das die beteiligten Projekte untereinander abgestimmt
haben. 2. Projekte können weitere Strukturdaten erfassen, müssen diese aber
auf die Viewer-Typologie mappen. 3. zvdd mappt die Viewer-Typologie für die
Indexierung auf das eigene Strukturdatenset. Die Mappingregeln sind
entsprechend angegeben.
Wie Herr Stäcker nun ausgeführt hat, ist dieses zweischichtige Verfahren auch
recht zielführend:
Mienes Erachtens macht dei Differenzierung schon
Sinn, weil der Viewer
ein Tool der Massendigitalisierungsprojekte ist (war), zvdd aber über
die VD16-18 orientierten Projekte hinausgeht und daher ein abstrakteres
Modell verfolgen muss, das für die Bedürfnisse der hier dargestellten
Literaturgruppe nach meinem Gefühl zu wenig differenziert ist.
So hatte ich unsere bisherige Diskussion ebenfalls verstanden. Etwas anders
sehe ich jedoch, was Herr Migl nun ausführt:
Meine Bitte an die DFG-Viewer-Gemeinde wäre
deshalb, die Typologie
daraufhin noch mal anzusehen, dass ja auch Projekte des 18. bis 20.
Jahrhunderts ihre Dokumente im Viewer präsentieren wollen. Die zvdd
Liste war der schon vor einem Jahr unternommene Versuch, sich diesem
Problem zu stellen.
Das Viewer-Set ist aktuell - über den Einsatz an der SLUB Dresden, der ULB
Halle und der HAB Wolfenbüttel hinaus - u.a. in verschiedenen Projekten der UB
Frankfurt/M., der ULB Düsseldorf, der RLB Koblenz, der UB Trier, der StB Mainz
und der FH Potsdam im Einsatz. In allen diesen Projekten werden Materialien
aus dem 16. bis 20. Jahrhundert auf Basis dieser Typologie erschlossen. Aus
verschiedenen Diskussionen über den Einsatz der Typologie kann ich nur
berichten, daß bislang keine Wünsche nach Erweiterung, Kürzung oder Änderung
der Typologie aufgekommen sind. Aus den Diskussionen um die Vorbereitung von
VD18 kann ich ebenfalls nur berichten, daß sich die zwischen den Partnern
abgestimmte Typologie aus der Viewer-Typologie ableitet und einen reduzierten
Ausschnitt davon zur Erschließung vorsieht. Aus meiner Sicht und Erfahrung hat
sich die Typologie also für den Einsatz auch über VD16/17 hinaus bewährt.
Vielleicht haben Sie, lieber Herr Migl, hier andere Erfahrungen gemacht. Ich
denke aber, daß man dann - über die theoretische Diskussion hinaus - etwas
Empirie beisteuern sollte.
Unterm Strich denke ich deshalb, daß zvdd hier frei ist, entweder die Viewer-
Typologie zu verwenden oder eben eine eigene zu etablieren, die aus einem
Mapping der Viewer-Typologie (und weiterer, evtl. im Einsatz befindlicher
Typologien) erwächst. Technisch sollten aus meiner Sicht beide Wege gangbar
sein. Aber das muß letztlich Herr Kothe beurteilen, da mir die Details der
zvdd-Implementierung nicht bekannt sind.
Beste Grüße,
Kay Heiligenhaus