Accueil > Contributions > Explorer le catalogue des bibliothèques de Rennes Métropole

Explorer le catalogue des bibliothèques de Rennes Métropole

Dans un précédent article, j’ai pu poser quelques bases pour enclencher la relation avec un acteur public dans le cadre de l’Open Data. Passons à présent à un peu de technique.

Sources de données

La première chose fut de déterminer ce sur quoi je pourrais travailler et comment y accéder. Rennes Métropole utilise depuis longtemps un SIGB tout-en-un. Ce logiciel gère à la fois le catalogue et la gestion des prêts. Nous souhaitions accéder au catalogue afin d’offrir à termes une API facilitant l’accès aux données du réseau des bibliothèques de Rennes Métropole.

Nous avons rapidement déchanté, non pas que l’accès aux données soit impossible, mais le seul point d’entrée du catalogue est son moteur de recherche public. En effet, aucun point d’accès programmatique déjà proposé par le SIGB. Ou plutôt si, mais il s’agit d’une option payante et donc d’un investissement dont les services des bibliothèques de Rennes Métropole n’ont jamais eu besoin.

Heureusement, ces mêmes services nous ont offert un beau soutient et fourni leur accord pour exploiter le catalogue via le moteur de recherche.

Au pied de la montagne

L’intérêt d’une API est qu’elle cible les machines plutôt que les humains. Par conséquent, elle n’expose que l’essentiel et, en principe, de manière structurée ce qui facilite grandement le travail d’exploration de la donnée de manière automatisée. A contrario, le moteur de recherche lui cible les humains et se soucie assez peu d’une systématisation de l’exploration.

Mon point de départ était donc celui-ci :

Page d'accueil du moteur de recherche

Page d’accueil du moteur de recherche

La première approche, naïve, fut de chercher toutes les oeuvres commençant par la lettre a puis par b, etc. Deux difficultés sont immédiatement apparues :

  • Débuter par des lettres et des chiffres serait il suffisant pour extraire l’ensemble des oeuvres ?
  • Le moteur de recherche limite le nombre de résultats à 32000 lors d’une recherche aussi large

Un affinage était nécessaire mais sans complexifier la tâche. J’ai donc décidé de chercher par auteur en tablant sur le fait qu’il pouvait facilement y avoir plus de 32000 oeuvres débutant par un motif donné, mais probablement pas 32000 auteurs. Par ailleurs, comme un auteur amène par lien hypertexte à ses oeuvres, je retombais sur mes pattes. L’indirection présente un coût de traitement comme je l’expliquerai plus loin mais se révèle simple à mettre en place. Par ailleurs, le motif n’est plus un unique caractères mais une série de deux : aa, ab, etc. Toujours afin d’éviter la limite des 32000. Malgré tout, il subsiste des recherches l’atteignant encore mais j’ai considéré que je pouvais, pour le moment, accepter une légère perte d’information.

Do you speak HTML ?

Puisque je naviguais au sein des résultats du moteur de recherche, ma matière première était du code HTML. Celui-ci offre une structure mais bien plus limitée que le résultats d’une API spécifique. Malgré tout, le code HTML de la page de résultat possédait suffisamment d’indicateurs pour en extraire de la donnée pertinente : titre, méta-données, éditeur, côte, etc.

Notice

Notice

 

Il est assez évident que le code HTML généré par le moteur de recherche a été développé à une époque où les standards du web étaient encore balbutiants. En d’autres termes, il pique les yeux.

Heureusement, j’avais à ma disposition des outils programmatiques capables de lire chaque page HTML retournée par le moteur de recherche. Une fois ces pages décomposées, je pouvais extraire les données qui me semblaient utiles. Il a fallut du temps et de la patience néanmoins pour tout extraire. En effet, ce code HTML n’utilisant pas, ou peu, d’identifiants uniques au sein de sa structure, pointer vers les éléments contenant des données s’est révélé un peu plus compliqué. Il a été nécessaire de trouver un contournement se basant sur les informations à ma disposition :

  • Le label exposé, par exemple TITRE.
  • Puis chercher l’élément le juxtaposant pour en extraire l’information.

Voici un exemple tiré directement du résultat du moteur de recherche :

&lt;table width="100%" cellspacing="3" cellpadding="0"&gt;<br />
&lt;tr&gt;&lt;!-- next row for fieldtag=t --&gt;<br />
&lt;td valign="top" width="20%"  class="bibInfoLabel"&gt;TITRE&lt;/td&gt;<br />
&lt;td class="bibInfoData"&gt;<br />
&lt;strong&gt;Nevermind / Nirvana, groupe voc. et instr.&lt;/strong&gt;<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;

Cette approche a bien fonctionné. Le désavantage le plus notable est le surcoût lié au chargement et à la navigation au sein de tant d’éléments superflus à notre objectif final. Unitairement ce n’est pas un problème mais j’ai collecté quelques 600 000 notices…

Par ailleurs, comme je l’indiquais plus haut, le fait de devoir utiliser les auteurs comme point d’entrée du catalogue m’a obligé à consommer bien plus de pages HTML que si j’avais pu directement parcourir la liste exhaustives des oeuvres.

Vous avez bien un peu de temps ?

Comme indiqué ci-dessus, j’ai récolté environ 600 000 notices en un peu moins de trois jours. Un conseil, estimez à l’avance le nombre global de notices via le moteur de recherche. L’idée est que si vous avez un plafond vous pourrez potentiellement optimiser votre récolte afin d’en réduire la durée.

