The work actually started long before that, with the Robustifying Scholia grant (see doi:10.3897/rio.5.e35820), where we explored alternatives. The Wikidata graph (RDF) split has been long coming, and I can recommend this recent The Signpost article by Lane for a good overview. So, this would not have been possible with the many people who contributed over the years. But this last sprint really made a difference.

The developments of the QLever software in the past year are very important, and the SPARQL endpoint we run now is live updated, just like we knew from the Wikidata Query Service (WDQS). Recent improvement allowed us to replace all the Wikidata and Blazegraph specific aspects of the SPARQL queries, and good discussions let to pragmatic approaches to keep localization features Scholia had for displaying query results from Wikidata.

The work is not completed, however. All queries are SPARQL 1.1 now, but some can still be further optimized, and some still need some fixing. For example, I still spot some QIDs here and there, instead of the localized labels that should be shown instead. Also, we are actively looking in getting everything running again on WMF servers (see this overview issue), so that scholia.toolforge.org works again.

For now, however, please use qlever.scholia.wiki.

Fortunately, it looks like we will have a working replacement in time before the WDQS instance with all the Wikidata triples in a single SPARQL endpoint goes down, likely in a week or so (even tho we may be behind the citation peak).

The work of the past year helped, for exampe, making it easier to configure Scholia for a different endpoint and the asynchronous loading of panels (reducing the stress on the SPARQL end point). Already in September, Prof. Hannah Bast started a branch for the transition and various hackathons this autumn, and the work by Konrad Linded who explored and addressed some of the hurdles to take. The tips and suggestions from Hannah and RobinTF really made a difference. And also a huge thanks to Daniel who kept relentlessly pushing this forward.

When I posted my will we make it post, there was a demo instance and a spreadsheet showing the state of each query. The instance showed no human-readable labels. This was because the WDQS wikibase:label service was used a lot, and there is no replacement for that. Getting labels for all relevant items is possible, but makes the queries a lot heavier and made even more queries run out of memory. Various solutions were discussed, Finn indicated he preferred a macro solution, which Lars implemented, and saw some tweaks after that. Then followed a long series of patches by particularly Peter to update all the SPARQL queries to have them use the new labels macro. But plenty of other things were fixed or newly implemented, such as Wolfgang’s /backend page.

So, with one week to go, we need your help: as the weekly Wikidata Status Update already indicated:

this month’s Scholia hackathon has moved Scholia closer to its planned switch to a QLever backend. Beta testers can assist by exploring the interim QLever-backed Scholia instance and reporting any issues.

And thanks to Adriano and others who already have!

Now, we are not done yet. The real instance at scholia.toolforge.org has seen ridiculous abuse by scrapers (and the main instance is regularly unusable, to be honest), and we have no idea the new setup is powerful enough. And we need to point to the new servers anyway. So, plenty of work is left to be done in the next few days.

But we are getting close. So, please give qlever.scholia.wiki a go, and let us know your observations. As Linus’s law writes:

Given enough eyeballs, all bugs are shallow.

So far, we have been able to continue to use a legacy SPARQL endpoint with all the data, but in exactly one month that endpoint will be sunset. And we are not ready.

Rescuing Scholia

Daniel and Lane have been leading an effort to rescue Scholia. The hackathons were part of this effort. It seems that QLever is the only route left. Earlier efforts to rewrite the more than 350 Scholia SPARQL queries to support the graph split have basically failed. The complexity is far too high. QLever, however, provides the full graph and since recently full SPARQL 1.1 support. That is also not enough to reproduce the full Scholia functionality, but it seems to get us far. Importantly, the data may not update as frequently as the WDQS, and that is another complexity to take into account. Particularly, all the 404 pages.

So, in the next weeks, we have to complete rewriting all those queries as queries that QLever can handle. A team of people have done great work already, including Konrad.

I hope we make it in time.

I wanted to see what I could recover, and here I describe what I did and what could be done next.

A list of all articles

