With this letter we take a principled stand against the proliferation of so-called ‘AI’ technologies in universities. As an educational institution, we cannot condone the uncritical use of AI by students, faculty, or leadership. We also call for reconsidering any direct financial relationships between Dutch universities and AI companies.The unfettered introduction of AI technology leads to contravention of the spirit of the EU Al act. It undermines our basic pedagogical values and the principles of scientific integrity. It prevents us from maintaining our standards of independence and transparency. And most concerning, AI use has been shown to hinder learning and deskill critical thought.

These few lines contain for me more than 25 years of research and I know the complexities. Before I can co-sign this letter, I need to understand the details. There is no definition of ‘AI’ here and it mentiones the EU AI Act (I guess, the letter actually writes “Al” (with an l of letter) act, I notice now after I read the content in another font), but I have not read the EU AI Act yet (it is 144 pages of legal text).

The legal context of the Open Letter

Let me first say, I am not a lawyer (IANAL). I am not versed in the specific legal definitions of tightly defined and controlled words.

Reading the EU AI Act, I read a reassuring opening statement (repeated later with more context, links to other laws, etc):

to promote the uptake of human centric and trustworthy artificial intelligence (AI) while ensuring a high level of protection of health, safety, fundamental rights as enshrined in the Charter of Fundamental Rights of the European Union (the ‘Charter’), including democracy, the rule of law and environmental protection, to protect against the harmful effects of AI systems in the Union

We clearly see how these things are currently routinely violated.

This Regulation does not apply to AI systems or AI models, including their output, specifically developed and put into service for the sole purpose of scientific research and development.

In Dutch this is officially translated to “wetenschappelijk onderzoek”, so scientific research seems to be legally including humanites, etc, and not limited to natural sciences [citation needed].

The EU AI Act also outlines a definition of “AI”, leaning towards machine learning, but the border between deterministic, rule-based algorithms and machine-learned patters for predictions remains a bit vague to me. But I can live with it.

The Open Letter’s contravention of the spirit of the EU Al act gets context here too. It has to be the spirit, because the law does not apply to academia. Good, clarified. The Letter continues with:

It undermines our basic pedagogical values and the principles of scientific integrity. It prevents us from maintaining our standards of independence and transparency. And most concerning, AI use has been shown to hinder learning and deskill critical thought.

Yes, that clearly links to the EU AI Act’s protection of rights. Maybe on purpose and maybe there are legal reasons to not explicitly list them, are the international human rights, which includes rigths to benefit from science, but I think this is still in the spirit of the EU AI Act. And if AI fetters our ability to learn (yes, there is scientific evidence for that [citation needed]), then it violates the EU AI Act (IANAL).

What the Open Letter expects

The next part of the Open Letter calls to what the signers expect from our universities. I will will reflect on each of them.

Resist the introduction of AI in our own software systems, from Microsoft to OpenAI to Apple. It is not in our interests to let our processes be corrupted and give away our data to be used to train models that are not only useless to us, but also harmful.

The intrinsic problem and why I think it is fair to call out these companies, is, as the letter explains, there is an clear conflict of interest. The goal of companies is to make profit (and in a Western world, as much as possible), and not any of the human or scientific needs. In this respect, companies like Elsevier could just as well have mentioned too (see e.g. this post by Prof. Van Rooij, actually 2nd signature on the letter).

Ban AI use in the classroom for student assignments, in the same way we ban essay mills and other forms of plagiarism. Students must be protected from de-skilling and allowed space and time to perform their assignments themselves.

About a year ago, I was pleasently surprised by the depth of discussion at Maastricht University on how and when to use AI, and by default not. This one is really complicated and it matters when and how the AI is used. After all, and the spirit of the EU AI Act expects us to use AI in research (to trigger innovation). So, I cannot agree with the literal statement, but I fully agree with the spirit. Particularly combined with the clear “Stop the Uncritical Adoption of AI Technologies in Academia” of the title of the Open Letter.

I read this line like this, AI in the classroom must have a purpose that aligns with the EU AI Act. That means, use for writing assays, reports, it must not be used. I am old enough that remember the academic discussions (at Radboud University) about writing and the clear hesitance among scholars about the use of written assignments: “I want to test their scientific knowledge and reasoning skills, not their ability to write narratives”. And LLMs, like ChatGPT but also the European, more open variants, they write narratives, so the written report and assay is no longer a valid way to assess a student’s scientific learning progress.

