Language models model languages. The simpler the language, the simpler the model. Large language models (LLMs)\ndo more: they do not merely capture a language, but also model what you can say with them. And you can\nmap one model to another, and use that to translate things between langauges. Have a numerical representation,\nand you can have your LLM run on a processing unit (CPU, or more likely, GPU).\nMore and more models are available (mostly proprietary, commercial) to use this. Chat bots, translation\ntools, grammar checkers, generative models. And because of the numerical representation, it is also\neasy enough to combine language with numerical data.
\n\nAnd I guess converting a SMILES to something else should not surprise me. Using SMILES as molecular\ndescriptor has been around for some time. Using a generative model to generate an IUPAC name is another\nexample. STOUT had been doing that for some time (doi:10.1186/s13321-021-00512-4).\nBut based on deep learning, it is based on probabilities. Or recovering SMILES strings from\nMorgan fingerprints (doi:10.59350/srwee-de037).
\n\nThe alternative is to generate IUPAC names using the IUPAC rules. Computational tools that do this have\nbeen around for a long time. The IUPAC naming rules are defined in the blue books, see\nthis page. At some point in the nineties, based on the\nwork of the Woordenboek Organische Chemie, I proposed to make a HTML version of the Dutch translation.\nThe never happened.
\n\nNow, these LLMs have become quite powerful that they can do a ton of things. They can without problem\nuse external tools. That makes a lot of sense: why would you predict something when you can look it up\nor easily computer. That helps with exact validation. For example, Claude is said to validate JSON to\nmake sure it never outputs JSON that is not valid (which it does without that validator).
\n\nSo, why not translation the IUPAC rules into a program and use that program to deterministically calculate\nIUPAC names? Or even Preferred IUPAC names (PINs)? Wikidata wants those. The lack of a tool to\ndetermine if a name is a PIN or to just calculate it blocked\nthe addition of a Wikidata property earlier this year.
\n\nNoel O’Boyle (now EMBL-EBI) found and\ncompared three open source tools,\neach with a matching preprint: NISPO (doi:10.48550/arXiv.2607.26113),\nOpenClatura (doi:10.26434/chemrxiv.15006114/v2),\nand Orthonym (doi:10.26434/chemrxiv.15009769/v1).\nThey yield 85-95% valid IUPAC names, as reported in Noel’s blog post. Of these, Orthonym by default\nreturns PINs and then the yield is a good bit lower.
\n\nA fourth tool is mentioned in the blog: smiles-to-iupac,\nbut no compared. The author of this tool, Inwan Yoo, has been actively\ncontributing to\nthe OPSIN tool.
\n\nThere is much to like about this, even the “competition”. These projects will be compared.\nWhere the differ, it will highlight where all tools have it wrong, some of the tools,\nand even none of the tools, and the IUPAC rules turn out to be “wrong” (more likely, ambiguous).\nThe same for OPSIN (doi:10.1021/ci100384d). I think this is a win for the open science chemistry community and\nlooking forward to what will happen in the next few months.
\n\nAnd, I will need to find some time to see how many Wikidata SMILES I can convert into PINs.
\n\n