University of Glasgow

Roderic Page

![Bob
mesibov](https://lh3.googleusercontent.com/-dGuQKhH1gu0/V-5oJIf564I/AAAAAAAAESQ/0lVote3X0pk/bob_mesibov.jpg?imgmax=1600 "bob_mesibov.jpg"){border="0"
width="100" height="100" style="float:right;"} The following is a guest
post by [Bob Mesibov](http://www.polydesmida.info/mesibov.html).

Do you know the party game \"Telephone\", also known as \"Chinese
Whispers\"? The first player whispers a message in the ear of the next
player, who passes the message in the same way to a third player, and so
on. When the last player has heard the whispered message, the starting
and finishing versions of the message are spoken out loud. The two
versions are rarely the same. Information is usually lost, added or
modified as the message is passed from player to player, and the changes
are often pretty funny.

I recently compared ca 100 000 beetle records as they appear in the
[Museums Victoria (NMV)](http://museumvictoria.com.au) database and in
DarwinCore downloads from the [Atlas of Living Australia
(ALA)](https://www.ala.org.au) and the [Global Biodiversity Information
Facility (GBIF)](https://www.gbif.org). NMV has its records aggregated
by ALA, and ALA passes its records to GBIF. The \"Telephone\" effect in
the NMV to ALA to GBIF comparison was large and not particularly funny.

Many of the data changes occur in beetle names. ALA checks the
NMV-supplied names against a look-up table called the National Species
List, which in this case derives from the Australian Faunal Directory
(AFD). If no match is found, ALA generalises the record to the next
higher supplied taxon, which it also checks against the AFD. ALA also
replaces supplied names if they are synonyms of an accepted name in the
AFD.

GBIF does the same in turn with the names it gets from ALA. I\'m not
100% sure what GBIF uses as beetle look-up table or tables, but in many
other cases their GBIF Backbone Taxonomy mirrors the Catalogue of Life.

To give you some idea of the magnitude of the changes, of ca 85000 NMV
records supplied with a genus+species combination, about one in five
finished up in GBIF with a different combination. The \"taxonRank\"
changes are summarised in the overview below, and note that replacement
ALA and GBIF taxon names at the same rank are often different:

![Generalised](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhm86HNtpVNXs2o5u_YV__Wxvh2n1aA90Px8kxxHviV7XS_yZbgKxR68RPtmKsTcl_Nq5BLuZNPupYDQP5dyl2PQyCY9cSe-A3mATS6ubId65XWEKpnode7OpMbddNBzTLRvIyP/?imgmax=1600 "generalised.png"){style="display:block; margin-left:auto; margin-right:auto;"
border="0" width="405" height="600"}

Of the species that escaped generalisation to a higher taxon, there are
42 names with genus triples: three different genus names for the same
taxon in NMV, ALA and GBIF.

Just one example: a paratype of the staphylinid *Schaufussia mona*
Wilson, 1926 is held in NMV. The record is listed under *Rytus howittii*
(King, 1866) in the ALA Darwin Core download, because AFD lists
*Schaufussia mona* as a junior subjective synonym of *Tyrus howitti*
King, 1866, and *Tyrus howittii* in AFD is in turn listed as a synonym
of *Rytus howittii* (King, 1866). The record appears in GBIF under
*Tyraphus howitti* (King, 1865), with *Rytus howittii* (King, 1866)
listed as a synonym. In AFD, *Rytus howittii* is in the tribe Tyrini,
while *Tyraphus howitti* is a different species in the tribe Pselaphini.

ALA gives \"typeStatus\" as \"paratype\" for this record, but the
specimen is not a paratype of *Rytus howittii*. In the GBIF download,
the \"typeStatus\" field is blank for all records. I understand this may
change in future. If it does, I hope the specimen doesn\'t become a
paratype of *Tyraphus howitti* through copying from ALA.

There are lots of \"Telephone\" changes in non-taxonomic fields as well,
including some geographical howlers. ALA says that a Kakadu National
Park record is from Zambia and another Northern Territory record is from
Mozambique, because ALA trusts the incorrect longitude provided by NMV
more than it does the NMV-supplied locality text. GBIF blanks this
locality text field, leaving the GBIF user with two African records for
Australian specimens and no internal contradictions.

ALA trusts latitude/longitude to the extent of changing the
\"stateProvince\" field for localities near Australian State borders, if
a low-precision latitude/longitude places the occurrence a short
distance away in an adjoining State.

Manglings are particularly numerous in the \"recordedBy\" field, where
name strings are reformatted, not always successfully. Complex NMV
strings suffer worst, e.g. \"C Oke; Charles John Gabriel\" in NMV
becomes \"Oke, C.\|null\" in ALA, and \"Ms Deb Malseed - Winda-Mara
Aboriginal Corporation WMAC; Ms Simone Sailor - Winda-Mara Aboriginal
Corporation WMAC\" is reformatted as in ALA \"null\|null\|null\|null\"

Most of the \"Telephone\" effect in the NMV-ALA-GBIF comparison appears
in the NMV-ALA stage. I contacted ALA by email and posted some of the
issues on the ALA GitHub site; I haven\'t had a response and the issues
are still open. I also contacted Tim Robertson at GBIF, who tells me
that GBIF is working on the ALA-GBIF stage.

Can you get data as originally supplied by NMV to ALA, through ALA?
Well, that\'s easy enough record-by-record on the ALA website, but not
so easy (or not possible) for a multi-record download. Same with GBIF,
but in this case the \"original\" data are the ALA versions.


The following is a guest post by Bob Mesibov. Do you know the party game "Telephone", also known as "Chinese Whispers"? The first player whispers a message in the ear of the next player, who passes the message in the same way to a third player, and so on. When the last player has heard the whispered message, the starting and finishing versions of the message are spoken out loud. The two versions are rarely the same.

Guest post: Our taxonomy is not your taxonomy

![Bob
mesibov](https://lh3.googleusercontent.com/-dGuQKhH1gu0/V-5oJIf564I/AAAAAAAAESQ/0lVote3X0pk/bob_mesibov.jpg?imgmax=1600 "bob_mesibov.jpg"){border="0"
width="100" height="100" style="float:right;"} The following is a guest
post by [Bob Mesibov](http://www.polydesmida.info/mesibov.html).

According to
[w3techs](https://w3techs.com/technologies/overview/character_encoding/all),
seven out of every eight websites in the Alexa top 10 million are UTF-8
encoded. This is good news for us screenscrapers, because it means that
when we scrape data into a UTF-8 encoded document, the chances are good
that all the characters will be correctly encoded and displayed.

It\'s not quite good news for two reasons.

In the first place, one out of eight websites is encoded with some
feeble default like ISO-8859-1, which [supports even fewer characters
than the closely related
windows-1252](http://www.i18nqa.com/debug/table-iso8859-1-vs-windows-1252.html).
Those sites will lose some widely-used punctuation when read as UTF-8,
unless the webpage has been carefully composed with the HTML equivalents
of those characters. You\'re usually safe (but see below) with big
online sources like Atlas of Living Australia (ALA), APNI, CoL, EoL,
GBIF, IPNI, IRMNG, NCBI Taxonomy, The Plant List and WoRMS, because
these declare a UTF-8 charset in a meta tag in webpage heads. (IPNI\'s
home page is actually in ISO-8859-1, but its search results are served
as UTF-8 encoded XML.)

But a second problem is that just because a webpage declares itself to
be UTF-8, that doesn\'t mean every character on the page sings from the
Unicode songbook. Very odd characters may have been pulled from a
database and written onto the page as-is. In ALA I recently found an
ancient rune --- the High Octet Preset control character (HOP, hex 81):

<http://biocache.ala.org.au/occurrences/6191ca90-873b-44f8-848d-befc29ad7513>
<http://biocache.ala.org.au/occurrences/5077df1f-b70a-465b-b22b-c8587a9fb626>

HOP replaces ü on these pages and is invisible in your browser, but a
screenscrape will capture the HOP and put
Sch[HOP]{style="color:white;background-color:black;\""}rhoff in your
UTF-8 document.

Another example of ALA\'s fidelity to its sources is its coding of the
degree symbol, which is a single-byte character (hex b0) in
windows-1252, e.g. in Excel spreadsheets, but a two-byte character (hex
c2 b0) in Unicode. In this record, for example:

<http://biocache.ala.org.au/occurrences/5e3a2e05-1e80-4e1c-9394-ed6b37441b20>

the lat/lon was supplied (says ALA) as 37Â°56\'9.10\"S 145Â°
0\'43.74\"E. Or was it? The lat/lon could have started out as
37°56\'9.10\"S 145°0\'43.74\"E in UTF-8. Somewhere along the line the
lat/lon was converted to windows-1252 and the Â° characters were
generated, resulting in geospatial gibberish.

When a program fails to understand a character\'s encoding, it usually
replaces the mystery character with a **?**. A question mark is a
perfectly valid character in commonly used encodings, which means the
interpretation failure gets propagated through all future re-uses of the
text, both on the Web and in data dumps. For example,

<http://biocache.ala.org.au/occurrences/dfbbc42d-a422-47a2-9c1d-3d8e137687e4>

gives *N?crophores* for *Nécrophores*. The history of that particular
character failure has been lost downstream, as is the case for myriads
of other question marks in online biodiversity data.

In my experience, the situation is much worse in data dumps from online
sources. It\'s a challenge to find a dump *without* question marks
acting as replacement characters. Many of these question marks appear in
author and place names. Taxonomists with eastern European names seem to
fare particularly badly, sometimes with more than one character variant
appearing in the same record, as in the Australian Faunal Directory
(AFD) offering of Wêgrzynowicz, W?grzynowicz and Węgrzynowicz for the
same coleopterist. Question marks also frequently replace punctuation,
such as n-dashes, smart quotes and apostrophes (e.g. O?Brien (CoL) and
L?Échange and d?Urville (AFD)).

Character encoding issues create major headaches for data users. It
would be a great service to biodiversity informatics if data managers
compiled their data in UTF-8 encoding or took the time to convert to
UTF-8 and fix any resulting errors before publishing to the Web or
uploading to aggregators.

This may be a big ask, given that at least one data manager I\'ve talked
to *had no idea* how characters were encoded in the institution\'s
database. But as ALA\'s Miles Nicholls
[wrote](http://www.ala.org.au/blogs-news/sharing-data-through-the-atlas/)
back in 2009, \"Note that data should always be shared using UTF-8 as
the character encoding\". Biodiversity informatics is a global
discipline and UTF-8 is the global standard for encoding.

Readers needing some background on character encoding will find
[this](https://www.w3.org/International/questions/qa-what-is-encoding)
and especially [this](http://kunststube.net/encoding/) helpful, and a
very useful tool to check for encoding problems in small blocks of text
is [here](http://string-functions.com/encodedecode.aspx).


The following is a guest post by Bob Mesibov. According to w3techs, seven out of every eight websites in the Alexa top 10 million are UTF-8 encoded. This is good news for us screenscrapers, because it means that when we scrape data into a UTF-8 encoded document, the chances are good that all the characters will be correctly encoded and displayed. It's not quite good news for two reasons.

Guest post: It's 2016 and your data aren't UTF-8 encoded?

The follow is a guest post by [Bob
Mesibov](http://www.qvmag.tas.gov.au/qvmag/?c=153), who has [contributed
to iPhylo before](search?q=bob+mesibov).
![Bob](http://lh4.ggpht.com/-GuEIp2E_0Ns/T_6s1sVLk3I/AAAAAAAABh0/lr7VS0hnXoY/bob.jpg?imgmax=800 "bob.jpg"){border="0"
width="113" height="146" style="float:right;"}

Like many iPhylo readers, I deal with large, pre-existing compilations
of biodiversity data. The compilations come from museums, herbaria,
aggregation projects and government agencies. For simplicity in what
follows and to avoid naming names, I\'ll lump all these sources into a
single fictional entity, the PAI (for Projects, Agencies and
Institutions).

The datasets I get from the PAI typically contain duplicate records,
inconsistencies in content and format, unexplained data gaps, data in
wrong fields, fields improperly used, no flagging of doubtful data, etc.
Data cleaning consumes most of the time I spend on a data project.
Cleaning can take weeks, analysing the cleaned data takes minutes,
reporting the results of the analysis takes hours or days. (Example:
[doi:10.3897/BDJ.2.e1160](http://dx.doi.org/10.3897/BDJ.2.e1160))

I can understand how datasets get messy. Data entry errors account for a
lot of the problems I see, and I make data entry errors myself. But the
causes of messiness are one thing and its cure is another. The
custodians of those data compilations don\'t seem to have done much (or
any) data checking. Why not?

When I\'m brave enough to ask that question, I usually get a polite
response from the PAI. Here are 10 explanations I\'ve heard for
inadequate data checking and cleaning:

**(1) The data are fit for use, as-is.** No cleaning is needed, because
the data are fit for *some* use, and the PAI is satisfied with that. One
data manager wrote to me in an email: \'\...even records with lower
certainty, in this case an uncertain identification, can be useful at a
coarser resolution. Although we have no idea as to the reliability of
the identification to the species or even genus they are likely
correctly identify\[ing\] something as at least an animal, arthropod and
possibly to class so the record is suitable for analysis at that
level.\'

**(2) The PAI is exposing its data online. The crowd will spot any
problems and tell the PAI about them.**

I\'ve previously pointed out
([doiL10.3897/zookeys.293.5111](http://dx.doi.org/10.3897/zookeys.293.5111))
how lame this explanation is. As a strategy for data cleaning it\'s
slow, piecemeal and wildly optimistic. At best, it accumulates
data-cleaning \'tickets\' with no guarantee that any will ever be
closed. What I hear from the PAI is \'We\'re aware of problems of that
kind and are hoping to find a general solution, rather than deal with a
multitude of individual cases\'. Years pass and the individual cases
don\'t get fixed, so interested members of the crowd lose faith in the
process and stop reporting problems.

**(3) No one outside the PAI is allowed to look at the whole dataset,
and no one inside the PAI has the time (or skills) to do data checking
and cleaning.**

This is a particularly nice Catch-22. I once offered to check a portion
of the PAI\'s data holdings for free, and was told that PAI policy was
that the dataset was not to be shared with anyone outside the PAI. The
same data were freely available on the PAI\'s website in bits and pieces
through a database search page.

**(4) The PAI is migrating to new database software next year. Data
cleaning will be part of the migration.**

No, it won\'t. Note that this response isn\'t always simple
procrastination, because it\'s sometimes the case that the PAI\'s
database has only limited capabilities for data checking and editing.
PAI staff are hopeful that checking and editing will be easier with the
new software. They\'ll be disappointed.

**(5) The person who manages data is on leave / was seconded to another
project / resigned and hasn\'t been replaced yet / etc.**

This is another way of saying that no one inside the PAI has the time to
do data checking and cleaning. When the data manager returns to work or
gets replaced, data checking and cleaning will have the same low
priority it had before. That\'s why it didn\'t get done.

**(6) Top management says any data cleaning would have to be done by
outside specialists, but there\'s not enough money in the current budget
to hire such people.**

Not only a Catch-22, but a solid, long-term excuse, applicable in any
financial year. It would cost less to train PAI staff to do the job
in-house.

**(7) The PAI would prefer to use a specialist data tool to clean data,
like [OpenRefine](http://openrefine.org/), but hasn\'t yet got up to
speed on its use.**

The PAI believes in magic. OpenRefine will magically clean the data
without any thought required on the part of PAI staff. The magic will
have to be applied repeatedly, because the sources of the duplications,
gaps and errors haven\'t been found and squashed.

**(8) The PAI staff best qualified to check and clean the data aren\'t
allowed to do so.**

IT policy strictly forbids anyone but IT staff from tinkering with the
PAI database, whose integrity is sacrosanct. A very specific request
from biodiversity staff may be ticketed by IT staff for action, but
global checking and editing is out of the question. IT staff are not
expected to understand biodiversity studies, and biodiversity staff are
not expected to understand databases.

This explanation is interesting because it implies a workaround. If a
biodiversity staffer can get a dump from the database as a simple text
file, she can do global checking and editing of the data using the
command line or a spreadsheet. The cleaned data can then be passed to IT
staff for incorporation into the database as replacement data items. The
day that happens, pigs will be seen flying outside the PAI windows.

**(9) The PAI datasets have grown so big that global data checking and
editing is no longer possible.**

Harder, yes; impossible, no. And the datasets didn\'t suddenly appear,
they grew by accretion. Why wasn\'t data checking and editing done as
data was added?

**(10) All datasets are messy and data users should do their own data
cleaning.**

The PAI shrugs its shoulders and says \'That\'s just the way it is, live
with it. Our data are no messier than anyone else\'s\'.

I\'ve left this explanation for last because it begs the question. Yes,
users can do their own data cleaning --- because it\'s not that hard and
there are many ways to do it. So why isn\'t it done by highly qualified,
well-paid PAI data managers?


The follow is a guest post by Bob Mesibov, who has contributed to iPhylo before. Like many iPhylo readers, I deal with large, pre-existing compilations of biodiversity data. The compilations come from museums, herbaria, aggregation projects and government agencies.

Guest post: 10 explanations for messy data, by Bob Mesibov

The following is a guest post by [Bob
Mesibov](http://www.qvmag.tas.gov.au/qvmag/?c=153).
![Bob](http://lh4.ggpht.com/-GuEIp2E_0Ns/T_6s1sVLk3I/AAAAAAAABh0/lr7VS0hnXoY/bob.jpg?imgmax=800 "bob.jpg"){border="0"
width="113" height="146" style="float:right;"}  
  
The i4Life project has very kindly liberated Catalogue of Life (CoL)
data from its database, and you can now download the latest CoL as a set
of plain text, tab-separated tables
[here](http://www.catalogueoflife.org/DCA_Export/).  
  
One of the first things I did with my download was check the
\'taxa.txt\' table for species name popularity\*. Here they are, the top
10 species names for animals and plants, with their frequencies in the
CoL list and their usual meanings:  
  

#### Animals

  
2732 *gracilis* = slender  
2373 *elegans* = elegant  
2231 *bicolor* = two-coloured  
2066 *similis* = similar  
1995 *affinis* = near  
1937 *australis* = southern  
1740 *minor* = lesser  
1718 *orientalis* = eastern  
1708 *simplex* = simple  
1350 *unicolor* = one-coloured

#### Plants

  
1871 *gracilis* = slender  
1545 *angustifolia* = narrow-leaved  
1475 *pubescens* = hairy  
1336 *parviflora* = few-flowered  
1330 *elegans* = elegant  
1324 *grandiflora* = large-flowered  
1277 *latifolia* = broad-leaved  
1155 *montana* = (of a) mountain  
1124 *longifolia* = long-leaved  
1102 *acuminata* = pointed  
  
Take the numbers [*cum grano
salis*](http://en.wikipedia.org/wiki/Grain_of_salt). The first thing I
did with the CoL tables was check for duplicates, and they\'re there,
unfortunately. It\'s interesting, though, that *gracilis* tops the
taxonomists\' poll for both the animal and plant kingdoms.  
  
\*With the GNU/Linux commands  
  

::: {style="font-family:sans-serif;background-color:#E6E6E6;"}
  
awk -F\"\t\" \'(\$11 == \"Animalia\") && (\$8 == \"species\") {print
\$20}\' taxa.txt \| sort \| uniq -c \| sort -nr \| head  
awk -F\"\t\" \'(\$11 == \"Plantae\") && (\$8 == \"species\") {print
\$20}\' taxa.txt \| sort \| uniq -c \| sort -nr \| head  
:::

  


The following is a guest post by Bob Mesibov.

Guest post: Top 10 species names and what they mean

The following is a first for iPhylo, a guest post by [Bob
Mesibov](http://www.qvmag.tas.gov.au/qvmag/?c=153).
![Bob](http://lh4.ggpht.com/-GuEIp2E_0Ns/T_6s1sVLk3I/AAAAAAAABh0/lr7VS0hnXoY/bob.jpg?imgmax=800 "bob.jpg"){border="0"
width="113" height="146" style="float:right;"}  
  
Rod Page introduced \'dark taxa\' here on
[iPhylo](http://iphylo.blogspot.com.au/2011/04/dark-taxa-genbank-in-post-taxonomic.html)
in April 2011. He wrote:  
  

> The bulk of newly added taxa in GenBank are what we might term \"dark
> taxa\", that is, taxa that aren\'t identified to a known species. This
> doesn\'t necessarily mean that they are species new to science, we may
> already have encountered these species before, they may be sitting in
> museum collections, and have descriptions already published. We simply
> don\'t know. As the output from DNA barcoding grows, the number of
> dark taxa will only increase, and macroscopic biology starts to look a
> lot like microbiology.

  
Rod suggested that \'quite a lot\' of biology can be done without
taxonomic names. For the dark taxa in GenBank, that might well mean
doing biology without organisms -- a surprising thought if you\'re a
whole-organism biologist.  
  
Non-taxonomists may be surprised to learn that a lot of **taxonomy** is
also done, in fact, without taxonomic names. Not only is there a \'dark
taxa\' gap between putative species identified genetically and Linnaean
species described by specialists, there\'s a \'dimly lit taxa\' gap
between the diversity taxonomists have already discovered, and the
diversity they\'ve named.  
  
Dimly lit taxa range from genera and species given code names by a
specialist or a group of collaborators, and listed by those codes in
publications and databases, to potential type specimens once seen and
long remembered by a specialist who plans to work them up in future,
time and workload permitting.  
  
In that phrase \'time and workload permitting\' is a large part of the
explanation for dimly lit taxa. Over the past month I created 71 species
of this kind myself. Each has been code-named, diagnostically imaged,
databased and placed in code-labelled bottles on museum shelves. The
relevant museums have been given digital copies of the images and
data.  
  
The 71 are \'species-in-waiting\'. They aren\'t formally named and
described, but specialists like myself can refer to the images and data
for identifying new specimens, building morphological and
biogeographical hypotheses, and widening awareness of diversity in the
group to which the 71 belong.  
  
\'Time and workload permitting\'. Many of the 71 are poor-quality or
fragmented museum specimens from which important morphological data, let
alone sequences, cannot be obtained. Fresh specimens are needed, and
fieldwork is neither quick nor easy. In my special corner of zoology, as
in most such corners in zoology and botany, the widespread and abundant
species are all, or nearly all, named. The unnamed rump consists of a
huge diversity of geographically restricted and uncommon species. There
are more than 71 in that group of mine; those are just the rare species
I know about, so far.  
  
\'Time and workload permitting\'. A non-taxonomist might ask, \'Why
don\'t you just name and describe the 71 briefly, so that the names are
at least available, and the gap between what\'s known and what\'s named
is narrowed?\' The answer is simple: inadequate descriptions are the
bane of taxonomy. There are hundreds of species in my special group that
were named and inadequately described long ago, and which wind up on
checklists of names as \'*nomen dubium*\' and \'*incertae sedis*\'.
Clearing up the mysteries means locating the types (which hopefully
still exist) and studying them. That slow and tedious study would better
have been done by the first describer.  
  
Cybertaxonomic tools can help bring dimly lit taxa into full light, but
not much. The rate-limiting steps in lighting up taxa are in the minds
and lives of human taxonomists coping with the huge and bewilderingly
complex diversity of life. It\'s not the tools used after the observing
and thinking is done, it\'s the observing and thinking.  
  
In their article \'Ramping up biodiversity discovery via online quantum
contributions\' (<http://dx.doi.org/10.1016/j.tree.2011.10.010>),
Maddison et al. argue that the pace of naming and description can be
increased if information about what I\'ve called dimly lit taxa is
publicly posted, piece by piece, \'publish as you go\', on the Internet.
In my case, I would upload images and data for my 71
\'species-in-waiting\' to suitable sites and make them freely
available.  
  
Excited by these discoveries, amateurs and professionals would rush to
search for fresh specimens. Specialists would drop whatever else they
were doing, borrow the existing specimens of the 71 from their
repositories and do careful inventories of the morphological features I
haven\'t documented. Aroused from their humdrum phylogenetic analyses of
other organisms, molecular phylogeny labs would apply for extra funding
to work on my 71 dimly lit taxa. In no time at all, a proud team of
amateurs and specialists would be publishing the results of their
collaboration, with 71 names and descriptions.  
  
Shortly afterwards, flocks of pigs would slowly circle the 71 type
localities, flapping their wings in unison.  
  
Memo to Maddison et al. and other would-be reformers: the rate of
taxonomic discovery and documentation is very largely constrained by the
supply of taxonomists. You want more names, find more namers.


The following is a first for iPhylo, a guest post by Bob Mesibov. Rod Page introduced 'dark taxa' here on iPhylo in April 2011. He wrote:Rod suggested that 'quite a lot' of biology can be done without taxonomic names.

Rogue Scholar Beiträge

Guest post: Our taxonomy is not your taxonomy

Guest post: It's 2016 and your data aren't UTF-8 encoded?

Guest post: 10 explanations for messy data, by Bob Mesibov

Guest post: Top 10 species names and what they mean

Dimly lit taxa - guest post by Bob Mesibov