Co-creation

The project is still running another few months, but the launch last week gives us the opportunity to include feedback from the stakeholders from the Dutch society, many of which have been involved in the project via designathons and hackathons (see doi:10.14573/altex.2407211).

The VHP4Safety platform is a co-creation created by most of the people working on the VHP4Safety grant. Some people focused on innovation and education (RL3), others on the regulatory questions (RL2), and some on the development of the platform (RL1). The research line 1 (RL1) included a work package on the technological development, work package 1.1, and that was led by Maastricht University (Ozan and me) and the Applied University of Utrecht (Dr. Marc Teunis). This project would not be together without the leadership by Prof. dr. ir. Juliette Legler, Dr. Cyrille Krul, and Prof. dr. Anne Kienhuis (see this video).

Not just technology

I have to give a huge shout out to Ozan whom had the daunting task to set up something like OpenRiskNet (doi:10.1016/j.toxlet.2018.06.617), a project with at least twice as much funding for operating and documenting just the technical platform, but also help other partners getting their work on the platform. Also shout outs to Luc who in our group first explored how to translate the OpenRiskNet platform to VHP4Safety with kubernetes from which we concluded that that was not an option for us. And to Sean in our group who introduced us to Docker Swarm.

But that is just one aspect of the technological layers. The design outlined in the original proposal is based on earlier projects, including OpenRiskNet, eNanoMapper, OpenRiskNet, Open PHACTS, NanoCommons, SbD4Nano and many others. It is based on open standards developed and/or adopted by ELIXIR Europe projects and many other organisations.

And then we have not even covered the content on the platform.

A virtual human

Building full virtual human is an ambition. Many digital twins capture just one part of human biology. For safety assessment we need many models, data from experiments, and knowledge bases. And we need a clear narrative that describes how those isolated solutions are integrated so that regulatory questions can be answered. That co-created combination is the launched virtual human platform.

Underlying the VHP is a good bit of open science, though it also integrated proprietary solutions, currently needed to be able to replace animal testing. And our modular co-creation resulted in many separate git repositories. This allows distributed development models and all contributors to take ownership of the development of their contributions. Marc and Frank introduced a agile computing approach that we adopted to guide the development of the full platform.

There is so much to write up about the platform (and we will), but for now I want to highlight a few essential git repositories underlying the 1.0 version of the platform we launched last week (along with the number of contributors in the past two years):

• virtual-human-platform (10 contributors): software that provide the platform UX
• cloud (11 contributors): collects the meta data about (computational) services
• ui-casestudy-config (7 contributors): collects the details of the narratives of the case studies

This includes Aniek, Fabian, Isaac, Ivo, Javier, Jente, Linde, Marvin, Myrthe, Saad, Shakira, and Youp, in addition to the earlier named Ozan and Marc.

This excludes the many contributions via the designathons and hackathons that are behind many of the commits to these repositories. And this also excludes the many other source code repositories for tools and services developed and made available on this VHP, with even more researchers.

Very much aware of all the work that is still ahead of us, I am happy with the important milestone of this release. Thank you to everyone who contributed to this co-creation, all the involved institutes, NWO for the funding, and the Dutch public for the important NWA question.

The project delivered!

References

• 10.14573/ALTEX.2407211
• 10.1016/j.toxlet.2018.06.617

In a recent paper, Yojana Gadiya, Javier Millán Acosta, and Tooba Abbassi-Daloii led a project called BioDataFuse (worked on at the biohackathons of ELIXIR in 2023 and 2024 and of SWAT4HCLS in 2024 and 2025) and the matching Python package, pyBiodatafuse (doi:10.1093/bioinformatics/btag064).

With a group of researchers from The Netherlands, Switzerland, Czech Republic, and the USA, multiple databases are wrapped in a uniform data model. The package allows the generation of a graph across the imported databases which can then be further analyzed and visualized. This is an example (RDF) graph that was generated:

Seeing this kind of interoperability brings back good memories.

Congrats to all authors!

References

• 10.1093/BIOINFORMATICS/BTAG064
• 10.37044/OSF.IO/MHSQP
• 10.37044/OSF.IO/PTMG5_V1

The FIP is a collection of FAIR implementation choices made by a community of practice for each of the FAIR Principles.

In the early GO FAIR days, people referred to the challenges and choices. FIPs are a formal approach to report the choices. The days of the implementation networks, like the Chemistry Implementation Network (doi:10.1162/dint_a_00035), or the AdvancedNano network (doi:10.1016/j.impact.2024.100513). For the first, we absolutely agreed on the InChI, for example, but we never wrote that down as a FIP. But even without FIPs, the idea was that communities could learn from each other, could converge. This is where the term FAIR Convergence Matrix comes from. (I had forgotten I was actually part of the matching Working Group. If only I had dedicated funding for it at the time.)