The first step is actually to create a list of all articles published in the IJC and collect as much metadata about them as possible. With just over 100 articles, I decided to use Wikidata, as a machine-readable database, supporting the curation and reporting. I wanted at least two independent sources, and for Wikidata, use public resources. That means, while Web of Science does have a list of all articles, I only used this for validation, and not as information source. Instead, I used citations to IJC articles and, of course, the Internet Archive (IA). It turns out a query like this does wonders (well, for the abstracts; I did not find full-texts archived on IA):

https://web.archive.org/web/*/http://www.ijc.com/abstracts/*

I found that all but one article had the abstract archived in the IA. Here’s an example:

This gave my a lot of information to add to Wikidata. Title, publication date, volume, article number, keywords, an absstract, and, of course, the list of authors. Some authors I know personally, many I did not. But it did allow me to enter all articles to Wikidata along with the authors and “author” (P50) or “author name string” (P2093).

The article authors

It also turned out that multiple authors listed their IJC article on their public ORCID profile. That greatly helped identification. I managed to link many authors to mostly existing Wikidata items:

I already mentioned that I used Wikidata to collect this information. Besides the interactive visualization with Scholia, it also gave me the option to track my progress with SPARQL queries. For example, this query helped me do that author FAIR-ification:

You can see here two columns with author information, one for P50 and the other for P2093. There is quite some identification left to be done, and additional information is welcome:

Sources

So, that brings us to this list of sources:

• Internet Archive: abstracts and metadata
• ORCID profiles: ORCIDs of (some) authors
• Google Scholar: metadata and citations
• Web of Science: independent list for external validation

Because there is plenty of work left to be done and I hope the collected information will further spread in library collections, I added sources as much as possible. This query lists for all articles the Web of Science identifier (recorded so that everyone can check the consistency), the link to the Internet Archive-d abstract page, and a link to a known full text (five).

If you wonder, neither OpenAlex or Europe PMC have a full list.

What’s next?

I do not have a formal training in archiving, but I am happy with the minimal viable metadata collection. I know more can be done (and love to hear your pointers and suggestions): more author identies, better coverage of keyword annotation, etc. But I think an important addition is adding citations to and from the IJC articles are important. The journal predates efforts like the I4OC and Open Citations, so I may have to manually recover citations from Google Scholar. I will have to report on that later. But you can enjoy the citations that are already there. And now that we have sufficient metadata, I can use this to find more full texts.

Btw, I have made contact with Prof. Steven Bachrach, who founded the journal and was the Editor-in-Chief.

The history tells me that our society may sound woke and leftish, in reality it is a continous fight for basic human rights. (Something that plenty have been saying for years.) In this case, a healtht life is the human right.

So, what can I do to make this report more FAIR?

Findable in Wikidata

Since this report has been mentioned in the news, it clearly is notable. The simplest thing to do is thus to just add it Wikidata. Because the DOI of the report had not been recorded yet, I could not let Scholia do it for me. But doing it manually is only a bit more work: Q135222054. The provided metadata on the RIVM website is minimal.

But we can do more. Particularly, because I want people to find this report when they look info knowledge about the 28 studied chemicals, I added main subject annotation using the information in Table 1 in the report. Using Scholia and the CAS registry number in the table, I crosscheck the information in Wikidata is consistent with the report (and visa versa). It was. I then added the Dutch name and acronym for most of them. Some already had the name as in the Table. That gives us a nice “Topic scores” plot for the Scholia page of the report:

The central PFAS bubble is also only one main subject but larger because many the specific PFAS compounds are subclassing PFAS. And you may also note many smaller bubbles. These actually come from main subject annotations of articles cited from the report. Because I added a few of them too. Not all, because many are not in Wikidata (yet).

Findable in WikiPathways

