Sparna Blog http://blog.sparna.fr Web de données | Architecture de l'information | Accès aux connaissances Wed, 12 Jul 2017 07:20:19 +0000 fr-FR hourly 1 Outil de test de vocabulaires SKOS http://blog.sparna.fr/2017/07/11/outil-de-test-de-vocabulaires-skos/ http://blog.sparna.fr/2017/07/11/outil-de-test-de-vocabulaires-skos/#comments Tue, 11 Jul 2017 08:11:39 +0000 http://blog.sparna.fr/?p=1151 Nous avons développé un outil de test de vocabulaires SKOS (« SKOS Testing Tool »). Cette application est une interface vers l’outil de validation qSKOS de Christian Mader. L’application est gratuite, open-source, sans login, et en français ! Vous pouvez soumettre des demandes d’évolution ou des remontées de bug sur le Github du projet. L’outil permet de…

Cet article Outil de test de vocabulaires SKOS est apparu en premier sur Sparna Blog.

]]>
Nous avons développé un outil de test de vocabulaires SKOS (« SKOS Testing Tool »). Cette application est une interface vers l’outil de validation qSKOS de Christian Mader.

L’application est gratuite, open-source, sans login, et en français ! Vous pouvez soumettre des demandes d’évolution ou des remontées de bug sur le Github du projet. L’outil permet de :

  • valider un fichier SKOS uploadé ou à partir d’une URL;
  • sélectionner les règles à vérifier;
  • récupérer le résultat de la validation dans un rapport HTML, le format texte brut de qSKOS, ou en RDF dans le Data Quality Vocabulary DQV;
  • pointer directement sur l’URL du rapport de test à partir d’une URL de fichier SKOS (voir les détails sur la page de documentation Github);

Vous avez dit « test de SKOS » ?

On peut distinguer plusieurs niveaux de règles dans les règles vérifiées par qSKOS et l’outil de test :

Les contraintes formelles : SKOS défini peu de contraintes formelles :

  • un concept ne doit pas avoir plus d’un skos:prefLabel par langue
  • un même libellé ne peut pas être à la fois prefLabel ou altLabel
  • une entrée ne peut pas être à la fois Concept et Collection
  • et c’est à peu près tout.

Les conventions SKOS : SKOS donne des contraintes qui sont plus des conventions ou des bonnes pratiques :

  • les relations d’alignement sont à utiliser entre des ConceptScheme différents
  • il faut mieux ne pas avoir d’homonymes dans un ConceptScheme
  • les skos:notation doivent être uniques dans un même ConceptScheme
  • un Concept marqué comme « top concept » (racine) ne doit normalement pas avoir de skos:broader
  • etc.

Les « boulettes classiques » :

  • Concepts sans libellés;
  • Cycles dans la hiérarchie des concepts;
  • Caractères spéciaux dans les libellés (copier-coller depuis Word…)
  • etc…

Les bonnes pratiques de publications de données liées : L’outil vérifie quelques autres bonnes pratiques de publication :

  • Il faut mieux que les concepts soient documenter avec des propriétés de documentation SKOS;
  • Il faut mieux qu’ils soient reliés à d’autres concepts dans le vocabulaire (avec des broader, narrower ou related);
  • Il faut mieux qu’ils fassent référence à d’autres données sur le web (linked data);

Correction automatique des fichiers

La prochaine grande étape après le test sera de proposer des corrections automatiques des données pour certain problèmes, similaires à ce que fait Skosify.

A vos vocabulaires !

Illustration : « Usage des nouvelles mesures » sur Gallica : http://gallica.bnf.fr/ark:/12148/btv1b8412951c

Cet article Outil de test de vocabulaires SKOS est apparu en premier sur Sparna Blog.

]]>
http://blog.sparna.fr/2017/07/11/outil-de-test-de-vocabulaires-skos/feed/ 0
Référentiel ROME de Pôle Emploi en SKOS (à partir de data.gouv.fr) http://blog.sparna.fr/2017/04/18/rome-pole-emploi-skos-rdf-data-gouv-fr/ http://blog.sparna.fr/2017/04/18/rome-pole-emploi-skos-rdf-data-gouv-fr/#comments Tue, 18 Apr 2017 08:31:17 +0000 http://blog.sparna.fr/?p=1132 Etalab, la mission chargée de la politique Open Data de l’administration aujourd’hui intégrée à la DSI de l’Etat, vient d’ouvrir le portail du service public de la donnée (lire l’article sur silicon.fr) : des jeux de données de référence, « à fort impact économique et social », d’un niveau de qualité et de fraîcheur garanti. Parmi ceux-ci…

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

]]>
Etalab, la mission chargée de la politique Open Data de l’administration aujourd’hui intégrée à la DSI de l’Etat, vient d’ouvrir le portail du service public de la donnée (lire l’article sur silicon.fr) : des jeux de données de référence, « à fort impact économique et social », d’un niveau de qualité et de fraîcheur garanti. Parmi ceux-ci le Répertoire Opérationnel des Métiers et de l’Emploi (ROME), la classification utilisée par Pôle Emploi.

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.

]]>
http://blog.sparna.fr/2017/04/18/rome-pole-emploi-skos-rdf-data-gouv-fr/feed/ 2
UNESCO Thesaurus published with Semantic Web standards and Open-Source software http://blog.sparna.fr/2017/02/06/unesco-thesaurus-published-with-semantic-web-standards-and-open-source-software/ http://blog.sparna.fr/2017/02/06/unesco-thesaurus-published-with-semantic-web-standards-and-open-source-software/#comments Mon, 06 Feb 2017 08:03:10 +0000 http://blog.sparna.fr/?p=1102 Sparna conducted in 2016 the replacement of the Thesaurus Management Software and thesaurus publication platform for the UNESCO, with Open-Source tools all relying on Semantic Web technologies. The result is the new UNESCO vocabularies publication platform at http://vocabularies.unesco.org. The project was conducted in 2 phases : a new thesaurus publication platform based on Skosmos, SKOS…

Cet article UNESCO Thesaurus published with Semantic Web standards and Open-Source software est apparu en premier sur Sparna Blog.

]]>
Sparna conducted in 2016 the replacement of the Thesaurus Management Software and thesaurus publication platform for the UNESCO, with Open-Source tools all relying on Semantic Web technologies. The result is the new UNESCO vocabularies publication platform at http://vocabularies.unesco.org. The project was conducted in 2 phases : a new thesaurus publication platform based on Skosmos, SKOS Play and Fuseki, and in a second phase the deployment of VocBench as the new Thesaurus Management Software. The system leverages Semantic Web standards by relying on SKOS as the data exchange format, SPARQL as the online thesaurus query language, and dereferancable URI identifiers.

The new thesaurus browser

The first objective was to replace the thesaurus publication platform, while maintaining existing backoffice tools for thesaurus management. This choice allowed to quickly demonstrate a publicly available interface for searching and browsing the vocabulary, without waiting for the deployment of the complete system.

