8 Jul
2010
8 Jul
'10
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