Hi Roger,

Here is a possible solution that might just work!

1. Only one GUID system.
2. For taxon stuff we call these NameUsage GUIDs
3. NameUsage GUIDs come in different 'flavours' - probably identified by

the metadata returned.

4. Some flavours may be TaxonName, TaxonConcept and NameOccurrence
5. We have an ontology that defines the types of NameUsage GUID.
6. The ontology can evolve through time catering for different needs.

This is *EXACTLY* what I have been trying to describe!! Thank you, Ricardo and Roger, for communicating in one short post what I have evidently failed to communicate in many long, ranting posts! :-) I really should become more fluent in the "object/class/ontology/identity" geek-speak...but my brain is already full with taxonomy & database geek-speak (not to mention technical diving geek-speak).

I would point out that within the "TaxonName" flavor, there may be "subflavors" like "Basionym", "New Combination", and "Orthographic Variant" -- just as within the TaxonConcept flavor there are "Original", "Revision", "Nominal", etc. subflavors. (Apologies for my Amerikanized spelling...)

Questions this raises for me are:

1. Do we have a single managed ontology for all TDWG GUIDs i.e.

we have a single ontology to manage different types of specimen GUID and different types of NameUsage GUID. This looks like a central ontology for taxonomic object classes and may take the debate outside the GUID discussions into general architecture.

I think this is an important issue that needs to be discussed, but is probably beyond the scope of this GUID discussion forum.

2. Can you tell by looking at a GUID what it's class is. i.e. do

we embed the class name in the LSID namespace.

I would say "definitely no". For many reasons...one of which is that the same GUID might be returned with different metadata depending on what "flavor" is requested/delivered (e.g. GUID 1234 might apply to a NameUsage instance that represents both a Basionym Creation [TaxonName flavor], and a TaxonConcept of type "Original"). I think this is something that should be handled by the resolution service, via the established ontology.

3. If we use LSIDs what do we include in the 'data' returned and what

in the metadata returned? I believe the metadata can change but data can't so we may want to put our metadata as the LSID data (I don't think an object class should change - I may be wrong)

For me to understand the question, I'll need you to elaborate on what you mean by "object class". I can think of at least two possible meanings of this term in this context, and my answer would depend on which meaning you intended.

My general feeling is that most of the useful information is metadata, the only candidates for data (in my mind) being the literal text string (NameString), a ref pointer to a defined Documentation instance (if any), and perhaps position information (e.g. page) within the Documentation instance. All of these might be intially recorded in error, but could be corrected via the LSID revision id (version).

But I have neither sharp insight nor strong opinions regarding such matters, so I'll leave that level of technical debate to more capable individuals.

There are probably other questions.

I have several, but I think they mostly lie outside the scope of this discussion forum, and are perhaps best addressed down the road (e.g., at the February workshop).

This may be a fruitful way forward.

Yes, I hope so.

Aloha, Rich