The Wikidata Knowledge Graph Explained: Items, SPARQL and Enterprise Use

The Wikidata knowledge graph is the largest openly licensed structured dataset on the web: 122,983,051 items, built through more than 2.5 billion edits by a community of roughly 41,000 active contributors. It sits behind answers you have almost certainly seen without knowing it — in Google search panels, in Siri, in Alexa.

It is also the best available reference model for anyone building a knowledge graph of their own. Wikidata solved, in public and at scale, most of the problems an organisation hits when it tries to make its own knowledge machine-readable: how to identify things unambiguously, how to record where a fact came from, how to handle statements that are true only for a period, and how to keep all of it queryable.

This guide explains what the Wikidata knowledge graph is, how items and statements are structured, how to query it with SPARQL — including the 2025 graph split that broke a lot of existing queries — and what it all means if you are considering an enterprise knowledge graph. We deployed Wikibase for the European Commission, so this is ground we have covered in production rather than in theory.

What Is a Knowledge Graph?

A knowledge graph stores information as a network of things and the relationships between them, rather than as rows in tables. The basic unit is a triple: subject, predicate, object.

Douglas Adams  —[educated at]→  St John's College
Douglas Adams  —[date of birth]→  1952-03-11
Douglas Adams  —[notable work]→  The Hitchhiker's Guide to the Galaxy

Chain enough of those together and you can answer questions no single table anticipated — "which authors educated in Cambridge wrote science fiction adapted for radio?" — because the relationships themselves are data you can traverse.

Knowledge graph vs relational database

A relational schema is designed around the questions you expect. Adding a genuinely new kind of relationship usually means altering tables and rewriting queries. In a graph, a new relationship is simply another edge; nothing else has to change.

That flexibility is the whole point. It is also why knowledge graphs suit messy, evolving, heterogeneous knowledge — exactly the kind most organisations actually have — and why they pair so well with AI, which we come back to below.

What Is Wikidata?

Wikidata is Wikipedia's sister project for structured data. Where Wikipedia holds prose written for humans, Wikidata holds facts written for machines — and does it once, centrally, in a language-independent way that all Wikipedia editions and any outside application can reuse.

The scale of it

According to Wikidata's own statistics page:

• 122,983,051 items — people, places, species, chemical compounds, works, events, organisations
• 2,533,498,484 edits since launch
• 40,907 active users maintaining it

Two things explain that trajectory, and both are worth stealing. The first is the editor community. The second is the software underneath: Wikibase.

How a Wikidata item is structured

Every item gets an opaque identifier beginning with Q, and every property one beginning with P. Douglas Adams is Q42; "instance of" is P31.

Opaque identifiers look unfriendly and are in fact the single most important design decision in the whole project. Q42 carries no language, no spelling, no assumption about what the thing is called. Labels in 300+ languages hang off the identifier; the identifier itself never has to change.

Q42  (labels: Douglas Adams / Douglas Adams / ダグラス・アダムズ ...)
  P31  instance of        →  Q5  (human)
  P106 occupation         →  Q214917 (playwright)
  P569 date of birth      →  1952-03-11
         ├─ qualifier  P1326 latest date  →  ...
         └─ reference  P248 stated in     →  Q36578

Three features of that shape matter far more than they first appear:

• Statements, not fields. An item can hold several competing values for the same property, each ranked.
• Qualifiers. Context on a statement — valid from, valid until, applies to which jurisdiction. Most real facts are only true under conditions.
• References. Where the claim came from. This is what separates a knowledge graph you can audit from a pile of assertions.

If you build an enterprise knowledge graph and skip qualifiers and references, you will rebuild them within a year. Every organisation eventually needs to answer "true as of when?" and "who says so?".

Who actually uses Wikidata

Search engines use it to populate entity panels. Voice assistants use it to answer factual questions. Libraries, museums and research institutions use it as shared authority control, so that their catalogue and someone else's can agree on which "Paris" is meant. It has become the de facto identifier hub of the open data web.

Wikibase: The Software Behind Wikidata

Wikidata is a website. Wikibase is the open-source software suite it runs on, maintained by Wikimedia Deutschland — and you can run it yourself.

