Wikidata, the open knowledge graph sister to Wikipedia, is undergoing major changes in 2025 as the Wikimedia Foundation splits its data into two graphs. One of the split pieces is essentially the data of the WikiCite project, which is an initiative expanding the use of Wikidata as a platform for scholarly information. Due to WikiCite's success, it accounts for over 50% of the triples on the Wikidata graph. This split was motivated by challenges in scaling up the Wikidata SPARQL Query Service, which relies on Blazegraph, a technology unsuited for Wikidata's current scale and growth rate. While the split has been prepared since 2021, this large infrastructure change has wide implications both for community tools which use WikiCite data, such as the Scholia platform, as well as for core functionalities of Wikidata, such as systems that detect duplicate items and constraint violations. In this paper, we present an overview of the infrastructure available on Wikidata for querying scholarly information and how it serves the community endeavours related to the WikiCite initiative. In particular, we focus on the Wikidata Query Service split, its motivations, and its impacts for those intending to use Wikidata as a source of semantic scholarly data. We present the alternatives for rewriting or redirecting broken queries, making explicit the rules of the graph split, and when federated queries are now required, guiding stakeholders on how to adapt to the new infrastructure.
Wikidata has matured as a core resource in the Linked Open Data ecosystem for academic information. As of 2025, the platform has become part of workflows in biocuration and scholarmetrics, collecting identifiers, disambiguating names, and providing a Query Service to gather information from a single access point.
The WikiCite project has scaled the capacity of Wikidata to host metadata about publications,
bringing semantics to the handling of citations in the Wikimedia ecosystem [
The statements on Wikidata are retrievable in diferent ways. Data is openly available with CC0
dedication, and access options range from complete dumps [
Wikidata hosts an oficial endpoint with a graphical interface, known as the "Wikidata Query Service" (WDQS). The web interface of the query service, available at https://query.wikidata.org, facilitates the writing of queries by providing autocompletion, syntax highlighting, and showcasing examples. The
WDQS also provides a rich set of default visualizations, including image grids, interactive maps, bar
charts, and timelines, which can be embedded directly into web pages using <iframe> tags. The WDQS
is updated nearly in real time, with query results usually reflecting changes within minutes or even
seconds of the information coming to the platform. [
Powerful as it is, the community widely uses the Wikidata Query Service, and embedding its results
is common practice. Of note, the Scholia platform for presenting and curating scholarly information
relies heavily on WDQS and its standardized, plug-and-play visualizations [
In 2015, the query service was launched by the Discovery Department at the Wikimedia Foundation
[
Even if carefully planned, such a change brings a number of challenges to Wikidata. Here, we describe
the graph split from a WikiCite perspective, documenting it with a focus on the academic community
relying on the Wikidata infrastructure. A more complete version of the discussion is documented on a
living Meta-Wiki page [
As of August 2025, the technical rules for the split [
Included in the scholarly graph are all triples for items that either (1) contain a (non-deprecated)
statement with the property "publication type of scholarly work" (P13046) or (2) have a (non-deprecated)
value for "instance of" (P31) that matches any one out of 49 scholarly QIDs. This list includes "scholarly
article" (Q13442814) and 24 subclasses of it, "thesis" (Q1266946) and 15 subclasses of it, plus "erratum"
(Q1348305), "dissertation" (Q1385450), "comment" (Q58897583), "research report" (Q59387148), "field
study report" (Q1402850), "conference poster" (Q54670950), "scientific note" (Q114613919) and, perhaps
surprisingly, "Bachelor of Literature" (Q112585758). These QIDs were selected by the Search Platform
team from a list containing over 4000 values [
There are around 77 million items on the main graph and 45 million items on the scholarly graph. The information on these scholarly works is particularly rich, corresponding to 8.7 billion triples, while the main endpoint hosts slightly less, with around 8.4 billion.
It is often not trivial to know in which endpoint a particular query should be run, as query results may
be split across diferent graphs. To aid users in rewriting queries, we developed a simple online checker
for verifying queries across the Wikimedia-hosted endpoints [
For SPARQL queries needing both graphs, internal federation is necessary. Its usage is being
documented collaboratively in the Internal Federation Guide [
SELECT ? a r t i c l e T y p e ? a r t i c l e T y p e L a b e l WHERE { SERVICE wdsubgra ph : s c h o l a r l y _ a r t i c l e s { wd : Q 4 1 7 9 9 1 9 4 wdt : P31 ? a r t i c l e T y p e } SERVICE w i k i b a s e : l a b e l { bd : s e r v i c e P a r a m w i k i b a s e : l a n g u a g e " en " . } }
The split does not afect functionalities of Wikidata that are independent of the Wikidata Query Service. For example, requests via the REST API or the Action API should not be changed.
There are assessments of growth on multiple parts of Wikidata, including discussions on the limits
of the platform and on extra regulation of mass edits [
This paper discusses the Wikidata Query Service graph split from a WikiCite perspective, providing the
community with resources to navigate the changes. A longer, multilingual version of the presented FAQ
is available on the Meta page for WikiCite [
During the preparation of this work, the author(s) used Grammarly, ChatGPT in order to: Grammar and spelling check, Formatting assistance. After using these tools/services, the authors reviewed and edited the content as needed and take full responsibility for the publication’s content.