So, alternatively, we should very carefully and scientifically evaluate which forms of assessment we perform, and banning AI in the classroom may just be distracting from a more fundamental problem. Anyways… if you continue using writing assignments to test progress in learning, you must ban use of AI in that process. You must be testing the student, not some piece of software (as a teaching institute).

Cease normalising the AI hype and the lies which are prevalent in the technology industry’s framing of these technologies. The technologies do not have the advertised capacities and their adoption puts students and academics at risk of violating ethical, legal, scholarly, and scientific standards of reliability, sustainability, and safety.

Sounds like a no brainer. But I too find my own university uncritically promoting AI. Maybe the tested it well, and just forgot to share that. But hey, scientifical quality goes all ways.

Fortify our academic freedom as university staff to enforce these principles and standards in our classrooms and our research as well as on the computer systems we are obliged to use as part of our work. We as academics have the right to our own spaces.

Again, a no brainer. But important to add. It must be said as it is intrisic part of Recognition & Rewards. If you cannot guarantee academic freedom, there there is something seriously wrong with your R&R.

Sustain critical thinking on AI and promote critical engagement with technology on a firm academic footing. Scholarly discussion must be free from the conflicts of interest caused by industry funding, and reasoned resistance must always be an option.

Yeah, this is something that is underestimated. Part of our academic teaching is this critical thinking. It returns in academic reading (did you already read “What Little Red Riding Hood Can Teach Us about Reading Science”, doi:10.1515/9783110782844-010, by Monica Gonzalez-Marquez et al.?), scientific programming, data analysis, and our teaching has been lacking here. Not just for new AI forms, but also for the old algorihmts. I have seen this, and scientific literature is riddled with mistakes, just because our peer reviewers are not sufficiently skilled. This will take effort. I know, it was a major part of my PhD thesis.

Of course, this is exactly why I have been so active in Open Science. Without Open Science, we cannot work in the spirit of the EU AI Act. It’s nothing new. It’s just that the big money has found in AI a way to profit at the expense of humans.

So, go read that Open Letter and sign too!

So, when propagating chemical structures from the Beilstein Bioschemas feed, I was looking for names, IUPAC or not, ideally the name used in the article. When I asked about this, the question came up if they could autogenerate IUPAC names, for which various new tools exist (I think I am missing one from an American team, but cannot find the reference), along with multiple established commerical tools. Because the IUPAC nomenclature is a long list of naming rules, priorities, etc, a rule-based algorithm is logical, but newer methods take a deep-learning approach.

Back to the chemical annotation of chemistry literature. This is of obvious interest: you want to know where we can read more about a certain chemical. We need the chemical structures in a database for that, linked to the articles. This is, of course, one of the original studies of cheminformatics. And when authors of the chemical literature do not provide this routinely (this post shows a few exceptions, but it is still all too rare). And then manual and automated curation is needed, e.g. done by Chemical Abstracts.

Third, Wikidata has about 1.4 million chemical compounds and many names. A property propoal for IUPAC names has been long pending, but once accepted in one form or another, will require IUPAC names too.

One million IUPAC names

Thus, the idea came up, can we create a set of 1 million unique IUPAC names found in literature? I asked on the ELIXIR Europe slack channel if Europe PMC had such a dataset (doi:10.1093/nar/gkad1085). I knew they had been adding chemical named-entity recognition (NER) results in their annotation API. I learned they used ChEBI. Melanie Vollmar and Summer Rosonovski or Europe PMC gave useful information and support. Magnus Palmblad also replied and provided Python code to use the Europe PMC API to fetch names it returns and see if those are IUPAC names. Well, that’s easy. We have OPSIN for that (see doi:10.1021/ci100384d).

Unfortunately, the Europe PMC NER results are not ideal for IUPAC names. Just scanning some 5, 6 organic chemistry journals returned some 8 thousand IUPAC names in open access articles. But it quickly started to be too limited: each set of articles returned increasingly few new names. The reason is simple: the NER is too greedy and as a result, does not easily recognize longer IUPAC names. It is too happy with a substring of the IUPAC name. For example, when it encounters the IUPAC name 5-Bromo-1H-indole-3-carboxylic acid, it settles for indole-3-carboxylic acid:

