Le web des données

On pourrait définir le web des données comme étant le projet de rendre le web (et les informations qu’il véhicule) aussi aisément lisible et exploitable par des ordinateurs que par des êtres humains, en faisant sauter les spécificités de structuration des données propres à chaque base de données fournissant des informations sur internet.

Etant donné qu’il naît de plusieurs frustrations dans le fonctionnement du web « normal », et que sa dénomination suscite souvent des incompréhensions, peut-être est-il bon de commencer par là.

Les problèmes de compréhension

1. Pour comprendre ce qu’est le web des données, on aimerait pouvoir voir ce qu’il permet de faire. Des réalisations existent déjà, mais elles ne montrent rien que le web actuel ne soit plus ou moins déjà capable de faire. La visibilité en est donc moindre (alors qu’à l’avènement du web 2.0, on pouvait dire : « Ouah ! trop fort ! »).
2. l’autre appellation, « web sémantique« , est polysémique (!). Certains moteurs de recherche dits sémantiques –  c’est-à-dire visant à éviter toute confusion dans les mots recherchés, et/ou voulant proposer des informations et non des listes de résultats — n’utilisent absolument aucune des technologies du web des données.
3. Le web des données utilise des concepts radicalement nouveaux pour beaucoup (RDF, RDFa, triplets, …), risquant décourager ceux qui seraient intéressés.

Les frustrations que le web des données est censé combler

1. les pages sont liées entre elles, mais ces liens ne sont pas typés
2. les bases de données sont structurées, mais leur structure disparaît lorsque leurs données sont affichées sur le web
3. les manières pour accéder malgré tout à la structure des bases de données ne sont pas (assez) universelles

Reprenons en détail

Première frustration : Les liens ne sont pas typés

Dans la Wikipedia se trouvent notamment les pages

• Jean-Paul Sartre
• Paris

Un ordinateur peut constater que la page Jean-Paul Sartre contient un lien vers la page Paris, et que l’inverse n’est pas vrai. Mais il est incapable de comprendre que de ces deux objets, l’un est un personnage historique et l’autre un lieu géographique, et que la relation entre eux est : le premier est né dans le second.

Le web des données consiste notamment à ce que la page Jean-Paul Sartre contienne

• une information globale : l’objet décrit dans cette page est un être humain
• au moment de pointer vers la page Paris : du code permettant de dire « Ceci est le lieu de naissance du sujet principal de cette page ».

Pour cela, il faut décrire ce qu’est un être humain. Dans le web des données, un être humain est une ressource à laquelle on relie d’autres ressources selon certains types de relations.

Dans une base de données classique, un être humain serait plutôt une ligne (un enregistrement) ayant un certain nombre de champs : une date de naissance, un lieu de naissance, une liste d’ouvrages dont il est l’auteur, un mari ou une épouse, des enfants, une date de mort, etc.

Le web des données estime que chacune de ces  propriétés est en soi une ressource qui sera à son tour liée à d’autres ressources :

• Jean-Paul Sartre
  • est né à Paris (ce n’est pas la seule chose qui se soit produite dans cette ville !)
  • a écrit Huis Clos (que d’autres ont mis en scène, ou interprété, etc.)
  • a vécu avec …
• …Simone de Beauvoir
  • née en 1908 à Paris
  • auteur du Deuxième Sexe
  • etc.

Plutôt que de représenter cela sous forme de listes à puces imbriquées, il apparaît rapidement plus « simple » (si si !) de faire un schéma figurant toutes ces lignes, schéma composé de nœuds et de liens.

Dans un premier temps, le schéma pourrait sembler avoir pour centre Jean-Paul Sartre, mais un glissement permanent (ou décentrement progressif) vers Simone de Beauvoir, puis vers Le Deuxième Sexe, puis vers l’histoire du féminisme, est tout à fait légitime. Et surtout il est possible.

Plusieurs remarques :

