Lieber Herr Heiligenhaus, 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. Es gibt unzählige Projekte, die dieses Strukturdatenset nicht verwenden können, weil es ihren Anforderungen nicht gerecht wird. Sie nennen selbst ein Beispiel: die Kirchenbücher. 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-g

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. 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. 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. Die Frage der Kommunikation wäre dann: Wieviele Optionen bieten wir dem Anwender an? Eine oder mehrere? 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. 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. 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. 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: Dienstag, 25. November 2008 13:47 > An: technik(a)dfg-viewer.de > Betreff: Re: [DFG-Viewer] zvdd/DFG-Viewer METS Profil - Version 2.0 > > Lieber Herr Meyer, liebe Kolleginnen und Kollegen, > >> 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. :) > 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. > >>> 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. > 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. > >> 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

Ich sehe den DFG Viewer jedoch immer in einem Paket mit ZVDD. Im Zweifelsfall werden die Inhaltsanbieter mittels des DFG-Viewers checken, ob ihre Daten valide sind und annehmen, dass diese dann auch durch ZVDD verarbeitet werden koennen. Genau das halte ich auch fuer sinnvoll, auch wenn der DFG-Viewer nicht unbedingt als Validator fuer ZVDD geplant war.

Ich sehe den DFG Viewer jedoch immer in einem Paket mit ZVDD. Im Zweifelsfall werden die Inhaltsanbieter mittels des DFG-Viewers checken, ob ihre Daten valide sind und annehmen, dass diese dann auch durch ZVDD verarbeitet werden koennen. Genau das halte ich auch fuer sinnvoll, auch wenn der DFG-Viewer nicht unbedingt als Validator fuer ZVDD geplant war.