Skip to content

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à !

Publicités

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 !)

« Papa, c’est quoi un SRU ? »

27/10/2017

Il faut vraiment que j’arrête de parler boulot à table… Quoiqu’il en soit, j’ai lâchement botté en touche et épargné l’explication à mon fils, mais je ne vous l’épargnerai pas (je me sentirai certainement mieux après).

Z39.50 + web = SRU ?

Les premières fois (et pendant des années) que j’ai entendu parler de « SRU/SRW », c’était systématiquement pour entendre : SRU, c’est comme Z39.50, mais sur le web.

Ce n’est pas faux. Mais c’est un discours pour bibliothécaires : on part des concepts qu’ils maîtrisent, et on fournit les ajustements nécessaires à la compréhension.

Quand je dis « concepts qu’ils maîtrisent », je veux dire que la plupart des bibliothécaires voient bien l’utilisation qui peut être faite de Z39.50 : une recherche fédérée, ou une fonction d’import de notices venues de l’extérieur au sein d’un SIGB. Mais je ne suis pas sûr que qu’un aussi grand nombre de collègues serait en mesure de décrire l’architecture client-serveur, énoncer que Z39.50 est un protocole, et est également une API. (Si je m’égare sur les compétences techniques des collègues, n’hésitez pas à râler : ça m’intéresse réellement de savoir à quoi m’en tenir sur la culture générale professionnelle technique normale dans la profession aujourd’hui).

Ce n’est pas faux, donc, mais ça ne me plaît pas. Parce que justement, nous devons apprendre à raisonner avec les concepts du web, maîtriser avant tout les technologies développées par d’autres, et s’intégrer dans une communauté plus large des développeurs, responsables de services en ligne et diffuseurs de (méta)données.

Et d’ailleurs, si on veut diffuser nos données, il faut expliquer ce qu’est le SRU à d’autres professions. Si on les force à passer par le concept « Z39.50 » pour ensuite aller au SRU, c’est mort.

Donc je propose de renverser la logique : le SRU, c’est un web service standardisé adapté aux besoins des catalogues de bibliothèques.

Le SRU, c’est un web service

Je ne vais pas refaire une explication longue sur ce que sont les web services.

L’objectif des web services est de fournir à des applications les données enfermées dans une base de données, sans les dé-sémantiser en ne fournissant que du HTML.

On va donc proposer les mêmes informations, mais diffusées à la fois dans son site web en HTML, et sous forme d’API en JSON ou en XML (le plus souvent)

Et même, pour faire les choses plus proprement, il est préférable que la vue HTML exploite elle aussi l’API (avec besoin du coup d’une API interne, et d’une API différente pour exposer les données à destination d’utilisateurs extérieurs).

De la sorte, quand on doit refondre la base de données (changer de logiciel de SGBD, par exemple), il n’y a qu’une seule application qui attaque directement cette base de données, et c’est cette API-là seulement qu’il faut refaire.

Bref, un SRU, c’est un web service.

(petit rappel sur la différence entre API et web service : tout web service est une API. Mais parmi les API, seules celles qui passent sur le web, en HTTP, sont des web services. Z39.50 est une API, puisqu’elle permet à deux programmes d’échanger des données et des commandes, mais ce n’est pas un web service puisque ce protocole se passe en dehors du web)

SRU est un web service standardisé

Les bibliothèques sont une belle et large communauté. Et c’est une de ses forces que quand l’une d’entre elles a une idée ou un besoin, elle se demande si d’autres n’ont pas eu l’idée ou le besoin auparavant. Et proposer son catalogue sous forme de web service, pour faciliter la récupération et l’exploitation des métadonnées qui sont dedans.

Je ne vous refais pas l’histoire de SRU (que, en gros, j’ignore). Mais des bibliothèques se sont mises d’accord pour définir une manière standardisée (çàd identique) de proposer leur catalogue en web service.

Si vous voulez un contre-exemple : DoMyBiblio.net propose un web service pour interroger le Sudoc. Son développeur  @YvesTomic (qui a fait un boulot formidable, n’y voyez aucune critique : sa plate-forme est extrêmement utile) a choisi lui-même les noms à donner aux balises qui encadrent les éléments d’information.

Le standard SRU précise la manière dont on peut interroger le serveur qui expose les données du catalogue (en ce sens, SRU est un protocole puisqu’il définit comment faire dialoguer des machines, un client et un serveur). Il précise notamment :

  • qu’il faut un fichier « Explain » en plus de l’interrogation proprement dite du catalogue.
    Ce fichier Explain liste les formats de récupération, les critères de recherche disponibles et leur signification
    Cf. le fichier Explain du SRU de la BnF
    Cela peut sembler un gadget, ou un bonus, mais ça signifie que le mécanisme du SRU est autodocumenté : on peut bien sûr fournir la liste des critères de recherche sur une page web, ou dans un beau fichier PDF. Mais on expose aussi ces informations d’une manière accessible à un ordinateur, qui peut les extraire et les manipuler.
  • qu’il faut encapsuler les notices du catalogue de métadonnées « de gestion » : rappel de la requête, mention du nombre de résultats global, format d’exposition des données
  • qu’on peut ajouter des informations sur la notice extérieures à la notice elle-même : par exemple sa date de création ou de dernière modification, si cette information ne se trouve pas déjà à l’intérieur de la notice.