• Simone de Beauvoir et Jean-Paul Sartre ont une relation (symétrique) de type « est l’ami de ».
• Et entre Simone de Beauvoir et Le Deuxième Sexe existe la relation : « Est l’auteur de » (ou, dans l’autre sens : « A pour auteur »). Cette relation est la même qu’entre Sartre et Huis Clos.

Bref, pour définir un être humain, on peut donner la liste des types de ressources auquel il peut être associé (lieu, œuvre, date, autre être humain), et la nature de ces relations.

Quelles associations peut-il y avoir entre deux individus ? Quelques exemples :

• relations familiales : père, mère, fils, soeur
• relations personnelles : mari, amie, concubin
• relations professionnelles : collègue, voisin de fauteuil d’Immortel

L’ontologie Relationship définit quelles sont les relations qui peuvent associer deux êtres humains (ami de, fils de, etc.).

Les ontologies

Une ontologie définit, pour un type de  ressource donné, quelles relations peuvent lier cette ressource à d’autres ressources. Un être humain est un type de ressource, un lieu géographique en est un autre.

Remarque : Relationship ne décrit pas ce qui relie un être humain à une œuvre de l’esprit, ou à un lieu géographique. Donc pour décrire Sartre, l’utilisation d’autres ontologies sera certainement nécessaire.

Si j’écris dans un article les différents types de relations entre deux êtres humains, je pourrai faire une liste simple en énumérant : fils de, frère de, ami de, etc.

Mais l’objectif du web des données est qu’un ordinateur soit lui aussi capable de comprendre cette liste comme étant une ontologie. Pour cela, il existe différentes manières d’écrire cette ontologie.

L’être est relation

Le terme d’ontologie, issue de la philosophie, désigne l’étude de ce qu’est l’être, ce qui le définit, quelle est son essence. Donc, en informatique, l’ontologie d’une ressource est la nature des relations qu’il peut avoir avec d’autres ressources : est l’auteur de, a pour auteur, est la capitale de, a pour monnaie, etc.

Le web des données tourne autour de la qualification des liens entre les ressources.

L’ensemble Ressource — Nature du lien — Ressource est appelé triplet, qui est le cœur du web des données puisque ce sont les triplets que l’on manipule, que l’on véhicule, que l’on transporte, et qui permettent de passer d’un nœud à l’autre.

Deuxième frustration : sorties de leur base pour être affichée sur une page web, les données ne sont plus structurées

Dans un catalogue de bibliothèque, les données sont stockées en champs. Dans chaque notice se trouve un titre, un auteur, etc.

Un moteur de recherche web, qui navigue sur internet comme un internaute, tombe sur des pages contenant l’information :

Titre : Huis Clos
Auteur : Sartre, Jean-Paul
etc.

Mais le moteur de recherche ne « sait » pas qu’il s’agit d’un livre, il ignore ce que signifie « être le titre d’un livre« , etc. Une des premières concrétisations du web des données est de restituer la structure de la base sous forme de données associées entre elles.

Dans l’exemple ci-dessus, le PPN de la notice Sudoc est : 000563668. Ce sera l’identifiant unique de cette ressource, qu’on exprimera sous forme d’URL non équivoque : http://www.sudoc.abes.fr/DB=2.1/SRCH?IKT=12&TRM=000563668

Donc la ressource http://www.sudoc.abes.fr/DB=2.1/SRCH?IKT=12&TRM=000563668

• est un livre
  • les types de relations qui caractérises un livre peuvent être décrite avec le Dublin Core.
• et, à ce titre, a un certain nombre de propriétés :
  • il a pour titre : « Huis Clos » (c’est une chaîne de caractères)
  • il a pour auteur Jean-Paul Sartre, qui est en soi une ressource rattachée à d’autres livres. Cette ressource a pour PPN 027123227 dans le Sudoc, qui pourrait permettre de la désigner sous forme d’une URL non univoque.
• en Dublin Core (dc), l’auteur est appelé creator.

Si bien que le triplet reliant l’œuvre à l’auteur pourrait être représenté :

Dans la page web, le code contiendrait dans des balises HTML  :

