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.

Les mouvements du « Data Is King »

Le principe « Data is King » sous-tend les mouvements suivants :

L’Open Data : l’ouverture des données (publiques avec data.gouv.fr ou privées) induit une structuration de l’écosystème des acteurs en deux : d’un côté ceux qui produisent la donnée, de l’autre côté ceux qui l’utilisent ou la réutilise (par une posture de neutralité nécessaire, le producteur de la donnée ne peut pas être celui qui illustre son utilisation dans une application, sous peine de perdre cette impartialité quant à la donnée). Cette structuration illustre parfaitement la notion de réutilisation des données dans plusieurs applications.

Le Web de données, ou sémantique : la notion de web de données, tout en étant antérieure dans le temps à la notion d’Open Data, en est en fait l’aboutissement, la dernière marche au niveau qualitatif. Un peu comme si, se rendant compte que la barre du web sémantique avait été mise trop haut, les architectes du web avaient mis là une marche intermédiaire : publiez vos données d’abord, peu importe le format. Pour ce qui est des aspects propres au web de données, à savoir l’identification des concepts avec des URI et les relations avec d’autres données, hé bien, on verra plus tard, une fois que cette marche aura été franchie. Sous cette problématique se retrouve là encore le « Data is King », les promesses du web en plus : décentralisation, liens, accès par tous et partage par tous.

Gestion du contenu et SEO. Finit le SEO à base des quelques mots-clés mis au bon endroit dans la page. Depuis schema.org, ce qu’il faut pour « ranker », ce sont des données structurées. La promesse de remonter dans les résultats de recherche va inciter les web agencies et les producteurs de contenu à publier leurs métadonnées, voire à produire lorsqu’elles n’y sont pas. On va pouvoir se passer de moteur de recherche dans les systèmes, se contenter de publier de la donnée structurée, et tout faire reposer sur Google pour l’indexation.

L’autre buzzword du moment, Big Data, n’est pour moi pas lié à cette philosophie « Data Is King ». Le Big Data, c’est d’abord de gros algorithmes permettant de traiter beaucoup de données, l’accent est plus mis sur l’infrastructure, la performance, et la scalabilité, que sur les données elles-mêmes.

Les échelles du « Data Is King »

Le principe « Data is King » se retrouve à plusieurs échelles. A l’échelle des applications d’abord, où l’on va privilégier la modélisation claire des schémas de données, et – au minimum – s’assurer que les données ne sont pas prisonnières des applications, voire privilégier dès le départ une politique d’ouverture des données des applications. On le voit avec un peu de recul, les applications passent, les données restent, il est donc capital de faire en sorte que les données ne sont pas propres aux applications, qu’elles peuvent être réutilisées dans d’autres contextes. On ne développe plus des applications, on développe des données; d’autres développeront les applications qui viendront tirer avantage de ses données. La donnée fait partie du capital de l’entreprise, l’application n’en fait pas partie.

A l’échelle des architectures applicatives ensuite, où l’on passe d’architectures orientées services (SOA) à des architectures orientées données, qu’on pourrait appeler DOA par jeu d’opposition. Cela est directement lié aux architectures REST, mais va un peu au-delà, dans la mesure où REST, bien que nécessitant d’identifier des ressources par des URIs, ne privilégie pas nécessairement les données sur le document. Il est plus facile de décentraliser les données et de centraliser les services que de décentraliser les services et de centraliser les données. La promesse d’interopérabilité du SOA et de SOAP est d’emblée dépassée par les architectures REST.

A l’échelle du web enfin, où l’on est en train d’ajouter au web des documents un web des données. Les liens de cette nouvelle couche de la toile ne se font plus de page à page, mais de données à données. Les données sont publiées, interreliées, interprétables par les machines, réutilisables.

Vive le roi Data !

Cet article Data Is King ! est apparu en premier sur Sparna Blog.