Open-Source Chemistry Analysis Routines

During my PhD, in 2003, when I worked a few months with Prof. Peter Murray-Rust (University of Cambridge) and Prof. Janet Thornthon (EMBL-EBI), I learned about the research by Sam Adams (doi:10.1039/B411699M), Joe Townsend (doi:10.1039/B411033A), and Peter Corbett (doi:10.1007/11875741_11). One of the tools that used this research was (is) OSCAR, short for Open-Source Chemistry Analysis Routines (see this detailed write up by Peter MR). Later, in 2010 I visted Peter again, as postdoc, in Cambridge, and then worked on the OSCAR project too. And while OSCAR did a lot more, the integration of Corbett’s NER research made OSCAR the obvious follow-up step in finding IUPAC names in literature.

And because OSCAR4 had been integrated into Bioclipse (doi:10.1186/1758-2946-3-41) and I had this ported to Bacting already (doi:10.21105/joss.02558), using this was trivial. The use of Europe PMC is different now, however, and we are no longer using the Annotations API, but just using it to find open access articles, and to get the full text in XML format. That allows a simple XPath search on <p> elements, pass the resulting string to OSCAR4, and the recognized names are checked with OPSIN. And with this approach, processing two of the five or six journals we earlier explored, we find another 40+ thousand IUPAC names. Quite a success, I am tempted to say.

A Blue Obelisk project

So, I started a new Blue Obelisk project, iupac-names, to collect 1M IUPAC names. For researchers to use, learn from, etc. Just IUPAC names. Not even the chemical structure, nor the link to the articles. The first is trivial to do with OPSIN, so the matching SMILES do not need to be stored. Links to literature is tricky because of the aforementioned issues, and we only want to know which (partial) IUPAC names occur in literature. If you really want to know in which articles that IUPAC name is found, you can simply do a search in Europe PMC.

And because we only store IUPAC names, this are very basic facts (this is an IUPAC name, as defined by OPSIN being able to generate a SMILES for this structure) and that that string occurs in some article) and we can share them as CCZero. We defined various milestones, and I am happy that the first two have been reached within two weeks:

• Milestone 10k (doi:10.5281/zenodo.14965762)
• Milestone 50k (doi:10.5281/zenodo.14978557)

This second milestone has 53848 unique names, but as literature goes, there are interesting variations, some likely because of typesetting leading to spaces added and missing. If we ignore spaces and hyphens, we have 50534 names left (hence the milestone). But IUPAC names are also not fully unique, partly because of Unicode character variations and greek letter alternatives, and you may wonder how many different chemical structures this set reflects. While not perfect, the Standard InChI gives some lower limit, and we find 36528 InChIKeys in this second milestone.

Now, we need twenty times as much to reach the 1M IUPAC names, but given we have many, many more open access articles to process. The bottleneck seems to be mostly our workflow.

Can you contribute?

Yes, of course! This is an open science project. But please keep in mind the narrow focus of this project: only IUPAC names which can be found in (open access) literature. This project doed not accept autogenerated names (PubChem would have given use many millions already), nor IUPAC names from existing databases. Ideally, you are able to show the code you use to extract/find those names in literature.

Can I use these names?

First of all, this is what the CCZero license and open science nature of this project is about: reuse. We love to hear how you are using these names, tho, and we encourage you to write up how you are using them. You can use DataCite to cite the release you used, and citing this blog post by DOI is also possible.

Does it support my language too?

No, at this moment it only support IUPAC names in English. Dutch, French, Spanish, or Chinese IUPAC names are valid, but currently not supported. See also this post.

Will there be a publication?

Magnus and I intend so. We already submitted an abstract to the International Conference on Chemical Structures, which has a Collection in the Journal of Cheminformatics. If the abstract gets accepted, of course, we can submit there. Otherwise, we will look for another venue, likely diamond open access.

Where is your script?

Ah, fair point. We did not decide on the final license yet. I have used two scripts based on the template by Magnus. As soon as we have finalized the license, we will make those available.

But I did find we have been blogging about our work a lot. Searching for Rich gives false positives, but plenty of discussions of his work. At the same time, my name shows up multiple times in Depth-First too. Looking back at our shared history, we find, for example, Rich has blogged a lot about using the Chemistry Development Kit in Ruby .

