DV-Technik November 2008

dv-technik@dfg-viewer.de

10 participants
41 discussions

by Dr. Thomas Staecker

Liebe Kollegen, derzeit werden von Seiten der DFG die bekannten Praxisregeln überarbeitet. Unsere Bemühungen um ein verbindliches Format fuer den Viewer/zvdd sollen dort einfließen. Für den METS Bereich ist das wohl relativ konsolidiert durch das Papier von Herrn Funk. Noch etwas Schwierigkeiten haben wir mit MODS. Die Doku auf den Viewer Seiten: http://dfg-viewer.de/fileadmin/groups/dfgviewer/MODS_Application_Profile_20… ist nicht der aktuelle Diskussionsstand. Ich möchte hier noch einmal nachfragen, wie der Stand der Überarbeitung des MODS-Profils ist? Frau Levergood und Herr Otte wollten sich seinerzeit der Sache annehmen. Wenn es möglich wäre, kurzfristig zumindest das Minimalset abzuschließen und zu veröffentlichen, wäre das sehr hilfreich. Viele Gruesse, Ihr Th. Stäcker -- 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

16 years, 1 month

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

by Kay Heiligenhaus

Lieber Herr Funk, lieber Herr Meyer, liebe Kolleginnen und Kollegen, zunächst meinen besten Dank für die Erstellung des METS-Profils. Ich hatte noch nicht die Zeit, mir das im Detail anzuschauen, liefere aber meine Anmerkungen nach entsprechender Lektüre noch nach. Kurz aber zu den noch offenen Fragen: > Ich habe sie aus der physischen StructMap verknüpft. Für die > Einzelseiten geht es ja auch gar nicht anders, weil die keine > Repräsentation in der logischen StructMap besitzen. Das haben wir analog gemacht und ich denke, das ist so auch sinnvoll. > Beim Download des Gesamtwerks scheiden sich die Geister: ich habe das als Sequenz von > Einzelseiten interpretiert und entsprechend in der physischen Struktur > verlinkt, Herr Heiligenhaus hat das PDF dagegen mit der logischen > Struktur "Monographie" verknüpft. Wenn jemand Downloads von einzelnen > Kapiteln anbietet, kann er diese wiederum ausschließlich in der > logischen Struktur verknüpfen. Der Viewer sucht bisher übrigens nur in der physischen Struktur nach > Downloads. Ich hab nochmal etwas drüber nachgedacht. Aus meiner Sicht wäre es konsequenter, bei Gesamtwerken und Kapiteln grundsätzlich von der logischen structMap aus zu verknüpfen. Das grundlegende Argument ist für mich, daß wir uns hier auf der logischen Modellierungsebene befinden. PDFs des Gesamtwerkes können eben Inhaltsverzeichnisse haben, Titelblätter, weitere Metadaten in den dafür vorgesehenen PDF-Feldern usw. usf. PDFs auf Strukturdatenebene sind per definitionem "logische" Einheiten. Es ist sicherlich kein Problem, das bei uns entsprechend für die Gesamtwerke anzupassen, ich hielte aber eine Änderung der Viewer-Implementierung in der beschriebenen Hinsicht für in sich konsistenter. > (2) Was ist mit den zvdd-Srukturtypen? Sind diese für den DFG-Viewer > nicht mehr Pflicht wie in der letzten Version? Die zvdd-Strukturtypen waren für den Viewer noch nie Pflicht. Wenn Strukturtypen codiert werden, dann nach dem Schema, das unter http://dfg-viewer.de/profil-der-strukturdaten/ beschrieben und von den beteiligten Einrichtungen ja auch verabschiedet wurde. zvdd muß diese Typen auf das eigene Typsystem mappen (die entsprechenden Mappingregeln sind auf der o.g. Seite ja auch genannt). > Eigentlich sind sie für den DFG-Viewer tatsächlich nicht nötig. Der > Viewer zeigt einfach für jedes Strukturelement das an, was im LABEL- > Attribut steht, und wenn das nicht belegt ist, dann zeigt er direkt die > Angabe im TYPE-Attribut an. Man könnte nun höchstens für die ZVDD- > Strukturdatenliste beispielsweise intern alternative Bezeichnungen > hinterlegen, so dass nicht der Inhalt des TYPE-Attributs als Fallback > angezeigt wird, wenn kein LABEL existiert, sondern diese interne > Bezeichnung. Nach meinem Verständnis müßten dann die unter o.g. Adresse angegebenen dt. Bezeichnungen verwendet werden (wenn der Viewer gerade in einem anderen "Sprachmodus" ist, müßten entsprechende Übersetzungen angezeigt werden). > Ich halte die Strukturdatenliste aber dennoch für wichtig, weil sie die > Ausgabe der verschiedenen OAI-Schnittstellen verschiedener > Einrichtungen ein Stück weit standardisiert. Dadurch dass jede > Einrichtung angehalten ist, ihre intern verwendeten Strukturdaten auf > dieses Set herunterzubrechen, bevor sie sie per OAI in der Welt > verteilt, liefern alle OAI-Schnittstellen ein vergleichbares > Strukturdatenset. Sehe ich auch so. > (3) Darf es ein <div TYPE="page" /> in der logischen Structmap geben? > Das war in einem der vorigen Beispieln so. > > Meinem Verständnis nach darf es das nicht geben, weil eine Seite keine > logische Struktur ist. Eine metaphysische Frage. ;) - - - Nein, ich sehe das ebenfalls so. > Ich kann jetzt selbst nur raten, weil ich zu Hause den Quellcode nicht > einsehen kann, aber ich würde vermuten, der Viewer würde den ersten > MODS-Datensatz (den der Zeitschrift/des mehrbändigen Werks) ignorieren. > Das würde ich zumindest von ihm erwarten, ob er es wirklich tut, habe > ich ehrlich gesagt nie getestet. :o) Da sehe ich noch etwas Diskussionsbedarf. Wir testen aber auch gerade, wie wir unsere Daten modellieren, um ein gewünschtes Ergebnis zu erzielen. Kurz noch eine abschließende Frage: Wir hatten uns ja darauf verständigt, daß auch Einzelseiten persistent adressiert werden _können_. Ein Beispiel hierfür wäre: <mets:structMap TYPE="PHYSICAL" > <mets:div ID="phys582" TYPE="physSequence" > <mets:div ID="phys52047" TYPE="page" LABEL="[Seite 1]" CONTENTIDS="urn:nbn:de:gbv:3-100002425-p0001-0" ORDER="1" > ... </mets:structMap> Im <div> der Einzelseite in der phys. structMap findet sich also im Attribut "CONTENTIDS" die persistente Adresse der entsprechenden Einzelseite. Im METS-Profil ist das auch entsprechend dokumentiert. Leider wird diese Information aktuell im Viewer nirgends angezeigt, was aus meiner Sicht ein Bug ist. Wichtig fände ich in diesem Zusammenhang auch noch, daß dem Nutzer kurz erläutert wird, was es mit solchen Identifiern auf sich hat. Es hat sich ja in verschiedenen Diskussionskontexten gezeigt, daß das Konzept von URNs, PURLs usw. in Nutzerkontexten (und auch in der bibliothekarischen Fachwelt) z.T. weder bekannt noch verstanden worden ist. Hier ist wohl noch Aufklärungsarbeit nötig. Und dann zum Schluß noch: Es gibt noch einen Bug bei der Anzeige der Strukturdaten im IE7. Diese werden nicht neben den Images angezeigt, sondern darunter. Beste Grüße, Kay Heiligenhaus

