Globally Unique Identifier - Part III

[Richard Pyle]

> > It seems to me that a lot of complexity would disappear if we
> could all get
> > behind a single issuer of GUIDs, and mirror the capability to
> resolve those
> > GUIDs on dozens or hundreds of servers around the world, and
> only use the
> > GUIDs in a semantic context that is self-evident.
>
> Perhaps.  But what about if an insitution wants to provide IDs for more
> than just specimen or name objects?  Should we always rely on a single
> authority to provide a mechanism for doing that? I don't think that
> would go very far.

No -- we come together as a community to agree upon mechanisms for GUID
assignment and exchange among well-defined classes that we routinely wish to
share and aggregate information about (Specimen/Observations,
Names/Concepts/Assertions, References, Agents, and maybe a couple of
others). If Bishop Museum wanted to provide IDs for, say, Baseball cards, or
Star Wars memorabilia, or some other object type, then it would coordinate
with other holders of data relating to baseball cards [or perhaps trading
cars in general] or Star Wars memorabilia [or perhaps movie memorabilia in
general], and they would decide amongst themselves whether DOIs or LSIDs or
UUIDs, or MACs, or whatever make the most sense for their particular needs.

If Bishop Museum wanted to provide IDs for something like condition reports
of specimens over time, or changing dynamics of wild populations, or DNA
sequences, or Images, or any number of other objects that are relevant to
bioinformatics, then they would propose a new class of objects to TDWG,
along with an appropriate schema and recommend standards for implementation,
and other institutions with like-data would discuss the optimal approach to
dealing with those sorst of data. The "community" would debate the various
options in the context of integration with existing data exchange protocols,
etc., and a standard would emerge.

Don't get me wrong....the letter "G" is my favorite letter in DiGIR.  And
the more I think about it, the more I understand why you want the IDs to
have embedded context that can be resolved automatically, without any custom
tweaking to accomodate new classes of IDs.  But the costs (or at least my
perception of the costs) do tend to frighten me a bit.  It makes a lot more
sense for specimen data.  If Bishop Museum's server is down -- tough luck,
you can't have our data.  But I would *HATE* to rely on any one particular
server to get public-domain information like taxon names whenever I needed
it.  Yes, the single-point failure problem is real.  But there are
technological solutions to minimize those sorts of concerns (on an
intermittent basis) down to something indistinguishable from zero.  I don't
think I have ever gone to Google and found it down.  And there can be
redundancy built into the system.

So now let me ask you this:  Are the advantages of serving the GUID needs of
both specimens and taxon names via an identical, generalized GUID scheme
greater than the advantages of custom-tailoring the GUID scheme for each
different sort of data (owned, vs. public-domain)?  I think I already know
the short answer is "Yes", but I'm interested in the reasons (e.g., common
set of software tools to deal with both, etc.)

> The DN portion is meant to be resolvable by the DNS system.  So yes,
> there is a dependency on the continued existence of the DN, but is can
> be set up to be resolved by any LSID service endpoint.

I think I need to learn more about LSIDs before forming too strong of an
opinion either for, or against them.

> If we use the MAC approach + a context such as an LSID or DOI form, then
>   there is absolutely no need for a central issuing agency.

Agreed!  And that might be the better approach (for a lot of reasons).  My
only concern would be to what extent desktop database applications can uses
MAC values as primary keys (compared to using something like long integers)
efficiently and effectively, when manipulating large datasets in real time.
I guess this may be a trivial point in the grand scheme of things -- but
ultimately taxonomists will want to be able to work with large datasets on
their personal computers.

> Again, just use a MAC based GUID inside an LSID context.  If you have
> any MS dev tools on your machine type "guidgen" and the command prompt.
>   Voila!  Globally unique identifiers.  No matter how many times you
> push the "New GUID" button.

Yes, and this may be the best approach. MACs are scary for people to read,
but as I said before, people really shouldn't be reading them.