Le protocole SRU précise aussi la manière de paginer les résultats : on n’indique pas le numéro de la page, mais le numéro de la première notice apparaissant sur la page (&startRecord=100).

Le format des données

SRU laisse libre la manière de diffuser ses métadonnées : il précise juste que ces métadonnées sont encapsulées dans des balises <srw:record>…</srw:record>.

On peut donc diffuser du Marc, mais aussi du Dublin Core, de l’EAD, etc. en l’encapsulant dans ces balises <srw:…>

Voici l’arbre XML qui structure une page de résultats type.

SRU ne dit en réalité pas grand chose de ce qu’il y a à l’intérieur de srw:recordData (la partie verte du schéma, qui correspond ici à une notice en MARC mise en XML). D’un côté, ça ajoute de la souplesse et permet d’y mettre toutes sortes de formats. D’un autre côté, ça veut dire qu’on doit documenter hors SRU la liste des différents éléments d’information d’un format MARC : un programme qui tombe sur une zone 300$a (en XML, ce sera <datafield tag="300" ind1=" " ind2=" "><subfield code="a">...</subfield></datafield>) ne peut pas récupérer facilement la signification (le libellé correspondant, la définition) de cet élément d’information.

Le SRU de la BnF ouvre !

Tout ça pour dire que désormais, le catalogue de la BnF, et toutes ses métadonnées, est désormais accessible via SRU, avec la documentation nécessaire, un formulaire de recherche pour faciliter la découverte et la prise en main de la chose — et même une petite feuille de style pour ceux que le XML effraierait (case à cocher en bas du formulaire).

Et moi, je vous présenterai dans un prochain billet un petit outil pour extraire facilement en CSV des données du catalogue, adossé au SRU.

Ce qui permettra de répondre en partie à la question que vous vous posez tous si vous êtes arrivez aussi loin dans la page : « Qu’est-ce que je peux bien faire avec ça ? »

Ce que data.bnf.fr m’apprend de Lully (2)

24/10/2017

Après le premier billet qui s’intéressait surtout au compositeur (quoique en l’effleurant seulement), voyons un peu les oeuvres. A ce stade, je connais le modèle de data.bnf.fr (vous aussi ?), mais pas forcément quelles propriétés (et utilisées avec quelle fréquence ? avec quelles valeurs ?) sont associées aux entités Oeuvre, Expression, Manifestation — sachant que toutes les métadonnées des notices du catalogue ne sont pas reportées dans data.bnf.fr, mais que d’autres sont ajoutées (et notamment des alignements vers d’autres bases, il faudra bien y venir).

Bref, faisons le point.

La requête suivante permet d’extraire les propriétés appliquées aux manifestations, expressions et oeuvres attribuées à Lully

DEFINE input:same-as "yes"
PREFIX rdarelationships: <http://rdvocab.info/RDARelationshipsWEMI/&gt;
PREFIX dcterms: <http://purl.org/dc/terms/&gt;
PREFIX bnf-onto: <http://data.bnf.fr/ontology/bnf-onto/&gt;
PREFIX skos: <http://www.w3.org/2004/02/skos/core#&gt;
PREFIX foaf: <http://xmlns.com/foaf/0.1/&gt;
select ?typeEntite ?propEntite (count(?propEntite) as ?OccurrencesProprietes)
where {
{?entite ?role <http://data.bnf.fr/ark:/12148/cb13898799k#about&gt;.
?entite ?propEntite ?valEntite.
?entite a ?typeEntite.}
UNION
{?expression ?role <http://data.bnf.fr/ark:/12148/cb13898799k#about&gt;.
?entite rdarelationships:manifestationExpressed ?expression.
}
}
ORDER BY ?typeEntite, ?propEntite

Ca fait pas mal de propriétés distinctes :

  • Manifestations : 24
  • Expressions : 176
    Les rôles sont répétés selon différentes ontologies, et rien qu’avec l’ontologie bnf-roles, on a 119 propriétés différentes
  • Oeuvres : 20

Les manifestations

Liste des propriétés, par ordre décroissant d’occurrences

dcterms:subject 808
dcterms:title 238

rdarelationsships:expressionManifested
238

rdf:type
238

rdfs:seeAlso
238
owl:sameAs 238

bnf-onto:FRBNF
237

dcterms:description
235
dcterms:date 234

dcterms:publisher
217