16 years, 1 month

Download / Checkout der Viewer-Sources?

by Kay Heiligenhaus

Lieber Herr Meyer, nach dem Ausfall eines Teils des SLUB-Netzes (und damit auch der Viewer-Dienste) am letzten Wochenende haben wir bei semantics diskutiert, welche Maßnahmen man einleiten könnte, sollte sich ein solcher Fall wiederholen. Der Vorschlag aus unserer Entwicklung ist, daß man einen Fallback auf eine lokale Viewer-Installation machen könnte - der eigentliche Nutzer würde so gar nicht merken, daß im Hintergrund "irgend etwas nicht stimmt". Um ein solches Fallbackszenario genauer evaluieren zu können, müßten wir Zugriff auf die Viewer-Sources / Systemvoraussetzungen haben. Betreiben Sie ein Repository, aus dem man die Sources auschecken könnte? Welche sonstige Möglichkeit besteht, den jeweils aktuellen Produktionsstand erhalten zu können? Dank & beste Grüße, Kay Heiligenhaus ======================================= Kay Heiligenhaus Geschäftsführung semantics Kommunikationsmanagement GmbH Viktoriaallee 45, 52066 Aachen Tel: +49 241 89 49 89 29 Fax: +49 241 89 49 89 30 eMail: heiligenhaus(a)semantics.de Web: www.semantics.de Registergericht: Amtsgericht Aachen, HRB 8189 Geschäftsführer: Prof. Dr. Christian Stetter, Kay Heiligenhaus M.A., Dipl. Ing. José de la Rosa