Rich blogged about a lot of cheminformatics innovation. For example, in 2006 he was working on multi-atom bonding , such as in ferrocene, something that is even today not routinely used in cheminformatics. I replied to that in this post. Another thing he explored was embedding chemical graph notations in PNG images. In 2007 he wrote how to Never Draw the Same Molecule Twice: Image Metadata for Cheminformatics . This was picked up by several others, including me with an implementation in JChemPaint.

Another tool that I really liked was his Chempedia which collected “[f]ree chemical information resources created and reviewed by chemists”. One of the things it did was link chemical names to chemical structures, e.g. for this compound . And because of the open license I was able to generate an RDF representation of Chempedia. This resulted perhaps in one of my first online SPARQL endpoints.

One and a half year ago he was confronted with health issues . Rich blogged openly about the months after that. Rereading this post is still hard, having seen cancer in action on my mother. It turned out to be cancer, a brain tumor . Just this Thursday I attended a fascinating ²H NMR presentation, showing how much better we got at recognizing tumors, but Rich’ MRI was obvious. He blogged for months on his plan. Until the end of May this year.

Some weeks ago I received confirmation our fear; he passed away. Richard L. Apodaca was born in 1968, completed his PhD at the University of Texas at Austin in 1996 on Studies in enantioselective catalysis: (1) a new class of chiral C₂-symmetric bisphenols; (2) Diorganotin dihalides (wikidata:Q131405461). Rich published multiple papers in the field of medicinal chemistry (see his Scholia profile), was very active in open science and held many patents. His latest work was about Balsa: A Compact Line Notation Based on SMILES (see doi:10.26434/chemrxiv-2022-01ltp).

The Depth-First blog has a CC-BY 2.0 license and perhaps Rogue Scholar can archive it? It helps us remember Rich and his contributions to open science cheminformatics.

Sadly, the meetings was still during the (partial) lockdown, and I think my contribution could have been more extensive. But I am happy I got to pitch the idea of using Wikidata in this area too, taking advantage of the work done by the LOTUS (doi:10.7554/eLife.70780) team earlier.

And this is key to me: you cannot do statistics, chemometrics, machine learning, or artificial intelligence without good quality linked data. Happy reading!

Each data set comes with an index pointing to the individual nanopubs, and that looks like this:

I wonder what options I have to to archive the full set up nanopublications on Figshare or Zenodo, and see that DOI show up here…

With this major provider of Linked Open Data for chemistry now published, I should soon see where my Isbjørn stands. The release of this publication is also very timely with respect to the CHEMINF ontology, as I last week finished a transition from Google to GitHub, by moving the important wiki pages, including one about “Where is the CHEMINF ontology used?”. I already added Gang’s paper. A big thanks and congratulations to the PubChem team and my sincere thanks to have been able to contribute to this paper.

Update: Mark wrote up a blog post on the RDF that the ChEMBL team itself.

Yesterday, the paper “The ChEMBL database as linked open data” (doi:10.1186/1758-2946-5-23) by Andra Waagmeester (@andrawaag), Ola Spjuth (@ola_spjuth), Peter Ansell (@p_ansell), Antony Williams (@chemconnector), Valery Tkachenko, Janna Hastings, Bin Chen (@binchenindiana), David J Wild (@davidjohnwild), and me appeared in the OA JChemInf journal.

I am also indebted to the ChEMBL team (@chembl) for both providing such valuable data under a liberal Open Access license and their critical reading of the manuscript! Additionally, I would like to stress that the ChEMBL team will create their own RDF version of ChEMBL and that this paper is not describing the version they will release.

BTW, the source of the paper is available from GitHub. And the (original) scripts to create RDF from the MySQL dump of ChEMBL are also on GitHub.

This paper outlines the RDF as it has evolved from various earlier projects. The above diagram visualizes the basic structure (red), various Linked Data resources linked too (blue) and illustrates how various ontologies are used, such as the CHEMINF, BIBO, and CiTO ontologies.

