DV-Technik

dv-technik@dfg-viewer.de

329 discussions

Beschreibungssprachen für Typologien [War: zvdd/DFG-Viewer METS Profil - Version 2.0]

by Kay Heiligenhaus

Lieber Herr Enders, auch, wenn das wohl tatsächlich unter dem Label "Viewer 3.0" zu fassen sein wird, möchte ich diesen Beitrag nochmal unter neuem Subject aus dem Gestrüpp der Diskussionsfäden reißen, da hier m.E. eine Reihe von interessanten Aspekten berührt werden: > Berechtigte Frage - die wuerde mich auch interessieren. IMHO ist es > schon so, dass bestimmte Funktionalitaeten aus Konsistenzgruenden an > den Strukturtypen haengen sollten. Das ist aus meiner Sicht der Kern der Überlegungen, die hier anzustellen sind (aus technischer Sicht): Wir haben m.E. zu unterscheiden zwischen den Aspekten der "Standardisierung/Homogenisierung/Interoperabilität" und den Aspekten der Funktionalitäten, die sich daraus ableiten. Den letzten Aspekt haben wir im Rahmen unserer Diskussionen bislang gar nicht behandelt. Die Viewer-Implementierung adressiert diese Zusammenhänge, soweit ich das Übersehen kann, bislang überhaupt nicht, sprich: für den Viewer sind alle Typen gleich (was auch aus meiner Sicht die konsequente Umsetzung dessen ist, was wir abgestimmt haben, von daher also ein Feature, kein Bug ;). > Die Granularitaet eines Inhaltsverzeichnisses bspw. fuer eine > Zeitschrift oder eines Mehrbaendigen Werkes koennte man von dieses > Strukturtypen abhaengig machen. Fuer eine konsistente Darstellung > dieser Verzeichnisse ist es m.E. sinnvoll die Strukturtypen zu nutzen > und nicht die Granularitaet der METS Datei. Dem kann ich mich nur anschließen. > Wenn ich das derzeit richtig verstehe koennte der Viewer auch ein > Inhaltsverzeichnis einer kompletten Zeitschrift anzeigen (bis hinunter > zur Artikelebene), falls das komplette Inhaltshaltsverzeichnis in einer > METS Datei enthalten waere. Ja, das könnte er. Soweit ich das ausgetestet habe, zeigt der Viewer alles an, was ihm an Strukturhierarchien in einer METS-Datei "untergeschoben" wird. Damit kann man ganz interessante Effekte erzeugen - und das war auch ein Grund, warum ich die Darstellung der Strukturdaten auf der rechten Seite mit einem gewissen Argwohn betrachte: man scrollt sich hier u.U. einen Wolf, wenn man ein recht komplexes Inhaltsverzeichnis abbilden möchte. Das ist dann alles andere als übersichtlich und sinnvoll nutzbar. Von daher passen wir z.Z. auch die Lieferung unserer METS-Container bei komplexen Werken so an, daß sie mit der aktuellen Implementierung (und nichts anderes haben wir) einigermaßen sinnvoll nutzbar sind. Das bedeutet aber eben: wir nutzen die Granularität der METS-Dateien, die geliefert werden, da wir keine funktionale Sicht auf die Strukturtypen im Viewer vorfinden. > Ich koennte mir auch gut vorstellen, dass die Anzeige der > bibliographischen Daten von dem jeweiligen Strukturtyp abhaengen > koennte. Ebenfalls ein wichtiger Aspekt! Und auch hier gilt: in der aktuellen Implementierung ist man gezwungen, die MODS-Daten dynamisch so aufzubereiten, daß man bei der Navigation z.B. durch eine Zeitschrift tatsächlich auch erkennen, wo man sich gerade befindet. > Das wir solche "Auswuechse" derzeit nicht sehen, hat IMHO damit zu tun, > dass wir es noch mit sehr homogenen METS Dateien zu tun haben. Naja, einen Testcase (aus den Zeitschriften der Deutschen Morgenländischen Gesellschaft) hatte ich ja bereits geliefert... > 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. Hm, das ist natürlich ein etwas gewagter Ansatz. Und ich glaube auch nicht, daß das ein technisch sinnvolles Konzept sein kann, auch wenn ich nicht bestreiten würde, das mancher Anwender das so sehen mag. Aus meiner Sicht ist das Thema aber bereits adressiert, da wir auf unserer letzten Sitzung in Halle besprochen hatten, daß der Viewer um einen technischen Validator ergänzt werden wird, der einem Entwickler die Informationen mitgeben wird, die er braucht, um eine konkrete Implementierung debuggen zu können. > Im Prinzip bleibt nicht viel uebrig als ein Pointer auf die > entsprechende Mapping-Information zu setzen. Es gibt zum Speichern des > pointers leider nicht so richtig viele Moeglichkeiten. > Man koennte es in der <techMD> speichern - bspw. einer techMD mit einem > bestimmten ID-Wert. Dies wuerde einen schnellen Zugriff auf den Pointer > ermoeglichen. Das finde ich einen guten Ansatz. Ich hatte bislang eher dazu tendiert, das in <mets:digiprovMD> unterzubringen, aber da paßt es nicht wirklich rein. > Vielleicht haetten wir dann auch ne Loesung die Kaffee kochen kann und > Socken stopfen ;-) Oder Gadamer-Texte in unterschiedlichen Geschwindigkeiten vorlesen. ;) > SKOS ist dafuer eigentlich recht schoen geeignet: > > <rdf:Description rdf:about="http://www.dfg- > viewer.org/registry/divtypes/zvdd/chapter"> > <rdf:type rdf:resource="http://www.w3.org/2008/05/skos#Concept"/> > <skos:prefLabel xml:lang="x-notation">chapter</skos:prefLabel> > <skos:altLabel xml:lang="en-latn">Chapter</skos:altLabel> > <skos:altLabel xml:lang="de-latn">Kapitel</skos:altLabel> > <skos:notation rdf:datatype="xs:string">chapter</skos:notation> > > <skos:definition xml:lang="en-latn">Ganz viel Erklaerung, was ein > Kapitel ist, und was nicht ;-)</skos:definition> > <skos:inScheme rdf:resource=" http://www.dfg- > viewer.org/registry/divtypes/zvdd"/> > <vs:term_status>stable</vs:term_status> > <skos:historyNote rdf:datatype="xs:dateTime">2008-11- > 25T16:42:00.000-00:00</skos:historyNote> > <skos:exactMatch rdf:resource=" http://www.dfg- > viewer.org/registry/divtypes/dfg-viewer/chapter"/> > <skos:changeNote rdf:datatype="xs:dateTime">2008-11- > 25T16:47:00.000-00:00</skos:changeNote> > </rdf:Description> > > Das waere bspw. ein SKOS Concept fuer ein Chapter des ZVDD-Concept > Schemas. > Interessant hierbei ist, das <skos:exactMatch> dieses SKOS-Concept zu > dem entsprechenden DFG-Viewer-Concept in Verhaeltnis setzt > (exactMatch). Das sieht auf den ersten Blick sehr interessant aus! Ich teile aber mit Herrn Stäcker gewisse Vorbehalte gegenüber RDF, habe aber selbst nichts zur Hand, nachdem Herr Stäcker "seine TEI-Taxonomien" hier schnell wieder aus dem Verkehr gezogen hat. Wie gesagt, das muß ich mir noch etwas genauer anschauen und vielleicht finden sich ja noch weitere Vorschläge. Beste Grüße, Kay Heiligenhaus