bnf-onto:firstYear
209

rdavocab:dateOfPublicationManifestation
209
rdavocab:note 190

rdavocab:placeOfPublication
173

rdavocab:publishersName
170

rdarelationships:electronicReproduction
55

bnf-onto:isbn
35

Il n’y a apparemment pas de propriété qui permette d’identifier les oeuvres spécifiquement musicales — mais en fait si : cette information peut se retrouver en indexation Sujet.

Voilà une autre requête qui récupère l’indexation Sujet associée aux documents dont Lully est l’auteur.

Et si on récupère les indexations les plus fréquentes…

sujet sujetLibelle OccurrencesSujet

http://data.bnf.fr/ark:/12148/cb11976032c
« 18e siècle »@fr 425

http://data.bnf.fr/ark:/12148/cb119329384
« Partitions »@fr 241

http://data.bnf.fr/ark:/12148/cb11976227b
« Opéras »@fr 138

http://data.bnf.fr/ark:/12148/cb146484776
« Opéras-ballets »@fr 118

http://data.bnf.fr/ark:/12148/cb12215119w
« Parties »@fr 77

http://data.bnf.fr/ark:/12148/cb13601444k
« Arrangements »@fr 62

http://data.bnf.fr/ark:/12148/cb12215082c
« Extraits »@fr 57

http://data.bnf.fr/ark:/12148/cb11976232x
« Ouvrages avant 1800″@fr 44

http://data.bnf.fr/ark:/12148/cb124905429
« Partitions et parties »@fr 43

http://data.bnf.fr/ark:/12148/cb11960516v
« Solfège »@fr 37

http://data.bnf.fr/ark:/12148/cb12111871s
« Clavecin, Musique de »@fr 35

http://data.bnf.fr/ark:/12148/cb12490452b
« Réductions chant et piano »@fr 32

http://data.bnf.fr/ark:/12148/cb121516267
« Motets »@fr 30

http://data.bnf.fr/ark:/12148/cb11975995h
« 20e siècle »@fr 28

http://data.bnf.fr/ark:/12148/cb11975999w
« 19e siècle »@fr 27

http://data.bnf.fr/ark:/12148/cb122150931
« Airs d’opéra »@fr 26

http://data.bnf.fr/ark:/12148/cb119604900
« Piano, Musique de »@fr 20

http://data.bnf.fr/ark:/12148/cb11948111j
« Harmonie (musique) »@fr 16

http://data.bnf.fr/ark:/12148/cb11975998j
« 17e siècle »@fr 15

http://data.bnf.fr/ark:/12148/cb133183660
« Musique »@fr 14

… on voit bien que ce n’est justement pas une indexation : c’est une catégorisation de genre ou de forme. Dans certains cas, on peut même identifier qu’il s’agit de partitions, et non d’enregistrements.

En revanche l’inverse n’est pas possible : il n’y a pas d’information Ceci est un enregistrement sonore dans l’indexation.  Passons justement aux expressions.

Les expressions

La propriété dcterms:type est celle qui nous intéresse pour ça : concernant les documents liés à Lully, elle peut prendre 4 valeurs (codées selon le référentiel dcmitype) :

  • Text
  • Sound
  • MovingImage
  • InteractiveResource

Et selon la volumétrie suivante (l’information de décennie est extraite de la date, elle-même liée non à l’expression mais à la manifestation)

Les oeuvres

Presque toutes les oeuvres de Lully recensées dans data.bnf.fr sont typées, avec une propriété <http://musicontology.com/genre&gt;

Ce qui nous donne la liste des genres musicaux suivants

On peut donc à présent croiser tout ça

(toujours en se limitant à Lully)

Evidemment, on reste dans tous ces cas tributaire de la manière dont les données d’origine ont été renseignées : par exemple, si la mention de « partition » a été indiquée en zone 258*, mais pas en indexation sujet (subdivision « genre/forme »), on est cuit…

Une petite astuce pour finir (au cas où)

Si jamais vous ne savez pas comment facilement récupérer la requête Sparql qui se « cache » dans l’URL des liens auxquels je renvoie : il vous suffit de copier-coller cette URL sur le site URL Decoder/Encoder.

Pour la fois suivante, on parlera de croisement avec d’autres API (élargissement à d’autres sources). Ou alors d’identifier les compositeurs ou musiciens dans data.bnf.fr (élargissement à d’autres personnes).

———-

*Si vous vous demandez à quoi sert la zone 258 : vous pouvez utiliser cette page. C’est un pense-bête. Vous n’aurez pas accès à la documentation détaillée (bouton « Ouvrir la page »), mais en saisissant le nom d’une zone ou d’une sous-zone Intermarc ça vous fournit son libellé (et réciproquement). C’est déjà pas mal…
Cela dit, concernant spécifiquement la 258, vous avez peut-être raté ce billet 🙂