Additionally, various applications and links are described developed by various co-authors. For example, Peter worked on the use in Bio2RDF and Bin and David on Chem2Bio2RDF. Andra developed an extension for his (#altmetric) CitedIn resource, giving credit to a paper when data in it is extracted into ChEMBL. Ola, Valery, and Anthony developed a Bioclipse Decision Support extension, which supports a nearest neighbor search in ChEMBL using ChemSpider. Of course, Ola also hosts the SPARQL end point of which you can monitor the uptime at the also cool mondeca.com service:

(Yes, I think I have all the cool buzzwords covered in this paper. Sadly, marketing is needed nowadays as a scientist. Where is the time that you could rant on page after page in all your domain specific jargon, not having to worry if your reader would understand it immediately, or without a university degree…)

What this paper does not describe, is all the things I did with ChEMBL-RDF in the Open PHACTS project (@Open_PHACTS), which includes the use of QUDT and the jQUDT library for unit normalization outlined in this document and the use of VoID for link sets as described in this document.

Last week, ChEMBL 13 was released, with even more data, data fixes, etc. Since my RDF for ChEMBL 09 my workflow has become more solid and uses more common ontologies, started using more common ontologies and ontologies I just like, such as CHEMINF and CiTO. Below is an overview of the resource types present in the RDF: activities (almost 7M now), chemical entities, assays, targets, and documents.

The data on Kasabi will be updated soon, and the SPARQL end point hosted by Uppsala University was updated yesterday, including the SNORQL frontend:

The new data is not fully backwards compatible. The changes to the RDF include the use of cito:citesAsDataSource, more typing using existing ontologies, e.g. with cheminf:CHEMINF_000000 and pro:PR_000000001 from the PRotein Ontology.

A paper dedicated to the ChEMBL-RDF is in preparation. Existing use cases can be found here.

So, this new edition is again thicker, summing up to 152 pages now, which is 28 pages more than the 3rd edition . Indeed, the table of contents is more than half a page longer in itself, though, just barely, still fitting on four pages. In fact, I had to remove one (new) subsection title, because it would take otherwise two further pages.

The new content is again a mix of sections and chapters. While writing new chapters, I find myself realizing I need to cover more basics. Those get typically added as new sections. I did not get many feature requests, except for one email pointing me the text promised how to interpret and handle failing atom type perception, which explains one of the new sections. The full list of new content is:

• Section 2.1.4: explaining the three flavors of atomic coordinates
• Extended Section 2.2: added detail about electron counts of bonds (partly in reply to this post by Rich)
• Chapter 5 “Protein and DNA”: four pages, mostly about PDB files, and the matching CDK data structure
• Chapter 6 “IChemObjectBuilders”: four pages explaining the four alternative builders CDK 1.4.7 has
• Section 7.8: a new section with recipes on how to post-process read input, discussing MDL molfiles only now. It talks about what information is present in the file format, and what steps must be untertaken to add missing information
• Section 8.2.4 “No atom type perceived?!”
• Section 11.4: describes how to depict aromatic rings
• Section 11.5: describes how to change the background color of depictions
• Section 13.4: explains how to calculate the Van der Waals volume of molecules
• Section 18.1.3: discussing the API improvement in the iterating readers
• Appendix C: a list of all descriptors provided by the CDK
• Appendix D: a list of file formats known by the CDK, indicating which has readers and writers

On top of that, I improved other bits of the book too, such as the resolution of the depictions of molecules, as well as those of various diagrams. Also the number of scripts has seriously gone up, from 94 to 134!

Appendix C is a prelude to a chapter I am already writing, but did not get finished yet: a chapter about descriptor calculation. But since I just started a new post-doc position, it may take another six months for that chapter to make it into print.

The paperbak is available from Lulu.com, an on-demand publisher, as well as this ebook version.

I am starting to get the hang of this publishing soon, publishing often thing, and just uploaded edition 1.4.1-0 of the Groovy Cheminformatics book. The cover is the same (with one typo fix), and the content is 20 pages thicker. True, six of those pages are isotope masses of all natural isotopes. That leaves 14 pages with this new content:

• Section 2.7 on line notations with 2.7.1 about reading and writing SMILES
• Section 6.3 about Sybyl (mol2) atom types
• Section 7.4 on atom numbering with 7.4.1 on Morgan atom numbers, and 7.4.2 on InChI atom numbers
• Chapter 9 on molecule depiction with the new rendering code, with
  • Section 9.1 on drawing molecules,
  • Section 9.2 on rendering parameters, and
  • Section 9.3 on the generator API and how to add custom content
• Section 11.4 on calculating aromaticity
• Appendix A.2 listing all Sybyl atom types
• Appendix B listing all naturally occurring isotopes

Features requests most welcome.