DV-Technik November 2008

dv-technik@dfg-viewer.de

10 participants
41 discussions

Re: [DFG-Viewer] zvdd/DFG-Viewer METS Profil - Version 2.0

by Kay Heiligenhaus

Lieber Herr Meyer, > 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. Ja, das finde ich eine sinnvolle Lösung. > 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. Ich denke schon, daß die abgestimmte Typologie in dieser Form übersetzt werden sollte. Bzgl. der Nutzung einer Beschreibungssprache für die Darstellung von Typologien scheinen wir aber noch einen gewissen Diskussionsprozeß vor uns zu haben. Das sollte man folglich wohl besser unter Viewer 3.0 buchen, oder? Beste Grüße, Kay Heiligenhaus

15 years, 5 months

Re: [DFG-Viewer] zvdd/DFG-Viewer METS Profil - Version 2.0

by Kay Heiligenhaus

Lieber Herr Stäcker, > ich werde das dumpfe Gefühl nicht los, dass Sie aneinander vorbei reden > und hier ein Problem hochgeschaukelt wird, dass es eigentlich gar nicht > gibt. Von Seiten der Gadamerschen hermeneutischen Anverwandlungen > liesse sich sicher noch einiges beisteuern, so ganz und gar klug finde ich > ihn nämlich für Fragen des Systems, vor allem spachlicher Systeme, > nicht ;-) Naja, über Gadamer ließ sich schon immer trefflich streiten, bevor uns hier aber Herr Enders und Herr Kothe die rote Karte zeigen, sollten wir das lieber nicht weiter in der Liste tun. > In unseren Casus kann ich eigentlich nicht erkennen, dass wir > mit den beiden jetzt vorgeschlagenen Strukturdatensets auch nur im > Entferntestesten an die Weltformel gedacht haben. Die Sets sollen vor > allem "typische" Merkmale von alten Drucken (vd16/17) oder von > Druckwerken (zvdd) abbilden, diese sind nicht - wie Sie suggerieren, > Herr Heiligenhaus - unendlich und sind daher nicht verbindlich zu > vereinbaren, sondern sie gelten materialgebunden in der Tat für alle > (!) Drucke. Da reden wir nun aneinander vorbei: ich sehe das für Drucke ebenfalls so, habe nur bezweifelt, daß man mit einer Erweiterung auf "zwei Dutzend" Strukturtypen auch alles andere (Handschriften, Kirchenbücher, Emblembücher, Noten, Akten, Nachlässe usw. usf.) generisch beschreiben kann. Man kann m.E. noch nicht mal eine vollständige Liste "alles anderen" aufstellen. Und muß das auch gar nicht tun, denn: > Jetzt können zu diesen natürlich weitere hinzutreten. Entweder > in Form von Präzisierungen: Vedute statt Illustration oder Ergänzungen > z.B. Motto. In diesem Sinne ist das System allgemeingültig, weil es ein > Grundset benennt, zugleich aber auch flexibel ist, weil es weder > hinsichtlich der Präzisierung noch der Ergänzung Einschränkungen macht. > Wenn man dies mappt (und es ist sinnvoll ein gemeinsames Grundset für > die nicht unendlich variablen Drucke, Handschriften und (das wäre zu > klären) Archivalien zu haben, dann wären Präzisierungen auf die > abstarktere Form, Ergänzungen auf die Asylform "section" zu mappen. > Letztere heisst ja nicht mehr als: hier ist ein Einschnitt oder hier > ist "etwas". So versöhnt sich Allgemeines und Spezielles. So ist es. Beste Grüße, Kay Heiligenhaus

15 years, 5 months

Re: [DFG-Viewer] zvdd/DFG-Viewer METS Profil - Version 2.0

by Kay Heiligenhaus

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. Richtig. Dennoch möchte ich nochmal kurz darauf hinweisen, daß die Strukturdatenliste dann relevant wird, wenn keine LABEL geliefert werden. Denn der Viewer hat m.E. dann dafür zu sorgen, daß die Typen auf konkrete Bezeichnungen gemapped werden und je nach Sprache, die der Nutzer gewählt hat, eben so angezeigt. Habe ich das konzeptionell bislang falsch verstanden? > 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. Das finde ich einen guten Vorschlag. Technisch würde ich allerdings weiterhin erwarten, daß das nicht in Textform geschieht (wie z.Z.), sondern in einer Form, die syntaktisch geregelt ist. Das kann auf SKOS basiert sein, das kann auf TEI basiert sein. Hier müßten man m.E. noch etwas nachdenken. Beste Grüße, Kay Heiligenhaus

15 years, 5 months

Re: [DFG-Viewer] zvdd/DFG-Viewer METS Profil - Version 2.0

by Kay Heiligenhaus

Lieber Herr Meyer, ich muß meiner Antwort zwei Dinge vorwegschicken, denn Ihre Mail berührt nun auch zwei Punkte, die m.E. nicht auf der Ebene des technischen Diskurses zu verhandeln sind, sondern die Klärung dessen Voraussetzungen betreffen. 1. Mit dem ersten Punkt beschäftigt sich im allgemeinen die Philosophie, vielleicht etwas spezieller die Erkenntnistheorie, traditionell gesprochen aber die Hermeneutik: Was ist X? Im konkreten Fall: Was ist eigentlich eine Typologie? Hierzu möchte ich zunächst aus einem Werk zitieren, das dem einen oder anderen verrät, welche Position ich hierzu einnehme: "Das sollte sich an Diltheys Nachfolgern zeigen: Die pädagogisch-anthropologischen, psychologischen, sozialogischen, kunsttheoretischen, historischen Typenlehren, die sich damals ausbreiteten, demonstrierten ad oculos, daß ihre Fruchtbarkeit jeweils von der geheimen Dogmatik abhing, die ihnen zugrunde lag. An all diesen Typologien von Max Weber, Spranger, Litt, Pinder, Kretschmer, Jaensch, Lersch usw. zeigte sich, daß sie einen begrenzten Wahrheitswert hatten, aber denselben einbüßten, sowie sie die Totalität der Erscheinungen erfassen, d.h. vollständig sein wollten. Solcher 'Ausbau' einer Typologie ins Allumfassende bedeutet aus Wesensgründen ihre Selbstauflösung, d.h. den Verlust ihres dogmatischen Wahrheitskerns. [...] Das Denkmittel der Typologie ist in Wahrheit nur von einem extrem nominalistischen Standpunkt aus legitimierbar." (Hans-Georg Gadamer: Hermeneutik II. Wahrheit und Methode. Ergänzungen. Register. Tübingen 1993, S. 101) Ich würde mich dieser Position Gadamers in jeder Hinsicht anschließen. Sie bedeutet übertragen auf unser hier diskutiertes Problem, daß ich den Angang, den sie hier vorschlagen, sozusagen eine generische Typologie der Erschließung der Welt formulieren zu können, für von Anfang an zum Scheitern verurteilt halte. Diese Typologie wird nämlich m.E. dann gar nichts mehr unterscheiden können (sie würde reduziert werden müssen auf genau einen Strukturtyp mit dem Namen "Struktur") oder eben niemals fertig, weil sie sich in einer unendlichen Diskussion aller denkbaren Unterscheidungen in einer haltlosen Liste von allen möglichen Strukturen verlieren würde. 2. Bei dem zweiten Punkt dreht es sich um die Frage: Wer hat welche Beschlüsse gefaßt? Wie war er dazu legitimiert? Welche Legitimation gibt es, diese Beschlüsse wieder in Zweifel zu ziehen? Wer kann darüber befinden? Hier zitiere ich nicht, sondern versuche zunächst vorneweg noch mal in Erinnerung zu rufen, daß sich im Rahmen der Vorbereitung der DFG-Viewer-Umsetzung die fachlichen und technischen Vertreter von vier Bibliotheken (SLUB Dresden, ULB Halle, BSB München, HAB Wolfenbüttel), die im VD16/17-Kontext mit dem Thema "Massendigitalisierung" befaßten waren, ergänzt um die Vertreter der SBPK Berlin und der SUB Göttingen, die solche Vorhaben vorbereiteten, auf eine Strukturdatentypologie verständigten, die dann im Netz dokumentiert wurde und ist. Alle diese Bibliotheken haben anschließend dann Maßnahmen ergriffen, ihre jeweiligen Projekte auf diese Beschlüsse auszurichten, entsprechende Prozesse und Schnittstellen einzurichten, die diese Beschlüsse auch bedienen konnten. Nun führen wir eine Diskussion auf dieser _Technikliste_, angestoßen durch eine Nachfrage von Herrn Kothe, die ganz offensichtlich zum Gegenstand hat, diesen formalen Beschluß aufzuheben. Ungeklärt scheint mir dabei allerdings die Frage: Ist das hier das richtige Gremium dafür? Wenn ja, wodurch ist es legitimiert? Wenn nein, welches ist denn das entsprechende Gremium? Hinzu kommt dann noch die Frage: Aus welchem Prozeß ist eigentlich das Alternativmodell entstanden, der hier ganz offensichtlich zur Diskussion gestellt wird? Welche Empirie liegt ihm zugrunde? Welche Gremien? Wie gesagt: Ich stelle beide Anmerkungen hier bewußt an den Anfang meiner Mail. Ich halte es - das kann man anders sehen - eben für wichtig, sich die "Bedingungen der Möglichkeit" seines Handelns ab und an explizit ins Gedächtnis zu rufen, ansonsten kommt man bei bestimmten Fragen: schnell in Treibsand. > 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. Genau: Mehr kann und will es zum aktuellen Zeitpunkt nicht sein. Und genau unter diesen Voraussetzungen ist das auch so entschieden worden. > 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-geförderter Digitalisierungsprojekte. Das ist wohl richtig. > 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. Nein, insoweit sind wir uns nicht einig. Ich glaube nämlich schlichtweg nicht (s. meine Anm. 1), daß diese Aufgabe lösbar ist. Und ich glaube vor allem nicht, daß diese Aufgabe, sollte sie doch lösbar sein, von den hier bislang Beitragenden mit gegebenen Mitteln gelöst werden kann. > 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. Vollkommen richtig: zvdd ist ja schließlich auch die Abkürzung für 'Zentrales Verzeichnis digitalisierter Drucke'. Ich halte das zvdd-Set zudem in keiner Hinsicht für generisches, es ist einfach nur reduzierter. Zudem muß ich auf einen Punkt aufmerksam machen, von dem ich weiß, daß er hier den wenigsten wichtig sein wird: das zvdd-Set ist für mich allein dadurch schon mit einer gewissen Zurückhaltung zu betrachten, daß es in formal ungenügender Form eine Sammlung von Strukturtypen benennt: da steht 'TextSection' neben "Announcement_Advertisement", da steht "TitlePage" neben "Imprint_Colophon". Für einen Entwickler - dieser Hinweis sei mir in diesem Kreis gestattet - wäre Sourcecode, der Variablen gemixt im C-Style und im Camel-Case-Style benennt, schlichtweg ein Unding. Sowas deutet immer darauf hin, daß hier nach unterschiedlichen Style-Guides gearbeitet wurde oder eben nachlässig mit solchen Konventionen umgegangen wird. Wie gesagt, kein starkes Argument, aber immerhin eine Auffälligkeit, was den Reifegrad der Dokumentation betrifft. > 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. Vollkommen ausgeschlossen aus meiner Sicht. Wenn Sie Handschriften im Blick haben, mag das noch gehen. Bei Kirchenbüchern würden Sie schon in schleudern kommen, bei sonstigen Archivmaterialien (Akten, Nachlässe, Bildsammlungen) dann schon gänzlich und spätestens bei den Museen wäre sie zum Scheitern verurteilt. Von daher halte ich es auch für denkbar unnötig, diesen Angang überhaupt zu wählen. Aus meiner Sicht hat der Viewer, hat zvdd nur einen Rahmen vorzugeben, in denen die Communities aus ihrer Fachkenntnis und innerhalb ihrer Entscheidungsstrukturen kontrollierte Vokabularien zu beschreiben hätten (TEI-Taxonomien, Herr Stäcker?). Für die VD16/16-Welt haben diese das bereits getan. Aus meiner Erfahrung und Sicht taugt dieses Set auch für das 18. bis 20. Jahrhundert. Was wollen wir zum aktuellen Zeitpunkt denn mehr? > 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. Dem kann ich nicht folgen: diese Modelle richten sich gerade nicht an unbedarfte Anwender, sondern an Leute, die sich fachlich mit der Sache auskennen. Das aktuelle Modell wurde von ebendiesen Fachleuten ja auch mit guten Gründen beschlossen. > 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. Wie gesagt: das "komplett generische Modell" gibt es aus meiner Sicht nicht. > 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. Der Aufwand würde vermieden, wenn man einen definierten Rahmen hätte, innerhalb dessen die fachlich versierten Communities ihre Typologien erstellen. Technisch halte ich das für den richtigen Angang, fachlich tue ich das auch. Die von Ihnen vorgebrachten Argumente überzeugen mich nicht. Sie stellen für mich auch keinen Blick über den Tellerrand dar, sondern einen Sprung ins kalte Wasser, denn - ich wiederhole es nochmal - an der Entwicklung einer generische Typologie haben sich schon ganz andere Leute die Finger verbrannt. Und die wilde Mischung der Metaphern zeigt auch bereits, warum das so ist... ;) Beste Grüße, Kay Heiligenhaus