<span property="dc:creator" content="http://dbpedia.org/resource/Jean-Paul_Sartre">Jean-Paul Sartre</span>

L’œil de l’internaute ne voit que « Jean-Paul Sartre » (la balise n’est pas affichée), et le moteur de recherche qui navigue sur le web voit que Jean-Paul Sartre est contributeur de l’œuvre décrite ici, selon la définition de « creator’ » donnée par Dublin Core.

Si la page contient ce type de code, l’information initiale, structurée, n’est plus perdue lorsqu’elle est affichée sur le web. Google ou Yahoo indexant des pages et des pages d’un opac sauraient proposer une recherche par titre, auteur ou sujet — et donc assez rapidement proposer une recherche fédérée sur un grand nombre de catalogues.

Remarque : le plus souvent, en réalité, la page ne contiendra pas ce code. Le site web est capable de reconnaître si celui qui consulte une notice bibliographique est un navigateur web (donc un internaute), ou une machine intéressée uniquement par ces triplets. Selon qu’il s’agit de l’un ou de l’autre, il le renverra vers la page web (en HTML) ou vers la page proposant le même contenu, mais sous forme de triplets. Cette double orientation (appelée négociation de contenu) a pour conséquence que les pages web, le plus souvent, ne contiendront pas les triplets. Donc pour la notice Sudoc ci-dessus, l’information en triplet pour l’auteur sera sur une autre représentation de cette notice, sous la forme plus probable :

<http://www.sudoc.abes.fr/DB=2.1/SRCH?IKT=12&TRM=000563668><http://purl.org/dc/terms/creator><http://dbpedia.org/resource/Jean-Paul_Sartre>

où la première URL désigne la notice, la seconde « le fait d’avoir pour auteur », et la troisième l’auteur lui-même

Troisième frustration : les méthodes existantes pour accéder aux données structurées ne sont pas assez universelles

Ne mentionnons que deux méthodes traditionnelles.

Le z39.50 : il permet d’interroger un catalogue avec un protocole spécial, et de récupérer des métadonnées non mises en forme (à la différence d’une page web), mais avec indication de chacun des champs. Cette interrogation est structurée mais :

• elle est extérieure au web
• elle est propre aux bibliothèques
• elle est limitée aux métadonnées bibliographiques

