[tdwg-content] [tdwg-tag] Inclusion of authorship in DwC scientificName: good or bad? [SEC=UNCLASSIFIED]

[Richard Pyle]

All,

Wow, I disappear to Las Vegas for a couple days, and now I don't know what
is more surreal: Vegas, or this thread (my money is on Vegas, though I am
not a betting man).

Couple points: 

>From Tony:
> Well, that sounds fine to me, however you may note that the 
> ICZN Code at least expressly states that authorship is *not* 
> part of the scientific name:

Don't drag the Code in this.  The Code doesn't govern DwC terms.

>From Jim:
> For some inexplicable 
> reason zoologists throw away the parentheses and the stuff following.

For some inexplicable reason, botanists feel the need to track ALL new
combinations as though they were nomenclatural (rather than taxonomic)
events; whereas zoologists more surgically track only the ones that generate
homonyms.
-)

More from Jim:
> I think it is a really bad move to attempt to redefine "name" so as to 
> include the name metadata to achieve some degree of name resolution

I think it's a REALLY bad move to even try to come up with a unified
definition of "name" at all in our context.  Doing so is an unholy
abomination, a lexical atrocity, an affront to logic and an insult the
natural order of the cosmos and any deity conceived by humankind. (to coin a
phrase) 

The First Commandment of biodiversity informatics communication is:

"Thou shalt not useth the unqualified term 'name' with the expectation that
he or she upon whose ears (or eyes) it falls will not completely
misunderstandth thy point."

Rod wrote:
> I'm with Jm. For the love of God let's 
> keep things clean and simple.  

If clean and simple is the goal, then DwC:scientificName should be defined
as the complete set of textual elements useful for recognizing a unique
scientific name (or formula of names, in the case of hybrids).  If the name
is already parsed in the source database, then populate the record with the
parsed elements in their respective DwC terms accordingly, and form
scientificName as a reasonably standard(ish) concatenation of the full set
of elements, to form a string as just defined.  If the name is not already
parsed in the source database, then provide the complete text string (as
just defined) verbatim.

*THAT* is about as simple as it is going to get, I'm afraid.

But Rod was talking about "fields", so maybe he's talking about a database
model, rather than DwC terms (which, I think, this thread is mostly about).

The Model we're taking for GNUB establishes a record for every
"NameElement". For example, if there was a usage representing "Centaurea
affinis Friv. ssp. affinis var. Affinis", there would be four TaxonNameUsage
records (one for each NameElement: "Centaurea" as used at the rank of genus;
"affinis" as used at the rank of species; "affinis" as used at the rank of
subspecies; and "Affinis" at the rank of variety).  We inherit the
authorship for each NameElement through its associated Protonym link.  In
this case, we know it to be an autonym, because each of the last three
(infrageneric) NameElements (epithets) happens to share the same Protonym.

Besides the parsed NameElement, GNUB also includes fields (for each
NameElement) for: 

VerbatimNameString (actual string of characters used to represent the most
complete form of the name, inclusive of authorships, prefixes, suffixes,
etc., )

TaxonRank (controlled vocabulary)

VerbatimRank (the actual rank they declared it to be within the usage
instance, if some obscure-ish rank from the 18th century that is not among,
but easily mapped directly to, one of the Controlled Vocabulary items for
TaxonRank)

CorrectedNameElement (in case the usage was not in compliance with the Code;
such as feminine adjectival epithet combined with a masculine genus, or
other such Code-correctable anomalies)

Because the names are fully atomized there can very easily be generated a
"standard" name-form, with or without authorship and/or standardized
prefixes & suffixes & such.

Simple?  HELL no.  Powerful?  You betcha.

Aloha,
Rich