Now, I had on my wishlist to write up a list over FIPs around chemistry. This is relevant for the FAIR4ChemNL project, but obviously beyond that. And while we did a lot of FAIRification work in, particularly, the nanosafety cluster projects (eNanoMapper, NanoCommons, NanoSolveIT, RiskGONE, and SbD4Nano), a lot of this never was formalized as FIPs. Second, various relevant standards have been proposed in chemistry, for chemical compounds and transformation products, among plenty of other things. But during the first ELIXIR Toxicology Community workshop in Utrecht, we had FIPs on the agenda too (see this report).

FIPs in Chemistry

But while I had already several browser tabs open for months, I never could find the courage to start making the list. Silly. Therefore, this list should be considered a start. I don’t think it is exhaustive. I know there is an index somewhere, but I cannot find back that browser tab. Additions are most welcome: I will update this post (thanks to git and Rogue Scholar). In brackets I list (a selection of) the FAIR enabling resources mentioned in that FIP.

• Adverse Outcome Pathways FIP (DOI, AOP Wiki ID)
• Toxicogenomics (ISA-Tab, BioStudies, ArrayExpress)
• WorldFAIR WP04 NANOMATERIALS FIP01 (DOI, ORCID, UUID, ROR, InChI, DataCite, QMRF, RDF/JSON-LD, OWL; doi10.5281/zenodo.7378109)

Is that all? No, I do not think so, but this is all I can easily find (ironically). Well, I guess you now see why I have had a so much trouble starting to write down this post… Someone will surely give me some pointers…

Ackknowledgments

I also like to thank all the people involved in these FIPs. I strongly encourage you to look up all the people who wrote them down. I also like to thank the INTOXICOM workshop FIP experts Iseult Lynch and Gerhard Burger for sharing their knowledge.

Finally, I recommend checking out the FIP Wizard.

References

• 10.1162/dint_a_00035
• 10.1016/J.IMPACT.2024.100513
• 10.37044/OSF.IO/UN2RW
• 10.5281/zenodo.7378109

Thus, the idea came up, can we create a set of 1 million unique IUPAC names found in literature?

We started out with using Europe PMC to get JATS XML files for the full texts of open access articles. Parsing the XML is easy and the text paragraphs are passed through OSCAR and OPSIN. That has not changed.

What did change last weekend is something I had long on my todo list (but life interfered). The first approach was to ask for named entities using the Europe PMC APIs. But I quickly realized that with OSCAR and OPSIN we could get more names out of the articles. The next step was to move from Google Colab to a command line script. That gave another boost, as explained in this second post in the series. We reached 200 thousand names in june 2025 but then things slowed down again in the growth. Two months later we only had 75 thousand more. However, plenty of discussion was happening and there turned out to be other, larger collections of IUPAC names under an open license. Millions of names, actually.

But another problem emerged. We were still using the Europe PMC API and were basically asking for open access articles between two dates. Practically, the API could answer requests between 1 and max 3 days. Beyond that, times outs and 404s became an issue. Moreover, because these dates are publications dates and not the dates on which the JATS were deposited, I had to got back to previous months and redo the queries. That gave another 5 thousand names since last August. Something had to change.

The new Approach

Europe PMC, however, also provides the JATS XML files as download on their FTP site. Already that august 2025 I had a prototype and knew it would change the game. These gzipped XML files are about 150 to 250 MB. Unzipped, about 1 GB each. Better, these files are based on Europe PMC identifiers, hopefully resolving the issue with using dates in the queries.

Now, parsing a 1 GB XML files is a total non-issue. I have done it plenty of times before. Just use a Simple API for XML (SAX) parser. This is a streaming parser giving you full control of how to parse things. It is ideal for this siutation: you just keep the current paragraph of text in memory and release that when done with that paragraph. That is, you do not have to read the full file in memory, just the bits you are interested in. I used this for my Chemical Markup Language patches for Jmol and JChemPaint back in the nineties.

Last weekend I finally made the jump. Use SAX to extract the <p> elements one by one, running OSCAR on them, filter with OPSIN, output that name, and clear the memory. Effectively, each gzipped file processes with a Groovy script in about 1 to 2 hours.

The output is a mesmerizing stream of scientific literature (which I will use until someone points me to a Java CLI library that creates a Matrix-style falling letters equivalent), tho less so as a static image:

In this plot, an x means a new article to be processed. Each . and o that follows is a single <p> element and the difference is that an o means at least one IUPAC name was detected in the paragraph.

