larlet-fr-david-cache/cache/846ce81d2400b35515857d7af175dc3f/index.md

title: Au-delà des limites, que reste-t-il concrètement du Web sémantique ?
url: http://www.lespetitescases.net/au-dela-des-limites-que-reste-t-il-concretement-du-web-semantique
hash_url: 846ce81d2400b35515857d7af175dc3f

<p>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, « <a href="http://www.lespetitescases.net/les-technos-du-web-semantique-ont-elles-tenu-leurs-promesses">Les technos du Web sémantique ont-elles tenu leurs promesses ?</a> » :</p>

<p>Si, à travers les différents cas d’implémentation des technologies du Web sémantique décrits dans le <a href="http://www.lespetitescases.net/les-technologies-du-web-semantique-entre-theorie-et-pratique">précédent billet</a>, 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 :</p><ul class="c17 lst-kix_8umz1jj966ks-0 start"><li>les <strong>systèmes de stockage des données en RDF</strong> (ou triple store) ont montré des <strong>limites du point de vue de l’intégrité des données</strong> (gestion des transactions), <strong>des performances</strong> (temps de réponse de certaines requêtes) ainsi que de <strong>la montée en charge </strong>(volumétrie). Ainsi, parmi les trois axes qui définissent traditionnellement le Big Data : vitesse, volume et variété (les « 3V »), les deux premières caractéristiques ne sont pas encore atteintes par ces technologies et si la décentralisation des données, au cœur même du modèle du Web de données, a pu constituer en partie une solution, c’est oublier la problématique de résilience du réseau et la nécessité d’agrégation des données pour les interroger.</li><li>la<strong> structure même du modèle RDF a fait apparaître des limites quant à la gestion de la provenance des différentes informations et la contextualisation du triplet</strong> : or, si ce point était présent dans la feuille de route du Web sémantique écrite par Tim Berners-Lee, il n’est toujours pas vraiment résolu. Des <a href="https://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">solutions</a> sont apparues mais elles ne sont pas entièrement satisfaisantes. De ce point de vue, <a href="https://www.w3.org/TR/rdf11-concepts/">RDF 1.1</a> est un rendez-vous manqué, d’autant qu’à la même époque le modèle des “<a href="http://graphdatamodeling.com/Graph%20Data%20Modeling/GraphDataModeling/page/PropertyGraphs.html">property graph</a>” qui propose une réponse à cette limite a commencé à s’imposer… Ce modèle est aujourd’hui au coeur de toutes les technologies de bases de données graphes proposées par les gros acteurs du secteur : <a href="https://console.bluemix.net/docs/services/graphdb/index.html">IBM</a>, <a href="https://docs.microsoft.com/fr-fr/azure/cosmos-db/graph-introduction">Microsoft</a>, <a href="https://aws.amazon.com/fr/neptune/">Amazon</a> (basé a priori sur le produit <a href="https://www.blazegraph.com/">Blazegraph</a> dont la société<a href="http://www.snee.com/bobdc.blog/2017/12/sparql-and-amazon-web-services.html"> semble avoir été rachetée par Amazon</a>), <a href="http://janusgraph.org/">Google</a>, sans compter les nouveaux venus  : <a href="https://www.huaweicloud.com/en-us/product/ges.html">Huawei</a>, <a href="https://www.datastax.com/products/datastax-enterprise-graph">Datastax</a>, <a href="https://neo4j.com/">Neo4j</a> ou <a href="https://orientdb.com/">OrientDB</a>. Ainsi, le modèle de graphes se porte bien et, pour cause, il offre une souplesse inégalée dans la manipulation des données structurées et dans l’interrogation croisée de données hétérogènes. Mais, ils ont tous fait le choix d’implémenter le modèle des property graph et ils ont tous adopté le <a href="http://tinkerpop.apache.org/">framework Apache Tinkerpop</a> et le <a href="https://tinkerpop.apache.org/gremlin.html">langage de requêtes Gremlin</a> pour interagir avec le système de stockage, ce qui en fait un standard de fait.</li><li><strong>le destin d’une technologie, indépendamment de son intérêt ou de sa qualité, tient aussi à son degré d’appropriation par les développeurs</strong>. Or, malgré sa relative ancienneté (<a href="https://www.w3.org/TR/WD-rdf-syntax-971002/">le premier brouillon de RDF est publié en 1997 sur le site du W3C !!</a>), il reste encore beaucoup de travail en la matière et, à la vue du nombre incessant de technologies qui apparaissent (et disparaissent), il est à craindre que <strong>les technologies du Web sémantique restent des technologies de niche maîtrisées par peu de développeurs</strong>.</li></ul>

