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.

Le CIDOC-CRM est une ontologie formelle de haut-niveau permettant de structurer la description et l’histoire d’objets patrimoniaux (tableaux, sculptures, bâtiments, fouilles archéologiques, etc.) – ou d’autres informations similaires. L’objectif de ce modèle est de permettre l’intégration de données provenant de sources hétérogènes dans un graphe commun, cohérent, à l’échelle d’une institution ou au-delà, permettant ainsi l’accès et l’interprétation scientifique de ces informations.
Le périmètre du CRM, tel qu’il est défini, est « toutes les informations requises pour l’échange et l’intégration de données scientifiques à propos du passé humain et de toutes les preuves de ce passé arrivées jusqu’à nous ». Etant fait pour la description structurée de l’histoire d’objets patrimoniaux, le CRM utilise a plein une modélisation évènementielle; c’est-à-dire que fondamentalement, on ne dit pas « Le tableau Le Désespéré a pour date de création : [entre 1843 et 1845] », mais « Entre 1843 et 1845, Gustave Courbet a conduit une Activité de Création dont l’objet était le tableau Le désespéré« ; nuance. D’ailleurs, si j’en crois la notice Wikipedia, on ne dit pas non plus « ce tableau a pour titre Le Désespéré« ; on dit « Gustave Courbet a effectué une activité de nommage de ce tableau qu’il a baptisé Désespoir« , puis « Quelqu’un d’autre (qui ?) a (probablement) effectué une autre activité de nommage (quand ?) et a baptisé le même tableau Le Désespéré« .

Ce qui fait la force du CIDOC-CRM…

Le CIDOC-CRM est un modèle issu de plus de vingt ans de standardisation au sein du Comité International pour la Documentation (CIDOC) du Conseil International des Musées. Autant dire qu’il est le résultat d’une sédimentation de longues réflexions, ce qui rend ses fondations théoriques extrêmement solides. Le CRM a fait l’objet de 2 versions d’un standard ISO, ISO21127:2004 et ISO21127:2014. Il donne donc un cadre de modélisation rigoureux, mais avec une logique qu’il faut s’approprier.

Son paradigme de modélisation événementielle est très puissant et permet d’exprimer de nombreuses informations de façon très flexible. Les Evènements (ou plutôt, les Activités) sont les objets centraux que l’on décrit à l’aide du CIDOC-CRM : des Acteurs participent à des Evenements, qui se produisent dans un Lieu donné, une Temporalité donnée, et affectent des Objets donnés; tout cela pouvant être nommé avec des Appellations et typer avec des Types. Voilà, en une phrase, vous savez tout !

Le CIDOC-CRM est un modèle générique avec un fort niveau d’abstraction, et il ne descend volontairement pas dans le détail de spécifications de certains domaines métier particulier; c’est pourquoi il a fait l’objet d’extensions pour des domaines spécifiques. Dans le monde de l’infodoc on citera en particulier FRBRoo, l’intégration des principes du FRBR dans le cadre de la modélisation orientée objet du CIDOC-CRM, ou bien PRESSoo, lui-même une extension de FRBRoo pour la carctérisation des publication en série; dans d’autres domaines, on peut citer CRMarchaeo, une extension pour la description des données archéologiques, une communauté active autour du CIDOC-CRM.

…Et ce qui le rend compliqué

Ce n’est pas la taille de ce modèle qui le rend compliqué. Le CIDOC-CRM contient 84 classes et 154 propriétés (288 si on compte aussi les inverses) (chiffre approximatif). C’est peu, si l’on compare aux 602 classes et 877 propriétés de schema.org, et cela en fait une ontologie de taille moyenne.

Franchement, la chose qui le rend le plus compliqué, c’est peut-être sa documentation. Un sympathique fichier PDF de 115 pages (tiens, une nouvelle version sort aujourd’hui 26 mars 2019, un hasard), ça c’est sûr, c’est de la spécification formelle ! de bon vieux tableaux de propriétés à la schema.org pourraient être les bienvenus. MAIS MAIS mais, pour vous aider à vous plonger dans le CIDOC, voici une petite visualisation de l’arborescence des classes du modèle et de FRBRoo, construite à partir de SKOS-Play :

