[tdwg-content] [tdwg-tag] Inclusion of authorship in DwCscientificName: good or bad?

[Richard Pyle]

> > verbatimScientificName
> > As I suggested in an earlier post, this would be "the complete set of
> > textual elements useful for recognizing a unique scientific name",
> > exactly as they appear in the original source.
> yes for the definition, but Im not sure if removing scientificName from
the
> dwc terms is a true option though.
> Its the most known term of all...

Yes, I know and agree. I figured I'd take a stab at the "ideal" world first,
then curb back to reality...  :-)

The problem is, scientificName as it currently is defined is not exactly the
same thing as verbatimScientificName.  The problem with scientificName is
both its curse and its blessing.  The liberal definition makes it very easy
to accommodate from the perspective of the provider; but this same liberal
definition *can* make it difficult for many clients.  Many people do use it
as a "verbatim" representation of a string blob in their database.  Others
generate "clean" concatenated name-string values from their parsed
databases.  Many, as Tony pointed out, do not include Authorship, even
though they have Authorship information (as represented in
scientificNameAuthorship).  One golden rule of data management that I often
tell people is that it's often better to be consistent, then correct.  That
is, something that's consistently incorrect can be corrected easily.  But
something that is inconsistently correct is often harder to deal with.  In
the case of scientificName, different people have different ideas of what
"should be", but I think the only "correct" answer is the one described in
the term definition.

> > uninomialNameElement
> > Used for all names at the rank of genus and above; would also replace
> > "genus" in DwC.
> Genus will still be needed to represent the denormalised classification,
but
> not for the parsed bits.

Right -- you mean in the sense of Family, Order, Class, etc.  Personally, I
think it would be "ideal" to eliminate these individual fields and just use
dwc: higherClassification for this purpose.  People with normalised data can
represent it properly via parentNameUsage[ID] -- with the understanding that
all names with a rank lower than genus would include the genus name as
uninomial.

There's no elegant solution to this, as far as I can tell.

> > infragenericNameElement
> > Better term for "subgenus".
> Probably same is true for subgenus

I was just suggesting a better label for subgenus, so in this case it would
mean exactly the same thing as subgenus does, just spelled differently.  The
reason the more general term is better than the rank-specific "subgenus" is
to accommodate infrageneric Sections as well. Of course, we're screwed in
the case where both a subgenus *and* a section are provide; but in that case
I would be inclined to rely on a verbatim string to capture that.

At this point, though, I really don't have a good sense for how best to
proceed.

Aloha,
Rich