16 years, 1 month

zvdd/DFG-Viewer METS-Profil Version 2.0

by Stefan Funk

Sehr geehrte Kolleginnen und Kollegen, da über die Technik-Liste diese Woche keine weiteren Kommentare bzw. Änderungswünsche geäußert wurden, finden Sie anbei die finale Version 2.0 des zvdd/DFG-Viewer METS-Profils. In beigefügtem ZIP-Archiv befindet sich die originäre XML-Datei des Profils incl. drei kompletter XML-Beispiele, die in die anderen Versionen aus Gründen der Übersichtlichkeit nicht übernommen wurden, weiterhin eine HTML-Version mit Stylesheet sowie eine PDF-Datei des METS-Profils. Kommentare sind weiterhin jederzeit gerne willkommen. Viele Grüße aus Göttingen und Ihnen allen ein schönes Wochenende. Stefan Funk. -- Stefan E. Funk DP-D - Diensteportal Digitalisierung Goettingen State and University Library - The Historical Library Building Papendiek 14, 37073 Goettingen, Germany Phone: +49 551 39-7700 | 39-12170 Mail: funk(a)sub.uni-goettingen.de

16 years, 1 month

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

by Dr. Thomas Staecker

Lieber Herr Funk, herzlichen Dank fuer das Schnüren des Päckchens. Leider wird der Anhang von unserem Emailserver geblockt. Wären Sie so freundlich, ihn noch einmal an meine private Email zu schicken: T.Staecker(a)gmx.de Viele Gruesse, Ihr Th. Staecker > Sehr geehrte Kolleginnen und Kollegen, > > da über die Technik-Liste diese Woche keine weiteren Kommentare bzw. > Änderungswünsche geäußert wurden, finden Sie anbei die finale Version 2.0 des > zvdd/DFG-Viewer METS-Profils. > > In beigefügtem ZIP-Archiv befindet sich die originäre XML-Datei des Profils > incl. drei kompletter XML-Beispiele, die in die anderen Versionen aus Gründen > der Übersichtlichkeit nicht übernommen wurden, weiterhin eine HTML-Version mit > Stylesheet sowie eine PDF-Datei des METS-Profils. > > Kommentare sind weiterhin jederzeit gerne willkommen. > > Viele Grüße aus Göttingen und Ihnen allen ein schönes Wochenende. > Stefan Funk. > > > -- > Stefan E. Funk > DP-D - Diensteportal Digitalisierung > Goettingen State and University Library - The Historical Library Building > Papendiek 14, 37073 Goettingen, Germany > Phone: +49 551 39-7700 | 39-12170 > Mail: funk(a)sub.uni-goettingen.de > ------------------------------------------------------------------- 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

16 years, 2 months

[Fwd: [InetBib] Übersetzung des Dublin Core Abstract Model (DCAM)]

by Thomas Stäcker