Skosmos was used as the thesaurus browser; it is easy to deploy, well documented, and the team behind it from the National Library of Finland is super-reactive for fixing bugs. It offers out-of-box features like alphabetical/hierarchical browsing, autocomplete search, URI-based content negociation, and a feedback form. Important aspects for UNESCO were the ability to have a multilingual interface (English, French, Spanish, Russian), the possibility to customize the stylesheets/logo/help page, or the order of the fields in a concept display page. We added a direct link to trigger a search in the UNESDOC database from a concept page in Skosmos, thus easily linking the new thesaurus browser to the existing resource center.

unesco-skosmos

UNESCO thesaurus published in Skosmos

2 additionnal components were used for a complete vocabulary publishing solution; SKOS Play was used to generate downloadable PDF documents generated from the SKOS thesaurus : complete editions of the thesaurus with alphabetical index, hierarchical tree and translation tables, and KWIC indexes, each in French, English, Spanish and Russian. The documents are regenerated automatically each time a new version of the thesaurus is published. Fuseki with a customized SPARLQ form is used as the frontend for public SPARQL querying of the thesaurus.

Meron Ewketu, responsible for the UNESCO thesaurus, describes the benefits of the new publication platform : « The obvious benefit is the enhanced user interface : a nice hierarchical display, a powerful search, an easy navigation between the different language versions. Thanks to these features the platform was immediately endorsed by our user community. What is also very much appreciated is the possibility of responding to various user needs in terms of format and content. Being able to extract part of the thesaurus as per our users’ requirements, and being able to deliver the content in a variety of formats, including PDF, using the SPARQL endpoint and SKOS Play. We have also noticed an increase in user participation. The feedback form enabled us to engage with our users more easily.« 

The Collaborative Thesaurus Management Software

The second phase of the project aimed at replacing the old thesaurus management software, and integrating it with the new thesaurus browser. UNESCO and Sparna chose to deploy VocBench, an open-source SKOS-based thesaurus management solution from the Tor Vergata University in Rome. We also considered Ginco as a possible alternative; VocBench was chosen mainly for its ability to properly handle collaborative multi-user maintenance of the thesaurus; this was an important aspect for UNESCO, having remote contributors to the thesaurus in Russia, and translations in Chinese and Arabic coming in the future; the ability to work remotely and to have a validation workflow of the modifications was essential. In addition, Vocbench is already deployed by other international organizations, and the upcoming v3 of Vocbench is funded by the ISA2 program of the European Union, thus giving garantees as to the maintenance of the application in the next few years.

unesco-vocbench

UNESCO Thesaurus managed in VocBench

VocBench is SKOS-XL from the bottom up and stores the thesaurus data in an RDF triplestore. We chose to deploy GraphDB from Ontotext as the backend for VocBench. VocBench offers user profile management and edition workflow management, multilingual thesaurus editing, and the possibility to add custom attributes to the thesaurus concepts and terms. We used this to capture corresponding country codes and language codes for certain concepts in the UNESCO thesaurus with a small UNESCO vocabulary publishing ontology describing these 2 properties.

The deployment in production of Vocbench is fairly complex, essentially due to the middleware component on which it relies, called SemanticTurkey; VocBench requires a total of 4 pieces of software (relationnal database, RDF triplestore, SemanticTurkey server, VocBench application server). But, once you are familiar with the procedure, and again with the precious help of the community on th mailing-list, everything works fine. Another limitation of VocBench v2 is that it does not support SKOS Collections, only ConceptSchemes.

Ms Ewketu explains the benefits of VocBench : « Apart from the obvious functionalities of collaborative and distributed maintenance, other important aspects for us were the ability to manage several vocabularies and the ability to make alignments with other thesauri. Being able to document changes through history notes is something very interesting, which I am sure we will exploit in the future. This is quite interesting for researchers who study the evolution of terminology, within an organization.« 

« leverage the thesaurus to achieve interoperability« 

The project clearly is a success story for Semantic Web technologies : with URIs, RDF and SKOS as W3C standards, the UNESCO has achieved its mission of transforming its thesaurus into open, reusable data. The thesaurus is now available for browsing by humans and in machine-readable formats. URIs makes it open for linking from/to other knowledge organization systems on the web, thus enabling interoperability between document databases of multiple organizations.

The project is also a great success story for Open Source; the support from the community and the maintainers of both Skosmos and VocBench was essential for such a quality achievement, and Sparna and UNESCO contributed to both communities by providing translations, filing bug reports and testing new versions. It shows how these tools have enabled the UNESCO to replace an entire thesaurus management platform with no licensing cost, no vendor or data lock-in.

« The main benefit of this project for us will be to leverage the thesaurus to achieve interoperability between our different repositories, as well as with external datasets. » concludes Ms Ewketu from UNESCO. « We are currently working on integrating the new thesaurus within the various information systems. Next phase will be mapping our thesaurus with vocabularies such as the UN Thesaurus and Eurovoc. »


Want to learn more ? reach me at thomas /dot/ francart /at/ sparna /dot/ fr.

Cet article UNESCO Thesaurus published with Semantic Web standards and Open-Source software est apparu en premier sur Sparna Blog.

]]>
http://blog.sparna.fr/2017/02/06/unesco-thesaurus-published-with-semantic-web-standards-and-open-source-software/feed/ 4
Créer des référentiels SKOS/RDF à partir d’Excel http://blog.sparna.fr/2017/01/12/creer-des-referentiels-skosrdf-a-partir-dexcel/ http://blog.sparna.fr/2017/01/12/creer-des-referentiels-skosrdf-a-partir-dexcel/#comments Thu, 12 Jan 2017 14:55:12 +0000 http://blog.sparna.fr/?p=1084 Les projets de « moteurs de recherche sémantiques », ou de « d’accès intelligent à l’information » nécessitent de mettre au point, reprendre et maintenir des référentiels d’autorités : concepts d’indexation, liste de personnes, organisations, lieux, etc. Ces référentiels d’autorité forment l’embryon d’un Knowledge Graph de l’organisation. RDF et/ou SKOS sont de bonnes technologies pour implémenter ce Knowledge Graph…

Cet article Créer des référentiels SKOS/RDF à partir d’Excel est apparu en premier sur Sparna Blog.

]]>
Les projets de « moteurs de recherche sémantiques », ou de « d’accès intelligent à l’information » nécessitent de mettre au point, reprendre et maintenir des référentiels d’autorités : concepts d’indexation, liste de personnes, organisations, lieux, etc. Ces référentiels d’autorité forment l’embryon d’un Knowledge Graph de l’organisation. RDF et/ou SKOS sont de bonnes technologies pour implémenter ce Knowledge Graph de par leur structure en graphe, leur absence de modèle contraint et la possibilité de récupérer des données liées sur le web pour enrichir la connaissance interne. La maintenance et le travail sur ce graphe de connaissance peut nécessiter des outils professionnels et commerciaux; mais ils ne sont pas toujours justifiés et les projets simples et les approches pragmatiques feraient mieux de favoriser l’outil le plus simple pour commencer à créer un Knowledge Graph : Excel.

