From validation of the data in the knowledge graph to further projects of data integration and dissemination, many different usages of SHACL specifications were explored…

… and more exploratory usages of SHACL are foreseen !

“

A knowledge-graph powered open data portal

The European Parliament Open Data Portal (EPODP) went live in January 2023. Its particularity is that it is not a mere aggregation of documents or dump files from business applications in custom formats; but rather a collection of datasets each extracted from a central semantic knowledge graph, itself aggregating data migrated from approximately twenty business applications. The result is a semantically interoperable open data portal : the semantic of its data model is clearly defined and documented, and reuses widely deployed existing ontologies. It already provides its data to different consumers (most notably the europarl website and the EU law tracker) in a context of cross-institutions interoperability. The data captures the activity of the parliament : as co-legislator together with the Council of the EU, the European Parliament (EP) holds plenary sittings, in which reports originating from committees, as well as motion for resolutions, are amended and voted; after the vote, the final adopted texts are published.

The focus on semantic interoperability of EPODP maximizes the potential of reuse and linkage of its datasets, and maximizes the quality of the offered data. It comes however at a cost when building the portal : deep analysis and understanding of the existing data and documents structure is required to capture the business semantic. SHACL is the way to formally encode this business semantic – but how is it deployed in practice ? how is it maintained ? what are the different types of SHACL specifications used ?

SHACL at the center of a model-driven approach

SHACL in the EPODP is at the basis of multiple model-driven usages depicted in the following diagram:

There was two key drivers for introducing the use of SHACL in the EPODP project : validation of the data in the knowledge graph, and generation of public documentations of the models. The same SHACL specification that captures the business semantic is directly actionable to be published as a documentation and to validate the data. The produced documentation is a set of public files, such as the ELI-EP application profile documentation and others accessible from the EPODP developer’s corner. The SHACL Play documentation generator is used to produce the documentation pages. Data validation happens at earlier stages, after data transformation steps.

Two additional usages of SHACL specifications were explored : one was to generate SPARQL queries to extract the content of datasets from the larger knowledge graph. The SHACL specification of a dataset content is interpreted to generate SPARQL CONSTRUCT queries, executed against the entire knowledge graph, to return a subset of data corresponding to the specification. The query generation was implemented in SHACL Play, however the EPODP chose to continue using manually crafted SPARQL queries to generate the datasets. The other usage was to complement the SHACL specifications with the mapping rules used to feed the corresponding properties or classes in the graph. This has the advantage that the mapping rules are documented and maintained alongside the specification and not in a separate document. This work is ongoing.

More exploratory usages of SHACL are foreseen : generating a query user interface based on the SHACL specification, using the Sparnatural query builder, and also input forms to facilitate the creation of DCAT datasets descriptions. Additionally, automated generation of the JSON-LD context and the JSON schema of the API are foreseen.

Not « 1 SHACL to rule them all », but application profiles, dataset definitions, and migration specifications

The definition of the EPODP knowledge graph is not captured in a single SHACL specification, but rather in three different application profiles, each being a selection of classes and properties of one sub-domain : ELI-EP covers the description of documents and activities, ORG-EP covers the definitions of EP organisations (such as committees, political groups, etc.) and members of the parliament, and SKOS-EP covers how controlled vocabularies are structured. In addition, DCAT-EP is the specification for how dataset records are described in the EPODP catalog – but this is not part of the knowledge graph per se.

