[tdwg-guid] Globally unique vs. globally locatable

Jerry Cooper cooperj at landcareresearch.co.nz
Thu Jun 14 00:12:43 CEST 2007


Here's a use case that's been going around in my head for a few years
now and it raises some issues to which satisfactory solutions haven't
occured to me yet. 

I believe there is a different emphasis in the use of GUIDs around
names/taxon concepts than there are around such things as collections,
observations or items of literature. This use case is about the use of
resolveable GUIDs in any registration system for new organism names (or
nomenclatural novelties in general). 
There are a number of current name registration models, either extant
or proposed, that seem have a centralised model in mind. I don't like
that. What I would like to see is a distributed network of 'name issuing
authorities' wth some overarching governance structure managed by the
code bodies. In this scenario a use case might be this ...

1) Any organisation can set itself as an issuer of new names.
2) It gets agreement from an authoritative body, designated by the code
bodies, that it is a recognised issuer.
3) It hosts a web site/service that allows its community to enter data
on new names (+whatever additional servics it desires)
4) It issues GUIDs associated with new names.
5) It provides a web service to resolve those GUIDs to an agreed, and
unchanging metadata document on the name.
6) It provides a mechanism (push/pull) for anybody, but especially
aggregators, to resolve these metadata
7) It has a contract with the code body that ,should it cease to be an
issuer, then it transfers responsibility for it's service to another
issuer (or perhaps an approved global aggregator service).

So what about LSIDs in this scenario? It appears to satisfy the
technical requirements. However some issues come to mind and I'm sure
those who know more about this than me have answers. I'd be interested
in hearing them.

Some isues are:
a) in the mycological world at least there appear to be a number of
organisations who would like to sign up to this model - but can't jump
the technical hurdle of providing an LSID resolution service. They can
provide metadata, GUIDs and could provide a 'resolution' service to a
global aggregator (in this case IndexFungoruum) by email attachments if
necessary. The LSID technical hurdle should not stall such a system. 
b) the LSID contains a namespace which effectively 'brands' the issuer.
This is where I really don't like the fact that the GUID relies on a
sub-string which contains a namespace. In the case of new names the
original issuer is an important fact, but it should be part of the
metadata document - not the GUID.
c) what happens when an issuer 'goes under' and is required to transfer
responsibility to another designated authority? LSIDs wraps the
resolution mechanism into the GUID. So either the ownership of the
namespace gets transferred or another GUID is issued for essentialy the
same object. Neither option sounds attractive.

This yet another reason why we, Landcare Research, have chosen not to
rely on LSIDs for name object GUIDs, and so our LSIDs contain a GUID
within a GUID.


>>> Ricardo Pereira <ricardo at tdwg.org> 14/06/2007 4:52 a.m. >>>
Hi folks,

Here is another issue from that discussion thread that I'm 
splitting: (simply) globally unique vs. globally locatable. As Chuck

1. An identifier that is simply globally unique - that is, the id is
never duplicated and always refers to the same thing. So, you can use it
as a unique reference in a paper, like an ISBN/ISSN number. But more
importantly, it also can be used in data files/serialized XML to enable
computers to quickly compare import/export records for merge/update,
which is an important function to many, many biodiversity data projects.
But, this id does not itself tell you where it can be found. Its
location must come from another source.

2. An identifier that is globally locatable via the Internet - that is,
the id is never duplicated and always locates the same thing (with a
further definition needed of what the thing is). The globally locatable
identifier needs to be locatable by a web browser (HTTP) but more
importantly also by web services which may want to use a different

I would argue that, without loss of generality, any identifying 
scheme considered by this group (LSID, DOI, Handles, ARK and any HTTP 
URL based scheme) fulfill both use cases. Since we are interested in 
sharing data, the 2nd use case is far more important for us than the 
first. For that reason, I would suggest that any other scheme that 
provide globally unique but non-locatable identifiers (i.e. that
use case #1 but not #2) would be irrelevant to this group.

Such a scheme would still be important for cases other than sharing 
data, but that discussion would be outside of the scope of this group.

If you are interested in discussing the best way to make your local 
identifiers globally unique (which was the issue that started this 
discussion I suppose), that's the subject of another (very relevant) 
thread. For now the only thing I'll say about that is that there are 
guidelines for making local identifiers globally unique in each 
identifying scheme. In the particular case of LSIDs you may find 
information about that in the following documents:

* The LSID Specification - http://www.omg.org/cgi-bin/doc?dtc/04-05-01
* LSID Best Practices (Naming conventions) - 
* LSID Namespaces discussion - 

In any case, rest assured that we will sum up all those guidelines 
into a section of the Bratislava Declaration ;)


tdwg-guid mailing list
tdwg-guid at lists.tdwg.org 

WARNING: This email and any attachments may be confidential and/or
privileged. They are intended for the addressee only and are not to be read,
used, copied or disseminated by anyone receiving them in error.  If you are
not the intended recipient, please notify the sender by return email and
delete this message and any attachments.

The views expressed in this email are those of the sender and do not
necessarily reflect the official views of Landcare Research.  

Landcare Research

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-tag/attachments/20070614/2f8aadc8/attachment.html 

More information about the tdwg-tag mailing list