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