[tdwg-content] DwC taxonomic terms

[John R. WIECZOREK]

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
>