[Taxacom] FW: formation of zoological names with Mc, Mac, et

Thu Sep 3 02:41:39 CDT 2009

>Keep it simple - only do what's needed to achieve your aims
Agreed, except that different end users have different aims, and certain taxonomic conventions, and the Code, also need to be upheld

>Atomize each separate data element
Yes and no! It may be difficult to recognise data elements properly. To take my hypothetical example once again:

Examplus primus Smith, 1970

If I understand you correctly, you would go for something like this:

Genus: Examplus
Species: primus
Species authority: A.B. Smith, jr. (born January 1, 1950 in Utopia, Lalaland)
Publication date: October 20, 1970

All of this is well and good, except that it completely overlooks THE MOST IMPORTANT data element to my mind, namely:

Name: Examplus primus Smith, 1970

This is a single data element representing the way that the Code prescribes the citation of the (full) name! Note also that the above split fields way of doing it doesn't even indicate that we are using binomial nomenclature, i.e. the generic epithet isn't JUST the genus to which the species is assigned, it is ALSO the first part of the binomial name! Similarly, the author/date isn't JUST the person who named it and when, but is ALSO the end bit of the "namestring"!

Stephen

________________________________________
From: Paul Kirk [p.kirk at cabi.org]
Sent: Thursday, 3 September 2009 7:27 p.m.
To: Tony.Rees at csiro.au; Stephen Thorpe; jim.croft at gmail.com
Cc: taxacom at mailman.nhm.ku.edu
Subject: RE: [Taxacom] FW: formation of zoological names with Mc, Mac, et

I think Dawin Core is a data exchange format rather than a database
schema format ... ;-)

I'm no database expert but I do have some experience and this has taught
me, amongst other things to:

Keep it simple - only do what's needed to achieve your aims.
Atomize each separate data element.
Normalize till it hurts then denormalize till it works.
If it still dont work fast enough put in some 'cached' fields (e.g.
(botanically) make a binomial from the atomized generic name and
specific epithet) to speed up searching.
If you are a subset of some larger database add some links to that
database to benefit from collaboration. If you have their primary key(s)
as a foreign key in your database even a CSV download now and again can
fill in some of your gaps and allow you to assess whether their updates
to e.g. orthography should be accepted.

In haste,

Paul

-----Original Message-----
From: taxacom-bounces at mailman.nhm.ku.edu
[mailto:taxacom-bounces at mailman.nhm.ku.edu] On Behalf Of
Tony.Rees at csiro.au
Sent: 03 September 2009 08:14
To: s.thorpe at auckland.ac.nz; jim.croft at gmail.com
Cc: taxacom at mailman.nhm.ku.edu
Subject: Re: [Taxacom] FW: formation of zoological names with Mc, Mac,
et

Hi Steve,

Well I *thought* Darwin Core had separate fields for scientific name
("scientificname") and author, however it appears I am wrong and the
intention is to hold a "namestring", see
http://wiki.tdwg.org/twiki/bin/view/DarwinCore/ScientificName

However the OBIS implementation of Darwin Core, with which I have spent
most of my experience over the past x years, *does* have separate fields
for "scientificname" and "scientificnameauthor", see
http://www.iobis.org/tech/provider/implementation/, which is what I was
(perhaps foolishly) expecting in the master Darwin Core spec, since it
is notionally an extension of DC - anyone from TDWG care to comment?

- Tony

-----Original Message-----
From: Stephen Thorpe [mailto:s.thorpe at auckland.ac.nz]
Sent: Thursday, 3 September 2009 5:06 PM
To: Rees, Tony (CMAR, Hobart); jim.croft at gmail.com
Cc: taxacom at mailman.nhm.ku.edu
Subject: RE: [Taxacom] FW: formation of zoological names with Mc, Mac,
et

Tony, Jim, list,

I am getting a little confused if you guys are agreeing or disagreeing
with me!
I am saying that EFFECTIVELY, the authority/date is part of the name,
albeit an optional part, despite the Code claiming that it isn't, but at
the same time treating it as if it is! The Code can only prescribe
things about names, NOT about auxiliary information. The Code prescribes
what the authority/date of a name is, so these things are part of the
name, albeit optional. Most databases/publications in the world today
would have a single field called 'Name', which would look like this:

Name: Examplus primus Smith, 1970

NOT like this:

Name: Examplus primus
Authority: Smith
Date: 1970

At least in entomology, when you put a determination label on a
specimen, you typically include authority date as part of the
identification (=as part of the name).

OK, so we could play "semantic revisionism" and redefine name as
"namestring", and say that the Code prescribes things about namestrings,
but why bother?

One thing to be clear about is that I am certainly NOT in favour of only
citing e.g. Examplus primus, and leaving out the authority/date! What I
AM saying is that we should NOT write things like Examplus primus A.B.
Smith, jr., October 20, 1970. Instead, if we really want to know
auxiliary info., then we should structure a database more like this:

