PhycoBank

Lieber Markus (Cc Andreas K.),

bei der Frage, welche Globalen Identifier geeignet seien (im Zusammenhang mit unserer Algenregistrierung), stoße ich immer wieder auf LSIDs, die 2005 durch Rod Page promoted wurden und obwohl zwischenzeitlich für tot erklärt, in Namens/Taxondatenbanken und Netzwerken (noch) verwendet werden [CoL, ZooBank, IndexFungorum, Ipni, WORMS, AlgaeBase, ITIS…].
Als Laie versuche ich mal zusammenzufassen:
Bei Identifiern kann man unterscheiden in Identifier von Originalsystemen, die in der Wahl ihrer Identifier frei sind und Aggregatorsystemen, die selber Identifier vergeben.

GBIF vergibt Species-IDs und nennt die Quelle, verwendet selber keine LSIDs
Die Taxonomy Search Engine von 2005 vergab offensichtlich LSIDs für Records anderer Systeme. Daraus würde ich folgern, dass LSIDs im Zusammenhang von Aggregatoren am sinnvollsten sind.

Für Stand-Alone-Systeme (die aber Daten an Netzwerke liefern wollen) könnte ein eine stabile http-Id sinnvoller sein, sofern eine Webdomain langfristig zur Verfügung steht.
Bei ZooBank sehe ich den wesentlichen Unterschied zwischen LSID und http-Id darin, dass letztere „klickable“ und damit direkt ansteurerbar ist.
urn:lsid:zoobank.org:act:BDCE76E3-FCFE-431C-AFD1-F0AE18A0B0E0
http://zoobank.org/NomenclaturalActs/BDCE76E3-FCFE-431C-AFD1-F0AE18A0B0E0

Frage 1: liege ich mit den Überlegungen richtig?
Frage 2: gibt es aus Deiner Sicht gute Argumente für LSIDs oder gegen stabile http-Ids ?

Neugierig auf Deine Antwort grüßt herzlich,
Henning

Hallo Henning,

LSIDs sind in der Tat ziemlich tot und ich würde sie nicht empfehlen. Allerdings hast Du Recht dass sie bei Nomenklatoren bisher am meisten eingesetzt worden sind.
IBM, die Erfinder haben sich schon lange zurückgezogen und auch TDWG empfiehlt sie nicht mehr.

Identifier haben potentiell mehrere Aufgaben:

• lokal vs global einmalig (GUIDs)
  GUIDs haben den Vorteil dass man sie überall mit anderen ids mischen kann und immer eindeutig bleiben. Lokale benötigen zusätzlich einen Kontext den man kennen muss, zB WoRMS.
  UUIDs sind hier die gängigen GUID die man dezentral generieren kann. ZooBank benutzt diese exzessiv.

• persistent, d.h. die id ändert sich über lange zeit nicht. Da haben vor allem domain basierte Systeme wie URLs Probleme

