[tdwg-content] DwC taxonomic terms

[Blum, Stan]

> -----Original Message-----
> From: "Markus Döring (GBIF)" [mailto:mdoering at gbif.org]
> Sent: Tuesday, August 25, 2009 2:31 AM
> To: Blum, Stan
> Cc: tuco at berkeley.edu; tdwg-content at lists.tdwg.org
> Subject: Re: [tdwg-content] DwC taxonomic terms
> 
> Stan,
> Im not sure if I understand you correctly when saying we should
> differentiate between describing taxa and using them for
> identifications. Do you suggest to have a completely seperate set of
> terms for the two purposes?

Taxon(Concept)ID would be the same in both contexts, description and identification.  My point was that TaxonNameID should NOT be included in an identification.  Include the name, yes, along with nameAuthor, date, accordingTo elements, but not the NameID.  They are all just strings to be processed in determining what taxonomic concept was intended. I think a TaxonNameID is useful only in documenting the derivation of names (if it's useful at all).  That could be an extreme view, but I tossed it out to see if other agreed or not.



> In case we have 2 ID terms, one for the name (scientificNameID) and
> one for the concept (taxonConceptID), this maps nicely to TCS. The
> reason why we favoured nameUsageID over taxonID was that a taxon by
> definition is accepted. 

In the context of an identification, yes, a taxon is asserted to be valid/accepted by the identifier (at the time), but not all identifications are accepted by the data manager, so that last statement isn't always true.  Also not all taxa are accepted/valid within a classification (if it includes synonymous taxa).  

I think "nameUsageID" is too obscure for general use.  It makes sense, but only after understanding the "name-according-to" concept.  I think TaxonID along with (and therefore different from) TaxonNameID make a better combination.  TaxonConceptID also works well.


> And it would therefore be awkward to use this
> term as the ID for a synonym or misapplied name - unless it refers to
> the accepted taxon and is not a "primary key". If we call it
> taxonConceptID this might be less of a problem. TCS does the same and
> uses the taxon concept ID as a primary key for classic synonyms aka
> nominal taxon concepts.

I don't follow the "primary key" point, but I think we agree about the taxonConceptID as the preferred (or acceptable) name for this term.


> My biggest concern with going for actually two classes (name & taxon
> concept) and having 2 IDs for them is what do other ID terms like
> originalNameID, higherTaxonID, acceptedTaxonID refer to? It might
> cause confusion in case the IDs are not GUIDs - which I think we will
> have to still live with for quite some time. On the other hand this
> might be the price to pay for being exact and the terms quite clearly
> are called either xxxNameID or xxxTaxonID...

If we are moving from distributed query to harvesting and querying against a large integrated repository, the need for most of the higher taxonomic names goes away.  We put them in the original DwC to support querying.  In a large integrated repository, the higher classification used by the provider will be stripped off, won't it?  All that will matter is the lowest level (most precise) taxon used in the identification(s).

Are we still trying to support the distributed query function?

-Stan