Par ailleurs, les diagrammes fournis pour les uses-cases, assez utiles, utilisent un formalisme auquel on n’est pas habitué dans la modélisation d’ontologies classiques. Pour d’autres documents d’introduction on pourra consulter avec profit la présentation du CRM et de FRBRoo sur le site de Doremus.

Un des autres aspects qui le rend compliqué c’est son fort niveau d’abstraction. Le CRM définit en effet des notions comme « Persistent Item », « Man-Made Thing », « Propositional Object »… pas évident de s’approprier la définition de ces notions. Ajoutez à cela que tous les identifiants du CRM commencent par un code : « E5_Event », « E70_Thing », « P94_has_created », et la lecture devient compliquée. Cette identification, rebutante au premier abord, n’est finalement pas pire qu’une autre, d’autant que les noms des propriétés et des classes sont associés à des définitions très précises, et on fini par connaître par coeur les plus importants (E55_Type, P14_carried_out_by…).

Par ailleurs le CRM est formellement défini dans le PDF de référence sus-mentionné, et il n’existe pas d’implémentations de référence du modèle en OWL. Les implémentations OWL fournies sur le site sont explictement non-officielles, et de toutes façons pas à jour. L’implémentation OWL la plus à jour (mais qui date tout de même d’il y a 2 ans, et de 3 versions du modèle) semble être celle d’Erlangen-CRM. Ce n’est donc pas forcément immédiat d’intégrer ce modèle dans une application basée sur les technologies du web de données.

Les projets qui utilisent le CIDOC-CRM

Mais qui qui qui (sont les snorkis) se sert du CIDOC-CRM ? L’implémentation la plus impressionnante est celle du British Museum, notamment au travers de l’interface ResearchSpace. Vous aimez les spaghettis ? voici la formalisation des données du catalogue du BM en CIDOC-CRM :

Vous voulez expérimenter avec les données CIDOC-CRM du BM ? je vous propose un tutorial d’interrogation des données du British Museum en SPARQL.

Aux Etats-Unis, le Yale Center for British Art publie également des données dans le CIDOC-CRM, mais semble-t-il assez light.

Le projet Doremus a créé une extension de FRBRoo / CIDOC-CRM pour la musique classique (composition, concerts), documentée ici.

Je travaille en ce moment sur une première version de la plateforme OpenArchaeo pour l’intégration de données de fouilles archéologiques, alignées sur le CIDOC-CRM à partir de base relationnelles (base ARSOL) et de fichiers XML (base AERBA).

Par ailleurs, dans le cadre de ELI (European Legislation Identifier), j’ai spécifié l’extension du modèle ELI pour la description des étapes et des documents lors de l’élaboration des projets de lois : ELI-DL (pour « draft legislation »); c’est un bon cas pour l’utilisation du CIDOC-CRM et de FRBRoo, puisque l’élaboration d’une loi est vue comme une séquence d’Activités utilisant ou produisant des documents, jusqu’à la publication finale de la loi au JO. C’est également un bon scenario d’utilisation du CIDOC-CRM comme cadre méthodologique, tout en utilisant uniquement des propriétés métier pour masquer les notions trop abstraites du CRM.

On peut également supposer que l’Institut National d’Histoire de l’Art (INHA) s’intéresse à ce genre de sujet. Le laboratoire LARHRA, laboratoire de recherche historique à Lyon, s’y intéresse également dans le cadre du projet SYMOGIH, pour lequel un autre modèle de données avait été initialement mis au point.

Les outils pour convertir

Le CIDOC-CRM étant un modèle fait pour l’intégration de données, le labo de FORTH, en Crète, qui abrite les cerveaux du CRM, a mis au point un language et un outil de mapping, X3ML, permettant de mapper et convertir des fichiers XML vers le modèle CIDOC-CRM. Pour convertir les données de bases relationnelles, on peut utiliser –Ontop–.

