GUIDs for Taxon Names and Taxon Concepts

Richard Pyle deepreef at BISHOPMUSEUM.ORG
Fri Nov 11 13:22:05 CET 2005

Hi Roger,

Many thanks!  This is helpful.

> I think you are wrong in your conclusions that we do not need
> GUIDs for TaxonNames and TaxonObjects

You are mistaken if you believe that I don't think we need GUIDs for
TaxonName objects.  I *do* think we need them.  I just believe that we will
do more harm  than good if we encourage a proliferation of separate
Name-GUIDs and Concept-GUIDs, when there is not a clear distinction between
them.  If we recognize two distinct "kinds" of GUIDs, with the realization
that the same informational object (e.g., a new combination) would be
represented by one data provider as one "kind" of GUID, and by another data
provider as the other "kind" of GUID, then I think we are setting ourselves
up for some really thorny data management issues down the road.

> I need to do diagrams
> to illustrate the case so have created a wiki page here:

This is excellent and I will expand upon it in the Wiki to reflect the point
I am trying to make as soon as I have time.

> > Yes, you could certainly force-treat zoological names as though they
> > botanical names (treating new combinations as "new names"), just as you
> > could easily force-treat botanical names as though they were zoological
> > names (assigning TaxonName GUIDs only to basionyms, and representing new
> > combincations via Usage/TaxonConcept GUIDs).  I just believe that we
> > come to regret it if we leave the distinction "fuzzy".
> I am not suggesting we leave it fuzzy I am suggesting we leave it up to
> the nomenclators and that it isn't a GUID issue.

It is a GUID issue if there are two different "kinds" of GUID established,
without a clear distinction between them. And I think the current
distinction between whether a data provider sould establish a TaxonConcept
GUID or a TaxonName GUID for a given data record is "fuzzy".

> Just because we are not solving the problem here does not mean that
> we are not going to get the problem solved.

Yes, but we may be creating a new problem, or exacerbating an existing
problem, by introducing different kinds of GUIDs without a clear
understanding of which types of GUIDs apply to which kinds of data objects.

> Then don't refer to the TaxonName GUIDs issued by nomenclators when you
> issue your TaxonConcepts. Just ignore the nomenclator bit. If you are
> correct then everyone will follow your lead. A two GUID system will just
> degrade to a one GUID system if the names thing is wrong.

It's not about "right" or "wrong" -- it's about optimizing the efficiency
and effectiveness of information exchange.  Encouraging the creation of
ill-defined GUIDs carries with it a risk of impeding information exchange,
because of ambiguities about mapping records in one dataset to records in
another dataset.

> Here is a definition of the two types of GUID:
> A TaxonName GUID resolves to a data object that only contains
> information about nomenclature. The provider does not intend
> anyone to be able to identify a specimen to this GUID.
> TaxonConcept GUIDs resolves to a data object that contains information
> about the delimitation/circumscription/relationships of a taxon.
> The provider intends people to be able to identify or otherwise
> related data to this GUID.

As a vocal and long-standing commentator on the difference between a
taxonomic "name" and a taxonomic "concept", I feel I have a strong grasp of
this distinction.  What concerns me on this GUID discussion is that I
believe that ill-defined GUID "domains" ("kinds") have the potential of
doing more harm than good.  We don't all agree on what a "name" is.  We
don't all agree on what a "concept" is.  But we probably can agree on what a
usage instance is.  This is why I now advocate focusing on this broadest,
most flexible, and unambiguous of taxonomic entities to start with in
applying TDWG-standard GUIDs to, because ALL datasets can conform to it
(especially if the "SEC" part of the usage instance can be set to "Nobody in

I'll try to articulare this more effectively on the Wiki page you started.


More information about the tdwg-tag mailing list