Les API, plus fréquentes. Pendant que l’internaute interroge une base de données via l’interface « normale » (avec une URL en http://www.base.fr/question?termes=huis-clos), obtenant des pages HTML, les machines qui veulent exploiter l’information de la base de manière plus structurée peuvent passer par une autre URL. Ils cherchent sur http://api.base.fr/question?termes=huis-clos, et obtiennent ainsi une page XML, ou chaque champ est entre des balises signifiantes.

Cette interrogation est structurée mais :

• chaque site a ses API, et peut les faire évoluer. Pour s’interconnecter avec une nouvelle base, il faut lire toute la documentation relative à ses API
• la navigation de l’internaute est déconnectée de celle de la machine. Il faut maintenir deux interfaces parallèles.

Alors qu’en intégrant dans ses pages web de résultats des informations structurées sur le modèle

<span property="dc:creator" content="http://dbpedia.org/resource/Jean-Paul_Sartre">Jean-Paul Sartre</span>

toutes les limites mentionnées ci-dessus sautent.

Où, quand, comment ?

Le web 2.0 a progressivement envahi le web « initial », si bien que les deux ont fini par se confondre.  Qu’en est-il du web des données ?

Il est dangereux de prophétiser. On constate pour l’instant des projets spécifiquement consacrés à produire des données liées (linked data) sous forme de triplets, de manière à ce que celles-ci soient exploitables par d’autres applications. Cela nous donne ce schéma déjà célèbre et en permanente évolution, où les sources de ces données sont indiquées avec les liens déjà existant entre elles.

On trouve notamment au centre DBpedia, qui reprend des contenus de la Wikipedia, mais structurés en triplets. On peut ainsi exploiter les données de la Wikipedia pour extraire des informations et les afficher ailleurs.

Vous pouvez ainsi comparer la fiche Jean-Paul Sartre sur la DBpedia et sur la Wikipedia.

Avec un peu d’efforts, on arrive à lire la fiche de la DBpedia, mais on voit bien qu’elle n’est pas en langage naturel. Voyez la liste des « influences » de Sartre : chaque ligne est structurée.

On pourrait ainsi, dans un dictionnaire philosophique en ligne, à la fiche Nietzsche, récupérer toutes les personnes dites influencées par Nietzsche dans la DBpedia, c’est-à-dire toutes les personnes ayant dans leur propre fiche cette même information.

On pourrait énoncer quatre manières principales de créer ces informations structurées :

• reprise manuelle : c’est long, fastidieux et décourageant. Mais c’est possible… En outre on peut envisager une aide à la saisie de la part des logiciels : vous tapez votre texte, et à un moment vous sélectionnez un mot comme si vous voulez le rendre cliquable. A la place, une autre icône de l’éditeur de texte vous propose d’associer ce mot à un concept de DBpedia (ou d’une autre base). C’est ce que propose MOAT (explications).
• templates : lorsqu’une base de données récupère une notice (de livre, de gène, d’oiseau) pour l’afficher, elle utilise un template (ou modèle) qui prend chaque valeur de la notice et la place quelque part dans la page, en gras ou en italiques, précédée du mot « Titre » ou du mot « Date de publication ». Il serait généralement assez simple de modifier ces templates pour que l’information dans la page contienne également des balises précisant la nature de chaque information affichée, faisant appel à une ontologie (il existe à présent des ontologies dans tous les grands domaines de la connaissance).
• pages en plein texte – métadonnées : une page web est elle-même une ressource, avec des métadonnées qui peuvent être exprimées en triplets.  Le CMS (logiciel de production de site web) peut donc être paramétré pour que les métadonnées des pages fassent des liens vers l’auteur, le sujet de la page, etc. ou l’auteur soit désigné par son profil LinkedIn, le sujet par son identifiant Rameau, etc. Les logiciels WordPress, Drupal, etc. permettent cela sans aucune difficulté.
• pages en plein texte – contenu : lorsqu’un rédacteur produit un texte pour un site web, le CMS qui va générer la page en ligne, en plaçant automatiquement au-dessus de la page un bandeau, en mettant à gauche un menu, etc., peut être programmé pour repérer certains mots spécifiques (récurrents et à sujet fort dans la thématique du site) pour rajouter du code afin de rattacher ces mots à un concept décrit par exemple sur la DBpedia, sur le site lui-même, ou ailleurs (exemple).

Réalisations

On peut distinguer trois types de concrétisations :

• les sites « normaux » qui exposent leurs données sur leurs pages de données sous forme de triplets
  • Le catalogue suédois Libris fournit pour chaque notice d’ouvrage, une exposition de cette notice en triplet :
    • Huis Clos en mode « normal » : http://libris.kb.se/bib/1917295
    • Huis Clos sous forme de triplets : http://libris.kb.se/data/bib/1917295?format=application/rdf+xml
    • Le lien de la première notice vers la seconde est un lien caché présent dans la page :
      <link rel="alternate" type="application/rdf+xml" title="RDF Representation" href="http://libris.kb.se/data/bib/1917295?format=application/rdf+xml" >
  • Facebook propose aux propriétaires de sites web, blogs, etc. d’ajouter des métadonnées selon leur propre ontologie, OpenGraph. Des fonctionnalités de réseau sont associées à la génération de ces métadonnées sur les pages.
• les sites qui manifestement servent à peu près exclusivement de sources pour des applications et non pour être lues par des internautes (DBpedia, notamment, mais aussi la Linked Movie Database)
• Les sites « normaux » qui exploitent les données des autres (et les rediffusent à leur tour) pour créer une information nouvelle
  • Geonames fournit des informations sur des lieux, via un moteur de recherche simple. Il va puiser ces informations dans diverses sources.
  • BBC Music (qui récupère des données et les ré-expose à son tour, tout comme Geonames, d’ailleurs)

C’est sur cette dernière catégorie que peuvent porter le plus d’incompréhensions : l’utilisation de données d’autres bases, le web « actuel » le fait déjà (voir cette notice de Huis Clos sur Calice68, rubrique Biographie). Donc ça n’a l’air de rien de nouveau…

Mais ces enrichissements déjà existants sont faits en décryptant le code de la Wikipedia ou d’autres sources, codes non normalisés, mouvants. Ils peuvent aussi utiliser des API Amazon ou LibraryThing, mais celles-ci sont également spécifiques à chaque source — alors que le web des données universalise l’encodage des métadonnées, donc facilite leur récupération.

Et le RDF ?

C’est simple : Le RDF (Resource Description Framework) liste des consignes pour décrire des ressources : pour être conforme à ces consignes RDF, il faut décrire ses données sous forme de triplets, et que chaque ressource soit désignée par un identifiant unique.

Un site peut dire qu’il suit les préconisations RDF pour décrire ses ressources (notamment ses propres pages) s’il les décrit sous forme de triplets (et non pas, par exemple, sous forme de notices avec des champs).

Cela permet ensuite à un développeur de se brancher sur plusieurs sites auto-déclarés RDF, pour en extraire les informations qui l’intéresse, grâce à cette structure commune de triplets.

Et le RDFa ?

C’est simple encore : c’est du RDF intégré dans des pages web. Comment intégrer ces triplets dans les pages web sans gêner l’internaute ? Le RDFa explique quels balises et attributs utiliser (balises <span>, ou, pour chaque élément HTML, attributs property, about, etc).

Quelles perspectives ?

L’objectif du web des données n’est pas de remplacer complètement le web. Il est simplement d’interconnecter le plus grand nombre de sites (et surtout de données) à travers ces technologies. Il serait absurde de dire que « ça ne marchera pas » puisqu’il compte déjà de nombreuses réalisations, et il n’y a pas de raison que ça s’arrête. Quant à savoir s’il n’intégrera qu’une partie des sites web, ou la quasi-totalité, c’est une mauvaise question, car on peut intégrer dans ses pages du RDF selon plusieurs modalités :

• pour décrire ses pages web
• pour exposer les notices de ses bases de données
• pour enrichir le texte de ses pages
• etc.

C’est exactement la même chose que pour le web 2.0 : un site proposant un fil RSS mais pas de possibilité de commenter est-il 2.0 ? Il y a plusieurs niveaux d’intégration, qui ne sont pas gradués entre eux. Disons qu’il y a plusieurs manières de s’impliquer ou d’exploiter le web des données.

Concernant les bibliothèques, les perspectives sont, pour commencer (le reste viendra plus tard, avec la familiarisation et l’imagination) :

• le remplacement de l’OpenURL par du RDF, plus normalisé, non spécifique aux bibliothèques et donc grâce auquel nous bénéficieront des travaux de tous les développeurs qui travaillent dessus
• les catalogues fédérés prennent une toute autre envergure, de même que la « libre circulation » des métadonnées moissonnables, enrichissables, manipulables. On s’éloigne toujours davantage du catalogage manuel, du Z39.50 et des connecteurs faits un par un pour les moteurs de recherche fédérée.
• l’intégration facilitée de contenus enrichis (pages de couvertures, bibliographies, biographies, etc.) de manière beaucoup plus fine. Actuellement, si on veut ajouter du contenu Wikipedia à son catalogue en ligne, on est obligé de prendre toute la page Wikipedia. Avec le web des données, le choix d’afficher telle ou telle information sera beaucoup plus fin et contextuel.
• A quoi sert de cataloguer une notice si on peut faire un lien vers elle, et qu’avec ce lien on rapatrie en temps réel toutes les informations utiles ? Au lieu de cataloguer, une exemplarisation sera largement suffisante !

Ce n’est déjà pas si mal !

Il ne vous reste plus quà suivre les travaux du tout nouveau groupe « Bibliothèques et web des données », par mail ou RSS.