GUID opacity

[Richard Pyle]

Hi Ricardo,

> 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

Only if TDWG followed your suggestion of breaking opacity and set forth an
equivalent standard for other "domains" of GUID; e.g.:

urn:lsid:some_authority.org:Specimen:id4321
urn:lsid:some_authority.org:Documentation:id9876
urn:lsid:some_authority.org:Agent:id5678

The main reason I am somewhat uncomfortable with LSIDs is that I don't think
they are opaque enough (or, as you described, offer too much temptation to
break opacity), in the sense that they embed human-intelligible information
within the GUID itself.

> 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.

I believe this should be avoided.

> 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.

Again, my gut feeling is that this would lead to long-term headaches for
future data managers.  I would rather see some attribute (something like
"Class" -- though this word is over-used!) be part of any TDWG LSID standard
such that each LSID includes a metadata element from among a shared ontology
(e.g., "Specimen" or "NameUsage" or "Documentation").  LSID issuers may well
use the namespace for this purpose, but I think it wise to at least *try* to
render the namespace semantically opaque, by embedding this sort of
distinction as a standard metadata attribute of any TDWG-compliant LSID.

> But again, that
> could be done in a more extensible manner via a shared ontology and
> separate metadata services.

I would prefer that approach.

> 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.

Agreed!

Aloha,
Rich

Richard L. Pyle, PhD
Database Coordinator for Natural Sciences
  and Associate Zoologist in Ichthyology
Department of Natural Sciences, Bishop Museum
1525 Bernice St., Honolulu, HI 96817
Ph: (808)848-4115, Fax: (808)847-8252
email: deepreef at bishopmuseum.org
http://hbs.bishopmuseum.org/staff/pylerichard.html