8 Jul
2010
8 Jul
'10
8:11 a.m.
Lieber Herr Meyer, liebe Kolleginnen und Kollegen,
gestern habe ich, nach dem frustierenden Fußballspiel, im Bedürfnis
etwas Produktives tun zu müssen, die download-Funktion bei uns
nachgerüstet, z.B.
<mets:fileGrp USE="DOWNLOAD" >
<mets:file ID="download_ptr2images_drucke_55-4-hist-2f"
MIMETYPE="text/html" >
<mets:FLocat
xlink:href="http://diglib.hab.de/download.php?dir=drucke/55-4-hist-2f&lang=de"
LOCTYPE="URL" ></mets:FLocat>
</mets:file>
</mets:fileGrp>
und
<mets:structMap TYPE="PHYSICAL" > <mets:div
ID="physMD_515681113"
TYPE="physSequence" >
<mets:fptr FILEID="download_ptr2images_drucke_55-4-hist-2f"
</mets:fptr> etc.
Hierbei sind mir zwei Dinge aufgefallen. Zunächst einmal konnte ich
keine Dokumentation dazu finden (mit Nachsicht für mein schwaches
Gedächtnis), was angesichts einer so wichtigen, von der DFG immer wieder
nachgefragten Funktion etwas unglücklich ist. Meine Anregung wäre, ein
Muster mit nur einer Seite anzuzeigen, das wirklich alle Funktionen
enthält. Die Muster auf den Viewer-Seiten sind unvollständig. In diesem
Zusammenhang sollte man vielleicht auch überlegen, ob man, wenn es
adminstrativ keine Zumutung ist, nicht ein Mailarchiv anlegen könnte,
das man durchsuchen kann. Wir sollten auch die Hinweise auf die
support-Liste auf den Viewer-Seiten löschen, da diese Liste nicht mehr
bedient wird.
Zum anderen ist ein Fehler aufgetreten, den ich noch nicht ganz verstehe
und wo ich Ihre Hilfe erbitte. Nach Implementierung des Codeschnipsels
wird die seitenpersistente URL (aus CONTENTIDS) nicht mehr angezeigt,
sondern nur noch die Werk-URL:
http://dbs.hab.de/oai/wdb/?&verb=GetRecord&metadataPrefix=mets&…
Das Vorbild für meine Implementierung war - wie so oft :-) - Halle:
http://digitale.bibliothek.uni-halle.de/pon/oai/?verb=GetRecord&metadat…
Hier funktionierts es, ich kann nur beim besten Willen keinen
Unterschied zwischen den Implementierungen erkennen, es muss ihn aber geben.
Noch ein Hinweis an die Münchner Kollegen. Das Beispiel im
Viewer-Demonstrator führt zu einer Fehlermeldung, hier scheint etwas mit
den Pfaden nicht zu stimmen.
Viele Grüße,
Th. Stäcker
--
Dr. Thomas Staecker (stellv. Direktor; Leiter Abteilung Integrierte Medienbearbeitung,
Benutzung) Herzog August Bibliothek - Postfach 1364 - D-38299 Wolfenbuettel Tel.
+49(0)5331/808-303 - email: staecker(a)hab.de
8 Jul
8 Jul
9:45 a.m.
Lieber Herr Staecker,
liebe KollegInnen,
das Problem mit den @CONTENTIDS hat nichts mit der Download-Funktion zu tun. Eigentlich
dürften die Identifier auch vor der Nachrüstung der Download-Funktion schon nicht
angezeigt worden sein. Der Grund ist, dass wir uns ursprünglich mal darauf verständigt
hatten, nicht sämtliche @CONTENTIDS zur Anzeige zu bringen, sondern nur persistente URL
und URN. Deshalb prüft der Viewer formal das "Protokoll" ab, um die Art des
Identifiers zu ermitteln ("http:" bzw "https:" bei PURL,
"urn:" bei URN). Alle Identifier, die keinem dieser Muster folgen, werden nicht
angezeigt.
Der Hintergrund dieser Entscheidung war - wenn ich mich recht erinnere - das wir dem
Nutzer nicht einfach Identifier anzeigen wollten, ohne dass der Nutzer eine Möglichkeit
hat, die Art des Identifiers zu bestimmen (denn dann ist auch der Identifier ziemlich
nutzlos). Einzig PURL und URN können vom Viewer direkt mit den entsprechenden Resolvern
verlinkt werden (bzw. sind auch sonst als solche erkennbar), so dass die Identifier für
den Nutzer brauchbar werden.
In Ihrem konkreten Fall müssten Sie also lediglich die relativen Links zur absoluten URLs
machen, damit diese angezeigt werden.
Die schlechte Dokumentation ist auch mir ein Dorn im Auge. Ich schlage deshalb vor, die
Erweiterung der Dokumentation genauso wie eine Verbesserung der Beispiele ebenfalls in
unsere aus dem letzten Treffen hervorgegangene ToDo-Liste (und den daraus resultierenden
DFG-Antrag) aufzunehmen. Dazu müssten wir aber klären, wer nun eigentlich für die
Dokumentation verantwortlich ist. Bisher haben ja die Kollegen aus Göttingen für die
METS/MODS-Dokumentation verantwortlich gezeichnet. Bestehen Einwände dagegen, dass wir
deren Pflege zumindest in diesem Fall auch in Dresden erledigen?
Die Einstellung der Support-Mailingliste befürworte ich, da sie tatsächlich noch nie viel
und in letzter Zeit gar nicht mehr genutzt wurde. Ein Mail-Archiv existiert für beide
Listen bereits, ist derzeit aber nur SLUB-intern erreichbar. Da werde ich mal sehen, ob
ich das ändern kann.
Viele Grüße
Sebastian Meyer
--
Sebastian Meyer
Projekt-Mitarbeiter
Sächsische Landesbibliothek -
Staats- und Universitätsbibliothek Dresden (SLUB)
01054 Dresden
Tel.: +49 351 4677-206
Fax: +49 351 4677-711
http://www.slub-dresden.de/
-----Ursprüngliche Nachricht-----
Von: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-
viewer.de] Im Auftrag von Thomas Stäcker
Gesendet: Donnerstag, 8. Juli 2010 08:12
An: dv-technik(a)dfg-viewer.de
Betreff: [DFG-Viewer] download
Lieber Herr Meyer, liebe Kolleginnen und Kollegen,
gestern habe ich, nach dem frustierenden Fußballspiel, im Bedürfnis
etwas Produktives tun zu müssen, die download-Funktion bei uns
nachgerüstet, z.B.
<mets:fileGrp USE="DOWNLOAD" >
<mets:file ID="download_ptr2images_drucke_55-4-hist-2f"
MIMETYPE="text/html" >
<mets:FLocat
xlink:href="http://diglib.hab.de/download.php?dir=drucke/55-4-hist-
2f&lang=de"
LOCTYPE="URL" ></mets:FLocat>
</mets:file>
</mets:fileGrp>
und
<mets:structMap TYPE="PHYSICAL" > <mets:div
ID="physMD_515681113"
TYPE="physSequence" >
<mets:fptr FILEID="download_ptr2images_drucke_55-4-hist-2f"
</mets:fptr> etc.
Hierbei sind mir zwei Dinge aufgefallen. Zunächst einmal konnte ich
keine Dokumentation dazu finden (mit Nachsicht für mein schwaches
Gedächtnis), was angesichts einer so wichtigen, von der DFG immer
wieder
nachgefragten Funktion etwas unglücklich ist. Meine Anregung wäre, ein
Muster mit nur einer Seite anzuzeigen, das wirklich alle Funktionen
enthält. Die Muster auf den Viewer-Seiten sind unvollständig. In diesem
Zusammenhang sollte man vielleicht auch überlegen, ob man, wenn es
adminstrativ keine Zumutung ist, nicht ein Mailarchiv anlegen könnte,
das man durchsuchen kann. Wir sollten auch die Hinweise auf die
support-Liste auf den Viewer-Seiten löschen, da diese Liste nicht
mehr
bedient wird.
Zum anderen ist ein Fehler aufgetreten, den ich noch nicht ganz
verstehe
und wo ich Ihre Hilfe erbitte. Nach Implementierung des
Codeschnipsels
wird die seitenpersistente URL (aus CONTENTIDS) nicht mehr angezeigt,
sondern nur noch die Werk-URL:
http://dbs.hab.de/oai/wdb/?&verb=GetRecord&metadataPrefix=mets&…
er=oai:diglib.hab.de:ppn_515681113
Das Vorbild für meine Implementierung war - wie so oft :-) - Halle:
http://digitale.bibliothek.uni-
halle.de/pon/oai/?verb=GetRecord&metadataPrefix=mets&mode=view&identifi
er=94835
Hier funktionierts es, ich kann nur beim besten Willen keinen
Unterschied zwischen den Implementierungen erkennen, es muss ihn aber
geben.
Noch ein Hinweis an die Münchner Kollegen. Das Beispiel im
Viewer-Demonstrator führt zu einer Fehlermeldung, hier scheint etwas
mit
den Pfaden nicht zu stimmen.
Viele Grüße,
Th. Stäcker
--
Dr. Thomas Staecker (stellv. Direktor; Leiter Abteilung Integrierte
Medienbearbeitung, Benutzung) Herzog August Bibliothek - Postfach 1364
- D-38299 Wolfenbuettel Tel. +49(0)5331/808-303 - email:
staecker(a)hab.de
2:59 p.m.
Lieber Herr Meyer,
Meyer, Sebastian schrieb:
Lieber Herr Staecker,
liebe KollegInnen,
das Problem mit den @CONTENTIDS hat nichts mit der Download-Funktion zu tun. Eigentlich
dürften die Identifier auch vor der Nachrüstung der Download-Funktion schon nicht
angezeigt worden sein. Der Grund ist, dass wir uns ursprünglich mal darauf verständigt
hatten, nicht sämtliche @CONTENTIDS zur Anzeige zu bringen, sondern nur persistente URL
und URN. Deshalb prüft der Viewer formal das "Protokoll" ab, um die Art des
Identifiers zu ermitteln ("http:" bzw "https:" bei PURL,
"urn:" bei URN). Alle Identifier, die keinem dieser Muster folgen, werden nicht
angezeigt.
Der Hintergrund dieser Entscheidung war - wenn ich mich recht erinnere - das wir dem
Nutzer nicht einfach Identifier anzeigen wollten, ohne dass der Nutzer eine Möglichkeit
hat, die Art des Identifiers zu bestimmen (denn dann ist auch der Identifier ziemlich
nutzlos). Einzig PURL und URN können vom Viewer direkt mit den entsprechenden Resolvern
verlinkt werden (bzw. sind auch sonst als solche erkennbar), so dass die Identifier für
den Nutzer brauchbar werden.
In Ihrem konkreten Fall müssten Sie also lediglich die relativen Links zur absoluten URLs
machen, damit diese angezeigt werden.
verstehe, ja, dass lässt sich schnell ändern. Sorry, das hatte ich nicht
mehr präsent. Danke für die Analyse.
Die schlechte Dokumentation ist auch mir ein Dorn im
Auge. Ich schlage deshalb vor, die Erweiterung der Dokumentation genauso wie eine
Verbesserung der Beispiele ebenfalls in unsere aus dem letzten Treffen hervorgegangene
ToDo-Liste (und den daraus resultierenden DFG-Antrag) aufzunehmen. Dazu müssten wir aber
klären, wer nun eigentlich für die Dokumentation verantwortlich ist. Bisher haben ja die
Kollegen aus Göttingen für die METS/MODS-Dokumentation verantwortlich gezeichnet. Bestehen
Einwände dagegen, dass wir deren Pflege zumindest in diesem Fall auch in Dresden
erledigen?
Aus meiner Sicht überhaupt nicht. Ich möchte auch anbieten, dass wir von
Wolfenbüttel das TEI-P 5 Formats für Handschriften vorbereiten, da wir
ohnehin daran arbeiten bzw. schon recht viel Substanz zurückgreifen
können. Ich bin auch gern bereit, einschlägige Beispiele vorzubereiten.
Ich denke, wenn wir hier zusammenarbeiten, geht es recht fix, es wäre
nur schön, wenn Sie ein bisschen koordinieren könnten.
Die Einstellung der Support-Mailingliste befürworte
ich, da sie tatsächlich noch nie viel und in letzter Zeit gar nicht mehr genutzt wurde.
Ein Mail-Archiv existiert für beide Listen bereits, ist derzeit aber nur SLUB-intern
erreichbar. Da werde ich mal sehen, ob ich das ändern kann.
Das wäre wunderbar. Ganz herzlichen Dank!
Beste Grüße,
Ihr
Th. Stäcker
Viele Grüße
Sebastian Meyer
--
Dr. Thomas Staecker (stellv. Direktor; Leiter Abteilung Integrierte Medienbearbeitung,
Benutzung) Herzog August Bibliothek - Postfach 1364 - D-38299 Wolfenbuettel Tel.
+49(0)5331/808-303 - email: staecker(a)hab.de
5309
days inactive
5309
days old
2 comments
2 participants
participants (2)
-
Meyer, Sebastian -
Thomas Stäcker