Ce besoin de génération de données RDF à partir de tableaux éditables par tous, sans courbe d’apprentissage, est récurrent. C’est pourquoi SKOS Play vient d’être enrichi avec un nouveau convertisseur de tableaux Excel vers SKOS / RDF. On créé un fichier Excel, on le structure en respectant quelques règles, on le soumet au convertisseur, et celui-ci nous renvoie un fichier RDF/SKOS. Le convertisseur contient quelques règles prédéfinies pour générer du SKOS mais permet très facilement de générer du RDF utilisant n’importe quel vocabulaire (schema.org, SHACL, etc.).

Ce convertisseur en ligne ne demande rien à télécharger, rien à installer, pas de login à créer, n’a pas de limitations, et est entièrement documenté. Il permet sans aucune courbe d’apprentissage de créer des données RDF/SKOS, par des documentalistes ou professionnels de l’information sans formation sur ces notions. Ce développement a été en partie financé par le gouvernement Luxembourgeois dans le cadre du développement de la nouvelle version du portail de recherche Legilux sur la législation luxembourgeoise, qui s’appuie sur un certain nombre de référentiels contrôlés (testez l’autocompletion du champ de recherche pour vous en rendre compte).

Format des fichiers Excel

Le formulaire de conversion inclut un certain nombre de fichiers Excel d’exemples que vous pouvez télécharger pour les adapter à vos propres données, pour respecter le format de tableau attendu par le convertisseur (reportez-vous à la documentation en ligne). Ce format est très simple :

  • quelques informations d’entête dans les premières lignes (URI du ConceptScheme / graphe nommé, métadonnées descriptives du référentiel, déclaration des préfixes, etc.);
  • une ligne déclarant les propriétés RDF correspondant à chaque colonne;
  • puis ensuite une ligne par entrée, avec son URI dans la première colonne puis les valeurs de chaque propriétés dans les colonnes suivante;

Ce qui donne :

screenshot_excel_convert

Génération de données RDF

Le convertisseur supporte tout le modèle SKOS, y compris les skos:Collection, skos:OrderedCollection, le SKOS-XL, etc. avec toutes les facilités de saisie correspondantes (possibilité d’inverser le sens des propriétés, de barrer certaines cellules pour qu’elles ne soient pas converties, etc.). Et pour ceux qui veulent aller plus loin, le convertisseur supporte toutes les constructions RDF avancées :

  • déclaration de préfixes;
  • littéraux avec langues ou datatypes;
  • noeuds anonymes;
  • listes RDF;
  • graphes nommés;

Le convertisseur a été éprouvé dans plusieurs projets en production pour la génération de référentiels d’autorité (personnes, organisations, status, etc.), de concepts SKOS enrichis avec des métadonnées d’autres vocabulaires, et de configuration de Shapes en SHACL.

Intégration avec Google Spreadsheet

Excel c’est bien. Excel collaboratif c’est mieux. C’est pourquoi le convertisseur s’intègre directement avec Google Spreadsheets. Le résultat ? on peut éditer ses tableaux à plusieurs en même temps dans un document en ligne Google, puis se connecter dans le convertisseur avec son login Google, choisir le fichier dans la liste des fichiers de notre Drive, et convertir ce fichier à la volée.

Le web sémantique n’a pas besoin d’être compliqué.

Crédit photo : By Piet Mondrian – Gemeentemuseum Den Haag,  Public Domain, https://commons.wikimedia.org/w/index.php?curid=37614350

Cet article Créer des référentiels SKOS/RDF à partir d’Excel est apparu en premier sur Sparna Blog.

]]>
http://blog.sparna.fr/2017/01/12/creer-des-referentiels-skosrdf-a-partir-dexcel/feed/ 0
SHACL (RDF Shapes Constraint Language) : enfin la possibilité de valider des données RDF http://blog.sparna.fr/2017/01/02/shacl-rdf-shapes-constraint-language-enfin-la-possibilite-de-valider-des-donnees-rdf/ http://blog.sparna.fr/2017/01/02/shacl-rdf-shapes-constraint-language-enfin-la-possibilite-de-valider-des-donnees-rdf/#comments Mon, 02 Jan 2017 12:27:45 +0000 http://blog.sparna.fr/?p=1065 La vie des standards est parfois un peu difficile à comprendre, et c’est particulièrement vrai pour ce qui concerne le web de données. Pourquoi en effet existe-t-il depuis 2004 un standard – OWL – permettant de faire des raisonnements automatiques sur des données, ce dont on a rarement besoin, alors qu’il n’existe aucun standard W3C…

Cet article SHACL (RDF Shapes Constraint Language) : enfin la possibilité de valider des données RDF est apparu en premier sur Sparna Blog.

]]>
La vie des standards est parfois un peu difficile à comprendre, et c’est particulièrement vrai pour ce qui concerne le web de données. Pourquoi en effet existe-t-il depuis 2004 un standard – OWL – permettant de faire des raisonnements automatiques sur des données, ce dont on a rarement besoin, alors qu’il n’existe aucun standard W3C pour vérifier si des données sont conformes, ce dont on a toujours besoin ? la réponse est sans doute dans les besoins et les problématiques des participants au W3C à l’époque, et dans la vision d’un web « sémantique » qui penchait plus vers un idéal d’Intelligence Artificielle que vers un idéal de Données Liées. Seulement on a vite compris que pour faire du raisonnement il faut avoir des données correctes.

Une nouvelle recommandation W3C prévue pour juin 2017, SHACL (SHapes Constraint Language), va remédier à ce manque en permettant d’exprimer des contraintes de vérification sur un graphe RDF.

Le problème avec OWL

Je participe à beaucoup de projets qui impliquent des transformations et des publications de données RDF ou SKOS sur le web. Et c’est bel et bien d’abord des problématiques de validation et de vérification de données que nous avons, et pratiquement jamais des besoins de raisonnements. Or une ontologie n’est pas faite pour vérifier la conformité des données à une spécification, ni faite pour décrire la structure d’un formulaire de saisie de données répondant à ces spécifications.

Ce que nous faisons donc systématiquement est donc de quand même créer une ontologie, mais de « tordre » l’interprétation de cette ontologie en l’utilisant pour vérifier des contraintes. Par exemple le fait d’exprimer que la propriété « a_pour_auteur » a pour « domaine » la classe « Document » en OWL/RDFS veut dire « si X porte la propriété a_pour_auteur, alors c’est un Document », et certainement pas « la propriété a_pour_auteur ne devrait être exprimée que sur des Document »; mais c’est pourtant comme cela que l’ontologie créée est utilisée dans ce contexte (en dérivant par exemple des règles de vérification SPARQL à partir des axiomes OWL).

SHACL