Vielleicht könnte man die Übersetzungsfreude von KIM auch für unser Profil nutzen ;-) Im Übrigen wäre es vielleicht sinnvoll, uns hier mit unserem METS/MODS einzuklinken. Der Konnex über Göttingen wäre ja gegeben. Viele Gruesse, Th. Staecker -------- Original-Nachricht -------- Betreff: [InetBib] Übersetzung des Dublin Core Abstract Model (DCAM) Datum: Fri, 21 Nov 2008 10:59:01 +0100 Von: Keßler, Mirjam <M.Kessler(a)d-nb.de> Antwort an: Internet in Bibliotheken <inetbib(a)ub.uni-dortmund.de> An: <inetbib(a)ub.uni-dortmund.de> Liebe Kolleginnen und Kollegen, Die "KIM-AG Übersetzungen" des Kompetenzzentrum Interoperable Metadaten (KIM) übersetzt Dokumente im Bereich Metadatenstandards vom Englischen ins Deutsche, um deren Anwendung im deutschsprachigen Raum zu erleichtern. Ab sofort steht nun auch die Übersetzung des Abstract Model der Dublin Core Metadata Initiative (DCMI) zum Download auf der KIM-Homepage bereit. Homepage des Kompetenzzentrum Interoperable Metadaten http://www.kim-forum.org Übersetzung des Dublin Core Abstract Model (DCAM) http://www.kim-forum.org/material/uebersetzungen/dcam.htm Mit freundlichen Grüßen Mirjam Keßler -- Mirjam Keßler Deutsche Nationalbibliothek Kompetenzzentrum Interoperable Metadaten / Öffentlichkeitsarbeit Adickesallee 1 D-60322 Frankfurt am Main Telefon: +49-69-1525-1763 mailto: m.kessler(a)d-nb.de

16 years, 2 months

Fwd: AW: zvdd/DFG-Viewer METS Profil - Version 2.0

by Jochen Kothe

Jochen Kothe -- Göttinger Digitalisierungszentrum Niedersächsische Staats- und Universitätsbibliothek Platz der Göttinger Sieben 1 37073 Göttingen Projekt: DigiZeitschriften http://www.digizeitschriften.de Projekt: DigiWunschbuch http://www.digiwunschbuch.de Projekt: IMPACT http://www.impact-project.eu Email: kothe(a)sub.uni-goettingen.de

16 years, 2 months

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

by Dr. Thomas Staecker

Da waren Sei schneller als ich ... ;-) Gruss, Staecker > Lieber Herr Kothe, > > > > > (2) Was ist mit den zvdd-Srukturtypen? Sind diese für den DFG-Viewer > > > > nicht mehr Pflicht wie in der letzten Version? > > > > > > Die zvdd-Strukturtypen waren für den Viewer noch nie Pflicht. Wenn > > > Strukturtypen codiert werden, dann nach dem Schema, das unter > > > > > > http://dfg-viewer.de/profil-der-strukturdaten/ > > > > > > beschrieben und von den beteiligten Einrichtungen ja auch verabschiedet > > > wurde. zvdd muß diese Typen auf das eigene Typsystem mappen (die > > > entsprechenden Mappingregeln sind auf der o.g. Seite ja auch genannt). > > > > > .......... > > das macht ja so überhaput keinen Sinn - die Repositories liefern ein > > ZVDD-konformes METS an ZVDD und ZVDD nimmt dieses METS um den DFG- > > Viewer zu nutzen, der aber wiederum ganz andere Strukturtypen "verlangt" - vice > > versa. Da DFG-Viewer und ZVDD zentrale Anwendungen des beschlossenen Formates > > sind sollt wir hier auf jeden Fall für ein einheitliches Set sorgen.. > > Das macht schon Sinn - denn es ist Beschlußlage und seit Viewer-Version 1 so auch dokumentiert. Der Viewer stammt nun mal aus dem Kontext der Pilotprojekte VD16/17 erweitert um Vertreter der SBBPK und der SUB Göttingen. Und diese Projekte haben sich in einem intensiven Diskussionsprozeß darauf verständigt, diese Strukturdatentypologie (http://dfg-viewer.de/profil-der-strukturdaten/) zu verwenden, da das zvdd-Set als zu eng betrachtet wurde. Einen Ausweg sehe ich allenfalls darin, daß zvdd dann eben das Viewer-Set übernimmt - oder eben für ein entsprechendes Mapping sorgt. > > Beste Grüße, > Kay Heiligenhaus ------------------------------------------------------------------- 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

16 years, 2 months

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

