Globally Unique Identifier

[Wouter Addink]

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 at BBA.DE>
To: <TDWG-SDD at 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 at 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!