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

[Tony.Rees at csiro.au]

Quoting Rich Pyle:

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

Maybe an answer would be to use TCS not DwC for exchange of purely taxonomic data? How about creating a TCSA format for bulk transfer - or is this not a great thought... (not being that familiar with TCS)

One problem is that (e.g.) it is often desired to include some non-taxonomic information along with the names e.g. distribution/habitat codes, etc.

Just an idea, don't know if it solves the residual DwC issues anyway,

Cheers - Tony
 

> -----Original Message-----
> From: Richard Pyle [mailto:deepreef at bishopmuseum.org]
> Sent: Thursday, 25 November 2010 11:56 AM
> To: 'Markus Döring'
> Cc: Rees, Tony (CMAR, Hobart); Chuck.Miller at mobot.org; tdwg-
> content at lists.tdwg.org; dmozzherin at eol.org
> Subject: RE: [tdwg-content] [tdwg-tag] Inclusion of authorship in
> DwCscientificName: good or bad?
> 
> > > 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
>