iPhylo

Roderic D. M. Page

Wednesday, May 13, 2026

A new way to view the Tree of Life

One of the grand challenges of comparative biology is to assemble the [“tree of life”](https://en.wikipedia.org/wiki/Tree_of_life_(biology), a diagram that connects all species in a single structure (let’s leave aside for now the question of whether a tree is actually the best representation). My goal here is to outline a way of navigating the tree of life, specifically the Open Tree of Life.

Given a tree with some 2 million species, the obvious question is how can we visualise it? There are several projects that can accommodate trees of this size, such as Vienne’s LifeMap, Rosindell’s OneZoom, and Taxonium. Each of these viewers is impressive in their own way, but in my opinion each has problems. LifeMap treats the tree as a static structure in 2D space and uses tiles to enable the user to zoom in and out in the same way we navigate a digital map. Because trees are mostly empty space it is easy to get lost. OneZoom uses an almost hypnotic fractal tree layout, coupled with zooming in and out - a similar approach to LifeMap but with a different way to render the tree. It is fun, but the fractal pattern distorts aspects of the tree. Taxonium takes a different approach, the complete tree is rendered in 2D and is uniformly zoomed on the y-axis, stretching it out.

None of these projects has felt satifsfactory to me. They often don’t use the screen area efficiently, labels can be hard to read, and they treat tree visualisation as simply scaling or stretching a fixed layout. Open Tree of Life itself has a viewer tries a different approach to showing the tree, collapsing various nodes, but it feels clunky in comparison to the other viewers. This is a pity, because the Open Tree of Life is a fascinating project, a supertree that is regularly(ish) updated with new phylogenies, and which links to evidence for each node in that tree.

For a while I’ve been exploring a method called summary trees to display large trees, such as taxonomic classifications (based on work by Karloff and Shirley). The key feature of a summary tree is that you collapse a tree to a specified number of nodes (or leaves), which means you can ensure that the tree fits into your display space, and hence that all labels are legible. The trick is to figure out what nodes to collapse. I’ve used the approach of Libin et al. that partitions a tree based on a score given to each node.

This is a nice idea, but if you fit the tree of life into a browser window say, 30 lines high, then how do you see the rest of the tree? One approach would be to treat growing the tree as a form of zooming, so that one level of zoom would grow the tree to twice the size, and so on, and you would then have to pan to see the whole tree. I think this has potential for individual phylogenies, but for really big trees you just end up getting lost.

Instead, what if you clicked on a node in the tree and that node became the root of a new tree that you could explore, and that tree would be guaranteed to fit in your window? So you browse through the tree, making different parts fan out or collapse as needed.

This seemed appealing, but animating the transition between trees felt rather beyond my programming skills… so I asked ChatGPT and Claude for help. Part of the challenge to problem solving is understanding what the actual problem is. ChatGPT introduced me to the idea of a “transition scene” where you have the before and after trees, and you compute how one transforms into the other. Claude Code made this a reality, and now I could smoothly navigate around the tree. Obviously, starting at the root of the whole tre everytime would get tedious, so I added a simple search tool to find a node in the tree to start from.

So we have a the notion of collapsing a tree to a given size (summary trees), a way to decide what nodes to collapse (a combination of a scoring scheme and a priority queue), and we use transition scenes to move between trees. You can see the result of all this here: https://iphylo.org/ott-viewer.

Having got a browseable tree working, the next issue is how do you go “back”, and what does “going back” even mean? We can wire up the browser’s back button to take you back to the previous tree, but I wanted something more. I’d come across a paper that described “Hoptrees” which shows your navigation history not as a simple linear list of where you have been, but arranges that history as a tree. This felt like a natural fit for navigating the tree of life, and hence above the tree you will see your navigation history as a simplified version of the larger tree.

As always there is more that could be done, but this feels like a natural stopping point. The tree browser works, and when I use it I spend less time thinking about the interface and more about the relationships in the tree, and that feels as it should be.

References

Brooks, M., West, J. D., Aragon, C. R., & Bergstrom, C. T. (2013). Hoptrees: Branching History Navigation for Hierarchies. In P. Kotzé, G. Marsden, G. Lindgaard, J. Wesson, & M. Winckler (Eds), Human-Computer Interaction – INTERACT 2013 (pp. 316–333). Springer. https://doi.org/10.1007/978-3-642-40477-1_20

Karloff, H., & Shirley, K. E. (2013). Maximum Entropy Summary Trees. Computer Graphics Forum, 32(3pt1), 71–80. https://doi.org/10.1111/cgf.12094

Libin, P., Vanden Eynden, E., Incardona, F., Nowé, A., Bezenchek, A., EucoHIV Study Group, Sönnerborg, A., Vandamme, A.-M., Theys, K., & Baele, G. (2017). PhyloGeoTool: Interactively exploring large phylogenies in an epidemiological context. Bioinformatics, 33(24), 3993–3995. https://doi.org/10.1093/bioinformatics/btx535

Page, R. D. (2012). Space, time, form: Viewing the Tree of Life. Trends in Ecology & Evolution, 27(2), 113–120.

Sanderson, T. (2022). Taxonium, a web-based tool for exploring large phylogenetic trees. eLife, 11, e82392. https://doi.org/10.7554/eLife.82392

De Vienne, D. M. (2016). Lifemap: Exploring the Entire Tree of Life. PLOS Biology, 14(12), e2001624. https://doi.org/10.1371/journal.pbio.2001624

Wong, Y., & Rosindell, J. (2022). Dynamic visualisation of million‐tip trees: The OneZoom project. Methods in Ecology and Evolution, 13(2), 303–313. https://doi.org/10.1111/2041-210X.13766

Monday, May 04, 2026

Alpha shapes and DNA barcoding

How to cite: Page, R. (2026). Alpha shapes and DNA barcoding. https://doi.org/10.59350/qx8j9-vam77

DNA barcoding generates a lot of specimen data with geographical coordinates (see for example Guest post: response to “Putting GenBank Data on the Map”). The question naturally arises: “how accurate are those coordinates?”.

Browsing the BOLD database using BOLD View I often come across sequences whose coordinates are labelled “Coordinates from country centroid”, so these may bear little relation to where the specimen was actually collected. But how can we assess the accuracy of other coordinates?

Inspired by a 2008 Flickr blog post The Shape of Alpha I decided to create plots of the distribution of geotagged specimens in the BOLD database, grouped by geographic level. For example, we could aggregate all points labelled as being from the country “India”, then subset those into points labelled as being from various regions within India, and so on down the geographic hierarchy implied by country, province, etc. Rather than plot all the points, I decided to sumamrise them using the same approach Flickr used, we enclose the points in an alpha shape. Below are examples for India.

The two maps differ in how closely the curve fits the points, which is determined by the value of alpha (α) used to compute the shape. The smaller the value the tighter the fit. The first map used α=0.3 and is fairly coarse, with α=0.1 we see the alpha shape skirts around Bangladesh, and is hence a better representation of the boundary of India.

The original Flickr blog post was showing how well geotagged photographs on Flickr were tracing out geographical areas. From my perspective, one reason to make these maps is to spot problematic records. For example, the map for Tasmania looks a bit strange. There are records on the Australian mainland, and Lord Howe and Macquarie Islands that clearly aren’t from “Tasmania”. Maybe the coordinates are wrong, maybe the placename is wrong? Either way, we now have some records to investigate.

This project is live on the BOLD View web site, it was mostly written using Claude Code, making use of the GIS features in Postgres. It is an example of how easy AI tools make it to do some quick exploration of an idea (in this case, something inspired by a blog post that is nearly twenty years old).

Wednesday, March 18, 2026

SimpleMappr is dead, long live SimpleMappr?

How to cite: Page, R. (2026). SimpleMappr is dead, long live SimpleMappr? https://doi.org/10.59350/20dk7-8ns92

David Shorthouse, perhaps best know for his fabulous Bionomia project is also the author of SimpleMappr , a web site for generating publication-ready species distribution maps. These maps have appeared in many publications, and also pop up in iNaturalist.

David has announced that SimpleMappr will be turned off. Obviously not an easy decision for him to take, and sadly yet more evidence of the fragility of a lot of taxonomic infrastructure (as seen in the struggles of both BHL and TAXACOM).

I don’t use SimpleMappr, but I know that lots of people do, and so I wondered how easy it would be to create a new version (based on David’s code) that could be hosted either on a central site or on people’s own computers The short answer is that it is “easy”, so long as your definition of “easy” includes (a) getting Claude Code to do the bulk of the work, and (b) ignoring most of the more sophisticated features of David’s app.

Long story short, I have a (somewhat) working version of SimpleMappr running on a cloud server at https://simplemappr.cloud, source code here.

As with my previous post, this project involved forking the original code, asking Claude to read it, and sketch out a way to move it to a more robust setting, in this case using Docker containers. Early days, but I am delighted how easy (for various values of “easy”) it is to breath new life into old projects.

Using AI to revive a macOS app to preview GIS files

How to cite: Page, R. (2026). Using AI to revive a macOS app to preview GIS files. https://doi.org/10.59350/rb118-6m142

About a decade agho when I was working with GIS files, such as shapefiles, there was a nice QuickLook plugin for Macs called 1. GISLook that would show you the corresponding map as an icon.

macOS keeps evolving, as a result apps become obsolete unless they are continually updated. For small, solo developer projects, this often means the app no longer works. If the code is open source, at it is in this case, then potentially somebody can come a long and revive the project. But, realistically this can be a daunting prospect. I last wrote native macOS code about two decades ago, a lot has changed.

Indeed, a lot has changed. With tools such as Claude Code, it is possible to point an AI at an old repository and, in effect, say, “build this, but for today’s Macs”.

In this case, I cloned the original repo, asked Claude to take a look, and then created a new repo rdmpage/gis-quicklook and Claude got to work. Of the original code, only the core file reading functions survive, the interface code has all gone. But after about a day’s messing about, I have a new app that has even more functionality because it supports the GeoJSON format as well.

You can get the app from the GitHub repo. Note that because it isn’t the App Store you will need to run a onetime command in terminal to get it to work:

xattr -cr GISLookApp.app

Here are four GIS files and their preview icons.

I should thank the original author, Bernie Jenny at Monash University in Melbourne. If you are at all interested in maps, globes, and cartography, you should look at his web page, it has some very cool stuff. I coundln’t have done this project without his open source (GPL 3.0) code.

Nor could I have done it without Claude Code. The level of debugging involved in this project was insane, there were log files flying past, Finder cache rebuilds, numerous dead ends and subtle “gotchas”, never mind the obstacle of learning how to support custom Finder icons and previews on a modern Mac.

This is the larger point, AI makes it possible, at least in principle, to look at an old, abandoned project, perhaps targeting an out of date API, and have a realistic chance of reviving it. That is a real game changer, made possible by a combination of open source and state of the art AI.

Tuesday, March 10, 2026

Using AI to understand a DNA barcoding mystery

How to cite: Page, R. (2026). Using AI to understand a DNA barcoding mystery. https://doi.org/10.59350/nbsfn-91m72

As I continue to add features to BOLD-View I keep coming across interesting cases where something seems not quite right with the data. Typically this prompts further investigation, which typically means going down a rabbit hole. As an example, take barcode GMAEA6199-22 which was collected by Donald Hobern in Australia and is identified to order level as Strepsiptera (I thank Donald for this example).

This barcode falls within a cluster which contains sequences labelled as either strepsipteran (in many cases identified down to species, Elenchus varleyi) or hempiteran. Almost all the strepsipteran sequences are assigned to a BIN BOLD:ACH2898. The hemipteran sequences are not assigned to a BIN, even though they are essentially identical to the strepsipteran sequences.

A new feature I’ve added to BOLD View’s display for a barcode is a map of all similar sequences, grouped by BINs. For this example the Stepsiptera BIN has a wide geographic range, including central America and South Africa, as well as Australia (through GMAEA6199-22 which is a stepsipteran but not included in the BIN).

So, we have a widespread BIN, likely to be Elenchus varleyi, which has identical sequences to those labelled as hemipteran. What is going on?

Now if you know anything about Strepsiptera you’ll know that they have a pretty bonkers biology, being endoparasites of insects, and male and females have quite different life histories. But as an exercise I decided to ask Claude to see what it made of this situation. Here is the prompt I used.

I also uploaded the tree picture you see above, and the paper “Descriptions and biological notes of the Australian Elenchidae (Strepsiptera)” doi:10.1071/IT9890175 which described Elenchus varleyi (I got the DOI for the paper from another of my projects, BioNames.

The paper is behind a paywall, and isn't on SciHub, but is on [ResearchGate](https://www.researchgate.net/publication/248899086), so I downloaded the PDF and used Marker to convert it to Markdown, which has become the default language of choice for sending documents to AIs.

Claude thought for a bit and then came back with a summary that basically said:

the mixture of strepsipteran and hemipteran sequences is likely due to the “hemipteran” barcodes actually being for their strepsipteran parasites rather than the hemipterans themselves.
give that one of the hosts of Elenchus varleyi is Sogatella kolophon, which is widespread, that would account for the occurrence of essentially identical DNA sequences across separate continents.

Claude noted that a single hemipteran can host multiple strepsipteran individuals, increasing the chance of mistakenly sequencing the pareasite rather than the host. The picture below shows adult neotenic females ♀ of the Elenchus varleyi in the abdomen of the hemipteran Sogatella kolophon. (Fig. 14 from doi:10.1071/IT9890175).

Now, you and I could figure this out with some background biology and reading the paper, but the point here is that Claude could do it more or less automatically, which means we could potentally scale this to look at all “odd” or “anomalous” barcodes and get suggestions as to what has happened. Hence we have the possibility for large-scale database curation (see also “CurateGPT: A flexible language-model assisted biocuration tool” doi:10.48550/arXiv.2411.00046).

That said, we need some things in place. It helps to have links to information on the species and sequences involved, e.g. what paper(s) described the species, what paper(s) published the sequences. In this case I used BioNames to find the DOI for the paper describing Elenchus varleyi which was behind a paywall. That is likely to be an obstacle to this approach.

Out of curiousity I explored an alternative scenario, in part inspired by Plazi. Imagine that we can’t share the full text of the paper, but we do have access to the facts or claims the paper makes. Plazi doesn’t quite do this, it extract images and the text of taxonomic treatments, but let’s imagine we could extract a series of triples from the paper, such as:

(Elenchus varleyi, parasitises, Sogatella kolophon)

Given a set of these we could potentially still infer the cause of the barcoding patterns we were seeing, but without needing access to the paywalled text (we’d need access to the text to extract the triples, but Claude wouldn’t need to see the text). Of course, this is not a new idea (Peter Murray-Rust has been advocating for this for a long time).

But what triples should we extract from a given paper. Out of interest I asked Claude what triples it would need to generate the answer it gave me to the strepsiptera/hemiptera example. Here is what it gave me:
Parasite–host relationships:

(Elenchus varleyi, parasitises, Sogatella kolophon)
(Elenchus varleyi, parasitises, Toya drope)
(Elenchus varleyi, host_family, Delphacidae)
(Sogatella kolophon, is_majority_host_of, Elenchus varleyi)

Life cycle and tissue intimacy (critical for the contamination argument):

(Elenchus varleyi female, is_obligate_endoparasite_of, adult host)
(Elenchus varleyi female, life_strategy, neotenic/larviform)
(Elenchus varleyi female, spends_entire_life_in, host body)
(Elenchus varleyi male, develops_as, endoparasitic larva)
(Elenchus varleyi female, extrudes_only_in, adult hosts)

Superparasitism (strengthens contamination argument):

(Elenchus varleyi, exhibits, superparasitism)
(superparasitism, maximum_observed, six parasitoids per host)
(superparasitism, frequency, common in Brisbane)

Dispersal mechanism:

(Elenchus varleyi female, dispersed_by, macropterous adult hosts)
(Elenchus varleyi larvae, dispersed_by, macropterous adult hosts)
(Elenchus varleyi male pupa, extrudes_in, both nymphs and macropterous adults)

Taxonomic and geographic scope:

(Elenchus, distribution, cosmopolitan)
(Elenchus, only_parasitises, Delphacidae)
(Elenchus varleyi, type_locality, Brisbane Queensland)
(Elenchus varleyi, distribution, Queensland NSW Canberra Northern Territory)

Supporting observation (supporting wide distribution argument):

(Perkins 1907, observed, Elenchus from widely separated countries show very little difference)

Now I think that some of these triples we could dispense with. I asked Claude and it said the following would be enough:

(Elenchus varleyi, parasitises, Sogatella kolophon)
(Elenchus varleyi female, is_obligate_endoparasite_of, adult host)
(Elenchus varleyi, host_family, Delphacidae)
(Elenchus varleyi female, dispersed_by, macropterous adult hosts)
(Elenchus, distribution, cosmopolitan)

These are fairly simple statements that could liklely be extracted from the paper. That raises issues of how we do that, and how we express those triples. I asked Claude for suggested vocabularies, it mentioned Darwin Core and the Relations Ontology, among others. I am congenitally averse to big, verbose ontologies so I’d prefer something light weight, and maybe Darwin Core would be enough?

So, in summary, I’m encouraged by the way Claude suggested a plausible explanation for the pattern in the barcode tree, and that it might not always need access to full text to do so (although I suspect giving an LLM access to full text is likely to beat giving it a set of triples that might not encompass all the relevant information in the paper). This also gives me a further incentive to work on the problem of providing context for each barcode, especially the scientific papers that published the sequences, and the papers that published the taxonomic names.

But one problem still remains. How do we get all this information back into BOLD so that a user looking at these sequences knows what is going on, knows that "Hemiptera" doesn't mean "Hemiptera" in this case, and that what we are seeing is a case of a widespread insect host being infected by a widespread parasite, which was originally described from Australia. The ability to add annotations and thrid party analyses will become crucial if people are to get the most out of DNA barcoding databases.

References

Caufield, H., Kroll, C., O’Neil, S. T., Reese, J. T., Joachimiak, M. P., Hegde, H., Harris, N. L., Krishnamurthy, M., McLaughlin, J. A., Smedley, D., Haendel, M. A., Robinson, P. N., & Mungall, C. J. (2024). CurateGPT: A flexible language-model assisted biocuration tool (arXiv:2411.00046). arXiv. https://doi.org/10.48550/arXiv.2411.00046
Kathirithamby, J. (1989). Descriptions and biological notes of the Australian Elenchidae (Strepsiptera). Invertebrate Taxonomy, 3(2), 175–195. https://doi.org/10.1071/it9890175

Sunday, February 15, 2026

GBIF Geocoder: using GBIF to find places on a map

How to cite: Page, R. (2026). GBIF Geocoder: using GBIF to find places on a map https://doi.org/10.59350/7g6pt-3mz06

I’ve relaunched a “toy” tool that I made a while ago to help geocode localitiies using GBIF. Geocoding converts a text string, such as “Cambodia: Ratanakiri Province” into latitude and longitude coordinates. For some reason, the biodiversity community typically refers to this as “georeferencing”, which is usually defined as locating an image of a map (see Wikipedia entry for georeferencing, and Allmaps for some great examples).

You can try GBIF Geocoder at https://rdmpage.github.io/gbif-geocoder/. Code is available on GitHub at https://github.com/rdmpage/gbif-geocoder.

The idea behind the “GBIF Geocoder” is that GBIF has a huge number of geocoded specimens, and hence if you are looking for coordinates for a locality there is a good chance that somebody has already found them. So, all we need to do is search GBIF for specimens with localities that match the place you are trying to geocode. I created a version of this tool in 2018, mentioning it in a blog post GBIF at 1 billion - what’s next?, and wrote it up in a short note in bioRxiv Geocoding genomic databases using GBIF.

The original version was hosted on Glitch, a wonderful platform where people to create pretty much anything using HTML and Javascript. Glitch is no more so I’ve finally got around to rebuilding it, inspired by this post on Bluesky by Tapani Hopkins:

The original project used node.js, whereas I wanted something simple using just HTML and Javascript so it could be hosted using GitHub pages (or, indeed, on any other static hosting platform). I fired up Claude Code to help me with the port. I continue to be amazed at just how much fun this style of coding is, and the power of the tools. I make requests and suggestions, and Claude will fire up an instance of Google Chrome to check that the code works. I think a key feature of this style of programming is that it can reduce that inital hurdle when you know you need to make changes, and may even have made notes to yourself about what needs to be done, but there will the initial tedium of reworking old code to work with a new platform i.e., Googling questions, re-reading GitHub docs, etc. Instead, I get to focus on what I want to do, namely revive an old tool that I think people may find useful.

Wednesday, November 19, 2025

Model Context Protocol (MCP) and triple stores: natural language queries for knowledge graphs

Some quick notes based on experiments with Model Context Protocol (MCP) and (Claude](https://claude.ai).

Model Context Protocol (MCP) is all the rage right now, and I’ve been slow to take a look. Kingsley Idehen recently wrote The Semantic Web Project Didn’t Fail — It Was Waiting for AI (The Yin of its Yang) where he argued that Large Language Models (LLMs) provide (finally) a user-friendly way to query triple stores (i.e., knowledge graphs). Instead of simply presenting users with an empty SPARQL query box, we can now formulate a query in natural language and have AI convert that into SPARQL.

That eases the challenge of learning a new query language, but it get’s better. MCP enables us to connect an AI with another service. It acts a bit like a broker. You tell the AI what you want to do, the AI talks to the MCP server to figure out how to do what you want, gets the results, then converts them into a natural language (or other format) result that you can use. hence you can have a conversation with a knowledge graph!

There are examples of MCP servers that speak SPARQL, such as MCP Server SPARQL by
Eric Zhu. Since I mostly program in PHP (gasp) version 7 (gasp) I ended up asking ChatGPT to help write a simple MCP server. There then followed a dance between ChatGPT and Claude where ChatGPT would very confidently declare that the code was done, and Claude would get increasingly exasperated that I appeared to be trying to do something that wasn’t working. I eventually had to tell Claude to back the f**k off with its snarky comments and maybe be more helpful in its messages. Eventually I got a simple server up and running.

The code php-mcp-server is very basic, but supports SPARQL queries running on an instance of Oxigraph that runs on my Mac. For example, I can ask:

and Claude will respond:

It will also show me the SPARQL queries it makes to find this information.

This feels like a game changer. The MCP server I’ve written is incredibly crude, but I can now start to query a knowledge graph about DNA barcodes and associated literature in plain English, and get back useful results.

What I really want to do is combine this with details on the actual papers (for example, lists of specimens sequenced, whether they are type specimens, where were the samples collected from, etc.) as a way to help curate databases such as BOLD. I recently released BOLD View (see blog post BOLD View: exploring DNA barcodes) to make it easier to explore DNAbarcode data, and I’m fascinated by how much scope there is for curation to add taxonomic identifications, geographic location, etc.

To make this curation eassier I’ve started to assemble a knowledge graph linking barcodes, Genbank sequences, and taxonomic names to the associated scientific literature, with the ultimate goal of being able to ask: “given this barcode that lacks a proper scientific name, is there anything in the published literature that can tell me what it actually is?”. The idea of being able to literally ask that question using a combination of an AI and a MCP server is vert exciting.

Thursday, August 07, 2025

Make Data Count Kaggle Competition

I’ve written several times here about the Make Data Count project and its major output to date, the Data Citation Corpus, currently at version 4 (see The fourth release of the Data Citation Corpus incorporates data citations from Europe PMC and additions to affiliation metadata).

In June Make Data Count launched a Kaggle Competition with the goal of developing a tool that will process articles (in either PDF or XML format), extract data citations (e.g., DOIs for datasets in repositories such as Dryad, or accession numbers such as 6TAP in the Protein Data Bank), and classify these citations as either “primary” (data published in that paper) or “secondary” (reuse of existing data

I think the competition is an excellent idea, and the $US100,000 is a great motivator to get people trying to solve this problem. I’m tacking part in the competition, which has meant learning Python very fast. I’ve dabbled a bit before, but this was a whole new thing. ChatGPT has been indespensible, especially in explaining why something I was doing wasn’t going to work, and what an error message really meant. The whole process became horribly addictive. You can submit a solution on five tiems a day, and the counter resets at midnight GMT, so there were nights I was up well after midnight coding and using up the following day’s submission quota! Another interesting feature is the lively discussion between people that are rivals for substantial prize money. Participants are sharing code and ideas, often not their best scoring ideas — after all, everyone wants to win — but still giving hints and support, and sharing findings.

The competition provides a small set of training data (about 500 PDFs and a simialr number of XML files). The idea is that you write code to analyse those files and output a list of data citations. You then submit your entry to Kaggle, which runs your code against a “hidden” set of PDFs and XML files and tells you your score. The best score wins prizes. My place in this competiton pretty accurately reflects my skills and ability :)

Issues with the competition

Unfortunately the competition itself has been — how shall I put this — poorly run. There has been virtually no engagement from DataCite in their own competition, despite repeated queries from the entrants to explain the often inexplicable reasoning for the scoring in the training data, or why some of the PDFs are wrong or incomplete. Some PDFs are preprints, not the actual papers (and may differ in whether they cite data or not). The XML comes in a variety of formats, which we weren’t told about. Some XML was “gold standard” JATS-XML as used by PubMed Central, others were publisher specific, or the output of PDF parsers or annotation tools.

I ended up making my own training data (https://doi.org/10.34740/kaggle/dsv/12667298) listing what I think are the actual data citations (about twice as many as are in the “official” training data).

There are some high scoring entries (see the leaderboard) so it looks like Make Data Count will get somes useful tools form this competition. My only concern is that these tools may be optimised to replicate the somewhat erratic and poorly described annotation process that DataCite used to create the training and “hidden” test data, rather than accuarately retrieve the actual data citations. Perhaps my concerns will prove unfounded, or maybe the tools can be easily retrained with better data.

But I am somewhat baffled that such an importasnt project for which Make Data Count have secured funding for serious prize money has been essentially left unattended by the organisers.

The competition runs until 3 September.

References

Page, R. (2024). Problems with the DataCite Data Citation Corpus https://doi.org/10.59350/t80g1-xys37
Page, R. (2024). The Data Citation Corpus revisited https://doi.org/10.59350/wvwva-v7125

Tuesday, July 08, 2025

How many times are DNA barcoding datasets cited?

How to cite: Page, R. (2025). How many times are DNA barcoding datasets cited? https://doi.org/10.59350/s0c6z-2m608

This note accompanies a dataset that I uploaded to Zenodo (https://doi.org/10.5281/zenodo.15824274). My goal in creating this dataset is to link data created on the Barcode of Life Data Systems to the DOIs for those datasets, and then to link those data DOIs to DOIs for the papers (if any) that created those datasets, and/or cited them.

For example, the paper “DNA barcodes enable higher taxonomic assignments in the Acari” (Young et al., 2021) cites three barcode datasets: DS-BINFL, DS-5FLR, and DS-10FLR. Each of these datasets has a DOI of the form: https://doi.org/10.5883/ plus the DS number. One reason I want to m ake these links is so that when the dataset is displayed, say, in my BOLD View app, I could also show the papers that created/cited the dataset, providing some context to the data (e.g., why was the data collected?). Another reason is that once we link data to papers we can do some interesting things, such as assign credit (Zeng et al. 2020), or discover what organisations funded the work. I hope to explore these topics in the future.

Matching datasets to publications was a tedious process, there are more details on the GitHub repository. I started with a Google Scholar search, then did lots of manual filtering and cleaning. Most of the articles have DOIs, and only these articles are included in the Zenodo dataset, which is intended as a contribution to Make Data Count.

This only scratches the surface of what could be done. There are many datasets that I could not find in the literature (they may never have been cited). I also want to retrieve links between individual DNA barcodes and the papers that published them. Apart from context and metrics, I’m also interested in whether these papers might contain more detailed information about the sequences, such as geographic localities. In this way we could potentially enrich the BOLD database, as part of the “virtuous cycle” envisioned by David Schindel (Schindel and Page, 2024).

References

Page, R. (2025). Citations of datasets published by Barcode of Life Data Systems (BOLD) [Data set]. Zenodo. https://doi.org/10.5281/zenodo.15824274

Schindel, D. E., & Page, R. M. P. (2024). Creating Virtuous Cycles for DNA Barcoding: A Case Study in Science Innovation, Entrepreneurship, and Diplomacy. DNA Barcoding, 7–32. https://doi.org/10.1007/978-1-0716-3581-0_1

Young, M. R., deWaard, J. R., & Hebert, P. D. N. (2021). DNA barcodes enable higher taxonomic assignments in the Acari. Scientific Reports, 11(1). https://doi.org/10.1038/s41598-021-95147-8

Zeng, Tong, Longfeng Wu, Sarah Bratt, and Daniel E. Acuna. ‘Assigning Credit to Scientific Datasets Using Article Citation Networks’. Journal of Informetrics 14, no. 2 (1 May 2020): 101013. https://doi.org/10.1016/j.joi.2020.101013.

Thursday, June 05, 2025

A metabarcoding mess and the importance of just looking at the data

How to cite: Page, R. (2025). A metabarcoding mess and the importance of just looking at the data. https://doi.org/10.59350/q2v8n-wc488

Here I summarise a few posts on Bluesky where I raised concerns about some metadabarcoding datasets that were highlighted by GBIF:

Looking at these datasets it’s clear that something is wrong.

Data

The datasets discussed are for CO1 Amplicon Sequence Variants from Madagascar, which are part of the Insect Biome Atlas project. The data is described in Miraldo et al. https://doi.org/10.1038/s41597-025-05151-0. There are two datasets for Madagascar:

CO1 Amplicon Sequence Variants of leaf litter arthropod communities collected at Malaise traps from the Insect Biome Atlas project in Madagascar https://doi.org/10.15468/pad7pc
CO1 Amplicon Sequence Variants of bulk arthropod samples (mild lysis) collected with Malaise traps from the Insect Biome Atlas project in Madagascar https://doi.org/10.15468/6u5rum

In case the data changes in the future I’ve made snapshots of the two datasets and uploaded them to Zenodo doi:10.5281/zenodo.15599342. The files I downloaded (https://doi.org/10.15468/dl.kwjyjt and https://doi.org/10.15468/dl.2p3z5q) are the GBIF annotated archives, hence they include the mapping between the taxonomic names and GBIF’s backbone taxonomy.

Problem

In browsing the data on GBIF I noticed some striking distribution patterns: insects normally found in Europe and/or North America were also turning up in Madagascar, based solely on these metabarcoding datasets. For example, Helina impuncta.

Helina impuncta

Metadata barcoding data can be a complicated beast, especially if you try and navigate the multiple databases that house metadata on the sampling program and the output of sequencing machines. For example, GBIF occurrence 5162479277 is linked to ENA record ERR12944764 which in turn has multiple identifier links:

Study Accession	Sample Accession	Experiment Accession	Run Accession	Tax Id
PRJEB61109	SAMEA115499645	ERX12317105	ERR12944764	1234904

What’s nice about the GBIF datasets that they wrap all this up into a single package that we can explore. BLASTing a few sequences in these datasets suggests that the identifications of these sequences were probably correct, so the source of the problematic maps lies elsewhere.

Lots of maps

I wrote a simple PHP script to read the GBIF dataset, aggregate the GBIF taxon ids (i.e., the GBIF taxa that the sequences were mapped to) and draw a map for each taxon (code is on GitHub) . These maps use GBIF’s maps API to retrieve a tile (256 x 256 pixels) showing the distribution of each taxon on a global map (i.e., zoom level 0 on a tiled web map). I overlay that on a GBIF base map tile (see Base Map Tiles), and dump the output as HTML.

This is crude but gives a quick visual overview of the data. For the litter datasets there are a lot of these Euro-Madagascar distributions:

litter

For the malaise trap data the results look much more like what I’d expect, lots of taxa restricted to Madagascar.

malaise

But there are still examples of the problematic pattern mentioned above.

What happened?

In the paper describing the data there is a paragraph discussing contamination:

The paper goes on to discuss possible examples of contamination. Looking at the results I suspect there has been a lot more contamination than the authors allow, especially for the litter dataset.

Summary

These results are preliminary, and I’ve contacted the authors of the paper to see if we can find out what happened. But for me the most obvious conclusions are:

Metabarcoding has the potential to generate a lot of spurious records that may negatively impact databases such as GBIF.
One of the great features of GBIF is that it enables you to simply look at the data. In an age of automated pipelines and big data I think visualisation is increasingly important. It’s often an easy way to discover that something is not as it should be.

References

Miraldo, A., Sundh, J., Iwaszkiewicz-Eggebrecht, E. et al. Data of the Insect Biome Atlas: a metabarcoding survey of the terrestrial arthropods of Sweden and Madagascar. Sci Data 12, 835 (2025). https://doi.org/10.1038/s41597-025-05151-0

Page, R. (2025). Snapshot of Insect Biome Atlas data for Madagascar from GBIF [Data set]. Zenodo. https://doi.org/10.5281/zenodo.15599342

Friday, May 16, 2025

Tracking changes in DNA barcode BINs

How to cite: Page, R. (2025). Tracking changes in DNA barcode BINs. https://doi.org/10.59350/h97dq-dat02

Following on from releasing BOLD View I’ve started to explore how the classifcation of DNA barcodes changes over time. BOLD uses the RESL algorithm described in Ratnasingham & Hebert (2013, 2016) to cluster barcodes into “BINs”. As the number of DNA barcodes grows over time these clusters may change. For example, some clusters may increase in size as barcodes are added, and some clusters may be merged as sequences of intermediate similarity are found that link those BINs. Within the public-facing BOLD portal there is no way to see the history of a BIN (Meier et al., 2022), so I decided to explore this. I downloaded of data packages from BOLD for the period 2022-2024, as well as the BARCODE 500K data for 2016. BOLD issues regular releases of its data, querterly releases are persistent and received a DOI. More regular releases don’t get a DOI and seem to disappear from the web site, but I have a copy of the release for 06-Sep-2024, which I used to create BOLD View.

The data packages I’ve used to infer version history are listed below.

Dataset	DOI
iBOLD.31-Dec-2016	10.5883/dp-ibold.31-dec-2016
BOLD_Public.30-Mar-2022	10.5883/dp-bold_public.30-mar-2022
BOLD_Public.06-Jul-2022	10.5883/dp-bold_public.06-jul-2022
BOLD_Public.28-Sep-2022	10.5883/dp-bold_public.28-sep-2022
BOLD_Public.30-Dec-2022	10.5883/dp-bold_public.30-dec-2022
BOLD_Public.31-Mar-2023	10.5883/dp-bold_public.31-mar-2023
BOLD_Public.30-Jun-2023	10.5883/dp-bold_public.30-jun-2023
BOLD_Public.29-Sep-2023	10.5883/dp-bold_public.29-sep-2023
BOLD_Public.29-Dec-2023	10.5883/dp-bold_public.29-dec-2023
BOLD_Public.29-Mar-2024	10.5883/dp-bold_public.29-mar-2024
BOLD_Public.19-Jul-2024	10.5883/dp-bold_public.19-jul-2024
BOLD_Public.06-Sep-2024	no DOI

Versioning

I am only interested in a few of the fields in the data, namely ,bin_uri, identification, identification_method, and identified_by. Note that field names can change between data packages, so we may have to translate field names, or assemble a field’s value from other fields (e.g., taxonomic classification). Rather than store all the data I used Tuple-versioning , so that we store values for processid and the various data fields, together values for valid_from and valid_to. The first time a combination of values is found we set valid_from to the YYYY-MM-DD date of the corresponding data package, and valid_to to NULL. Note that we may have multiple barcodes for a given processid (e.g., for different genes) so we index on both processid and marker_code. We also compute a MD5 hash of the data for a barcode to enable fast lookup of a particular set of values. The hash is not sufficient to identify an edit as the same set of values may have more than one period of validity. For example, a barcode may be in one BIN, then move to another, then move back again.

When we load the first data package (iBOLD.31-Dec-2016) all rows in the database will have NULL values for valid_to. This signals that those values for the data are currently valid. We then add the remaining data packages from oldest to most recent. For each barcode, if the data for a barcode in the current package is the same as that already in the database (i.e., for which valid_to is NULL) we do nothing. But if the data has changed we do the following:

set valid_to for the most recent row to the YYYY-MM-DD data of the current data package
add a new row with valid_from set to the same date, and valid_to set to NULL.

At the end of this process we have a list of values for the selected fields for each barcode, together with the time span that those values were valid.

Queries

There are two kinds of queries I’ve explored so far. The first is tracking the changes for an individual barcode, the other is the history of a BIN.

Barcode histories

Here is the history for XAF587-05

2022-03-30 - 2022-09-28

identification: Poanes hobomok
identified_by: Paul Hebert

2022-09-28 - 2024-07-19

identification: Lon hobomok
identified_by: Paul Hebert

2024-07-19 -

identification: Lon hobomok
identified_by: Paul D.N. Hebert

This examples shows that we need to be careful when counting edits to a barcode. We could simply record these as changes in identification and identifier, but is a little more complicated. Poanes hobomok and Lon hobomok are synonyms (Cong et al., 2019), so we’ve not changed the taxonomic identification, merely the name. In the absence of a single authoritative source of taxonomic names and synonyms I use TAXMATCH-like rules to “stem” the species names (Boyle, 2013), so that if two values of identification have the same species epithet (taking into account possible change in gender of the genus name) I treat these as changes in name, not identification. The other change is from “Paul Hebert” to “Paul D.N. Hebert”, which is clearly the same person. I compute the Levenshtein distance between values of identified_by and treat any value > 5 as a different name (5 was chosen so that “Paul Hebert” to “Paul D.N. Hebert” would be the same).

BINs

For BINs reconstruct the history by taking a BIN and finding all barcodes that have, at any point in time, been a member of that BIN. So far the best way I’ve come with to visualise the changes in a BIN is to create a “storyline” (see Liu et al., 2013) where the composition of each BIN is shown at each timeslice.

For example, here is the history of BIN BOLD:ABX0491 which contains barcocdes identifiers as Rhamma, Rhamma anosma, and Rhamma bilix (Prieto, et al. 2021).

The vertical columns are time slices, barcodes in the same BIN are grouped together in coloured rectangles, and the history of each barcode can be traced from left to right. You can see cases where barcodes have moved between BINs (BOLD:ABX0491 gobbled up two smaller BINs). There are also barcodes that were (for one time slice) not in any BIN.

This visualisation has been challenging to create, I ended up using # Graphviz as implememted in (https://dreampuf.github.io/GraphvizOnline).

Summary

This is still early stages, but it looks promising. The next step would be to incorporate it into BOLD View. It might also be interetsing to develop measures of stability of barcode clustering based on how often members move around.

References

Boyle, B., Hopkins, N., Lu, Z., Raygoza Garay, J. A., Mozzherin, D., Rees, T., Matasci, N., Narro, M. L., Piel, W. H., Mckay, S. J., Lowry, S., Freeland, C., Peet, R. K., & Enquist, B. J. (2013). The taxonomic name resolution service: an online tool for automated standardization of plant names. BMC Bioinformatics, 14(1). https://doi.org/10.1186/1471-2105-14-16
Cong, Q., Zhang, J., Shen, J., & Grishin, N. V. (2019). Fifty new genera of Hesperiidae (Lepidoptera). Insecta Mundi, 2019, 0731. https://doi.org/10.5281/zenodo.3677235
Hebert, P., & Ratnasingham, S. (2016). Systems, methods, and computer program products for merging a new nucleotide or amino acid sequence into operational taxonomic units (United States Patent US20160103958A1). [https://patents.google.com/patent/US20160103958A1)
Liu, S., Wu, Y., Wei, E., Liu, M., & Liu, Y. (2013). StoryFlow: Tracking the Evolution of Stories. IEEE Transactions on Visualization and Computer Graphics, 19(12), 2436–2445. https://doi.org/10.1109/TVCG.2013.196
Meier, R., Blaimer, B.B., Buenaventura, E., Hartop, E., von Rintelen, T., Srivathsan, A. and Yeo, D. (2022), A re-analysis of the data in Sharkey et al.’s (2021) minimalist revision reveals that BINs do not deserve names, but BOLD Systems needs a stronger commitment to open science. Cladistics, 38: 264-275. https://doi.org/10.1111/cla.12489
Prieto, C., Faynel, C., Robbins, R., & Hausmann, A. (2021). Congruence between morphology-based species and Barcode Index Numbers (BINs) in Neotropical Eumaeini (Lycaenidae). PeerJ, 9, e11843. https://doi.org/10.7717/peerj.11843
Ratnasingham, S., & Hebert, P. D. N. (2013). A DNA-Based Registry for All Animal Species: The Barcode Index Number (BIN) System. PLOS ONE, 8(7), e66213. https://doi.org/10.1371/journal.pone.0066213

Friday, April 11, 2025

Future interfaces for the Biodiversity Heritage Library

On Wednesday this week (April 9th, 2025) I gave a talk entitled “Future interface(s) for BHL” (the slides are on FigShare) at BHL Day 2025. My goal was to introduce “BHL-Light”, an exploration of an alternative interface to the Biodiversity Heritage Library (BHL). As some readers may already know, BHL is coming to a crossroads, and so this presentation felt a bit more urgent than my usual “here’s yet another web site I made”.

BHL-Light

BHL-Light is my attempt to explore other ways of navigating BHL. The current interface is somewhat dated, and I wanted to start from scratch and see what might be possible to create, even for someone with my somewhat limited skills. BHL-Light has only a very small subset of BHL’s content, I’m putting scalability issues to one side so that I can have some fun.

The tech (TL;DR BHL was not harmed in the making of this)

Under the hood, BHL-Light stores BHL metadata, OCR text, and layout information as JSON documents in CouchDB (one of my favourite databases for exploring new ideas).

BHL serves its images from Internet Archive, which is not always available. BHL recently uploaded images to AWS, but the images there are not currently viewable on the web. So I ended up creating my own image server. I used Hetzner’s S3-compatible object storage for the image files, added imgproxy to resize images as needed, and finally put all this behind a Cloudflare CDN to speed up image delivery (and reduce traffic to the S3 store, which becomes a real consideration when one is paying for all of this).

To view BHL content (e.g., books, journal volumes) I wrote my own viewer, modelled loosely on Google Books. I expressly wanted to avoid IIIF because I find IIIF viewers a terrible way to view documents, and for me BHL is all about the text.

The web site itself is a few PHP scripts to glue everything together, and I’ve tried to avoid using Javascript unless absolutely necessary. HTML + CSS is really powerful these days, so you can do a lot without resorting to Javascript.

Tour

In building BHL-Light I’ve wanted a simple interface to concentrate on displaying content as much as possible. I also wanted a cleaner interface, one that is responsive (AKA "mobile friendly").

BHL has some extraordinary content. It has works both old and new.

Text

The viewer I built makes it easy to scroll through an item, and also makes text selectable (something you currently can’t do in BHL. This means you can interact with text in the browser, such as using Google Chrome to translate part of the text.

It also opens up the possibility of annotation using Hypothes.is.

Geotagging and maps

I also demonstrated pages that had been geotagged. These tags can be extracted and used to create an interactive map.

I still haven’t decided on the best way to interact with the map. For example, should we use the map to search for content geographically, or should we search for content and display those results on a map, or both? I ran out of time to resolve this, so for now if you click on the map you see a H3 hexagon that encloses where you click. The idea is that then the page would display BHL content within that area. Other idea ideas include something like Frankenplace or JournalMap.

Document layout

For me one of the most exciting areas for the future is adding document layout information to BHL content, such that not only can we identify articles, but figures, tables, references, etc. In this way BHL could finally offer something akin to what Plazi can deliver: structured text about species. This has seemed a challenging task, but recent AI developments have been a game changer. In particular, Datalab have released powerful and simple-to-use tools that do a very good job of retrieving document structure from scanned pages. I have started to use this on BHL content and display the results on BHL-Light. For example, Datalab makes it almost trivial to identify and extract figures from scanned pages. Below is a comparsion of document layout for a page as inferred from a born-digital PDF by Plazi, and the same page in BHL where it is simply an image, but Datalab's methods have inferred which bits are text, figures, captions, etc.

One unexpected consequence of building my own image server (see above) is that the task of displaying figures by cropping page images becomes almost trivial. This idea was inspired in part by Smits et al.’s approach of cropping Internet Archive images.

What’s next?

There is much to do. BHL-Light is missing many features. It doesn’t make it easy to find content such as articles found by BioStor, the project I started over a decade ago to find articles in BHL. Search is rudimentary at best, and I haven’t tackled taxonomic names yet (but have ideas for this).

For me BHL-Light is a fun way to explore BHL, and its development has made me even more aware of all the work done to create the current and maintain the BHL portal. Apart from being a play thing for me, I am curious as to whether BHL-Light might be a way to have “BHL-mini” portals, rather like GBIF hosted portals. In this way, we could have views of BHL focused on a particular taxon, institution, person, etc., or localised by language and/or country. Perhaps we could de-extinct past projects such as BHL-Europe?

References

Page, R.D. Extracting scientific articles from a large digital archive: BioStor and the Biodiversity Heritage Library. BMC Bioinformatics 12, 187 (2011). https://doi.org/10.1186/1471-2105-12-187

Page, Roderic (2025). Future interface(s) for BHL. figshare. Presentation. https://doi.org/10.6084/m9.figshare.28777868.v1

Smits, T., Warner, B., Fyfe, P., & Lee, B. C. G. (2025). A Fully-Searchable Multimodal Dataset of the Illustrated London News, 1842–1890. Journal of Open Humanities Data, 11(1), 10. https://doi.org/10.5334/johd.284

Wednesday, February 26, 2025

BOLD View: exploring DNA barcodes

How to cite: Page, R. (2025). BOLD View: exploring DNA barcodes. https://doi.org/10.59350/81kzw-qy18

For a while now I’ve been exploring ways to navigate through DNA barcodes. Over the years I’ve built various “toys” to explore barcodes, such as Displaying a million DNA barcodes on Google Maps using CouchDB, built a small scale browser using Elastic search that had some succes, and discovered that Postgres can search for DNA sequences and it’s really fast. At the same time, I’ve bemoaned the challenges of getting barcode data into GBIF, and the current state of BOLD’s data exports.

Over the last few months I’ve been getting a project to the point where it’s usable, and today I’ve released a live version called BOLD view. Why make a portal to DNA barcodes when BOLD have themselves recently released a new version of their own portal you might ask? There are two reasons. Making my own forces me to explore the barcode data in some detail, which is eye-opening in places. The second reason is that I want to be able to explore the barcode data at various levels and in different ways. For example, I want an interactive global map of barcodes.

I want to see a DNA barcode in context, including a phylogeny that includes barcodes both within and outside the BIN the barcode belongs too.

I want to make the imagery more visible.

I want to be able to navigate the taxonomy underlying the barcodes using tools such as summary trees.

I want to be able to input a DNA search and quickly search for matches.

I also want to be able to connect the barcodes to the science behind them (who created the barcodes and what questions were they addressing?).

Abve all, I just want to be able to explore the data. I don’t want donut charts and dashboards. I want to be able to see the data and the connections. There is still much to be done, in particular I want to visualise sequence alignments. We can have a global map, and a global taxonomy, where is the global alignment?

I hope to work on BOLD view further, but for now it is out the door and my spotlight will inevitably turn elsewhere.

Tuesday, October 29, 2024

Internet Archive as a single point of failure

How to cite: Page, R. (2024). Internet Archive as a single point of failure https://doi.org/10.59350/1r3m1-c5e22

Just a placeholder to mark the ongoing impact of the Internet Archive being attacked (see here, here and here for details).

The impact of this on the Biodiversity Heritage Library (BHL) has been huge, and reveals the extent to which BHL depends on the Archive. The Archive is:

BHL’s long-term archival storage of book scans
BHL’s processing pipeline for converting images to text
BHL’s store for additional metadata (e.g., page numbers)
BHL’s image server (i.e., all the images of scanned books on the BHL website are served from the Archive)

The attack on the Archive has crippled BHL (parts are slowly coming back). I think this is time for a fundamental rethink in how BHL manages its data, its processing pipeline, and how it serves images.

Friday, October 18, 2024

Exploring BOLD's DNA barcode data releases: there's a fraction too much friction

How to cite: Page, R. (2024). Exploring BOLD's DNA barcode data releases: there's a fraction too much friction https://doi.org/10.59350/6qepn-ge510

Recently I’ve been exploring data downloaded from BOLD. Part of this was motivated by work done with David Schindel for a recent book:

In this blog post I record some struggles I’ve had with the supposedly “Frictionless” data provided by BOLD. I list a serious of issues, and make some recommendations as to how these can be fixed.

Previous versions disappear from site

The web page Data Packages lists datasets that can be downloaded.

The two most recent have the DOIs:

While this makes it easy to link to the latest version of the data, it inhibits reproducibility because the data doi:10.5883/DP-Latest points to can change, and there is (currently) no unique DOI for that particular dataset. Once a version becomes the third oldest, then it seems to get a version-specific DOI.

The list of “Historical Data” releases is not exhaustive. Currently (2024-10-17) there are four older versions listed:

However I have downloaded older versions that are no longer listed on the Data Packages web page. This makes it hard for anyone wanting to trace the history of changes in BOLD data.

Recommendation

Have distinct DOIs for latest version (i.e., in addition to “10.5883/DP-Latest”), and keep list of all releases on the web site.

Even better, switch to using Zenodo to store data, they provide a nicer model of versioning, and can also provide download metrics.

Where are the images?

A major surprise is the lack of URLs for specimen images. The imagery in BOLD is very useful, yet not included in the data export! The only way to get a list of image URLs is to get the data from GBIF(!).

Recommendation

Include images URLs in the data releases.

Column names change over time and aren’t standardised

One major source of frustration is that the labels used for the columns of data can change. This is, pun intended, a major source of friction in supposedly “frictionless” data. Code that successfully parses one dataset may fail with the new release. One could argue that the code should rely solely on the information in the data package, but there are some columns (e.g., geographic coordinates, the raw sequences) that require special treatment, and the natural language descriptions of each column are not machine-readable.

Below is a table of column names from a range of data packages from 2022-09-28 to 2024-09-06. Most column names are stable, but sometimes new ones appear, and sometimes they vanish. Core data elements, such as nucleotide sequences can change, e.g. nuc versus nucraw.

column name	2022-09-28	2023-09-29	2023-10-27	2024-07-26	2024-08-02	2024-08-09	2024-09-06
associated_specimen
associated_specimens
associated_taxa
bin_created_date
bin_uri
biome
bold_recordset_code_arr
class
collection_code
collection_date
collection_date_accuracy
collection_date_end
collection_date_start
collection_event_id
collection_note
collection_notes
collection_time
collectors
coord
coord_accuracy
coord_source
country
country/ocean
country_iso
depth
depth_accuracy
ecoregion
elev
elev_accuracy
extrainfo
family
fieldid
funding_src
gb_acs
genus
geoid
habitat
identification
identification_method
identification_rank
identified_by
identifier_email
insdc_acs
inst
kingdom
life_stage
marker_code
museumid
notes
nuc
nuc_basecount
nucraw
order
phylum
primers_forward
primers_reverse
processid
processid_minted_date
province
realm
record_id
recordset_code_arr
region
reproduction
sampleid
sampling_protocol
sector
sequence_run_site
sequence_upload_date
sex
short_note
site
site_code
sovereign_inst
species
species_reference
specimen_linkout
specimenid
subfamily
subspecies
taxid
taxon_name
taxon_rank
taxonomy_notes
tissue_type
tribe
voucher_type

Recomendation

Avoid changing the names of data columns between releases. Adopt standardised terms, such as Darwin Core, wherever possible. Tell us that these are Darwin Core by using the dwc: prefix.

Use identifiers for people

People appear in several places in the data, notably as identifiers and collectors. The BOLD data uses simple text strings (i.e., names) of people, rather than external identifiers such as ORCIDs. This means we miss out on valuable information. For example, for a 2 million sequence subset of the latest release I was curious as to who identified the most specimens. For each of these names I then wanted to find out who they were. For example, are they taxonomists? If so, what is their expertise? What taxonomic papers have they published? Where are they based? If BOLD included ORCID ids it would be easier to answer these questions. Instead, I resorted to Google and produced the following table:

Top 10 identifiers of BOLD specimens:

Name	Affiliation	ORCID
Kate Perez	U of Guelph	0000-0001-5233-1539
Angela Telfer	U of Guelph	0000-0003-1846-6362
Daniel H. Janzen	U of Pennsylvania	0000-0002-7335-5107
Valerie Levesque-Beaudin	U of Guelph	0000-0002-6053-0949
Gergin A. Blagoev	U of Guelph	0000-0003-1844-0779
Renee Miskie	U of Guelph	-
BOLD ID Engine	-	-
Brandon MONG Guo jie	Academia Sinica, Taipei	0000-0002-1673-8021
Paul D.N. Hebert	U of Guelph	0000-0002-3081-6700
Brian Fisher	California Academy of Sciences	0000-0002-4653-3270

Note that most of the top ten identifiers work at the University of Guelph, the home of BOLD. This tells us something about the degree to which BOLD is dependent on its own staff to identify specimens, versus the extent to which it has engaged the wider community.

The flip side of this is that these people are curating an important database. Are they getting credit? Is this curation making its way into Bionomia, which has mechanisms to give credit to this work.

I have also briefly looked at collector names, and it is - as one might expect - something of a mess. The same person’s name is written different ways, text strings representing multiple people are incorrectly split into individual names, etc. The description in the data package is more wishful thinking than reality:

Recommendation

Add ORCID identifiers for people who have identified specimens.

Method of identification not standardised

The value of BOLD as a tool for identifying new sequences depends on the reliability of existing DNA barcodes. How are these identified? The field identification_method is full of a mix of terms. There are all the obvious traps people fall into when not being careful with data. The same term may be spelt differently and/or is capitalised differently. People add qualifiers to a term, such as the date of identification, making it much harder to ask simple questions such as how many sequences have been identified based on their morphology, versus based on their sequences.

So far I’ve found 1889 different terms for identification method, here are the top 20:

BIN Taxonomy Match
BOLD ID Engine Manual
BOLD Sequence Classifier
Morphology
morphology
morphological
BOLD ID Engine (March 2015)
Tree based Identification(April 2016)
Morphological
BIN Taxonomy Match (Mar 2023)
BIN Taxonomy Match (May 2019)
Tree based Identification (Feb 2017)
BIN Taxonomy Match (May 2017)
BIN Taxonomy Match (Oct 2022)
BIN Taxonomy Match (Aug 2023)
BIN Taxonomy Match (Mar 2017)
BOLD ID Engine
BIN Taxonomy Match (Apr 2017)
BIN Taxonomy Match (Jun 2019)
Tree Based Identification (April 2016)

Note that we have “Morphology”, “morphology”, “morphological”, and “Morphological”. How is “BOLD ID Engine Manual” different from “BOLD ID Engine”? Note the use of dates as qualifiers.

Recommendation

Enforce a standardised vocabulary, add additional fields for date and notes on identification.

Voucher type not standardised

The description of the voucher_type reads:

This is patently false. Instead of seven terms are at least 508 for this field. Here are the top 20 terms (* indicates a term from the controlled vocabulary):

Vouchered:Registered Collection*
DNA/Tissue Vouchered Only*
To Be Vouchered:Holdup/Private*
museum voucher
E-Vouchered:DNA/Tissue+Photo*
Voucher Type: Morphological
No Specimen*
Museum voucher, whole specimen in ethanol
Vouchered:Private Collection
Museum Vouchered:Type*
Museum Vouchered:Type Series*
Museum voucher, Whole specimen in ethanol
Museum voucher, whole specimen
Museum Vouchered
Museum voucher, e-voucher
Museum voucher, Whole specimen
Museum voucher, E-vouchered with additional representatives stored in ethanol in parent lot
vouchered: not registered collection
Museum voucher, E-vouchered with additional representatives stored in ethanol
in alcohol (ethanol, 96%)

Recommendation

Enforce the existing controlled vocabulary.

Institutions lack identifiers

Institutions are listed by name. As with any string, there is the potential for different spellings and formatting. Anyone interested in getting metrics for institutional engagement with BOLD, and comparing that to, say, sources of funding, would much rather have identifiers than strings.

Here are the top 20 institutions:

Centre for Biodiversity Genomics
University of Pennsylvania
Area de Conservacion Guanacaste
Mined from GenBank, NCBI
Canadian National Collection of Insects, Arachnids and Nematodes
SNSB, Zoologische Staatssammlung Muenchen
Australian National Insect Collection
University of Malaya, Museum of Zoology
Instituto Nacional de Biodiversidad, Costa Rica
Royal Ontario Museum
California Academy of Sciences
NEON Biorepository at Arizona State University
Research Collection of M. Alex Smith
Smithsonian Tropical Research Institute
University of New Brunswick, Fredericton
York University, Packer Collection
Wellcome Sanger Institute
Smithsonian Institution, National Museum of Natural History
Natural History Museum, London
University of Oulu, Zoological Museum

Recommendation

Add external identifiers for institutions such as RORs.

Summary

Some of these issues raised here are easy to fix, other will require a lot of curation. I suspect that part of the problem is that there’s no evidence that BOLD itself makes use of these data dumps. If you view data exports as somethign you are “supposed to” do, rather than something that you yourself use, then there’s no incentive to make sure the data is fit for purpose. Eating your own dog food is a great way to avoid these problems.