Wikidata › What Wikidata Couldn't Solve

Wikidata expanded what language AI systems could do, but it wasn't perfect. Like any system built on collaborative editing and structured data, it faced fundamental limitations. Let's be honest about what it couldn't do well.

The open editing model that made Wikidata scalable also created quality control challenges. Anyone could edit, which meant errors, vandalism, or biased information could slip into the knowledge base. While the community worked diligently to maintain accuracy, incorrect contributions could persist for hours, days, or sometimes weeks before someone noticed and corrected them.

This wasn't a theoretical problem. In practice, it meant applications couldn't blindly trust Wikidata without verification. A question-answering system might retrieve factually incorrect information if someone had vandalized a page or made an honest mistake. The community review process eventually caught these errors, but there was always a window of vulnerability.

The collaborative model created headaches with controversial or disputed information. For topics where there was legitimate debate or multiple perspectives, Wikidata's requirement to represent facts objectively sometimes clashed with different interpretations of what constituted factual truth.

Consider territorial claims. Is Taiwan a country or a province of China? Different communities disagree about what the facts are. Wikidata had to represent these disputes while maintaining a neutral knowledge base.a nearly impossible task when the "facts" themselves are contested.

Disputes over how to represent information about contentious political events, historical controversies, or cultural claims revealed the difficulty of maintaining neutrality when different communities held incompatible views.

Wikidata excelled at representing well-documented entities like historical figures, geographical locations, or scientific concepts with established Wikipedia articles. But coverage was uneven:

• Obscure entities: Small towns, minor historical figures, niche scientific concepts often had incomplete or missing information
• Recent events: New entities took time to be added and properly documented
• Specialized domains: Highly technical fields required expert contributors who might not be active in the Wikidata community
• Geographic bias: Detailed data about European capitals, sparse information about small towns in Africa or Asia

The knowledge base's coverage reflected the interests and expertise of its contributors. If no one in the community cared about a particular domain, that domain remained poorly represented.

The entity-property-value model worked beautifully for discrete, objective facts:

• Birth dates: March 11, 1952 ✓
• Population: 2.1 million ✓
• Chemical formula: H₂O ✓

But it struggled with subjective or context-dependent information:

• "This person was influential during this period" - How do you quantify "influential"?
• "This concept is controversial among scholars" - How do you represent degrees of controversy?
• "This artwork is considered a masterpiece" - By whom? According to what criteria?

Some knowledge is inherently fuzzy, contextual, or conditional. Representing qualitative assessments, opinions, or contextual interpretations required workarounds or simplifications that might lose important subtleties.

While Wikidata's structure was language-agnostic, the labels and descriptions provided by contributors reflected the linguistic diversity of the editing community. This created imbalances:

• Entities of interest to English-speaking contributors: multilingual labels in dozens of languages
• Entities primarily of interest to speakers of less-represented languages: labels only in those languages, maybe a few others

This imbalance created barriers for applications requiring consistent multilingual support across all entities. A multilingual application might work great for well-known entities but fail for obscure ones that lacked labels in the target language.

As the knowledge base grew to millions of items and billions of statements, computational challenges emerged. Querying the full knowledge graph required significant computational resources. While the SPARQL interface provided powerful querying capabilities, the sheer scale of the data meant that some queries could be slow or require careful optimization.

Complex queries involving multiple joins and filters could take seconds or even minutes to execute. For real-time applications, this was problematic. Applications often needed to work with subsets of the data or pre-computed indexes rather than querying the live database directly.

The knowledge base evolved constantly. Properties and items could be merged, deleted, or restructured as the community refined the knowledge organization. This created challenges for applications:

• An application built on specific identifiers might break when items were merged
• Property structures might change, requiring code updates
• Queries that worked yesterday might fail today if the underlying data structure changed

While Wikidata tracked change history, maintaining compatibility with evolving data structures required ongoing maintenance from application developers. The knowledge base was a moving target, and applications needed to move with it.