Aller au contenu principal

Des milliers de ebooks (et de liens !) dans le catalogue de la BnF

09/07/2018

Posons le contexte

Depuis 2011, la BnF acquiert des ebooks. Parfois à l’unité, parfois en bouquets. L’ensemble, cumulé sur plusieurs années, avait fini par représenter 100.000 documents. Et pendant que les acquéreurs achetaient, les normalisateurs définissaient le format des notices cibles à obtenir.

A la fin, tout est prêt – il n’y a plus qu’à les mettre dans le catalogue. La BnF dispose évidemment d’un accès à l’API Worldcat et peut donc dériver en masse les notices.

Mais une simple dérivation signifiait qu’on allait générer 100.000 notices bibliographiques pas vraiment intégrées au catalogue :

  • Soit en ne générant aucun lien vers aucune notice d’autorité (les notices d’auteur, mais aussi l’indexation sujet)
    c’est à ça que ressemble les notices récupérées des éditeurs : description riche, mais aucun lien aux autorités
  • Soit en générant des notices d’auteur à la volée (récupération du nom + prénom et faire une fiche d’auteur minimaliste), alors qu’une partie d’entre eux existait déjà dans le catalogue

L’objectif d’un chantier qui a duré toute l’année 2017, a donc consisté à voir comment récupérer, pour chacun de ces ouvrages, le maximum d’informations :

  1. Sur ses auteurs
  2. Sur ses sujets

Et cela a donné le processus ci-dessous :

Le point d’entrée, c’est une liste d’ISBN fournie par chacune des plateformes (Wiley, ScienceDirect, Springerlink, etc.)

A la suite de ça : pour chaque ISBN

  • Récupération de la notice complète Worldcat en Marc21
  • Dans cette notice, on récupère la combinaison Titre + Auteur(s)
    • On cherche dans le catalogue BnF si cette combinaison Titre-Auteur renvoie un résultat
    • Si c’est le cas, on récupère les identifiants BnF
      • De chaque auteur
      • De l’indexation Rameau
      • De l’indexation Dewey
    • Dans tous les cas, on interroge le Sudoc (api isbn2ppn).
      Si la notice existe :

      • Si elle a des liens à des notices d’auteur IdRef, on les récupère
        • pour voir si la notice IdRef contient un équivalent BnF
      • Si elle a une indexation Rameau / Dewey, on les prend
        • Et on récupère dans les notices IdRef les identifiants BnF de ces concepts Rameau / Dewey
      • Au passage : si un catalogueur du réseau Sudoc a déclaré un homothétique papier (version imprimée équivalente à la version électronique) : on récupère l’ISBN, et on regarde s’il existe dans le catalogue BnF
    • L’indexation Rameau fait l’objet d’un traitement particulier :
      Les notices WorldCat fournissent uniquement une indexation LCSH
      Or 105.000 notices Rameau contiennent des équivalents LCSH
      Donc il est possible de convertir l’indexation LCSH en indexation Rameau :

      • A condition de respecter les règles d’utilisation Rameau (ne pas mettre en tête de vedette un concept utilisable seulement en subdivision, par exemple)
      • A condition que le concept LCSH ne soit pas déclaré équivalent à deux concepts Rameau (dans ce cas, quel concept Rameau choisir ?)
        Pour faire ça, je suis passé par un fichier XML intermédiaire, en local (pour éviter, à chaque libellé LCSH, d’interroger le catalogue de la BnF), qui contenait l’ensemble des alignements LCSH-Rameau et les règles d’utilisation des concepts Rameau

A la fin, on a agrégé un certain nombre d’informations :

  • La description textuelle du document (Titre, mention de responsabilité, date, éditeur, nombre de pages, etc.) : de WorldCat uniquement
  • Les liens aux notices d’auteurs :
    • Si l’imprimé existe à la BnF, du catalogue BnF
    • Si la version électronique a été cataloguée manuellement dans le Sudoc, du Sudoc
  • L’indexation Sujet :
    • du catalogue BnF, si on a la version imprimée
    • du catalogue Sudoc, si la notice du ebook a fait l’objet d’une indexation Rameau manuelle
    • de la conversion LCSH à Rameau
  • La déclaration d’homothétique papier : venant du Sudoc uniquement

 

On peut ensuite reconstruire la notice cible, avec un ordre de préférence : par exemple pour l’indexation Sujet, on préfèrera l’indexation BnF, puis l’indexation Sudoc, puis la conversion LCSH-Rameau.

Le cœur de ce dispositif, ce sont les alignements :

  • Alignements entre notices bibliographiques, qui permettent de reporter d’une notice à l’autre certaines informations
  • Alignements entre référentiels (LCSH-Rameau), qui permettent de convertir dans un vocabulaire ce qui a déjà été exprimé dans un autre.

Résultat quantitatif

Sur les 95.000 notices de ebooks rattachées à des bouquets, voici les liens générés

Nombre de notices avec au moins 1 lien $3 en zone 606 Indexation Rameau 77322 81,39%
Nombre de notices avec au moins 1 lien $3 en zone 676 Indexation Dewey 26239 27,62%
Nombre de notices avec au moins 1 lien $3 en zone 700 Liens auteurs 10234 10,77%
Nombre de notices avec au moins 1 lien $3 en zone 432 Homothétiques imprimés 1614 1,70%
Nombre de notices avec au moins 1 lien $3 en zone 710 Liens auteurs Organisations 956 1,01%
Nombre de notices avec au moins 1 lien $3 en zone 607 Indexation géographique 526 0,55%
Nombre de notices avec au moins 1 lien $3 en zone 600 Indexation personne 330 0,35%

Pour l’indexation Sujet, c’est plutôt très satisfaisant. L’essentiel vient des équivalences LCSH-Rameau alimentées par le Centre Rameau : cela se voit au fait que les liens vers les auteurs (zones 700) sont beaucoup moins importants ; on n’a de version imprimée que dans 10% des cas.

Evidemment, toutes ces notices sont récupérables.

Questionnement final

Chaque notice obtenue est donc le résultat de l’agrégation de plusieurs sources.

Il est possible de revenir au fichier intermédiaire (un énorme fichier XML) qui permet de voir, pour chaque ISBN, ce qui a pu être rapatrié de la BnF, du Sudoc et de WorldCat. Mais c’est complètement invisible dans la notice Marc finale. Par par manque de bonne volonté : mais parce que le format Marc prévoit de donner la source d’une notice (l’ARK BnF, le numéro WorldCat) – mais pas de sourcer un élément d’information au sein d’une notice.

Il sera très tentant de recommencer l’expérience sur des documents non encore indexés à la BnF, mais indexés ailleurs.