15 years, 5 months

Re: [DFG-Viewer] zvdd/DFG-Viewer METS Profil - Version 2.0

by Kay Heiligenhaus

Lieber Herr Enders, > hey, das ist hier die Technikliste - ich weiss nicht, ob solche > abstrakten Argumentationen hier hilfreich sind ;-) Ich weiß, Sie sind inzwischen in England. Da gehört es sich nicht, in guter deutscher Tradition, auch mal etwas auszuholen und ins Reich der Bildungsgeschichte abzutauchen. ;) Aber, Scherz beiseite: Mir ist schon wichtig, sich in diesem Kontext die beiden Fragen zu stellen, die eben keine technischen sind: 1) Über was reden wir hier? 2) Wer entscheidet hier was? > Wichtig hierbei ist vor allem auch der Zweck, warum in ZVDD Typen > definiert wurden: > a) fuer die Suche und das Browsen, d.h. um diese entsprechend auf > bestimmte Strukturtypen einzuschraenken > b) fuer die Anzeige von Struktureinheiten (bspw. in > Inhaltsverzeichnissen, Trefferlisten etc). Einige der in ZVDD > aufgefuehrten Strukturtypen besitzen ansonsten keine weiteren > Metadaten, weswegen der Strukturtyp die einzige Moeglichkeit ueberhaupt > etwas anzuzeigen. Diesen Angang teilen wir - glaube ich - alle. > Ich fuerchte es gab gar keine Style-Guides ;-) > Die "TextSection" genannten Typen sind mehr oder weniger direkt aus GDZ > / DigiZeit uebernommen worden, wohingegen alle mit Unterstrich "_" > zusammengesetzten Strukturtypen mehrere Typen aus GDZ/DigiZeit > vereinen. > D.h. die Art und Weise der Benennung spiegelt die Relation zu > GDZ/DigiZeit wider. > Das ist fuer unseren Zweck natuerlich alles andere als ideal. Ich denke, man sieht diesem Set seine Genese im GDZ mit den dort bearbeiteten Materialien förmlich an. Und das ist einer der Gründe, es nicht wirklich im ausgelobten Sinne "generisch" zu finden. > >Wie gesagt: das "komplett generische Modell" gibt es aus meiner Sicht > nicht. > > Das sehe ich auch so. Daher auch mein Versuch die Diskussion mittels > SKOS (siehe andere Mail) in eine andere Richtung zu lenken. Diesen Hinweis fand ich auch sehr hilfreich. Ich bin in diesen Zusammenhängen auch zu wenig unterwegs bislang (daher auch mein Anknüpfen an die TEI-Taxonomien, die Herr Stäcker in einer Sitzung mal sehr überzeugend vorstellte). Das schaue ich mir im Nachgang aber gerne intensiver an. > Ich denke, die einzelnen Dienste (wie bspw. DFG-Viewer und ZVDD) > sollten ihr eigenes Set an Begriffen verwenden, aber dafuer sorgen, > dass diese automatisiert zur Laufzeit gemappt werden koennen. So sehe ich es auch. > Projekte, die diese Dienste nutzen wollen, koennen ebenfalls ihre > eigenen Typen verwenden. Allerdings muessen sie mittels einer SKOS- > Collection und entsprechenden Concepts ein Mapping nach ZVDD und/oder > DFG-Viewer bereitstellen. Dito. > Ich glaube naemlich nicht, dass wir hier wirklich alle Semantiken, die > Forscher nutzen moechten wirklich auf ein (generisches) Modell > zurueckfuehren kann, da sich die Perspektive auf das Dokument aendert, > wenn man inhaltlich arbeitet. > > D.h. der Fokus liegt bei obigem Ansatz weniger auf Standardisierung als > auf Interoperabilitaet - und natuerlich darauf Informationen dynamisch > zu verarbeiten und nicht mit statischen Listen zu hantieren. Dito. Dennoch meine ich, daß es sich bei der einen Typologie, die in diesem Umfeld bereits entwickelt wurde, im Kern um eine Standardisierung handelt, die für _Buchmaterialien_ vom 16. bis 20. Jahrhundert durchgängig verwendet werden kann, auch wenn nicht alle Teile in allen Jahrhunderten relevant sind. Auf die Schnelle nur - beste Grüße, Kay Heiligenhaus

