Re: [DFG-Viewer] [Fwd: Re: AW: PI DFG-Viewer]

28 Apr 2009

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Re: [DFG-Viewer] [Fwd: Re: AW: PI DFG-Viewer]