SHACL permettra de spécifier la « forme » (Shape) à laquelle on souhaite qu’un graphe RDF réponde. Cette spécification s’exprime par exemple comme cela (Attention, cet exemple est extrait de la version temporaire de SHACL au 02/01/2017 et peut changer dans la recommendation finale) :

ex:PersonShape
	a sh:Shape ;
        # Applies to all persons
	sh:targetClass ex:Person ;
	sh:property [
                # Constrains the values of the ex:ssn property
		sh:predicate ex:ssn ;     
		sh:maxCount 1 ;
		sh:datatype xsd:string ;
		sh:pattern "^\\d{3}-\\d{2}-\\d{4}$" ;
	] ;
	sh:property [
		sh:predicate ex:child ;
		sh:class ex:Person ;
		sh:nodeKind sh:IRI ;
	] ;
	sh:property [
		rdfs:comment "A person's parents are represented via ex:child used in the inverse direction." ;
		sh:path [ sh:inversePath ex:child ] ;
		sh:name "parent" ;
		sh:maxCount 2 ;
	] .


Comment décoder cet exemple ? « Sur les ex:Person, il faut que la propriété ex:ssn (numéro de sécu) soit présente au maximum une fois, et qu’elle soit une chaine de caractère qui réponde à une certaine expression régulière. Il faut également que la propriété ex:child soit une référence à des IRI/URI qui soit une autre ex:Person. Il faut également qu’une ex:Person soit référencée au maximum 2 fois par ex:child ». Et ainsi de suite.

La version publique de SHACL est publiée à https://www.w3.org/TR/shacl/ mais je vous recommande d’ici juin de vous référer au document en cours d’écriture à https://w3c.github.io/data-shapes/shacl/.

Validateurs SHACL

De la même façon que des ontologies OWL peuvent être interprétées par des raisonneurs OWL, les contraintes SHACL seront vérifiées par des vérificateurs SHACL. L’implémentation la plus avancée est sans doute celle de TopQuadrant (les éditeurs principaux de la recommendations SHACL) qui a publié en open-source l’implémentation de SHACL utilisé dans TopBraid.

Europeana a également annoncé un ensemble de règles SHACL pour vérifier les données EDM (Europeana Data Model), ainsi qu’une implémentation d’un validateur SHACL.

Il faut également noter que, si SHACL permet de valider des données a posteriori, la recommandation inclut également ce qu’il faut pour utiliser les règles pour créer des formulaires de saisie (ordre des propriétés, libellés/regroupement des zones, etc.), ce qui permettra donc de spécifier la structure de formulaires de données sémantiques.

Une technologie importante pour la publication et l’intégration de données

SHACL va modifier profondément la façon dont on mène les projets web de données. Plutôt que de définir une ontologie forcément un peu bancale ou limitée (car pas utilisée pour son objectif principal qui est de donner un point de vue sur des données), on commencera par définir un jeu de contraintes SHACL que l’on souhaite vérifier sur les données. Tous les projets d’échange et d’intégration de données vont pouvoir tirer parti de cette nouvelle brique.

Cela assainira également le discours autour du web de données : il ne sera plus obligatoire de passer par une étape où l’on doit expliquer ce qu’est une ontologie ! Bref, je vois SHACL comme un composant important dans l’ensemble d’outils dont nous disposons pour partager et lier des données de qualité sur le web. Et vous, pensez-vous que SHACL vous sera utile ?

Illustration de l’article : By Deutsche Fotothek, Public Domain, https://commons.wikimedia.org/w/index.php?curid=6483869

Cet article SHACL (RDF Shapes Constraint Language) : enfin la possibilité de valider des données RDF est apparu en premier sur Sparna Blog.

]]>
http://blog.sparna.fr/2017/01/02/shacl-rdf-shapes-constraint-language-enfin-la-possibilite-de-valider-des-donnees-rdf/feed/ 10
Article ArABESque – Le web de données, de « l’information en réseau » http://blog.sparna.fr/2016/08/01/article-arabesque-web-de-donnees-information-reseau/ http://blog.sparna.fr/2016/08/01/article-arabesque-web-de-donnees-information-reseau/#comments Mon, 01 Aug 2016 12:29:56 +0000 http://blog.sparna.fr/?p=1050 La revue « ArABESque » publie dans son numéro 83 un dossier intitulé « Créer du lien, faire sens  – Un nouveau souffle sur les données« . Je signe l’article d’introduction de ce dossier, qui brosse le paysage, revient sur l’historique et donne quelques perspectives de l’écosystème du web de données. ArABESque est la revue de l’ABES (Agence Bibliographique…

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

]]>
La revue « ArABESque » publie dans son numéro 83 un dossier intitulé « Créer du lien, faire sens  – Un nouveau souffle sur les données« . Je signe l’article d’introduction de ce dossier, qui brosse le paysage, revient sur l’historique et donne quelques perspectives de l’écosystème du web de données. ArABESque est la revue de l’ABES (Agence Bibliographique de l’Enseignement Supérieur), qui gère notamment le SUDOC, catalogue collectif des bibliothèques de l’enseignement supérieur, 10 millions de notices, en RDF, évidemment !

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 Lee1, 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’Insee2) ;

  • 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, FOAF3.

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« 4. 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éricain5). Quant aux ontologies, on se référera au projet LOV – Linked Open Vocabularies6.

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.org7, 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-Lex8.

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.

1 Voir l’article de référence sur le sujet : Tim Berners-Lee, James Hendler and Ora Lassila, « The Semantic Web », Scientific American, Mai 2001.

2 URI de Paris définie par l’Insee : http://id.insee.fr/geo/commune/75056 , voir http://rdf.insee.fr/geo

4 Linked Open Data : http://linkeddata.org/

5 En triplet RDF : <http://data.bnf.fr/ark:/12148/cb12049451f> skos:closeMatch <http://id.loc.gov/authorities/subjects/sh90000103>

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

]]>
http://blog.sparna.fr/2016/08/01/article-arabesque-web-de-donnees-information-reseau/feed/ 0
Article dans la revue I2D – ELI : une « mise en lien » des textes juridiques européens http://blog.sparna.fr/2016/08/01/eli-article-i2d-adbs/ http://blog.sparna.fr/2016/08/01/eli-article-i2d-adbs/#comments Mon, 01 Aug 2016 10:46:38 +0000 http://blog.sparna.fr/?p=1043 A l’occasion du dossier « Web de données et création de valeurs : le champ des possibles » dans la revue de l’ADBS I2D de juin 2016, je cosigne avec Jean Delahousse cet article sur le projet ELI, dont il avait déjà été question ici. ELI : une « mise en lien » des textes juridiques européens La législation…

Cet article Article dans la revue I2D – ELI : une « mise en lien » des textes juridiques européens est apparu en premier sur Sparna Blog.

]]>
A l’occasion du dossier « Web de données et création de valeurs : le champ des possibles » dans la revue de l’ADBS I2D de juin 2016, je cosigne avec Jean Delahousse cet article sur le projet ELI, dont il avait déjà été question ici.