Les champs d’applications me réjouissent d’avance

Ci-dessus, une utilisation d’un web service Worldcat qui rend compte de l’indexation de chaque ouvrage, au sein de laquelle on peut identifier ce qui relève d’une mention « genre de l’œuvre »

Bibliostratus & le baromètre de la lecture publique : avoir des métadonnées homogènes

25/04/2018

Comme annoncé, je commence mes retours d’expérience sur l’utilisation de Bibliostratus, en commençant par le plus ancien (automne-hiver).

Mes utilisations constituent à chaque fois un détournement de l’intention première du logiciel, puisque en bonne logique je n’ai pas vraiment besoin d’aligner « mes » données (de la BnF) avec les données de la BnF — quoique… (mais ce sera pour une autre fois.)

Le baromètre des prêts de la lecture publique

Depuis 2014, le Ministère de la Culture missionne un prestataire (en l’occurrence TMO Régions) pour dresser un panel des « meilleurs prêts » (c’est-à-dire des ouvrages les plus empruntés) dans les bibliothèques de lecture publique.

Le Ministère et le prestataires ont identifié un fournisseur de SIGB qui couvrait une assez grande diversité d’établissement, et qui s’occupe de l’extraction des bases de données : liste des prêts de l’année et métadonnées bibliographiques associées.

Les premières années, les analyses ont porté  sur quelques dizaines de bibliothèques, clientes de C3RB et utilisatrices de son logiciel Orphée. Plus récemment, l’étude s’est élargie à 146 (2016) puis 167 bibliothèques (2017), en incluant aussi des extractions venant d’instances Koha et Infor.

L’analyse 2016 a été mis en ligne fin avril 2017, je suppose que 2017 ne tardera plus.

<mise à jour du 27/04/2018>C’est en ligne — et un article de LivreHebdo s’en fait l’écho</mise à jour>

Problème 1 : le modèle de données

Le problème pour ce genre d’analyse, c’est (pour l’instant !) le modèle de données utilisé dans les catalogues de bibliothèques : une notice par ISBN, c’est à dire une notice par produit éditorial. Vous n’avez pas la possibilité de regrouper facilement plusieurs ISBN qui sont des rééditions d’une même oeuvre (dans différentes langues ou à travers le temps, chez différents éditeurs, etc.).

Dans l’idéal, il aurait fallu pouvoir disposer d’un catalogue FRBR dans lequel retrouver tous les ISBN extraits des 167 catalogues.

Mais bon, puisqu’on en n’est pas là, il faut le faire spécifiquement pour l’occasion : pour identifier les oeuvres (et non les livres) les plus empruntées au niveau national, il faut donc réaliser des regroupements par auteur identique & titre identique.

Oui mais…

Problème 2 : qualité des données

Si vous prenez 167 catalogues de bibliothèques différents, vous aurez des métadonnées très différentes — toutes de qualité, très certainement, mais toutes ayant fait des choix ou choisi des sources diverses : Electre, Moccam, BnF, catalogage local, Worldcat, dérivation + reprise, dérivation sans reprise, …

Donc les titres ne se ressemblent pas toujours :

  • Thorgal. Les mondes de Thorgal. Kriss de Valnor, 1
  • Kriss de Valnor, tome 1
  • Kriss de Valnor, Je n’oublie rien (1). Les mondes de Thorgal
  • Les mondes de Thorgal. Je n’oublie rien.
  • etc

Sans compter les problèmes d’accents, de majuscules, d’abréviations, d’initiales, etc.

TMO Régions a donc contacté le Département des métadonnées de la BnF pour voir s’il était possible d’avoir des métadonnées homogènes pour chacun des ISBN associé à au moins un prêt dans une bibliothèque.

La BnF, des métadonnées homogènes ?

Disons que le catalogue BnF a une histoire complexe, qui compose un joli patchwork ressemblant parfois à un lent processus de balkanisation.

Mais :

  • les prêts 2017 dans les bibliothèques publiques portent pour l’essentiel sur des ouvrages de moins de 20 ans, donc les règles de catalogage, même si elles évoluent un peu chaque année, ont généré sur cette période un ensemble plutôt cohérent
  • la base d’autorités est unique : donc au moins les noms d’auteur sont orthographiés de la même manière sur l’ensemble des notices bibliographiques

Méthodologie et remarques

Je ne vais pas vous décrire ici l’ensemble de la procédure suivie. J’en dégagerai quelques traits intéressants, et pour le détail je vous renvoie à ce document (PDF – 6 p.).

  • Le corpus comptait 150.000 ISBN (120.000 pour des prêts antérieurs à 2017, et 30.000 d’ISBN nouvellement apparus dans les prêts 2017).
  • Dans 94% des cas, un ARK BnF, ou à défaut un PPN (Sudoc) a pu être trouvé.
    Dans 3% des cas, plusieurs identifiants ont été trouvés.
  • la demande ne consistait finalement pas à faire un alignement propre : il fallait fournir des métadonnées fiables et homogènes pour chaque notice, si bien qu’il n’était pas indispensable d’identifier l’édition exacte correspondant au prêt initial avec certitude. Si la recherche par ISBN ne fonctionnait, une recherche simple « Titre+Auteur » suffisait au besoin.
  • il a fallu définir une stratégie, une méthode, pour obtenir le taux d’alignement le plus haut avec le moins de faux positifs possible. L’outil traite les données qu’on lui donne. Mais il réagit différemment si on lui donne beaucoup ou peu d’informations.
    Donc il faut vraiment prendre conscience de ce qu’il fait concrètement, même s’il le fait automatiquement. Pour l’essentiel, c’est décrit dans ce document (Word – 10 p.)
    (il est toujours possible d’être plus précis, mais que c’est long !).
  • Une utilisation par cycles (ou on refait passer plusieurs fois les « restes » du passage précédent) s’est révélée très intéressante

Conclusion

Ce fut une expérience très intéressante, pour tester la montée en charge du logiciel sur plusieurs dizaines de milliers de notices.

Concernant le taux de recouvrement avec le catalogue BnF + Sudoc, je ne sais pas s’il vous semble élevé ou frustrant (surtout que le recours au Sudoc n’est pas du tout marginal !). Il y a plusieurs explications (que je détaillerai une autre fois si ça vous intéresse) concernant l’absence d’ISBN d’ouvrages relevant manifestement du Dépôt légal (édités en France ou diffusés en France). Sachez qu’on y travaille — mais que trouver une solution satisfaisante pour tous types de cas de figure n’est pas simple !

Néanmoins, 97% de taux d’alignement en cumulant BnF et Sudoc, sachant que les deux sont engagés dans la Transition bibliographique et travaillent de concert, c’est très rassurant :

