new blog: "Rescuing Scholia #3: We did it!" https://chem-bla-ics.linkedchemistry.info/2026/02/28/rescuing-scholia-3-we-did-it.html https://doi.org/10.59350/kd793-2fe02

"For now, however, please use qlever.scholia.wiki." https://qlever.scholia.wiki/

Replies show up in the blog.

#wikidata #scholia #qlever #sparql

Rescuing Scholia #3: We did it!

It was not a set up, when I openly wondered if we would be able to rescue Scholia in time. I honestly did not know. Three weeks and some serious hacking by an international team later I was more optimistic. Actually, just before christmas, we started writing a SWAT4HCLS 2026 demonstration abstract. This was accepted and you can read the Scholia 2026: Compliance with SPARQL 1.1 preprint here and here. This paper describes the work that had to be done, and I am deeply grateful to everyone who contributed with smaller or bigger contributions (Daniel, Peter, Konrad, Johannes, Lars, Wolfgang, Hannah). I am merely first author for the demo, and just another contributor to the long series of patches, in a branch started by Prof. Hannah Bast.

chem-bla-ics

yesterday evening work with @EvoMRI on the @wdscholia instance on Toolforge. We noted that our main instance only shows half of the results, only @wikidata 'main' part. The 'scholarly' articles part are no longer there. That day has been pending.

We seem very close. I wrote up a status 3 weeks ago: https://chem-bla-ics.linkedchemistry.info/2025/12/31/rescuing-scholia-2-getting-close.html

For this week, plz use https://qlever.scholia.wiki/

We put a banner on the #toolforge instance

#openscience #wikidata #sparql #scholia

Rescuing Scholia #2: getting closer

Three weeks ago, I wrote a the post Rescuing Scholia: will we make it in time?, where I sketched a future without Scholia. Scholia, started almost 10 years ago and I think it is worth keeping around longer.

chem-bla-ics

There will be changes in the week of January 20th 2026 regarding the WDQS graph split and sunsetting of the legacy service. There is a https://qlever.scholia.wiki/ mirror running with QLever as backend with the full Wikidata content. This mirror is part of an evaluation of alternatives to Blazegraph.

#wikidata #scholia #qlever

News about Scholia:

"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"

"scholia.toolforge.org has seen ridiculous abuse by scrapers"

"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. "

https://chem-bla-ics.linkedchemistry.info/2025/12/31/rescuing-scholia-2-getting-close.html

#scholia #wikidata #wikibase

Rescuing Scholia #2: getting closer

Three weeks ago, I wrote a the post Rescuing Scholia: will we make it in time?, where I sketched a future without Scholia. Scholia, started almost 10 years ago and I think it is worth keeping around longer.

chem-bla-ics

new blog: "Rescuing Scholia: will we make it in time?" https://doi.org/10.59350/yh369-rr787 https://chem-bla-ics.linkedchemistry.info/2025/12/08/rescuing-scholia.html

"What started out in 2016 on Twitter became a (small) award winning decade long collaborative project. Unfortunately, the future is not clear. We are at odds if it will survice the growth of Wikidata and in particularly the SPARQL graph split."

#wikidata #scholia #openscience

"QLever is the fastest engine overall, but is slower for distinct answers. Virtuoso is fast but diverges the most by far mostly due to several known causes. MillenniumDB and Blazegraph are the slowest. MillenniumDB is fast on simple queries, but slow on complex queries." https://ceur-ws.org/Vol-4108/paper3.pdf

#wikidata #sparql #scholia

I have been following the developments of the @bonfire #Fediverse software for some time now, particularly their #OpenScience extension, because I see it as a future manifestation of open, interactive, publication-based #SciComm on the #Fediverse: http://openscience.network

A few days ago the first pilot was presented that is also self-hostable: https://openscience.network/setup/
However, looking at its current state, I can only take that achievement with a grain of salt.

One of the reasons why the Fediverse is so independent and resistant to central takeovers is because it does not rely on global identity service providers. This is precisely what sets it apart from other #BigTech platforms, as well as Bluesky. However, regarding the development of the Bonfire Open Science flavour, it has become apparent over the past few years that the Bonfire developers are increasingly taking a #ORCID-centric approach.

ORCID is a global centralized identity provider that relies entirely on the infrastructure and services of US #Hyperscalers. Anyone who gets involved with ORCID submits to them being the single point of failure with all its consequences, similar to #Cloudflare (btw. guess which provider orcid.org runs on), and that is exactly the opposite of what decentralized networks are about. The organization behind ORCID is also supported by some of those big publishers, who ultimately were the reason why there had to be a counter-movement in the first place, which we now call Open Science.

Anyone who integrates providers such as ORCID into decentralized technologies is probably letting #BigTech in through the back door. #Scholia, which is based on #WikiData, offers a reasonable alternative to ORCID. Its technical infrastructure is independent from big cloud providers, large publishers cannot buy their way into its community, and it even discloses the code for its platform itself.

There is nothing wrong with having an optional feature for importing data from ORCID. However, I find it highly questionable to make user registration dependent on this service provider. I hope that in the future, attention will once again be turned to local SSO authentication services, good old-fashioned email registration, and ORCID integration will become optional.

Edit: In the initial version of this post, I stated here that the current pilot even enforces the use of ORCID. In reply to this post, the Bonfire developers clarified that ORCID integration is optional and they are offering multiple authentication methods including email. In response, they have also corrected the setup guide linked above, which initially gave the impression that ORCID integration is currently mandatory.

#Hyperscaler #Centralization #Science #Bonfire
Open Science Network

Reclaim scientific discourse with federated digital spaces where researchers shape their own conversations, data, and collaborations

#ClimateKG will be used for the #IPCC #AR6 corpus of 7 main reports of 10,000 pages. For corpus browsing, republishing, community enrichment. The constructed knowledge graph in Wikibase/MediaWiki allows browsing using the familiar #MediaWiki interface with #Wikidata enhancements like infoboxes, and #scholia like interfaces https://scholia.toolforge.org/ | Republishing is intended for sharing or reviewing search results on climate topics | Enrichment is for data scientists to make use of reports >>>
Scholia

Scholia is a service that creates visual scholarly profiles for topic, people, organizations, species, chemicals, etc using bibliographic and other information in Wikidata.

Scholia

it takes quite a bit of effort to update all the SPARQL queries (we have more than 300) to accommodate for the RDF graph split of @wikidata

Want to help? Check out https://www.wikidata.org/wiki/Wikidata:Scholia/Events/2025_11

#wikidata #scholia

Wikidata:Scholia/Events/2025 11 - Wikidata

Bei der etwas anstrengenden #Orcid Maske ist man ja versucht, seine Literatur einfach nur in #WikiData zu erfassen und im Orcid auf einen #Scholia Link zu verweisen. Nur hat man dort wiederum meist das Problem, dass die übergeordneten Werke zuerst modelliert werden müssen....