ELI : une « mise en lien » des textes juridiques européens

La législation est, pour les pays d’Europe et pour l’Union européenne, un élément structurant de la vie des citoyens, de l’activité économique et du débat politique. La législation nationale et régionale s’impose aux citoyens qui peuvent également invoquer le droit européen auprès des juridictions nationales ou lors d’un appel auprès de la Cour de justice européenne. Les entreprises qui opèrent en Europe doivent appréhender la réglementation d’une trentaine de pays, mais également les évolutions des législations techniques, commerciales et financières que préparent la Commission et le Parlement européens et qui seront transposées en droit national.

Face à l’importance du droit mais aussi à la complexité d’accès à des corpus juridiques linguistiquement hétérogènes et géographiquement dispersés, les Journaux officiels (JO) européens ont voulu innover en imaginant un système original d’identification, de signalement et de mise en relation des corpus juridiques à travers l’Europe : le standard ELI (European Legislation Identifier)1. Cette initiative a reçu le soutien officiel de l’Union européenne en 20122. Les premiers résultats sont exploitables depuis 2015 grâce aux précurseurs qu’ont été les JO anglais, français, italiens, luxembourgeois et européens. D’autres états membres le déploient actuellement, sur la base du volontariat.

ELI utilise les technologies du web de données

ELI permet d’identifier, décrire et relier les textes de lois sur le web de données dont il utilise les technologies pour arriver à son objectif :

  • les identifiants des textes de loi sont des URIs ;
  • ceux-ci sont décrits suivant un modèle de données formalisé, comme une ontologie ;
  • ces descriptions sont ajoutées aux portails web de diffusion des lois à l’aide de marquage sémantique RDFa ;
  • les liens se font à l’échelle du Web, d’un URI vers un autre.

Dans une logique d’accès simplifié à la loi, ELI impose que les identifiants soient signifiants, « lisibles » par l’humain et associés à une logique de navigation dans le corpus législatif. Par exemple, la directive européenne 2003/98/CE sur l’ouverture des données publiques3 (qui a ouvert la voie à l’Open data) est identifiée par le ELI : http://data.europa.eu/eli/dir/2003/98/oj ; sa transposition dans la loi française (décret n° 2005-1755 du 30 décembre 2005) peut être identifiée par https://www.legifrance.gouv.fr/eli/decret/2005/12/30/2005-1755/jo/texte, et une métadonnée indiquera que le décret français « eli:transposes » la directive européenne.

Modèle FRBR et graphe de données législatif

Le modèle FRBR prescrit le découpage des notices documentaires en niveaux conceptuels : Oeuvre, Expression, Manifestation, Item4, auxquels FRBRoo5 ajoute – entre autres – le niveau d’« Oeuvre complexe »6. Ces modèles proposent également de nombreuses propriétés pour décrire chacun des niveaux, créant des modèles précis mais complexes.

ELI se veut à la fois générique (applicable aussi bien pour la common law que pour le droit codifié), simple à implémenter, mais rigoureux dans la description des lois ; il a donc défini un modèle compatible avec l’idée-clé du découpage des notices en 4 niveaux conceptuels, mais dépouillé du reste de la complexité de FRBRoo. Une quarantaine de champs sont spécifiés, en particulier les liens entre lois : « modifie », « cite », « baséSur », etc.

Les niveaux FRBR – plus l’« Oeuvre complexe » FRBRoo – sont donc appliqués à la description des lois :

  • Oeuvre complexe : texte juridique identifié par un certain nombre de composants invariants dans le temps (Directive 2003/98/CE) ;
  • Oeuvre : version spécifique du texte au cours du temps ; typiquement sa version d’origine (publiée au JO) ou l’une de ses versions consolidées ;
  • Expression : variante linguistique d’une version particulière, dans des systèmes législatifs multilingues (comme la loi européenne) ;
  • Manifestation : format de fichier spécifique d’une variante linguistique d’une version particulière ; typiquement, le PDF authentifié pour la version opposable du JO ou la version HTML.

En accord avec la logique des données (et modèles) liées, chaque État membre peut spécialiser les descriptions ELI avec ses propres champs, conservant ainsi une sémantique précise tout en restant compatible avec le cadre général.

Un cadre flexible pour une adoption progressive

L’approche d’ELI n’est pas contraignante : chaque État peut spécifier sa propre structure d’URI à partir des composantes définies par ELI, choisir de publier seulement certaines métadonnées ou implémenter ELI uniquement sur une partie de son corpus.

Pour les JO qui ont une pratique de catalogage des textes légaux, ELI dans sa forme la plus simple a peu d’impact sur les chaînes de production documentaires ; il peut être implémenté en ajoutant uniquement des métadonnées en RDFa dans les pages web finales, sans impact ni sur le reste du flux ni sur l’expérience utilisateur, la principale tâche du JO étant de publier ses métadonnées à l’aide des champs de l’ontologie. ELI constitue donc pour les JO une première marche vers le web de données ; une fois la dynamique enclenchée, les flux documentaires pourront être enrichis avec plus de métadonnées ou des descriptions plus précises.

Le graphe des données ELI, en cours de constitution, est un objet original dans le paysage du web des données ; par sa publication décentralisée, son adaptabilité et la légèreté des moyens mis en œuvre, il se différencie d’un projet tel qu’Europeana7 qui vise à constituer un catalogue centralisé d’œuvres d’art. En effet, dans ELI, chaque acteur garde la charge de publier son propre graphe de notices documentaires en s’appuyant sur sa propre infrastructure. Il se différencie également du projet multilingue Wikipedia/Dbpedia8 car les données sont publiées dès l’origine pour le web des données à partir d’une activité de catalogage professionnelle. Il s’en différencie encore par la variété des acteurs dont les statuts sont très divers : administrations nationales, régionales ou européennes mais aussi éditeurs privés assurant une mission de service public.

ELI concilie adaptabilité et interopérabilité en s’appuyant sur un mix de référentiels partagés publiés par l’Union européenne (langues, lieux, statuts des documents, formats de fichiers) comme sur des référentiels propres à la législation nationale (acteurs juridiques, types de texte).

Cette coordination originale d’acteurs divers qui publient avec leurs moyens propres des graphes complémentaires dans le web des données exige une implémentation simple et économique, mobilisant un minimum de compétences spécialisées. Simple, car la mise en œuvre est réalisée par les JO qui n’ont pas au départ de compétences dans les technologies du web sémantique. Économique, car le coût de mise en œuvre ne devrait pas dépasser quelques dizaines de milliers d’euros pour les JO aux budgets les plus réduits. Les solutions pour répondre à ce challenge sont le partage de retours d’expérience entre JO, des formations pour chaque pays et un standard stable pour éviter des coûts de maintenance élevés.

Premiers exemples de réutilisation

