Taxon debate synthesis?

Richard Pyle deepreef at BISHOPMUSEUM.ORG
Wed Nov 16 02:04:17 CET 2005

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

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

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.


More information about the tdwg-tag mailing list