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
 
  -----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