To inaugurate my first article on Sparna’s blog, let’s share a little feedback of mine today about Sparna’s well-known SKOSPlay! whose 10 years’ birthday is to celebrate this year !

10 yo, quite a historic tool ! but more than ever actual in a context where the semantic technologies get front of the scene anew due to growing interest shown by the digital humanities movement to data interoperability projects via the standardized knowledge structuration (Wikipedia-Wikidata projects e.g., as semantic wiki devices), and also due to the last progress of artificial intelligence, now able to processing large amount of data and soon fully leveraging the potential of ontologies and knowledge graphs.

From asking for a taxonomy to querying RDF files with an API…

This said, in a more practical way, semantic web standards are not always easy to manipulate as a professional – if non-initiate to SPARQL and nor confirmed data scientist, and even when you have got to deal with a simple structured list of terms !

Either your data is already SKOS-standardized (great !), there sometimes come to have a gap between normalization step and visualization step that requires a bit more technical IT skills. Either – most of time – the common muggle-born is to start with a plain Excel spreadsheet, create a list, add some hierarchy, maybe other scope notes or definitions and… end far puzzled wondering how to get a 5-star data vocabulary ⭐ !

A SKOSPlay!-within-a-SKOSPlay!

Wink to @belett, anything possible now with SKOSPlay!

Aiming at visualizing (and printing !) SKOS thesauri, taxonomies and vocabularies at the very beginning, SKOSPlay! is a full online free and open source tool leveraging semantic technologies (RDF, SPARQL, inference, Linked Data) to generate downloadable HTML or PDF documents. More and more new features have been added since then : alignments display, OWL and SKOS-XL files processing, autocomplete fields and permuted indexes generating …

Hello @veronikaheim, maybe SKOSPlay! could match your need ?

… among other nice and useful developments.

But as an Excel aficionada, the one that I prefer is the Excel-to-RDF converter tool.

One sheet. One import. One result. Easy-peasy, happy terminologist :))

(And you can even keep your custom colors templates and formats !!! 🦄 )

Come on & let’s SKOSPlay!

Let’s figure out you want to display or construct a small vocabulary you could quickly visualize in a standardized SKOS-structured way :

Now to fit in the SKOS model your data has to follow a particular template you can fullfill by downloading on SKOSPlay! website.

First you have to define the header of the template : the global scheme of your vocabulary, its URI, title and description :

Adding the terms of your list (with the URIs)… Here with the “@en” language indication on top of the column as I am to create an English-French multilingual vocabulary :

Recreating the arborescent structure through the Excel template (don’t mind my color palette, I always like colouring my Excel sheets to better visualize the info at a glance !).

The hierarchical broader-narrower structure is to be recreated by adding a “skos:narrower” column (or skos:broader, as you want, with only 1 broader value per line) where you will list the different specific values front of the more generic one (separated by comas). Here I used a PREFIX too in order to shorten my http:// URIs, SKOSPlay! can process them anyway !

Then adding a few notes and other information (multilingual values, skos:notation, any other default properties known in the converter (see the documentation) or different custom elements of yours by adding other PREFIXes :

Your Excel template is ready to go ! quite an easy configuration in my demo here, but SKOSPlay! can also deal with skos:Collections, SKOS-XL and other advanced RDF structures : blank nodes, RDF lists, named graphs. And now possible to generate OWL and SHACL files with the converter too !

Now it’s time to turn your (finally-not-so-dirty-) data into a SKOS-charming file. Take your favorite magic wand SKOSPlay! Excel-to-RDF converter tool and load your Excel file in it (adding some optional parameters if needed).

Well done, it’s a wonderful RDF-ized vocabulary file (here in a Turtle format but you have also RDF/XML, N-Triples, N-Quads, N3 and TriG available) :

Wingardium Visualiza !

We’re almost done. Go back to the website, tab “Play!”, load your last RDF-serialized file and go to the next step to chose the kind of display you want to get, endly press (SKOS)Play! and … abracadataaaaaaa !

Many different options to visualize your arborescent data. Tree, static and dynamic, but also more « professional » and printable sorts of displays like alphabetical, hierarchical or permuted views :

And KWIC (as for « KeyWord In Context ») :

Even possible to load an online Google spreadsheet (mine is shared here), just by adapting a little its URL for the converter’s need. Interesting feature in a collaborative purpose when you are team-building a vocabulary !

The whole pack fully documented and findable on Sparna’s website & Git. Some recent users even produced a short video tutorial to show what they managed to do with different SKOSPlay! visualization tools.

Already knew about SKOSPlay! ? go see his little brother, SHACLPlay! and feel free to give us some feedback in the comments 

Happy Birthday SKOSPlay! & Long live Semantic Web !

A bit more Vouvray with your nougat de Tours ?

Cet article 2013-2023 : ‘Tis SKOSPlay!’s Birthday ! est apparu en premier sur Sparna Blog.

J’y interviens 2 fois cette année. D’abord avec le Réseau Canopé pour présenter la mise en ligne et les spécificités des vocabulaires du ScolomFr pour l’indexation des ressources pédagogiques. J’avais décrit le navigateur et la timeline permettant de remonter dans les versions du vocabulaire dans un précédent billet. Le ScolomFr s’est enrichi dans sa dernière version de particularités excitantes que nous présentons :

• Profil d’application en SHACL;
• Ontologie spécifique pour décrire les modifications dans un vocabulaires contrôlés et les liens entre certains vocabulaires du ScolomFr;
• Tableau de « diff » des modifications apportées dans la version du vocabulaire;

Ensuite avec les Archives Nationales pour présenter le travail effectué depuis un an sur Rico-converter, un outil de conversion d’instruments de recherche en EAD et de notices d’autorités en EAC vers un graphe sémantique structuré suivant l’ontologie Records In Context (RiC-O). RiC est le nouveau modèle conceptuel mis au point par et pour la communauté des archivistes, que j’avais décrit dans un précédent billet. Le convertisseur a permis de convertir 15000 notices EAC et 28000 fichiers EAC des Archives Nationales en RDF (environ 155 millions de triplets). Une préfiguration d’un futur data.archives-nationales.culture.gouv.fr ?

Les 2 après-midi de rencontre auront lieu les jeudi 19/11 et 26/11, dans ce monde virtuel gather.town :

Merci à Logilab de continuer d’organiser cet évènement.

Au plaisir de vous voir nombreux à semweb.pro 2020 !

Crédit illustration : sur le blog de Logilab, pour semweb.pro 2019

Cet article semweb.pro 2020 : vidéos en ligne et 2 après-midi de rencontres (virtuelles) les jeudi 19/11 et 26/11 est apparu en premier sur Sparna Blog.

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

Facilite les phases de prototypage

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

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

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

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

Une infinité de points de vue

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

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

Flexibilité maximale

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

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

Le raisonnement, ou les manipulations automatiques des données

Réconciliation

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

Classification

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

Inférence

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

Consistance

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

Conclusion…

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

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

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

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

L’environnement distribué, ADN du web

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

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

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

Interconnection des données

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

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

Enrichissement des données

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

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

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

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

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

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

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

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

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

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

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

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

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

Update

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

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