15 years, 5 months

Re: [DFG-Viewer] Download / Checkout der Viewer-Sources?

by Kay Heiligenhaus

Lieber Herr Meyer, > derzeit liegt der DFG-Viewer in einem internen SVN-Repository. Ich > werde mir demnächst mal Gedanken darüber machen, wie ich das Repository > öffentlich machen könnte. Das fände ich prima! Einer der Vorzüge von "open source" ist ja tatsächlich, daß der Sourcecode öffentlich ist. ;) Ansonsten wäre das nur ein Label unter vielen. Können Sie abschätzen, wann mit einem SVN-Repository zu rechnen ist? Ich würde nämlich tatsächlich gerne etwas Zeit in eine Fallback-Lösung investieren (man sieht ja am Zusammenbruch der Europeana, was es bedeutet, wenn gute Ideen tatsächlich genutzt rsp. sabotiert werden). > Vorher stehen aber noch ein paar drängendere > Probleme auf meiner Tagesordnung, unter anderem die Verlagerung der > Gesamt-PDFs in die logische Struktur, die Verschachtelungstiefe der > Navigation und das Darstellungsproblem im IE7. Alles klar. Halte ich von der Priorisierung auch für wichtiger. Dennoch nochmal der Hinweis, daß mir das wirklich ganz ernst ist mit der skizzierten Überlegung. Die Verfügbarkeit des Viewer-Service ist im VD16/17-Umfeld von einer gewissen Kritikalität. Auch wenn ich weiß, daß ein Ausfall der Netzinfrastruktur in Dresden eher selten vorkommen wird, ist es mir wichtig, sowas nicht als einen schicksalhaften Schlag zu betrachten, sondern es bewußt in der Konzeption einer verteilten Servicearchitektur zu berücksichtigen. Nur dann, so meine Überzeugung, ist das Konzept auch wirklich belastbar. Beste Grüße, Kay Heiligenhaus

