GUID opacity

Ricardo Scachetti Pereira ricardo at TDWG.ORG
Wed Nov 16 09:47:19 CET 2005


  Rich and all,

I think Roger raised an interesting issue: GUID opacity.
Reading between the lines of the previous discussions regarding the many
“types of GUIDs” we should have, I suspect that some of us are assuming
that GUIDs should not be completely opaque.

For example, when you say we should have a NameUsage GUID, for example,
would you hardcode that in the namespace of an LSID, like the following one?

urn:lsid:some_authority.org:NameUsage:id1234

LSIDs and other GUID technologies require that their ids must be opaque.
However, due to the syntax of LSIDs, users might tend to circumvent that
requirement and use parts of the LSID (the namespace) for other purposes.

In my opinion, breaking opacity might offer simple implementation path
to hardcode some semantics directly into the GUIDs without requiring any
other service layer. However, that might not be very extensible in the
sense that it doesn’t allow for new classifications of GUIDs that have
been already issued.

I think some of the specimen folks also tend to use this shortcut when
they offer to use same GUIDs for the same physical object. What is
attempted in that case is to hardcode known relationships between
specimens and to simplify identification of duplicates. But again, that
could be done in a more extensible manner via a shared ontology and
separate metadata services.

Again, if decide to use the shared ontology idea (which we haven’t
discussed enough, but we should), we can keep our system flexible and
extensible, and we can leave our GUIDs semantically opaque.

What are your thoughts on that matter?

Cheers,


Ricardo






_______________________________________________________
Yahoo! Acesso Grátis: Internet rápida e grátis.
Instale o discador agora!
http://br.acesso.yahoo.com/




More information about the tdwg-tag mailing list