Cas d'usage et contexte
Wikidata est souvent cité comme exemple de Knowledge graph RDF. En réalité il ne l’est pas nativement. Il n’est pas davantage structuré par une ontologie OWL formelle, pas plus qu’il ne fait fonctionner de raisonneurs ou de règles logiques. Toutefois, c’est un cas d’usage pertinent à étudier à plus d’un titre. De par son volume de données et les problématiques de performance de requêtes SPARQL, fédérées ou non ainsi que pour la réconciliation de données, avec ou sans identifiants.
Wikidata est la base de connaissances structurée collaborative du mouvement Wikimédia, lancée en 2012. C’est l’un des plus grands graphes de connaissances publics au monde. Il est librement accessible via un endpoint SPARQL public, le Wikidata Query Service (WDQS).
L’interrogation de la propriété « Number of triplets » (P10209) de Wikidata (Q2013) donne un résultat de 15 019 727 427 pour la date d’août 2023, pour le dump RDF complet, qualificatifs et références inclus. Cette propriété n’a pas été mise à jour depuis. Toutefois, une étude de benchmark académique (workshop Wikidata 2025) situe le dump complet à ~20 milliards de triplets dès octobre 2024 (source : Patel-Schneider, Benchmarking SPARQL Engines on Wikidata Queries, wikidataworkshop.github.io/2025). Le dump complet en Turtle représentait alors 100GB compressé et 850 non compressé. A noter que l’étude soulignait alors la rapidité de chargement de QLever (4,5 heures), le plus rapide, contre dix jours avec Blazegraph, le plus lent.
Choix de modélisation et architecture
Modèle de données
Wikidata utilise le modèle de données Wikibase, propre à Wikimédia, qui ne repose pas sur OWL. Il n’y a ni ontologie OWL formelle avec axiomes de description logique, ni raisonnement automatique (aucun raisonneur OWL n’est activé). Les entités sont identifiées par des Q-items (entités) et P-items (propriétés) reliés par des « statements » assortis de qualificatifs et de références. Ce n’est pas un profil OWL, mais il existe une taxonomie légère via rdfs:subClassOf, wdt:P31 (instance of) et wdt:P279 (subclass of).
Wikidata est d’abord un wiki fonctionnant sur MediaWiki, avec une structure. Les entités sont stockées comme des pages MediaWiki, avec un backend de persistance MariaDB/MySQL. Wikidata réalise néanmoins un export RDF/TTL sous forme de dump, régulièrement mis à jour.
La mise à jour en continu : du wiki au flux RDF
Ce dump périodique ne doit pas être confondu avec la mise à jour en continu. WDQS est alimenté en parallèle par un Streaming Updater bâti sur Apache Flink et Kafka. Chaque édition sur Wikidata déclenche un événement (via le flux de changements MediaWiki), le job Flink calcule le diff RDF correspondant et le pousse sur un topic Kafka, qu’un consommateur applique ensuite sur le triplestore. Ce mécanisme est déployé en production depuis 2021.
On a donc affaire à un très large ensemble de données en RDF. C’est, plus proche, en pratique, d’une base de données relationnelle interrogeable par SPARQL que d’un Knowledge graph avec une dimension logique. En revanche, cela permet d’interroger, via des requêtes SPARQL fédérées, Wikidata et d’autres bases simultanément. C’est utile, notamment pour la réconciliation d’entités, mais c’est très loin de l’automatisation d’agents dits « autonomes » capables de prendre des décisions.
Volume de données et migration
En mai 2025, Wikidata ayant atteint en grossissant une taille ne permettant plus à une seule instance du WDQS de gérer le volume de requêtes, le graphe unique a été scindé en deux endpoints distincts. L’un dessert un graphe principal l’autre est dédié aux données bibliographiques issues du projet WikiCite. Comme l’indique cette page de wikidata , ces données « scholarly » représentaient à elles seules plus de 50% des triplets du graphe Wikidata. Elles peuvent désormais être interrogées via https://query-scholarly.wikidata.org/. Le graphe principal est mécaniquement plus petit que celui d’avant scission.
Jusqu’à présent, Wikidata s’appuyait sur le triplestore open source Blazegraph pour l’interrogation en SPARQL via WDQS. Or les mises à jour de Blazegraph ont significativement ralenti depuis le rachat, en 2018, des équipes SYSTAP, du nom de domaine et de la marque par Amazon. La version open source ne suffit plus à assurer des conditions d’accès et d’interrogation satisfaisantes, alors que le volume de Wikidata n’a cessé d’augmenter depuis l’origine.
De Blazegraph à QLever : pourquoi migrer ?
Une migration vers QLever a été engagée après une évaluation communautaire comparative (face à Virtuoso notamment). C’est un moteur open source Apache 2.0, capable d’indexer et d’interroger plus d’un trillion de triples sur un seul serveur, gérant nativement la recherche plein texte combinée aux requêtes structurées, et conforme SPARQL 1.1 (y compris SPARQL Update). Le déploiement en production reste toutefois progressif et phasé à ce stade : il ne s’agit pas d’un basculement déjà achevé.
QLever ne change pas le niveau sémantique de Wikidata : il améliore les performances et la scalabilité du triplestore, mais Wikidata reste sans ontologie OWL ni raisonnement formel après migration. Pour autant, la base de connaissance est une source d’information pour de nombreux cas d’usage.
Wikidata comme outil d’interopérabilité pour des communautés scientifiques
On peut interroger Wikidata via WDQS pour étendre sa connaissance d’un sujet en cherchant toutes les informations reliées. Pour peu que l’on sache ce que l’on cherche, la traduction d’une logique d’exploration en requêtes SPARQL peut conduire à collecter beaucoup de données pertinentes dans des domaines où une communauté active les met à jour.
WikiPathways permet d’illustrer l’usage communautaire de Wikidata et comment la base de connaissances sert à l’intégration de données biomedicales à grande échelle. WikiPathways est une plateforme collaborative dédiée à la curation de voies biologiques, utilisée activement par des centaines de chercheurs qui y contribuent régulièrement. Au-delà de la seule visualisation, Elle exploite les identifiants Wikidata comme couche d’interopérabilité pour mapper automatiquement des milliers de gènes, protéines, métabolites et composés chimiques entre des dizaines de bases de données (KEGG, Reactome, ChEBI, PubChem, UniProt, NCBI, DrugBank, etc.). Cette fonction de résolution d’identifiants est au cœur de son utilité pratique.
Grâce à un modèle de données centralisé et systématique dans Wikidata des scripts génériques aident les biologistes à traduire n’importe quel identifiant d’un système vers un autre via une simple requête SPARQL. En pratique, cela signifie qu’un chercheur peut partir d’une liste de gènes issus de son RNA-seq (identifiants Entrez ou Ensembl), les convertir via Wikidata en métabolites correspondants (ChEBI) puis interroger les voies affectées dans WikiPathways le tout de manière automatisée. C’est un workflow réel, qui illustre concrètement le rôle de Wikidata comme couche de résolution d’identifiants inter-bases.
Wikidata et la réconciliation d’entités au-delà des communautés scientifiques
La réconciliation d’entité (entity reconciliation, aussi appelée entity resolution ou record linkage) consiste à déterminer si deux enregistrements provenant de sources différentes font référence au même objet du monde réel : une personne, un lieu, une œuvre, une organisation, etc.
Dans l’écosystème du web de données, cela prend une forme très concrète : on cherche à lier des données locales (un tableau CSV, un catalogue de bibliothèque, une base de produits) à des identifiants stables et partagés, comme les items de Wikidata (Q42 = Douglas Adams, Q90 = Paris, Q1266546 = record linkage, etc.). Cela permet :
- De désambiguïser des chaînes (« Paris » la ville vs « Paris » l’œuvre homérique).
- D’enrichir ses données avec les propriétés disponibles dans Wikidata (coordonnées, dates, identifiants externes comme IMDb, VIAF, ISBN…).
- De publier des données liées (Linked Open Data).
Le protocole de réconciliation (Reconciliation API)
L’outil Open Source OpenRefine (anciennement Google Refine) a défini un protocole, désormais standardisé, pour les services de réconciliation. Il s’agit du Reconciliation Service API (spec : reconciliation-api.github.io/specs/). Ce protocole expose quatre fonctionnalités principales, décrites ci-dessous.
- Réconciliation: Envoyer une ou plusieurs chaînes de caractères et recevoir en retour des candidats (ex : entités Wikidata) avec un score de correspondance
- Data extension: Une fois les entités rapprochées, récupérer les valeurs de propriétés Wikidata souhaitées (P19 = lieu de naissance, P569 = date de naissance, etc.).
- Preview: Afficher un aperçu HTML d’une entité candidate.
- Suggest : Autocompletion pour rechercher des entités et des propriétés
OpenRefine dispose également d’une extension Wikidata dédiée qui ajoute des fonctionnalités spécifiques : création de schémas QuickStatements pour écrire dans Wikidata en batch, gestion des labels/descriptions/aliases par langue, etc.
On trouvera sur la page OpenRefine « reconciling » toutes les informations nécessaires pour procéder.
OpenRefine n’est pas le seul outil disponible pour cette réconciliation. Tout outil compatible avec le protocole précité peut s’interfacer avec n’importe quel service qui l’implémente, pas seulement Wikidata. Ainsi OpenRefine propose plusieurs services de réconciliation avec d’autres sources que Wikidata.
Conclusion
Wikidata est sans doute le cas d’usage le moins abouti de ma série sur les axes modélisation sémantique et raisonnement. Mais son volume et son approche collaborative, portée par les communautés Wikimedia, en font un cas industriel de dataset RDF largement exploitable. Le volume de données présentes dans Wikidata en fait de facto un hub de réconciliation indispensable à considérer. En particulier, du fait de la présence d’identifiants associés aux entités tels que des ISBN, DOI, VIAF, ou identifiants ROR, qui permettent une réconciliation exacte en interrogeant Wikidata via SPARQL. De plus en implémentant les SPARQL federated queries, il y a possibilité de croiser des données en direct.
Toutefois, le Wikidata Query Service ne permet la fédération (clause SERVICE) qu’avec des endpoints SPARQL approuvés dans une liste blanche (l’« Allowlist ») pour protéger la stabilité et la performance du service. Aussi, pour requêter un KG non approuvé, la solution est d’interroger depuis son propre endpoint SPARQL (Virtuoso, GraphDB, Fuseki, etc.) en faisant SERVICE vers Wikidata, et non l’inverse.
Le prochain cas développé sera celui de LinkedIn, une approche qui a choisi l’orientation statistique plutôt que schéma et raisonnements formels logiques.