Alors, près à vous frotter au CIDOC-CRM ? avec toutes ces infos au moins, vous ne vous arracherez pas les cheveux !

Cet article Le CIDOC-CRM, ne nous arrachons plus les cheveux ! est apparu en premier sur Sparna Blog.

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

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

Retour aux racines du web

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

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

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

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

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

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

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

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

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

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

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

Quels enjeux et quelles conséquences ?

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

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

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

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

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

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

Prochaines promesses ?

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

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

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

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.

Réutiliser d’autres vocabulaires/modèles

Le web de données permet de partager et relier des données sur le web, et il permet également de partager et relier des modèles de données. Réutiliser un modèle déjà existant pour exprimer ses données permet 1/ de bénéficier de la réflexion et des bonnes pratiques de modélisation qui ont sédimenté dans ce modèle et 2/ de rendre les données ainsi exprimées plus facilement compréhensibles et compatibles avec d’autres applications.

Il est donc tout à fait possible pour modéliser son domaine de « faire son marché » parmi les modèles déjà publiés, par exemple en parcourant l’annuaire du LOV (Linked Open Vocabularies). Trois modèles notamment sont réutilisables presque à tous les coups : FOAF pour décrire des personnes, des organisations et des documents, DCTerms pour des métadonnées qui s’appliquent largement (« creator », « subject », « publisher », etc.), et SKOS (dont je re-mentionne au passage la traduction française) pour tout ce qui est liste contrôlée. Ces 3 vocabulaires sont d’ailleurs les plus réutilisés dans l’écosystème des modèles du web de données.

Outre ces 3 vocabulaires, nous avons également pour le modèle de description des fonds d’archives réutilisé OWL Time pour la représentation des dates et des intervalles temporels, wgs84_pos pour l’expression des latitudes/longitudes, et une seule propriété de PROV-O, le modèle de description de la provenance récemment recommandé par le W3C (voir plus bas).

Qualifier les propriétés

Si vous lisez ceci je ne vous apprendrai rien en disant que RDF est un modèle de triplets, sujet-prédicat-objet (dans le cas contraire, voir cette introduction). Donc en RDF on dit : « L’entreprise Lafarge (sujet) possède un siège social (prédicat) en France (objet) ». Le problème, dans les descriptions archivistiques, c’est que les entités sont décrites, par définition, au passé. Et que, dans le passé, il s’en est passé des choses, justement, et que les informations relatives à une entité ont évolué. Il faut donc être capable, pour toutes les informations composant la description d’une entité (nom, siège social, liens avec d’autres entités…), de les qualifier avec des dates de validité (et pourquoi pas également des lieux de validité). C’est-à-dire qu’au lieu de dire « Lafarge possède un siège social en France », on dit « Lafarge entretient une relation de siège social avec la France, relation qui était valable jusqu’en avril 2014″ (le cimentier Français ayant décidé de déplacer son siège social en Suisse après sa fusion avec Holcim).

On dit qu’on réifie la relation, on la transforme en ressource à part entière pour pouvoir exprimer des choses dessus. Autant dire que cela complexifie nettement le modèle. Mais c’est le prix à payer pour structurer ces informations complexes. Dans la syntaxe RDF Turtle, on passe, sans qualification de dates, de :

ex:Lafarge mdfa:pays ex:France .

à ceci, avec une date de validité exprimée à la fois comme date structurée (« 2014-04-11″) et à la fois comme chaine de caractères (« jusqu’en avril 2014″) :

ex:Lafarge mdfa:pays _:b .
_:b rdf:type mdfa:RelationLieu .
_:b mdfa:lieu ex:France .
_:b mdfa:dateValidite _:c .
_:c time:hasEnd _:d .
_:c rdfs:label "jusqu'en avril 2014" .
_:d time:inXSDDateTime "2014-04-11"^^xsd:date .

Ou, en notation Turtle abbréviée :

ex:Lafarge mdfa:pays [
  rdf:type mdfa:RelationLieu ;
  mdfa:lieu ex:France ;
  mdfa:dateValidite [
    time:hasEnd [ 
      time:inXSDDateTime "2014-04-11"^^xsd:date ;
    ] ;
  ] ;
  rdfs:label "jusqu'en avril 2014";
]