Cela signifie que quand une bibliothèque voudra aligner son catalogue avec la BnF, elle trouvera forcément des taux inférieurs.
Mais les documents réellement empruntés dans ces bibliothèques sont bel et bien référencés soit dans le catalogue BnF soit dans le Sudoc. Donc la FRBRisation couvrira bien la partie la plus vivante des collections.

Or c’est sur ces collections que les lecteurs feront des recherches dans les catalogues. La FRBRisation par les agences couvrira donc les fonds qui les intéressent. Et après tout, c’est pour eux qu’on fait tout ça ! #nelesoublionspas

La Transition bibliographique : Bibliostratus, un logiciel pour avancer ensemble

20/04/2018

Présentation

Le groupe Systèmes & Données du programme Transition bibliographique propose désormais aux bibliothèques un nouvel outil pour entrer de plein pied dans la Transition bibliographique : Bibliostratus (pour une Stratégie d’alignement des URIs).

Bibliostratus : menu d’accueil

Parce que c’est bien beau de suivre des formations, de faire de la veille sur le sujet, etc. Concrètement, on fait quoi ?

Alors justement, comme cela a été évoqué lors de la dernière journée Systèmes & Données, la démarche proposée est la suivante :

  • Les agences bibliographiques, l’Abes et la BnF, font du calcul de masse pour construire du LRM dans leurs catalogues (plus d’explications ici)
  • Les autres bibliothèques sont invitées à profiter de ces calculs

Le problème, si vous êtes une de ces « autres bibliothèques », c’est que vous ne savez pas forcément quelle notice de votre catalogue correspond à quelle notice BnF (pour l’Abes, cette question-là est plus facile : les SCD cataloguent dans le Sudoc donc leurs notices contiennent des PPN Sudoc).

Donc quand la BnF aura fini (si c’est jamais « fini »…) de LRMiser son catalogue : quand pour chaque « notice bibliographique » BnF, devenue entre temps manifestation, aura été associée une expression et une oeuvre (ou plusieurs) — comment saurez-vous ce qu’il faut récupérer ?

Pour le savoir, il vous faut aligner vos données avec celles de la BnF, c’est-à-dire réaliser cette identification, cette correspondance, entre vos notices et celles de la BnF. Rappel : si vous avez des FRBNF, ils ne sont pas assez fiables !

Donc plutôt que d’attendre la fin de la LRMisation du catalogue BnF, ce travail d’alignement peut être commencé dès aujourd’hui, pour injecter dans vos catalogues, soit les notices BnF complètes (en écrasant les vôtres), soit juste les ARK dans la zone adaptée.

Un chantier de ce genre a été présenté le 14 novembre, à travers l’exemple de la BM de Montpellier, la BnF et la BM de Montpellier ont collaboré pour définir une méthode et des outils pour réaliser cette opération d’alignement.

Copie d'écran : alignements en cours N° notice - ARK BnF

Copie d’écran : alignements en cours N° notice – ARK BnF

Et c’est aujourd’hui et dans les jours à venir que ces outils et cette méthode vont être proposés, à travers :

Doivent être publiées aussi prochainement des vidéos pour faciliter la prise en main.

Limites

Le logiciel n’est pas encore complètement débuggué. Il a tendance à croire que les données qu’on lui donne sont propres et fiables. Plus exactement : il les contrôle, mais tous les cas de figure aberrants n’ont pas encore été identifiés, de même que si l’utilisateur y met met n’importe quoi par manque de vigilance, Bibliostratus peut planter…

C’est pour ça qu’il y a un forum, notamment :

  • pour vous aider à comprendre les erreurs à ne pas commettre
  • pour nous aider à améliorer le logiciel

Questions de méthodes

Par ailleurs, Bibliostratus se contente de réaliser en algorithme des règles métier : il compare des métadonnées entre elles, celles qu’on lui donne (de votre catalogue) et celles qu’il trouve (de la BnF). Si ces métadonnées sont lacunaires ou fautives (d’un côté ou de l’autre), les alignements proposés sont peu fiables.

De même, si vous proposez une liste d’ISBN, c’est plus fiable qu’une liste de Titre-Auteur-Date. S’il y a tout ça, c’est mieux : le logiciel fera une recherche sur ISBN, et contrôlera ensuite que le titre et la date sont identiques. Donc selon la manière dont chaque alignement est obtenu (et le logiciel précise de quelle manière il est obtenu), les propositions seront plus ou moins fiables.

Il faut donc le considérer comme un facilitateur conçu pour gagner du temps, pas comme un outil magique 🙂

Et pour la suite ?

Outre les types d’informations que j’ai mentionnées plus haut et que vous trouverez soit sur Github soit sur le site Transition-bibliogaphique.fr, j’aurai l’occasion de revenir sur Bibliostratus ici-même pour vous raconter aussi comment moi-même j’en ai l’utilité — car si je n’ai a priori pas besoin d’aligner les données BnF avec les données BnF, pourtant je rencontre des situations où Bibliostratus peut se révéler très utile.

Et je me dis que ça pourra l’être aussi pour vous.

Donc on s’en reparle bientôt.

Pour les remarques, commentaires, problèmes, n’hésitez pas : c’est par là !

20-21 mars 2018 : Deux journées professionnelles sur les métadonnées

04/04/2018

Fin mars se sont tenues à la BnF deux journées professionnelles, dont les vidéos seront bientôt en ligne :

  • Le 20 mars : une journée sur la diffusion des données BnF, sous le titre « Quelles contributions de la BnF à la circulation des données ? »
  • Le 21 mars : un sommet ARK international

Photo @iladpo – Twitter

Je ne vais pas vous en faire un résumé (d’autant que j’ai malheureusement raté une partie de la seconde), mais dégager quelques points saillants.

Commençon par souligner que manifestement chacune répondait à une attente forte, pour différentes raisons.

Première présentation officielle du SRU BnF

Depuis son lancement à l’automne dernier, c’est la première présentation en auditorium du SRU de la BnF (c’est-quoi-un-sru). Il est encore tout jeune, et je pense qu’il va mettre du temps à trouver son public.

