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.

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

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

Le problème avec OWL

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

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

SHACL

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

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

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

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

Validateurs SHACL

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

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

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

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

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

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

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

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

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.