DV-Technik November 2008

dv-technik@dfg-viewer.de

10 participants
41 discussions

by Dr. Thomas Staecker

Lieber Herr Funk, verzeihung, dass es so kleckerweise kommt. Ich habe noch einen Ergaenzungswunsch, der auf unsere jüngsten Diskussionen Bezug nimmt. Wir sollten die Funktion des LABEL Attributs beschreiben und auch im Beispiel zeigen:  <mets:div CONTENTIDS="urn:nbn:de:gbv-7-gdz-12345678-ex11__LOG_01" DMDID="DMD_01" ID="ex11__LOG_01" TYPE="Chapter" LABEL="Das erste Kapitel"> Viele Gruesse, IHr Th. Staecker -- Dr. Thomas Staecker (Leiter Abteilung Alte Drucke, Digitalisierung) Herzog August Bibliothek - Postfach 1364 - D-38299 Wolfenbuettel Tel. +49(0)5331/808-119 - email: staecker(a)hab.de

15 years, 5 months

Viewer-Webseite, die Zweite

by Meyer, Sebastian

Liebe Kolleginnen und Kollegen, den Vorschlägen von Frau Sommer und Herr Heiligenhaus folgend habe ich die Viewer-Webseite nochmal etwas umgestaltet. Die Strukturdaten haben nun wieder einen Platz auf oberster Navigationsebene und einen neuen Einleitungstext spendiert bekommen. (Vielen Dank dafür, Frau Sommer!) Da das Laboratorium namentlich keinen Anklang gefunden hat und ohne die Strukturdatenliste auch inhaltlich nichts mehr zu bieten hat, habe ich es wieder entfernt. Die Mailinglisten finden sich nun wieder unter "Kontakt". Viele Grüße Sebastian Meyer -- ___________________________________________________ Sebastian Meyer Abteilung Informationstechnologie Referat Entwicklung Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) 01054 Dresden Besucheradresse: Zellescher Weg 18 Tel.: +49 351 4677-206 Fax: +49 351 4677-711 Mail: smeyer(a)slub-dresden.de Web: http://www.slub-dresden.de/ ___________________________________________________

15 years, 5 months

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

by Kay Heiligenhaus

Lieber Herr Mahnke, > die Synchronisation mit dem Dresdener Repository funktioniert nun: > https://develop.sub.uni-goettingen.de/repos/dfg-viewer/ Prima, vielen Dank! Läßt sich problemlos auschecken. Bin gespannt. Beste Grüße, Kay Heiligenhaus

15 years, 5 months

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

by Kay Heiligenhaus

Lieber Herr Meyer, > Herr Mahnke aus Göttingen hat mich darauf aufmerksam gemacht, dass er > mit mir bereits vor einiger Zeit einen öffentlichen Mirror des DFG- > Viewer-Repositories in Göttingen eingerichtet hatte. Das hatte ich > völlig vergessen. Derzeit gibt es noch ein kleines Problem mit dem > regelmäßigen, automatisierten Abgleich der Repositories, das sollte > aber bald behoben sein. Prima. Ich bin gespannt. Unsere Entwickler freuen sich auf jeden Fall schon auf frische open sources! ;) Beste Grüße, Kay Heiligenhaus

15 years, 5 months

Re: [DFG-Viewer] Viewer-Webseite

by Kay Heiligenhaus

Lieber Herr Meyer, prima, vielen Dank für die Verlinkung der aktuellen Dokumentationen! > Die Strukturdatenliste und den Hinweis auf die Mailinglisten habe ich in einen Laborbereich > ausgelagert, damit sie stärker von der Anwendungsdokumentation getrennt sind. Hm, das finde ich persönlich keine überzeugende Lösung. Weder finde ich den Begriff "Laboratorium" so wirklich gelungen, noch denke ich, daß sich die Strukturdatenliste in einem solchen befindet. Schließlich ist die ja nichts für Hobbychemiker, sondern was für die Projekte, die sich mit gedruckten Materialien beschäftigen. Ich fände es besser, den bisherigen Punkt "Profil der Strukturdaten" auf der Hauptebene zu behalten und darunter dann die bislang vorliegenden Profile (z.Z. ebene genau eines für Druckwerke) zu verlinken. Auf der Hauptseite könnte ein knapper Text stehen, der das Konzept erläutert. Was denken die anderen? Beste Grüße, Kay Heiligenhaus

15 years, 5 months

Viewer-Webseite

by Meyer, Sebastian

Liebe Kolleginnen und Kollegen, ich habe nun die Texte der Viewer-Webseite noch einmal überarbeitet und die aktuellen Profile verlinkt. Ich hoffe, damit verfügt der DFG-Viewer nun über eine nachvollziehbare Dokumentation. Die Strukturdatenliste und den Hinweis auf die Mailinglisten habe ich in einen Laborbereich ausgelagert, damit sie stärker von der Anwendungsdokumentation getrennt sind. Verbesserungsvorschläge und Korrekturen sollten Sie gegebenenfalls bitte noch diese Woche anbringen, da ich die Webseite gerne zeitnah in die Übersetzung geben würde. Viele Grüße Sebastian Meyer -- ___________________________________________________ Sebastian Meyer Abteilung Informationstechnologie Referat Entwicklung Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden (SLUB) 01054 Dresden Besucheradresse: Zellescher Weg 18 Tel.: +49 351 4677-206 Fax: +49 351 4677-711 Mail: smeyer(a)slub-dresden.de Web: http://www.slub-dresden.de/ ___________________________________________________

15 years, 5 months

kleine Korrektur METS

by Dr. Thomas Staecker

Lieber Herr Funk, noch einen kleinen Nachtrag zu Ihrem Papier. Der Passus aus S.16 der PDF Version: "Das oberste <div> Elemente repräsentiert die gebundene Einheit." ist nach unseren Vorbesprechungen so nicht ganz korrekt. Es geht nicht um die Bindeeinheit (wenn das hier gemeint ist), sondern die bibliographische Einheit, das gilt m.E. auch für die physSequence. Ich würde formulieren: "Das oberste <div> Elemente umfasst die Seiten, die die bibliographische Einheit repräsentieren". So OK? Viele Gruesse, Ihr Th. Staecker -- Dr. Thomas Staecker (Leiter Abteilung Alte Drucke, Digitalisierung) Herzog August Bibliothek - Postfach 1364 - D-38299 Wolfenbuettel Tel. +49(0)5331/808-119 - email: staecker(a)hab.de

15 years, 5 months

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

15 years, 5 months

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

15 years, 5 months

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

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