15 years, 5 months

Re: [DFG-Viewer] zvdd/DFG-Viewer METS Profil - Version 2.0

by Kay Heiligenhaus

Lieber Herr Meyer, > Gut, gut, ich gebe mich ja schon geschlagen. :) Trotzdem würde ich aber > auch nicht formulieren, dass Downloads des Gesamtwerks _immer_ in der > logischen Struktur verlinkt werden müssen. Bei PDFs hat das durchaus > einen Sinn, vorstellbar sind aber beispielsweise auch ZIP-Archive der > Images und das wäre eindeutig eine physische Struktur. > Aus Sicht des Viewers sehe ich da auch kein Problem: wenn es Downloads > der physischen und der logischen Gesamtstruktur gibt, werden eben beide > zum Download angeboten (perspektivisch jedenfalls, bislang sind > individuelle Downloads ja sowieso noch nicht implementiert). Wer dann > in beiden Fällen dasselbe PDF verlinkt hat, findet selbiges eben > zweimal im Viewer. > In der jetzigen Form können wir ja definieren, dass die logische > Struktur bevorzugt behandelt wird: ist dort ein PDF des Gesamtwerks > verlinkt, wird dieses hinter den Button im Viewer gehängt, andernfalls > wird in der physischen Struktur nach einem entsprechenden PDF gesucht. > Das würde auch Einrichtungen wie uns die Möglichkeit geben, das Gesamt- > PDF weiterhin als physische Struktur zu verlinken, solange wir darin > keine Inhaltsverzeichnisse, Titelblätter oder Metadaten einbinden (denn > dann ist es wirklich nicht mehr als die Sequenz der Einzelseiten und > gehört nicht in die logische Struktur). Prima. Damit kann ich gut leben - und das bietet genau die Flexibilität, die wir m.E. an dieser Stelle brauchen. > Ein Problem gibt es da nur: in der logischen Struktur ist nicht > eindeutig definiert, wie denn die relevante übergeordnete Struktur > identifiziert werden kann, deren PDF-Version zum Download angeboten > werden soll. Das oberste <div> kann es nicht sein, da das bei > mehrbändigen Werken und Zeitschriften keine PDF-Entsprechung hat. > Anhand des TYPE-Attributs lässt es sich auch nur bedingt unterscheiden, > da ja nicht zwingend vorgeschrieben ist, dass pro Monographie, Band, > Zeitschriftenheft, etc. eine eigene METS-Datei (mit entsprechendem > Gesamt-PDF-Download) vorhanden sein muss. Manch einer steckt vielleicht > jedes Kapitel einer Monographie in eine eigene METS-Datei mit > entsprechendem Gesamt-PDF. Dann wäre die Identifizierung nach > TYPE="monograph" nicht möglich. Außerdem würden wir damit die > Strukturdatenunabhängigkeit des DFG-Viewers aufgeben, weil er Downloads > dann nur noch verknüpfen könnte, wenn die Strukturen entsprechend der > VD16/17-Typologie benannt wurden. > In der physischen Struktur ist die Sache einfacher: dort ist es immer > das oberste <div> der Hierarchie. Das stimmt. Aber ich schlage mich - wie Herr Funk - auch immer noch mit diesem "obersten DIV" etwas herum. Spontan habe ich noch keinen rechten Vorschlag. Vielleicht hat ja jemand anderes eine zündende Idee? > Es ist kein Bug, sondern ein fehlendes Feature. :) Aber Sie haben > recht: bislang zeigt der Viewer nur die persistenten Adressen des > Gesamtwerks an. Perspektivisch sollte er natürlich auch die der > aktuellen Einzelseite anzeigen. Fände ich wichtig. Die Entwurfsfassung der Praxisregeln macht sich ja für dieses Konzept berechtigt sehr stark. Soweit ich es überblicken kann, sehen das auch sehr viele Projekte so, die entweder den URN-Granular-Ansatz hierzu aufgreifen oder eine PURL-basierte Lösung für diesen Zweck nutzen. Unterm Strich kommt dabei, gleich welcher technische Ansatz genutzt wird, das gleiche raus: Einzelseiten sind der Bezugspunkt der Referenzierung im wissenschaftlichen Kontext. Wenn ein Projekt das liefern kann, sollte es der Viewer (als primäre Anzeigeform von Digitalisaten aus DFG-Projekten) auch anzeigen können. > Wobei ich das nicht als Aufgabe des DFG-Viewers sehe, falls Sie das > damit sagen wollten. Der Viewer sollte den Identifier schlicht anzeigen > und gegebenenfalls mit den entsprechenden Resolvern verknüpfen. (Gibt > es einen internationalen Resolver für URNs? Eine automatische > Verknüpfung mit dem DNB-Resolver funktioniert doch nur bei URNs des > deutschen Namensraums, oder?) Tja, jetzt sind sie bei einem wichtigen Punkt, den die Nationalbibliotheken bislang noch nicht gelöst haben: es gibt aktuell keinen Metaresolver und keine Resolving-Registry. Soweit ich davon Kenntnis habe, arbeiten die Nationalbibliotheken aber an einer entsprechenden Lösung - warten können wir darauf aber nicht. Mein Vorschlag wäre deshalb: lösen Sie zunächst schlichtweg zum DNB-Resolver auf. Damit haben Sie Deutschland, Österreich und die Schweiz "eingefangen" (deren Namensräume verwaltet die DNB). Wenn dann - in zehn Jahren? - die ersten Digitalisate aus italienischen oder spanischen Bibliotheken mit dem DFG-Viewer angezeigt werden sollen, haben sich die Nationalbibliotheken hoffentlich bereits verständigt. ;) Wenn nicht, dann kann man die Namensräume auch im Viewer pragmatisch nachziehen. Technisch aufwendig wäre das nicht. > Ja, das liegt an der mangelnden CSS2-Unterstützung des IE7: um > semantisch korrektes Markup zu erzeugen, haben wir auf eine Tabelle > verzichtet und dafür per CSS der Image-Ansicht und der Navigation > jeweils das Verhalten von Tabellenspalten zugewiesen, damit sie nicht > umbrechen. Leider interpretiert der IE7 das nicht korrekt. Unser > Webdesigner weiß bescheid und brütet an einer Lösung. :) Tja, das Elend, wenn man Webseiten barrierefrei gestalten will. Da wünsche ich Ihrem Designer: allen Erfolg! Beste Grüße, Kay Heiligenhaus

