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:

http://wiki.gbif.org/guidwiki/wikka.php?wakka=SeparateNamesAndConcepts

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

were

...

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

will

...

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 particular").

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

Aloha, Rich