But in order to avoid having a bottleneck for data resolution at the point
of MAC issuance, you would need to get the data mirrored efficiently across
many servers. This could be done like DNS (as I undertand it), where the
changes propagate through a haphazard web of servers.  But I think I'd be
more comfortable having some sort of centralized hub or coordinator (like
GBIF) to ensure data mirroring is done efficiently and completely.  On this
point, I could very-well be persuaded to change my view.

> > Again, I'll have to think about this some more.  I certainly don't think
> > that the "system" should be incapable of dealing with new
> classes -- sort of
> > like how anyone can develop their own Federation Schema and use DiGIR to
> > establish specific information networks.  But I'd hate to see a
> breakdown in
> > the global transmission of biodiversity information simply
> because different
> > subgroups establish their own special-needs,
> non-mutually-compatible classes
> > for dealing with essentially the same kinds of information
> (especially if
> > they do not also conform to a generalized international standard).
>
> Bah.  That's the whole point of this - to facilitate data exchange.  If
> a small subgroup wants to start exchanging data in an abbreviated
> format, so what?

No problem if they also continue to provide the relevant bits via the
"conventional" means.  But BIG problem if everyone in Europe gravitates
towards one conventional standard, and everyone in the U.S. gravitates
towards a different flavor, and everyone in Asia gravitates towards yet a
different flavor.  I'm thinking Cell Phone standards, NTSC vs. PAL,
competing HDTV standards, DVD+R vs. DVD-R, etc., etc.

Already we have some problems in dealing with the fact that ICZN and ICBN do
not have perfectly compatible Codes of nomenclature.  Imagine if different
geographic regions adopted their own versions of nomenclatural Codes; or if
the Fish people got together and decided they wanted slight different rules
to apply to their names.  Such freedom would not likely contribute favorably
to scientific progress.  Taxonomists conform to respective Codes of
nomenclature not because they are perfect in how they establish names, but
because the community has converged on a single standard.

> As long as the identifiers being used are able to
> resolve the type of object being passed around,

...which they presumably wouldn't be if the providing server were
offline....no?

> and the objects conform
> to their definitions, it shouldn't be a problem.  By initially
> establishing a robust framework for Scientific Names and perhaps
> specimen data / collections, then there will be little need for others
> to recreate new ways to represent that data.

...so why comprimise the optimality of the system in order to accomodate
those who might prefer to define objects in a slight different way from
everyone else?

> The benefits of a robust
> reliable representation and provision of cheap, effective software tools
> will hopefully overcome the steep learning curve needed to even
> understand what's in some of these schemas.

Yes, but this is something we both agree on!

> But if I want to say to you, hey look at this specimen xxx while we're
> chatting from around the world using an instant messenger while
> collaborating on some project, would't it be nice to just be able to
> type in lsid:mymuseum.org:specimen:1234 and have your client retrieve
> that exact data and associated metadata directly?

But such a chat would certainly provide an opportunity to suggest context.
Wouldn't it be easier if I said "Hey, go to GBIF and look up SpecimenID
1234"? This scenario seems to apply equally to both of our world
perspectives. The only advantage I would see for LSIDs in this case is if I
forgot to mention to my colleague that I wanted her to look up a specimen,
rather than a taxon name, and just told her to "look up 1234".  Not likely
in a human-human conversation.

> A trivial example but
> one that can form the foundation of some cool stuff for data exchange
> and interaction.  I thought that was the whole point of these GUID
> things.  But maybe I'm mistaken?

Yes, I certainly agree that this is the whole point of GUIDs!  What I don't
understand is why LSIDs (with domain-active requirements) fulfill this more
effectively (all costs and benefits considered) than other GUID systems.

> Except in the somewhat bizarre case when you need the old version of the
> object.

Yeah, but as you say this is a bizarre case.  In those bizarre cases, you
can send an email to the data manager and ask for a report on the edit
history of the record.  If they got it, they got it. But I don't see this as
being such a routine need that it needs to be accomdated-for by the GUID
system (unless, as I suggested earlier, that it was otherwise completely
transparent and could be ignored without consequence).

> Yeah, good question.  Maybe this should be on the GBIF DADI list or TDWG
> general?  Or even the LSID list?

If it moves, let me know where it goes.  Right now, it's time for bed....

Cheers,
Rich