Prendre en compte les valeurs textuelles

J’espère qu’aucun archiviste qui lit ceci ne sera vexé si je dis que les descriptions d’archives actuelles ne sont pas très structurées. J’entends par là que, de ce que j’ai pu en voir, le contenu des descriptions est essentiellement textuel, et que peu de listes contrôlées ou de thesaurus sont utilisés pour structurer les valeurs que l’on renseigne dans les différents champs de la description. D’autre part, par la force des choses, certains éléments d’information sont manquants, ou imprécis, et il peut être difficile ou impossible de leur donner une valeur contrôlée. Quelques exemples :

• Pour indiquer la plage de date couverte par un fonds d’archives : « 1923-1932, 1936-1945 (manque 1933 à 1935) » (tiré de la norme ISAD(G));
• Pour indiquer la modalité d’entrée d’un fonds aux services d’archives : « Don de la Société ardoisière de l’Anjou (exploitation de Renazé) aux Archives départementales de la Mayenne, 1969″ (tiré de la norme ISAD(G));
• Pour indiquer une source complémentaire à un fonds (un autre fonds d’archives, géré dans un autre service, pouvant donner des informations supplémentaires sur les mêmes institutions/personnes/lieux) : « Archives départementales de la Savoie $ SA 243-244 : collèges d’Avignon (dont celui d’Annecy) »;

La création d’un modèle de description des fonds d’archives ayant pour objectif de structurer de telles descriptions se doit à la fois de les amener à plus de structuration pour améliorer l’accès et la gestion de l’information, et en même temps se doit de rester compatible avec les données telles qu’elles sont aujourd’hui; c’est-à-dire qu’il faut tout à la fois conserver la valeur de date « 1923-1932, 1936-1945 (manque 1933 à 1935) » sans perte, et en même temps permettre de structurer cette valeur si possible, pour donner la possibilité de rechercher les fonds en utilisant une plage de dates que l’on sélectionne dans des calendriers, ce qui n’est pas possible si les informations de dates sont laissées textuellement.

Cela a eu des conséquences à plusieurs endroits dans le modèle :

• Première conséquence, lorsqu’il est nécessaire d’indiquer une référence à un autre fonds d’archives, géré par un autre service d’archives, il faut pouvoir y faire référence même si ce fonds ne possède pas (encore) d’URI sur le web de données. RDF propose pour cela un mécanisme de noeuds blancs, ou noeuds anonymes, permettant d’associer des informations à une ressource dont on ne connait pas l’identifiant, ou qu’on ne souhaite pas identifier avec une URI. Cependant ce n’est pas vraiment ce que l’on veut faire ici. Lorsque l’on indique comme source complémentaire « Archives départementales de la Savoie $ SA 243-244 : collèges d’Avignon (dont celui d’Annecy) », il ne s’agit pas nécessairement du titre exact ou de la cote exacte d’un autre fonds, mais simplement d’une référence textuelle à quelque chose (peut-être à plusieurs choses d’ailleurs) dont le titre par exemple, est différent de ce que l’on indique en y faisant référence. Le modèle contient donc un mécanisme de référence textuelle pour faire référence à un fonds ou à une entité, qui permet :

1. de rester compatible avec les valeurs textuelles existantes dans les données actuelles;
2. de pouvoir faire référence à un fonds ou à une entité dont on ne connait pas précisément le titre, l’intitulé ou l’URI;
3. de pouvoir travailler dans un mode « on exprime la relation d’abord, et on essaie de résoudre la valeur contrôlée ensuite »;
4. de pouvoir travailler à un niveau de granularité et de finesse que l’on choisit (trouver/sélectionner la bonne valeur contrôlée prend du temps, en rester à une référence pas/peu contrôlée est plus simple);

Prenons l’exemple d’un fonds d’archives qui serait la copie d’un autre, et dont on veut indiquer l’original :

On peut indiquer cette référence sous forme de texte ainsi :

