[tdwg-content] proposed term: dwc:verbatimScientificName

Richard Pyle deepreef at bishopmuseum.org
Thu Dec 9 22:31:10 CET 2010


I guess what I don't understand is: what would go in
scientificNameWithAuthorship that isn't already achievable via these three
terms:

verbatimScientificName (any text string purporting to represent as
unambiguously as possible a scientific name, inclusive of authorship if
available)
scientificName (effectively canonical name explicitly without authorship =
your scientificNameWithoutAuthorship)
scientificNameAuthorship (only the authorship; no scientific name elements)

Give me a use case where one would want to use something like
scientificNameWithAuthorship in a way that couldn't be served by these three
elements.

The only one I can think of is the case where the original verbatim
name-string for the record is a mis-spelling of an autonym (and the provider
wanted to represent the mis-spelling in verbatimScientificName).  In that
case, the onus would be on the consumer to generate the correct autonym
form, with authorship after the species epithet, rather than after the
infraspecific epithet.  This seems like a rare use case to me.  There are
*plenty* of rare use cases out there that DwC does not accommodate, so I
don't see that as justification for introduction of a new term, that might
further confuse people. Moreover, it seems like a very simple algorithm for
a consumer to recognize an autonym (nomenclaturalCode=ICBN + Rank is below
species + second two components of trinomial are identical), and then format
the string accordingly from scientificName and scientificNameAuthorship.

I *STRONGLY* disagree with your suggestion to drop scientificNameAuthorship.
This is an extremely fundamental component to nomenclatural disambiguation,
and a relative "pain in the parse" for a consumer when provided only with a
full name-string-with-authorship. To me, the use cases where your suggested
scientificNameWithAuthorship cannot be easily met with a combination of
verbatimScientificName , scientificName,  and scientificNameAuthorship are
far, far, far fewer than the use cases that would benefit from receiving
content where authorship is pre-parsed from canonical name.

Aloha,
Rich

> -----Original Message-----
> From: Gregor Hagedorn [mailto:g.m.hagedorn at gmail.com]
> Sent: Thursday, December 09, 2010 10:26 AM
> To: Richard Pyle; Markus Döring; David Remsen (GBIF)
> Cc: tdwg-content at lists.tdwg.org
> Subject: Re: [tdwg-content] proposed term: dwc:verbatimScientificName
> 
> About the problem of author strings in the middle of the scientific names
in
> autonyms: Perhaps the debate is argued too much from the providers side.
> My proposal to add a scientificNameWithAuthorship is based on consumer
> use cases.
> 
> verbatimScientificName is meant to give the consumer no guarantee
> whatever on what form the name has. This is good, because it guarantees
> that a maximum of records can be served from providers having no
> guarantees themselves. However, it does not allow the consuming
> applications or services to make decisions.
> 
> I believe the majority of a consumers either need a
> scientificNameWithoutAuthorship (output policy, name-matching policy) or a
> scientificNameWithAuthorship (unambiguous name representation policy,
> name-matching policy).
> 
> The latter use case cannot be served with the modification following
> Markus's and David's proposal. This means that every service intending to
> match or display unambiguous name strings with authors needs to do
> parsing. Furthermore, providers that know that they have canonical
scientific
> names with authorship cannot transmit information about this fact.
> 
> I even doubt, whether the use cases for an isolated
> scientificNameAuthorship string are very frequent (although they certainly
> exist). I therefore propose to emend DwC with:
> 
> verbatimScientificName
> scientificNameWithoutAuthorship (which might continued to be called
> scientificName)
> scientificNameWithAuthorship
> 
> and drop the scientificNameAuthorship to reduce complexity.
> 
> Gregor




More information about the tdwg-content mailing list