Les bibliothèques qui récupèrent les données de la BnF via le serveur Z39.50 disposent là d’un outil qui fonctionne et répond à leurs besoins actuels. Lui substituer le SRU pour faire la même chose revient pour l’instant à juste dépenser de l’argent (développements et implémentation prestataire) et du temps pour un service équivalent, alors que le Z39.50 ne s’arrêtera pas tout de suite. Donc il faut retenir plusieurs choses :

  • de nouveaux services peuvent être envisagés, et conçus bien plus facilement en se greffant sur un SRU qui utilise les technologies du web (HTTP, XML) qu’en allant chercher le Z39.50 (techno ancienne, inutilisée hors des bibliothèques).
    Il faut donc espérer que se constitue peu à peu un ensemble de retours d’expériences, et de partage de logiciels ou bibliothèques de fonctions, autour de cette base de données désormais accessible.
    A noter que ces services / outils peuvent être de type

    • synchrone : affichage en temps réel dans une interface web d’informations récupérées dynamiquement du SRU
    • asynchrone : fonction d’export et de récupération pour alimenter un fichier, une page web, une base de données
  • notamment, il y a des services/outils/plateformes à envisager qui combinent diverses sources, dont le SRU — mais aussi data.bnf.fr, Gallica, et des trucs hors BnF : ISTEX, un SRU Sudoc, etc.
  • Les bibliothèques doivent peu à peu (au gré des marchés de réinformatisation) demander un module d’import SRU plutôt que Z39.50 pour récupérer les notices BnF :
    • les critères de recherche sont plus nombreux, notamment sur les autorités
    • les limitations techniques (nombre de notices récupérables) sautent
    • le SRU n’est pas dépendant de l’iso2709 (format standard d’échange des notices en Marc),
      • qui ne permet pas de faire passer des notices trop longues
        (il faut qu’elles soient très longues : une zone peut avoir jusqu’à 10.000 caractères. Mais ça se trouve !)
      • qui est très contraignant et fragile : c’est illisible (cf. 3 notices Unimarc en iso2709), on rencontre toujours des problèmes sur les encodages, etc.

Astuce pour extraire une liste de notices en format Marc du SRU

Si vous avez une liste d’ISBN, ou une liste de numéros de notices : vous pouvez les chercher dans le catalogue public, bien sûr. Mais si vous voulez d’emblée regarder le formqat Marc des notices, vous pouvez copier-coller la liste des ISBN ou des n° de notices (ou ARK) dans le critère de recherche idoine

Ce qui vous permet d’afficher une liste de notices Marc
(plus rapide que de lancer une requête dans le catalogue, sélectionner les notices en haut de la liste, puis bouton « Voir la sélection »)

C’est ce genre de cas d’utilisation qu’il faut progressivement identifier pour être amenés à utiliser le SRU à bon escient, comme complément du catalogue et du serveur Z39.50.

De plus en plus d’ISNI

Il y a actuellement 1,8 millions de notices d’autorité Personnes dans le catalogue BnF. Dont 83% avec ISNI. Si l’ISNI est adopté par toute la chaîne du livre qui publie et diffuse la production éditoriale, le circuit de traitement des ouvrages en sera grandement facilité, y compris dans la manière dont le catalogage courant en FRBR pourra être mis en place.

Créer une nouvelle zone Marc, c’est facile ?

Mon passé d’administrateur de SIGB au SCD de Nice m’avait laissé complètement ignorant de la manière dont, dans de très nombreuses bibliothèques, la collaboration avec le prestataire SIGB se passe. A l’Abes comme à la BnF, comme dans un SCD, l’établissement est autonome sur l’évolution du format de catalogage : si une nouvelle zone s’avère nécessaire, l’administrateur SIG (ou catalogue) la configure dans le module de catalogage, on paramètre l’indexation, les facettes, l’affichage — et voilà.

Mais dans de très nombreuses bibliothèques la création d’une zone, et la configuration de l’outil pour l’exploiter, passe par une prestation.

Donc lorsque l’Abes crée la zone 219 pour le Sudoc (nouvelle zone Unimarc de date conforme à RDA-fr), les SCD l’intègrent sans trop de difficulté (du moins je le suppose — en tout cas je sais qu’à Nice ça n’aurait pas posé de problème particulier) ; la BnF suit le même choix parce que les agences collaborent — et en soi c’est une bonne chose. Sauf que les bibliothèques qui récupèrent les notices BnF ne sont pas comparable au bibliothèques universitaires. Et ce peut être compliqué que de choisir de payer une prestation au fournisseur du SIGB, pour un gain de service à peu près nul (si ce n’est pour éviter une non régression).

Data.bnf.fr a mis à jour son modèle de données

C’est la petite toilette de printemps annuelle.

Simplifications dans les URI du graphe

(pour voir directement les schémas, c’est sur la page Comprendre le modèle de données de data.bnf.fr)

Les URI ont été harmonisées : au lieu d’avoir des oeuvres en URI_ark#frbfr:Work, des personnes URI_ark#foaf:Person, des collectivités en URI_ark#foaf:Organization, tout est passé en #about.

