A partir des fichiers de données du Répertoire Opérationnel des Métiers et de l’Emploi, j’ai mis en ligne des visualisations de données du ROME, après nettoyage, traitement, et conversion des données en SKOS.

Le Répertoire ROME

Ce répertoire ROME m’avait intéressé il y a 4 ans lorsque j’avais effectué une mission pour l’optimisation sémantique du moteur de recherche SolR d’un job board. Nous nous étions demandé à l’époque si nous pouvions réutiliser une partie de ce référentiel pour effectuer un rapprochement (automatique ou manuelle) des titres d’annonces d’emplois vers le référentiel. Cela aurait permis, à partir de l’identification du nom du poste, de catégoriser automatiquement les annonces dans la catégorie ROME appropriée. Le ROME contient en effet plus de 11000 dénominations de postes/métiers, catégorisés dans une double classification : une arborescence principale, et une arborescence thématique. On y trouve donc des entrées comme :

• Accompagnateur / Accompagnatrice en écotourisme
• Responsable de rayon produits alimentaires
• Assistant / Assistante mise en scène
• etc.

Ces noms de postes sont organisés dans une classification à 3 niveaux : « AGRICULTURE ET PÊCHE, ESPACES NATURELS ET ESPACES VERTS, SOINS AUX ANIMAUX > Espaces naturels et espaces verts > Bûcheronnage et élagage ». Le 3eme niveau (ici « Bûcheronnage et élagage ») correspond à une fiche métier (ici http://candidat.pole-emploi.fr/marche-du-travail/fichemetierrome?codeRome=A1201) et est associé à un code (ici A1201).

Arborescence principale du code ROME dans SKOS-Play

Conversion en SKOS

Je suis reparti ici des fichiers bruts fournis sur data.gouv.fr, et j’ai passé un peu de temps à les convertir en SKOS avec le convertisseur Excel vers SKOS de SKOS Play :

• ajustement manuel de certaines valeurs mal séparées par des virgules dans le fichier CSV de départ;
• suppression des guillemets simples et doubles;
• fusion des 2 fichiers fournis (arborescence principale et arborescence thématique);
• réorganisation des colonnes;

Il s’agit ensuite de construire un tableau Excel au format adéquat pour une conversion vers SKOS, en adaptant la structure des fichiers, typiquement en calculant le contenu de nouvelles colonnes avec des formules Excel. En particulier, il s’agit de donner des identifiants URI à toutes les entrées du code ROME, pour arriver ainsi à des données open data « 4 étoiles ».  Cette conversion SKOS est relativement aisée à réaliser, sans écriture de code ni script. Elle est accessible à toute personne capable de manipuler Excel.

Ces données SKOS du ROME sont publiées à http://data.sparna.fr/vocabulaires/code-rome.

Je ne rentrerai pas dans les détails de modélisation du ROME en SKOS, sauf sur 1 point : on peut se demander ce qu’il convient d’identifier comme « Concept » dans ce référentiel. J’ai pris le parti de considérer chaque nom de poste comme un skos:Concept, et tous les éléments de classification thématiques comme des skos:Collection (donc des tiroirs, qui ne sont pas utilisables dans une indexation). Un point de vue différent mais tout aussi valable serait de considérer non pas les noms de poste comme des concepts, mais bien les noms de métier, chaque métier ayant une correspondance avec une fiche sur le site Pôle Emploi; les noms de poste seraient alors des synonymes (skos:altLabel) du métier (dans l’exemple au-dessus, le métier A1202 « Bûcheronnage et élagage » aurait alors pour synonymes « Agent / Agente d’aménagement des haies et fossés », « Agent / Agente d’entretien des espaces naturels », « Ouvrier / Ouvrière d’entretien des espaces naturels », etc.).

Visualisations de données

A partir des données SKOS, on peut ensuite générer des visualisations avec SKOS Play : ces visualisations sont publiés à http://labs.sparna.fr/code-rome.html. 3 visualisations ont été produites :

1. Un champ de recherche assisté (avec une autocompletion sur les noms des métiers), permettant de lancer une recherche d’annonces sur le site Pôle Emploi à partir d’un nom de métier; on pourrait imaginer quelque chose de similaire pour accéder aux fiches métiers plutôt qu’aux annonces;
2. Une vue arborescente avec d3js, permettant de naviguer visuellement dans l’arbre;
3. Un listing indenté en HTML, que l’on peut plier et déplier;

On notera que, sauf pour l’articulation entre le champ de recherche assisté et le site de Pôle Emploi qui demande 10 lignes de javascript, ces visualisations sont produites directement par SKOS Play sans avoir à écrire de code.

Un « Web des données de l’emploi » ?

On a donc ici fait passer le référentiel ROME à un meilleur niveau de qualité des données, permettant une intégration facilitée dans d’autres systèmes, d’autres outils de recherche. Au delà de la démonstration sur la conversion et la visualisation de données, j’aimerai dans une deuxième étape illustrer l’alignement des données du ROME avec d’autres référentiels (probablement ESCO), en utilisant OnaGUI, qui permet de simplifier les alignements de vocabulaires. On aurait alors un beau référentiel 5 étoiles, _dans_ le web (et pas simplement _sur_ le web), avec des correspondances vers d’autres données. Un « web des données de l’emploi » ? il fallait bien ça à quelques jours des présidentielles !

Dans une deuxième étape je publierai le SKOS généré pour que les URIs soient déréférençables, en utilisant SKOSMOS, dans un déploiement similaire à celui utilisé pour publier le thesaurus de l’UNESCO.

J’espère que cette conversion de données en SKOS permettra une diffusion et une intégration plus large de ce référentiel utile pour la recherche d’emplois. Dites-moi si vous réutilisez ces données pour d’autres visualisations ou d’autres systèmes, ou si vous souhaitez de l’aide pour son intégration.

Illustration de l’article tirée de Wikimedia Commons : https://fr.wikipedia.org/wiki/Fichier:Metro_de_Paris_-_Ligne_2_-_Rome_07.jpg

Cet article Référentiel ROME de Pôle Emploi en SKOS (à partir de data.gouv.fr) est apparu en premier sur Sparna Blog.

Le web de données, de « l’information en réseau »

Le web de données (on préférera ce terme à celui plus ambigu de web sémantique), ce n’est pas compliqué ; ça marche et c’est utile, en particulier pour les bibliothèques.

Retour aux racines du web

Le web n’a pas été conçu pour n’être qu’un paquet de documents mis en lien. Il intègre, dès sa conception en 1989 par Tim Berners Lee¹, plus de sémantique que l’utilisation qui en sera faite ensuite. En particulier par la dualité Identifiant/Représentation :

• Identifiant : ce qui commence par « http://… » et que l’on voit dans la barre d’adresse de notre navigateur est une URL, où le « L » est mis pour « Locator ». C’est donc l’adresse d’un document sur le web; mais ce n’est qu’un cas particulier des URIs, où le « I » est mis pour « Identifier« , qui sont des identifiants, dans le contexte du web, de choses du monde réel. On comprend donc qu’on peut identifier sur le web n’importe quoi à l’aide d’une URI : Victor Hugo, les pizzas margherita, le terme de thésaurus « gouvernance », la Loire, la caractéristique « se situe à », etc. On parle d’une façon générale de ressources.

• Représentation : si une URI est l’identifiant d’une « ressource », alors quel « document » obtiendra-t-on en naviguant vers cette URI ? On a l’habitude d’obtenir pour une même adresse toujours le même document, mais d’une façon générale un identifiant peut être associé à plusieurs représentations qui varient – de façon transparente – en fonction de préférences de langue, de format, de lieu, etc. C’est ce qu’on appelle la négociation de contenu.

Cette capacité des URIs d’identifier absolument n’importe quoi, indépendamment d’une représentation particulière, est la clé de voûte de l’universalité du web (de données).

Une fois les « choses » identifiées et rendues indépendantes des documents qui les représentent, il devient possible de parler de ces choses : je peux publier sur le web l’assertion que « La Tour Eiffel se situe à Paris », en utilisant 3 URIs pour identifier les 3 composantes de cette assertion : La Tour Eiffel, la notion de « se situer à », et Paris. C’est le standard RDF (Resource Description Framework) qui permet d’employer ces assertions en triplets. Notons au passage que, le web étant par nature décentralisé, n’importe qui est libre :

• de créer une nouvelle URI pour identifier Paris ;

• ou de créer une assertion en se référant à une URI déjà existante pour Paris (par exemple celle définie par l’Insee²) ;

• ou encore d’exprimer des liens d’équivalence entre identifiants : l’URI que je définis pour Paris représente la même « chose » que celle définie par l’Insee.

On voit donc se dessiner ce qui nous occupe : un réseau décentralisé de données liées par des triplets.

Mais il faut aller plus loin pour que l’interopérabilité soit complète – puisque le web de données n’est qu’une solution à la problématique de l’interopérabilité. En effet, pour qu’une autre application puisse décoder mon assertion, il faut que je donne une définition précise des identifiants que j’ai utilisés, qui sont sans doute différents de ceux que comprend cette application. En particulier, il faut que je donne une définition précise de mes « verbes » (« est situé à ») et mes « types » (« Lieu », « Personne », etc.). C’est ce que permettent les ontologies, dont l’objectif est de donner un sens univoque à ce dont je parle, à l’aide de la logique formelle (on parle également de vocabulaire ou de modèle de données, un peu par abus de langage). Les ontologies permettent également de déclarer des équivalences entre verbes ou entre types, rendant ainsi interopérables des données hétérogènes. Par exemple, je peux dire que, dans mon contexte « est situé à  » relie quelque chose à un « Lieu » et que cela représente la même notion que l’identifiant « basedNear » défini dans une autre ontologie bien connue, FOAF³.

Les ontologies font donc émerger de cet océan de liens des structures interopérables, rendant ainsi les données liées plus « sémantiques », c’est-à-dire plus facilement réutilisables.

Quels enjeux et quelles conséquences ?

Souvenons-nous des fausses promesses entendues au milieu des années 2000 à propos du web de données : les machines allaient bientôt comprendre « le sens » des textes, on nous parlait de web 3.0, de « Twine » (un site qui n’existe plus maintenant mais qui promettait la révolution des réseaux sociaux), on cherchait quelle serait la « killer-app » – une application si attrayante qu’elle aurait justifié la technologie à elle seule, etc. Rien de tout cela n’est arrivé, mais d’autres conséquences ont eu lieu.

D’abord une quantité grandissante de « données ouvertes et liées » publiées par une variété importante de producteurs de données : c’est le fameux « Linked Open Data« ⁴. Citons-en quelques points notables: DBPedia francophone (une extraction en RDF des données de Wikipedia), data.bnf.fr (notices FRBRisées – voir plus bas -, autorités et thématiques de la Bibliothèque Nationale de France), ou encore VIAF (Virtual International Authority File, une mise en commun des fichiers d’autorité d’une quarantaine de bibliothèques et de musées).

Dans cet ensemble de données, il faut en mentionner certaines ayant un statut particulier : les thésaurus. Ceux-ci peuvent être représentés et publiés dans le modèle SKOS. Ce modèle permet d’aligner les thésaurus pour permettre l’interopérabilité de catalogues documentaires utilisant des vocabulaires d’indexation différents (« Désobéissance civile » dans Rameau est ainsi rapprochée de « Civil disobedience » dans les sujets de la librairie du congrès américain⁵). Quant aux ontologies, on se référera au projet LOV – Linked Open Vocabularies⁶.

Ensuite, une appropriation de cet enjeu des données structurées et liées par les grands moteurs de recherche : c’est l’initiative schema.org⁷, qui propose un modèle de description de « plein de choses dont on parle sur le web » (blogs, livres, films, produits, etc.), compréhensible par Google, Yahoo, Bing et consorts. On peut reprocher à schema.org son biais vers le e-commerce, sa vision occidentalisée et son manque de transparence dans la gouvernance, mais si les bibliothèques souhaitent rendre leurs données plus visibles par les moteurs, cela passe par la publication de données compatibles avec schema.org.

D’une façon plus profonde, ces technologies induisent une représentation générale de l’information en graphe décentralisé, en réseau. Ce mode de structuration, de pensée, fait suite à celui plutôt tabulaire des bases relationnelles, et plutôt hiérarchique de XML. La conséquence est flagrante sur les notices bibliographiques avec le modèle FRBR. Les « Functionnal Requirement for Bibliographic Records« , successeurs de l’ISBD (« International Standard for Bibliographic Record« ) proposent en effet un éclatement de la notice en 4 niveaux conceptuels, eux-mêmes reliés aux personnes ou aux organisations impliquées dans la vie du document (auteur, contributeur, éditeur, possesseur), lesquelles sont elles-mêmes reliées entre elles ou à d’autres données du web.

Cette tendance est à rapprocher du constat que de plus en plus de systèmes informatiques de diffusion des catalogues utilisent une base de graphe RDF (« triplestore« ) pour centraliser les métadonnées des notices FRBRisées, les fiches d’autorité et les thésaurus. Cette base devient le pivot central des canaux de diffusion (sites web, flux RSS, formats d’échange métier, etc.). Les lois européennes sont notamment diffusées sur ce mode, via la base Cellar et le portail Eur-Lex⁸.

Prochaines promesses ?

Sans retomber dans les promesses hasardeuses évoquées plus haut, on peut néanmoins esquisser les lignes de force du web de données pour les prochaines années : une utilisation grandissante de schema.org par les moteurs de recherche et les projets de diffusion de données; l’intégration native des fonctions de publication/récupération de données du web dans les Content management system (CMS) et les SIGB; la publication et l’alignement de plus en plus de données – dont des thésaurus ou des données de la recherche; la généralisation de FRBR et de ses dérivés pour la description des notices bibliographiques, etc.

Au-delà des aspects technologiques, ce sont des logiques de partage, de réutilisation, de mise en réseau, de collaboration, ou d’insertion dans un écosystème d’acteurs, qui sont favorisés par cet artefact unique qu’est le web de données.

Cet article Article ArABESque – Le web de données, de « l’information en réseau » est apparu en premier sur Sparna Blog.

Il faut toujours prendre un peu de recul et se méfier de la propagation des discours qui ne sont pas toujours fondés : ce visuel présente un certain danger de réduction de la problématique du partage de données structurées sur le web, d’abord parce que d’autres données liées sont disponibles que celles représentées par cette image (ne pas prendre ce diagramme comme un point d’entrée si vous cherchez des données), ensuite parce que cette image a tendance à masquer les problématiques bien différentes qui se cachent derrière ces données (mise en ligne de bases de données déjà structurées, utilisation de données crowdsourcées, traitement automatique du langage, retraitement de formats semi-structurés, aggrégations de plusieurs bases, etc.), ensuite encore parce qu’il ne dit rien de la qualité des données publiées, finalement parce que les données structurées sur le web, c’est aussi l’open data ou la structuration des contenus (RDFa, schema.org). Mais cette image reste un excellent support de communication pour introduire la problématique.

Bon, et sinon, si on regarde d’un peu plus près cette image, qu’y voit-on ?

• D’abord (mais ça ne se voit pas), la détection des données est faite à la fois à partir des données référencés dans l’annuaire datahub.io (tag lod) et (c’est nouveau) à partir d’un crawl automatique des données du web datant d’avril 2014;
• Il y a plus de jeux de données : 520 contre 337 dans la version précédente; et 2900 liens entre jeux de données;
• La taille des cercles n’est plus proportionnelle à la quantité de données, mais aux nombres de liens entrants. Ce n’est pas la taille qui compte (!), mais, dans ce monde en réseau, le nombre de données qui référencent les vôtres;
• Geonames occupe une place (presque) aussi centrale que DBPedia;
• Il y a un nouveau code couleur pour les datasets relatifs à la linguistique;
• On y trouve maintenant les déclinaisons linguistiques de DBPedia, comme le DBPedia francophone;

Et si l’image a été remise à jour, le message qui l’accompagne dans les présentations devrait lui-aussi subir un petit lifting, et c’est intéressant de lire ce que réponds Chris Bizer là-dessus notamment en comparant les données liées et les contenus structurés (Microdata/RDFa/Microformats) :

• Les sites qui mettent à disposition des données structurées sous forme de Microdata/RDFa/Microformats sont 1000 fois plus nombreux (« three order of magnitude larger ») que ceux publiant de la données liée;
• Les données liées et les données disponibles via Microdata/RDFa/Microformats ne couvrent pas les mêmes domaines : e-gouvernment, bibliothèques, sciences de la vie, linguistiques, géographie pour les premières, et produits, commentaires utilisateur, adresses, événements, offres d’emploi, recettes, personnes pour les secondes. Peu de recouvrement entre les 2 technologies en terme de données;
• dans le monde Microdata/RDFa/Microformats, on ne trouve pas, ou très peu, de liens vers d’autres données, là où on en trouve dans le monde des données liées, jusqu’à un certain point (normal, c’est fait pour ça); et la présence de liens, notamment vers des référentiels terminologiques partagés, peut favoriser la réutilisation des données;
• Les données que l’on trouve dans les données liées sont très structurées, celles que l’on trouve en Microdata/RDFa/Microformats ne vont en général pas plus loin que 3 ou 4 attributs, contenant en général du texte;

Et de conclure : « Les données liées ont donc été adoptées par des communautés qui ont un intérêt à voir leurs données facilement réutilisées et sont prêtes à en faire l’effort, comme les bibliothèques, les gouvernements, le monde de la recherche (avec en tête les sciences du vivant et la linguistique qui ont adopté en premier ces technologies) et les réseaux sociaux. Et il est aussi logique de voir que d’autres communautés adoptent Microdata/RDFa/Microformats, celles qui veulent principalement pousser leurs données vers les applications Google pour avoir plus de trafic sur leur site et qui n’ont pas d’intérêt à créer des liens [dans leurs données] vers d’autres (qui sont probablement de toutes façons leurs concurrents) ».

Alors, en caricaturant, les données liées pour le public, Microdata/RDFa/Microformats pour le privé ? on n’est pas si loin de la vérité, sans doute.

Cet article Linked Open Data Cloud : nouvelle version est apparu en premier sur Sparna Blog.

Je continue à creuser le sillon entamé précédemment de démos simples et réutilisables de ce que peuvent apporter les données disponibles sur le web pour enrichir un texte, sans infrastructure compliquée. Pour cela je vous invite à entrer dans le laboratoire de sparna.fr ! http://labs.sparna.fr sera un terrain de jeu qui hébergera dans le futur d’autres applications et illustrations des technologies du web de données et de l’open data, « so stay tuned » !

Mais revenons à la démo, ou aux démos puisqu’il s’agit de 2 pages :

• la première page de démo est un article scientifique en français enrichi grâce aux données de la base Isidore;
• la seconde est un article de presse en anglais enrichi grâce aux données de DBpedia.

Qu’est-ce qu’elles illustrent ?

1. La génération du contenu d’une partie du contenu à partir des données du web : ici, la génération automatique de la liste des articles du même auteur dans la page Isidore;
2. L’affichage d’informations contextuelles lorsqu’on clique sur un élément annoté dans le texte : dans le cas de l’article scientifique, on va chercher sur Isidore, dans le cas de la news, sur DBpedia, mais le principe est le même : on affiche un encart avec titre, photo, définition ou description et un lien vers une page plus complète;
3. Dans la démo DBpedia, la l’affichage sur une carte des noms de lieux mentionnés dans le texte : les noms des villes, régions ou pays sont marqués avec un identifiant DBpedia, et on va récupérer dynamiquement l’information de positionnement dans DBpedia, pour afficher un marqueur sur la carte; la carte et le texte sont synchronisés, quand on passe la souris sur un lieu géographique dans le texte, le marqueur correspondant sur la carte se met en surbrillance, et inversement;
4. Dans la démo Isidore, la navigation dans les termes des thesaurus; certains mots du texte dans l’article (« habitat », « XVIIIe siècle », etc.) renvoient vers les concepts abstraits d’un thesaurus; on récupère alors les notions plus génériques et plus spécifiques de cette notion, qui seront elles-mêmes cliquables et permettent donc de naviguer dans la hiérarchie des terminologies associées à l’article;
5. Dans le démo DBpedia, la possibilité d’afficher les informations dans plusieurs langues, simplement en changeant un paramètre de la page : essayez en français, en russe, en néerlandais, etc. vous avez compris l’idée, il suffit de changer le paramètre de langue dans l’adresse de la page;
6. Enfin, tout cela illustre l’interrogation de bases SPARQL directement depuis les pages HTML, sans infrastructure serveur, puisque les requêtes sont envoyées en utilisant JSONP depuis du javascript; A noter que cela demande que le endpoint SPARQL supporte le JSONP; c’est le cas de Virtuoso qui est utilisé pour DBpedia et Isidore; Sesame le supportera dans sa prochaine version.

Que peut-on imaginer à partir de ça ? Plusieurs idées :

• se brancher derrière un annotateur automatique qui mettrait les annotations automatiquement (type DBpedia Spotlight), pour présenter une interface de navigation enrichie à partir de n’importe quel texte;
• imaginer une interface de navigation dans des thesaurus SKOS que l’on pourrait « brancher » sur n’importe quelle source de données contenant du SKOS pour naviguer dans des terminologies;

Vos idées et vos cas d’usage sont les bienvenus ! n’hésitez pas à montrer ces pages comme des démos ou à les récupérer et les adapter avec votre propre contenu !

English summary :

I have launched http://labs.sparna.fr and I am presenting 2 demos of articles augmented with linked data :

• the first one is a demo of a news article in english augmented with DBpedia data;
• the second one is a demo of a scientific article in french augmented with data from Isidore (Isidore is a data repository containing humanities articles metadata and classification thesaurii);

These pages illustrate :

• How you can generate part of the content dynamically from the web of data : the list of articles from the same author in the Isidore demo is fetched dynamically when the page loads;
• How you can pull and display contextual information besides the text, in an « infobox », when the reader clicks an underlined word;
• How you can fetch geographic coordinates from DBpedia to automatically plot the locations mentionned in the text on a map (provided they have been « tagged » with a DBpedia identifier), in the DBpedia demo;
• How you can navigate thesaurus terms in the Isidore demo : some words correspond to thesaurus concepts (« habitat », « XVIIIe siècle »), thus generic and specific concepts are displayed in the infobox;
• That the data in DBpedia can be fecthed in diferent languages to adapt to the reader’s language : try to load the DBpedia demo in french, in russian, in dutch… and try playing with the 2-letter language code in the URLs to display other languages;
• How SPARQL queries can be executed directly from within an HTML page without requiring any server infrastructure, provided the SPARQL endpoint supports JSONP;

Don’t hesitate to save the webpages and adapt them with your own annotated content, and drop me a note if you have other use-cases in mind !

Cet article Des articles enrichis grâce au web de données (DBpedia, Isidore) est apparu en premier sur Sparna Blog.

Le schéma de données, quel schéma de données ?

Facilite les phases de prototypage

Dans les approches à base de RDF+SPARQL, on n’a pas besoin d’avoir un schéma de données pour commencer à travailler. On a juste besoin des données. Le schéma peut venir après. « Data first, model after ». C’est une approche « bottom-up », là où les SGBD+SQL ont nécessairement une approche « top-down » : « model first, data after ». Cela permet un prototypage rapide des projets : plus besoin d’attendre d’avoir défini un modèle de base de données avant de faire une première requête.

Intégration de données hétérogènes

Ces absence de schéma, de modèle, dans les bases de données RDF (triplestores) donne la possibilité d’y intégrer des données :

• hétérogènes : exprimées avec des modèles différents, en ayant ensuite la possibilité de les réconcilier sur un modèle unique si besoin;
• incomplètes : avec des valeurs manquantes, en ayant la possibilité de repérer ces objets anormaux si besoin;
• incohérentes : venant de sources différentes qui donnent des informations contradictoires, en ayant la possibilité de repérer ces incohérences et de les corriger si besoin;

Une infinité de points de vue

Zéro schéma signifie aussi une multiplicité de schémas. Les technologies sémantiques permettent d’exprimer les mêmes données suivant plusieurs schémas dans la même base, offrant alors plusieurs « points de vue », plusieurs façons de voir les mêmes données. Et ceci automatiquement avec de l’inférence OWL. Chaque application consommant les données pourra alors s’appuyer sur le schéma qu’elle comprend. On favorise ainsi l’interopérabilité entre applications. Un exemple ? le standard de représentation SKOS permet une représentation simple de systèmes d’organisation de connaissances (thesaurus, arbres de classement, …) , à base de « Concept » qui portent des « prefLabels » (libellés préférentiels). C’est un format d’échange commode, mais inadapté à la représentation de bases de connaissances riches, comme une base de personnes. Il est tout à fait possible de dire « ce que tu appelles une Personne dans ton système je l’appelle également un Concept SKOS, et la propriété foaf:name que tu utilises correspond à la propriété skos:prefLabel SKOS », pour ainsi obtenir une « vue » SKOS d’une base de personnes.

Ce faisant, on permet également de séparer les métadonnées initiales des contenus (riches et compliquées) des catégories de ces contenus pour la diffusion, en fonction des supports ou des publics (souvent plus simples et liées à l’usage). L’exemple classique est l’hôtel rangé dans une catégorie « bon marché » alors que ses métadonnées initiales sont plus complexes : prix par nuit, nombre d’étoiles, labels, piscine, etc.

Flexibilité maximale

Le fait que le schéma ne contraigne pas les données donne une flexibilité et une évolutivité importante au système. On peut rajouter, supprimer, modifier un attribut ou une classe à la volée. On peut modifier le schéma, sans toucher aux données. On peut même changer de schéma facilement. Prenons un cas d’intégration de données : une application intégrant une source de données externe avec ses propres données, et se retrouvant confronté au cas où cette source de données change de format et de modèle :

• dans le monde du XXème siècle, en SGBD+SQL, confronté à un tel cas on doit 1/ modifier le parsing des données qui ont changé, 2/ modifier les tables du système pour prendre en compte ce nouveau format, 3/ modifier les requêtes de l’applicatif.
• Dans le monde du XXIème siècle, en RDF+SPARQL : 1/ pas de parsing à modifier (les données arrivent toujours en RDF), 2/ pas de schema à modifier (il n’y en a pas) et 3/ il faut toujours modifier les requêtes de l’applicatif… plus qu’un 1/3 du travail. Et encore, il est possible, le temps de modifier les requêtes, d’ajouter de l’inférence pour recréer les données dans l’ancien modèle à partir du nouveau, de façon à ce que les requêtes continuent à répondre.

Le raisonnement, ou les manipulations automatiques des données

Réconciliation

Le raisonnement est la capacité des outils RDF à déduire automatiquement de nouvelles informations à partir des informations existantes. Notons bien que ces capacités de raisonnement ne sont ni proposées par tous les outils RDF, ni forcément utiles dans tous les contextes. Elles vont par exemple permettre de réconcilier les données hétérogènes sur un modèle commun : « Ensemble des personnes = ensemble des contacts qui viennent de mon répertoire de téléphone + ensemble de mes contacts dans les réseaux sociaux ».

Classification

Le même mécanisme est utilisé pour des besoins plus proches de la classification (« repurposing » de contenu), pour définir les ensembles d’objets dans des points de vue multiples, tel qu’évoqué plus haut. On peut par exemple avoir d’un côté l’ensemble des objets « Hébergements », et de l’autre l’ensemble des objets « Hôtels pas chers » défini comme « l’ensemble des objets Hébergements qui sont de type hôtel et ont un prix par nuit inférieur à 60 euros ». Le deuxième ensemble sera calculé à partir du premier, automatiquement.

Inférence

L’inférence permet de précalculer des liens ou des données qui facilitent l’écriture des requêtes et améliorent les temps de réponse. Le total des buts marqués par une équipe de football dans une compétition est calculé comme la somme de tous les buts marqués par cette équipe dans les matchs de cette compétition. La donnée est calculée une fois, et peut ensuite être présentée directement sur la page de l’équipe, il n’y a pas de calcul à faire au moment de l’affichage (voir le site de la coupe du monde de la BBC, réalisé à partir des technologies du web de données en utilisant le raisonnement).

Consistance

L’inférence est aussi ce qui permet de contrôler la consistance par rapport au modèle de données. Car si en RDF il est possible de ne pas avoir de schéma, dans les cas où il y en a un, le moteur d’inférence sera capable de déterminer si les données sont consistantes par rapport à ce schéma ou non.

Conclusion…

Ce travail d’analyse partiel est une synthèse des expériences acquises avec ces technologies, et des lectures spécialisées (le forum answers.semanticweb.com contient beaucoup de réponses intéressantes). Il doit permettre de bien situer les avantages de ces technos pour ne pas en faire une évangélisation aveugle, et de les utiliser au mieux pour résoudre des problèmes concrets. Il y aurait peut-être d’autres avantages à étudier, comme la réutilisation possibles de schémas existants, comme ceux que l’on peut trouver dans le LOV (Linked Open Vocabularies).

De plus en plus de projets vont vouloir soit tirer parti de ce qui est publié librement sur le web de données, soit rationnaliser des intégrations d’API compliquées, ou encore améliorer leurs chaines de traitement et de diffusion de contenus, ouvrir des données de bases auparavant fermées, aligner des référentiels avec du raisonnement, etc… tous ces projets peuvent bénéficier d’une approche basée sur le web de données. Si vous voulez en savoir plus, n’hésitez pas à réagir ici ou à me contacter.

Cet article Bénéfices clés des technologies du web de données 2/2 – absence de modèle, raisonnement est apparu en premier sur Sparna Blog.

Par conséquent, les projets où le modèle de données est stable et qui n’ont ni besoin d’intégrer des données provenant d’autres systèmes, ni besoin de fournir leurs données à d’autres systèmes, n’ont pas de bénéfice à utiliser cette approche. Elle a tout son sens notamment dans les projets d’ouverture des données, d’open data (la donnée est distribuée et les modéles hétérogènes) mais il faut y sensibiliser les acteurs. J’examine dans ce premier post le premier de ces 3 bénéfices : un réseau de données décentralisées, distribuées.

L’environnement distribué, ADN du web

Tout comme l’hypertexte a révolutionné les contenus et les documents dans un contexte distribué (la façon de les écrire, de les diffuser, d’y naviguer), le web de données – on pourrait parler d’ « hyperdonnées » ou d’ « hyperdata » pour faire le paralelle – permet de prolonger encore cette approche en l’appliquant aux données des applications. C’est-à-dire en mettant en relation les données dans un environnement distribué.

Interrogation fédérée des données

Cet aspect distribué permet une interrogation fédérée des données. Plus la peine d’avoir toutes les données au même endroit pour les interroger. Dans le monde SGBD+SQL, pour interroger plusieurs sources de données, on doit forcément les avoir dans le même système. En RDF+SPARQL, le mot-clé SERVICE permet d’envoyer des critères de recherche à des sources de données différentes, et de combiner les résultats en une seule requête. Un exemple de requête sur le web de données est « donne-moi la date de naissance des acteurs de Star-Trek » (une première source de données a l’info des acteurs de Star-Trek, une source différente a leur date de naissance).

Interconnection des données

Cette approche distribuée permet également de combiner des données enfouies dans des systèmes propriétaires pour les réutiliser ensemble. Vous savez, c’est quand la comptable aimerait bien recouper des infos de facturation qui sont dans un CRM du genre SAP avec les feuilles de temps des employés qui sont dans une base Oracle… au XXème siècle on lui dit gentiment que ce n’est pas possible, au XXIème siècle on ajoute un middleware relationnel vers RDF, et hop, soit en utilisant une requête fédérée avec SERVICE (voir plus haut), soit en intégrant les données ainsi traduites dans un triplestore (voir le prochain post), le recoupement d’informations devient possible.

La même problématique se retrouve dans l’open data; comment utiliser ensemble des données sur les lycées, celles sur les collèges et les écoles, et d’autres sur la population pour créer une (hypothétique) application qui montrerait la carte scolaire ? en ayant normalisé ces données qui parlent de la même chose (« établissement », « nombre d’élèves », « latitude »,  « longitude », etc…), et en ayant fait des liens entre elles (« le collège se trouve dans le quartier X », et « le quartier X a tant d’habitants »). Notons que les bénéfices de cette mise en commun des données sont autant pour les utilisateurs des données que pour les collectivités elles-mêmes qui vont avoir accès en un point central à des données auparavant hétérogènes.

Enrichissement des données

L’interconnection des données permet de tirer parti des données qui viennent de l’extérieur du système développé. On peut ainsi enrichir un système interne qui utilise les technologies du web de données par des informations venant de sources de données externes : une photo provenant de DBPedia, une arborescence géographique provenant de Geonames (« France > Champagne-Ardenne > Marne > Arrondissement d’Epernay > Epernay »), les listes d’ouvrages d’un auteur provenent de la BNF, etc.

Qu’est-ce qui permet cet aspect distribué ?

Cette distribution n’est possible que parce qu’un certain nombre d’efforts ont été fait pour obtenir un accès unifié aux données. Cet accès unifié aux données passe notamment par :

• Une identification de chaque objet avec une URI, et la possibilité d’accéder aux données de cet objet simplement en « appellant » cette URI. Pas besoin d’une requête compliquée ou d’un protocole d’accès obscur, on utilise HTTP, le protocole du web; si on veut « référencer » un objet dans nos données, on indique simplement son URI;
• Un protocole d’interrogation standardisé : SPARQL. Attention, il y a bien non seulement le langage d’interrogation SPARQL, lui-même bien mieux normalisé que SQL dont les multiples variantes ne facilitent pas les migrations d’un outil vers un autre, mais également le protocole d’interrogation, qui permet d’interroger n’importe quelle source de données de façon standard, sans avoir besoin d’un quelconque « driver » comme en SQL.

Ces efforts de standardisation ont par ailleurs des « effets de bord » positifs :

• une plus grande indépendance vis-à-vis des outils. Si le protocole et le langage de requête sont standards, il est possible de commencer à utiliser des outils gratuits (Sesame, Jena) en phase de prototypage et de passer ensuite de façon transparente sur des outils commerciaux sans rien redévelopper;
• l’interrogation des données se faisant par le protocole HTTP, il est très facile de déployer un système de cache HTTP pour améliorer les temps de réponse. Ces outils de cache (par exemple Squid) sont largement connus et déployés par les administrateurs systèmes, là où les mécanismes de cache au niveau d’une base de données sont plus compliqués à mettre en oeuvre (outils propriétaires et plus bas niveau).

L’aspect décentralisé est dans l’ADN du web. Il est normal qu’il s’applique aux données après s’être appliqué aux documents. Il est également normal de parler de préférence de « web de données », et non pas de web « sémantique », adjectif vague, aux promesses floues qu’il faut sans cesse expliquer; le terme « web de données » est mieux défini et ses promesses plus concrètes.

Dans la deuxième partie j’examinerai les deux autres bénéfices clés des technologies du web de données : l’absence de schéma et les possibilités de raisonnement.

Cet article Bénéfices clés des technologies du web de données 1/2 – l’environnement distribué est apparu en premier sur Sparna Blog.

Le web de données, de son côté, n’a jamais permis autre chose que la diffusion et l’interconnexion de données à l’échelle du web. Il aura fallu attendre la libération des données publiques pour que cet enjeu devienne clair. L’open data offre le cas d’usage idéal pour le web de données – car en fait, on pourrait presque dire que ces 2 mots désignent la même chose et ont le même objectif.

Soyons clair : avancer vers les technologies du web de données, pour un producteur de données, demande un effort supplémentaire. Que peut-il en attendre ? J’y vois 5 enjeux :

1. Devenir un producteur de données de référence. La possibilité offerte par les standards du web de données de faire des liens entre les instances décrites dans les données, permettent à un producteur d’obtenir des liens entrants vers ses données, devenant ainsi un « hub », un acteur central dans le réseau de données. C’est un enjeu stratégique : si vous n’ouvrez pas vos données aujourd’hui, d’autres le feront à votre place, et deviendront les référents.
2. L’enrichissement de ses données avec celles des autres; La possibilité de relier les éléments décrits dans les données à d’autres, comme celles de la BNF, de l’INSEE, d’Eurovoc, de DBPedia, va permettre aux consommateurs des données de suivre ces liens et d’enrichir le système qu’ils construisent avec ces nouvelles données.
3. La normalisation de son catalogue de données au format DCAT, le rendant ainsi interopérable avec les catalogues des autres producteurs. Cela améliore la visibilité et la réutilisation du catalogue des datasets.
4. La réutilisation de modèles existants pour décrire les données; les données publiées depuis 10 ans couvrent de nombreux domaines du savoir, et la problématique de description de beaucoup de données a donc déjà été traitée. De nombreux vocabulaires sont déjà disponibles (sur le LOV par exemple) et prêts à l’emploi pour décrire le contenu des données.
5. Le bénéfice d’outils existants, et de futures évolutions. Poussé par le W3C, les standards du web de données sont ouverts, pérennes, et formeront la base d’autres technologies, par exemple pour indiquer la traçabilité et les versions des données. Les outils compatibles avec ces standards existent et continueront d’exister.

Y a-t-il, y aura-t-il convergence ? les projets de recherche comme Datalift proposent des outils basés sur les technologies du web de données pour que les producteurs de données « sémantisent » les données. Et moi aussi, je peux vous aider !

Update

Etalab vient de publier le compte-rendu de l’événement « Datalift Camp » qui adressaient ces problématiques et dont ces réflexions personnelles sont issues.

Cet article Open data et web de données : convergence ? est apparu en premier sur Sparna Blog.