Skip to content

Créer une ontologie en SKOS – retour d’expérience (6/5) : Outils utilisés

16/03/2015

(j’ai bien indiqué « 6/5″ dans le titre, car au départ je n’avais pensé qu’à 5 billets)

Rappel du plan de l’ensemble des billets

  1. Le projet : explication liminaire
  2. Le format SKOS : petite exploration
  3. SKOS : questionnements infinis sur les subdivisions de termes
  4. Le processus de transformation (petits bricolages)
  5. La mise en ligne finale et ses limites (du point de vue des principes du web de données)
  6. Outils utilisés autour du projet et de SKOS (édition et visualisation)
  7. [peut-être] Perspectives d’autres utilisations de SKOS dans les bibliothèques et plus largement
    (ce billet est incertain : il n’est pas du tout rédigé, j’ai quelques vagues idées et ça mériterait d’être creusé. Ou alors je le rédige et le publie à son état d’ébauche, et on en parle ensuite.

Voici un rapide billet sur les outils utilisés pour la production du fichier SKOS. Je ne reviens pas sur le publipostage Word et le fichier XSL, déjà suffisamment évoqués.

RDF en généra : RDF W3C Validator + RDF Translator

Celui-là, je ne m’en sépare pas ! Ce validateur en ligne permet de contrôler que les triplets sont correctement formés, et d’afficher un graphe (image PNG) pour s’en rendre compte. A utiliser plutôt avec des petits tronçons de code, sinon ça devient un graphe incompréhensible (trop gros), même si la fonction de contrôle de conformité reste intéressante sur l’ensemble des données produites.

En complément, RDF translator permet d’avoir une sérialisation différente (N-triples, Turtle), souvent plus lisible que le RDF/XML.

Editer du SKOS : Protégé + SKOSEditor

Au tout début du projet, j’étais bien en peine de savoir à quoi devait ressembler réellement un fichier SKOS en RDF/XML. J’ai donc récupéré Protégé, logiciel de l’Université de Stanford.

Ce logiciel permet notamment de construire des ontologies OWL, c’est-à-dire des vocabulaires de propriétés. Par exemple si vous voulez décrire une organisation (un établissement) avec ses sous-structures, vous aurez besoin d’une propriété indiquant qu’une structure SCD X est rattachée à l’Université X. Le « est rattaché à » s’exprime sous forme d’URI, gérée et décrite au sein d’une ontologie.

Protégé permet donc de construire de telles ontologies.

Il propose aussi un plugin SKOS Editor. Après avoir installé Protégé dans un répertoire de son ordinateur, on télécharge en plus le fichier du plugin SKOS pour le déposer dans le répertoire /plugins de Protégé.

Un onglet « SKOS » apparaît, qui permet de créer un nouveau vocabulaire SKOS, ou d’ouvrir un fichier préexistant pour l’éditer ou le visualiser.

Je m’en suis servi au début pour comprendre ce que je devais produire, et en cours de route pour contrôler ce que je générais et voir si l’affichage était correct.

skoseditor

Naviguer dans un vocabulaire SKOS

Pour visualiser le résultat final, j’ai utilisé parallèlement (ou successivement) SKOS Play et SKOS Reader. Les 2 outils proposent plusieurs formats en sortie (mais la dernière fois que j’ai voulu tester SKOS Reader, il n’a pas réussi à lire mon fichier SKOS…).

skosplay

Le résultat en sortie est une page web dynamique, pleine de liens internes (renvois, etc.)

exemple skos-play

Créer une ontologie en SKOS – retour d’expérience (5/5) : Limites du résultat final

12/03/2015

Rappel du plan de l’ensemble des billets

  1. Le projet : explication liminaire
  2. Le format SKOS : petite exploration
  3. SKOS : questionnements infinis sur les subdivisions de termes
  4. Le processus de transformation (petits bricolages)
  5. La mise en ligne finale (et ses limites, du point de vue des principes du web de données)
  6. Outils utilisés autour du projet et de SKOS (édition et visualisation)
    (oui, en cours de route j’ai ajouté un 6e billet)

Les limites que je veux évoquer portent uniquement sur les conditions de publication d’une ontologie SKOS, au sens où je l’ai comprise.

En réalité ces limites n’ont pas beaucoup d’importance pour le groupe de travail qui a élaboré ce référentiel, car ils estiment que la solution est transitoire : le référentiel pourrait être profitablement enrichi par de nouveaux collaborateurs, et déplacé sur d’autres serveurs (avec une autre adresse). Ce qui a été mis sur Bibliopat.fr serait donc une version de « lancement », pour interpeler des communautés intéressées à travailler sur ce projet.

L’URL de l’ontologie n’est pas pérenne

Le site web (CMS Drupal) est conçu de telle manière que chaque fois qu’on recharge une pièce jointe, le nom du fichier est incrémenté de 1.

Actuellement, l’URL du fichier RDF est : http://www.bibliopat.fr/sites/default/files/provenances/referentiel_0.txt. Mais si on veut mettre en ligne une nouvelle version, l’URL d’accès deviendra referentiel_1.txt.

Cela signifie donc que tous les concepts qui sont dedans ont également des URI susceptibles de changer au fur et à mesure des versions.

(pire : les versions précédentes restent par défaut en ligne…)

Pas de négociation de contenu

Je rappelle le principe de la négociation de contenu : vous disposer d’une seule URI
(du type : http://http://www.bibliopat.fr/provenances/referentiel)
et selon que c’est un navigateur web ou un bot qui cherche à « ouvrir » cette URI, il sera redirigé tantôt vers la version HTML (redirigé vers l’URL http://http://www.bibliopat.fr/provenances/referentiel.html), tantôt vers la version RDF (http://http://www.bibliopat.fr/provenances/referentiel.rdf).

Je vous laisse voir sur l’article Wikipedia quelles sont les spécifications techniques qui permettent d’obtenir ce résultat.

En tout cas là, tout ce que j’ai fait, c’est indiquer une équivalence vers la version RDF depuis le fichier HTML : dans les métadonnées du fichier HTML, il y a donc une ligne

<link rel="alternate" type="application/rdf+xml" href="http://www.bibliopat.fr/sites/default/files/provenances/referentiel.rdf#" title="Structured Descriptor Document (RDF/XML format)">

Bon, le lien est devenu faux dès lors qu’on a fait des mises à jour dans la version RDF…

Je suppose qu’il doit être possible de proposer de la même manière une équivalence HTML (pardon : une sérialisation HTML) depuis la version RDF, mais je ne sais pas comment.

RDFa dans le HTML aurait été sympa aussi !

Dernier petit regret, qui pour le coup n’est dû qu’à ma flemme : j’aurais pu intégrer dans le code HTML des balises RDFa, c’est-à-dire injecter des triplets RDF (non visibles à l’affichage dans le navigateur) à l’intérieur des rubriques présentes dans la page et présentant les concepts en tableaux.

Donc par exemple pour l’entrée Reliure aux armes, ajouter le code :

<div about="#3"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:skos="http://www.w3.org/2004/02/skos/core#">
<span property="rdf:type" resource="http://www.w3.org/2004/02/skos/core#Concept"/>
<span property="skos:prefLabel">Reliure aux armes</span>
<span property="skos:altLabel">Reliure armoriée</span>
<span property="skos:altLabel">Armoiries</span>
<span property="skos:definition">Reliure présentant les armes d’une personne physique ou morale. Les armes peuvent présenter seulement les motifs et figures héraldiques qui les constituent ou figurer de façon plus complète en étant accompagnées d’éléments tels que couvre-chef (couronne, chapeau, tiare, heaume), cimier, dais ou pavillon, manteau, insigne de fonction ou de dignité (crosse, bâton..), supports et tenants, collier d’ordre, devise, cri d’armes.</span>
<span property="skos:inScheme" resource="#Marque"/>
<span property="skos:broader" resource="#2"/>
<span property="skos:example" resource="http://www.bibliopat.fr/sites/default/files/provenances/reliure_aux_armes_1.jpg"/>
</div>

Mais bon, voilà, je ne l’ai pas fait…

Créer une ontologie en SKOS – retour d’expérience (4/5) : Processus de production

10/03/2015

Rappel du plan de l’ensemble des billets

  1. Le projet : explication liminaire
  2. Le format SKOS : petite exploration
  3. SKOS : questionnements infinis sur les subdivisions de termes
  4. Le processus de transformation (petits bricolages)
  5. La mise en ligne finale (et ses limites, du point de vue des principes du web de données)
  6. Outils utilisés autour du projet et de SKOS (édition et visualisation)
    (oui, en cours de route j’ai ajouté un 6e billet. J’ai même vaguement l’idée qu’un 7e pourrait être intéressant.)

Workflow

Une fois que tous les choix intellectuels ont été retenus (cf. billet précédent), j’ai choisi de garder la méthode que j’utilise habituellement pour récupérer du Excel et en faire un fichier XML avec des traitements complexes au milieu (le plus souvent ; regroupement de lignes par sous-rubriques, comme dans le cas de génération de fichiers EAD)

transformations

 

  • Publipostage vers Word, qui rajoute simplement des balises XML autour des valeurs des colonnes.
    C’est ainsi un fichier XML très simple, « plat ».
    Le publipostage génère un fichier Word avec autant de <item> qu’il y a de lignes dans le tableau
    publipost
  • Retouches rapides à la main (ajout d’une balise racine, remplacement des & par des &amp;).
  • Feuille XSL qui traite les données du fichier XML de manière à obtenir le résultat espéré

La feuille XSL

Je ne vais pas vous copier-coller la feuille XSL en l’état, elle fait plus de mille lignes et me semble assez indigeste et incompréhensible : elle a été élaborée en continue pendant 6 mois, avec une sorte d’historicité de certaines lignes.

Même si je rajoute toujours des commentaires en-tête de certaines parties de code, l’ensemble s’appréhende assez mal.

Son rôle est de :

  1. produire les 2 fichiers en sortie : RDF/XML et HTML (car une sortie HTML était demandée)
  2. au passage, attribuer à chaque concept le même identifiant de 2 côtés
  3. pour le fichier RDF :
    • générer toute la structure qui englobe les concepts (les métadonnées de l’ontologie, en somme)
    • créer les renvois d’un concept à l’autre, en exploitant les identifiants générés à la place des labels (relations de type skos:broader et skos:related)
  4. pour le fichier HTML : contenir la mise en forme (CSS), la navigation (liens internes avec menu à listes imbriquées + ancres pour remonter vers le haut de la page), appeler les images illustrant certaines marques d’exemplaires

Pour la suite

Le prochain billet évoquera certaines limites pour le référentiel actuellement en ligne.

Je dis « certaines limites », car il y en a certainement d’autres dont je n’ai pas du tout conscience.

Créer une ontologie en SKOS – retour d’expérience (3/5) : Cas de conscience

05/03/2015

Précision

Ce billet entre dans le concret des choix d’encodage, comme en connaissent parfois les catalogueurs quand ils se triturent le cerveau pour choisir entre deux sous-zones, ou deux indicateurs. Enfin bref, ça signifie généralement que si le lecteur n’est pas lui-même un catalogueur qui a eu affaire aux mêmes sous-zones, la description du problème lui semblera absconse, et même indécente.

Donc ce billet intéressera vraisemblablement les quelques francophones qui ont eu à se poser des questions sur la bonne manière d’utiliser SKOS. Les autres… les autres reviendront quand ça leur arrivera : au moins ils savent à présent que ce billet existe, il les attend. Moi, ça me permet principalement de faire de l’auto-archivage et de l’auto-documentation.

Petite limite de SKOS : formes rejetées et formes alternatives

Je passe rapidement sur un deuil qu’il a fallu faire : dans le tableau fourni initialement par le groupe de travail, il y a avait 3 colonnes distinctes :

  • Libellé
  • Formes alternatives
  • Formes rejetées

Autant le dire : SKOS ne distingue par les 2 dernières formes : ce sont toutes des skos:altLabel. Heureusement (merci au groupe porteur du projet !) ça n’a pas remis en cause le choix de SKOS, et je n’ai pas eu à chercher comment exprimer (avec une autre ontologie ?) la notion de « forme rejetée » : les 2 dernières colonnes ont été fusionnées et tout est parti en « formes alternatives »/skos:altLabel.

Les subdivisions…

Là, par contre, je me suis davantage cassé la tête, et je ne suis même pas sûr d’avoir trouvé une solution satisfaisante.

Dans le tableau fourni, en plus de « libellé », etc., il y avait 3 autres colonnes :

  • Matière
  • Aspect
  • Technique

Exemple : un ex-libris peut être en papier, en cuir ou en tissu. Un ex-dono également.

Donc une même matière peut se retrouver liée à plusieurs types de marques d’exemplaires.

J’ai mis du temps à comprendre ce que ça pouvait signifier dans SKOS. Et j’ai fini par trouver un parallèle dans Rameau : ces 3 rubriques correspondent au même genre d’information que les subdivisions géographiques ou chronologiques.

Au sein d’un vocabulaire contrôlée, c’est une liste un peu particulière de valeurs, une sous-catégorie de concepts.

Dans l’ontologie « Marques d’exemplaire », j’avais donc finalement 4 types de concepts distincts :

  • les marques d’exemplaire
  • les matières qui peuvent qualifier (optionnellement) ces marques d’exemplaire
  • les précisions sur l’aspect, qui fonctionnent comme les matières
  • les techniques utilisées pour générer ces marques d’exemplaires

Donc je dois arriver à produire une ontologie SKOS qui rend compte de ces différents types de concepts. Mais comment dois-je articuler les familles de concepts entre eux ?

Un petit tour par data.bnf.fr

Pour y voir plus clair, je suis allé voir comment fonctionne les termes Rameau dans data.bnf.fr.

Plus exactement, j’ai cherché des exemples de subdivisions, pour voir comment data.bnf.fr les avait mis en SKOS.

Prenons le mot Renaissance, dont la note dit :

S’emploie uniquement en subdivision chronologique [sans subd. géogr.] à tous sujets noms communs et noms propres, à l’exception des personnes et des sujets pour lesquels il existe un découpage chronologique spécifique, ou qui sont complétés par l’expression « de la Renaissance », par ex. : Manuscrits à peintures de la Renaissance

C’est là un concept particulier dans Rameau, de type « subdivision chronologique ». Ce concept est distinct de Peintures de la Renaissance, qui est de type « Indexation matière Tête de vedette ».

Et comme le dit la note, il est d’ailleurs impossible d’associer la subdivision « Renaissance » à ce mot-matière. « Renaissance » sera plutôt associée à des pays, etc.

Après avoir bien navigué sur data.bnf.fr, j’ai fini par prendre contact avec @SebPeyrard, parce que je ne comprenais pas « comment ça fonctionnait » (merci à lui pour ses explications et sa patience !).

En fait, la BnF n’a pas vraiment publié Rameau sous forme d’ontologie SKOS : elle a publié l’ensemble de l’indexation utilisée dans le catalogue de la BnF dans un format RDF/XML utilisant les propriétés SKOS, avec un lien, depuis chaque mot-clé, vers les ressources bibliographiques  qui l’utilisent.

Ainsi, quand on va chercher la version RDF de Renaissance,  on trouve :

  1. les liens vers les documents qui utilisent cette indexation
  2. la notice en SKOS. Si je ne garde que cette partie, voici ce que ça donne :
    (voir la version sur Gist, avec un code couleur peut-être plus lisible)
    <?xml version="1.0" encoding="UTF-8"?>
    <rdf:RDF xmlns:bnf-onto="http://data.bnf.fr/ontology/bnf-onto/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:skos="http://www.w3.org/2004/02/skos/core#">
    <rdf:Description rdf:about="http://data.bnf.fr/ark:/12148/cb11993774x">
    <skos:prefLabel xml:lang="fr">Renaissance</skos:prefLabel>
    <skos:closeMatch rdf:resource="http://dewey.info/class/940/"/>
    <skos:closeMatch rdf:resource="http://dewey.info/class/900/"/>
    <skos:scopeNote xml:lang="fr">S'emploie uniquement en subdivision chronologique [sans subd. géogr.] à tous sujets noms communs et noms propres, à l'exception des personnes et des sujets pour lesquels il existe un découpage chronologique spécifique, ou qui sont complétés par l'expression "de la Renaissance", par ex. : Manuscrits à peintures de la Renaissance</skos:scopeNote>
    <rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/>
    <skos:related rdf:resource="http://data.bnf.fr/ark:/12148/cb13318531w"/>
    <skos:related rdf:resource="http://data.bnf.fr/ark:/12148/cb119768499"/>
    <skos:related rdf:resource="http://data.bnf.fr/ark:/12148/cb119757175"/>
    <skos:altLabel xml:lang="fr">+* 1400......- 1599......+:1400-1599: (Renaissance)</skos:altLabel>
    <skos:altLabel xml:lang="fr">Renaissance (subdivision chronologique)</skos:altLabel>
    <rdfs:seeAlso rdf:resource="http://catalogue.bnf.fr/ark:/12148/cb11993774x"/>
    <dcterms:isPartOf rdf:resource="http://data.bnf.fr/vocabulary/scheme/r166"/>
    <dcterms:isPartOf rdf:resource="http://data.bnf.fr/vocabulary/scheme/r168"/>
    <skos:narrower rdf:resource="http://data.bnf.fr/ark:/12148/cb11976234m"/>
    <skos:narrower rdf:resource="http://data.bnf.fr/ark:/12148/cb11976033q"/>
    <skos:broader rdf:resource="http://data.bnf.fr/ark:/12148/cb119344445"/>
    <bnf-onto:FRBNF rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">11993774</bnf-onto:FRBNF>
    <owl:sameAs rdf:resource="http://stitch.cs.vu.nl/vocabularies/rameau/ark:/12148/cb11993774x"/>
    </rdf:Description>
    </rdf:RDF>

J’ai mis en gras les principaux éléments qu’on retrouve dans la version web. En rouge : le code qui indique que « Renaissance » est un concept au sens ou SKOS le définit.

Dans la note et dans un des skos:altLabel, on retrouve bien la notion de subdivision chronologique. Mais ça, c’est visible par un être humain, pas par un ordinateur.

Je ne trouve pas ici :

  • une information exprimée en triplets disant :
    <ce_concept> <est_de_type> <subdivision_chronologique>
    qui me permettrait par exemple via une requête SPARQL d’extraire la liste des subdivisions chronologiques de Rameau
  • une information (informatique) expliquant à quels types d’autres concepts Rameau celui-ci peut être associé, ou ne pas être associé

Ne vous y méprenez pas : c’est déjà énorme, et bien pratique. Mais de mon point de vue on a là un corpus, pas une ontologie.

En tout cas ça ne correspondait pas du tout à ma situation : la BnF est partie d’une masse de notices existantes, pour en extraire l’indexation à un instant t.
Moi, je devais construire une ontologie qui permettrait ensuite de produire des notices : car c’était bien l’idée, à savoir faire en sorte que, un jour, un environnement de catalogage importe le contenu de l’ontologie pour aider la saisie et contrôler le contenu (de manière à ce qu’on ne puisse pas associer n’importe quel concept avec n’importe quel autre).
Donc exactement l’inverse.

Solution envisagée

J’en suis venu à l’idée de construire des sous-classes de skos:Concept.

Des sous-classes

En effet dans une ontologie SKOS toute entrée est de type skos:Concept. Mais dans l’ontologie des marques d’exemplaires, j’avais quatre familles distinctes de skos:Concept (cf. plus haut).

Pour SKOS, une « famille de concepts » s’appelle un ConceptScheme.

J’ai donc  défini mes 4 types (mes 4 « ConceptScheme ») ainsi :

<!--Définition du concept Scheme "Marque d'exemplaire", appliqué à chacune des lignes du tableau-->
<rdf:Description rdf:about="#Marque">
<rdf:type rdf:resource="skos:ConceptScheme"/>
<rdfs:label xml:lang="fr">Marque d'exemplaire</rdfs:label>
<skos:definition>Type des marques de possession ou d'origine constatées sur les exemplaires</skos:definition>
</rdf:Description>

<!--Définition de 3 concept Scheme : Material, Technique, Appearance-->
<rdf:Description rdf:about="#Material">
<rdf:type rdf:resource="skos:ConceptScheme"/>
<rdfs:label xml:lang="fr">Matière</rdfs:label>
<skos:definition>Type de concept "Matière"</skos:definition>
</rdf:Description>

<rdf:Description rdf:about="#Technique">
<rdf:type rdf:resource="skos:ConceptScheme"/>
<rdfs:label xml:lang="fr">Technique</rdfs:label>
<skos:definition>Type de concept "Technique"</skos:definition>
</rdf:Description>


<rdf:Description rdf:about="#Appearance">
<rdf:type rdf:resource="skos:ConceptScheme"/>
<rdfs:label xml:lang="fr">Forme</rdfs:label>
<skos:definition>Type de concept "Forme"</skos:definition>
</rdf:Description>

Et ensuite, chaque concept de la colonne « Matière » était rattachée à la famille de concepts « Matière ».

<rdf:Description rdf:about="#Material5">
<rdf:type rdf:resource="skos:Concept"/>
<skos:inScheme rdf:resource="#Material"/>
<skos:prefLabel>Parchemin</skos:prefLabel>
</rdf:Description>

« Parchemin » (identifiant : #Material5) est donc un concept SKOS (ligne 2) du type « Material ».

Maintenant, quand je décris un concept comme « Ex-libris », comment je peux dire qu’il peut être en parchemin ?

Car SKOS ne me permet pas de définir la propriété « est dans la matière XXX »

materiau

(comment exprimer ma flèche ?)

Des sous-propriétés

Ben oui, après les sous-classes de skos:Concept, j’ai dû définir des sous-propriétés de skos:related.

En gros : cette flèche relie 2 concepts SKOS entre eux, mais d’une manière bien plus précise que ce qu’exprime « skos:related ».

En tête de mon ontologie SKOS, j’ai donc ajouté les précisions suivantes :
<!--Matière-->
<rdf:Description rdf:about="#material">
<rdf:type rdf:resource="owl:ObjectProperty"/>
<rdfs:subPropertyOf rdf:resource="skos:related"/>
<rdfs:label xml:lang="fr">Matériau [subdivision]</rdfs:label>
<skos:definition>Définit le matériau utilisé. S'emploie uniquement en subdivision des types de marques.</skos:definition>
</rdf:Description>

<!--Technique-->
<rdf:Description rdf:about="#technique">
<rdf:type rdf:resource="owl:ObjectProperty"/>
<rdfs:subPropertyOf rdf:resource="skos:related"/>
<rdfs:label xml:lang="fr">Technique [subdivision]</rdfs:label>
<skos:definition>Définit la technique utilisée. S'emploie uniquement en subdivision des types de marques.</skos:definition>
</rdf:Description>

<!--Forme-->
<rdf:Description rdf:about="#aspect">
<rdf:type rdf:resource="owl:ObjectProperty"/>
<rdfs:subPropertyOf rdf:resource="skos:related"/>
<rdfs:label xml:lang="fr">Forme [subdivision]</rdfs:label>
<skos:definition>Définit l'aspect de la marque. S'emploie uniquement en subdivision des types de marques.</skos:definition>
</rdf:Description>

J’ai donc désormais 3 nouvelles propriétés à disposition, me permettant d’associer mes concepts « marque d’exemplaire » avec les matériaux, techniques ou aspects.

Et pour si je veux associer un ex-libris à une liste de matériaux, de formes ou de techniques possibles, ça donne (simplifié) :

<rdf:Description rdf:about="#Marque1">
<rdf:type rdf:resource="skos:Concept"/>
<skos:prefLabel xml:lang="fr">Ex-libris</skos:prefLabel>
<tme:material rdf:resource="#Material1"/>
<tme:material rdf:resource="#Material2"/>
<skos:related rdf:resource="#Material1"/>
<skos:related rdf:resource="#Material2"/>
<!--Rattachement du concept au ConceptScheme "Marque"-->
<skos:inScheme rdf:resource="#Marque"/>
</rdf:Description>

J’ai doublé chaque propriété tme:material d’une propriété skos:related pour rendre la relation plus facilement exploitable. Mais en fait le skos:related était induit par la description plus haut de la propriété tme:material, sous-propriété de skos:related.

Et finalement ?

Finalement dans les versions suivantes du tableau Excel envoyées par le groupe de travail, ce tableau qui contient le vocabulaire contrôlé à mettre en SKOS, les colonnes ont disparues (pour des choix propres au groupe de travail).

Je n’ai donc pas eu besoin de mettre en place tout le dispositif ci-dessus. Ce qui m’a simplifié la vie, et m’a évité d’être potentiellement ridicule avec les choix retenus.

Mais grâce à cela j’ai pu apprendre pas mal de trucs, même si j’ai l’impression qu’il n’y a pas vraiment de solution définitivement satisfaisante.

Je serais intéressé par des avis sur la solution que j’avais envisagée. Oui, c’est à toi que je parle, toi qui fais partie des 4 internautes arrivés jusqu’à ce stade du billet. Si tu es là, tu as certainement une remarque à faire :-)

Conclusion

Un billet plein de code, indigeste, mais que tout le monde a finalement survolé. Donc peu de dégâts au final !

Ah oui, finalement je ferai un 6e billet sur les outils utilisés pendant le projet.

Ce qui nous donne :

Rappel du plan des billets prévus :

  1. Le projet : explication liminaire
  2. Le format SKOS : petite exploration
  3. SKOS : questionnements infinis sur les subdivisions de termes
  4. Le processus de transformation (petits bricolages)
  5. La mise en ligne finale (et ses limites, du point de vue des principes du web de données)
  6. Outils utilisés autour du projet et de SKOS (édition et visualisation)

Créer une ontologie en SKOS – retour d’expérience (2/5) : SKOS ?

03/03/2015

Rappel du plan des billets prévus :

  1. Le projet : explication liminaire
  2. Le format SKOS : petite exploration
  3. SKOS : questionnements infinis sur les subdivisions de termes
  4. Le processus de transformation (petits bricolages)
  5. La mise en ligne finale (et ses limites, du point de vue des principes du web de données)

La demande était, en substance : mettre en ligne un vocabulaire contrôlé dans un format lisible par l’être humain et par l’ordinateur.

Je ne sais pas pour vous, mais moi, spontanément, j’ai tout de suite pensé à SKOS
(ce qui est une erreur : il y a peut-être d’autres solutions, que je n’ai pas davantage envisagées depuis, et qui auraient pu être pertinentes pour le projet).

SKOS : un vocabulaire pour des vocabulaires

SKOS correspond exactement à la commande initiale.

Imaginons que vous voulez publier dans le web de données (donc sous forme de triplets RDF) un vocabulaire contrôlé (comme l’est RAMEAU, ou le MeSH).

En gros :

  • quand vous voulez diffuser un vocabulaire contrôlé, vous allez avoir besoin des notions suivantes :
    • forme retenue
    • forme(s) rejetée(s)
    • définition(s)
    • illustrations et exemples
    • liens entre les différents concepts présentés :
      • « plus large que » :
        « cancer » est plus large que « cancer du sein« 
      • « proche de » :
        « trisomie 21″ et « trisomiques 21 » sont 2 concepts Rameau distincts, mais liés entre eux.
        (oui, je sais, je suis très en forme pour mes exemples)
    • et quelques autres petites choses utiles dont je parlerai plus tard (peut-être=
  • quand vous voulez le mettre dans le web de données, vous allez avoir besoin que ces liens entre concepts soient exprimées sous forme d’URI.
    Par exemple, pour lier le concept « cancer » (URI : http://data.bnf.fr/ark:/12148/cb11931105q) avec « cancer du sein » (URI http://data.bnf.fr/ark:/12148/cb11933256c), il faudra l’exprimer sous la forme :

    http://data.bnf.fr/ark:/12148/cb11933256c skos:broader http://data.bnf.fr/ark:/12148/cb11931105q

    (ou skos:broader est une manière raccourcie de dire : http://www.w3.org/2004/02/skos/core#broader.)

Requête SPARQL (via le Sparql Endpoint de data.bnf qui donne des exemples de concepts liés entre eux par la relation skos:related.
(la requête n’est pas forcément un modèle de syntaxe, mais comme elle fonctionne…)

select ?sujet1 ?label1 ?sujet2 ?label2 where {
?sujet1 a skos:Concept.
?sujet1 skos:related ?sujet2.
?sujet1 skos:prefLabel ?label1.
?sujet2 skos:prefLabel ?label2.} 
LIMIT 100

La 2e  ligne demande que, dans data.bnf, le « sujet1″ soit défini comme un concept au sens SKOS.
La 3e ligne indique que sujet1 et sujet2 sont liés entre eux par la relation skos:related.Les 4e et 5e lignes permettent de récupérer les labels des sujet1 et sujet2 (car sujet1 et sujet2 sont les URI des concepts, pas les formes retenues)

Résultat de cette requête :

exemple Rameau SKOS - résultats (tableau) en format HTML

Bref, SKOS fournit le vocabulaire pour définir

  • les attributs d’un concept : skos:prefLabel, skos:altLabel, skos:definition, etc.
  • les relations entre concepts
  • ce qu’est un concept lui-même : on peut ainsi chercher dans data.bnf.fr les objets de type « skos:Concept » (c’est la 2e ligne de ma requête ci-dessus), parmi tout ce que peut contenir data.bnf.fr (des personnes, par exemple)

Exemple pour les marques d’exemplaire

J’en suis donc venu à produire un fichier RDF/XML avec ce genre de lignes, qui décrit (comme c’est indiqué) la notion de « reliure aux armes » (du propriétaire ou de quelqu’un d’autre) :

(Je reviendrai dans le dernier billet prévu sur l’URL de déréférencement du vocabulaire, ici http://www.bibliopat.fr/sites/default/files/provenances/referentiel.rdf

<rdf:Description rdf:about="http://www.bibliopat.fr/sites/default/files/provenances/referentiel.rdf#3">
<rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/>
<skos:prefLabel xml:lang="fr">Reliure aux armes</skos:prefLabel>
<skos:prefLabel xml:lang="en">Armorial binding</skos:prefLabel>
<skos:prefLabel xml:lang="es">Encuadernación heráldica</skos:prefLabel>
<skos:prefLabel xml:lang="de">Einband Wappen</skos:prefLabel>
<skos:altLabel xml:lang="fr">Reliure armoriée</skos:altLabel>
<skos:altLabel xml:lang="fr">Armoiries</skos:altLabel>
<skos:altLabel xml:lang="fr">Armes</skos:altLabel>
<skos:altLabel xml:lang="en">Armorial tool</skos:altLabel>
<skos:altLabel xml:lang="en">Armorial panel</skos:altLabel>
<skos:altLabel xml:lang="fr">Blason (forme rejetée)</skos:altLabel>
<skos:altLabel xml:lang="en">Coat of arms (forme rejetée)</skos:altLabel>
<skos:altLabel xml:lang="en">Heraldry (forme rejetée)</skos:altLabel>
<skos:definition xml:lang="fr">Reliure présentant les armes d’une personne physique ou morale. Les armes peuvent présenter seulement les motifs et figures héraldiques qui les constituent ou figurer de façon plus complète en étant accompagnées d’éléments tels que couvre-chef (couronne, chapeau, tiare, heaume…), cimier, dais ou pavillon, manteau, insigne de fonction ou de dignité (crosse, bâton..), supports et tenants, collier d’ordre, devise, cri d’armes.
D'autres éléments non héraldiques peuvent également être présents en plus de ces armes : lettre unique, initiales, chiffre, monogramme, cri d’armes (phrase de ralliement propre à une personne physique ou morale, inscrite sur les armoiries et placée à la partie supérieure de la composition.),… Dans ce cas, il faut préciser « reliure aux armes et initiales… », « reliure aux armes et chiffre… », « reliure aux armes et monogramme… », « reliure aux armes et cri d’armes… ». Si l’on ne parvient pas à identifier les armes, il faut utiliser l’expression « reliure aux armes non identifiées ».</skos:definition>
<skos:inScheme rdf:resource="http://www.bibliopat.fr/sites/default/files/provenances/referentiel.rdf#Marque"/>
<skos:broader rdf:resource="http://www.bibliopat.fr/sites/default/files/provenances/referentiel.rdf#2"/>
<skos:example rdf:resource="http://www.bibliopat.fr/sites/default/files/provenances/reliure_aux_armes_1.jpg"/>
</rdf:Description>

Le code ci-dessus génère, pour l’ordinateur, un graphe de ce genre (obtenu avec le W3C RDF Validator):

servlet_4719432152438056035

Pour la suite

Le billet qui suivra sera sur mes cas de conscience concernant la manière d’utiliser SKOS, face à divers choix d’encodage. J’aurai donc l’occasion d’y remercier (mais je le fais déjà, plutôt deux fois qu’une !) @SebPeyrard pour ses explications concernant la conversion de Rameau en SKOS pour data.bnf.fr, qui m’a bien aidé.

Le suivant devrait être consacré à ceci :
(dont je reconnais volontiers que c’est du bricolage)

transformations

Créer une ontologie en SKOS – retour d’expérience (1/5)

27/02/2015

J’ai été sollicité il y a quelques mois par un groupe informel de collègues bibliothécaires pour voir comment il était possible de mettre dans un « format informatique » un vocabulaire contrôlé de marques d’exemplaires.

Ce projet a été l’occasion pour moi de m’intéresser de très près à SKOS, donc je compte vous en parler en plusieurs fois, car j’ai pu aborder pas mal d’aspects divers.

Tout d’abord, de quoi on parle

De quelque chose qui, au départ, ressemblait à ceci : une manière normalisée de décrire des marques de propriétés apparaissant sur des livres anciens (ex libris manuscrit, reliure aux armes du propriétaire, etc.).

types - institut de France

Le groupe de travail en question comptait :

  • enrichir et finaliser ce vocabulaire contrôlé, en combinant les compétences et expériences issues de plusieurs bibliothèques patrimoniales (et plusieurs vocabulaires déjà existants)
  • fournir une terminologie multilingue
  • trouver une manière de le publier en ligne qui soit également exploitable par des machines (on verra plus tard ce que ça peut impliquer)

Plan des billets à venir

(ce plan est purement indicatif, les promesses électorales n’engageant que ceux qui les écoutent)

  • Le format SKOS : petite exploration
  • SKOS : questionnements infinis sur les subdivisions de termes
  • Le processus de transformation (petits bricolages)
  • La mise en ligne finale (et ses limites, du point de vue des principes du web de données)

En attendant

En attendant les billets suivants, vous pouvez voir le résultat du travail du groupe sur la rubrique Provenance > Description et signalement de Bibliopat.fr.

Vous pourrez y voir notamment que ma contribution (dans la partie basse de la page) ne porte que sur une petite dimension du projet, qui par ailleurs a une approche plus scientifique (et non purement technique).

Nice recherche 2 conservateurs (services à la recherche inside)

19/02/2015

Recherche Conservateur – Petite prime – Photo FlicKR par Kevin Dooley – CC-BY-2.0

Ca n’apparaît pas dans Poppee (ni sur la carte de 27point7) parce que nous n’avions aucun poste vacant nous permettant de faire entrer cette information, mais le SCD de Nice a deux postes très susceptibles d’être vacants (presque déjà carrément vacants, quoi) :

  • un responsable du pôle Lettres, Arts, Sciences humaines et sociales (coordination de 3 bibliothèques – cf. l’organigramme)
  • un responsable des Services à la recherche

Je vais vous parler surtout de ce dernier, parce qu’il me concerne de plus près. Mais le premier est bien aussi !

Les services à la recherche au SCD de Nice

Il y a environ 9 mois, nous avons accompagné un laboratoire de l’Université dans un projet de recherche qui impliquait l’extraction et l’enrichissement de milliers de notices dans theses.fr et le Sudoc (et quelques autres petites choses au passage).

Nous avions déjà pas mal de compétences techniques en interne, mais encore jamais appliquées sur ce genre de projets, en dialogue avec des chercheurs, et en déployant une méthodologie spécifique.

Ce projet, finalisé pour l’essentiel, nous a permis de mettre le pied à l’étrier sur la question des services aux activités de recherche. Plusieurs collègues sont montés en compétence sur ces questions, nous avons recruté 27point7 pour 3 mois (il est chez nous en ce moment, en stage Enssib) pour nous aider à conceptualiser, formaliser, définir le calendrier et clarifier les objectifs.

Mais grosso modo nous avons un responsable des services à la recherche, chargé de :

  • accompagner les projets de recherche incluant une dimension de traitement, extraction, enrichissement, visualisation de données
    (avec pour l’assister une BAS extra, la même qui rédige ce genre de billets, et puis je donne un coup de main aussi)
  • dialoguer avec la Dirved en amont, et avec les chercheurs en direct, dès qu’il s’agit d’élaborer des plans de gestion des données (H2020 mon amour)
  • coordonner l’affichage de l’offre de services aux chercheurs pour l’ensemble du SCD : pas pour mettre en place l’ensemble des services dans l’ensemble des BU, mais pour garantir une lisibilité de cette offre (qui ne concerne pas que les données, mais inclut l’accès aux ressources, la politique d’open access et d’accompagnement à la publication, l’aménagement des espaces, etc.)

Bref, nous sommes déjà sur une bonne lancée, le collègue qui arrivera n’aura pas à construire sur du rien (et divers interlocuteurs, vice-président, doyen ou chercheur, sont très intéressés par ce service).

On ne cherche pas dans l’immédiat un expert en traitements des données : nous avons cela en stock.

En revanche il nous faut quelqu’un capable d’évoluer (il ne s’agit pas d’arriver avec des compétences, il s’agit d’être prêt à en acquérir, continuellement), familier avec les enjeux de la recherche scientifique et capable de dialoguer avec des chercheurs, ayant fait un minimum de veille sur les enjeux des humanités numériques, sachant ce qu’est une API (même s’il ne sait pas forcément la manipuler), en mesure d’identifier les possibilités qu’offrent les technologies du web de données, etc. Travail en équipe et en réseau, relations avec les chercheurs, les labos, les IGE documentation, etc., seront à assurer au quotidien.

Ce poste est au cœur des évolutions des métiers aujourd’hui, mais tout n’est pas à inventer sur place : il y a une équipe, des compétences, des objectifs, un soutien de l’établissement.

Donc pour un conservateur qui a vu émerger la question des services à la recherche, que ça intéresse et qui veut s’y mettre, c’est l’endroit idéal.

Seul défaut de ce poste : j’en suis le supérieur hiérarchique direct (département Sidoc, aka Système d ‘information documentaire). Vous devrez donc me supporter. Mais pour le reste, il est génial.

Circuit

Donc pour plus de précisions (et même entretien !) : les fiches de postes et modalités de contact sont en ligne :

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 139 autres abonnés