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