• resolvable, d.h. wie komme ich an die Informationen über das “Ding” für das der identifier steht. Identifier die “resolvable” sind sind gleichzeitig an ein Protokoll gebunden und man muss nicht noch einen besonderen service kennen. Bei identifiern die nicht “resolvable” sind geschieht dies über einen getrennten service. Eine einfache Nummer zB kann ich über einen REST service oder eine webseite auflösen. Zb hat WoRMS einfache integer, die AphiaID. 172999 ist zB Abarenicola affinis (Ashworth, 1903) das einfach über die webseite auflösbar ist: http://www.marinespecies.org/aphia.php?p=taxdetails&id=172999
  Insbesondere URLs & DOIs sind da zu nennen. (PURLs werden von OCLC nicht mehr unterstützt und sind wohl schon von https://w3id.org/ überholt)

Daneben ist es gut wenn ids persistent sind und niemals wiederverwertet werden. D.h. es werden immer nur neue ids generiert und alte evtl sogar nur logisch gelöscht, d.h. man kann die id immer noch auflösen und der Datensatz hat nur ein Vermerk dass er gelöscht wurde.

So, was würde ich nun empfehlen? Vor allem etwas einfaches was sich nicht zu sehr an eine bestimmte Technik knüpft. Die allermeisten Systeme sind mittlerweile schon wieder weg.

Ich würde zwischen folgenden wählen:

• integers: sie sind kurz, prägnant und gut & effektiv zu verarbeiten. Resolvable werden sie über einen service und man kann im Zweifel immer einfach guids erzeugen indem man ihnen ein präfix voranstellt: "worms:172999” und das wars.
• UUIDs: ähnlich wie integers nur global eindeutig und dezentral generierbar. Das ist toll. Allerdings sind die Dinger etwas lang und von Menschen einfach nicht zu merken.
• DOI: das DOI system wächst und wächst und via DataCite kann man als eigene DOI authority fungieren sodass diese auch nichts kosten. Allerdings ist DataCite nicht ganz so zuverlässig wie ich gedacht hätte, die services sind schonmal einfach weg für ein paar Stunden. Über die Metadaten und vor allem crossref gibt es allerdings eine Verlinkung von Publikationen und Autoren - die ist allerdings nicht besonders offen (crossref jedenfalls nicht)

Den Aspekt des “resolvable” würde ich nicht mit der Funktion des Identifizierens vermischen. Ein JSON REST service, LinkedOpenData und ein html portal sollten dies ausreichend erledigen.

Es mag dich vielleicht erstaunen, aber ich würde tatsächlich integern den Vorzug geben. Allerdings mit der Auflage sie niemals zu löschen oder für andere Namen zu recyceln.
UUID oder DOI sind aber auch keine schlechte Wahl.

So, dann viel Spass beim Entscheiden.
Ich hoffe es hat ein wenig geholfen.

Liebe Grüsse,
Markus

Hallo Markus,

vielen vielen Dank für Deine schnelle und ausführlichen Mail. Das hilft uns mit Sicherheit sehr, auch für einige Überlegungen des Workflows. Wir halten Dich auf dem Laufenden, wenn wir mit der Entscheidungsfindung weiter sind, da unsere Namensdaten ja auch möglichst zeitnah in die Biodiversitätsdatennetzwerke eingebunden werden sollen.

Herzliche Grüße,
Henning

Hallo Andreas,

IPNI nutzt für ihren Service auch LSIDs (z.B. http://www.ipni.org/ipni/plantNameByVersion.do?id=184409-1&version=1.2.1.3&output_format=lsid-metadata&show_history=true). Ganz interessant ist, dass die auch die Versionierung mit der LSID auflösen.

beim Durchsehen der IDs relevanter Datenbanken, ist mir aufgefallen wie weit LSIDs verbreitet sind. Für CoL scheinen LSIDs wichtig zu sein. Mir ist auch aufgefallen, dass bei AlgaeBase und anderen LSIDs eigentlich erst bei den Aggregatoren wichtig werden. Mal sehen, was Markus dazu sagt.

Ich halte nach wie vor http-Ids für die sinnvollere Variante.

Viele Grüße,
Henning

Hallo Henning,

(Andreas M. interessiert sich brennend für das Thema Identifier, daher nehme ich ihn in für diesen Email Thread und auch für alle anderen zum Thema in 'cc'.)

Mir ist auch aufgefallen, dass bei AlgaeBase und anderen LSIDs eigentlich erst bei den Aggregatoren wichtig werden.
Kannst du das näher erklären? Heißt das, dass Aggregatoren LSIDs für Namen aus AlgaeBase erzeugen? Welche Aggregatoren sind das?

viele Grüße
Andreas

Hallo Andreas und Andreas

„Catalogue of Life“ als rezentes System und TSE (historisch?) scheinen bei der LSID-Verwendung zentral zu sein.

Rod Page hat sich 2005 für die Taxonomy Search Engine dazu geäußert. Alle im Paper genannten Internetquellen sind nicht mehr aktiv.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC555944/

Auszug dort: TSE generates LSIDs by concatenating the name of the source web server with the suffix "lsid.zoology.gla.ac.uk" to generate the authority. The namespace is the name given to the identifier in the source database, and the object identifier is the identifier used by the source database. For example, the record for Homo sapiens in the ITIS database would have the LSID:

urn:lsid:itis.usda.gov.lsid.zoology.gla.ac.uk:tsn:180092
where "tsn" is the "taxonomic serial number" used by ITIS as a unique identifier for each taxonomic name, and "180092" is the tsn for Homo sapiens.
The TSE uses the perl library distributed by IBM's Life Science Identifier project [11] to create a LSID authority for each of the source databases. Hence, any software that can resolve LSIDs (such as LaunchPad [11] or the BioPathways Consortium Web Resolver [32]) can view the metadata associated with an LSID generated by TSE.
Viele Grüße
Henning

PS1 @Andreas K.: Hattest Du schon die Antwort von Markus an Andreas M. weitergeleitet?
PS2 WORMS bei VLIZ verwendet Aphia-Ids, Info: http://www.marinespecies.org/aphia.php?p=webservice

Henning

Interger

0000001

Pro: einfache Nummer, relativ Nutzerfreundlich, relativ einfach in URL zu transformieren

Kontra: nur im Zusammenhang des eigenen Systems eindeutig

UUID

BDCE76E3-FCFE-431C-AFD1-F0AE18A0B0E0

4a0b4089-e478-11e5-86e7-bc764e092680

(36 Zeichen)

Pro: global sehr wahrscheinlich eindeutig, automatisierte Weiterverarbeitung einfach, relativ einfach in URL zu transformieren

Kontra: Nutzerunfreundlich für menschliche Nutzung (abschreiben, merken…)

Http-Identifier

http://herbarium.bgbm.org/object/B100209225

http://algaeregistration.org/typus/

http://algaeregistration.org/name/

Pro: keine Auflösung notwendig, Identifier direkt klickable

Kontra: extra Domain müsste erworben und langfristig erhalten werden

DOI

http://dx.doi.org/10.3372/AR0000001

doi:10.3372/AR0000001

Pro: -

Kontra: Kosten1€/doi (NT), DOI für Einzelrecords nicht vorgesehen (NT), System nicht ausfallsicher (MD), Publisher wollen vielleicht keine dois eines anderen Verlages in ihren Originalpublikationen (WHK)

Henning

Hallo Henning,

super Übersicht!

Ich würde die LSIDs auf jeden Fall mit in diese Liste mit aufnehmen.

Alternativ zu DOIs könnten auch NOIDs (Nice Opaque Identifier) /Handles verwendet werden.
Diese werden bei BHL-Europe (BHL?) und von vielen Bibkiotheken eingesetzt und werden vornehmlich für Archivierte Medienobjekte eingesetzt.

• https://wiki.ucop.edu/display/Curation/NOID
• https://en.wikipedia.org/wiki/Handle_System

Andreas

Hallo Andreas,

dieses Dokument (Beginner’s Guide to Persistent Identifiers Version 1.0) werde ich auch lesen, weil es am Schluss einige Entscheidungshilfen für Identifier gibt.

Viele Grüße und gute Heimreise,
Henning

Hallo Andreas,

nach unseren Diskussionen und dem Input von Markus, habe ich in den folgende Publikation gelesen:
GBIF (2011). A Beginner’s Guide to Persistent Identifiers, version 1.0. Released on 9 February 2011. Authors Kevin Richards, Richard White, Nicola Nicolson, Richard Pyle, Copenhagen: Global Biodiversity Information Facility, 33 pp, accessible online at http://links.gbif.org/persistent_identifiers_guide_en_v1.pdf.
http://bioimages.vanderbilt.edu/pages/guid-applicability-final-2011-01.pdf

Dort gibt es auch einen Set von Recommendations.

Wir wollen „Abstract objects“ verwalten (Diese Objects sind nomenclatural acts, d.h. es sind weder Identifier für den Namen, noch für die Species noch für den Typus sondern jeweils für nomenclatural acts mit Metadaten (wo publiziert, legitim?, valid?))
GBIF empfiehlt für Namen und andere „Abstract objects“ die Verwendung von GUIDs, wobei zwischen dem Identifier und der Auflösung unterschieden wird.

Auf Seite 6 werden die 3 Anforderungen an Identifier genannt:
(1) Persistence + (2) Uniqueness + (3) „data object that it represents can be easily retrieved“

Persistence: UUID, DOI
Unique (global): UUID, (single database system): Integer
Einfacher Zugang (self-resolving, actionable): HTTP-Identifyer

Das Beispiel von ZooBank (Co-Autor des GBIF-Guides Richard Pyle ist involviert) ist ziemlich gut, weil sie alles vereinen: UUID, die Teil einer LSID und vor allem einer http-URI sein kann. Einziger Haken ist, dass sie die 36Zeichen-UUID menschlichen Nutzern zumuten.

urn:lsid:zoobank.org:act:BDCE76E3-FCFE-431C-AFD1-F0AE18A0B0E0
http://zoobank.org/NomenclaturalActs/BDCE76E3-FCFE-431C-AFD1-F0AE18A0B0E0

Wenn ich Markus’ Mail noch mal gründlich lese, wäre eine DOI-Lösung auch möglich.

Lassen wir mal das kommerzielle „crossref“ mit den hohen Kosten beiseite.
Markus bezog sich auf „datacite“ und darauf: „via DataCite kann man als eigene DOI authority fungieren sodass diese auch nichts kosten“.
DataCite wird von TIB Hannover betrieben (? https://www.tib.eu/de/publizieren-archivieren/doi-service/doi-registrierung/), die deutschen Großforschungseinrichtungen sind dabei und das ganze wird von DFG und BMBF unterstützt. Die Frage wäre, wie schnell man als eigene DOI authority fungieren könnte und ob wir das wirklich wollten.

Das habe ich jetzt auch gefunden und mir angeschaut, wie GBIF mit der Vergabe von DOIs bei Downloads umgeht. Ich habe eine Datenabfrage gemacht und heruntergeladen (Siehe E-Mail). Bei dem Prozess (schnell!) wurde eine DOI erzeugt, die mit relativ geringer Verzögerung über Datasite abrufbar war. Ich bin dazu in Pangaea gegangen, habe die von GBIF erzeugte DOI

doi.org/10.15468/dl.vy322t in den Resolver https://doi.pangaea.de/ gepastet und war bei meinem Download-Record.

Was wir tun könnten: DOIs verwenden und darüber unsere Integer-IDs auflösen.

Alternative wäre z.B. sowas wie AlgaeRegistry:10123456 mit der Regel für Publisher, dass das mit http://algaeregistry.org[Identifier] verlinkt sein muss.

Soweit meine Überlegungen dazu,
viele Grüße und ein schönes Wochenende,
Henning

Lieber Andreas,

Gestern habe ich kurz mit Anton gesprochen, der noch einmal bekräftigte, dass die DOI-Metadaten eher aus dem Bibliotheksbereich kommen.

1. Fragte er, ob irgendwo anders DOIs in Registrierungszusammenhängen oder für Namen verwendet werden, was ich verneinte.
2. Anton meint, dass moderne & erfolgreiche Systeme wie ZooBank auch sowas wie Best-Practise sind.
3. Anton sagte, dass DOIs unseren Bemühungen http-URIs zu installieren entgegenlaufen.

Abgesehen davon habe ich heute die Ansprechperson bei TIB zu DOIs erreicht. Wenn ich das richtig verstanden habe wäre für uns alles kostenfrei.
Es gäbe 2 Optionen für uns. 1.: Da die Universitätsbibliothek der Freien Universität als Daten Center fungiert und einen Vertrag mit TIB Hannover hat, könnten wir über die UB gehen. Oder 2. Wir würden selbst als Datacenter fungieren, was wohl durch das Leitungsgremium abgesegnet und einen eigenen Vertrag der Museumsleitung mit TIB möglich wäre. Zu Details warte ich noch auf Rückmeldung von TIB. Auch zeitlich sollte alles relativ zügig gehen. Eine Datenbank-Ausgabeseite zu einem Nomenclatural Act oder einem Taxon könnte als Landing Page fungieren.

DataCite hat eine neue Metadatenschema-Version (die nächste Vollversion ist in 2-3 Jahren zu erwarten). Zur neuen Version 4.0 gibt es ein Webinar (eine Stunde Laufzeit und nicht unbedingt nötig).
Wichtiger ist die Dokumentation des neuen Metadaten-Schemas von 41 Seiten. Mit dem müssen wir uns intensiv beschäftigen, wenn wir DOIs via DataCite nutzen wollen und wir sollten uns damit beschäftigen, da viele Fälle, die bei der Weitergabe von Daten an Menschen und Maschinen in der MetaData Working Group bereits berücksichtigt sind. Z.B. Zitierung externer Quellen via DOI, ISBN, handle, LSID etc.

Für mich war interessant (S. 3), dass die Metadaten genutzt werden, um Forschungsdaten, die über DOIs zugänglich sind zu beschreiben, dass aber auch andere Identifier-Schemas für die Zukunft von DataCite erwogen werden. Grundsätzlich gibt es eine starke Überlappung von Daten, die wir erheben wollen und deren Metadaten; grundsätzlich passt das Metadatenschema eher für komplexe Forschungs-Datensätze, als für unsere „Nomenclatural Acts“.

Die Dokumentation ist über http://schema.datacite.org/meta/kernel-4.0/doc/DataCite-MetadataKernel_v4.0.pdf einsehbar.

Soweit zum Zwischenstand.

Viele Grüße,
Henning

Hallo Henning,

mir scheint wir kommen der endgültigen Entscheidung näher.

Das Metadatenschema der DOIs passt nun wirklich nicht so gut für unseren Anwendungsfall. DOIs scheiden auch aus den anderen genannten Gründen eher aus.

Ich habe Richard Pyle von ZooBank gefragt aus welchen Gründen ZooBank LSIDs verwendet.
Seine Antwort ist sehr interessant, das er sich auch klar gegen LSIDs ausspricht und gleichzeitig auch Argumente für UUIDs in die Waagschale wirft:

In any case, my advice for identifiers is: DO NOT use LSIDs!  At the time we
selected them, the biodiversity informatics community had embraced them, so
Catalog of Life, IPNI, Index Fungorum and ZooBank all adopted them. However,
the rest of the community abandoned them.  Soon we will also abandon them as
well.

However, the SMARTEST thing we did was to use UUIDs as the object
identifiers, so I would STRONGLY encourage you to adopt UUIDs for the core
identifier scheme.  LSID, HTTP, DOI, etc. are all dereferencing mechanisms,
allowing people to retrieve information about records by placing an object
identifier in the context of a resolution service.  To be clear, you can
break down an LSID such as this:
urn:lsid:zoobank.org:act:A932E38D-5B1F-44AF-8385-89498FE8B3B6
into the dereferencing metadata: " urn:lsid:zoobank.org:act:"
and the object identifier: "A932E38D-5B1F-44AF-8385-89498FE8B3B6"

The same is true for DOIs.  We could very easily create a DOI prefix to the
same object identifier to make DOIs:
10.XXXX/A932E38D-5B1F-44AF-8385-89498FE8B3B6

We already do the same for HTTP:
http://zoobank.org/A932E38D-5B1F-44AF-8385-89498FE8B3B6

In any case, there are MANY reasons why the object identifier should be a
UUID.  It's ugly for humans to look at, but these identifiers are not
intended for humans.  For computers, they are fantastic.

So, if you decide to go with DOIs, I would strongly suggest you construct
them with UUID object identifiers.

ZooBank wird anscheinend in Zukunft auch HTTP-Identifier vergeben. Wir sollten uns dieser 'Best Practice' anschließen.

Der Vorteil von UUIDs gegenüber reinen Integer Core-IDs, den Rich hier nennt, ist meines Erachtens schwerwiegend. Bei einer Entscheidung für UUIDs hätten wir einen Garanten für Zukunftssicherheit in der Tasche.
Selbst wenn in ferner Zukunft unser Domain-Name verloren geht, das HTTP Protokoll zum Auslaufmodell wird, oder die Algenregistrierung mit einem anderen System fusioniert hätten wir immer noch die Grantie dass zumindest die Core-ID global einmalig ist. Bei Integer IDs könnten wir hingegen Probleme bekommen.

Viele Grüße
Andreas

Hallo,

das war genau meine Befürchtung mit dem Metadatenschema.

Wir sollten die beiden Ebenen „Lokaler identifier“ und „nach außen gereichter Identifier“ unterscheiden.

Bei unseren Specimens gibt es zum Beispiel nach wie vor die lokalen Barcodes und dann gibt es zusätzlich die nach außen publizierten http-URIs, mit dem Barcode als Bestandteil. Beides sind Identifier für dieselben Objekte mit verschiedenen Funktionalitäten. Richard Pyle sieht das ein wenig anders (UUIDS sind die Identifier und der Rest ist sozusagen nur Protokoll), aber in der Praxis ist das egal.

In dem Algenregistry-Fall wären das dann lokal die UUIDs und nach außen würde wir sie als http-URI mit unserem eigenen Metadatenschema reichen und alles ist gut.

Die andere Diskussion darüber, welche Objekte überhaupt Identifier haben sollen, hatte ich nicht richtig verstanden. Interne Identifier (UUIDs) vergeben wir ja ohnehin für alle relevanten Klassen. Es geht dann wohl eher darum, was wir nach außen reichen, oder? Das würde ich versuchen, von der Nutzerseite aus zu sehen. Also was die Objekte sind, die ich aus Nutzersicht referenzieren können möchte. Vielleicht können wir ja nochmal darüber skypen?

Ich schicke das auch nochmal an Walter, der sich ja wohl für DOIs ausgesprochen hatte?

Viele Grüße
Anton

Hallo Anton

Interne Identifier (UUIDs) vergeben wir ja ohnehin für alle relevanten Klassen.
Es geht dann wohl eher darum, was wir nach außen reichen, oder?
Das würde ich versuchen, von der Nutzerseite aus zu sehen.
Also was die Objekte sind, die ich aus Nutzersicht referenzieren können möchte.

Genau das ist der Punkt und zudem ein Weiteres Argument für UUIDs. Wie du geschrieben hast haben wir dadurch flexibler und können nach Bedarf auch für Objekt-Typen die anfangs noch keinen „nach außen gereichten Identifier“ haben einen diesen zur Verfügung stellen.
Bei reinen "Integer-IDs" ist das mit einem größeren Aufwand und mehr Abwägen/Überlegen verbunden.

Vielleicht können wir ja nochmal darüber skypen?

Sehr gerne!

Andreas

Hallo,

von der Nutzerseite her, sehe ich als „Objekte“ (mit IDs) eigentlich nur
den Registration Event selbst (vom Registration Centre selbst vergeben),
den Namen (alle Namen) einschl. des standardisierten Autorenzitats (Fremd-IDs wo möglich),
den Beleg (Specimen oder anderes nomenklatorisches Belegobjekt) (dito)
und das Literaturzitat (dito).

Herzlichen Gruß
Walter

Hallo Andreas,

in Bezug auf DOIs ergibt sich jetzt folgendes (daher jetzt doch erst mal kein größerer Verteiler von meiner Seite):

Ich habe Walter auf den gegenwärtigen Zwischenstand gebracht und hatte das Blatt im Attachment als Diskussionsgrundlage mit.
Wie zu erwarten, ist jetzt nicht der Zeitpunkt in Bezug auf DOIs übers Knie zu brechen.

Walter hat noch einmal für DOIs geworben:
Grund 1: DOIs sind gängiger Bestandteil von Zitierungen in Journals, sie werden genutzt und sind bei der Community akzeptiert (die Argumente hatte Walter schon genannt).
Grund 2: Für Forschungsförderer hat ein DOI-System auch große Akzeptanz (Die DOI-Vergabe von GBIF im Bereich von Datendownloads ist wohl bei DFG und BMBF gut angekommen).
Bemerkung zu den Metadaten: Einerseits sollten wir schauen, wie groß der Aufwand ist NUR die mandatory Fields zu bestücken, andererseits sollten wir das Potential prüfen, die Metadaten gezielt für eine möglichst große „Data discovery“ zu nutzen (z. B. zur Verschlagwortung, z.B. für höhere Taxa bzw. Großgruppen).
Bemerkung zum Workflow: Walter schlug vor zu überlegen, ob der Workflow so laufen könnte, dass wir Identifer vergeben, die nach Prüfung der Publikation (elektronisch, Print, Buch etc.) erst bei uns zur DOI gemacht werden.

Ergebnis: DOIs sind für uns weiter im Rennen, d.h. ich werde nach dem Urlaub weitermachen mit der Prüfung, wie wir DOIs vergeben könnten UND wir haben DOI weiter auf der Agenda.

Von meinen Identifier-Beispielen im Angang gefallen ihm die mit den kürzeren Zahlen besser, als die UUIDs für den Publikationsprozess (siehe auch meine Bedenken von heute Morgen):

Bevorzugt, wenn wir uns für http-Identifier entscheiden:
http://phycobank.org/name/30000001

Bevorzugt, wenn wir uns für DOIs entscheiden:
doi:10.15468/30000001

Viele Grüße,
Henning

for the final decision see #6592#note-2