It seems that DOI allows for any existing IDs to be used as part of the unique identifier. That seems to me as a fast to adopt short term solution but not a good idea for the long term. At first sight I very much liked the LSID specification, but the longer I think about it, the less I like some parts. What I think is missing in the LSID specification is that the unique identifier should be 'meaningless' apart from being an identifier to become time independent (and to avoid possible political problems). Any solution with a URN I can think of has some meaning, which makes solutions like a MAC-address generated GUID favorable in my opinion. And any meaning you need (like an authority of an object) can be specified in metadata instead of using it in the identifier. What is not very clear to me in the LSID specification is where the LSID generated by a LSIDAssigningService is actually stored.

Wouter Addink

----- Original Message ----- From: "Gregor Hagedorn" G.Hagedorn@BBA.DE To: TDWG-SDD@LISTSERV.NHM.KU.EDU Sent: Wednesday, September 08, 2004 6:20 PM Subject: Re: Globally Unique Identifier

I am not quite sure, but to me it seems with "GUID" you refer to the numeric, MAC-address generated GUID type. I have nothing against these. However, any URN in my view is a GUID that has most of the properties you mention:

...

• it is guaranteed to be unique globally, and can be created anywhere,

anytime by any server or client machine - it has no meaning as to where the data is physically located and will there not confuse any user about this

...

• most id

mechanisms, especially URI/URN ids require a 'governing body' to handle namespaces/urls to ensure every URN is unique, whereas a GUID is always unique

The governing body is restricted to the primary web address, and in most cases such an address is already available. Being a member of a governmental institution that explicitly forbids the use without prior consent, and forbids the use of its domain name once you are no longer working for them, I realize some potential for problem.

...

I do think a URL of some kind would be useful for things such as global searches of multiple databases, as this will allow the search to go directly to the data source where the name, referene, etc comes from. But this should not be part of its ID. Maybe a name/id should have several foms, a GUID for an ID and a URL + a GUID for a fully specified name.

What are the current thoughts on these ideas?

A GUID is only part of the problem. The other half of the problem is actually getting at the resource. URN schemes like DOI or LSID (I prefer the latter) intend to define resolution mechanisms. That make the URN not yet a URL - in my view the good comes with the good, location and reorganization independence.

I believe GBIF should install such an LSID resolver, which is why in the UBIF proxy model, under Links, I propose to support a general URL (including potentially URNS), a typed LSID and a typed DOI. This could be simplified to have just a URN (LSID and DOI are URNs), but that would then require string parsing to determine and recognize the preferred resolvable GUID types. Comments on splitting/not splitting this are welcome!

There may be some need to define a non-resolvable URN/numeric GUID as well. However, that would not be under the linking question. Is it correct that linking requires resolvability, or am I thinking into a wrong direction?

Gregor

...

---

Gregor Hagedorn (G.Hagedorn@bba.de) Institute for Plant Virology, Microbiology, and Biosafety Federal Research Center for Agriculture and Forestry (BBA) Koenigin-Luise-Str. 19 Tel: +49-30-8304-2220 14195 Berlin, Germany Fax: +49-30-8304-2203

Often wrong but never in doubt!