Skip to content

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)
9 commentaires
  1. 05/03/2015 10:43

    bonjour,
    et merci pour les 4 français qui s’intéressent à skos !
    le « typage » d’une relation précise entre 2 concepts peut être résolu comme tu le fais.

    je trouve judicieux même si c’est moche la double relation permettant à un système implémentant skos de pouvoir accéder à la relation skos:related même si celle ci est spécialisée.

    Une autre solution (cela n’engage que moi) serait de passer de RDF/XML à du RDF/Trig .. et par contre d’utiliser un Quad-Store pour la persistance ci besoin.

    Tu pourrais alors exprimer un contexte à ta relation : s – p – o – c
    (notez le petit hommage startrekien de circonstance..)

    cela donnerait un truc du genre (en trig) :

    tme:hasPotentialMaterial {
    toto:Marque1 skos:related toto:Material1 .
    toto:Marque1 skos:related toto:Material2 .
    }

    Autre remarque (moins en relation avec le sujet, mais j’en profite) :

    Un truc tout bête que je vois souvent et donc ici , c’est le triple inutile dans 99 % des cas d’utilisation de skos :

    reprenant ton exemple :

    Ex-libris

    #Marque1 a 2 relations skos:related (relation skos entre 2 skos:Concept.
    #Marque1 a 1 relation skos:inScheme
    3 preuves qui te permettent de retirer et d’alleger ton fichier du triple inutile suivant :

    cette remarque est valable dans nombreux cas de figure.
    personnellement, je pense que skos:inScheme devrait etre obligatoire et le typage dans un fichier d’import disant concept1 type skos:Concept, jamais utilisé.

    Partant du principe qu’un système implémentant skos se doit de gérer ce genre de regle défini dans la spec de skos :
    Si A skos:broader B ALORS A ET B sont des skos:Concept.
    tout systeme se disant « je gere le skos » devrait accepter un fichier d’import ne déclarant pas explicitement qu’une ressource est de type skos:Concept si ce fait est établi par ailleurs.

    Pour comparer avec la vraie vie, c’est un peu comme-ci on était obligé d’attacher sur les toits de toutes les maisons des grands panneaux avec écrit « MAISON ».
    cela dit ça serait marrant…m’en vais faire mon panneau moi…

    merci encore pour le club des 4.
    a +
    eric

  2. 05/03/2015 11:18

    j’aurai pas du mettre d’xml dans le com.. faut arreter le xml de toute façon ..

    il manque principalement ceci pour que ça soit compréhensible :

    […]
    « 3 preuves qui te permettent de retirer et d’alléger ton fichier du triple inutile suivant :

    toto:Marque1 rdf:type skos:Concept
     »

    sorry.

  3. 05/03/2015 11:40

    @Eric Sadou : merci beaucoup pour ces 2 commentaires extrêmement intéressants.
    Le 1er, je vais prendre le temps de le relire plus à fond.
    Pour le 2e : je sais, j’ai une vraie faiblesse avec XML, parce que je suis particulièrement à l’aise avec XSL. Et beaucoup plus démuni devant d’autres formats (pour l’instant).
    Et il m’arrive souvent de manipuler du RDF/XML avec des feuilles XSL (je sais, je ne devrais pas), en attendant d’apprendre comment manipuler du JSON-LD ou d’autres formats de données.
    A défaut de me guérir, je me soigne (ou du moins je me sermonne)

  4. 11/03/2015 12:10

    @Eric Sadou : à propos de la redondance que vous évoquez (comme quoi j’ai systématiquement indiqué que chaque concept était un concept, alors que d’autres prédicats suffisaient à le déduire), je pense que c’est une sorte de garde-fou psychologique nécessaire à ce stade pour moi, pour me souvenir de ce que je suis en train de manipuler.
    Pour vous donner un contre-exemple : je testais hier la description d’une organisation (un SCD, au hasard) en RDF (avec ce vocabulaire).
    J’ai voulu indiquer que cette organisation avait un site web, et une dénomination « préférée » :
    <http://bibliotheque.unice.fr/id&gt; foaf:website <http://bibliotheque.unice.fr/&gt; ;
    skos:prefLabel « Service commun de documentation de l’Université Nice Sophia Antipolis »

    Et puis j’ai réalisé que le domaine de foaf:website était un foaf:Agent;
    alors que le domaine de skos:prefLabel était un skos:Concept.
    Donc <http://bibliotheque.unice.fr/id&gt; était à la fois un agent et un concept.
    Donc il fallait que je fasse la même distinction que celle faite par data.bnf.fr, décrite sur cette page, entre les informations rattachées à la notice d’autorité, et la ressource elle-même.
    C’est une difficulté qu’on n’a pas avec les notices d’autorités en Unimarc, qui ne prétendent pas désigner les personnes elles-mêmes mais sont des fiches de métadonnées.

    Bref, en précisant à chaque ligne que dans mon vocabulaire contrôlé, j’ai des skos:Concept, je me garantis de ne pas l’oublier (et ça m’évite de dire qu’un concept « Ex libris » peut être en fer forgé, par exemple).

  5. 11/03/2015 12:26

    on a tous les 2 faux🙂
    inScheme n’induit pas qu’on est en presence d’un Concept. (sorry !)
    par ma remarque avec des relations broader/narrower ou topConceptOf est toujours valable.

    par contre tu dis « domaine de skos:prefLabel était un skos:Concept » : c’est également faux.

    un conceptScheme peut avoir un prefLabel par ex.

Trackbacks

  1. Créer une ontologie en SKOS – reto...
  2. Créer une ontologie en SKOS – retour d’expérience (3/5) : Cas de conscience | Veille juridique
  3. Créer une ontologie en SKOS… sur Bibliothèques [Reloaded] | Observatoire des technologies de l'IST
  4. Créer une ontologie en SKOS - retour d'e...

Les commentaires sont fermés.

%d blogueurs aiment cette page :