15 years, 5 months

WG: zvdd MODS Anwendungsprofil v1.0

by Otte, Karsten

Liebe Kolleginnen und Kollegen, Vergangene Woche habe ich das zvdd MODS Anwendungsprofil an die Liste support(a)dfg-viewer.de verschickt, aber damit wohl leider nicht alle interessierten KollegInnen erreicht. Daher nun das Ganze auch noch einmal an die "technik"-Liste. Schöne Grüße Karsten Otte Niedersaechsische Staats- und Universitaetsbibliothek Abteilung Handschriften und Alte Drucke Papendiek 14 37073 Goettingen Tel. ++49 551 39-13534 o. -5367 Fax ++49 551 39-5674 o. -5384 Email: otte(a)sub.uni-goettingen.de -----Ursprüngliche Nachricht----- Von: Otte, Karsten Gesendet: Montag, 17. November 2008 11:19 An: 'support(a)dfg-viewer.de' Betreff: zvdd MODS Anwendungsprofil v1.0 Liebe Kolleginnen und Kollegen, Im Anhang finden Sie die offizielle Version 1.0 des zvdd MODS Anwendungsprofils, sowohl als pdf- als auch (zum Vergleichen mit früheren Versionen) als doc-Datei. Das "Change log" habe ich für die v1.0 "auf Null gesetzt", daher sende ich auch das alte "Change log" mit den dokumentierten Änderungen nochmal separat mit. Herrn Meyer bitte ich, (nach dem Urlaub) das Profil auf der Viewer-Seite zu veröffentlichen. Herzliche Grüße von Karsten Otte Niedersaechsische Staats- und Universitaetsbibliothek Abteilung Handschriften und Alte Drucke Papendiek 14 37073 Goettingen Tel. ++49 551 39-13534 o. -5367 Fax ++49 551 39-5674 o. -5384 Email: otte(a)sub.uni-goettingen.de