16 years, 1 month

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

by Kay Heiligenhaus

Lieber Herr Stäcker, > Das ist ein Punkt, der auch mir noch nicht so ganz koscher ist. Wir > haben auf der einen Seite fixe TYPEs, auf der anderen Seite LABELs, die > vermutlich aber nur an bestimmten TYPEs hängen, z.B. chapter. Der > TYPE cover wird wohl kein - anderslautendes - LABEL erhalten. Wir liefern aktuell immer ein LABEL, da der Viewer bei unseren Tests ansonsten den Bezeichner aus der Strukturdatenliste übernommen hatte, nicht die Übersetzung. Ist das inzwischen geändert, Herr Meyer? > Wir haben - auf der Basis der TEI - in WF zwei Typen unterschieden. Zum einen solche, > die gleichsam leer sind (mit <index> zu bilden; z.B. hier ist eine > Illustration oder ein Kolophon), zum anderen solche, die erfasste Texte > aufnehmen, z.B. Kapitelüberschriften. Leztere werden mit <div > type=chapter><head>Überschrift....</head></div> erfasst. Das ist in der > TEI ganz leicht, man lässt dann einfach nach Wunsch Text weg, d.h. die > Idee der Strukturdatendatei ist, dass sie eigentlich ein Volltext ist, > bei dem man alles andere weggelassen hat. Nun geht das in METS nicht > ganz so elegant. Würde man aber dem Gedanken folgen, dass die TEI für > Volltexte weiter in METS genutzt werden soll, wäre es möglicherweise > auch sinnvoll, diesem Gedanken von partiellen Textübernahmen in TEI in > METS vielleicht noch einmal etwas Aufmerksamkeit zu schenken. Was > meinen Sie? So hatte ich eigentlich das zu implementierende Konzept verstanden. Und Herr Meyer hat in seiner Mail gerade eben bestätigt, daß dieses "Feature" wohl auch entsprechend umgesetzt ist/wird (habe dazu gerade keinen Testcase zur Hand). Beste Grüße, Kay Heiligenhaus

16 years, 1 month

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

by Kay Heiligenhaus

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

16 years, 1 month

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

16 years, 1 month

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

16 years, 1 month

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

16 years, 1 month

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

16 years, 1 month

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

16 years, 1 month

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

16 years, 1 month

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

16 years, 1 month

← Newer
1
...
25
26
27
28
29
30
31
32
33
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

DV-Technik