But since 16 of these compounds are readily found in human blood samples, that is handy knowledge when doing metabolomics (on blood samples). Or (and I leave that to later blog post), we can map the experimental data for Dordrecht versus the rest of The Netherlands to the PFAS compounds. That is relevant to research by VHP4Safety. There are many ways to see if you have PFAS in your dataset, but since we have many controlled lists of genes in metabolites, I added one for common PFAS in human blood samples. Well, the 16 common in Dutch blood samples:

Each metabolite here is annotated with their Wikidata identifier, allowing us to map experimental data on top of it. And we get links out to other databases almost for free:

And the link to Wikidata actually links to Scholia, so for the PFOA in the above example, we can quickly see the boiling point, decomposition point, and melting point of this PFAS. And literature with undoubtedly even more knowledge about this PFAS:

Now, these two steps were mostly manual: drawing WP5579 in WikiPathways and adding the report annotations (main subject and cites) in Wikidata.

Findable in the VHP4Safety Compound Wiki

As part of the VHP4Safety project, I am collecting information on chemicals studied in the context of toxicology, safety, and risk assessment. Often specific collections of compounds studied as a whole. This report is such a collection and provides experimental data on these compounds. So, I want this report to be findable for the VHP4Safety Compound Wiki too. Creating the collection is a manual step: Q5145.

Now, because both Wikidata and our VHP4Safety Compound Wiki (a Wikibase instance) are semantic and support, I can use SPARQL to create instructions to link the 28 compounds to the new collection. Now, arguably, that can be done manually too, and maybe faster, for larger collections this is harder. So, I dug up my earlier notes and got some useful things together.

This query lists all 28 PFAS linked to the report in Wikidata:

SELECT ?pfas ?pfasLabel WHERE {
  wd:Q135222054 wdt:P921 ?pfas .
  ?pfas wdt:P31 wd:Q113145171 .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],mul,en". }
}

Using federation powers, I can use this for a SPARQL query, and return the results in QuickStatements that say this VHP compound is part of the VHP collection:

PREFIX wb: <https://compoundcloud.wikibase.cloud/entity/>
PREFIX wbt: <https://compoundcloud.wikibase.cloud/prop/direct/>

SELECT (SUBSTR(STR(?cmp),45) AS ?qid) ?P21 WHERE {
  ?cmp wbt:P5 ?wikidata .
  SERVICE <https://query.wikidata.org/sparql> {
    wd:Q135222054 wdt:P921 ?pfas .
    ?pfas wdt:P31 wd:Q113145171 .
    BIND (substr(str(?pfas),32) AS ?wikidata)
  }
  BIND ("Q5145" AS ?P21)
}

I actually had to add 5 PFAS compounds in the VHP4Safety Compound Wiki first. That follows the same procedure for how I have been adding chemical compounds to Wikidata (see also this preprint). The input cas.smi has the (missing) SMILES, Wikidata QID, and English label:

C(CS(=O)(=O)O)C(C(C(C(C(C(F)(F)F)(F)F)(F)F)(F)F)(F)F)(F)F       Q27063662       6:2 Fluorotelomer sulfonate
CN(CC(=O)O)S(=O)(=O)C(C(C(C(C(C(F)(F)F)(F)F)(F)F)(F)F)(F)F)(F)F Q126605979      MeFHxSAA
CN(CC(=O)O)S(=O)(=O)C(C(C(C(F)(F)F)(F)F)(F)F)(F)F       Q126682412      MeFBSAA
C(=O)(C(C(F)(F)F)(F)OC(C(C(F)(F)F)(F)F)(F)F)O[H]        Q29387971       2,3,3,3-tetrafluoro-2-(heptafluoropropoxy)propanoic acid
C(C(C(=O)O)(F)F)(OC(C(C(OC(F)(F)F)(F)F)(F)F)(F)F)F      Q81981675       4,8-Dioxa-3H-perfluorononanoic acid

For reference, this is the command line I used to create QuickStatement instructions:

groovy createWDitemsFromSMILES.groovy -w compoundcloud.wikibase.cloud -c Q2368 -d P5 -l -i wikidata -a P11