Quoiqu’il en soit, les performances de la récolte avaient plusieurs facteurs limitant :

  • Le moteur de recherche n’est probablement pas optimisé pour subir des recherches aussi larges et soutenues
  • J’ai tenté de distribuer la charge en multipliant les agents de récolte mais il semblerait que les services informatiques de Rennes aient placé des gardes fous (et ils ont bien raison) diminuant mes capacités
  • Il aurait été intéressant que je puisse essayer mes agents de récoltes depuis un serveur plus performant (dans ce bon vieux cloud) et déterminer si ma machine elle-même posait ses contraintes

Le principal désavantage à une récolte si longue est de ne pas pouvoir la rejouer chaque nuit afin de synchroniser les données le plus régulièrement possible, notamment en ce qui concerne les attributs de prêts (date de retour par exemple).

Stockage de masse

L’idée d’extraire l’ensemble des notices du catalogue est une étape mais, dans une optique Open Data, il fallait proposer cet ensemble de données de manière structurée au public afin d’éviter de devoir toujours passer par une collecte fastidieuse.

A l’heure actuelle, il n’est pas encore clair quel medium de distribution je choisirai mais il est évident que celui-ci devra faciliter l’exploration des données récoltées. Une base de donnée relationnelle, ou NoSQL, semblerait un bon candidat.

Par ailleurs, récemment j’ai pu découvrir le projet BibServer de l’OKFN sur le sujet des données bibliographiques et je dois avouer aimer leur approche. Il s’agit d’une application web assez simple proposant un moteur de recherche, mais aussi une API, sur des notices (des records). Le serveur ne stocke pas les notices dans une base de données traditionnelle, ni sur le système de fichier lui même mais directement dans un moteur de recherche qui les indexe et propose une interface de recherche très poussée et efficace. Cela répond bien aux origines de notre intérêt des données de bibliothèques, ouvrir l’accès aux données par une API. Tout cela en participant à un effort international sur le sujet.

D’autre part, le projet BibServer promeut un format d’encodage des données bibliographiques simple et flexible s’appuyant sur des méthodes et ontologies standardisées : le BibJSON. Ce format offre une souplesse intéressante dans la manipulation des données et donc de belles perspectives.

Parlez-vous bibliothécaire ?

L’un des aspects les plus enrichissant de travailler sur des données est d’en comprendre le contexte, le vocabulaire, le jargon. Et pour le coup, le milieu des médiathèques est passionnant mais néanmoins complexe. Il s’agit d’une vieille discipline qui s’est enrichi dans le temps et qui continue d’évoluer. La BnF propose par exemple une revue de la complexité du catalogage.

Un exemple simpliste mais illustratif est celui du nom d’un auteur. En général, les notices utilisent le format « Nom, Prénom » qui semble moins intuitif que « Prénom Nom ». Mais il s’agit d’une règle de la norme NF Z 44-061 publiée par l’AFNOR. Tout est donc codifié suivant des règles strictes. La difficulté réside dans l’automatisation du traitement des ces règles afin d’en extraire l’information désirée, et potentiellement les rendre plus consommables en dehors du modèle français de catalogage et d’indexation. Par exemple dans la liaison avec des sources externes telles que Wikipedia (via DBPedia), MusicbrainzIMDBGoodReads, etc.

Ainsi, dans le cas de l’album Nevermind du groupe Nirvana, on se rend compte que le titre affiché est : Nevermind / Nirvana, groupe voc. et instr. Or nous ne sommes pas intéressés par la seconde partie du titre, qui ne nous apporte pas grand chose pour une exploration générique du catalogue. La difficulté est que nous n’avons pas toujours un motif clair pour scinder le titre ou l’auteur en différentes composantes. Nous pourrions ainsi avoir Nevermind Nirvana, groupe voc. et instr : Comment déterminer le titre de la description qui l’accompagne de manière automatisée ? Notons que le catalogue s’est construit durant des dizaines d’années, bien avant que l’outil informatique existe, expliquant que les données puissent induire en erreur un outil informatique.

Un autre exemple découvert au fil de l’eau est celui de la traduction. Le moteur de recherche retourne les traducteurs comme des auteurs donc je les traitais de cette façon. Evidemment ceci n’a pas de sens. Il a fallu par conséquent ajouter une vérification que l’ « auteur » retourné était effectivement l’un des auteurs réels de l’oeuvre, pas un traducteur, exécutant, etc.

Bref, l’extraction systématique des données est une étape. L’exploration en sera une autre plus complexe.

Et la suite ?

A l’heure actuelle, les données et le code ne sont pas encore publics. Le code qui nous a permis d’extraire le catalogue le sera bientôt (après un sérieux nettoyage de fond). est désormais accessible. Quant aux données, nous attendons le retour officiel des bibliothèques de Rennes Métropole afin, par exemple, de spécifier la licence avec laquelle nous pourrions distribuer les données.

Edit. du 26/02/2013 : Il semblerait que l’Etat porte un projet d’aides aux bibliothèques désireuses d’avancer vers le numérique (merci Léa du lien).

Creative Commons License
Collectif Open Data Rennes by Collectif Open Data Rennes is licensed under a Creative Commons Attribution 3.0 France License.
Creative Commons License
Collectif Open Data Rennes by Collectif Open Data Rennes is licensed under a Creative Commons Attribution 3.0 France License.

Voir en ligne : http://blog.cod-rennes.fr/2013/02/2...

À la une