[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [InetBib] CERL and ECPA publish report that explains persistent identifier schemes
- Date: Thu, 21 Dec 2006 14:28:29 +0100
- From: Hans-Werner Hilse <hilse@xxxxxx>
- Subject: Re: [InetBib] CERL and ECPA publish report that explains persistent identifier schemes
Hallo Liste, Hi Jakob,
da ja die Autoren hier mitlesen, gleich mal etwas (beinahe zuviel)
Replik:
On Wed, 20 Dec 2006 18:28:45 +0100 Jakob Voss <jakob.voss@xxxxxx> wrote:
Ecpa schrieb:
A recently published report explains the principle of persistent
identifiers and helps institutions decide which scheme would best
fit their needs.
Schöne Sache, die Bedeutung von Persistent Identifiers nimmt zu und
auch wenn der Report allein als Entscheidungsgrundlage nicht
ausreicht, bietet er doch schon mal einen Einstieg. Besonders gefällt
mir die Checkliste am Ende. Schön auch, dass der Text unter einer
CC-Lizenz lizensiert ist, nur schade, dass "NonCommercial" gewählt
wurde - damit kann zum Beispiel Wikipedia nichts anfangen ( siehe dazu
http://www.kuro5hin.org/story/2005/9/11/16331/0655 ).
Naja, vielleicht baue ich trotzdem wichtige Sachen in die
entsprechenden Artikel (also z.B. den zu den Identifier-Schemata) ein.
Ansonsten muss sich die Wikipedia tatsächlich mit einem Link begnügen.
Oder sie bekommt ein Einzelnutzungsrecht, aber wofür jetzt genau, das
wüsste ich gar nicht... Am besten ist ihr sicher gedient, wenn ich ein
paar freie weihnachtliche Stunden mit Artikel-Editieren verbringe :-)
Ansonsten wundert mich, warum info-URI (http://info-uri.info/)
ignoriert wird, das kommt immerhin von OCLC und die Gründe für die
Einführung von info-URI sagen einiges über die grundsätzlichen
Probleme von Identifikatoren aus. Außerdem wird die Rolle von URI im
Text nicht ausreichend herausgestellt. URI ist gewissermaßen die
Grundlage für alle globalen Identifier.
Das erzähl' mal den Leuten von Handle oder der DOI-Foundation ;-)
Zu infoURI bzw. dessen Fehlen im Bericht: Das hat verschiedene Gründe.
info-URI ist ein Konzept, das gar nicht unbedingt mit klassischen PI's
konkurriert. Info-URIs lösen sich z.B. sehr vom Resolving (das wegen
funktional und syntaktisch absolut uneinheitlicher Sub-Namensräume auch
schwierig wäre). Überhaupt ist der Info-URI-Namensraum ja explizit
dafür gedacht, andere Identifier-Schemata in den URI-Namensraum zu
integrieren. Im Kontext des Berichts, der aus der Frage entstanden ist,
welche Art Identifier man für seine elektronischen Ressourcen verwenden
will, kamen info-URIs leider nicht wirklich als Antwort in Frage.
Persistenz wird von info-URIs z.B. explizit nicht garantiert oder
verlangt (nur die der Subnamensraum-Bezeichner), vgl. auch Abgrenzung
info-URI/URN in RFC 4452, 6.3 (http://www.ietf.org/rfc/rfc4452.txt).
Insgesamt kommen die Interoperabilität und Zusammenhänge zwischen den
verschiedenen Identifier-Systemen etwas zu kurz. So ist jede NBN
gleichzeitig eine URN und jede URN gleichzeitig ein URI.
Ja. Das steht - leider etwas versprengt - auch drin. Vielleicht wäre
ein Grafik für "the big picture" doch besser gewesen. Vertan, vertan.
Jede DOI ist gleichzeitig ein Handle und sowohl für Handle als auch
für DOI gibt es einen Namensraum bei info-URI etc. So richtig Licht
ins Dunkel bringt der Text da nicht, dafür wären Wikipedia-Artikel
besser geeignet, da dort das ganze Laien-Kompatibel geschrieben
und in den Zusammenhang eingeordnet werden muss.
Ja, da lässt sich sicher auch noch viel machen. Info-URI ist ein
alles-integrierender Namensraum, insofern ist das nicht weiter
verwunderlich, dass Handles und DOIs ihren Weg dorthin gefunden haben,
um als URI schreibbar zu sein. Allerdings halte ich nun gerade bei
diesen beiden (DOI, Handle) die Anmerkungen zur Normalisierung im
Registrierungstext für die Subnamensräume für ein wenig kurz geraten --
sind sie doch eigentlich voll Unicode-fähig, was die Normalisierung
etwas schwieriger gestalten dürfte.
Die URN des Textes
urn:nbn:de:gbv:7-isbn-90-6984-508-3-8
erinnert mich daran, wie sehr leider noch gewurschtelt wird - so ist
die genaue Vergabe von NBN eher unklar, das Schema
<Verbundkürzel> "-" <Bibliothekssigel> "-" <irgendetwas> <Prüfziffer>
scheint zwar normiert zu sein, aber schon bei den Bibliothekssigeln
wurde vergessen, dass diese auch Sonderzeichen enthalten können.
Ja, insbesondere der Prüfziffernalgorithmus macht die Integration
schwierig. Er lässt beispielsweise ausschließlich "-" und ":" als
Sonderzeichen zu.
Der urn:nbn-Namensraum gefällt mir auch aufgrund der nationalen
Isolation der Resolver nicht sonderlich. Zwar findet häufig ein
Datenabgleich statt, so dass der deutsche NBN-Resolver auch die
urn:nbn's aus anderen Ländern auflösen kann. Aber inwieweit hier
wirklich verlässlich Interoperabilität herrscht, bleibt Nutzern und
Implementierern meist recht unklar. Das allerdings könnte kippen, wenn
DDDS sich wirklich irgendwann durchsetzt -- eher unwahrscheinlich, da
die Softwareentwicklungsszene im Bereich Server und Browser wenig
Interesse zeigt. Also bleibt es erstmal bei ein paar exemplarischen
Perl-Skripts und viel (zu viel) Spezifikation für so einen utopischen
Über-Resolver.
In der urn:nbn des hier diskutierten Reports findet sich auch in der
Tat die ISBN. Das erschließt sich allerdings nur Menschen (da kein
sinniges ISBN-Encodierschema und die nbn-Prüfsumme ohne klare
Abgrenzung) und ist hier eher als ein Hinweis in umgekehrte Richtung
gedacht (schnell gleichzeitig auch die ISBN angeben). Geschenkt, dort
hätte natürlich auch einfach "ABC" stehen können. Es ist jedenfalls
nicht als garantierte Inklusion des ISBN-Namensraum zu sehen.
Wie
sieht es außerdem mit folgendem Identifiern nach RFC 3187 aus:
urn:ISBN:9069845083
bezeichnet er den gleichen Text oder nicht oder garnichts?
Den gleichen Text, aber natürlich die eigentlich durch die ISBN
identifizierte gedruckte Fassung.
Der urn:isbn-Namensraum hat allerdings keine Mittel zum vernünftigen
Resolving des elektronischen Dokuments und ist daher als
Identifier-Angabe für diesen Report aus praktischen Gründen
ausgeschieden.
Wo lässt sich ermitteln, ob ein gegebener Identifier gültig ist
und welche Identifier bereits vergeben wurden?
Abhängig vom Schema, ggf. den folgenden Unterschemata, ob und wie so
etwas möglich ist.
Könnte man nicht mehrere Identifier-Systeme z.B. Handle und URN
gleichzeitig bedienen?
Klar. Allerdings vervielfacht das andererseits auch den
Wartungsaufwand, so dass ich abraten würde, so etwas eigenständig zu
machen. Vgl. aber z.B. das Projekt http://www.std-doi.de, die z.B. DOIs
(mittels Marketing verteuerte Handles) _und_ URNs vergeben. Allerdings
hat auch dort in der Webpräsentation die Rolle der URN starke Einbußen
erlitten, die wurde mal mehr betont, ja, sogar das Projekt als "Brücke"
zwischen URN und DOI aufgelistet. Mittlerweile steht auf den Seiten
fast nur noch etwas über DOIs.
Eine Herausforderung liegt meiner Meinung nach darin, bereits
existierende Identifier wie z.B. die ISBN-Nummern oder die
Bibliothekssigel in ein globales System von Identifiern einzubinden
anstatt laufend neue Systeme zu schaffen.
Nun, es müsste zumindest Notationen geben, die es erlauben,
Verbindungen zwischen Identifier-Schemata bzw. Korrelationen
auszudrücken. Damit hätte man dann wieder Mittel, Maschinen einsetzen
zu können.
Tja die Thematik ist halt leider nicht ganz so einfach, da vieles
historisch gewachsen ist und der Text wird nicht der letzte Versuch
zum Thema sein.
Weise Worte.
So für die Adventszeit oder für den Einstieg empfehle ich auch mal Tim
Berners Lee's »Cool URIs don't change«:
http://www.w3.org/Provider/Style/URI -- da ist schon Staub 'drauf, aber
es ist nach wie vor aktuell!
Mit besten Grüßen, gleich weihnachtlich an die ganze Liste mit besten
Wünschen für die kommende Weihnachtszeit und den Jahreswechsel,
Hans-Werner Hilse
Listeninformationen unter http://www.inetbib.de.