Re: [InetBib] Digital Object Identifier

[Hans-Werner Hilse <hilse@xxxxxx>]

Hallo nochmal kurz,

On Thu, 26 Oct 2006 13:41:20 +0200 Jakob Voss <jakob.voss@xxxxxx> wrote:

> DOI gibt es schon seit Jahren und das System hat sich im kommerziellen
> Verlagsbereich durchgesetzt. Als ein Hauptargument sehe ich, dass die
> DOI Foundation den Linkresolver http://dx.doi.org/ betreibt und auf
> dem Laufenden hält - und aufgrund des kommerziellen Modells dazu auch
> verpflichtet ist.

Stimmt. Natürlich hält ein Vertrag aber niemanden davon ab, aufzuhören
zu existieren, da sich in dem Moment der Punkt "Vertragspartei" auch
erledigt hat. Langzeitige Gültigkeit und Funktion von Persistenten
Identifiern ist immer eine Frage des administrativen Bekenntnisses
dazu, zukünftig eben die entsprechende Arbeit zu investieren.

Auf dx.doi.org kommt es übrigens gar nicht an, da DOI technisch das
Handle-System nutzt, deshalb wäre ohne dx.doi.org dann eben die Global
Handle Registry (GHR) am Zuge. Das herausstechenste Merkmal von DOI ist
die sauber standardisierten Metadaten und Serviceprofil-Informationen,
mit denen die Daten mit Handle-Mitteln annotiert werden.

> > > womit auch ISBN's integriert werden können. 
> >
> > Das kann eigentlich jedes mir bekannte Schema für Persistent
> > Identifiers. Und zwar können das alle lediglich in einem
> > Sub-Namensraum.
>
> Wieso "lediglich"?

Weil das eigentlich nichts besonderes ist. In einen Subnamensraum kann
man nämlich in den wirklich sehr weiten technischen Grenzen des
Handle-Systems so ziemlich jeden Identifier integrieren.

Im Falle von Handle/DOI gibt es auch keinen fixen, einheitlichen
Subnamensraum für ISBNs, der dann z.B. von der ISBN-Agentur gepflegt
würde. Jeder Publisher kann sich ein eigenes Prefix holen und dann z.B.
Identifier a la "10.12345/isbn-1-2345-6789-X" vergeben. Der nächste
Publisher macht das dann vielleicht für sein Prefix ähnlich. Die
Alternative nach dem DOI-Metadatenkernel sieht so aus, dass man seine
DOIs mit weiteren Identifiern annotieren kann. Da wäre dann auf
Metadatenebene der Platz, ISBN in DOI zu "integrieren".

> Das Problem der Integration von ISBNs ist nur, dass
> kein einheitliches Weiterleitungsziel angeboten wird. Dabei gibt es
> unter anderem ("ISBN" durch die Nummer ersetzen):
>
> http://www.worldcat.org/search?q=isbn:ISBN
> http://kavia.gbv.de/DB=4.1/CMD?ACT=SRCHA&IKT=7&TRM=ISBN
> http://de.wikipedia.org/wiki/Spezial:Booksources/ISBN

Hier muss man vorsichtig sein, die Funktion von persistenten
Identifiern nicht auf das Resolving zu reduzieren. Und mit
Linkresolvern, die dann eine gewisse Metadatenbasis vorhalten, haben
sie auch erstmal nichts zu tun. Das Resolving persistenter Identifier
wiederum sollte natürlich tunlichst nicht auf Linkresolver angewiesen
sein, sondern schon deterministisch auf eine festgelegte, administrativ
gepflegte Adresse/URL verweisen. Die zentrale Funktion von persistenten
Identifiern, wie eben auch DOIs, ist eigentlich erst einmal nur,
Resourcen einen Namen zu geben, d.h. also eine feste Verbindung von
einer Zeichenkette zu einer Resource herzustellen und -- "auf ewig" --
zu erhalten.

> In PICA wird die DOI als
> normale URL Kategorie 4083 (Pica+: 009P$a) gepackt mit dem Resolver
> http://dx.doi.org/ davor.

