[tcs-lc] Next 4 days...

Paul Kirk p.kirk at cabi.org
Wed Mar 16 02:35:13 PST 2005


OK, so we differ on how we see our Codes mixing/separating taxonomy with nomenclature and I suspect this difference is based on the 'concept' we personally have behind each word we use when we speak/type. So, for example, you say 'treating a different classification as though it was really a different name' to which I would respond 'the taxonomy which resulted in the new classification under a binomial system ... required an new name (nomenclatural act)' - the second part was a consequence of, but separate from, the first part. Part 1 - Aus beus L. belongs in Xus (taxonomy); part 2 - code requires new name Xus beus (L.) P.M. Kirk (nomenclature) [Botanical]. I cannot begin to be repeat this for a Zoological situation but would be interested in what it reads like.

I think I would prefer the 'smart' (code independant) solution ... so its ready for the BioCode ;o)

Paul

-----Original Message-----
From: Richard Pyle
To: Paul Kirk; tcs-lc at ecoinformatics.org
Sent: 16/03/05 10:15
Subject: RE: [tcs-lc] Next 4 days...

> six name objects; twelve concept objects - 9 & 11 (and 10 & 12)
> are not names in Botanical Nomenclature. 13-16 are not names
> but concepts (taxonomic opinions), assuming the string in
> parentheses represents an infrageneric (supraspecific) epithet.

Yes, I meant the parenthetical to be an infrageneric name (e.g.,
subgenus).

> Yes, we should settle the question of what constitutes a name
> but it will have to be Code specific because of the way the
> ICZN mixes (IMHO) too much taxonomy with its nomenclature ;-)

Funny -- because from my perspective, ICBN mixes too much taxonomy with
its
nomenclature (i.e., treating a different classification as though it was
really a different name!) :-)

We certainly could do it in a Code-dependant way, but actually I don't
think
we necessarily have to be Code specific.  We could do it the zoological
way,
and very easily produce name-strings with appropriate botanical
authorships
(provided we have elements for Combination Author -- which LC does).
Or, we
could also do it the botanical way, and just treat zoological names the
same
way as if the combinations were different "names".

Or, we could do what is probably the smartest solution and treat each
unique
combination of
Monomial/GenusName[+SpeciesEpithet[+InfreaSpecificEpithet]]
(where bracketed elements are optional) as a distinct name-unit
(assuming
that each of the three subunits is thought of as a protonym reference,
rather than as an orthographic string of characters).

But the important thing is that we all agree on how to define a "Name",
and
design the schema accordingly.

Rich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/tcs-lc/attachments/20050316/3a837aeb/attachment.htm


More information about the Tcs-lc mailing list