<h1 class="c9" id="h.xsyv3sxpmg00">Que reste-t-il concrètement du Web sémantique aujourd’hui ?</h1><p>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.</p><h2 class="c3" id="h.pv10h99ww39y">Wikidata, un graphe de connaissances centralisé</h2><p><a href="https://www.wikidata.org">Wikidata </a>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 <a href="https://www.slideshare.net/AntidotNet/fing-dataliftwikidataslideshare-32797347">données structurées des Wikipedias</a> (liens interlangues, infobox, catégories, coordonnées géographiques, liens vers des fichiers d’autorité). Ainsi, <strong>Wikidata est aux données structurées ce que Wikimedia Commons est aux médias : un centralisateur d’informations au service des Wikipedia</strong>s. 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é : <a href="https://dbpedia.org/">Dbpedia</a>, <a href="https://www.lespetitescases.net/dbpedia-ou-la-puissance-du-rdf-au-profit-du-savoir">initiative issue de la recherche, apparue en 2007</a>, dont l’objectif était directement lié à l’exposition des données structurées des Wikipedias selon les principes du Linked Data. </p><p>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 <a href="https://creativecommons.org/publicdomain/zero/1.0/deed.fr">Creative Commons Zero</a> (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,<strong> Wikidata propose des données structurées sous la forme de déclarations</strong>.</p><p> 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 <a href="">ontologie déterminée par la communauté au fur et à mesure</a>. Les valeurs peuvent être des liens vers d’autres entités de Wikidata ou des chaînes de caractères typées. Jusque là, <strong>le modèle ressemble à RDF</strong>. Là où il s’en écarte, c’est dans<strong> la possibilité d’associer à chaque déclaration des références</strong> pour la sourcer (reprenant ainsi le principe des notes de bas de page présentes dans les Wikipedia)<strong> et des qualificatifs</strong> pour la préciser, ce qui résout <a href="https://www.lespetitescases.net/quel-evenement-ou-comment-contextualiser-le-triplet">le gros problème de contextualisation du modèle RDF</a>. </p><p><span><img alt="" src="http://www.lespetitescases.net/files/image18.png" title=""/></span><br/><span class="c4 c7"><a href="https://commons.wikimedia.org/wiki/File:Datamodel_in_Wikidata_fr.svg">Modèle de données de Wikidata</a></span><span class="c10 c7">, Charlie Kristschmar, CC0</span></p><p>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 à <a href="http://aidanhogan.com/docs/wikidata-sparql-relational-graph.pdf">différentes études</a>. Ainsi, les données des entités sont traduites dans un <a href="http://korrekt.org/papers/Wikidata-RDF-export-2014.pdf">modèle RDF spécifique</a> et, à chaque mise à jour, sont indexées dans un triple store, en l’occurrence le logiciel <a href="https://www.blazegraph.com/">Blazegraph</a>. Avec <strong>l’importance que prend petit à petit Wikidata, le choix de SPARQL pour Wikidata justifie à lui seul l’apprentissage de ce langage de requêtes</strong>.</p><p>En effet, les objectifs initiaux de Wikidata ont été rapidement dépassés, car <strong>ce projet répondait à de nombreux défauts des autres projets existants</strong> 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é à <a href="http://www.lespetitescases.net/retour-sur-freebase-a-la-lumiere-du-web-of-data">Freebase</a>, initiative lancée par la société <a href="https://en.wikipedia.org/wiki/Metaweb">Metaweb </a><a href="https://googleblog.blogspot.com/2010/07/deeper-understanding-with-metaweb.html">rachetée par Google</a> 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 : <strong>le chaînon manquant de la gestion des connaissances</strong>. Il n’est donc pas étonnant que <strong>Wikidata soit rapidement devenu un hub</strong> supplantant peu à peu Dbpedia en tant que centre des<a href=""> alignements de référentiels divers</a> à travers le monde. Ce rôle me semble évoluer peu à peu ces derniers temps :  <strong>d’un hub de références, Wikidata tend à devenir un réceptacle des données elles-mêmes.</strong> Ainsi, à <a href="https://outreach.m.wikimedia.org/wiki/GLAM/Newsletter/August_2018/Contents/France_report">l’image du Musée St Raymond de Toulouse</a>, les institutions vont être peu à peu tentées de mettre directement leurs données dans Wikidata. Et le <a href="">projet WikiCite</a>, qui vise à centraliser les références bibliographiques pour les Wikipedias, risque fort d’accélérer ce mouvement. </p><p>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.</p><p>Et pour vous convaincre de l’importance de ce projet, il suffit de voir l’implication de Google : <a href="https://www.generation-nt.com/wikidata-donnees-structurees-wikipedia-actualite-1562481.html">mécène du projet à l’origine</a>, ils ont recruté son <a href="http://simia.net/wiki/Denny">développeur principal</a>, <a href="https://twitter.com/vrandezo">Denny Vrandečić</a>, 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 <a href="https://web.archive.org/web/20160305041722/http://mql.freebaseapps.com/ch02.html">ne suivait pas non plus précisément le modèle RDF</a>…) mais aussi d’une base de connaissances déjà conséquente. C’est sur cette base que Google a commencé à construire le <a href="https://www.blog.google/products/search/introducing-knowledge-graph-things-not/">Knowledge graph</a>, 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 <a href="https://searchengineland.com/google-close-freebase-helped-feed-knowledge-graph-211103">reverser le contenu de Freebase dans Wikidata</a> 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 <a href="https://ai.google/research/pubs/pub45634">la seule source de ce knowledge graph</a>.</p><h2 class="c3" id="h.301ojpft1xdg"><span class="c10 c12">Schema.org, une ontologie unique pour les unir tous </span></h2><p>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 <a href="https://developers.google.com/search/docs/guides/">recommandations de Google</a> 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 <a href="https://static.googleusercontent.com/media/research.google.com/fr//pubs/archive/35179.pdf">d’articles</a> ou d’<a href="https://www.lespetitescases.net/web-semantique-utilisateurs-stupidite-et-google">avis</a> de certains ingénieurs de Google sur l’intérêt des données structurées au sein des pages Web... </p><p>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 <a href="https://www.lespetitescases.net/yahoo-apporte-bananes-web-semantique-1">SearchMonkey</a>, 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 <a href="http://microformats.org/">microformats</a>. 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, <a href="https://schema.org/">Schema.org</a> voit le jour en 2012. </p><p>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 <a href="https://www.w3.org/TR/microdata/">Microdata</a>, standard concurrent mis au point dans le cadre de HTML5. Peu à peu, <a href="https://www.w3.org/TR/json-ld/">Json-LD</a> 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.</p><p><span><img alt="" src="http://www.lespetitescases.net/files/image20.png" title=""/></span></p><p>Avec Schema.org, c’est d’abord le <a href="http://www.lespetitescases.net/contrer-les-idees-re%25C3%25A7ues-sur-le-web-semantique%23comment-583">spectre de l’ontologie universelle</a> 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 <a href="https://www.w3.org/TR/1998/WD-rdf-schema-19981030/">pionnier du Web sémantique</a>, <a href="http://danbri.org/">Dan Brickley</a>, 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. </p><p>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 ? </p>
<blockquote class="twitter-tweet" data-lang="fr"><p lang="en" dir="ltr">RDF was designed as a data interchange framework; what you do in the privacy of your own database is your own business</p>— Dan Brickley (@danbri) <a href="https://twitter.com/danbri/status/1041387356618743808?ref_src=twsrc%5Etfw">16 septembre 2018</a></blockquote>