ex:fondsArchives_1 mdfa:aPourOriginal [
        mdfa:referenceTextuelle "collège Saint-Nicolas d'Annecy (1642-1785)." ;
]

Ou bien résoudre la référence, trouver la bonne URI contrôlée, et l’indiquer :

ex:fondsArchives_1 mdfa:aPourOriginal [
        mdfa:referenceTextuelle "collège Saint-Nicolas d'Annecy (1642-1785)." ;
        mdfa:ressource ex:uriUnAutreFondArchives ;
]

• Deuxième conséquence sur la description des dates : les dates mentionnées dans les descriptions de fonds sont soit : 1/ compliquées à décrire (« 1923-1932, 1936-1945 (manque 1933 à 1935) ») ou 2/ imprécises (« milieu du XIXème siècle »). On ne peut donc pas se contenter de 2 propriétés de dates (début et fin), il faut également pouvoir associer à l’information de date une description textuelle, et donner la possibilité, lorsque cela est possible/souhaitable, de structurer l’information. Pour cela nous avons réutilisé l’ontologie OWL Time qui permet de décrire des intervalles de dates, et d’associer à l’intervalle lui-même, ou bien à une date de début ou de fin d’intervalle, une description textuelle aussi bien qu’une information de date contrôlée;

Premier exemple, pour décrire les dates de contenu d’un fonds :

:fondsArchives_1 mdfa:datesContenu [
        rdfs:label "Du 1er janvier 1920 jusqu'aux environs de 1951"
        time:hasBeginning [ time:inXSDDateTime "1920-01-01"^^xsd:dateTime ] ;
        time:hasEnd [ time:inXSDDateTime "1951-01-01"^^xsd:dateTime ] ;
  ]

Deuxième exemple, pour décrire les dates de naissance et de décès d’une personne :

:personne_1 mdfa:datesExistence [
        rdfs:label "Date de naissance inconnue, mort le 23/10/1873"
        time:hasEnd [ time:inXSDDateTime "1873-10-23"^^xsd:dateTime ] ;
]

• Troisième conséquence sur des propriétés tantôt littérales, tantôt contrôlées; RDF et OWL permettent, on a un peu tendance à l’oublier, de déclarer des propriétés sans préciser si leur valeur sera une valeur contrôlée ou une valeur littérale. C’est ce que fait SKOS par exemple, pour les propriétés de notes descriptives : une note SKOS peut être une valeur littérale, ou une référence à une entité représentant la note (voir le SKOS PRIMER). De telles propriétés sont des Annotation Properties. C’est ce mécanisme que nous avons utilisé pour déclarer par exemple les propriétés correspondant au statut juridique, à la modalité d’entrée ou au support d’une ressource archivistique. Cela veut donc dire par exemple que, dans le cadre de cette ontologie, on laisse le choix de décrire les statuts juridiques comme une liste de valeurs contrôlées par un thesaurus en SKOS, ou bien comme une valeur textuelle libre.

On pourra donc dire tout aussi bien, pour indiquer la langue en utilisant une valeur contrôlée :

ex:notice_de_fonds_archives_1 dcterms:language <http://lexvo.org/id/iso639-3/lat> .

(on utilise dans cet exemple l’identifiant de langue latine issu de Lexvo, mais tout autre thesaurus contrôlé des langues peut faire l’affaire).

Ou bien ceci, en utilisant une description textuelle :

