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/