L’objectif d’ELI est de permettre de construire au meilleur coût des applications qui s’appuient sur le graphe de données des législations européennes. Grâce au travail de vulgarisation réalisé par le mouvement associatif, comme Open Law en France, des premiers projets de réutilisation apparaissent. On peut citer, par exemple, le tableau de bord d’Open Law9 qui, avec environ 12 jours de travail, a permis de récupérer et exploiter les données ELI françaises, italiennes et européennes, ou le travail en cours par un éditeur de logiciels, KBCrawl, pour exploiter les données ELI dans une application de veille juridique sectorielle. Leur point commun est d’avoir abouti à la création de services à haute valeur ajoutée pour des investissements de quelques jours à quelques dizaines de jours, avec la possibilité d’étendre le service sur les données d’autres pays utilisant le standard ELI.

En combinant ontologie générique, adressage à plusieurs niveaux, liens entre lois nationales et loi européenne, le tout dans un contexte multilingue, ELI crée donc un véritable graphe de données législatives à l’échelle européenne. Le web coopératif et décentralisé entre ici en résonance avec le projet européen, lui aussi coopératif et décentralisé.

1 ELI register : http://eur-lex.europa.eu/eli-register/about.html, voir également http://eli.fr

2 Conclusions du Conseil préconisant l’introduction d’un identifiant européen de la législation (ELI) : http://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:52012XG1026%2801%29

3 Directive « PSI » : http://eur-lex.europa.eu/legal-content/FR/NOT/?uri=CELEX:32003L0098

4 FRBR : www.bnf.fr/fr/professionnels/modelisation_ontologies/a.modele_FRBR.html

5 FRBR object-oriented

6 FRBRoo Complex Work : www.ifla.org/files/assets/cataloguing/frbr/frbroo_v2.2.pdf

7 Europeana : www.europeana.eu/portal

8 DBPedia francophone : http://fr.dbpedia.org

9 Tableau de bord d’OpenLaw : http://ld.openlaw.fr

Cet article Article dans la revue I2D – ELI : une « mise en lien » des textes juridiques européens est apparu en premier sur Sparna Blog.

]]>
http://blog.sparna.fr/2016/08/01/eli-article-i2d-adbs/feed/ 0
ELI – European Legislation Identifier : une voie pour le web de données législatif européen http://blog.sparna.fr/2015/05/31/eli-european-legislation-identifier-web-de-donnees-legislatif-europeen/ http://blog.sparna.fr/2015/05/31/eli-european-legislation-identifier-web-de-donnees-legislatif-europeen/#comments Sun, 31 May 2015 14:14:40 +0000 http://blog.sparna.fr/?p=970 Identifier, décrire et relier les lois sur le web ELI (European Legislation Identifier) est une initiative européenne pour identifier, décrire et relier les lois de l’Union européenne et de ses états membres. D’abord issue du forum des journaux officiels des pays membres de l’UE, l’initiative est en cours de déploiement en Europe, pour les pays…

Cet article ELI – European Legislation Identifier : une voie pour le web de données législatif européen est apparu en premier sur Sparna Blog.

]]>
Identifier, décrire et relier les lois sur le web

ELI (European Legislation Identifier) est une initiative européenne pour identifier, décrire et relier les lois de l’Union européenne et de ses états membres. D’abord issue du forum des journaux officiels des pays membres de l’UE, l’initiative est en cours de déploiement en Europe, pour les pays qui le souhaitent. ELI utilise l’infrastructure du web et les technologies du web sémantique pour arriver à cet objectif :

  • les identifiants de législation sont des URIs;
  • les législations sont décrites suivant un modèle de données formalisé comme une ontologie;
  • ces descriptions viennent structurer les pages web existantes en utilisant du balisage RDFa;
  • les liens se font à l’échelle du web, d’un URI vers un autre.

Si les lois sont accessibles depuis longtemps aux citoyens via les portails de diffusion nationaux (Legifrance en France), ELI va permettre une véritable mise en réseau des données des lois européennes, dans des formats ouverts et permettant leur réutilisation.

Pour donner un exemple très concret :

Les avantages d’ELI ?

Pour les états membres c’est un mécanisme d’identifiant homogène pour les lois sur le web; Il ne serait pas surprenant d’ailleurs que ce mécanisme d’identifiant URI devienne partie intégrante des systèmes de production législatifs dès les premières étapes de production d’un texte. C’est également un élément facilitateur d’accès à la loi pour le citoyen (et le réutilisateur de données). C’est un moyen de faciliter l’échange de données entre systèmes informatiques à l’intérieur de l’état ou entre états.

Pour les institutions européennes ELI est un moyen d’automatiser l’échange de données entre institutions ou depuis les états membres vers les institutions européennes. Eur-Lex (portail de la loi européenne) contient par exemple les références des « mesures nationales d’exécution », c’est-à-dire les lois nationales qui transposent les directives européennes. On retrouve par exemple le décret français cité plus haut dans Eur-Lex. Ces informations sont transmises manuellement par les états membres, mais leur récupération pourrait être automatisée grâce à ELI.

Pour les utilisateurs finaux ce seront des URIs homogènes, « user-friendly » (voir plus bas) – si tant est qu’une URI puisse être user-friendly !! – donc une pose de lien plus facile vers la loi, dans des tweets ou des billets de blog. Ce seront aussi des applications et des services à valeur ajoutée qui seront développés à partir des données mises à disposition en ELI; on imagine bien par exemple des tables de droit comparé entre plusieurs pays générées de façon automatique, montrant comment une directive a été implémentée dans différents pays.

URI user-friendly et modèle FRBR