Final remark

Are these 16 the only PFAS in our body? With 28 studied out of a potential seven million, I doubt it.

In turn, that poster described work of at least three years, going back to adding identifiers in 2015 and chemical structures in early 2016. I started using scripts two months later. This helped a lot with migrating pKa data from a custom Semantic MediaWiki installation to Wikidata and with adding thousands of EPA CompTox identifiers in 2017.

But that 2018 conference paper never happened. Because Scholia did. And even on the ICCS poster, Scholia was used to visualize chemistry data in Wikidata. To be honest, not just that, of course. About a year ago I had a serious go at finishing the paper, and it was sent around to co-authors. But I realized at the time, that the paper was lacking some good suggestions how the peer review our actual contributions to Wikidata. I could hardly expect readers of the paper browse the individual histories of all, by then, 1.3 million chemical compounds. And during the holidays I collected a few tools, which I had lined up to add to the manuscript.

However, another thing happened, the COVID-19 pandemic. While all the experience helped a lot with getting knowledge together around SARS-CoV-2, it also made something else clear: the software behind Wikidata does not scale well (enough). This lead to plans to split the RDF graph representation into two separate SPARQL endpoints. And that breaks many, if not most, of Scholia’s SPARQL queries, including those for the chemistry aspects. The situation in Summer 2024 was that there was a significant chance Scholia would not survive the split. And the Scholia Chemistry paper had to wait. You cannot publish an article of which the website is gone before it is formally accepted.

Let me make clear, this graph split is not solved and the risk is not gone. But a serious of unfunded, weekend hackathons allows us to refactor Scholia to give us a chance. It started with making Scholia more configurable. We had the first hackathons in October and November, and I had four more hackathon weekends this April.

The graph split into a main graph and a scholarly graph happened on May 9. Currently, we have been granted extra time and can use a legacy server with the full graph, but a lot less hardware, so slower. A final patch, merged in last week, allows us to define which SPARQL endpoint a query should run. So, each time we port a SPARQL query, we can directly update Scholia, making the migration somewhat more manageable.

But, with those uncertainties out of the way, it was time to finish the Scholia Chemistry paper!

The preprint (doi:10.26434/chemrxiv-2025-53n0w) brings 10 years of research together, and describes details of the used methods not formally peer-reviewed before. We describe in detail how chemical structures are added, the choices of Wikidata on how to represent chemical structures, how we curate the quality, and how we visualize chemical structures and data with Scholia. As you can expect, the Chemistry Development Kit has an important role, along with the InChI.

The paper introduces three new Scholia aspects for chemicals, chemical classes, and elements. Each aspect is a template for a page with information about molecular entities and chemical substances, compound classes (like fatty acids), and elements (like carbon). Each template provides relevant information. Of course, any compound, class, or element can also still be opened in the Scholia “topic” aspect, listing relevant literature.

With this paper we aim to show that Wikidata is a innovative platform that meets the needs for a chemical structure database, with detailed data provenance, and scalable community curation.

I welcome your strongest peer review on the preprint. I don’t liking settling for anything less. Here’s the abstract:

Sharing knowledge on chemicals in the digital age has been the playground of databases such as the Chemical Abstract Services and PubChem. Wikipedia complements this field by providing context to chemicals aimed at a broad audience, but is not easily read by machines. Wikidata was started as a database service to improve the machine readability of the knowledge captured in Wikipedia. Wikidata has an open license, application programming interfaces, and a strong provenance model. Scholia uses the features to provide access to chemical knowledge. This study reviews the chemistry in Wikidata, shows how thousands of new chemicals were added, extends Wikidata with new properties for chemical representation and external links to additional databases, and shows how we extended Scholia to represent the chemistry in Wikidata.

Thanks to Finn, Denise, Daniel, and Adriano!

Scholia has not been upgraded. It has more then 350 SPARQL queries, and each one has to be tested separately and updating every query is not trivial. Together with Daniel, Finn, and others, I have hacked up patches last year to:

• configure Scholia for the endpoint to use
• create pages for many Scholia SPARQL queries

This month I continued working on the second, and I:

• added titles for chemistry aspect panels
• use the legacy SPARQL endpoint

That second also indicated that the legacy server has more limited resources and users will more quickly run into error messages that too many queries are run in parallel. Now, users can rerun the query, but then the results table contains the previous error message. Second, you want to run the queries for one aspect to not run all at the same time, but have Scholia send of the query when the panel becomes visible (and scrolling a page takes a bit of time).

For these issues, I wrote these two patches (yet to be approven and merged):

• delete the previous error message
• lazy load the table and iframe panels

Now, the iframes already had some aspects of lazy loading, but it turned out that it was mostly lazy display, and the queries were still run as soon as possible. This last patch challenged my JavaScript skills and I learned Intersection Observer API, a browser technology that allows the browser to see what part of the webpage you are looking at right now. Yeah, I can easily see how that does user profiling, but in this case it is just used to fire of the SPARQL query when it become relevant. It uses an additional callback function, so I had to make sure Jekyll/Liquid creates custom callback functions for each panel. Actually, I intended to show the code here, but I am not entirely sure how to escape the code so that Jekyll does not try to run the instructions. For now, you have to check the PR.

Scholia Chemistry paper

The other things I have been doing, is finally finish up the Scholia Chemistry paper. That actually depended on the maturing of various tools, me figuring out how to characterize the actual amount of content contributed to Wikidata and how to make that transparent, and more recently, the above to be able to convince readers Scholia will not die with the graph split. With the above pages, we have, I think, sufficient guarantee it will be around for another few years, at least.

This paper, which I hope to finish the final draft today, applying some good feedback from co-author last weekend, is the final bit of work done on the Alfred P. Sloan Foundation grant.

We intend to put the paper up as preprint soon and then submit it do a Diamond Open Access journal, one that supports CiTO citation intent annotation.

But in addition to the data model for SPARQL as research output (see doi:10.32388/ZNWI7T.2), the paper also introduces the sparql-example-utils software that I was first introduced with at the recent October Scholia hackathon.

But I have/had some features I like to see added. The first is provenance. Who is the author/contributor of the SPARQL query? Is there a open license for it, or perhaps public domain? How do I give attribution if I reuse the SPARQL query? These things matter in a modern recognition and rewards world where is room for everyone’s talent. A set of good SPARQL queries may be more valuable than a ten-page Jupyter notebook (and the other way around). So, I started writing patches. And I created a custom jar so that I can see these patches in action in our growing list of SPARQL queries (here a WikiPathways query):

I started collecting SPARQL queries for ChEMBL, WikiPathways, and VHP4Safety. These queries are often part of other interfaces but we can easily extract the original SPARQL from the Turtle files behind these pages.

Scholia has received a fair share of scholarly and social attention. The Scholia paper has been cited over 100 times and the websites received about 200 thousand page views each day (though we do not know how to get Toolforge to give us sufficient insight into the how and what of that count). There is a Wikipedia template to link to Scholia and some of projects I am involved in link Scholia for articles, such as WikiPathways.

With that, there is also interest in using it for other Wikibases and perhaps even random SPARQL endpoints. These things are not trivial, as Scholia uses complementary APIs, various URL patterns for some of the functionality, and generally, all SPARQL queries are tweaked to the Wikidata Blazegraph SPARQL endpoint to ensure results are returned in reasonable time. But that last requires use of Blazegraph extensions to the SPARQL standard.

All this requires Scholia to become more independent, in a better model-view-controller model. And that actually turns out very important at this moment. That is, Wikidata is not a RDF-first database, but a Wikibase-based store. Whenever an edit is made, RDF is generated and the SPARQL endpoint is updated. Now, the number of edits in Wikidata is enormous and the notion that the SPARQL endpoint is often minutes at most behind is a huge accomplishment. But the Blazegraph platform cannot keep up with Wikidata. Blazegraph is open source, but has been bought up and development stopped from one day to another.