Each gzipped file gives 400 to 500 new IUPAC names. Indeed, going from 288 thousand to 300 thousand was a matter of a day and a half. And earlier this afternoon we passed the 400 thousand IUPAC names. With about 230 gzipped files. Now, I am going back in time, and the sizes of these files are shrinking: Another 500 files and the size has dropped to around 125 MB, so a rough estimate suggests that we will end up with 650 to 700 thousand names this way. This will be completed in a few weeks (and mostly because I need to focus first on other things again, because I can use our computing cluster do this).

Regarding the original goal, fortunately, we are still publishing at a higher rate every year, and more and more articles are available as open access. So, I still have good hopes we will reach the 1 million IUPAC names. Also, keep in mind, we know how to boost this by simple name variations to several millions, even with the 400 thousand we have today.

Oh, and our next milestone will be in the pocket before I visit Christoph Steinbeck’s cheminformatics team in Jena!

References

This is the second time a local Open Science Festival is organized in the area, with an Open Science Festival Maastricht in 2023. Of course, a year later Maastricht also hosted the 2024 national Open Science Festival.

This year’s event is co-organized by the (new) Open Science Community Parkstad and the Open Science Community Maastricht, with interdisciplinarity as main theme. The event will take day over two days, June 11 in Heerlen, and June 12 in Maastricht. You can register for either or for both days. Each days have plenary sessions and several parallel workshops, where you will dive into one of the many aspects of open science.

Looking forward to welcoming you in Limburg!

References

Still, Zotero 8 brought in prefix and suffix support, and I was wondering if this could be used for CiTO citation intent annotations. And it can. This was the result, and make of it what you want:

References

The meeting consisted of four keynotes, each one was quite interesting. Cornet gave a nice historic perspective of the venue and of the semantic web field, which is a great way to welcome the participants to your institute. The talk also touches on the main theme of the meeting: clinical data. It is a long standing (and important) research field, but progress is slow. Cornet comments along the lines that we have been talking about reasoning over patient data for more than twenty years, but we still have not solve it.

The problem is really not only privacy, but simple also lack of a common language. As Sabine Österle explains about sharing health/patient data in Switzerland, across 26 kantons and legislations and 4 national languages. Another issue is more technical, running SPARQL across hospitals involves more than just aligning ontologies, but also requires (too much) fiddling with SPARQL queries.

There was plenty of other content too, however. For example, I was pleasantly surprised by the RDF4RiskAssessment work, the RO-Crates for BioImaging, and FDPcrawleR. All these projects have direct links to research ongoing in our TGX team.

Hanna Bast gave the second keynote of the first day, about QLever (doi:10.1145/3132847.3132921). She talked about some of the recent improvements, something we really needed for Scholia. She showed a technical approach to make federated queries faster, tho it currently only works between endpoints that both run QLever. One thing I am looking forward to, is playing with the notion of materialized views, but the biohackathon was too short to get around to that during the Thursday.

The second day kicked off with a keynote by Janna Hastings, whose work I greatly admire. I was not disappointed today, and she showed the Behaviour Change Intervention Ontology and Chebifier (doi:10.1039/D3DD00238A).

The last talk I want to mention in the blog is by two researcher working with Michel Dumontier. They presented a study about deduplication in/of knowledge graphs. This is something I want to read in more detail.

References

• 10.1039/D3DD00238A
• 10.1145/3132847.3132921

Compact identifiers find a balance between compactness in writing and being a persistent, unique, and global identifier. It “is a string constructed by concatenating a namespace prefix, a separating colon, and a locally unique identifier (LUI)” (doi:10.1038/sdata.2018.29). For example, for proteins it can represent the PDB structure 2gc4 as pdb:2gc4. There is a clear similarity with the SciCrunch Research Resource Identifiers (RRIDs) as used by several journals, like eLife (doi:10.1007/s12021-015-9284-3).

When the prefixes are defined by community standards, then a compact identifier can be resolved. There currently are multiple providers of prefix files (doi:10.1038/sdata.2018.29), including Identifiers.org (doi:10.1093/bioinformatics/btaa864) and Bioregistry (doi:10.1038/s41597-022-01807-3). The Bioregistry has an overview of more than twenty registries of prefixes and their metadata (doi:10.1038/s41597-022-01807-3). The metadata commonly includes information on the URL pattern for each identifier. Often this is more than one pattern, as there may more several databases with information for the same identifier.

It is the URL pattern in the database that allows services to resolve the compact identifier into a link to a database. The above registries correspond to three existing resolvers that will take a compact identifier as part of a resolver URL and redirect to the database with the record matching that identifier:

• Name-to-Thing (N2T): https://n2t.net/
• Identifiers.org: https://identifiers.org/
• The Bioregistry: https://bioregistry.io/

