Open source IUPAC Name generators have something in common with buses; you wait forever for one, and then three come at once.
I am talking about NISPO, OpenClatura and Orthonym, which were released in quick succession over the summer/autumn, together with preprints that are likely destined for a journal near you. These were developed by Nicolas Runcie/Charlotte Deane (Oxford), Rostislav Fedorov/Adrian Mirza/Kevin Maik Jablonka (Helmholtz Jena/Berlin), and Kohulan Rajan/Achim Zielesny/Christoph Steinbeck (Jena), and at their essence they take a SMILES string and produce an IUPAC Name.
Many readers will be familiar with OPSIN, maintained by Daniel Lowe (and hosted online by my team), which has been around for a while and does the opposite transformation from IUPAC Name to structure; in fact, "NISPO" is "OPSIN" backwards :-). There are a small number of commercial IUPAC Name generators (one less now, with Revvity's purchase of ACD), but until this year nothing usable in the open space; previous open approaches have used transformer models to directly translate between SMILES and IUPAC Name, but these require a large training corpus and no sufficiently large open corpus exists (though see this set we extracted from patents).
If it's not obvious, the reason that three independent programs have arisen this year to generate IUPAC names is because frontier AI models are only now able to tackle problems of this complexity. NISPO, OpenClatura and Orthonym were developed independently (as far as I know), and so present an interesting glimpse into how the same problem lends itself to different solutions.
I'm not going to go into the details of each approach, nor am I going to compare features and so forth. Instead, I will do my own biased comparision of the coverage of these tools, and make some judgements about the quality of the names. So recall vs precision in a sense, or quantity vs quality. Before we begin, I note that these tools are under active development and at least one has made several releases to address bugs/features since I did this work. With this in mind, let me state that I am testing NISPO 0.1.7, OpenClatura 0.3.1 and Orthonym 1.0.7.
I am interested in the IUPAC names that biologists might want to see. To this end, my starting point is a set of IUPAC names extracted from PubMed Abstracts by LeadMine. I retain only those that OPSIN can parse and that are not indicated as ambiguous by OPSIN. This latter is important because we are going to be comparing to these extracted names later, and we want to make sure that the names and the SMILES strings have a 1:1 correspondance. All names resulting in the same SMILES were collated yielding 341,943 SMILES strings (with associated names).
Coverage
Let's start with how many names were generated.
| NISPO | OpenClatura | Orthonym | |
| For how many was an IUPAC name generated? | 336167 | 313588 | 193936 |
| ...that was read by OPSIN? | 333468 | 312068 | 192920 |
| ...considered unambiguous by OPSIN? | 327458 | 311878 | 192795 |
| ...where InChIs agreed? | 319327 | 292223 | 192785 |
Clearly Orthonym doesn't currently cover the same range as the other two; it has focussed on organic molecules. Regarding the other two, NISPO has the edge on OpenClatura.
Quality
For any non-trival molecule, many different IUPAC names can be written, some of which are more painful than others. For example, ethane could be written as 1-methylmethane [1]. This is definitely not a Preferred IUPAC Name (PIN), but it's an IUPAC name just the same. How can we compare the generated names along this axis? First of all, we'll assume that shorter is better. Secondly, we'll assume that fewer locants is better. Finally, we can check whether the generated names match any found in a PubMed Abstract for that SMILES string. Let's start with this final test, and extend the table above:
| Does the name match one of the original names? | 8974 | 28439 | 30316 |
Despite the lower coverage, Orthonym is generating names that best recapitulate the original name. OpenClatura is not far behind, but has many more chances to do so, while NISPO names are least likely to match the original.
For the name length and locant count comparison, we will restrict ourselves to the subset of 187489 entries where all three generate a name. If we consider the net pairwise comparison (i.e. X > Y minus Y < X, ignoring X = Y), then the original name is shortest and has the fewest locants. In terms of length, NISPO > OpenClatura > Orthonym (shortest). For locants, the original name has the fewest; for the others it's NISPO = OpenClatura > Orthonym (fewest). [2]
Slow cases
I experienced a small number of very slow cases for each software (which I caught with timeouts of 10s): 8 for NISPO, 14 for OpenClatura and 3 for Orthonym. The NISPO cases were around highly-branched symmetric molecules, while Orthonyn and OpenClatura's cases were highly-conjugated systems. I have reported all of these to the developers.
Concluding remarks
It's great to see three different writers developed in different ways and having different characteristics. Each will be able to use the others to identify strategies to improve quality or coverage as the case may be. It's very much early days and these tools are still in active development with versions released since I started looking into the comparison in early Sept.
The development of these three tools has been enabled by OPSIN; at the same time they are limited (at least in terms of round trip evaluation) to whatever OPSIN supports which, while extensive, is not exhaustive. OPSIN itself could perhaps benefit from a 'strict mode' on reading so that writers are forced to constrain themselves to strict IUPAC names. I think we are about to see a period of improvements to OPSIN in tandem with the development of these tools as each challenges the other. This seems to be already happening with the contribution of support for phane nomenclature by the author of...wait a sec...yet another IUPAC name generator?!! [3]
Footnotes
[1] I'm proud of the "1-". The "methylmethane" is an okay example, but the "1-" is the cherry on top that really grinds the gears of a chemist.
[2] I have thought about providing the original matrix of values, but you'll just find it confusing - I do myself each time I look at it.
[3] I thought about including this one also in the comparison but there's no associated preprint, and so it might not be ready. Also, at this rate, I'll never get this blog post out if I keep stopping to include new IUPAC name generators!