Together, ELI-EP, ORG-EP and SKOS-EP specify the structure of the entire knowledge graph from which the datasets are extracted. In addition, the structure of each dataset family available in the EPODP (such as adopted texts, plenary documents, parliamentary questions, etc.) is also described in SHACL, referred to as « DSD » for « Dataset Definition ». While the application profiles describe every possible properties on generic shapes, the DSDs will specify only the subset of properties used in a dataset, with possibly different cardinalities or range. For example, ELI-EP specifies that « a Work may have the property eli:adopts«  (with no minimum cardinality (eli:adopts is defined as « Indicates that the work represents the adopted work of one or several related works »). The DSD for adopted texts datasets specifies the shape of « Adopted texts » as a subset of the Works, and indicates that the minimum cardinality of eli:adopts is 1 for this particular subset. Besides, some properties, such as eli:amends are not available for adopted texts, thus not declared in the DSD.

In addition, specifications of the conversion of some data sources are also specified in independent SHACL files. The articulations of these 3 kinds of SHACL files and the reused ontologies is depicted in the following diagram:

There is currently no reuse or reference of shapes across the different specifications. Each is independent. A nice improvement would be to study how SHACL DSDs could be derived from the application profile SHACL, without redeclaring the identical constraints.

Editing SHACL in spreadsheets

In total 16 SHACL specifications are currently published in the EPODP, and around 80 are used to validate data migrated from each individual sources. The first step in the specification of each model is the design in a diagram such as the ones visible in the public documentations of the models. The EPODP team is then using spreadsheets to encode the specifications, adapted from the one provided in the SHACL Play suite. The spreadsheet is converted to SHACL using the xls2rdf converter. Spreadsheets provide a simple editing solution, with an easy learning curve, made even easier with a few formulas to compute cell values automatically. It even provides ways for editing advanced patterns (such as the ability to directly turtle lists for sh:or, or blank nodes for property paths), but of course still limits the expressivity. The following screenshot shows how property shapes look like in the spreadsheet:

Results and future perspectives

The EPODP use-case shows how SHACL can be applied in a systematic way in a data integration and dissemination project : at the data transformation step, at the knowledge graph level, and at the data dissemination. Public documentation, data validation, data extraction are tasks that can be be automated based on a SHACL specification. While the context is one of a large public institution, the same approach can be applied in industrial contexts. The SHACL specifications are a cornerstone of such projects, enabling semantic interoperability at large and a mutual understanding between business experts, data analysts, developers, and data consumers.

”

Veronika’s book will be divided into three parts :

1. Back to Basics
Introduction to logic and RDF, brief skimming of the topics. Also covering various world assumptions.

2. Getting to know the stuff
Introduction to SHACL, including core, sh-sparql, advanced features.

3. Working with the stuff
SHACL Stories. Use cases, user stories and implementations.

Image : © European Union, [2024] – EP

Cet article European Parliament Open Data Portal : a SHACL-powered knowledge graph est apparu en premier sur Sparna Blog.

• RobotDonnées, le module développé par Logilab pour data.bnf.fr qui permet le regroupement semi-automatique des éditions en œuvres;
  • où l’on apprend que data.bnf.fr ne comporte « que » 300 000 œuvres, alors que la cible théorique serait à plusieurs millions; par exemple on voit bien en regardant les oeuvres dont Michel Houellebecq est auteur dans data.bnf.fr que « La carte et le territoire » n’apparaît pas comme œuvre, mais que toutes les éditions de cet ouvrage sont bien listées quand on regarde tous les documents dont Houellebecq est l’auteur.
  • où l’on apprend également que ce regroupement en œuvre est progressivement réintroduit dans le catalogue général de la BNF;
• BiblioStratus, pour aligner un catalogue externe avec celui de la BNF sur la base de plusieurs heuristiques (ISBN, EAN ou bien titre+auteur+date ou titre+auteur); où l’on apprend que la transition n’est pas qu’écologique mais qu’il existe également une transition bibliographique;
• l’ANR ELKER pour « Enhancing Link Keys: Extraction and Reasoning », porté notamment par l’INRIA Grenoble pour la détection automatique des attributs permettant de trouver des correspondances dans 2 jeux de données RDF arbitraires; très impressionnant;
• CultuurLink, à tester pour tous ceux qui s’intéressent aux processus d’alignement de vocabulaires, bien que l’outil soit restreint aux vocabulaires patrimoniaux des Pays-Bas;
• et encore plein d’autres choses (cf les liens sur la page de l’atelier);

OnAGUI pour aligner 2 thesaurus SKOS

Je voulais profiter de cette thématique des alignements pour parler d’un autre outil d’alignement de thesaurus SKOS : OnAGUI pour « Ontology Alignment Graphical Interface« . OnAGUI est le genre d’outil qui ne paie pas de mine au premier abord mais qui est à mon avis l’outil dont la prise en main est la plus immédiate pour qui veut aligner 2 thesaurus en SKOS, tout en permettant d’outiller le processus depuis l’alignement linguistique automatique jusqu’à la validation manuelle de l’alignement produit.

L’interface d’OnAGUI pour aligner 2 thesaurus

Quelques considérations générales : d’abord l’acronyme parle d’alignement d’ « ontologies », mais pas de panique, ça marche pour des thesaurus en SKOS; surtout pour des thesaurus en SKOS, d’ailleurs. Ensuite, c’est open-source; ça s’installe facilement sur n’importe quel poste équipé de Java, c’est une application « de bureau », qui ne nécessite pas d’infrastructure client-serveur, etc. l’interface est en français (et anglais) puisque le développement à été fait par Laurent Mazuel à l’époque où il travaillait avec Jean Charlet au LIMICS (INSERM). L’outil est maintenu, notamment par votre serviteur.

Vous pouvez consulter la documentation d’OnAGUI où vous trouverez des informations plus détaillées sur le logiciel.

Alignement avec RAMEAU

Maintenant, le cas d’usage : il m’ait arrivé de rencontrer des personnes qui avaient besoin d’aligner un vocabulaire vers le langage d’indexation RAMEAU de la BNF. Comment faire ?

1. Je ne détaille pas ici la structure de RAMEAU et son mécanisme de « vedettes-matières pré-coordonnées » que je ne connais pas bien d’ailleurs, mais je pars (naïvement) de ce qui existe : le fichier des Thèmes Rameau que l’on télécharge depuis le site des dumps de données de la BNF. Il s’agit du fichier intitulé « [RDF/XML] Thèmes RAMEAU« .
2. A ce stade il faut l’avouer : la BNF a encore des efforts à faire sur diffusion des données de RAMEAU; les données telles qu’on les télécharge sont inutilisables telles qu’elles, et nécessitent : 1/ un nettoyage et 2/ une fusion en un seul fichier; je ne m’étends pas sur cette étape que j’ai réalisé à l’aide de scripts RDF4J dont je me sers régulièrement, mais on se ramène au final à un seul fichier RDF contenant tout RAMEAU en SKOS; si vous voulez tester OnAGUI sur un autre vocabulaire ne nécessitant pas cette étape de « magie noire », essayez avec le thesaurus de l’UNESCO ou Eurovoc;
3. Il faut ensuite avoir son propre thesaurus en SKOS; on peut utiliser pour cela l’outil de conversion Excel vers SKOS disponible dans SKOS Play;
4. Il faut télécharger OnAGUI en prenant soin de prendre une version postérieure à 0.3.2, version pour laquelle des améliorations ont été apportées pour fonctionner avec RAMEAU;
5. Muni donc de votre vocabulaire en SKOS d’un côté, de RAMEAU (nettoyé) de l’autre, et d’OnAGUI entre les deux, vous pouvez ensuite :
   1. Charger votre thesaurus dans OnaGUI (Menu « Fichier > Charger vocabulaire 1 > Charger en SKOS »);
   2. Charger RAMEAU dans OnaGUI (Menu « Fichier > Charger vocabulaire 2 > Charger en SKOS »), qui va vaillamment charger 160000+ concepts;
   3. Lancer un alignement linguistique (Menu « Alignement > I-Sub distance ») en prenant soin de :
      1. sélectionner la langue « fr » dans les 2 thesaurus;
      2. abaisser légèrement le seuil de tolérance de l’algorithme, en le mettant à 0.85 par exemple; ne le mettez pas trop bas sinon vous aurez trop de correspondances qui ne veulent rien dire, ni trop haut sinon vous allez rater des choses;
   4. Aller prendre un petit café, ou deux, ou trois… en fonction de la taille du vocabulaire que vous avez besoin d’aligner; patientez entre quelques secondes et une nuit entière;
   5. Analyser le tableau de résultat fourni et soit :
      1. supprimer des lignes de correspondances fausses; regardez le score de chaque correspondance : plus le score tend vers 1, meilleure est la correspondance linguisitique, plus le score diminue, plus les libellés sont éloignés;
      2. ajouter des nouvelles correspondances qui auraient été ratées;
   6. Puis exporter l’alignement (Menu « Fichier > Exporter l’alignemenr ») soit dans un format RDF EDOAL, le plus expressif, soit avec les propriétés d’alignement SKOS, soit en CSV pour une analyse dans un tableur;

Vocabulaire Rameau chargé dans OnaGUI

OnAGUI est un outil perfectible sur bien des aspects mais qui permet de valider « pour de vrai » des alignements sur des vrais projets, sans besoin d’infrastructure compliquée ou d’outil commercial. J’ai pu le mettre en œuvre à 2 reprises : pour l’alignement du thesaurus de l’IRSTEA vers le GEMET et Agrovoc, et plus récemment pour un essai d’alignement du vocabulaire thématique d’indexation de la loi Luxembourgeoise avec le thesaurus Eurovoc utilisé au niveau européen, sur la base de l’analyse des transpositions des directives européennes dans la loi nationale. Il peut également prendre en charger des cas d’usage d’alignement partiel, en alignant seulement les concepts créés ou modifiés après une certaine date, de façon à ne pas à avoir à refaire l’intégralité de l’alignement à chaque nouvelle version du thesaurus.

Si vous avez des questions, des cas d’usage ou des retours d’expérience sur OnAGUI, n’hésitez pas à soumettre des tickets dans le site du projet.

Cet article Aligner son thesaurus avec RAMEAU en utilisant OnAGUI est apparu en premier sur Sparna Blog.

Je vous propose un petit tour d’horizon des outils open-source pour la gestion et la diffusion de vocabulaires contrôlés.

Outils de gestion

Vocbench3

Vocbench3 est l’outil de gestion de référentiels SKOS que je recommande. Il est développé par l’Université de Rome Tor-Vergata, et financé pour 1 ou 2 année encore par le programme de financement européen ISA, ce qui lui donne une bonne visibilité à moyen terme. La communauté d’utilisateurs est large avec beaucoup d’organismes internationaux (FAO/Agrovoc, INRA, Office des Publications de l’UE/Eurovoc, etc.). Le support est bon, l’équipe de développement répond rapidement aux questions.

Coté technique, il est directement basé sur des données RDF, ce qui facilite son intégration dans des environnements techniques basés sur le web de données. Le modèle de données est extensible et permet de gérer des propriétés « customisées » sur les concepts. Vocbench permet également d’éditer des ontologies OWL, sans arriver à concurrencer Protégé.

Ginco

Ginco est l’outil de gestion de vocabulaires développé par le Ministère de la Culture pour la maintenance de ses référentiels. Il a été dès le départ spécifié pour être compatible avec la norme ISO-25964 sur la modélisation des thesaurus, et avec SKOS. Donc en particulier la gestion des facettes, des tableaux de concepts, etc. Il a un pendant « Ginco diffusion » qui motorise le site de diffusion des vocabulaires du MCC.

OpenTheso

OpenTheso est l’outil de gestion SKOS made in CNRS. La communauté d’utilisateurs est dans le monde de la recherche française/francophone (notamment le réseau FRANTIQ).
On pourra consulter la présentation d’OpenTheso à semweb.pro 2017 par Miled Rousset.

Outils de Publication et Visualisation de vocabulaires

Skosmos

Vous voulez valoriser vos vocabulaires/thesaurus/taxonomies ? Vous avez besoin des les rendre visibles, navigables, interrogeables par les utilisateurs ? Vous voulez recevoir du feedback, faire participer une communauté ? Skosmos est l’outil de choix.
Développé par la Bibliothèque Nationale de Finlande pour son portail « finto.fi » (parlez-vous finnois ?), Skosmos propose une interface de rendu très propre avec toutes les fonctions de navigation dans des vocabulaires contrôlés : listes alphabétiques, arborescence hiérarchique, recherche plain-texte avec autocompletion, gestion des groupes/collections SKOS, affichage propre des alignements avec d’autres vocabulaires. Il s’adapte assez facilement pour le mettre aux couleurs de l’institution. Il prend en charge la négociation de contenu pour l’accès aux données brutes en RDF. L’interface inclut également un formulaire permettant d’envoyer du feedback à l’équipe de maintenance du thesaurus.

L’équipe de développement répond très vite aux questions, le code PHP est de qualité, l’outil est vivant et de nouvelles versions sont disponibles régulièrement.

Skosmos est à mon sens LE meilleur outil pour la diffusion de vocabulaires en SKOS.

Skos Play

SKOS Play est l’outil que je développe depuis 2013 pour faire de la publication et de la visualisation de référentiels SKOS. Il permet de générer des documents PDF des vocabulaires, des sorties HTML dynamiques (arbres dépliables),des listings alphabétiques, des tableaux de traduction ou d’alignement, ou des data visualisations. A titre d’exemple on pourra consulter les rendus du code Rome de Pôle Emploi en SKOS.

SKOS Play est intégré dans la plateforme de publication des vocabulaires du MCC, et dans celle de l’UNESCO, pour la génération des PDFs. Le service en ligne est quant à lui utilisé plus de 500 fois par mois.

Conversion Excel, contrôle qualité, alignement

Skos Play convert

SKOS Play inclut un service de génération de données RDF/SKOS depuis des tableaux Excel (voir précédent billet).

Soyons honnêtes : rien ne remplace Excel ! pour de la saisie ou de l’analyse de données en masse, avoir une vue globale sur ces données, faire des reporting, gérer facilement plusieurs vocabulaires… Pas de courbe d’apprentissage, pas d’outil à installer, grande efficacité de saisie. Et si on utilise un environnement en ligne type Google Sheets, on gagne l’aspect collaboratif.
Cette passerelle Excel-RDF-SKOS s’est révélée très importante pour faire les reprises ou les créations initiales de vocabulaires, avant de les basculer dans des outils de gestion comme VocBench.

Skos Testing Tool : contrôle qualité

Le SKOS Testing Tool est une interface web permettant de valider la conformité de fichiers SKOS (voir précédent billet). L’outil s’appuie sur qSKOS, qui fonctionne lui en ligne de commande. 27 vérifications peuvent être effectuées sur les données, comme :

• vérification de l’absence de cycle dans la hiérarchie des concepts
• vérification que tous les concepts ont bien un prefLabel
• vérification que tous les concepts sont traduits (dans le cas de thesaurus multilingues)
• …

Combiné avec les sorties alphabétiques/hiérarchiques de SKOS Play, ces vérifications permettent de s’assurer de la qualité des données soit en amont lors des comités de validation du vocabulaire, soit en aval avant la diffusion des données en ligne dans Skosmos.

OnaGUI : Alignement semi-automatique

OnaGUI (Ontology Alignment Graphical User Interface) a été développé à l’origine à l’INSERM dans l’équipe de Jean Charlet pour faire de l’alignement d’ontologies médicales, et il a depuis été adapté pour pouvoir aligner des données SKOS.

C’est l’outil le plus accessible et le plus simple d’utilisation pour aligner 2 vocabulaires : on charge un thesaurus à gauche, un thesaurus à droite, et on lance un algorithme d’alignement qui va proposer des correspondances sur la base des proximités des libellés des concepts.

On utilise régulièrement OnaGUI pour illustrer les alignements de thesaurus dans les formations web de données à l’ADBS.

Si on veut utiliser des algorithmes d’alignement plus poussés, on se tournera vers l’API d’alignement de l’INRIA, mais qui demande du développement technique pour être intégrée dans un outil.

Quels outils manquent ?

Quels outils manquent dans l’écosystème des vocabulaires dans le web de données ?

• Probablement des outils faciles à mettre en œuvre pour assister à la création de vocabulaires à partir d’analyse de corpus (détection d’entités, agrégation des mots en concepts, etc.); en connaissez-vous ? IBM Watson ne ferait pas quelque chose comme ça ?
• Des interfaces d’alignement puissantes faciliteraient la mise en réseau des référentiels (des choses comme cultuurlink, mais généralisées);
• Une gestion des versions successives des vocabulaires, avec calcul de deltas, génération automatique de ce qui a changé entre 2 versions, etc;
• Des plugins dans les CMS courants (WordPress, Drupal, etc…) permettant d’importer directement des vocabulaires SKOS, et de les mettre à jour; ça doit bien exister, non ? également des ponts faciles et direct vers SolR et ElasticSearch;
• Mon rêve : un outil d’édition des vocabulaires en mode collaboratif et ouvert poussé, en mode SaaS, sans différence entre l’environnement d’édition et de publication, permettant de faire collaborer une communauté plus large que quelques éditeurs experts; ça viendra un jour !

Et vous, quels outils vous manquent ?

(Illustration de l’article : « Atelier Heilmann Ducommun pour la construction de machines-outils » Gallica http://gallica.bnf.fr/ark:/12148/btv1b10201510v)

Cet article Vocabulaires dans le web de données : quels outils open-source ? est apparu en premier sur Sparna Blog.

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 :

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.

Théoriquement, car, dans certains cas, on peut vouloir baser une application directement sur un triplestore RDF (ce qui a bien des avantages), ou bien avoir la possibilité de modifier, via un formulaire, des données RDF, en se basant sur une ontologie OWL particulière.

Et le hic c’est que les briques logicielles pour pouvoir éditer du RDF directement, via des formulaires générés à partir d’une ontologie par exemple, il n’y en a pas des tonnes. En fait j’en connais 2 que j’ai pu mettre en œuvre dans des projets différents : RDForms (anciennement RForms sur l’ancien site Google Code), sur lequel je reviendrai sûrement pus tard, et VIVO, ou plus exactement VITRO.

VIVO est un projet commun de plusieurs universités américaines et en particulier de l’Université de Cornell. L’objectif ? partager et mettre en lien les travaux de recherche des chercheurs de ces universités. Le moyen ? les technologies du web de données, RDF, OWL, SPARQL. L’outil ? VIVO, donc, qui permet de mettre en ligne les descriptions des publications scientifiques, des chercheurs, des conférences, et des labos de tout ce beau monde. L’originalité ? c’est que VIVO est basé sur un triplestore RDF et un moteur SolR pour la recherche, et que ses écrans de navigation et d’édition réagissent directement à une ontologie OWL, que l’on peut éditer directement dans le back-office de l’outil, en rajoutant également des annotations spécifiques pour contrôler certains comportements (comme la séparation des champs en onglets dans les écrans). Côté customisation également, des pages spécifiques peuvent être créées à partir de requêtes SPARQL et de templates Freemarker pour la présentation des résultats; le menu de navigation principal est également paramétrable. Et cerise sur le gâteau, la publication des données en RDF pour chaque fiche, via négociation de contenu, est incluse nativement.

Toutes ces fonctions sont offertes par la brique logicielle VITRO, qui est donc une brique logicielle « nue ». Et VIVO est un paramétrage assez conséquent de cette brique nue, avec une ontologie spécifique sur le domaine de la recherche scientifique, un menu de navigation spécifique (« People » / « Research » / « Organizations » / « Events »), et des écrans d’affichage particuliers, pour le profil d’un chercheur par exemple. En plus certaines visualisations sont incluses, comme une « Map of Science » (carte conceptuelle des thématiques de recherche d’un chercheur ou d’un labo), une navigation géographique par pays, ou un graphe des co-auteurs d’un chercheur. Le mieux est encore d’aller regarder tout cela sur les instances de VIVO actuellement en ligne, comme celle de l’University of Florida ou celle de Cornell (voir la liste de tous les déploiements de VIVO).

L’intérêt pour toutes ces institutions de publier les données brutes de leurs recherche dans un format RDF est de pouvoir 1/ faire des liens entre les données de chaque institution et 2/ mettre ensemble ces données dans un moteur de recherche centralisé, comme cela est démontré par le moteur beta.vivosearch.org qui aggrège et permet de rechercher sur les données de 8 institutions de recherche.

Avec VITRO, on a donc :

• un outil open-source, J2EE, prêt à déployer dans Tomcat;
• une plateforme de navigation / édition / recherche dans un triplestore RDF;
• avec un back-office permettant de modifier directement les données RDF, en se basant sur n’importe quelle ontologie de domaine;
• avec une gestion des comptes utilisateurs et des droits d’accès;
• avec des possibilités de customisation « relativement » aisées pour un développeur Java;

L’idéal serait de pouvoir mettre l’outil à l’épreuve !

Cet article VIVO / VITRO : solution d’édition et de publication RDF basée sur une ontologie est apparu en premier sur Sparna Blog.

Les wiki sont de bons moyens d’amener les membres d’une communauté à contribuer collectivement à une base de connaissance partagée. C’est sur ce principe que repose Wikipedia, mais la même idée peut s’appliquer à une entreprise, une association ou une administration.

Un wiki, c’est l’anarchie, et c’est son point fort. L’approche « contribuer d’abord, structurer (un peu) ensuite » assure que la barrière d’entrée pour un contributeur est très faible, qu’il n’est pas obligé de respecter une quelconque structure, et peut même s’approprier ou modifier les structures existantes (en modifiant l’organisation d’un article ou en modifiant des catégories dans le wiki). Cela assure la contribution du plus grand nombre de personnes possibles.

Un wiki, c’est l’anarchie, et c’est son point faible. C’est son point faible si l’exhaustivité ou la qualité des données sont un de ses objectifs, ou si l’on veut pouvoir réutiliser la connaissance contenue dans le wiki dans d’autres applications informatiques. Qualité, exhaustivité, structuration des données pour la machine peuvent difficilement être atteintes par le mode d’organisation classique du wiki [1. Un exemple sur wikipedia/dbpedia ? cette requête SPARQL sur DBPedia francophone ramène toutes les sociétés avec leur slogan. 1/ qualité : certains slogans contiennent des chiffres 2/ exhaustivité : le slogan n’est parfois pas renseigné 3/ structuration : cette requête est possible sur DBpedia qui a structuré les données, mais pas sur wikipedia.]

Les technologies du web sémantique sont un bon moyen pour structurer les informations et les partager sur le web. En miroir des wiki, on peut dire que cette structuration est à la fois leur point faible et leur point fort : point fort car c’est cette structuration des données qui les rend partageables et réutilisables par des machines (mais certains en doutent), point faible car arriver à ce niveau de structuration peut augmenter significativement la barrière d’entrée pour publier et partager des données, en particulier dans des projets de capitalisation de connaissances. Par ailleurs des solutions simples, paramétrables et gratuites de formulaires de saisie pour des données RDF ne courent pas les rues.

Vous me voyez venir. Les wikis sémantiques sont la solution de synthèse du meilleur des deux mondes : le wiki pour son côté « faible barrière d’entrée à la contribution » et la sémantique pour son côté « structuration et partage des données » [2. D’autres dans la sphère francophone l’avaient mentionné bien avant, ici et là.].

Semantic Media Wiki = Media Wiki + Structuration

Semantic Media Wiki (SMW) est une extension du logiciel de wiki Media Wiki, celui qui est utilisé par Wikipedia. Cette extension propose de pouvoir gérer des données structurées dans le wiki, et de publier de ces données dans les formats du web sémantique, dans une base RDF.

Je résume les fonctionnalités indiquées dans la page d’introduction de SMW :

• générer automatiquement des listes d’objets dans le wiki, plutôt que de les saisir à la main
• présenter les données visuellement dans des graphes, des cartes, des calendriers
• améliorer la structure du wiki en évitant les catégories ad-hoc du type « films des années 50″
• rechercher des informations de façon structurée (et plus uniquement plein-texte)
• mettre à disposition les données du wiki pour d’autres applications et intégrer les données d’autres applications dans le wiki via SPARQL

Voilà ce qu’il ressort de mes premières impression après avoir testé SMW :

1. L’installation de Media Wiki est facile (package « mediawiki » sur Debian), et de Semantic Media Wiki assez simple avec Semantic Bundle, un ensemble d’extensions regroupées dans un même paquet;
2. Le paramétrage est un peu alambiqué mais est bien documenté; il faut notamment suivre les pages qui expliquent comment importer un vocabulaire existant (type FOAF, DC, ORG ou autre), comment paramétrer les propriétés et les classes, et comment paramétrer un formulaire; une fois le paramétrage bien compris, on a à notre dispostion une vraie solution de création de formulaires de saisie pour des données RDF.
3. La synchronisation avec un triplestore Sesame fonctionne bien, et on arrive à récupérer les données structurées du wiki en RDF, et à les interroger en SPARQL.

Paramétrer Semantic Media Wiki pour saisir des données RDF

D’abord, synchroniser SMW avec Sesame

La doc est ici.

1. Installez Sesame en suivant cette procédure
2. Utilisez les valeurs suivantes dans le fichier de config (attention de bien mettre « /statements » à la fin de l’URL de service d’update)

$smwgDefaultStore = 'SMWSparqlStore';
# location of query service
$smwgSparqlQueryEndpoint = 'http://localhost:8080/openrdf-sesame/repositories/nomDuRepository';
# location of update service
$smwgSparqlUpdateEndpoint = 'http://localhost:8080/openrdf-sesame/repositories/nomDuRepository/statements';
# location of SPARQL over HTTP service, set it to ''; in case of problems
$smwgSparqlDataEndpoint = '';
# optional name of default graph
$smwgSparqlDefaultGraph = 'http://example.org/mydefaultgraphname';

Ensuite, si vous voulez, paramétrer SMW pour utiliser un vocabulaire externe

La doc est ici.

1. Assurez-vous d’être connecté en tant qu’admin du wiki
2. Créez une page MediaWiki:smw_import_PREFIXE_DU_VOCABULAIRE, par exemple MediaWiki:smw_import_org pour importer l’ontologie des organisations
3. Déclarez dans cette page les types et les propriétés du vocabulaire que vous voulez réutilisez, de cette façon :

   http://www.w3.org/ns/org#|[http://www.w3.org/TR/vocab-org/ The Organization Ontology]
    Role|Category
    Post|Category
    hasMember|Type:Page
    memberOf|Type:Page
    holds|Type:Page

4. Déclarez des propriétés et des catégories dans le wiki;
5. Déclarez la correspondances de ces propriétés et ces catégories avec les éléments du vocabulaire externe, en utilisant les marqueurs

[[imported from::org:Organization]] (pour une catégorie)
[[imported from::org:hasMember]] (pour une propriété)

Puis, paramétrer des formulaires de saisie

La doc est ici et là.

Je ne suis pas certain de comprendre tout l’enchainement du paramétrage, notamment les différences entre une « catégorie », un « template » ou « modèle », et le « formulaire ». Mais l’exemple de la doc fonctionne bien et peut ensuite être adaptée facilement avec la doc de paramétrage du formulaire sous les yeux. Pour paramétrer un formulaire qui a du sens pour des données structurées, on va surtout s’intéresser aux options suivantes :

• values from category= qui permet de restreindre la saisie d’un champ à une catégorie, c’est-à-dire en termes RDF à une classe – c’est l’équivalent d’un paramétrage de range RDFS;
• existing values only si vous ne voulez pas qu’un utilisateur qui remplisse le formulaire puisse choisir une valeur qui n’existe pas;

On va ensuite vouloir bloquer l’édition classique d’une page, pour ne permettre l’édition qu’à travers le formulaire. Pour cela il faut changer 2 paramètres dans SMW comme décrit dans la doc ici.

Finalement…

Tout projet d’outil de saisie va de pair avec une reprise de données, il faudrait étudier ce que les fonctions d’import/export de données de Media Wiki permettent, en tous cas l’utilisation de cette brique comme outil de contribution collaborative à une base de connaissances structurée est tentante !

Cet article Le wiki sémantique : solution de capitalisation des connaissances (structurées) est apparu en premier sur Sparna Blog.

Première Impression…

Première impression à l’installation : la procédure d’installation, certes documentée (seulement en anglais, dommage pour un projet qui sort du ministère de la culture français !),  n’est pas à la portée de tout le monde. Si les mots WAR, JDBC, LDAP ou les outils comme Tomcat ou Postgresql ne vous disent rien, vous allez avoir du mal à faire fonctionner l’application. Le MCC propose également une machine virtuelle préconfigurée avec l’application déjà installée permettant de la tester plus facilement.

Deuxième impression…

Deuxième impression, à l’usage cette fois-ci : hou là, mais il y a beaucoup de boutons ! et c’est tant mieux !

On dispose en effet dans GINCO de fonctionnalités de base aussi bien que des fonctionnalités avancées que l’on attend d’un TMS (Thesaurus Management System). C’est une vraie application de gestion. L’ergonomie à base d’onglets est déroutante, mais c’est le prix à payer pour avoir les objets qu’on manipule sous la main (un utilisateur d’Eclipse ne sera pas dépaysé).

Ce que je range dans les fonctionnalités de base et sur lesquelles je passe rapidement : la création de concepts, leurs organisation en arborescence générique-spécifique, la gestion des top concepts, des termes associés, du multilinguisme, des notes sur les concepts, l’affichage de l’arbre hiérarchique des concepts, la gestion des groupes de concepts.

Parmi les fonctionnalités avancées, je retiens :

• La séparation Concepts / Termes : les valeurs lexicales (termes) sont distinctes des entrées de vocabulaires à proprement parler (concepts), conformément à l’ISO-25964 sur laquelle GINCO s’appuie. Chaque concept est lié à un ou plusieurs termes, dont au moins un comme terme préférentiel. Cela permet de gérer un certain nombre d’informations au niveau de la valeur lexicale, comme la source ou le statut de validation;
• La possibilité d’ajouter des attributs personnalisés sur les concepts et sur les termes (dommage que ces attributs n’apparaissent pas dans les exports SKOS comme des propriétés RDF additionnelles, et dommage que ce ne soient que des champs texte et pas des liens vers d’autres concepts);
• La gestion des statuts de validation (candidat, validé, rejeté, déprécié, etc…) sur les concepts et les termes (d’ailleurs parfois un peu pénible car il faut penser à valider les termes et les concepts avant de pouvoir les utiliser);
• La gestion d’un historique de modification (piste d’audit) sur les vocabulaires que l’on peut exporter en CSV;
• La gestion des concepts complexes (regroupement de plusieurs autres concepts);
• La gestion des tableaux de concepts (Thesaurus Array de l’ISO 25964) permettant d’implémenter le mécanisme de facettes dans un thesaurus;
• La gestion du marquage des versions sur les vocabulaires (mais pas moyen a priori de revenir à une version précédente);

Troisième impression…

Troisième impression, une fois testée toutes les fonctions d’édition : les exports. 2 formats d’export sont proposés, l’un dans un format XML propriétaire permettant de capturer toute la richesse des données, l’autre en SKOS. Pas d’export dans le format XML de l’ISO 25964. Le SKOS exporté est tout à fait propre et rentre bien dans SKOS Play pour générer un PDF ou un index alphabétique du thesaurus. Ce qui fait de GINCO une solution open-source très pointue, d’un niveau professionnel, pour éditer/créer du SKOS (plusieurs crans au-dessus d’un ThManager ou d’un TemaTres par exemple). En rentrant dans le détail je n’ai malgré tout pas réussi à exporter de Collection SKOS.

Et pour finir…

Si je peux me permettre une liste de souhaits sur les évolutions futures, en vrac :

• La possibilité de chercher des concepts sur certains critères, notamment le statut (pouvoir avoir la liste de tous les concepts/termes en statut « Candidat » pour les valider). Par ailleurs je n’ai jamais rien réussi à trouver dans la boite de recherche en haut, j’ai peut-être raté quelque chose dans la configuration…
• La possibilité d’exporter dans le SKOS les attributs personnalisés et la possibilité de créer des attributs personnalisés qui soient des liens vers d’autres concepts ou d’autres termes;
• La possibilité de traduire l’interface dans d’autres langues, prioritairement en anglais;
• L’export des Groupes dans le SKOS en tant que skos:Collection (pas moyen de les avoir dans l’export);
• La possibilité de désactiver la gestion des statuts sur un vocabulaire pour ne pas avoir systématiquement à valider tout ce qu’on créé;
• La publication des concepts et des termes sur une plate-forme Linked Data;
• Eventuellement un export en SKOS-XL pour conserver la finesse de description des termes.

En tous cas GINCO est un outil à suivre pour la gestion de thesaurus SKOS. S’il vous intéresse pour un projet impliquant des vocabulaires contrôlés, je peux peut-être vous aider, n’hésitez pas à me contacter.

Cet article Ginco – Un éditeur SKOS Open Source est apparu en premier sur Sparna Blog.