15 years, 5 months

Re: [DFG-Viewer] zvdd/DFG-Viewer METS Profil - Version 2.0

by Kay Heiligenhaus

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

15 years, 5 months

Re: [DFG-Viewer] Einzelseiten-PDF zum Download

by Kay Heiligenhaus

Lieber Herr Meyer, > das Gesamt-PDF wird wie die Einzelseiten mit einer FILEID versehen und > dann in der physischen StructMap nicht mit einer "page" verknüpft, > sondern mit der gesamten "physSequence". Das ist eine der metaphysischen Fragen, die sich aus dem komplexen Dokumentenmodell ergeben. ;) Ich denke, für den aktuellen Zweck ist es leidlich gleichgültig, ob man aus der log. structMap verknüpft oder aus der phys. Für beides ließen sich auch hinreichende Gründe angeben. Spätestens beim Download von Kapiteln, Abschnitten usw. würden man sich aber eindeutig auf der log. Modellierungsebene befinden und folglich auch von dort verknüpfen müssen. Da letzteres aber im Viewer nicht vorgesehen ist (obgleich die DFG-Praxisregeln diese Möglichkeit explizit nahelegen), stellen wir das dann entsprechend bei uns um. Beste Grüße, Kay Heiligenhaus

15 years, 5 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

DV-Technik November 2008