340 notices en Unimarc LRM. 1 : Intentions et méthodologie

La 7e journée Métadonnées organisée par le groupe Systèmes et Données du programme Transition bibliographique a eu comme principal ordre du jour de présenter un ensemble de 340 notices d’items, manifestations, expressions et oeuvres cataloguées en Unimarc.

Sauf si vous avez suivi de bout en bout l’ensemble des étapes, cette nouvelle devrait déjà vous laisser perplexe.

D’abord sur le principe même : des notices en Unimarc correspondant à entités du modèle IFLA LRM ? Est-ce seulement possible ?

Alors qu’on sait bien que l’Unimarc est organisé en 2 branches :

• Unimarc pour les notices d’autorité  [Unimarc (A)]
• Unimarc pour les notices bibliographiques  [Unimarc (B)]

et que le modèle IFLA LRM est organisé autour de 4 classes (les OEMI), sans compter les relations de responsabilité et de sujet qui gravitent autour.

Et pourtant !

En faisant le choix de « ranger » les expressions du côté des autorités, c’est-à-dire d’utiliser le format Unimarc(A) pour décrire des expressions, on utilise pour la partie haute de l’arbre 2 notices d’autorité (Oeuvre et Expression) liées entre elles par des $3, et une notice bibliographie (Manifestation) liée à l’expression.

Ces 3 notices sont par ailleurs susceptibles d’être liées à des notices d’autorité Personne et Collectivité pour les mentions de responsabilité ; et le niveau Oeuvre peut être avoir une indexation Sujet.

Processus d’exploration

J’ai commencé un Notebook Python (cf. ce billet qui explique qu’un notebook est un document textuel qui inclut des parties de code exécutable) qui :

• importe les 4 fichiers UnimarcXML
  • items
  • manifestations
  • oeuvres et expressions
  • autres entités (personnes, collectivités, genre-forme)
• pour chaque notice trouvée, crée un objet Python en lui ajoutant des attributs à partir du contenu des notices.
  La liste de ces attributs peut évoluer, mais à ce stade il s’agit de :
  • l’identifiant : .id
  • le type d’entité : .type
  • la notice en XML et en texte : .xml et .txt
  • un « label » (pas tout à fait un point d’accès en bonne et due forme) : .label
  • les statistiques des zones et sous-zones (dictionnaire) : .stats_zones
  • les liens aux mentions de responsabilités (dictionnaire) : .resp
• chaque entité a des attributs supplémentaires pour les liens vers l’entité « supérieure » :
  • items : .toManifs
  • manifs : .toExpressions
  • expressions : .toOeuvres

Puis j’ai ajouté des mécanismes complémentaires pour pouvoir facilement :

• pour une manifestation donnée, avoir les items liés
• pour un identifiant, récupérer l’objet Python complet (donc avec sa notice initiale, son label, etc.) quel que soit son type
• d’autres « passerelles » (un identifiant renvoyant des informations) apparaîtront sans doute ultérieurement en fonction des besoins que je constate

Les objectifs

L’idée de tout ce dispositif est ensuite de pouvoir manipuler les données pour, notamment :

• afficher une notice précise avec des informations enrichies
• identifier des erreurs potentielles pour les corriger
• à force de manipulations un peu aléatoires, identifier ce qui est significatif, ce qui me permet de comprendre ce qu’il y a vraiment dans ce jeu de données
• expérimenter la datavisualisation en graphe, pour une notice précise ou pour le graphe complet

• tester des règles d’affichage d’un résultat ou d’une liste de résultats, en pouvant interagir avec le jeu de données
  Si je propose sur ce notebook une sorte de boîte de recherche (permettant de chercher un mot, par exemple) et que le programme associé à ce formulaire me renvoie les notices contenant ce terme :
  • que se passe-t-il si le mot doit être présent dans la manifestation, ou l’expression, ou l’œuvre, et que je ne « remonte » que cette entité ?
  • que se passe-t-il si j’essaie de concevoir une manifestation enrichie des expression(s) et œuvre(s) liées, et que la recherche porte sur l’arbre complet ? (ou chercher ? que ramener en liste de résultats ?)

Pour la suite

Le prochain billet fournira simplement un certains chiffres ou listes sur ces données Unimarc LRM, obtenus avec ce notebook (essayant de répondre à la question : quelles informations l’esprit juge-t-il significatif pour se dire au bout d’un moment « je sais ce qu’il y a dans ce corpus de 340 entités »)

NB : pour ceux que le code intéresse

Afin de faciliter la lecture et l’exécution du Notebook (si certains compte récupérer le dossier complet, avec fichiers de notices et scripts), j’ai déplacé une partie du code dans 2 fichiers :

• Record.py : la définition des classes
• common_dicts.py : ensemble de dictionnaires utiles (codes fonctions, zones de liens entre entités, etc.)