[tdwg-content] DwC taxonomic terms
David Remsen (GBIF)
dremsen at gbif.org
Tue Aug 25 11:04:04 CEST 2009
Upon re-read of your post I see that taxonAccordingTo has been
retained. Therefore I can interpret taxonPublication to simply be a
change in the name of namePublishedIn.
I have worked up various examples using the terms in combination with
some extensions we (Markus and I) have been drafting. They are
listed below with comments. Note that given the instability around
the taxon identifier names they might not be congruent with the
Euro+Med Example (http://spreadsheets.google.com/pub?key=tnoVriNunOOMzYp709vtauQ&output=html
We hit a snag with this example when the source database did not
provide identifiers for the misapplied names and we therefore had to
manufacture local identifiers for them. In this example
namePublishedIn holds the unparsed primary citation and
taxonAccordingTo holds the misapplied name reference.
Peabody Museum Zoological and Botanical Synonyms Example
Source Document (http://www.peabody.yale.edu/other/PROTEM/TAXSIG/taxonomy_synonyms_examples.pdf
Transformed Document (http://spreadsheets.google.com/pub?key=ts5YVtLnXCBvv8X-prpprOg&output=html
Transformed Document with Comments (http://code.google.com/p/gbif-ecat/wiki/GNAsynonymsExample
These examples best illustrates my reasoning for the use of the term
"taxon Reference" There is a comments part of the wiki that
highlights some of the issues I hit.
Lastly, this is a mapping of the DwC terms to the Catalogue of Life
I refer to a "GNA standard" in this document to refer to our use of
the draft terms in combination with other draft terms structured as
extensions according to the text guidelines. In this case I used
taxonAccordingTo to reference the latest taxonomic scrutiny property
of the standard dataset.
On Aug 25, 2009, at 7:00 AM, John R. WIECZOREK wrote:
> Right, that all makes sense now, and is exactly the kind of
> simplification that was already in place in the Location class, where
> the locationID refers to the Location as a whole, not some part of it,
> such as a country in one case or a city in another case. So, I agree,
> remove the taxonConceptID.
> I've been struggling with trying to come up with a better term name
> than nameUsage. After reading the arguments again with every
> alternative I can come up with (scientificName, taxonName, taxon_name,
> nameAsUsed, nameAsPublished, publishedName, publishedTaxon) I'm not
> sure I can really do any better for a name that states specifically
> what you are trying to encompass with that term. Nevertheless, the
> term seems awkward, especially on first encounter. The terms would
> have to be very carefully described (but I guess all terms should be).
> The problem is, I think the same problem with recognizing what the
> term is for would happen on the second encounter as well ("What was
> that term for again?"). I don't think that would happen with terms
> that were more familiar, even if their meaning is broad. To me,
> "taxon" works, because it could be a name or a concept - exactly what
> we're trying to encompass.
> So here's what I'd do in an attempt to be clear, concise, and
> Given that the Class is Taxon (which captures the idea of a name as
> well as it does a concept), consistency would argue that the id term
> for a record of the class should be taxonID. The list of terms under
> this scenario would be:
> taxonID, acceptedTaxonID, higherTaxonID, originalTaxonID,
> scientificName, acceptedTaxon, higherTaxon, originalTaxon,
> higherClassification, kingdom, phylum, class, order, family, genus,
> subgenus, specificEpithet, infraspecificEpithet, taxonRank,
> verbatimTaxonRank, scientificNameAuthorship, nomenclaturalCode,
> taxonPublicationID, taxonPublication, taxonomicStatus,
> nomenclaturalStatus, taxonAccordingTo, taxonRemarks, vernacularName.
> I retained "scientificName " for two big reasons. First, the obvious
> alternative "taxon" would be too easily confused with the name of the
> Class "Taxon". Second, scientificName has broad current usage and will
> immediately suggest the appropriate content for most users. An
> additional minor reason is that the term contrasts with and is nicely
> consistent with "vernacularName".
> The rest is all dependent on good definitions. Here are some drafts
> for new definitions for terms that need them. Please suggest any
> necessary revisions.
> taxonID: An identifier for a specific taxon-related name usage (a
> Taxon record). May be a global unique identifier or an identifier
> specific to the data set.
> acceptedTaxonID: A unique identifier for the acceptedTaxon.
> higherTaxonID: A unique identifier for the taxon that is the parent of
> the scientificName.
> originalTaxonID: A unique identifier for the basionym (botany),
> basonym (bacteriology), or replacement of the scientificName.
> scientificName: The taxon name (with date and authorship information
> if applicable). When forming part of an Identification, this should be
> the name in the lowest level taxonomic rank that can be determined.
> This term should not contain Identification qualifications, which
> should instead be supplied in the IdentificationQualifier term.
> acceptedTaxon: The currently valid (zoological) or accepted
> (botanical) name for the scientificName.
> higherTaxon: The taxon that is the parent of the scientificName.
> originalTaxon: The basionym (botany), basonym (bacteriology), or
> replacement of the scientificName..
> higherClassification: A list (concatenated and separated) of the names
> for the taxonomic ranks less specific than that given in the
> kingdom, phylum, class, order, family, genus, subgenus,
> specificEpithet, infraspecificEpithet - all unchanged.
> taxonRank: The taxonomic rank of the scientificName. Recommended best
> practice is to use a controlled vocabulary.
> verbatimTaxonRank: The verbatim original taxonomic rank of the
> scientificNameAuthorship, nomenclaturalCode - unchanged
> taxonPublicationID: A unique identifier for the publication of the
> taxonPublication: A reference for the publication of the Taxon.
> taxonomicStatus, nomenclaturalStatus, taxonAccordingTo, taxonRemarks,
> vernacularName - unchanged.
> On Mon, Aug 24, 2009 at 4:15 PM, "Markus Döring
> (GBIF)"<mdoering at gbif.org> wrote:
>> I think this is based on the different understanding of the other
>> IDs we are
>> If ScientificNameID is purely for the name as the term suggests, I
>> do agree
>> with you that taxonConceptID is still needed. But as me and David
>> argued we would prefer a wider definition closer to the originally
>> taxonID (which was turned into scientificNameID at some point). An
>> identifier for anything that is described by the taxonomic terms,
>> let it be
>> a name, a taxon (concept) or any other use of a name. So the same
>> effectively can have different IDs if it has been used in different
>> thereby representing different taxonomic concepts. This would make
>> conceptID superflous. If the taxon(Concept)ID is to take on this
>> role and
>> the scientificNameID is a purely nomenclatural name identifier
>> only, I am
>> with you.
>> One thing I would like to avoid very much though is that some ID
>> terms would
>> refer to the scientificNameID (like originalNameID) while others
>> like the
>> higherTaxonID would reference the taxonConceptID.
>> I think it all becomes a lot simpler if there is a single taxon/
>> nameID for
>> all purpuses. Similarly I dont think we would want a separate
>> specimenID and fossilID.
>> On Aug 25, 2009, at 0:55, John R. WIECZOREK wrote:
>>> While thinking further in trying to implement the suggested changes
>>> another question occurred to me. The recommendation was made in
>>> #48 to remove taxonConceptID. If it is removed, how would anyone be
>>> able to capture the proposition that a given specimen was a member
>>> a circumscription identified by a registered (having a resolvable
>>> GUID) taxon concept? I pose that one could not, because we would be
>>> left only with name terms. Unless I'm getting something wrong, I
>>> believe this term cannot be removed.
>>> On Thu, Aug 6, 2009 at 5:31 AM, Markus Döring<m.doering at mac.com>
>>>> Dear John & DwC friends,
>>>> after finally having time to review the current dwc terms again I
>>>> across a couple of issues I'd like to see discussed or even
>>>> changed. I
>>>> am working for nearly 1 year now with the new terms during their
>>>> development, especially with the new and modified taxonomic
>>>> terms. So
>>>> far they work very well in practice, but there are a few
>>>> I can think of, mostly related to the latest changes shortly before
>>>> the public review started. I have added them as separate issues
>>>> to the
>>>> google code site, but list them here in one go. The number of
>>>> is larger than I hoped for, but most of them are minor terminology
>>>> issues for consistency and not touching the core meaning of the
>>>> #47 rename basionym(ID) to originalName(ID)
>>>> The intend for this term is really to reflect where a name
>>>> comes from in case it is a recombination. The term basionym is
>>>> used with botanists and covers only the cases when an epithet
>>>> the same, i.e. not replacement names. The best matching, broader
>>>> therefore is originalName I think. Changes have to be done to
>>>> both the
>>>> verbatim name and the ID.
>>>> Good examples for synonyms, basionyms, replaced names etc can be
>>>> in this document:
>>>> #48 remove taxonConceptID
>>>> The conceptID is intended to state that 2 name usages / potential
>>>> are the same, even if they use a different name. This is a special
>>>> case of true concept relations and I would much prefer to see this
>>>> covered in a dedicated extension treating all concept relations,
>>>> especially frequent cases such as includes, overlaps, etc. I am
>>>> than willing to define such an extension
>>>> #49 rename scientificNameID, acceptedScientificNameID and
>>>> no matter what the final term names are I think the 3 ones should
>>>> consistent. Originally it was intended to call them taxonID,
>>>> acceptedTaxonID and higherTaxonID
>>>> with a loose definition of a taxon, more based on the idea of
>>>> that all
>>>> terms here are taxonomic terms and therefore contain taxon in their
>>>> name. The current version scientificNameID,
>>>> and higherTaxonNameID intends to do the same I believe, but the
>>>> terminology invites people to use them not referring to each other
>>>> from what I have seen so far in practice.
>>>> Concrete recomendations:
>>>> #49a replace scientificNameID with nameUsageID
>>>> There is the need to uniquely identify a taxon concept with a given
>>>> name, a name usage. A nameID suggests the name is unique which it
>>>> if combined with an sec reference aka taxonAccordingTo. A taxonID
>>>> suggests to refer to a distinct taxon concept. A name usage seems
>>>> smallest entity and can therefore be used to act as a sort of
>>>> key for names, taxa, taxon concepts or just usages of a name. All
>>>> other taxonomic dwc ID terms can and should point to a name usage
>>>> then. This makes me think if most/all other IDs should reflect
>>>> this in
>>>> their names, see below.
>>>> It could make sense to keep scientificNameID as a ID to the name as
>>>> defined by a nomenclator. But this ID can also be used as a name
>>>> id, so in order to gain clarity I would prefer to have the term
>>>> #49b rename acceptedScientificName(ID) to acceptedNameUsage(ID)
>>>> this term should point to the name usage that reflects the
>>>> taxon in case of synonyms, no matter if they are objective or
>>>> subjective. AcceptedScientificName sounds more like a nomenclatural
>>>> exercise and in accordance with #3 (nameUsageID) the term
>>>> acceptedNameUsage(ID) would be the best fit in my eyes.
>>>> #49c rename higherTaxonName(ID) to higherNameUsage(ID)
>>>> in consistency with nameUsage & acceptedNameUsage
>>>> #50 remove recommendation to concatenate multiple values,
>>>> for higherTaxonName/higherNameUsage
>>>> similar to originalName or acceptedNameUsage this term is meant
>>>> to be
>>>> a verbatim pointer to the higher taxon as an alternative way of
>>>> higherTaxonNameID. Therefore it should only contain a single
>>>> name, the
>>>> direct parent, in my eyes. There are also already the 7 mayor
>>>> ranks as
>>>> separate terms that can be used to express a flattened hierarchy.
>>>> I am aware DwC suggests to use concatenated lists in a single
>>>> term in
>>>> other places, e.g. , but I believe it would be better to keep the
>>>> meaning singular and use multiple instances of that term to express
>>>> multiple values. Dublin Core also recommends to use multiple XML
>>>> elements for multiple values, see recommendation 5 in
>>>> #51 rename namePublicationID to namePublishedInID
>>>> for consistency with namePublishedIn
>>>> #52 rename (verbatim)scientificNameRank to (verbatim)rank
>>>> to avoid discussions about whether the rank belongs to the name
>>>> or the
>>>> taxon and also because its nice and short and there is no clash in
>>>> biological terminology.
>>>> tdwg-content mailing list
>>>> tdwg-content at lists.tdwg.org
> tdwg-content mailing list
> tdwg-content at lists.tdwg.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tdwg-content