Lieber Herr Meyer, lieber Herr Stäcker,
ich habe noch mal über die diskutierten Fragen nachgedacht und komme zum Ergebnis: Aus meiner Sicht sollte das Resolving von URNs im Viewer nicht von den Standards abweichen, die sich in den verschiedenen Katalogsystemen etabliert haben. Heißt: Nutzung des Resolvers unter
http://nbn-resolving.org/
oder
http://nbn-resolving.de/
ohne weitere Parameterübergabe. Es liegt letztlich in der "Philosophie" des URN-Verfahren begründet, daß dann jede Einrichtung selbst entscheiden kann, wie die eigenen URNs - evtl. auch sammlungs- oder materialspezifisch - aufgelöst werden sollen. Hierzu stehen zwei Varianten zur Verfügung:
1. Alleinige Nutzung des Resolving-Dienstes der DNB. Der DNB werden hierzu, gleich in welchem Verfahren, URN und Primär-URL der jeweiligen Ressource unmittelbar gemeldet. Sollen URNs z.B. sammlungs- oder materialspezifisch (Hochschulschriften vs. Digitalisate aus DFG-Projekten vs. Digitalisate aus anderen Projekten unterschiedlich aufgelöst werden (eigener Präsentationsserver vs. DFG-Viewer), dann ist das über die Registrierung entsprechender URLs zu gewährleisten, die entweder direkt hierhin (eigenes Präsentationssystem) oder dorthin (Viewer) zeigen.
2. Nutzung des Resolving-Dienstes der DNB mit anschließendem eigenen Resolving. Hierzu werden der DNB PURLs übermittelt, die dann am eigenen Resolver aufgelöst werden können. Auch hier eben sammlungsspezifisch oder materialspezifisch. Lokal könnte dann eine "schönere" Auswahlseite präsentiert werden, die - bei Digitalisaten - zum Viewer verlinkt und zur lokalen Präsentation. Die automatische Auswertung von http-Referern (die allerdings beim Speichern der Links verlorengehen), die ein automatisches Redirecten einleiten, ist ebenfalls möglich.
Eine Festlegung, die allein im Viewer-Kontext von dieser Praxis (bzw. diesem Möglichkeitenraum) abweicht, verträgt sich aus meiner Sicht nicht wirklich mit den bestehenden Lösungen in den Katalog-Systemen. Vor allem hat man mit den oben beschriebenen Verfahrensweisen eigentlich "alles selbst in der Hand", sprich: kann die hier diskutierten Varianten auf Basis der bestehenden Formatkonventionen so umsetzen, wie man das für richtig hält.
Möchte man hier mehr Gestaltungsspielraum haben, dann sehe ich allenfalls noch die Möglichkeit, dem Viewer mehrere PIs zu liefern, die dann aber einem speziellen Type-System folgen müßten (type="viewer-purl" oder type="viewer-urn" oder type="very-special-own-resolving-service-purl" usw.), was nicht wirklich elegant wirkt und eher danach aussieht, die Metadaten eines Datensatzes zu verhunzen. ;) Vor allem funktioniert dies bei Einzelseiten nicht, da hier im METS-Format keine getypten Identifier übermittelt werden können, sondern nur URIs.
Beste Grüße,
Kay Heiligenhaus
> -----Original Message-----
> From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-
> viewer.de] On Behalf Of Dr. Thomas Staecker
> Sent: Tuesday, April 28, 2009 12:45 PM
> To: dv-technik(a)dfg-viewer.de
> Subject: Re: [DFG-Viewer] [Fwd: Re: AW: PI DFG-Viewer]
>
> Lieber Herr Meyer,
>
> >
> > nach meinem Verständnis wird das Präsentationssystem aber ab dem
> Moment selbst zu einem Teil der Ressource, ab dem sich der URN explizit
> auch darauf bezieht. Oder anders herum: die Ressource ist immer genau
> das, was der URN explizit adressiert. Und da jede Ressource, die mit
> einem URN versehen wurde, persistent gehalten werden muss, müsste das
> dann auch für das Präsentationssystem gelten.
> d.h. Ihre URN bezeichnet dann den bibliographischen Record, nicht das
> Digitalisat ;-) Ich glaube, wir müssen hier eine gewisse Abstraktion
> erlauben. Im Bibliothekssektor ist es auch so, dass eine Neubindung des
> Buches keinen neuen Druck generiert.
> >
> >> Die
> >> grundsätzliche Alternative wäre, wie gesagt, alle über die DNB
> resolvten
> >> URNs auf den Viewer zu lenken. Hier könnte man mit der DNB
> verhandeln,
> >> ob sie dann unsere eigetragenen URLs/PURLs automatisch an die Viewer
> URL
> >> übergibt.
> >
> > Das halte ich für kritisch, da ja längst nicht nur viewer-taugliche
> Digitalisate einen URN erhalten. Wir vergeben beispielsweise auch für
> die Dokumente unseres Hochschulschriftenservers URNs und diese dürfen
> natürlich auf keinen Fall zum DFG-Viewer aufgelöst werden. Aber selbst
> für unsere Digitalisate würde das nicht funktionieren: derzeit löst die
> DNB unsere URNs auf die PURLs auf. Da sich dahinter aber eine XHTML-
> Seite und kein METS verbirgt, könnte der Viewer damit nichts anfangen.
> > Dazu kommt die Problematik, dass wir auch mit Drittmitteln
> digitalisieren, die nicht von der DFG kommen. Die jeweiligen Förderer
> wären aber unter Umständen gar nicht so erfreut darüber, wenn "ihre"
> Digitalisate automatisch immer in den DFG-Viewer aufgelöst werden statt
> in das schicke Portal, das sie finanziert haben.
> > In sofern bevorzuge ich die Parameter-Lösung: hier kann nicht nur für
> jedes Digitalisat gesondert bestimmt werden, wohin es aufgelöst werden
> soll, sondern es ist prinzipiell sogar möglich, mehrere Zielsysteme zu
> hinterlegen und dann je nach Bedarf verschiedene anzusprechen.
>
> Ich dachte mir schon, dass hier Protest komm, und Ihre Argumente
> leuchten mir sofort unmittelbar ein. Es bliebe noch die Option, dass
> bestimmte URNs mit dem Viewer gekoppelt werden, wenn denn nicht doch
> vor
> diesem Hintergrund die Modifier-Lösung die bessere ist.
>
> Viele Grüße,
> Th. Stäcker
>
>
> >
> > 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 Dr. Thomas Staecker
> >> Gesendet: Dienstag, 28. April 2009 09:15
> >> An: dv-technik(a)dfg-viewer.de
> >> Betreff: Re: [DFG-Viewer] [Fwd: Re: AW: PI DFG-Viewer]
> >>
> >> Lieber Herr Meyer,
> >>> das ist aber inkonsequent. Wenn wir einerseits sogar schon beim
> Austausch
> >> einer gescannten Seite durch einen besseren Scan derselben Seite
> einen neuen
> >> URN vergeben, dann müssten wir doch bei der Präsentationsumgebung
> andererseits
> >> mit eben solcher Strenge verfahren.
> >>> Aber das ist eine rein akademische Diskussion, da wir uns ja längst
> einig
> >> sind, keine eigenen URNs für die verschiedenen Präsentationsformen
> zu
> >> vergeben.
> >> Ich sehe einen Unterschied zwischen der Ressource selbst (dem
> >> Digitalisiat) und dem es präsentierenden Rahmen. Aber Sie haben
> recht,
> >> das ist jetzt akademisch.
> >>>> Ja, ist klar, so sollte das geliefert werden, aber damit lösen Sie
> nicht
> >>>> das Problem, wie eine der beiden Ressourcen beim Aufruf ausgewählt
> >>>> werden soll. Die Lösung der DNB überlässt es dem Benutzer um den
> Preis
> >>>> eines Zwischenschrittes. Mir schien eine Variante mit
> Direktdurchgriff
> >>>> und Modifier eleganter.
> >>> Dieser Direktzugriff ließe sich doch dann seitens des Resolvers
> recht simpel
> >> umsetzen: Wenn der Nutzer statt des Parameters &n2ls so etwas wie
> &target=dv
> >> eingibt, wird er direkt zu der URL weitergeleitet, die in xepicur
> mit diesem
> >> Attribut ausgezeichnet ist. Man könnte noch überlegen, wie der
> Resolver
> >> reagieren soll, falls es zu diesem target keine URL gibt: entweder
> er zeigt
> >> dann die Auswahlliste aller verfügbaren URLs an (analog zu &n2ls)
> oder er
> >> leitet als Fallback immer auf die URL mit dem Attribut &role=primary
> weiter
> >> (analog zum Verhalten bei fehlendem target-Parameter).
> >>
> >> Das ist genau das, was ich gegenüber der DNB zu insinuieren
> versuchte.
> >> Das Problem ist, dass die DNB ein solches Feature (target=dv)zwar
> in
> >> der Dokumentation beschreibt, aber nicht implementiert hat. Wenn wir
> >> hier gegenüber der DNB einen abgestimmten Bedarf geltend machen,
> kann
> >> ich mir aber vorstellen, dass man dort diese Option nachrüstet. Das
> wäre
> >> aber dann mit der DNB noch einmal gesondert zu verhandel, wichtig
> wäre
> >> jetzt erst einmal, zu klären, ob wir es so machen wollen. Die
> >> grundsätzliche Alternative wäre, wie gesagt, alle über die DNB
> resolvten
> >> URNs auf den Viewer zu lenken. Hier könnte man mit der DNB
> verhandeln,
> >> ob sie dann unsere eigetragenen URLs/PURLs automatisch an die Viewer
> URL
> >> übergibt. Am kritischsten dürfte das in Bayern sein, weil dann
> >> vermutlich wirklich alles über den Viewer liefe, auch die Einträge
> im
> >> OPAC (wenn ich das recht erinnere). Die Alternative hierzu wäre,
> eine
> >> Viewer Primär-URL einzutragen.
> >>
> >> Viele Grüße,
> >> Th. Stäcker
> >>
> >>> 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 Dr. Thomas Staecker
> >>>> Gesendet: Montag, 27. April 2009 17:47
> >>>> An: dv-technik(a)dfg-viewer.de
> >>>> Betreff: Re: [DFG-Viewer] [Fwd: Re: AW: PI DFG-Viewer]
> >>>>
> >>>> Lieber Herr Meyer,
> >>>>
> >>>>> bislang dachte ich, das Ziel seien eigenständige URNs für
> dasselbe Werk in
> >>>> verschiedenen Zielsystemen. (Also beispielsweise eine URN für das
> Werk im
> >> DFG-
> >>>> Viewer und eine andere URN für dasselbe Werk in der lokalen
> Präsentation.)
> >>>>
> >>>> ich weiss nicht, das scheint mir auch nicht sachgerecht, weil es
> sich
> >>>> wirklich um diesselbe Ressource handelt, dann würden Sie erst
> recht die
> >>>> Umgebung aufwerten, weil Sie ein- und dieselbe Ressource in zwei
> >>>> Visualisierungen mit je separaten URNs ausstatten. Ich habe das
> >>>> URN-Konzept immer so verstanden, dass dasselbe auch gleich benannt
> >>>> werden muss. Hätten wir es nicht mit einem Webservice zu tun,
> sondern
> >>>> mit einer Kopie, wäre es in der Tat bedenkenswert.
> >>>>
> >>>> Deshalb auch meine Bedenken in Wolfenbüttel: damit würden sich
> URNs
> >>>> nicht mehr nur auf ein Werk, sondern auch auf dessen Kontext
> beziehen,
> >>>> was im Umkehrschluss bedeutet hätte, dass auch der Kontext
> persistent
> >>>> gehalten werden müsste.
> >>>>
> >>>> Da wäre ich nicht so streng. Umgebungen können sich lokal und beim
> >>>> Viewer ändern, trotzdem macht es auch ohne dies einen Unterschied,
> ob
> >>>> der Nutzer zum Viewer zurückkommt oder beim lokalen Anbieter
> landet.
> >>>>
> >>>>
> >>>>> Die Parameter-Lösung von Frau XXX erscheint mir dagegen durchaus
> >>>> praktikabel, auch wenn ich den Umweg über &n2ls unnötig
> kompliziert finde.
> >> Der
> >>>> Parameter &institution wäre eigentlich genau der richtige für uns
> -
> >> allerdings
> >>>> sollte er dann etwas generischer (und kürzer) benannt werden.
> Vielleicht
> >>>> könnte man dafür sogar das target-Attribut des identifier-Elements
> in
> >> xepicur
> >>>> verwenden, das bisher nur für DNB-interne Zwecke in Gebrauch ist?
> Etwa so
> >>>> (fiktives Beispiel):
> >>>>> <epicur>
> >>>>> <administrative_data>
> >>>>> [...]
> >>>>> <update_status type="urn_new"/>
> >>>>> [...]
> >>>>> </administrative_data>
> >>>>> <record>
> >>>>> <identifier
> scheme="urn:nbn:de">urn:nbn:de:gbv:089-
> >>>> 3321752945</identifier>
> >>>>> <resource>
> >>>>> <identifier scheme="url" target="tib"
> >>>> type="frontpage">http://edok01.tib.uni-
> >> hannover.de/edoks/e01dh01/</identifier>
> >>>>> <format scheme="imt">text/html</format>
> >>>>> </resource>
> >>>>> <resource>
> >>>>> <identifier scheme="url"
> target="dv">http://dfg-
> >>>> viewer.de/?set[mets]=http://edok01.tib.uni-
> >>>> hannover.de/edoks/e01dh01/</identifier>
> >>>>> <format scheme="imt">text/html</format>
> >>>>> </resource>
> >>>>> </record>
> >>>>> </epicur>
> >>>>>
> >>>> Ja, ist klar, so sollte das geliefert werden, aber damit lösen Sie
> nicht
> >>>> das Problem, wie eine der beiden Ressourcen beim Aufruf ausgewählt
> >>>> werden soll. Die Lösung der DNB überlässt es dem Benutzer um den
> Preis
> >>>> eines Zwischenschrittes. Mir schien eine Variante mit
> Direktdurchgriff
> >>>> und Modifier eleganter.
> >>>>
> >>>>
> >>>> Ratlose Grüße,
> >>>> Ihr
> >>>> Th. Stäcker
> >>>>
> >>>>
> >>>>> 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 Dr. Thomas Staecker
> >>>>>> Gesendet: Montag, 27. April 2009 17:02
> >>>>>> An: dv-technik(a)dfg-viewer.de
> >>>>>> Betreff: [DFG-Viewer] [Fwd: Re: AW: PI DFG-Viewer]
> >>>>>>
> >>>>>> Liebe Kolleginnen und Kollegen,
> >>>>>>
> >>>>>> ich leite Ihnen einmal hier einen Mailaustausch mit der DNB
> weiter zu
> >>>>>> der Frage, ob wir eine Viewer bezogenen URN Resolver bekommen
> könnten.
> >>>>>> Die Rückmeldung war nicht in jeder Hinsicht befriedigend, aber
> es gibt
> >>>>>> einen Lösungsvorschlag mit dem Code "&n2ls", so dass man
> immerhin die
> >>>>>> Viewerressource auswählen könnte. Meine Meinung dazu habe ich in
> der
> >>>>>> Antwort kundgetan, die Ihrige würde mich interessieren.
> >>>>>>
> >>>>>> Viele Grüße,
> >>>>>> Ihr
> >>>>>> Th. Stäcker
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Sehr geehrte Frau XXX,
> >>>>>>
> >>>>>> haben Sie vielen Dank für Ihre Erläuterungen. Ich sehe schon,
> dass die
> >>>>>> Sachlage etwas komplizierter ist, als man es sich wünschen
> möchte.
> >>>>>> Aber dazu im Einzelnen:
> >>>>>>
> >>>>>>> Der Modifier &institution ist dafür vorgesehen (aber bisher
> noch
> >>>>>>> nicht implementiert), dass bei Aufliegen eines Objektes bei
> >>>>>>> verschiedenen Insitutionen (z. B. Forschungszentrum und
> >>>>>>> Universitätsbibliothek) über die URN gesteuert werden kann, zu
> >>>>>>> welchem Server aufgelöst wird.
> >>>>>>> Der Modifier ist also für Ihre Anforderung nicht geeignet.
> >>>>>> Eigentlich ist das, was Sie beschreiben, genau das, was wir
> benötigen
> >>>>>> würden. Dieselbe Ressource liegt an zwei Orten und der Nutzer
> (oder der
> >>>>>> Anbieter) kann per Code entscheiden, wie sie aufgelöst wird.
> Dabei wird
> >>>>>> entscheidend sein, wo der Nutzer die Ressource gesehen hat.
> INsofern
> >>>>>> finde ich es schade, dass Sie dieses Feature wohl nicht
> implementieren
> >>>>>> werden.
> >>>>>>
> >>>>>>> Sie sollten vielmehr entscheiden, welche der genannten URLs die
> >>>>>> "role=primary"
> >>>>>>> erhält. Die Liste aller URLs erhalten Sie dann per Resolving
> mit dem
> >>>>>> Modifier
> >>>>>>> &N2Ls.
> >>>>>>> Beispiel:
> >>>>>>> http://nbn-resolving.de/urn:nbn:de:bsz:93-opus-59&n2ls
> >>>>>> Eine Primary-Auflösung ist zwar möglich, bedeutet aber einen
> >>>>>> Zwischenschritt, der vom Nutzer zu nehmen ist, da er aus einer
> Liste
> >>>>>> auswählen muss. Schöner wäre es, wie gesagt, wenn die URN nach
> der
> >>>>>> Quelle aufgelöst werden könnte, wo der Nutzer sie gefunden hat.
> Aber
> >>>>>> immerhin ist diese Lösung denkbar.
> >>>>>>
> >>>>>>> Zur URL des DFG-Viewers:
> >>>>>>> Wenn innerhalb einer URL eine andere URL aufgerufen wird (z. B.
> VG-Wort
> >>>>>>> Metis) haben wir schlechte Erfahrungen damit gemacht. Wir
> befürchten,
> >> dass
> >>>>>>> in diesen Fällen die URNs nicht auf die URLs aufgelöst werden
> können.
> >>>>>>> Wenn Sie diese URLs verwenden möchten, müssen wir unbedingt
> einen
> >>>>>>> Test dazu durchführen.
> >>>>>> Möglicherweise verstehe ich das Problem nicht ganz, aber was
> gemacht
> >>>>>> wird, ist doch nur, dass eine regelkonforme URL (dabei ist
> gleichgültig,
> >>>>>> ob diese URL wieder eine andere URL aufruft) mit einem Namen,
> der URN,
> >>>>>> verbunden wird. Wenn sie also auf den Viewer resolven und dort
> geht
> >>>>>> etwas schief, dann ist das doch eigentlich kein Problem des
> Resolvers
> >>>>>> mehr, weil der Weg zum Viewer ja funktioniert hat. Genauso gut
> kann auch
> >>>>>> jede andere URL versagen. Oder verstehe ich das Problem nicht
> richtig?
> >>>>>>
> >>>>>>> Zum URN/URL-Eingabeformular:
> >>>>>>> Die Veränderung der Längenbeschränkung für URL-Eingaben werden
> wir
> >>>>>>> auf unsere ToDo-Liste aufnehmen.
> >>>>>> Vielen Dank.
> >>>>>>
> >>>>>> Beste Grüße,
> >>>>>> 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
> >>>>>>
> >>>> --
> >>>> 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
> >>>>
> >>
> >> --
> >> 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
> >>
> >
>
>
> --
> 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
>
Lieber Herr Meyer,
> Dazu kommt die Problematik, dass wir auch mit Drittmitteln
> digitalisieren, die nicht von der DFG kommen. Die jeweiligen Förderer
> wären aber unter Umständen gar nicht so erfreut darüber, wenn "ihre"
> Digitalisate automatisch immer in den DFG-Viewer aufgelöst werden statt
> in das schicke Portal, das sie finanziert haben.
Jenseits der Frage, daß das natürlich jede Einrichtung / jedes Projekt selbst entscheiden können muß, wo was angezeigt werden soll, das nicht aus einer DFG-Finanzierung erwachsen ist: Mir ist hier und da die Frage gestellt worden, ob man nicht für "nicht-DFG-finanzierte" Projekte durch einen Parameter im METS das DFG-Logo oben rechts überschreiben kann, um hier evtl. einen anderen Förderungsträger zu verewigen. Ich finde das eigentlich keine schlechte Idee, denn offensichtlich besteht das Interesse, Formate und Visualisierung auch über DFG-Kontexte hinaus zu nutzen, was unserem Ziel ("Vereinheitlichung der Anzeige und Nutzung von Digitalisaten, gleich aus welcher Institution") doch nur förderlich ist. Was meinen Sie?
Beste Grüße,
Kay Heiligenhaus
Lieber Herr Meyer,
> Ich könnte damit gut leben, allerdings fürchte ich, dass das dem Wunsch
> der Kollegen (und der DFG) nicht gerecht wird. Deren Ziel ist es ja,
> die Entscheidung über das Zielsystem eben nicht dem Anbieter, sondern
> dem Nutzer zu überlassen.
Wie gesagt, mein Verständnis ist: Der Viewer sollte immer die _primäre_ Anzeigeform sein. Vom Viewer aus kommt man dann bei Bedarf zur lokalen Präsentation. Wenn man aber eine Auswahlmöglichkeit einblenden möchte zur Auflösung von URNs, dann kann man das über einen lokalen Resolver erreichen oder eben mehrere URNs/PURLs vergeben. Wenn hier ein weitergehender Anspruch besteht, dann kann man m.E. nur noch mit der DNB darüber verhandeln, daß über die Lieferungen mehrerer URLs zu einer Ressource automatisch diese Zwischenseite bei der DNB angezeigt wird. Aktuell muß man dazu einen Parameter übergeben, ohne zu wissen, ob es mehrere registrierte URLs gibt. Wenn man auch das noch weitertreiben möchte (ohne mit der DNB zu verhandeln), dann kann der Viewer zuvor über den Resolver der DNB ermitteln, ob mehrere URLs registriert sind:
http://nbn-resolving.de/urn:nbn:de:gbv:3:1-70927&xml
Entsprechend verlinkt der Viewer dann mit oder ohne Parameter (im Beispiel hier existiert nur ein URL, von daher würde auf http://nbn-resolving.de/urn:nbn:de:gbv:3:1-70927 verlinkt, nicht auf http://nbn-resolving.de/urn:nbn:de:gbv:3:1-70927&n2ls).
Technisch sehe ich kaum andere Möglichkeiten.
Beste Grüße,
Kay Heiligenhaus
Liebe Kolleginnen und Kollegen,
ich leite Ihnen einmal hier einen Mailaustausch mit der DNB weiter zu
der Frage, ob wir eine Viewer bezogenen URN Resolver bekommen könnten.
Die Rückmeldung war nicht in jeder Hinsicht befriedigend, aber es gibt
einen Lösungsvorschlag mit dem Code "&n2ls", so dass man immerhin die
Viewerressource auswählen könnte. Meine Meinung dazu habe ich in der
Antwort kundgetan, die Ihrige würde mich interessieren.
Viele Grüße,
Ihr
Th. Stäcker
Sehr geehrte Frau XXX,
haben Sie vielen Dank für Ihre Erläuterungen. Ich sehe schon, dass die
Sachlage etwas komplizierter ist, als man es sich wünschen möchte.
Aber dazu im Einzelnen:
>
>
> Der Modifier &institution ist dafür vorgesehen (aber bisher noch
> nicht implementiert), dass bei Aufliegen eines Objektes bei
> verschiedenen Insitutionen (z. B. Forschungszentrum und
> Universitätsbibliothek) über die URN gesteuert werden kann, zu
> welchem Server aufgelöst wird.
> Der Modifier ist also für Ihre Anforderung nicht geeignet.
Eigentlich ist das, was Sie beschreiben, genau das, was wir benötigen
würden. Dieselbe Ressource liegt an zwei Orten und der Nutzer (oder der
Anbieter) kann per Code entscheiden, wie sie aufgelöst wird. Dabei wird
entscheidend sein, wo der Nutzer die Ressource gesehen hat. INsofern
finde ich es schade, dass Sie dieses Feature wohl nicht implementieren
werden.
>
> Sie sollten vielmehr entscheiden, welche der genannten URLs die "role=primary"
> erhält. Die Liste aller URLs erhalten Sie dann per Resolving mit dem Modifier
> &N2Ls.
> Beispiel:
> http://nbn-resolving.de/urn:nbn:de:bsz:93-opus-59&n2ls
Eine Primary-Auflösung ist zwar möglich, bedeutet aber einen
Zwischenschritt, der vom Nutzer zu nehmen ist, da er aus einer Liste
auswählen muss. Schöner wäre es, wie gesagt, wenn die URN nach der
Quelle aufgelöst werden könnte, wo der Nutzer sie gefunden hat. Aber
immerhin ist diese Lösung denkbar.
>
> Zur URL des DFG-Viewers:
> Wenn innerhalb einer URL eine andere URL aufgerufen wird (z. B. VG-Wort
> Metis) haben wir schlechte Erfahrungen damit gemacht. Wir befürchten, dass
> in diesen Fällen die URNs nicht auf die URLs aufgelöst werden können.
> Wenn Sie diese URLs verwenden möchten, müssen wir unbedingt einen
> Test dazu durchführen.
Möglicherweise verstehe ich das Problem nicht ganz, aber was gemacht
wird, ist doch nur, dass eine regelkonforme URL (dabei ist gleichgültig,
ob diese URL wieder eine andere URL aufruft) mit einem Namen, der URN,
verbunden wird. Wenn sie also auf den Viewer resolven und dort geht
etwas schief, dann ist das doch eigentlich kein Problem des Resolvers
mehr, weil der Weg zum Viewer ja funktioniert hat. Genauso gut kann auch
jede andere URL versagen. Oder verstehe ich das Problem nicht richtig?
>
> Zum URN/URL-Eingabeformular:
> Die Veränderung der Längenbeschränkung für URL-Eingaben werden wir
> auf unsere ToDo-Liste aufnehmen.
Vielen Dank.
Beste Grüße,
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
Lieber Herr Stäcker,
> Genau, schön, dass Sie es präzisieren. Das war in meiner Mail
> missverstaendlich. In Ermangelungen anderer Resolver dachte ich, es
> verstünde sich von selbst ;-)
Gut. Da das immer und leicht durcheinander geht, war es mir nur wichtig, daß klar ist, daß wir über dieselben Dinge reden...
> Jein, natürlich "steckt" da noch eine URN drin, aber das Ganze ist
> natürlich keine URN mehr. Klar ist auch, dass der Modifier natürlich
> nur funktioniert, wenn er dem Resolver der DNB übergeben wird, dem URN
> Konzept selbst sind Modifier fremd und an anderen Resolvern würde es so
> nicht funktionieren.
So ist es.
> Insofern kann man vielleicht die Persistenzaspekte auch noch einmal
> etwas entspannter sehen. Wenn ich (möglichst persönlich) in 100 Jahren
> noch zu der Ressource kommen will, muss es unerheblich sein, in welchem
> Kontext sie angezeigt wird. Im heir und jetzt geht es erst einmal nur
> um einen konkreten Nutungskontext von URNs, die in einer bestimmten Form
> aufgelöst werden. Es an den Resolver der DNB zu koppeln macht
> angesichts mangelender Alternativen aus meiner Sicht aber Sinn.
Ja, das sehe ich auch so. Aus meinem Verständnis bestünde hier aber nur die Möglichkeit, die die DNB vorgeschlagen hat: Verlinkung auf eine Resolving-URL, die eine Liste der möglichen Ziele des _einen_ URN auflistet:
http://nbn-resolving.org/urn:nbn:de:gbv:089-3321752945&n2ls
Dies setzt aber voraus, daß man diese Alternativ-URLs an die DNB übermittelt hat (das Beispiel paßt in dieser Hinsicht nicht ganz, da die Alternativen hier die Archiv-Kopien der DNB sind, aber das Prinzip sollte "auf die Schnelle" klarwerden). Auch ist damit eben verbunden, daß der Nutzer dann immer eine Zwischenseite angezeigt bekommt und selbst eine Auswahl treffen muß. Andere Alternativen sehe ich nicht (die Verwendung mehrerer URNs, wie von Herrn Meyer als weitere Alternative ins Spiel gebracht, halte ich ebenfalls nicht für sachgerecht, wie Sie ja auch bereits ausgeführt haben).
Letztlich muß man sich hier aber m.E. fragen, warum man nicht einfach die Anzeige im Viewer zur "Standardanzeigeform" macht, die via URN adressiert wird, gleich, aus welchem Kontext man kommt. Das ist ja der Weg, den wir in Halle gehen. Vom Viewer kommt man immer auch zur lokalen Präsentation und damit auch zu evtl. erweiterten Funktionalitäten der lokalen Anzeige. Natürlich kann man gegen diese "Standardanzeigeform" auch Gegenargumente ins Feld führen und sich eben die Funktionalität wünschen, die Sie hier intendieren. Bei Verwendung "nur" eines URN/PURL läßt sich das aber technisch nicht sauber machen - es sei denn, man verzweigt auf diese Zwischenseite.
Beste Grüße,
Kay Heiligenhaus
Lieber Herr Stäcker,
> > so ganz schlau werde ich aus Ihrem Mailwechsel mit der DNB noch
> nicht. Ist es Ihr Ziel, daß URNs "kontextspezifisch" aufgelöst werden
> können, je "nach Herkunft eines Klicks"? Also z.B. aus dem VD17 auf den
> Viewer, aus dem OPAC auf den lokalen Bestand, aus dem Viewer selbst
> wiederum auf den Viewer usw.?
>
> Genau so ist es. Idee war eigentlich, dass ein Nutzer, der sich im DFG
> Viewer eine URN besorgt, auch wieder dorthin zurück gelangen kann und
> nicht auf dem lokalen Angebot landet.
Oh, dann reden wir aber - formal betrachten, was m.E. hier wichtig ist - nicht mehr über URNs, sondern a) über Resolving-URLs, die evtl. um Parameter angereichert werden, oder b) über eine URN-Auflösung zur einer Auswahlseite, die dann verschiedene Möglichkeiten des Zugangs anbietet. Einem URN selbst kann man nicht "ansehen", woher er kopiert wurde. Und wenn man ihm gleich eine Resolving-Adresse mit Parametern mitgibt, dann ist das kein URN mehr, sondern eben ein spezifischer URL, den der Nutzer sich kopiert. In dieser Hinsicht ist auch die Antwort der DNB nicht wirklich präzise, denn hier werden URNs und Resolving-URLs nicht klar voneinander abgegrenzt...
Beste Grüße,
Kay Heiligenhaus
Lieber Herr Stäcker,
so ganz schlau werde ich aus Ihrem Mailwechsel mit der DNB noch nicht. Ist es Ihr Ziel, daß URNs "kontextspezifisch" aufgelöst werden können, je "nach Herkunft eines Klicks"? Also z.B. aus dem VD17 auf den Viewer, aus dem OPAC auf den lokalen Bestand, aus dem Viewer selbst wiederum auf den Viewer usw.?
Beste Grüße,
Kay Heiligenhaus
> -----Original Message-----
> From: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg-
> viewer.de] On Behalf Of Dr. Thomas Staecker
> Sent: Monday, April 27, 2009 5:02 PM
> To: dv-technik(a)dfg-viewer.de
> Subject: [DFG-Viewer] [Fwd: Re: AW: PI DFG-Viewer]
>
> Liebe Kolleginnen und Kollegen,
>
> ich leite Ihnen einmal hier einen Mailaustausch mit der DNB weiter zu
> der Frage, ob wir eine Viewer bezogenen URN Resolver bekommen könnten.
> Die Rückmeldung war nicht in jeder Hinsicht befriedigend, aber es gibt
> einen Lösungsvorschlag mit dem Code "&n2ls", so dass man immerhin die
> Viewerressource auswählen könnte. Meine Meinung dazu habe ich in der
> Antwort kundgetan, die Ihrige würde mich interessieren.
>
> Viele Grüße,
> Ihr
> Th. Stäcker
>
>
>
> Sehr geehrte Frau XXX,
>
> haben Sie vielen Dank für Ihre Erläuterungen. Ich sehe schon, dass die
> Sachlage etwas komplizierter ist, als man es sich wünschen möchte.
> Aber dazu im Einzelnen:
>
> >
> >
> > Der Modifier &institution ist dafür vorgesehen (aber bisher noch
> > nicht implementiert), dass bei Aufliegen eines Objektes bei
> > verschiedenen Insitutionen (z. B. Forschungszentrum und
> > Universitätsbibliothek) über die URN gesteuert werden kann, zu
> > welchem Server aufgelöst wird.
> > Der Modifier ist also für Ihre Anforderung nicht geeignet.
> Eigentlich ist das, was Sie beschreiben, genau das, was wir benötigen
> würden. Dieselbe Ressource liegt an zwei Orten und der Nutzer (oder der
> Anbieter) kann per Code entscheiden, wie sie aufgelöst wird. Dabei wird
> entscheidend sein, wo der Nutzer die Ressource gesehen hat. INsofern
> finde ich es schade, dass Sie dieses Feature wohl nicht implementieren
> werden.
>
> >
> > Sie sollten vielmehr entscheiden, welche der genannten URLs die
> "role=primary"
> > erhält. Die Liste aller URLs erhalten Sie dann per Resolving mit dem
> Modifier
> > &N2Ls.
> > Beispiel:
> > http://nbn-resolving.de/urn:nbn:de:bsz:93-opus-59&n2ls
> Eine Primary-Auflösung ist zwar möglich, bedeutet aber einen
> Zwischenschritt, der vom Nutzer zu nehmen ist, da er aus einer Liste
> auswählen muss. Schöner wäre es, wie gesagt, wenn die URN nach der
> Quelle aufgelöst werden könnte, wo der Nutzer sie gefunden hat. Aber
> immerhin ist diese Lösung denkbar.
>
> >
> > Zur URL des DFG-Viewers:
> > Wenn innerhalb einer URL eine andere URL aufgerufen wird (z. B. VG-
> Wort
> > Metis) haben wir schlechte Erfahrungen damit gemacht. Wir befürchten,
> dass
> > in diesen Fällen die URNs nicht auf die URLs aufgelöst werden können.
> > Wenn Sie diese URLs verwenden möchten, müssen wir unbedingt einen
> > Test dazu durchführen.
> Möglicherweise verstehe ich das Problem nicht ganz, aber was gemacht
> wird, ist doch nur, dass eine regelkonforme URL (dabei ist
> gleichgültig,
> ob diese URL wieder eine andere URL aufruft) mit einem Namen, der URN,
> verbunden wird. Wenn sie also auf den Viewer resolven und dort geht
> etwas schief, dann ist das doch eigentlich kein Problem des Resolvers
> mehr, weil der Weg zum Viewer ja funktioniert hat. Genauso gut kann
> auch
> jede andere URL versagen. Oder verstehe ich das Problem nicht richtig?
>
> >
> > Zum URN/URL-Eingabeformular:
> > Die Veränderung der Längenbeschränkung für URL-Eingaben werden wir
> > auf unsere ToDo-Liste aufnehmen.
> Vielen Dank.
>
> Beste Grüße,
> 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
>
Lieber Herr Meyer,
> ich bin gerade dabei, die noch ausstehende Verlinkung von VD16/17-
> Nummern in die jeweiligen Datenbanken umzusetzen. Leider will mir
> partout nicht mehr einfallen, auf welche Typenbezeichnung für die
> Identifier wir uns zuletzt geeinigt hatten.
Wir hatten uns m.W. auf "vd16" und "vd17" geeinigt.
> Herr Heiligenhaus, Sie verwenden type="vda" für VD17-Nummern. Wie
> würden Sie dann VD16-Nummern auszeichnen?
Das "vda" ist bei uns historisch bedingt - im GBV wird dieser Typbezeichner bei SRU-Anfragen verwendet. Wäre nicht schlecht, wenn Sie das auch vorerst berücksichtigen könnten, ist aber nicht notwendig. Wir werden das mit einem kommenden Update auf "vd17" ändern. Bei VD16-Daten liefern wir jetzt bereits "vd16".
> Oder gibt es einen gemeinsamen Resolver, so dass wir gar nicht zwischen VD16 und VD17 (und
> künftigen VDs) unterscheiden müssen?
Mir ist keiner bekannt und ich denke auch nicht, daß ein solcher existiert.
Beste Grüße,
Kay Heiligenhaus
Liebe Kollegen,
ich bin gerade dabei, die noch ausstehende Verlinkung von VD16/17-Nummern in die jeweiligen Datenbanken umzusetzen. Leider will mir partout nicht mehr einfallen, auf welche Typenbezeichnung für die Identifier wir uns zuletzt geeinigt hatten.
Herr Heiligenhaus, Sie verwenden type="vda" für VD17-Nummern. Wie würden Sie dann VD16-Nummern auszeichnen? Oder gibt es einen gemeinsamen Resolver, so dass wir gar nicht zwischen VD16 und VD17 (und künftigen VDs) unterscheiden müssen?
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/
