[Taxacom] Data query

Stephen Thorpe stephen_thorpe at yahoo.co.nz
Tue Jun 25 20:40:16 CDT 2013


>....which means that WkiSpecies can only accommodate a single "correct" classification?  How do you handle cases where there is an active lumper v.

>splitter debate?  For example, some say it's Centropyge boylei, and some say it's Paracentropyge boylei, and there is no consensus yet.  Does WikiSpecies

>pick one and redirect from the other, or does it maintain two pages, with some sort of note concerning the ongoing debate?
 
There are a couple of options. My preferred one is just to file everything under one classification, more or less arbitrarily, say as Centropyge boylei, but redirect a page for Paracentropyge boylei to Centropyge boylei. The main thing is that all the relevant references are listed on the Centropyge boylei page, including those which refer to Paracentropyge boylei. I don't see a problem here ...


________________________________
From: Richard Pyle <deepreef at bishopmuseum.org>
To: 'Stephen Thorpe' <stephen_thorpe at yahoo.co.nz>; Tony.Rees at csiro.au; mesibov at southcom.com.au 
Cc: taxacom at mailman.nhm.ku.edu 
Sent: Wednesday, 26 June 2013 1:25 PM
Subject: RE: [Taxacom] Data query


> If further research resulted in a change to Centropyge aurantonota, 
> then someone would redirect the page for Centropyge aurantonotus 
> to a new page for Centropyge aurantonota. 

OK, good to know.  So the old link would remain, and would re-direct.

> Simple! Similarly, old combinations get redirected to new ones. 

....which means that WkiSpecies can only accommodate a single "correct"
classification?  How do you handle cases where there is an active lumper v.
splitter debate?  For example, some say it's Centropyge boylei, and some say
it's Paracentropyge boylei, and there is no consensus yet.  Does WikiSpecies
pick one and redirect from the other, or does it maintain two pages, with
some sort of note concerning the ongoing debate?

> Actually, ideally, a database would store only a genus name, 
> its gender, and the stem of the species name, and then 
> autocreate the correct suffix, but that would be tricky 
> as things are (in part because of the current Code's attempt 
> to please everyone with (hopelessly vague) "prevailing usage" 
> caveats on correct spellings) ...

Prevailing usage is not the only problem with that sort of automated gender
match.  The other problem concerns whether the species epithet was
originally used as a noun, or as an adjective.  Thus, at least one more
input parameter is needed to algorithmically derive the "gender-corrected"
spelling.

RIch


More information about the Taxacom mailing list