Wikidata › The Problem: When Knowing Isn't the Same as Understanding

Imagine you're a computer in 2012, and someone asks you: "What is the capital of France?" You have access to all of Wikipedia.millions of articles containing the answer. But here's the catch: you can't just "know" the answer. You need to find it, extract it, and verify it, all from unstructured text written for humans.

You start by searching Wikipedia articles. You find the France article, which says "Paris is the capital and most populous city of France." Great! But wait.you're a computer. To you, this is just a string of characters. You need to:

1. Parse the natural language to understand sentence structure
2. Identify that "Paris" and "France" are entities (not just random words)
3. Recognize that "capital" describes a relationship between them
4. Extract this relationship accurately
5. Verify this is trustworthy information

This process is slow, error-prone, and computationally expensive. And you have to repeat it every single time someone asks the question. There's no way to store "Paris is the capital of France" as a fact you can just look up instantly.

Before Wikidata, knowledge bases existed, but they all had serious limitations. Let's look at what was available:

WordNet (which we encountered back in 1995) captured relationships between words.synonyms, antonyms, hypernyms (is-a relationships). You could learn that "city" is a type of "municipality," or that "car" and "automobile" mean the same thing. But WordNet didn't know that Paris is a city, or that it's the capital of France. It understood word relationships but not facts about specific entities in the world.

DBpedia tried to solve this by extracting structured data from Wikipedia's infoboxes.those summary boxes you see on the right side of Wikipedia articles. If an article had an infobox with "Capital: Paris," DBpedia would extract that relationship. But this approach was brittle. Infoboxes had wildly different formats across articles and languages. The extraction process often failed or produced errors. And if an infobox was missing or incomplete, DBpedia had no way to extract that information from the article text.

The different language editions made the problem harder. Information about Paris existed in English Wikipedia, French Wikipedia, German Wikipedia, and hundreds of other editions, but there was no systematic way to connect these representations or keep them consistent.

To a computer, "Paris" in English Wikipedia, "Paris" in French Wikipedia, and "Paris" in German Wikipedia were three completely separate entities. There was no unified identifier saying "these all refer to the same city." A question-answering system needed separate knowledge bases for each language, duplicating effort and creating maintenance nightmares.

Even worse, the same entity might have different information in different languages. English Wikipedia might say Paris has 2.1 million people, while French Wikipedia says 2.2 million. Which is correct? How do you keep them synchronized? If the population changes, someone needs to manually update hundreds of articles across dozens of languages. Good luck with that.

Wikipedia's collaborative editing model.its greatest strength.created a unique challenge for structured data. Editors could add factual information to articles, but that information was embedded within paragraphs and sentences. There was no centralized way to update facts that appeared in multiple articles.

Consider what happens when Paris's population changes. That fact appears in:

• The Paris article
• The France article
• The "List of European capitals" article
• The "Most populous cities in France" article
• Potentially hundreds of other articles
• Across 300+ language editions

Someone would need to manually find and update every single occurrence. Inevitably, some would be missed, creating inconsistencies. You'd end up with different articles claiming different populations for the same city.

For AI systems attempting to reason about the world, these limitations were particularly painful. Language models trained on text could generate plausible-sounding responses, but they lacked mechanisms to verify facts or access authoritative knowledge sources.

A model might confidently state that the capital of France is Lyon because it had seen that city name appear frequently in contexts mentioning France. Or it might say Paris has 10 million people because it confused the city population with the metropolitan area. Without structured knowledge bases that could be queried and validated, language AI systems struggled with factual accuracy and reliability.

The computational cost added insult to injury. Each time an application needed to answer a factual question, it would need to:

• Process large amounts of text
• Run natural language processing to extract information
• Verify accuracy across multiple sources
• Deal with inconsistencies and ambiguities

This consumed significant computational resources and introduced latency that made real-time applications impractical. A centralized, structured knowledge base could be indexed, cached, and queried efficiently, answering questions in milliseconds instead of seconds or minutes.

The field needed a better way to represent knowledge.one that was structured, queryable, multilingual, collaboratively maintained, and accessible to machines. That's exactly what Wikidata would provide.