Therefore, a split of the Wikidata SPARQL platform is planned. This split will put one part of the knowledge in on endpoint and the other half in the other. Any query that needs information from both graphs, will have to do a federated SPARQL query. Basically, there are very few Scholia queries that do not rewriting. My first rewrite actually failed, because the rewriting is not obvious and quickly times out. To some extend, this is because now lots of results of subqueries need to be send over the network from one endpoint to the other. When the combined query basically covers half of each endpoint, that’s a lot of network traffic.

An immediate use case of the configuration is therefore running Scholia against the current three endpoints: the current official endpoint, and the two split endpoints under development. With a recent patch Finn and I worked on, this configuration looks like this (and saved as scholia.ini:

[query-server]
# Wikidata:
#sparql_endpoint = https://query.wikidata.org/sparql
#sparql_editurl = https://query.wikidata.org/#
#sparql_embedurl = https://query.wikidata.org/embed.html#

# Wikidata Split Main
sparql_endpoint = https://query-main.wikidata.org/sparql
sparql_editurl = https://query-main.wikidata.org/#
sparql_embedurl = https://query-main.wikidata.org/embed.html#

# Wikidata Split Scholar
#sparql_endpoint = https://query-scholarly.wikidata.org/sparql
#sparql_editurl = https://query-scholarly.wikidata.org/#
#sparql_embedurl = https://query-scholarly.wikidata.org/embed.html#

So, right now, we can test the impact of the split with Scholia and this patch. We would fire up a local instances of Scholia, running against one of the split endpoints, and use the Toolforge instance as baseline.

Now, on my system I need to use Python virtualenv so, I first start a Scholia venv:

source ~/.venvs/scholia/bin/activate

After that, I can select an other endpoint, e.g. the main Wikidata split endpoint (query-main-experimental.wikidata.org) were it not they are currently offline as part of the transition and run Scholia on a unique port:

scholia run

Then I can have two browser windows along side and compare Scholia pages againt the current Scholia instance and when running against another SPARQL endpoint. For now, I can test how well Scholia runs on the QLever instance of Wikidata (superfast and updated data once a week). Here the configuration I have is not entirely complete, and many SPARQL queries do not work against QLever, including anything with graphical depiction. But that said, I can use this configuration:

[query-server]
# QLever
#sparql_endpoint = https://qlever.cs.uni-freiburg.de/api/wikidata
#sparql_editurl = https://qlever.cs.uni-freiburg.de/wikidata/?query=
#sparql_embedurl = 

Then, I can compare, for example, the chemicals statistics the main Scholia with one running against QLever:

This query ran without modification. For other queries rewriting is needed, but with this setup we can at least quickly see the differences in the results.

To me, subsetting of Wikidata (or any large knowledge graph) is important for a couple of reasons. First, there can be practical reasons. Scholia, for example, is computationally expensive, and the idea we explore in the Alfred P. Sloan Foundation grant for Scholia (doi:10.3897/rio.5.e35820) was that a subset of Wikidata would make it more performant and potentially more environmental-friendly.

A second reason is more about the scientific process. When doing an analysis and when you want to make the reasoning transparent, you want to share the analyzed data as part of the research output (basically, the “data”). For example, the data may have undergone some curation, or you combined data from two or more different sources. And you will want to share this as part of the scientific process. Resharing a full dump of the larger knowledge base would not be practical for at least two reasons: duplication of huge data, and a lot of unrelated content makes it hard for peers to find the bits of interest to the study.

Subsetting may be useful here. This paper evaluates a number of different subsetting approaches. Myself, I am particularly excited about the idea that we can take a shape expression (e.g. ShEx) as input. I still love the idea that I take the SPARQL queries in my analyses, convert that into shapes automatically, and then get a subet that returns the exact same results as the query would on the full dataset.