Donc

  • les propriétés associées à la notice (date de création, date de dernière modification, lien au catalogue, FRBNF) sont associées à l’URI contenant l’ARK seul (exemple : http://data.bnf.fr/ark:/12148/cb13896861p)
  • les propriétés associées à la « chose », personne, oeuvre, etc. (titre, nom, date de création ou de naissance) sont associées à l’ARK#about (exemple : http://data.bnf.fr/ark:/12148/cb13896861p#about)
    Les URI #foaf:Person, #frbr:Work, etc. sont déclarées comme owl:sameAs l’URI#about, mais ne portent plus aucune propriété

Et on a pu supprimer la double URI #frbr:Expression et #Expression (jusque là, suite à un bug historique, le type d’expression, la langue et le lien à la manifestation étaient supportées par l’URI #Expression, tandis que les mentions de responsabilités étaient portées par l’URI #frbfr:Expression, les 2 étant reliées par un owl:sameAs).

Par exemple, avant, pour aller de l’ISBN au nom d’auteur, il fallait faire :

ISBN > manifestation > expression > frbr:expression 
          > auteur#about > auteur#foaf:Person > nom d'auteur

Désormais :

ISBN > manifestation > expression > auteur#about > nom d'auteur

Ce qui est plus logique et plus court.

Les anciennes URI restent valides, avec des owl:sameAs pour pouvoir continuer à les exploiter

Autres mises à jour

  • les ISBN sont décrits d’une manière plus souple :
    • les ISBN10 comme bnf-onto:isbn & bibo:isbn10
    • les ISBN13 comme bnf-onto:isbn & bibo:isbn13
      Il est donc possible de les distinguer, ou de les récupérer de manière indifférenciée
    • Par ailleurs, jusque là seul le 1er ISBN de la notice était récupéré. Ils le sont désormais tous.
  • Suite notamment au hackathon et au début de gros chantiers autour de Rameau, les alignements avec des référentiels extérieurs ont été enrichis.
    • les alignements avec les LCSH (vocabulaire de la Bibliothèque du Congrès) sont ceux validés un à un par les experts du centre Rameau, au lieu d’être calculés à la volée dans data.bnf.fr
    • Pour le domaine musical, on trouve de nouveaux alignements vers MusicBrainz depuis les auteurs (exemple : Mozart) ou les oeuvres (exemple : Let it be)
  • Et quand même : une amélioration notable des temps de réponse de l’interface (mais je ne dénoncerai personne)
  • un petit truc sympa : si vous prenez une notice bibliographique du catalogue (et que son auteur est dans data.bnf.fr) et si dans l’URL vous remplacez « catalogue.bnf.fr » par « data.bnf.fr », vous avez un beau fichier RDF/XML qui s’affiche.
    C’est un peu l’équivalent de l’extension « .rdf » dans les notices Sudoc

Plutôt que des identifiants pérennes, des identifiants gérés

La preuve que cette journée était bien concue : à l’issue de la présentation introductrice (présentation des principes et des concepts) par @SebPeyrard, les questions posées par l’assistance trouvaient systématiquement comme réponse : « Alors justement, ce sera approfondi à tel moment de cette journée — mais voici déjà quelques éléments ». C’est dire si le programme initial correspondait aux attentes de la salle !

Si vous n’avez pu participer à cette journée, vous avez donc tout intérêt à en guetter la rediffusion vidéo !

C’est une leçon essentielle de la journée ARK : les identifiants sont le premier service en ligne que nous devons rendre aux utilisateurs de nos ressources. Et si certaines ressources peuvent ne pas être pérennes (un document retiré pour raisons de droits, ou corruption de fichier, ou parce qu’on ne souhaite plus utiliser le concept décrit dans le référentiel des mots-matières), leurs identifiants doivent l’être.

D’ailleurs, il vaut mieux éviter de se donner un objectif de identifiants pérennes, qui a un goût d’éternité un peu angoissant. En revanche il faut se donner des moyens d’avoir des identifiants gérés.

Cela implique plusieurs choses :

  • un même identifiant ne doit pas servir à décrire successivement des choses différentes
  • si la ressource disparaît ou change d’endroit, l’identifiant doit demeurer
    • soit en fournissant une redirection (automatique ou pas) vers la ressource
    • soit en donnant des informations sur « ce qui s’est passée », ne serait-ce que « Ressource supprimée » — tout plutôt qu’une erreur 404
  • le fait de se préoccuper d’avoir des identifiants pérennes va de pair avec le projet d’une mise en ligne de ressources. Il n’est pas nécessaire d’avoir au niveau de l’établissement des missions patrimoniales, il n’est pas nécessaire que ce soit un gros projet ambitieux. Par contre il vaut mieux que ce soit fait proprement, et dès le début
  • la pérennité des identifiants permet de traverser plusieurs prestataires successifs au-delà de leurs solutions techniques et de leurs briques technologiques.
    Ce qui peut sembler une manière de les indifférencier, peut finalement être pour eux une manière de se distinguer, et devenir un critère de choix dans un appel d’offres. De même qu’en choisissant un SIGB qui vous permette à la fin d’un cycle d’exporter toutes vos données pour les réimporter dans un autre système  — et que vous ne choisiriez pas un SIGB qui ne propose pas de fonction d’extraction du catalogue et de la liste des prêts en cours !
  • quand on commence à envisager ces problèmes et à vouloir les résoudre, on rencontre assez vite ARK sur son chemin, comme un ensemble d’outils qui viennent accompagner la mise en place de solutions.

« Accompagner » n’est pas « résoudre ». L’outil n’est pas la solution. Il faut encore que l’établissement se dote d’une politique, qu’elle communique (en interne aussi !) sur cette politique. D’où ces préconisations de la BnF sur sa propre politique.

Théoriquement et techniquement, les ARK BnF ne peuvent désigner qu’une seule ressource. Mais techniquement rien n’empêche quelqu’un de récupérer une notice, de la vider et d’y décrire un autre document (ou une autre personne à la place). Drôle d’idée ? Pourtant ça se rencontre, et il y a toujours une « bonne raison ».

Ce qui prouve bien que l’enjeu sur les identifiants est avant tout une question de politique d’établissement, et de service rendu aux utilisateurs — avant d’être un problème technique.

De manière générale, au vu d’échanges, et de tweets, passés ces derniers mois, j’ai l’impression que beaucoup d’établissements se sentaient jusque là assez seuls, sans interlocuteurs ou partenaires identifiés, pour se poser les bonnes questions concernant leurs identifiants, et étaient contraints de tout redécouvrir individuellement. Cette journée est la première pierre dans la constitution d’une communauté professionnelle française/francophone. C’est une excellente nouvelle.

FRBRisation des imprimés français du XXe siècle

29/03/2018

Ceci est la suite du précédent billet.

Je re-précise tout de suite : on ne fait pas du vrai FRBR à ce stade. On identifie l’étape suivante pour avancer vers le modèle FRBR. Potentiellement, on découvre en cours de route que cette étape doit être précédée d’un certain nombre de choses — qu’on traite progressivement jusqu’à arriver au bout du projet. Puis on se donne un autre objectif.

Il y a deux raisons principales qui font qu’on ne peut pas convertir les notices concernées en FRBR pur :
(si on supposait que la normalisation est terminée, que le format de catalogage a été finalisé pour implémenter ce modèle, et que la manière d’alimenter ce format a été déterminée. Sinon ça en fait trois de plus)

  1. l’outil de catalogage n’est pas prévu pour, on ne saurait pas comment décrire, stocker, afficher, naviguer dans les entités créées
  2. les données sur lesquelles on travaille sont ce qu’elles sont

Les limites de l’environnement de travail

La BnF dispose de deux plateformes distinctes sur lesquelles (re)travailler ses données avec en vue le modèle FRBR : le catalogue, qui stocke les notices en (Inter)Marc, et data.bnf.fr, qui gère les données dans une base de données et les expose en RDF. Le catalogue alimente data.bnf.fr

Depuis 2011, data.bnf.fr s’efforce de « faire du FRBR » aussi bien que possible avec les données disponibles. Donc data.bnf.fr permet de tester des trucs en avance de phase, et quand c’est possible on les reverse ensuite dans le catalogue. Ce fut le cas de 185.000 liens entre notices bibliographiques (considérées comme autant de « manifestations ») et notice d’autorité Titre (considérées comme des « oeuvres ») ajoutés automatiquement, en plusieurs fois, depuis fin 2015.

Aujourd’hui dans le catalogue ne peuvent exister que deux types de notices :

  • les notices bibliographiques, décrivant les documents
  • les notices d’autorité, décrivant les autorités, notamment les auteurs Personnes physiques et organisations, ainsi que le vocabulaire Rameau

Parmi les notices d’autorité ont été créées plusieurs dizaines de milliers de « notices d’autorité Titre« , permettant notamment de faire de l’indexation matière pour dire que tel ouvrage est une étude sur Madame Bovary, par exemple. Si on veut créer davantage d’oeuvres (pour progresser dans l’implémentation du modèle FRBR), on peut donc créer davantage de notices d’autorité Titre et faire comme s’il s’agissait d’oeuvres au sens du modèle.

En revanche dans cette base de données du catalogue BnF rien ne permet de positionner correctement des Expressions. Or le modèle LRM les met finalement bien plus en valeur que l’oeuvre elle-même. Cela ne veut pas dire qu’on ne va rien faire (je parlerai des expressions dans un autre billet), mais qu’il sera impossible d’avoir des expressions dans le catalogue sauf à changer complètement d’outil et/ou de base de données.

Il est donc possible de travailler d’abord à la création automatique des oeuvres : parce qu’on peut expérimenter quelque chose dans data.bnf.fr et envisager ensuite de reverser le résultat (si satisfaisant) dans le catalogue.

Que veut dire « créer automatiquement des oeuvres »

Le principe consiste à identifier par algorithmes un ensemble de métadonnées comme permettant de décrire une même oeuvre.

Le mécanisme est le suivant, pour un auteur donné :

  • récupération de tous les titres dans les notices bibliographiques qui lui sont associées
  • regroupement des titres par similarité de chaîne de caractères
    (« Guerre et paix » de Tolstoï doit être associé à « La Guerre et la paix »)
  • évacuation des regroupements
    • qui contiennent déjà un lien vers une notice d’autorité Titre
      (il ne faudrait pas recréer une notice d’oeuvre Guerre et paix, ça ferait tâche)
    • qui contiennent des mélanges : agrégats, ou manifestations agrégatives, selon la terminologie LRM — toutes ces Oeuvres complètes qui peuplent abondamment le catalogue de la BnF et Gallica
      (là aussi, il serait risible qu’on révèle au monde que Balzac a écrit un chef-d’oeuvre inconnu, intitulé Oeuvres complètes)

L’outil de traitement : RobotDonnées

Ainsi que cela a été présenté le 14 novembre dernier, la BnF met ce projet en place en utilisant RobotDonnées, un outil qui exploite certains programmes développés dans le cadre du projet data.bnf.fr. Je réalise que dans le diaporama mis en ligne sur le site de la Transition bibliographique, toutes les copies d’écran se superposent (diapo 22) — toutes mes excuses !

Du coup voici, pour les diapos relatives à RobotDonnées, la version Google Drive, qui permet d’afficher les images une à une.

Un corpus pour démarrer : les imprimés français du XXe siècle

En réalité, outre le projet data.bnf.fr, la BnF a conduit ces dernières années une autre expérimentation de FRBRisation. Indépendamment de ce qu’il est advenu de l’aventure, le projet ReLire a bel et bien eu besoin de travailler au niveau des oeuvres, afin de constater que toutes les éditions successives sont épuisées.

L’équipe Analyses & Traitement des données a donc capitalisé sur l’expertise de l’équipe ReLire, et son utilisation de RobotDonnées, pour travailler sur les ouvrages imprimés des auteurs français du XXe siècle. On choisit donc :

  • une production pour laquelle la BnF est censée avoir l’exhaustivité, tant sur le plan géographique que chronologique
  • une langue stable, qui évite les évolutions de graphie des termes
  • des données propres
    … ou pas ?

Les données manipulées

RobotDonnées prend en entrée une liste d’auteurs. L’idée est, pour ces auteurs, d’extraire les formes de titres, de regrouper les formes identiques et de générer des oeuvres.

Un deuxième projet s’est greffé là-dessus : pour les éditions agrégeant plusieurs oeuvres, voir s’il était possible de lier la forme de titre à une notice d’oeuvre pré-existante — à condition que dans la notice bibliographique on puisse correctement associer la forme de titre avec son auteur (soit parce qu’il y a un seul auteur mentionné dans toute la notice, soit parce que la notice est suffisamment structurée pour éviter tout risque de confusion).

Or ce sont les mêmes auteurs dont les oeuvres sont publiées tantôt sous forme d’agrégats, tantôt sous forme de monographies.

Donc une première extraction des formes de titres a permis de sortir tout ce qui était suffisamment structuré pour considérer que le titre en question était bien associé à l’auteur en entrée

Pour tout ça, on est évidemment tributaire des données du catalogue.

Suivant ce processus, il faut éviter de faire croire que Pagnol a écrit une oeuvre intitulée « César, Marius, Fanny »

Nous menons donc un double travail :

  • affiner les paramétrages pour que ce qui sort des traitements automatiques soient propres (ou à peu près)
  • identifier des chantiers de reprise et de correction des données : dans les cas où la correction peut être appliquée en masse, rendre les notices plus conformes aux consignes de catalogage actuelles (sans les rendre parfaites pour autant), et améliorer les notices d’oeuvres produites par RobotDonnées
    Parmi ces chantiers :

    • l’attribution d’une date en zone codée, lorsque celle-ci était présente ailleurs dans la notice
      (pour calculer la date de création de l’oeuvre à partir de sa manifestation la plus ancienne)
    • le nettoyage des zones de titres structurées ainsi :
      Nom d’auteur. Titre d’ouvrage
      Ce genre de pratique n’est pas gênante pour accéder au document. Mais on ne va pas mettre dans data.bnf.fr qu’Emile Zola a écrit « Emile Zola. L’assommoir ».
    • la correction des rôles indéterminés : il y a dans data.bnf.fr près de 200.000 expressions liées à leurs auteurs par un rôle indéterminé. Ce qui, avec les codes de langues, va se révéler gênant quand on voudra travailler sur les expressions.
    • le nettoyage des notices analytiques (ou sous-notices, dont le rôle est d’assurer le dépouillement du contenu d’un ouvrage quand on le juge utile) quand elles signalent des « préfaces »
      Cette information doit être convertie en rôle « préfacier » au niveau de la notice principale, pour éviter de créer des milliers d’oeuvres intitulées « Préface », « Introduction », etc.

Calendrier et volumétrie ?

M’avancerai-je sur un calendrier ? Disons que vous devriez trouver des oeuvres « calculées automatiquement » dans data.bnf.fr courant 2018, pas mal de choses sont en bonne voie. La bonne nouvelle est que la phase « Regroupement par formes de titres » a déjà été réalisée pour 100.000 auteurs.

Sur la volumétrie, c’est encore plus compliqué : on part sur un ensemble de 400.000 auteurs. A partir de là, on ignore encore :

  • combien chacun a publié de livres
  • combien d’oeuvres (regroupements de formes de titres) pourront être identifiées
  • combien de regroupements contiendront des agrégats (pour lesquels ils ne sera donc pas encore possible de calculer des métadonnées d’oeuvres)

Donc il n’est pas vraiment possible d’identifier encore le nombre d’oeuvres qui seront ainsi générés dans le cadre de ce chantier.

Et ensuite ?

Quand on aura fait tout ça et que tout le monde 95% de tout-le-monde sera content du résultat, on pourra aller un cran plus loin :

  • corpus d’autres périodes
  • corpus autres que textuels
  • injection des données dans le catalogue
  • expérimentations sur les expressions
  • articulations avec les notices de regroupements générées dans le Sudoc (voire d’autres réservoirs)
  • et il sera prochainement question aussi de la manière dont d’autres bibliothèques pourront plus facilement récupérer tout ce travail (dans la continuité de cette présentation)

Préparer la FRBRisation, c’est déjà FRBRiser

27/03/2018

Depuis cette expression mémorable concernant le grand soir catalographique (ou plutôt son absence) pour les bibliothèques, on a toujours l’impression d’aller vers le modèle FRBR , ou — pire — de l’attendre. Mais on n’a jamais vraiment l’impression d’être en train de FRBRiser. Tout ne semble que prémisses à la vraie FRBRisation qui viendra un jour.

Pourtant il faut avoir l’audace de s’y résoudre : il n’existe pas d’étape de pré-FRBRisation, puisque par principe la Transition bibliographique consiste à avancer progressivement vers l’horizon LRM. Donc ce que nous réalisons aujourd’hui, ce n’est pas encore du FRBR, mais c’est déjà de la FRBRisation

Photo FlickR de Lee Varis – CC-BY-NC-ND-2.0

« Ce que nous faisons aujourd’hui », à la BnF, a été présenté pour partie à la journée Systèmes & Données du 14 novembre 2017. Il est convenu que les deux agences nationales ont nécessairement un rôle à jouer différent des autres structures — et je reviendrai une autre fois sur les étapes plus spécifiques aux bibliothèques de lecture publique.

Pour le moment, je vais me contenter de parler un peu de ce qui se passe à la BnF — et j’espère avoir le courage et le temps d’en faire plusieurs billets.

Le passage progressif à un nouveau modèle de données

Il y a plusieurs actions, à différents niveaux, qui font converger la BnF vers le modèle LRM. Parmi ceux-ci, citons :

  • normalisation : la participation aux lieux d’échanges internationaux et nationaux sur la normalisation, la définition même du modèle à implémenter
  • évolution du format de catalogage : la définition de la trajectoire du format de catalogage (Intermarc à la BnF, qui lui est propre et qu’elle peut donc choisir de modeler selon ses besoins, mais en anticipant aussi les besoins des réutilisateurs de ses données, qui pour la plupart récupère une version Unimarc de ses notices)
  • évolution des règles de catalogage : L’injection progressive du code de catalogage RDA-fr en règles de catalogage pour les diverses voies d’entrée des documents dans les collections.
    Du fait des spécificités, de l’organisation, des missions, de la taille des différentes équipes qui alimentent le catalogue de la BnF, il faut nécessairement définir des règles spécifiques (qui sont parfois identiques, parfois non) pour :

    • le Dépôt légal : exigence de qualité mais aussi de rapidité dans la perspective du CBU, volumétries croissantes et effectifs constants. A chaque nouvelle règle de catalogage envisagée, il faut multiplier la consigne par 80.000 notices et se demander dans quelle mesure cette nouvelle règle aura un impact sur les délais de mise à disposition des métadonnées.
    • les acquisitions (étrangères) : l’exigence de qualité est moindre, puisqu’on dérive les notices de Worldcat pour les acquisitions étrangères, et que la BnF n’est pas bibliothèque de référence pour les métadonnées hors domaine français. Néanmoins il faut veiller à la cohérence globale du catalogue (sinon des outils aussi utiles que les critères de recherche ou les facettes du catalogue en ligne n’ont plus de raison d’être)
    • le rétrospectif (catalogage / corrections) : étant donné la stratification du catalogue, les différents canaux par lesquels sont arrivés les actuelles 13 millions de notices bibliographiques, celles-ci sont pleines de problèmes qu’il n’est pas possible de laisser en l’état
  • évolution de l’outil de catalogage : celui actuellement utilisé a permis et permet toujours de travailler en articulant notices bibliographiques et notices d’autorité.
    Il n’est pas adapté à un catalogage nativement LRM, qui est l’objectif à atteindre. Il faut donc faire évoluer l’outil lui-même (ou en changer).

A présent que sont posées ces différentes dimensions, je reviendrai dans un prochain billet sur la partie qui m’intéresse le plus, parce qu’elle relève en grande partie du traitement des données (automatisé ou pas) : comment FRBRiser rapidement 13 millions de notices ?

[spoiler] On commence par le plus simple !

Extraire des données du catalogue de la BnF : un petit logiciel

30/10/2017

Voir le précédent billet sur l’ouverture du SRU (web service du catalogue de la BnF) la semaine dernière.

Je vous partage à présent un petit programme permettant d’extraire assez facilement des informations du catalogue de la BnF. Je reviendrai ultérieurement sur le making-of de ce programme : pour l’instant c’est juste le mode d’emploi.

Installation du programme ExtractionCatalogueBnF

  1. Récupérer le fichier .ZIP
    (sur Github : à simplement télécharger sur votre PC.)
  2. Dézipper le fichier où vous voulez : il crée un répertoire ExtractionCatalogueBnF, contenant
    • 1 répertoire exe (avec tout le programme)
    • 1 fichier ExtractionCatalogueBnF (qui n’est qu’un raccourci vers l’exécutable situé dans le répertoire exe)

Utilisation du programme

Quand on double-clique sur le fichier ExtractionCatalogueBnF, une fenêtre s’ouvre :

(màj 02/11/2017 : nouvelle mise en forme)

ExtractionCatalogueBnF - formulaire

Dans la moitié gauche : les donnés en entrée, avec au choix :

  • une URL de requête SRU BnF
    sous la forme : http://catalogue.bnf.fr/api/SRU?version=1.2&operation=searchRetrieve&query=bib.title%20all%20%22recherche%20temps%20perdu%20retrouve%22%20and%20bib.author%20all%20%22proust%22&recordSchema=unimarcxchange&maximumRecords=10&startRecord=1
    Logiquement, à partir du formulaire de recherche SRU BnF et de la documentation fournie, vous ne devriez pas avoir trop de mal à lancer une requête et récupérer une première liste de résultats au format XML. C’est après, pour savoir quoi faire de ces résultats, que ça se gâte. D’où ce logiciel.
  • OU un fichier pouvant contenir plusieurs colonnes (séparées par des tabulations), mais dont la première doit être un numéro de notice (sur 8 chiffres) ou un ARK BnF (sous la forme ark:/12148/cb403064476)
    Ce fichier a pu être obtenu comme étant le rapport d’une précédente requête, ou encore via une extraction du triple store de data.bnf.fr, ou par tout autre moyen.
    Attention : pas de guillemets pour encadrer les valeurs de chaque colonne
    Il faut préciser le chemin d’accès complet au fichier (arborescence des répertoires + nom du fichier avec son extension)

    • Si on a donné en entrée un nom de fichier
      il faut préciser quel format en sortie on veut utiliser pour indiquer les éléments d’information à récupérer : si je dis au programme récupérer la zone 100, celle-ci n’est pas la même en Unimarc (zone de données codées) et Intermarc (auteur principal)
      Cette information en revanche n’est pas utile si on copie-colle l’URL d’une requête SRU : l’information est déjà dans l’URL

Dans la moitié droite : les données en sortie

  • La liste des éléments d’information à récupérer :
    • Pour les formats Marc : nom des zones et/ou sous-zones.
      Si vous indiquez une zone, il précisera chaque sous-zone par son dollar. L’ensemble de la zone sera dans une colonne
      Si vous indiquez une sous-zone, le $ ne sera rappelé que dans le nom de la colonne
      Vous pouvez mélanger tout ça et mettre par exemple :
      200;200$a;200$e$i
      Ce qui vous permettra d’avoir une colonne avec l’ensemble de la zone 200 (zone de titre, en Unimarc), mais aussi dans une colonne à part la 200$a, et encore à côté les compléments éventuels du titre
    • Si vous avez choisi Dublin Core : indiquez simplement le nom des balises à récupérer :
      dc:identifier;dc:title;dc:creator
      Si certaines informations sont répétées, elles seront dans la même colonne, séparées par un ~
  • Si vous voulez extraire des informations concernant des notices d’autorité, vous pouvez récupérer le nombre de notices bibliographiques liées à chacune des notices, en cochant la case idoine
    C’est une information qui, dans l’interface web du catalogue, est indiquée en bas à droite des notices d’autorité. Dans ce programme, elle mélange les notices liées comme auteur et comme sujet
  • Le nom du fichier rapport qui contiendra les informations extraites
    Ce fichier sera déposé dans un répertoire reports directement dans le répertoire ExtractionCatalogueBnF

Attention : il faut que les données en entrée soient en cohérence avec les éléments d’information demandées en sortie

  • Si vous avez mis une URL du SRU en entrée, le format XML doit correspondre aux zones que vous demandez en sortie (si vous affichez de l’Unimarc, vous ne pourrez pas demander à récupérer les « dc:title »)
  • Si vous avez indiqué un fichier en sortie et choisi le format Dublin Core, vous ne pouvez pas demander à récupérer le 200$a

Attention

On sait que l’extraction est terminée quand…

Le formulaire se ferme

Limites

Pas de gestion des erreurs

Ce programme est un dérivé de celui que j’utilise depuis pas mal de temps, avec quelques ajustements. Ce qui veut dire que comme je sais comment m’en servir, je n’ai pas envisagé tous les cas problématiques, si on renseigne mal le formulaire.

Par exemple, si dans le champ « Zones » vous terminez par un point-virgule et non pas un élément d’information, ça va sans doute planter

Les diacritiques sautent

<mise à jour>A partir de la version 0.4 (04/11/2017), les accents sont préservés</mise à jour>

L’encodage dans Python, c’est un truc de oufs. Et comme j’avais besoin d’avancer, et que j’en avais marre de tomber de temps en temps sur une notice qui faisait tout planter (parce que s’y planquait un caractère non-conforme UTF-8), j’utilise la librairie Unidecode qui vire tous les diacritiques. Du coup utiliser ces extractions pour faire des belles références bibliographiques, par exemple, est juste impossible.

Pas d’upload pour l’option de fichier en entrée

Je peine à utiliser les fonctions de filedialog dans la librairie Tkinter. De manière générale, j’ai une utilisation laborieuse de cette boîte de dialogue. Donc elle n’est vraiment pas belle — et est tout juste fonctionnelle.

Ce qui me laisse une large marge de progression.

Pas de versioning

<mise à jour>Gestion des mises à jour : désormais (à partir de la version 0.4) un bouton apparaît quand il y a une version plus récente à télécharger</mise à jour>

Comme quoi c’est du bricolage : je ne sais toujours pas utiliser correctement Git ou Github (ou Tortoise ou autre chose). Donc je ne fais pas de versioning propre. Et je n’ai pas non plus de dispositif satisfaisant pour que les versions ultérieures de l’exécutable soient rangées sous une URL stable. Pour ça, je ne désespère pas.

Remarque sur les fichiers en entrée et les rapports

Le programme produit un fichier texte avec des colonnes séparées par des tabulations. Le moyen le plus simple de l’exploiter est encore de l’ouvrir avec le bloc-notes (ou autre éditeur de texte brut — pas Word) et de copier-coller son contenu dans Excel

  • Ctrl+A (sélectionner tout)
  • Ctrl+C (copier)
  • [dans Excel] Ctrl+V (coller

De même, si vous avez un fichier Excel contenant en première colonne des numéros de notice BnF, il vous suffit de copier-coller son contenu dans le bloc-notes pour obtenir un fichier qu’ExtractionCatalogueBnF puisse traiter. Attention : au moment d’enregistrer le fichier, penser à préciser qu’il est encodé en UTF-8 (sinon c’est de l’ANSI par défaut, et ça risque de faire planter le programme).

Rappel

Ce logiciel n’est pas un produit officiel de la BnF. Si j’y travaille (pour mon plus grand bonheur), j’ai développé ce programme hors de mon temps de travail, et à titre « officieux » : aucune pérennité ni efficacité du truc n’est garantie, vous êtes priés d’en faire usage avec prudence (mais tout retour sera la bienvenue). J’ai découvert plein de trucs tout au long de la conception du programme, le code s’en ressent fortement, ce n’est pas quelque chose qu’on pourrait diffuser comme ça à titre institutionnel.

Mais ça me rend déjà des services — donc je me dis que ça peut vous en rendre aussi ! Par ailleurs, ça permet à quiconque le souhaite de développer des améliorations (et il y a de quoi faire !)