Wikidata vs Wikibase

The distinction confuses people, so plainly:

• Wikidata is one specific, public, community-maintained knowledge graph.
• Wikibase is the software for building knowledge graphs of that kind — including private ones.

Wikibase gives you the same item/property/statement/qualifier/reference model, the same multilingual labels, the same edit history, and a SPARQL endpoint over your own data. Libraries, GLAM institutions, research consortia and public administrations use it precisely because the model has already been stress-tested at 123 million items.

Federation: keeping data where it belongs

Wikibase supports federation — your instance can reference Wikidata identifiers without copying Wikidata's content. You describe your own entities in your own instance and point at Q142 when you mean France, instead of maintaining your own list of countries forever.

For anyone with data-sovereignty obligations this is the key property: shared vocabulary, local control. Your sensitive records never leave your infrastructure, and they are still interoperable. It is the same principle we cover in what is private AI, applied to structured data. See also our note on running Wikidata as a local service.

Querying the Wikidata Knowledge Graph with SPARQL

A graph is only as useful as your ability to interrogate it. Wikidata exposes a public SPARQL endpoint at query.wikidata.org.

A first query

The ten largest cities in France, with labels in French:

SELECT ?city ?cityLabel ?population WHERE {
  ?city wdt:P31/wdt:P279* wd:Q515 ;   # instance of a (subclass of) city
         wdt:P17   wd:Q142 ;                # country: France
         wdt:P1082 ?population .            # population
  SERVICE wikibase:label { bd:serviceParam wikibase:language "fr,en" . }
}
ORDER BY DESC(?population)
LIMIT 10

Note wdt:P31/wdt:P279*. That property path means "instance of something which is, transitively, a subclass of city" — so you catch communes, municipalities and metropolises without enumerating them. Traversal like that is what you buy when you choose a graph.

The 2025 graph split — and why your old queries broke

This is the part most tutorials have not caught up with. On 9 May 2025 the Wikidata Query Service was split into two graphs, because scholarly-article data (WikiCite) had grown to more than half of all triples and Blazegraph could no longer scale to the whole thing.

• Main graph — query.wikidata.org — everything except scholarly articles.
• Scholarly graph — query-scholarly.wikidata.org — scholarly articles and related entities.

A transitional full endpoint existed until December 2025 and is now gone. So any query that needs both sides must use SPARQL federation explicitly:

SELECT ?work ?workLabel WHERE {
  # reach into the scholarly graph from the main endpoint
  SERVICE <https://query-scholarly.wikidata.org/sparql> {
    ?work wdt:P50 wd:Q42 .            # author: Douglas Adams
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}

The practical lesson generalises well beyond Wikidata: a knowledge graph that keeps growing will eventually force architectural decisions about partitioning and federation. Plan for it before it is urgent.

The Wikidata API

SPARQL is for questions about patterns. When you already know which entity you want, the REST and Action APIs are simpler and cheaper — fetch Q42, read its labels and statements, done. A rough rule: API for lookups, SPARQL for discovery. Both are free and rate-limited, so cache aggressively in production.

From Wikidata to an Enterprise Knowledge Graph

Most organisations have the same underlying problem Wikidata set out to solve: the same entity — a customer, a product, a regulation, a site — described differently in a dozen systems, with no shared identifier and no record of provenance.

Why organisations build one

• One identity per thing. A stable internal identifier that survives renaming and reorganisation.
• Questions across silos. Join CRM, ERP and documentation without a warehouse project per question.
• Provenance by default. Every fact carries its source, which is what makes it auditable.
• Grounding for AI. A curated graph is a far better substrate for an assistant than a folder of PDFs.

Four lessons Wikidata paid for already

1. Use opaque identifiers. Anything human-readable becomes wrong the moment something is renamed.
2. Model statements, not fields. Allow competing values with ranks; reality is rarely single-valued.
3. Make references mandatory early. Retrofitting provenance onto millions of facts is brutal.
4. Expect to partition. The 2025 split is what success looks like at scale.

Knowledge Graphs and LLMs: Why They Fit Together