Les URI ELI restent lisibles pour l’humain. Il ne s’agit pas d’URIs opaques composées de lettres ou chiffres incompréhensibles, mais d’URIs :

  • qui utilisent des éléments relativement homogènes dans les différents états membres; ELI n’impose pas de schema d’URI unique, mais des éléments à assembler, comme le type de document ou l’année de publication; les pays décident de leur schéma d’URI en fonction des habitudes de citation de leurs citoyens; les schémas d’URI de chaque pays seront documentés dans un registre au niveau européen;
  • qui sont « hackable » c’est-à-dire qu’en étant un peu débrouillard on peut raccourcir l’URI pour obtenir une liste de résultats (http://data.europa.eu/eli/dir/2003 doit ramener les directives européennes de 2003), ou bien on peut facilement accéder à un autre texte en modificant l’URI une fois qu’on a « compris le truc »;

L’ontologie ELI, quant à elle, en bonne européenne, est le résultat de compromis, et cherche à accommoder tout autant la « common law » anglo-saxonne que notre droit civil. C’est un modèle d’échange, de publication de métadonnées, et donc relativement simple; il reprend les informations essentielles de description des textes législatifs, en mettant l’accent sur les liens entre les textes, et notamment les liens d’implémentation et de transposition des directives européennes en lois nationales.

L’ontologie se base sur deux modèles :

  • FRBR pour le squelette LegalResource > LegalExpression > Format;
  • et Dublin Core (dcterms) à partir duquel certaines propriétés ont été étendues, quand ça avait du sens;

Coopération européenne et web de données

<attention_lyrisme>

L’Europe est une belle chose, on l’oublie un peu. Son fonctionnement technocratique est certainement critiquable, mais l’idée est belle; c’est celle de la coopération entre des peuples différents. Et quand, lors d’une réunion de projet ELI, des luxembourgeois, anglais et français, des employés des institutions européennes allemands et hongrois, écoutent un irlandais aider la délégation maltaise à spécifier ses URIs ELIs, l’idée de la coopération européenne s’impose. Parce que tous ces gens auraient pu choisir de rester dans leur pays plutôt que d’essayer de travailler ensemble.

Le web est une belle chose, on l’oublie un peu. Son fonctionnement de plus en plus mercantile et centralisé est certainement critiquable, mais l’idée est belle; c’est celle de la liberté pour chacun de s’exprimer, c’est celle de la mise en commun et de la mise en lien des connaissances de chacun. Et quand des projets collaboratifs internationaux comme ELI choisissent tout naturellement ce socle technologique pour se concrétiser, cette idée de la mise en commun et de la mise en lien des connaissances de chacun s’impose. Parce que toutes ces données auraient pu rester cloisonnées plutôt que d’essayer de se lier ensemble.

Phil Archer au dernier semweb.pro 2014 a dit (la phrase m’était restée) « don’t let anyone tell you that the semantic web doesn’t work. Because it does.« . Des projets comme ELI sont non seulement la preuve que ça marche (mais donner encore une preuve serait entrer dans le jeu de ceux qui objectent que cela ne marche pas), mais aussi la preuve que les valeurs qui sous-tendent les technologies du web (de données) sont en adéquation avec les besoins des projets actuels.

Et le mouvement ne peut que s’amplifier : car le web est tout à la fois ce qui permet à des projets collaboratifs comme ELI de se concrétiser, mais aussi ce qui déclenche de nouvelles collaborations, puisque c’est par l’ouverture (des opinions, des documents, des données) que naît la confiance, la compréhension, et la coopération.

</attention_lyrisme>

Références ELI

(illustration de l’article : Justitia (Maarten van Heemskerck, 1556) disponible sur wikimedia commons ici)

Cet article ELI – European Legislation Identifier : une voie pour le web de données législatif européen est apparu en premier sur Sparna Blog.

]]>
http://blog.sparna.fr/2015/05/31/eli-european-legislation-identifier-web-de-donnees-legislatif-europeen/feed/ 2
Gephi pour visualiser des graphes RDF http://blog.sparna.fr/2015/04/22/gephi-visualiser-des-graphes-rdf/ http://blog.sparna.fr/2015/04/22/gephi-visualiser-des-graphes-rdf/#comments Wed, 22 Apr 2015 15:24:22 +0000 http://blog.sparna.fr/?p=940 RDF est un modèle de données en triplets (sujet; prédicat; objet) qui, pris ensemble, forment un graphe. Et les triplestores RDF sont les bases de données qui permettent de stocker, manipuler et requêter ces graphes. RDF un modèle de données « bas niveau », l’équivalent du modèle relationnel pour les bases de données relationnelles « classiques »; c’est pourquoi…

Cet article Gephi pour visualiser des graphes RDF est apparu en premier sur Sparna Blog.

]]>
RDF est un modèle de données en triplets (sujet; prédicat; objet) qui, pris ensemble, forment un graphe. Et les triplestores RDF sont les bases de données qui permettent de stocker, manipuler et requêter ces graphes. RDF un modèle de données « bas niveau », l’équivalent du modèle relationnel pour les bases de données relationnelles « classiques »; c’est pourquoi j’ai toujours pensé que pour un utilisateur final, visualiser le contenu d’un graphe RDF « brut » a autant de sens que de visualiser le contenu des tables d’une base relationnelle – à savoir pas beaucoup; il y a souvent plein de colonnes ou de tables dans les données qui n’ont aucun sens pour l’utilisateur final, qui attend une représentation de ses informations « actionnable » et compréhensible pour son besoin.

On trouve pourtant tout un tas de projets ou de logiciels pour visualiser des graphes RDF natifs : RDF gravity, Visual RDF, Welkin, ou d’autres qui sont listés ici, , ou bien encore (voir également WebVOWL pour la visualisation d’ontologies OWL, donc sur un sujet un peu différent).

Une cartographie des acteurs du numérique pour #ToursTech

Et pourtant je suis tombé sur une problématique où la visualisation des données natives d’un graphe RDF avait vraiment du sens : représenter la cartographie des acteurs d’un territoire ou d’une communauté. En l’occurrence la cartographie des acteurs du numérique en Touraine, dans le cadre de la candidature de Tours au label #FrenchTech (#ToursTech). On peut donner plusieurs représentations possibles de cet ensemble d’acteurs :

  • en graphe type réseau social (l’approche que j’explore ici, donc);
  • en zones type TreeMap pour montrer les grandes masses (par exemple la répartition des entreprises par code APE en utilisant d3.js);
  • en courbes temporelles pour montrer des évolutions d’indicateurs;
  • en cartes géographiques pour visualiser les zones et les lieux dans l’agglomération
  • en arbres pour mettre en évidences des catégories d’acteurs;
  • etc.

Dans notre cas les triplets RDF correspondent exactement aux liens entre les acteurs, et sont des relations du type « est adhérent de (une association professionnelle) », « est fournisseur de », « a un partenariat avec », etc. Le besoin d’avoir une représentation du réseau social des acteurs devient donc le même que celui de représenter le graphe RDF natif.

Le résultat et quelques explications

Voici le résultat de cette cartographie (cliquez pour agrandir) (et jouer à « où est Charlie ? » en cherchant Sparna dans l’image !) :

carto-sans-noms-personnes-small

(je précise que cette représentation est partielle, exploratoire, et ne se veut pas représentative de la réalité du territoire)

Qu’est-ce qu’on y voit ?

  • des noeuds : organisations, personnes, lieux ou projets;
  • des liens : relations de type réseau social entre ces noeuds (« travaille dans ce lieu », « participe à ce projet », etc.); ces liens ne sont pas distingués par un label ou une couleur dans la cartographie, mais ils sont bien typés dans les données;
  • La taille d’un noeud est fonction de son nombre de liens;
  • La couleur d’un noeud est fonction de sa « centralité » dans le graphe, c’est-à-dire de sa proximité avec un maximum d’autres noeuds dans le graphe (enfin c’est ce que j’en ai compris !);
  • Les noms des personnes ne sont pas affichés pour des raisons de confidentialité;

On met ainsi rapidement en évidence :

  • les acteurs majeurs de la communauté, soit en terme de « taille » soit en terme de positionnement dans le réseau (PaloAltours, la cantine numérique bêta de Tours, CoopAxis le PTCE qui marie numérique et innovation sociale, Centre & TIC association professionnelle au service du numérique, etc.) ;
  • les liens qui les unissent (« comment puis-je rentrer en contact avec telle personne ou telle organisation ? »);
  • les communautés, qui sont plus apparentes si on partitionne le graphe et qu’on colorie les communautés :