<h2 class="c3" id="h.yka4qljxd2iq"><span class="c10 c12">Exposition des données, des gros hubs plutôt que des petits satellites ?</span></h2><p>Comme nous l’avons vu précédemment, la plupart des <strong>utilisateurs </strong>souhaite des <strong>mécanismes simples et efficaces pour récupérer les données</strong>. 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 <strong>contre-productif pour les organisations de ne pas répondre aux besoins des utilisateurs</strong> et de s’entêter à exposer les données selon les principes du Linked Data. C’est d’autant plus vrai que <strong>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</strong> voire en XML ou en Json. </p><p>De plus, <strong>publier des données selon les principes du Linked Data implique des responsabilités</strong>. 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 <strong>très nombreuses initiatives d’exposition des données ont aujourd’hui disparu</strong>, emmenant avec elles non seulement les identifiants mais aussi les données elles-mêmes. Gageons que les <strong>initiatives autour des données de la recherche, en particulier le </strong><strong><a href="https://fr.wikipedia.org/wiki/Fair_data">FAIR</a></strong><strong>, vont offrir les moyens d’exposer les données de manière durable</strong>. </p><p>Un des moyens de poursuivre le développement du Linked Open Data<strong> passera immanquablement par la centralisation de ces données dans quelques « hubs »</strong> 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.</p><p><span><img alt="" src="http://www.lespetitescases.net/files/image7.png" title=""/></span><br/><span class="c4 c7"><a href="https://lod-cloud.net/">LOD cloud Diagram</a></span><span class="c10 c7"> (Version de 2014), CC-BY</span></p><p>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. </p><p>Mais, est-ce bien nécessaire ? <strong>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)...</strong> Pour l’instant, ces organisations en sont convaincues mais pour combien de temps ? Le <a href="https://www.data.gouv.fr/fr/reference">service public de la donnée</a> ne pourrait-il pas aussi faire des recommandations en ce sens ?</p>