by Dr. Thomas Staecker

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. Anders formuliert, könnte man es auch so sehen, dass der Viewer zeigt alles anzeigt, was er bekommt, zvdd muss jedoch Vorschriften machen, weil es indexiert. Von Seiten des Viewers würde ich daher keine Vorschriften machen, aber die Nutzung der Liste "empfehlen". Im Übrigen fände ich es dessen ungeachtet "schön", wenn zvdd hier mehr bieten könnte als das bisherige ziemlich karge Subset von Strukturdaten. Wenn also ein Standard, dann den der Viewergruppe ;-) Man könnte aber hier über flexible Abstraktionsmodelle nachdenken, so dass angesichts der heterogenen Materialien beides ginge. Viele Gruesse, Thomas Stäcker > Hallo, > > Am Sonntag 16 November 2008 schrieb Kay Heiligenhaus: > ............ > > > > > (2) Was ist mit den zvdd-Srukturtypen? Sind diese für den DFG-Viewer > > > nicht mehr Pflicht wie in der letzten Version? > > > > Die zvdd-Strukturtypen waren für den Viewer noch nie Pflicht. Wenn > > Strukturtypen codiert werden, dann nach dem Schema, das unter > > > > http://dfg-viewer.de/profil-der-strukturdaten/ > > > > beschrieben und von den beteiligten Einrichtungen ja auch verabschiedet > > wurde. zvdd muß diese Typen auf das eigene Typsystem mappen (die > > entsprechenden Mappingregeln sind auf der o.g. Seite ja auch genannt).. > > > .......... > das macht ja so überhaput keinen Sinn - die Repositories liefern ein > ZVDD-konformes METS an ZVDD und ZVDD nimmt dieses METS um den DFG-Viewer zu > nutzen, der aber wiederum ganz andere Strukturtypen "verlangt" - vice versa. > Da DFG-Viewer und ZVDD zentrale Anwendungen des beschlossenen Formates sind > sollt wir hier auf jeden Fall für ein einheitliches Set sorgen. > > Gruß > Jochen Kothe > -- > Göttinger Digitalisierungszentrum > Niedersächsische Staats- > und Universitätsbibliothek > Platz der Göttinger Sieben 1 > 37073 Göttingen > Projekt: DigiZeitschriften > http://www.digizeitschriften.de > Projekt: DigiWunschbuch > http://www.digiwunschbuch.de > Projekt: IMPACT > http://www.impact-project.eu > > Email: kothe(a)sub.uni-goettingen.de ------------------------------------------------------------------- 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

16 years, 2 months

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

by Kay Heiligenhaus

Lieber Herr Kothe, > > > (2) Was ist mit den zvdd-Srukturtypen? Sind diese für den DFG-Viewer > > > nicht mehr Pflicht wie in der letzten Version? > > > > Die zvdd-Strukturtypen waren für den Viewer noch nie Pflicht. Wenn > > Strukturtypen codiert werden, dann nach dem Schema, das unter > > > > http://dfg-viewer.de/profil-der-strukturdaten/ > > > > beschrieben und von den beteiligten Einrichtungen ja auch verabschiedet > > wurde. zvdd muß diese Typen auf das eigene Typsystem mappen (die > > entsprechenden Mappingregeln sind auf der o.g. Seite ja auch genannt). > > > .......... > das macht ja so überhaput keinen Sinn - die Repositories liefern ein > ZVDD-konformes METS an ZVDD und ZVDD nimmt dieses METS um den DFG- > Viewer zu nutzen, der aber wiederum ganz andere Strukturtypen "verlangt" - vice > versa. Da DFG-Viewer und ZVDD zentrale Anwendungen des beschlossenen Formates > sind sollt wir hier auf jeden Fall für ein einheitliches Set sorgen. Das macht schon Sinn - denn es ist Beschlußlage und seit Viewer-Version 1 so auch dokumentiert. Der Viewer stammt nun mal aus dem Kontext der Pilotprojekte VD16/17 erweitert um Vertreter der SBBPK und der SUB Göttingen. Und diese Projekte haben sich in einem intensiven Diskussionsprozeß darauf verständigt, diese Strukturdatentypologie (http://dfg-viewer.de/profil-der-strukturdaten/) zu verwenden, da das zvdd-Set als zu eng betrachtet wurde. Einen Ausweg sehe ich allenfalls darin, daß zvdd dann eben das Viewer-Set übernimmt - oder eben für ein entsprechendes Mapping sorgt. Beste Grüße, Kay Heiligenhaus

16 years, 2 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

DV-Technik November 2008