Name: Examplus primus Smith, 1970
Authority: A.B. Smith, jr. (born: January 1, 1900, in Utopia, Lalaland)
Publication date: October 20, 1970

Cheers,

Stephen

________________________________________
From: Tony.Rees at csiro.au [Tony.Rees at csiro.au]
Sent: Thursday, 3 September 2009 6:38 p.m.
To: jim.croft at gmail.com; Stephen Thorpe
Cc: taxacom at mailman.nhm.ku.edu
Subject: RE: [Taxacom] FW: formation of zoological names with Mc, Mac,
et

Jim, all,

Well we are just talking semantics here - Stephen says the authority is
part of the name (which I agree it is not), you say the authority as a
qualifier to the name is generally redundant (which I disagree with).
David Remsen and GNA folk call the name and subsequent authority (and
possibly other qualifier) information the "namestring", I term I don't
really love but will use in this context...

To see why namestrings are more useful than names is not hard, e.g. take
a look at any official nomenclatural stuff (ICZN in this instance), e.g.

http://www.iczn.org/BZNJun2009opinions.html

You will, I hope, see the liberal use of "namestrings" rather than just
"names". ICZN certainly need to use these, and others to see them, for
all the reasons recently expounded as a part of this thread, for as long
as ambiguities or potential persist (which may be some time...)

Now, I would never put all of these elements in a single name field in
my database, since I do not have such a thing, however I certainly have
genus, species, authority (or author and date in separate fields) and
can perm them to reconstruct namestrings as needed. Actually I would be
surprised if you did not do the same?? This is quite different of course
from primary keys, which in my usage and many others', has nothing to do
with these name elements, for reasons previously discussed.

Regards - Tony

-----Original Message-----
From: taxacom-bounces at mailman.nhm.ku.edu
[mailto:taxacom-bounces at mailman.nhm.ku.edu] On Behalf Of Jim Croft
Sent: Thursday, 3 September 2009 4:15 PM
To: Stephen Thorpe
Cc: taxacom at mailman.nhm.ku.edu
Subject: Re: [Taxacom] FW: formation of zoological names with Mc, Mac,
et

I am Jim Croft (aka James Reginald Croft, aka Kim Croft to his family,
aka all maner of unpublishable appellations to his staff and
colleagues).  The one born in Toorak Melbourne Australia on 28 May 1951.
The bureaucrat botanist, not the hellfire and brimstone Baptist
minister, not the peace out hippie bookbinder.

My name is not "Jim Croft (Toorak) 1951" - although it could be argued
the implied information content is a little bit less ambiguous

When it comes to names, plants and animals are no different... If you
need to other information to sort out the use of the name, store and
manage that information.  But don't glue it to the name.  Because you
will never have enough and the end result will be unusable and
unenforceable.

I have had numerous arguments about this at the ANBG, saying that the
use of author names on labels and other materials in the Gardens is a
waste of time and space.  Other than a pathetically pretentious attempt
to look scientific it serves no useful purpose.  The only people who
need to invoke this information are nomenclaturalists when they need to
sort out which name to apply to which taxon.  Once that is done and
documented, no-one needs to see it.  Especially not the public.

jim

On Thu, Sep 3, 2009 at 8:25 AM, Stephen Thorpe<s.thorpe at auckland.ac.nz>
wrote:
> Note that the author/date are in the name field (as they are in any
sensible taxonomic database), implying that they are part of the name in
some meaningful sense, despite an overly pedantic interpretation of the
Code denying this! I guess one of the many inconsistencies in the Code
is that it says author/date isn't part of the name, but then treats it
as part of the name in many contexts...

--
_________________
Jim Croft ~ jim.croft at gmail.com ~ +61-2-62509499 ~
http://www.google.com/profiles/jim.croft
... in pursuit of the meaning of leaf ...
... 'All is leaf' ('Alles ist Blatt') - Goethe

_______________________________________________

_______________________________________________

Taxacom Mailing List
Taxacom at mailman.nhm.ku.edu
http://mailman.nhm.ku.edu/mailman/listinfo/taxacom

The Taxacom archive going back to 1992 may be searched with either of
these methods:

(1) http://taxacom.markmail.org

Or (2) a Google search specified as:
site:mailman.nhm.ku.edu/pipermail/taxacom  your search terms here

Find out about CABI's global summit on 'Food security in a climate of change' at www.cabiglobalsummit.com
19 - 21 October 2009, London, UK.

************************************************************************
The information contained in this e-mail and any files transmitted with it is confidential and is for the exclusive use of the intended recipient. If you are not the intended recipient please note that any distribution, copying or use of this communication or the information in it is prohibited.

Whilst CAB International trading as CABI takes steps to prevent the transmission of viruses via e-mail, we cannot guarantee that any e-mail or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions.

If you have received this communication in error, please notify us by e-mail at cabi at cabi.org or by telephone on +44 (0)1491 829199 and then delete the e-mail and any copies of it.

CABI is an International Organization recognised by the UK Government under Statutory Instrument 1982 No. 1071.

**************************************************************************