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

Tue Sep 8 18:29:38 CDT 2009

Yes, yes, yes, yes. yes:  Richard, your answer strikes me as right on target.

As to how things got represented in the database I last built... in
retrospect, it's a bit quaint. And a good illustration of why some
experience and some expertise are needed in these things.

I began with the project goal of using the database to build a paper
publication (genus list) accompanied by a full bibliographic record
for each name-stringy-thingy.

With what I now fully understand was an amusingly naive approach, I
planned to generate the final document by using the EndNote
bibliographic reference system to plug in the author/year parts of the
namestrings based on links to the references. (The references
originate in yet another database [not EndNote], but that's a whole
other story.)

It will come as no surprise that, while that scheme worked for many
(actually most) of the genera, it served as an excellent education
tool on how curiously screwy those name-string-things can actually be.

And, as in this dicussion in this mailing list, each of the many
participants in the project was quite sure what the rules were and
what the formats should be. And, like the discussion in this mailing
list, no two of us agreed.

Which leads to the related topic of just what the various parts of the
namestring are for and why they should be there. There is so much
disagreement on this (legitimate, I think -- many different purposes
are served in different instances), that I'm strongly in favor of
atomizing the hell out of this information. Users are then free to
create the namestring they need. That doesn't address digesting
existing data. But for holding and promulgating data, the smaller the
bits, the better the product.

-Dean
-- 
Dean Pentcheff
pentcheff at gmail.com

On Sat, Sep 5, 2009 at 1:28 AM, Richard Pyle<deepreef at bishopmuseum.org> wrote:
>
> No, in a database it would be most sensible to have something like this:
>
> TaxonNameUsageID: 62D43041-06BE-45A3-8D6B-D3853F0B3121
> ProtonymID: 62D43041-06BE-45A3-8D6B-D3853F0B3121
> ReferenceID: 13798543-078E-4B8E-B176-52DF4D0173EB
> TaxonRank: Genus
> NameElement: Goneplax
> [Plus a few other fields...]
>
> The fact that TaxonNameUsageID=ProtonymID tells us that this record
> represents the original creation event for this genus name.
>
> The ReferenceID would resolve to the full bibliographic citation for Leach,
> 1814.  Part of the metadata in the resolved Reference would be a
> ParentReferenceID, which might look something like this:
> 42E69941-A574-4E4E-901E-14EAC95F3CF4. Resolving the ParentReferenceID would
> give us the full bibliographic citation for Leach, 1813-1815.
>
> Oh, and before anyone starts qivering with fear about those ID values that
> look sooooo scary; keep in mind that the only thing a human would likely see
> is something along the lines of:
>
> "Goneplax Leach, 1814 [in Leach, 1813-1815]"
>
> Or
>
> "Goneplax Leach 1814 [in Leach, 1813-1815]"
>
> Or
>
> "Goneplax Leach [in Leach]"
>
> Or....whatever the personal preference of the end-user is for formatting
> such things.
>
> The database doesn't care how its data are formatted for a human -- that's
> something only humans care about.  What the database cares about is that
> nothing else on the planet uses any of the 3 identifiers listed above
> (62D43041-06BE-45A3-8D6B-D3853F0B3121; 13798543-078E-4B8E-B176-52DF4D0173EB;
> 42E69941-A574-4E4E-901E-14EAC95F3CF4), and that these identifiers always
> resolve to the same "thing". And, of course, the database cares about how to
> resolve these identifiers, and that the resolution service returns a result
> that it understands.  In the example given, the assumption is that the
> database resolves these identifiers internally, against its own data tables.
> If it needed to resolve the identifiers from an external application or
> service, then the identifiers would need to be wrapped in an appropriate
> resolution prefix -- like a URL, or an LSID, or a DOI.
>
> Oh, and when the human sees the name + authors in the preferred format, each
> component would likely be a hyperlink to the associated full metadata.
>
> Speaking as a (gradually) reformed
> taxonomist-who-designs-databases-like-a-taxonomist-would-design-a-database,
> I can say that as a general rule, taxonomists who design databases like a
> taxonomist would design a database (myself included) are lousy database
> designers.
>
> Aloha,
> Rich
>
> P.S. the example above is actually dumbed down a bit. Besides the missing
> fields (most of which are equally obtuse identifiers), the "TaxonRank" would
> most likely be "TaxonRankID", and would (most likely) be another identifier
> that resolves to a pre-defined taxonomic rank.
>
>
>> -----Original Message-----
>> From: taxacom-bounces at mailman.nhm.ku.edu
>> [mailto:taxacom-bounces at mailman.nhm.ku.edu] On Behalf Of
>> Stephen Thorpe
>> Sent: Friday, September 04, 2009 6:32 PM
>> To: fwelter at gwdg.de; taxacom at mailman.nhm.ku.edu
>> Subject: Re: [Taxacom] FW: formation of zoological names with
>> Mc, Mac, et
>>
>> But in a database, it would be most sensible to have it like this:
>> Name: Goneplax Leach, 1814
>> Original publication: Leach (1813-1815)
>>
>> ________________________________________
>> From: taxacom-bounces at mailman.nhm.ku.edu
>> [taxacom-bounces at mailman.nhm.ku.edu] On Behalf Of Francisco
>> Welter-Schultes [fwelter at gwdg.de]
>> Sent: Saturday, 5 September 2009 5:21 p.m.
>> To: taxacom at mailman.nhm.ku.edu
>> Subject: Re: [Taxacom] FW: formation of zoological names with
>> Mc, Mac, et
>>
>> > Goneplax Leach, 1814 [in Leach, 1813-1815]
>>
>> The name of the genus is Goneplax Leach, 1814, but if there
>> is a divergence between nomenclaturally and bibliographically
>> relevant years, I also would recommend to cite a name in a
>> way Dean proposed here. Or if there is a divergence between
>> authors (Boettger, 1909 in Wohlberedt 1909). This is often
>> done, and can be very helpful to find the original source,
>> especially in rarely cited names. It is not ruled so by the
>> Code, but makes much sense. If there was a movment in the
>> community to incorporate this into the ICZN Code, I would be
>> in favour of this idea.
>> I would not use a comma between author and year in a
>> bibliographical citation.
>>
>> Francisco
>>
>>
>> University of Goettingen, Germany
>> www.animalbase.org
>>
>> _______________________________________________
>>
>> 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 _______________________________________________
>>
>> 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
>
>
>
> _______________________________________________
>
> 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
>