ex:notice_de_fonds_archives_1 dcterms:language "Latin. Ecriture insulaire 
(noter en particulier l'abréviation utilisée pour per)" .

Spécialiser les entités

La vision du monde RDF et OWL comporte un présupposé majeur : il existerait dans le monde réel des « choses » que l’on peut identifier de manière certaine, que l’on peut isoler des autres, et auxquelles on peut donner une URI. C’est une vision où le monde se « discretise » pour mieux se manipuler. Une manipulation du monde sans le langage. Mais il n’est pas du tout sûr que des « entités » que l’on puisse identifier et isoler existent ailleurs que dans notre tête (je crois que Chomsky et Gondry parlent de ça, si j’ai bien compris, mais il faudrait que je revoie le film). Et une vision du monde qui ne prend pas en compte l’aspect temporel. Alors que tout change. Qu’on ne se baigne jamais deux fois dans la même eau. Que seul le changement est permanent. etc.

Mais revenons à nos archives pour replacer ce problème en contexte : l’archiviste décrit toujours une entité (comme une société par exemple) en regardant dans le rétroviseur, au passé. On ne décrit donc pas « une société », on décrit « la vie de la société ». Est-on en droit de dire que l’on parle de la même société lors de son immatriculation et 30 ans plus tard quand elle est devenue une multinationale ? Est-ce que la société Apple au début des années 1980 et la société Apple en 2014 sont la même chose ? peut-être pas. Ou pas complètement. Tout ce qui se rapporte à « Apple au début des années 1980″ ne se rapporte pas forcément à « Apple en 2014″.

On ne peut pas se contenter d’assigner une seule URI unique pour identifier une entité dont on souhaite rendre compte de l’évolution. Il nous en faut plusieurs. Et autant le point de départ de ce paragraphe nous a emmené dans des questions philosophiques théoriques, autant la solution pragmatique à ces questions est simple. Le modèle d’ontologie proposé par le W3C pour décrire la « provenance » (on dirait plutôt l’ « origine » ou l’ « historique », en français), PROV-O, propose 2 notions intéressantes : la notion d’ « Entité » (qui peut être ce qu’on veut : « An entity is a physical, digital, conceptual, or other kind of thing with some fixed aspects; entities may be real or imaginary. ») , et la notion de « spécialisation d’entité ». Et c’est cette dernière notion qui va particulièrement nous intéresser : la « spécialisation » d’une entité « en possède toutes les caractéristiques et présente en plus certains aspects spécifiques de cette entité. En particulier la plage de validité (lifespan) de l’entité qui est spécialisée contient les plages de validité de ses spécialisations. Des exemples de spécialisation peuvent être une période de temps ou un certain contexte. »

On pourra donc par exemple avoir 1/ une URI pour désigner « Apple » en tant qu’entité générique 2/ une URI pour chaque grande période de la vie de société, comme par exemple les 6 grandes périodes décrites dans l’historique de la page Wikipedia :

ex:Apple_entre_1976_et_1980 prov:specializationOf ex:Apple_en_general .
ex:Apple_entre_1981_et_1989 prov:specializationOf ex:Apple_en_general .
ex:Apple_entre_1990_et_1999 prov:specializationOf ex:Apple_en_general .
etc...

La finesse du découpage de la vie de l’entité en périodes historiques est laissée à l’appréciation de chacun. Les ressources archivistiques peuvent alors se rapporter soit à l’entité « générique », soit à l’une de ses « spécialisations ». Chacune des spécialisations portera ses caractéristiques propres (nombre d’employés, siège social, organigramme, etc.). On gagne en finesse de description de l’entité, et en finesse d’indexation des ressources.

Cet article Penser, modéliser (pour le web de données) – 2/2 est apparu en premier sur Sparna Blog.

Pour quoi modélise-t-on ?

La question n’est pas aussi simple qu’il n’y parait, et il y a tout à gagner à mettre à plat dès le début du travail de modélisation la distinction entre :

• un modèle/format de travail;
• un modèle/format d’échange;
• et un modèle conceptuel;

Est-ce que l’on cherche à définir un modèle de travail qui sera utilisé à l’intérieur d’un système logiciel (le schéma des tables de sa base de données, pour faire simple) ? ou bien est-ce qu’on cherche à définir un modèle d’échange qui sera fait pour publier les données à l’extérieur du système logiciel, sur le web de données ? La distinction est empruntée à Bruno Bachimont (dans Ingénierie des connaissances et des contenus : le numérique entre ontologies et documents (Lavoisier, 2007)) :

« Les formats d’échange permettent de rendre lisibles par différentes applications les mêmes données. Les formats de travail permettent à une application d’effectuer tous les traitements nécessaires et de créer les structures à cet effet. »

Ou bien encore, et c’est un peu différent, est-ce que l’on cherche à esquisser un modèle conceptuel du domaine, c’est-à-dire se mettre d’accord sur les principales entités de ce domaine et les relations qu’elles entretiennent entre elles, sans rentrer dans les détails d’implémentation ? FRBR par exemple est un modèle conceptuel, et RDA est une implémentation de FRBR en tant que modèle d’échange; et rien n’implique qu’un logiciel compatible avec ce format d’échange l’utilise effectivement en tant que format de travail; il y a même toutes les chances que non.

La distinction entre ces 3 objectifs est importante car chacun va apporter ses contraintes : par exemple, faire le modèle de travail d’une application implique de prendre en compte des contraintes de facilité de saisie ou de navigation dans les données pour l’utilisateur, ou de traçabilité des informations (quel utilisateur a créé quoi). Faire un modèle de publication pour le web de données amène des contraintes de facilité de compréhension, et de réutilisation du modèle. Faire un modèle de domaine ne demande pas de rentrer dans le détail de chaque propriété et de chaque relation, mais d’être tout à fait clair sur la définition de chaque entité.

Retour d’expérience numéro 1 : déterminer précisément l’objectif du modèle : modèle interne à une application, modèle de publication, ou modèle conceptuel.

« Be real »

Les modèles, les ontologies et tous ces bazars conceptuels ont ce côté rassurant des arrières-mondes que l’on fabrique pour s’échapper du douloureux réel. Tant que l’on reste dans le modèle, tout va bien, mais quand on commence à regarder les données, les vraies données qui existent réellement pour de vrai, ça fait toujours un peu mal : on a oublié de prendre en compte telle colonne dans le fichier de données, telle autre contient du texte alors qu’on avait prévu une référence contrôlée, etc. Pour paraphraser la boutade philosophico-geek « le réel, c’est ce qui fait mal quand on éteint l’ordinateur », on pourrait dire « les données, c’est ce qui fait mal quand on a fini le modèle ». « Reality is broken », par essence.

Non content de faire un modèle avec des boîtes et des flèches, il faut travailler le plus tôt possible dans le processus de modélisation sur les vraies données. Les exemples de données existantes exprimées suivant le modèle conçu doivent faire partie des livrables, autant que le modèle lui-même.

Retour d’expérience numéro 2 : travailler sur des exemples de vraies données, en les exprimant dans le modèle cible.

Modéliser c’est communiquer

Tous les modèles sont imparfaits, on a beau le savoir il faut se le redire sans cesse pour ne pas oublier la réalité que ce modèle tente de capturer. Ce n’est pas la réalité qui est cassée (« reality is broken »), ce sont nos modèles. Ou plutôt, la réalité est cassée parce qu’on en fait des modèles.

Tous les modèles sont imparfaits, car, malgré toutes les précautions que vous aurez prises pour faire émerger une objectivité, celle-ci ne restera finalement que votre vision du monde, la vôtre personnellement, ou celle du groupe de gens qui ont participé à sa mise au point. Eternelle subjectivité. Et c’est précisément parce que votre modèle est subjectif qu’il faut être capable de l’expliciter, de l’expliquer, de le communiquer aux autres. Le modèle doit servir de moyen, de support à la communication de votre vision du domaine métier. Il doit permettre d’instaurer un dialogue. Eternelle inter-subjectivité. Dès lors, il faut s’appliquer à rendre le modèle communicable :

• 99% des modèles OWL que l’on trouve sur le web utilisent des URIs et des libellés en anglais. Mais pourquoi ne pas faire un modèle en français, si on le voit comme un support de communication à destination d’acteurs francophones ? c’est le parti que nous avons pris avec Anaphore. Pensons local avant de penser universel, il sera toujours temps, le jour où le modèle aura un succès international, de le traduire ;
• un fichier d’ontologie OWL ne suffit pas; c’est incompréhensible. Faites des diagrammes, des schémas, dès le début du processus de modélisation, pour vous mettre d’accord et pouvoir parler du modèle. La communication autour du modèle commence dès sa conception ;
• c’est une évidence, mais documentez les classes et les propriétés du modèle, et le modèle lui-même, en suivant les pratiques de bon sens documentées dans le LOV ;
• utilisez les outils de génération automatique de documentation à partir du fichier OWL, comme LODE ou Parrot. Nous avons utilisé LODE pour son rendu propre et la possibilité d’intégrer les images des diagrammes dans la documentation ;
• prévoyez un moyen de recevoir du feedback une fois votre modèle publié; a minima une adresse e-mail, ou une mailing-list, un forum, un formulaire de suggestion, un hashtag, ce que vous voulez, mais permettez qu’un dialogue s’instaure.

Retour d’expérience numéro 3 : penser dès le départ le modèle comme un moyen de communication, autant qu’un moyen de structurer les informations dans un système informatique.

Un arbre plutôt que du marbre

Si vous vous placez dans la perspective de publier un modèle OWL sur le web, il faut envisager cela à la fois, bien sûr, comme l’aboutissement d’un travail de réflexion, mais aussi comme le début d’un processus d’évolution. Ne pensez pas que votre modèle va être figé une fois publié. Si, comme évoqué précédemment, vous avez tenu compte de la réalité des données, et que vous avez prévu les moyens de dialogue et de feedback, alors votre modèle évoluera en tenant compte des évolutions dans l’expression des données et des retours de la communauté. Soyez donc prêt à prendre en compte ces retours, en prévoyant pourquoi pas un mécanisme de versioning, et en établissant clairement le processus de mise à jour; sans faire l’erreur de FOAF qui a incorporé un numéro de version dans son URI, en étant maintenant incapable de la changer sans embêter tous ses utilisateurs !

« …the technical namespace ID [of FOAF] remains fixed and includes the original value of « 0.1 ». It long ago became impractical to update the namespace URI without causing huge disruption to both producers and consumers of FOAF data. We are left with the digits « 0.1 » in our URI. This stands as a warning to all those who might embed metadata in their vocabulary identifiers. »

Bref, pensez à votre modèle comme quelque chose de vivant, un arbre plutôt que quelque chose de figé dans le marbre. Une certaine automatisation dans son processus de publication sur le web peut donc être bienvenue.

Evidemment, si votre modèle est un modèle de travail interne pour une solution logicielle, son évolution est moins aisée, la problématique est différente.

Retour d’expérience numéro 4 : penser à l’évolution du modèle une fois sa mise en ligne, ne pas hésiter à le faire évoluer.

Le second volet de ces quelques réflexions, dont le titre « Penser, modéliser » s’inspire du livre « Penser, classer » de Georges Perec, sera consacré aux motifs de conception (design pattern) utilisés pour construire ce modèle de description des fonds d’archives.

Cet article Penser, modéliser (pour le web de données) (1/2) est apparu en premier sur Sparna Blog.

Cet article Ontologie, Thesaurus et Taxonomie sur le web de données 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.

Dans le monde des développeurs d’applications basées sur le web sémantique, il y a 2 grandes écoles en ce qui concerne les triplestores : les adeptes de Jena, et ceux de Sesame.

Personnellement j’ai un faible pour Sesame. Sesame propose des fonctionnalités proches de Jena, moins complètes, mais sans doute un peu plus facile à intégrer ; la philosophie de son API est différente, et, s’il s’agit de faire simplement de la manipulation de données RDF (sans inférence compliquée, sans gestion d’ontologie OWL), le choix entre les deux est essentiellement une question de goût ! Son interface web d’administration vous facilitera par contre énormément le travail s’il s’agit de configurer rapidement un triplestore et de charger des données RDF dedans.

On donne ci-dessous un tableau comparatif des fonctionnalités entre Jena et Sesame, au 1er mai 2012 ; il faut noter que, là où Jena propose d’emblée un certain nombre de modules avec beaucoup de fonctionnalités, pour Sesame ces fonctionnalités peuvent être présentes dans l’ « écosystème » autour de Sesame : OWLIM ou Ali Baba.

Cet article RDF : Sesame, Jena, comparaison des fonctionnalités est apparu en premier sur Sparna Blog.