Each of these URLs can be extended with a compact identifier. For example, a taxon record from the NCBI databases or the PDB entry mentioned earlier:

• https://bioregistry.io/pdb:2gc4
• https://identifiers.org/col:6MB3T (col is the prefix for the Catalogue of Life)

Why use in reports?

Using persistent identifiers is generally accepted as a good practice that benefits science and has been part of the ideas of FAIR data (doi:10.1038/sdata.2016.18) and of Open Science. Compact identifiers make it easy to be precise in reports about what things the reports talk about: they are relatively short but very precise at the same time. also, that has the benefit that they are much easier to reuse than labels of things and concepts that intrinsically have a certain level of uncertainty; a database entry has commonly a very specific meaning.

Examples uses

The use of compact identifiers can be used in two ways. The simplest is to just put the compact identifier as plain text in the document, possibly in parentheses (with the compact identifier highlighted here in bold):

This report is only about the experimental data of the human (NCBITaxon:9606) cell lines.

Or:

We found that BRCA1 (ensembl:ENSG00000012048) played an important role.

Alternatively, you can add a hyperlink with one of the resolvers, for example, Identifiers.org:

We found that BRCA1 (ensembl:ENSG00000012048) played an important role.

Compact identifiers for material identifiers

The European Registry of Materials proposes to use the compact identifier for their ERM identifiers (doi:10.1186/s13321-022-00614-7):

For example, the NanoSolveIT project registered a material with the ERM00000001 identifier. The full Uniform Resource Identifier (URI) for this compound is https://nanocommons.github.io/identifiers/registry#ERM00000001 which is too long to be used in documentation. The corresponding compact identifier erm:ERM00000001 is easy to use in written material, analogous to the use of Protein Data Bank (PDB) identifiers for proteins in journals.

Compact identifiers for citation intent annotations

The compact identifier has also been used as the method to include citation intentions in journal articles (doi:10.1186/s13321-020-00448-1, compact identifier here highlighted in bold):

We take advantage here of the ability to add notes to full form [..] references in bibliographies. These are referred to as bibnotes. The content of the note will be strictly formatted: it will use the syntax [cito:usesMethodIn] and formatted in bold. That is, the bibnote starts with the [ character, followed by one of the CiTO types, and ends with the ] character. If you wish to provide more than one annotation, you can repeat this syntax, separated by one or more spaces, for example: [cito:usesMethodIn] [cito:citeAsAuthority].

Note that in this use, the square brackets and bold typeface are used to make them easier to be recognized. Also, note that this document uses this approach to indicate the intention of why the cited articles are cited.

Conclusion

This document described what the compact identifier is, how it helps linking to online databases, and how they can be used in written reports as plain text, optionally hyperlinked with one of the compact identifier resolvers.

Acknowledgments

I thank github:tabbassidaloii, github:cthoyt, and github:larsgw for their comment on this GitHub repo.

References

I am looking forward to meet old friends, new friends (some whom I never met in person), and recent collaborators (that I never met in person). For those who will not be in Amsterdam, you can follow the meeting on social media with the hashtag #swat4hcls. And there is also this BioHackrXiv Fediwall, for those in the fediverse.

Scholia demo

I will give a demo to update people on the work in the Scholia project with Daniel Mietchen, Peter Patel-Schneider, Konrad Linden, Johannes Kalmbach, Lars Willighagen, Wolfgang Fahl, and Hannah Bast (also keynote in Amsterdam) to update the SPARQL queries we use to visualize data in Wikidata to SPARQL 1.1 so that it can run on Qlever. The abstract can be found in Wikimedia Commons.

This was the outcome of many years figuring how to ensure Scholia could remain working. The Wikidata RDF graph split has given us many headaches, so many that just before christmas it became it could be possible to survive the split, I was so happy, I realize I want to share this news. So, we teamed up and wrote this demonstration contribution abstract. Thanks to everyone who made this happen! Just to be clear, we are not done yet. The system is not running outside the Wikimedia Foundation platforms.

One of the reviewer comments requested a Scholia page for the meeting. It has not been updated for the accepted speakers, but you can look at pages for past meetings to get an idea what you will find.

SWAT4HCLS Biohackathon 2026

There will also be a biohackathon again, of course, with the option for BioHackRxiv reports. There are already several pitches, including one that I submitted about Scholia.

References

• harmonize hydrogens to various states: depiction, stereo, minimal, and unsafe (useful for depictions)
• generate wedge bonds based on coordinates and stereochemistry
• more Markush / RGroup support
• atropisomers via CXSMILES
• sugar extraction

I also update the following libraries/tools to use CDK 2.12:

• NanoJava 2.16
• Bacting 1.0.10 (and the Python pyBacting will follow asap)

References

• 10.5281/zenodo.18850648