Language models are strong at language and unreliable at recall. Knowledge graphs are the inverse: precise, structured, verifiable, and useless at conversation. Putting them together covers both weaknesses.

Grounding: the graph supplies the facts

Instead of asking a model to remember, you retrieve the relevant facts from the graph and ask it to answer from those, with the source attached. That shift — from recall to reading — is the single biggest lever on AI accuracy, as we set out in how accurate is ChatGPT. A graph makes it stronger still, because a retrieved triple is unambiguous in a way a retrieved paragraph is not.

Natural language to SPARQL

The other direction is just as useful: let the model write the query. A user asks a question in plain language, the system generates SPARQL, runs it against the graph, and answers from real results. The user needs no knowledge of P31 or Q515, and the answer is computed rather than recalled.

This is the problem QAnswer was originally built to solve, and it is why our AI assistants and APIs treat structured sources as first-class alongside documents.

Our Work with Wikidata and Wikibase

We are not commentators on this topic. We deployed a Wikibase instance for the European Commission and ingested a range of data sources into it, producing a public EU knowledge graph over European linked open data.

We also built WikidataComplete, which uses AI to propose new statements to Wikidata from unstructured text and puts each one in front of a human editor for approval — AI to find candidate facts, community to decide. And we connect assistants directly to MediaWiki and Wikibase instances, so an organisation's own wiki becomes a source an assistant can answer from, with citations.

If you want to explore what a graph plus an assistant looks like over your own content, the same machinery is available through our integrations — deployable on-premise or in a private cloud, which for public-sector and regulated work is usually the requirement that decides everything else. See data sovereignty.

Frequently Asked Questions

What is the Wikidata knowledge graph?

It is a free, collaboratively edited knowledge graph of 122,983,051 items, storing facts as structured statements with qualifiers and references rather than as prose. It is queryable via SPARQL and reused by search engines, voice assistants and cultural institutions worldwide.

How big is Wikidata?

122,983,051 items, built from over 2.53 billion edits by about 40,900 active users, per Wikidata's statistics page. Scholarly-article data alone grew to more than half of all triples, which is what forced the 2025 query-service split.

What is the difference between Wikidata and Wikibase?

Wikidata is one public knowledge graph. Wikibase is the open-source software it runs on, which anyone can deploy to build their own — publicly or entirely privately.

Is Wikidata a knowledge graph or a database?

Both, in a sense: it is stored in a database and modelled as a graph. What makes it a knowledge graph is the shape — entities connected by typed relationships, with provenance on the statements — rather than the storage technology.

How do I query Wikidata?

Use SPARQL at query.wikidata.org for pattern-based questions, or the REST and Action APIs when you already know the entity. Since May 2025, queries touching both the main and scholarly graphs need SPARQL federation.

Why did the Wikidata Query Service split into two graphs?

Scholarly-article data had grown past half of all triples and the Blazegraph backend could no longer scale to the full dataset. Since 9 May 2025 the main graph is served at query.wikidata.org and the scholarly graph at query-scholarly.wikidata.org; the transitional full endpoint was retired at the end of 2025.

Can I build a private knowledge graph like Wikidata?

Yes — that is exactly what Wikibase is for. You get the same data model and a SPARQL endpoint over your own content, can federate with Wikidata identifiers for shared concepts, and can host everything inside your own infrastructure.

How do knowledge graphs improve AI answers?

They give the model verifiable facts instead of asking it to recall. Retrieved triples are unambiguous and carry provenance, so answers can be traced to a source — and the model can be asked to generate SPARQL so users query the graph in plain language.

Where to Start

The Wikidata knowledge graph is worth understanding twice over: as the largest open structured dataset you can build on for free, and as a working reference design for a knowledge graph of your own. The identifier discipline, the statement model, the insistence on references — those are the parts to copy.

And once the graph exists, an AI assistant on top of it stops being a plausible-sounding text generator and becomes something that answers from facts you can point at.

‍

Build an AI assistant over your own knowledge — documents, wikis or knowledge graphs — with QAnswer. Explore our AI Assistants, our MediaWiki integration and our full list of integrations.

Learn more at www.qanswer.ai

Working on a knowledge graph project? Contact us or email info@the-qa-company.com