DV-Technik

dv-technik@dfg-viewer.de

329 discussions

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

16 years, 1 month

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

16 years, 1 month

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

16 years, 1 month

DFG Praxisregeln

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, 1 month

[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, 1 month

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, 1 month

← Newer
1
...
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