Brrrrr. Naja, ich denke mal, für die nächsten Dekaden wird das erstmal
funktionieren und es lässt sich ja immerhin auch zur Not maschinell
bestimmen, dass alles, was mit "http://dx.doi.org/"; beginnt, ein DOI
ist.

Hier zeigt sich allerdings, dass nicht einmal in der Bibliothekswelt
voll durchgedrungen ist, welche Probleme Persistente Identifier wie
z.B. der DOI eigentlich lösen. Jedenfalls erscheint es unsauber,
Identifiern, die die Unabhängigkeit von Adressen schaffen sollen, dann
wieder in Adressen zu verpacken. Man schafft sich jede Menge Probleme
und bringt nur die Nutzer dazu, falsch, nämlich mit Adresse statt
Identifier, zu zitieren.

In dem Zusammenhang: Im GVK scheinen NBN-URNs auch in "URL-Form", also
an die Resolver-Adresse konkateniert katalogisiert zu sein, obwohl sie
in einem Feld stecken, das explizit als URN ausgewiesen ist.

Wie auch immer: Es wäre wünschenswert, wenn die Kataloge die
tatsächlichen Identifier anzeigen. Die können dann ja ruhig mit einem
Link Richtung Resolver hinterlegt sein, aber sollten zumindest erstmal
den wahren Charakter des Identifiers anzeigen, der ja eben nicht URL
sein will.

> In MODS ist das meiner Meinung nach sauberer
> gelöst, da gibt es ein Feld "identifier" und DOI ist nur ein
> Spezialfall:
>
> <identifier type='doi'>...</identifier>

...und so gehört es sich eigentlich auch. Die Präsentationsschicht kann
das ganze dann ja mit einem Hyperlink Richtung korrektem Resolver
versehen, aber angezeigt werden sollte "DOI: 10.1234/....." statt einer
URL.

> Weil bisher jeder Anbieter ob kommerziell oder nicht auf seinen Daten
> sitzt, anstatt eine Liste aller vergebenen Identifier und die
> aktuellen Linkziele frei zur Verfügung zustellen. So kann erstens
> niemand einen besseren Resolver anbieten und zweitens sind irgendwann
> alle Identifier wertlos, weil der auf den Daten sitzende Anbieter
> seine Lizenz geändert hat, Pleite gegangen ist o.Ä.

Listen von "Linkzielen" (hier falsch, muss eigentlich "Resolving-Ziele"
oder so heißen) können bei persistenten Identifiern nicht zuverlässig
funktionieren, da die Ziele mitunter hoch dynamisch sind. Die Listen
wären quasi laufend veraltet. Ein guter Vergleich ist z.B. das DNS (und
es gibt ja Vorschläge, z.B. NAPTR/DDDS, das DNS zum Resolving von
Identifiern zu verwenden): Es wäre wenig sinnvoll, Listen anzubieten,
die die gegenwärtigen Hostname/IP-Zuordnungen angeben. Gerade wegen der
hochdynamischen Natur gibt es ja eben das DNS.

> P.S: Wikimedia plant für Wikipedia URNs einzusetzen - die vergebenen
> URNs werden natürlich frei verfügbar sein und der dazu passende
> Resolver Open Source. Ich kann zwar noch nicht versprechen, dass das
> bis Ende des Jahres fertig ist, aber es sieht ganz gut aus.

Danke für den Link dazu, aber Vorsicht, hier kann man sich auch schnell
in die Nesseln setzen. Einen Datenbank-Identifier in einen Persistent
Identifier zu integrieren, sollte man sich gut überlegen: Der
Datenbank-Identifier muss dann fortan auch "persistent" sein, das heißt
also, er sollte sich nicht ausschließlich aus der Position eines
Datensatzes in einer Tabelle ergeben, die sich möglicherweise (z.B.
Einspielen eines Backups, Löschen von anderen Datensätzen o.ä.) ändert,
sondern muss immer dem Datensatz folgen.


So, sorry an alle, die das nun so gar nicht interessiert, für den
langen Sermon, aber das Thema halte ich für wichtig, und meist falsch
eingeschätzt,

Gruß,

Hans-Werner Hilse