Modèle de données de Wikidata, Charlie Kristschmar, CC0
Ce billet fait partie d'une série de quatre billets qui visent à proposer un bilan de plus de 12 ans de travail avec les technologies du Web sémantique, « Les technos du Web sémantique ont-elles tenu leurs promesses ? » :
Si, à travers les différents cas d’implémentation des technologies du Web sémantique décrits dans le précédent billet, les promesses sont globalement tenues, force est de constater que les problèmes qui se posent en limitent aujourd’hui le déploiement à large échelle ou en dehors de marchés de niche clairement identifiés :
Malgré ces limites, certaines initiatives, projets ou usages ont réussi à se dégager et viennent valider certains aspects des technologies du Web sémantique.
Wikidata est un projet de la Wikimedia Foundation développé à partir de 2012 à l’initiative de l’association Wikimedia Deutschland. Son objectif initial était de centraliser et faciliter la maintenance des données structurées des Wikipedias (liens interlangues, infobox, catégories, coordonnées géographiques, liens vers des fichiers d’autorité). Ainsi, Wikidata est aux données structurées ce que Wikimedia Commons est aux médias : un centralisateur d’informations au service des Wikipedias. A l’origine, le projet est donc bien ancré dans la communauté Wikipédienne à son service direct. En ce sens, il se différencie nettement d’un autre projet auquel il est souvent comparé : Dbpedia, initiative issue de la recherche, apparue en 2007, dont l’objectif était directement lié à l’exposition des données structurées des Wikipedias selon les principes du Linked Data.
Wikidata reprend les principes qui ont fait le succès de Wikipedia : tout un chacun peut contribuer librement et l’ensemble des donnés est associé à une licence libre, dans ce cas la Creative Commons Zero (assimilable à la notion de domaine public). Les différences se situent évidemment dans les informations : là où Wikipedia propose des textes et Wikimedia Commons des médias, Wikidata propose des données structurées sous la forme de déclarations.
Ainsi, chaque page est associée à une entité dont l’identifiant est unique et opaque (sauf dans quelques rares cas qui relèvent plutôt de l’easter egg, cf. l’exemple ci-dessous). Les entités sont décrites par des libellés localisés (c’est-à-dire associés à une langue), une description localisée, des libellés alternatifs eux aussi localisés et un ensemble de déclarations dont la propriété fait partie d’une ontologie déterminée par la communauté au fur et à mesure. Les valeurs peuvent être des liens vers d’autres entités de Wikidata ou des chaînes de caractères typées. Jusque là, le modèle ressemble à RDF. Là où il s’en écarte, c’est dans la possibilité d’associer à chaque déclaration des références pour la sourcer (reprenant ainsi le principe des notes de bas de page présentes dans les Wikipedia) et des qualificatifs pour la préciser, ce qui résout le gros problème de contextualisation du modèle RDF.
Modèle de données de Wikidata, Charlie Kristschmar, CC0
Si Wikidata n’est pas structuré selon le modèle RDF, le projet a, en revanche, choisi SPARQL comme langage de requêtes et protocole d’interrogation. Ce choix fait suite à différentes études. Ainsi, les données des entités sont traduites dans un modèle RDF spécifique et, à chaque mise à jour, sont indexées dans un triple store, en l’occurrence le logiciel Blazegraph. Avec l’importance que prend petit à petit Wikidata, le choix de SPARQL pour Wikidata justifie à lui seul l’apprentissage de ce langage de requêtes.
En effet, les objectifs initiaux de Wikidata ont été rapidement dépassés, car ce projet répondait à de nombreux défauts des autres projets existants en la matière. Par rapport à Dbpedia, il présentait l’avantage d’être mis à jour en temps réel (Dbpedia est mis à jour tous les 6 mois…), d’offrir une qualité de service bien supérieure et de proposer une structuration des données plus rigoureuse, dbpedia étant issu de données dont l’objectif n’était pas celui d’alimenter une base de données structurées à l’origine. Comparé à Freebase, initiative lancée par la société Metaweb rachetée par Google en 2010, ce projet présentait l’avantage d’être porté par une communauté libre clairement établie. Bref, Wikidata est devenu LE projet de base de connaissances libre et ouvert que tout le monde attendait : le chaînon manquant de la gestion des connaissances. Il n’est donc pas étonnant que Wikidata soit rapidement devenu un hub supplantant peu à peu Dbpedia en tant que centre des alignements de référentiels divers à travers le monde. Ce rôle me semble évoluer peu à peu ces derniers temps : d’un hub de références, Wikidata tend à devenir un réceptacle des données elles-mêmes. Ainsi, à l’image du Musée St Raymond de Toulouse, les institutions vont être peu à peu tentées de mettre directement leurs données dans Wikidata. Et le projet WikiCite, qui vise à centraliser les références bibliographiques pour les Wikipedias, risque fort d’accélérer ce mouvement.
Ironie de l’histoire, alors que le Linked Open Data souhaitait mettre en relation des données hétérogènes et décentralisées chez différents fournisseurs, il aura suffi de 5 ans pour que les utilisateurs commencent à recentraliser leurs données au sein d’un espace unique.
Et pour vous convaincre de l’importance de ce projet, il suffit de voir l’implication de Google : mécène du projet à l’origine, ils ont recruté son développeur principal, Denny Vrandečić, lorsque le projet a été stabilisé. Et pour cause : grâce au rachat de la société Metaweb, Google a disposé non seulement d’une technologie de graphe scalable (qui ne suivait pas non plus précisément le modèle RDF…) mais aussi d’une base de connaissances déjà conséquente. C’est sur cette base que Google a commencé à construire le Knowledge graph, un autre exemple de base de connaissances centralisé bâti sur le modèle de graphe sans utiliser RDF. Ils ont rapidement compris qu’ils ne pourraient convaincre la communauté de poursuivre l’alimentation de Freebase, car cela revenait à travailler directement pour eux. Ils ont donc intelligemment proposé de reverser le contenu de Freebase dans Wikidata et ils ont accompagné la mise en place de Wikidata. Permettre l’éclosion de Wikidata, c’était aussi pour Google un moyen d’assurer une mise à jour de son graphe de connaissance, même si bien évidemment Wikidata n’est pas la seule source de ce knowledge graph.
Et, parmi les différentes sources de données qui alimente le Knowledge graph de Google, on trouve en bonne place les données structurées mises à disposition par les sites eux-mêmes sur les recommandations de Google dans l’objectif d’améliorer pour le producteur du site l’affichage des résultats dans le moteur de recherche. Quel changement quand on se souvient d’articles ou d’avis de certains ingénieurs de Google sur l’intérêt des données structurées au sein des pages Web...
Ce doute longtemps entretenu chez Google explique certainement pourquoi cette innovation n’a pas été portée par Google mais par Yahoo. Petit retour en arrière : en 2008, Yahoo lance SearchMonkey, une plateforme qui permet aux sites de proposer des plugins pour améliorer la présentation de leurs résultats sur le moteur de recherche de Yahoo en exploitant les données structurées à l’intérieur des pages Web. Il recommande alors l’utilisation de RDFa ou des microformats. Cette innovation de Yahoo est un véritable « game changer ». Google réplique dès l’année suivante avec les rich Snippets. Mais, l’un comme l’autre font face à un problème de taille : la normalisation du vocabulaire. C’est la raison pour laquelle Google, Yahoo et Microsoft vont s’allier pour proposer un vocabulaire commun. Préparé dans le plus grand secret, Schema.org voit le jour en 2012.
Dès l’origine, le projet vise à proposer un vocabulaire unique pour encoder les données structurées à l’intérieur des pages Web. La force de frappe de ces trois sociétés suffit à en faire un standard immédiat, d’autant que la promesse est à la hauteur : une meilleure visibilité dans leurs résultats de recherche par une mise en valeur du contenu. Il préconise alors RDFa et Microdata, standard concurrent mis au point dans le cadre de HTML5. Peu à peu, Json-LD qui permet de sérialiser du RDF avec la syntaxe Json, s’est imposé car il s’est avéré plus simple et moins intrusif de proposer des données encodées en Json-LD dans un bloc unique d’une page Web plutôt que d’insérer le RDFa à l’intérieur du balisage HTML.
Avec Schema.org, c’est d’abord le spectre de l’ontologie universelle qui revient au galop, d’autant que ce vocabulaire sort tout droit des trois plus grosses entreprises du secteur de l’époque, autant dire des caves des enfers. Pour calmer le jeu, la maintenance de Schema.org est placé d’abord sous l’égide du W3C et un pionnier du Web sémantique, Dan Brickley, en devient le mainteneur officiel. Employé par Google peu de temps après, il parvient à apaiser les craintes et à fédérer les énergies pour faire avancer depuis six ans cette initiative. Et force est de reconnaître que cela fonctionne.
Tout ça pour ça ? Permettre aux moteurs de recherche de récupérer plus facilement de la donnée structurée pour améliorer la visibilité des résultats de recherche (et surtout leur permettre d’alimenter leur knowledge graph à moindre frais…). Il semblerait bien que schema.org soit le seul exemple d’utilisation des technologies du Web sémantique à très large échelle. Et, après tout, comme le rappelle Dan Brickley, n’est-ce pas la vocation initiale de ces technologies ?
RDF was designed as a data interchange framework; what you do in the privacy of your own database is your own business
— Dan Brickley (@danbri) 16 septembre 2018
Comme nous l’avons vu précédemment, la plupart des utilisateurs souhaite des mécanismes simples et efficaces pour récupérer les données. L’enjeu de l’Open Data (qui, au passage, n’est pas une fin en soi de la production de données…) étant de permettre la réutilisation, il paraît contre-productif pour les organisations de ne pas répondre aux besoins des utilisateurs et de s’entêter à exposer les données selon les principes du Linked Data. C’est d’autant plus vrai que les coûts pour maintenir ce genre de systèmes sont plus élevés que la simple mise à disposition de jeux de données en CSV voire en XML ou en Json.
De plus, publier des données selon les principes du Linked Data implique des responsabilités. En effet, à partir du moment où les données sont liées par d’autres, les questions habituelles de maintien des URIs se posent. Or, on constate, en particulier dans le milieu de la recherche, que de très nombreuses initiatives d’exposition des données ont aujourd’hui disparu, emmenant avec elles non seulement les identifiants mais aussi les données elles-mêmes. Gageons que les initiatives autour des données de la recherche, en particulier le FAIR, vont offrir les moyens d’exposer les données de manière durable.
Un des moyens de poursuivre le développement du Linked Open Data passera immanquablement par la centralisation de ces données dans quelques « hubs » qui seront capables d’exposer selon les principes du Linked Data (ou sous d’autres formes d’ailleurs...) pour mutualiser les coûts de développement, de maintien en condition opérationnelle et de ressources humaines.
LOD cloud Diagram (Version de 2014), CC-BY
Il en va de même dans le milieu patrimonial : Gallica en France, Europeana en Europe, VIAF dans le monde, pour n’en citer que trois, jouent déjà le rôle d’agrégateur de données et/ou de contenus. Il paraît logique qu’ils offrent aussi ce service d’exposition que les plus petites organisations n’auraient pas moyen de se payer.
Mais, est-ce bien nécessaire ? Oui à condition qu’on reconnaisse politiquement à ces organisations, indépendantes de tout organisme privé ou communautaire, la mission d’exposer des données garantissant un haut niveau de description et de structure (impossible en CSV)... Pour l’instant, ces organisations en sont convaincues mais pour combien de temps ? Le service public de la donnée ne pourrait-il pas aussi faire des recommandations en ce sens ?
