[tdwg-content] DwC taxonomic terms

[John R. WIECZOREK]

On Tue, Aug 25, 2009 at 2:04 AM, David Remsen (GBIF)<dremsen at gbif.org> wrote:
> 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 current terminology.
> 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
> Standard Dataset
> http://code.google.com/p/gbif-ecat/wiki/CoL_Comparison
> 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.
> Cheers,
> David
> 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 consistent.
>
> 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
> scientificName.
>
> 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
> scientificName.
>
> scientificNameAuthorship, nomenclaturalCode - unchanged
>
> taxonPublicationID: A unique identifier for the publication of the Taxon.
>
> 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:
>
> John,
>
> I think this is based on the different understanding of the other IDs we are
>
> having.
>
> 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 have
>
> argued we would prefer a wider definition closer to the originally suggested
>
> 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 name
>
> effectively can have different IDs if it has been used in different places,
>
> thereby representing different taxonomic concepts. This would make the
>
> 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 occurrenceID,
>
> specimenID and fossilID.
>
> Markus
>
>
>
> 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 Issue
>
> #48 to remove taxonConceptID. If it is removed, how would anyone be
>
> able to capture the proposition that a given specimen was a member of
>
> 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> wrote:
>
> Dear John & DwC friends,
>
> after finally having time to review the current dwc terms again I came
>
> 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 improvements
>
> 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 issues
>
> is larger than I hoped for, but most of them are minor terminology
>
> issues for consistency and not touching the core meaning of the terms.
>
> Markus
>
> ---
>
> #47   rename basionym(ID) to originalName(ID)
>
> http://code.google.com/p/darwincore/issues/detail?id=47
>
> The intend for this term is really to reflect where a name originally
>
> comes from in case it is a recombination. The term basionym is mostly
>
> used with botanists and covers only the cases when an epithet remains
>
> the same, i.e. not replacement names. The best matching, broader term
>
> 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 found
>
> in this document:
>
> http://www.peabody.yale.edu/other/PROTEM/TAXSIG/taxonomy_synonyms_examples.pdf
>
> ---
>
> #48   remove taxonConceptID
>
> http://code.google.com/p/darwincore/issues/detail?id=48
>
> The conceptID is intended to state that 2 name usages / potential taxa
>
> 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 more
>
> than willing to define such an extension
>
> ---
>
> #49   rename scientificNameID, acceptedScientificNameID and
>
> higherTaxonNameID
>
> http://code.google.com/p/darwincore/issues/detail?id=49
>
> no matter what the final term names are I think the 3 ones should be
>
> 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, acceptedScientificNameID
>
> 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 isnt
>
> if combined with an sec reference aka taxonAccordingTo. A taxonID
>
> suggests to refer to a distinct taxon concept. A name usage seems the
>
> smallest entity and can therefore be used to act as a sort of unique
>
> 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 id
>
> 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 usage
>
> id, so in order to gain clarity I would prefer to have the term removed.
>
> #49b rename acceptedScientificName(ID) to acceptedNameUsage(ID)
>
> this term should point to the name usage that reflects the "accepted"
>
> 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, especially
>
> for higherTaxonName/higherNameUsage
>
> http://code.google.com/p/darwincore/issues/detail?id=50
>
> similar to originalName or acceptedNameUsage this term is meant to be
>
> a verbatim pointer to the higher taxon as an alternative way of using
>
> 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
>
> http://dublincore.org/documents/dc-xml-guidelines/
>
> ---
>
> #51 rename namePublicationID to namePublishedInID
>
> http://code.google.com/p/darwincore/issues/detail?id=51
>
> for consistency with namePublishedIn
>
> ---
>
> #52 rename (verbatim)scientificNameRank to (verbatim)rank
>
> http://code.google.com/p/darwincore/issues/detail?id=52
>
> 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
>
> http://lists.tdwg.org/mailman/listinfo/tdwg-content
>
>
>
> _______________________________________________
> tdwg-content mailing list
> tdwg-content at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-content
>
>
>