Lieber Herr Heiligenhaus, Nein, das haben Sie völlig richtig verstanden. Aber es ist eben nur ein Feature des DFG-Viewers und keine Voraussetzung für dessen Nutzung. Ebenso wie die Lieferung verschiedener Auflösungen und einer PDF-Variante nur optional sind. Wer das nicht liefern kann/möchte, muss es auch nicht tun. Und genau so verhält es sich mit der Strukturdatentypologie: wer sich daran hält, kommt in den Genuss der Übersetzung dieser Strukturdaten, aber wer sich nicht daran hält, bekommt seine Digitalisate trotzdem angezeigt - dann eben im Wortlaut der METS-Datei. Darüber müssten wir uns tatsächlich noch verständigen. Und falls dieser Teil der Webseite ebenfalls übersetzt werden soll, müssten wir das auch sehr zeitnah tun. Viele Grüße Sebastian -- ___________________________________________________ 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 20:16 > An: technik(a)dfg-viewer.de > Betreff: Re: [DFG-Viewer] zvdd/DFG-Viewer METS Profil - Version 2.0 > > 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. > > > > 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. > > > Beste Grüße, > Kay Heiligenhaus