carto-sans-noms-personnes-partition-small

D’autres projets ont utilisé une approche et des outils similaires pour cartographier les acteurs d’une communauté : l’écosystème du cluster CapDigital en île-de-france, ou bien cette cartographie des acteurs de l’Intelligence Economique en PACA.

Le dispositif : Wiki sémantique + triplestore + Gephi / sigma.js

Le dispositif que nous avons exploré pour réaliser cette cartographie est en 3 parties :

Le beurre : un wiki sémantique

Semantic Media Wiki (que j’avais exploré précédemment ici) nous donne une solution de centralisation des connaissances :

  1. collaborative, avec toute la machinerie wiki (versionning des pages, pages de discussion, etc.)
  2. structurée,  puisque la solution Semantic Media Wiki et ses divers plugins permet d’avoir des fiches à plusieurs champs, avec choix multiples, autocompletion, dates, etc.
  3. flexible, puisque le modèle de données et les formulaires de saisie peuvent évoluer au fil des besoins, et l’outil est facile à prendre en main pour des utilisateurs non-experts, jugez plutôt  les formulaires de saisie avec assistance à la saisie :screenshot-formulaire-semantic-media-wiki
  4. ouverte pour partager les données avec d’autres territoires (important sur l’aspect « mise en réseau des archipels territoriaux »);

C’est cet outil qui est utilisé pour renseigner les fiches des acteurs du territoire et leurs liens. Ces liens sont de types :

  • liens formels ou contractuels : fournisseur de, client de, travaille pour ;
  • liens de collaboration : a un partenariat avec, adhère à telle association, participe ou porte tel projet;
  • liens géographiques : se situe dans tel lieu;
  • liens capitalistiques : a du capital dans;

L’argent du beurre : une diffusion des données en RDF

Semantic Media Wiki c’est bien, mais nativement on ne peut pas réutiliser les données en dehors du wiki. On le synchronise donc (via sa fonction d’export RDF) avec un triplestore RDF Sesame, qui rend les données accessibles sur le web (via SPARQL), permettant ainsi à d’autres applications de tirer parti des données.

On a donc une solution de capitalisation des connaissances PAR le territoire (wiki sémantique collaboratif) et POUR le territoire (diffusion des données pour leur réutilisation).

Le sourire du crémier : Gephi pour exploiter les données

Le sourire du crémier : Gephi (et d’autres applications) qui peuvent réexploiter les données saisies dans le wiki. En particulier Gephi dispose d’un plugin d’intégration à partir de SPARQL (« Gephi Semantic Web Import Plugin » – Attention à la date de rédaction de ce billet le lien vers la page de documentation de ce plugin est cassé). Il devient donc possible de générer un visuel de notre réseau social à partir des données ainsi exposées.

On peut même automatiser la génération du visuel (ce qu’on a fait ici) avec un bout de Java grâce à l’API Gephi (Gephi Toolkit).

Mon retour d’expérience sur Gephi est très positif : facile à prendre en main, intégration SPARQL aisée et sans bug, on peut générer assez facilement des rendus intéressants. Inconvénient : cela reste des images statiques, ca ne bouge pas et ce n’est pas cliquable. Pour avoir quelque chose de plus interactif il faut se tourner vers SigmaJS. C’est ce que l’agence de communication Mwebius a expérimenté :

screenshot-sigmajs

Notez les options de sélection de ce que l’on veut afficher sur la gauche. Tout cela est branché en direct sur les données exportées du wiki.

Vous voulez utiliser les données ? pas encore…

La question de la licence des données récoltées pour ce travail de cartographie n’étant pas encore tranchée (ouvertes ou pas ? dans quel périmètre), je ne peux malheureusement pas mettre ici les liens ni vers le wiki sémantique, ni vers le service SPARQL de diffusion des données – je le fais dès que l’initiative #ToursTech a statué là-dessus, mais ce serait en tout cas un bel exemple de système d’intelligence économique territorial collaboratif diffusant ses données en open data. Rien que ça ! En attendant si vous voulez en savoir plus laissez un message ici et suivez la candidature #ToursTech !

Cet article Gephi pour visualiser des graphes RDF est apparu en premier sur Sparna Blog.

]]>
http://blog.sparna.fr/2015/04/22/gephi-visualiser-des-graphes-rdf/feed/ 1
Sparna – logo, identité visuelle http://blog.sparna.fr/2015/03/19/sparna-logo-identite-visuelle/ http://blog.sparna.fr/2015/03/19/sparna-logo-identite-visuelle/#comments Thu, 19 Mar 2015 11:28:26 +0000 http://blog.sparna.fr/?p=915 Cela aura pris un peu de temps, mais Sparna a enfin une identité visuelle web et papier cohérente : un magnifique site sparna.fr, cet incroyable blog que vous lisez, des cartes de visites groovy, des modèles de documents sexy, surtout un logo fantastique ! 😉 Le logo mixe et mets en parallèle deux univers :…

Cet article Sparna – logo, identité visuelle est apparu en premier sur Sparna Blog.

]]>
Cela aura pris un peu de temps, mais Sparna a enfin une identité visuelle web et papier cohérente : un magnifique site sparna.fr, cet incroyable blog que vous lisez, des cartes de visites groovy, des modèles de documents sexy, surtout un logo fantastique ! 😉

Logo SPARNA rouge aligné

Le logo mixe et mets en parallèle deux univers : l’univers du papier, des bibliothèques, de la tradition de transmission des connaissances d’une part (avec son crayonné graphique et le lettrage du « A » qui se rapproche des lettrines), et l’univers des données, du numérique (avec sa police stricte et droite). Le côté service, confiance et relation personnelle dans le travail est présent avec la silhouette du personnage qui se découpe dans le « A » (vous l’aviez vu, bien sûr ?). Tout cela est à mettre en lien avec la réflexion sur les valeurs dans le travail que j’avais pu avoir au moment de me lancer comme indépendant. La création d’un logo est à nouveau l’occasion de s’interroger sur le message que l’on veut transmettre.

Si vous avez besoin de récupérer le logo, vous le trouverez ici dans ces différentes versions :

Sur le site web, on retrouve le côté « réseau de données liées » avec la home page et la liste des références Sparna qui sont un peu déstructurées, et le fond blanc qui fait sobre et simple.

Le logo a été réalisé par le meilleur designer du monde : 10-6deSign (où l’on reconnaît son sens inné de la double lecture et de la rigueur ! merci Fabrice) et le site web par l’agence de communication tourangelle BTG communication. Je suis content du résultat !

Cet article Sparna – logo, identité visuelle est apparu en premier sur Sparna Blog.

]]>
http://blog.sparna.fr/2015/03/19/sparna-logo-identite-visuelle/feed/ 0