Une cartographie des livres en bibliothèque

Posted on

Bonjour !

Tout d’abord, toutes nos excuses pour le peu de mouvements sur ce blog, et l’absence d’évènements grand public autour de l’open data sur Rennes. Ces évènements vont prochainement revenir, et seront bien sûr annoncés ici et via la Cantine Numérique.

Cependant, ce n’est pas pour autant que les membres du collectif se tournent les pouces : nous travaillons sur différents projets et nous essayons de donner régulièrement des nouvelles et des réflexions sur ce blog, comme le fait par exemple Sylvain sur son travail d’extraction des données du catalogue des Bibliothèques de Rennes (voir ses deux articles ici et ).

C’est également un retour d’expérience que je vous propose aujourd’hui, et qui portera aussi sur la bibliothèque… eh oui, c’est un sujet qui passionne plusieurs membres du collectif, d’autant plus que nos interlocuteurs sont très ouverts sur le sujet et acceptent volontiers de discuter de leurs données avec nous. Cet article est donc un récit de nos essais, nos réflexions et nos bidouillages sur notre nouveau projet.

Une carte de la bibliothèque des Champs Libres

La bibliothèque des Champs Libres à Rennes s’étend sur six étages et dispose de plus de 200 000 documents en libre accès. Notre idée de départ était de cartographier la bibliothèque afin de pouvoir repérer l’emplacement de chaque livre. Par exemple, après une recherche dans le catalogue, pouvoir indiquer au lecteur que l’ouvrage se trouve non seulement aux Champs Libres, mais à tel étage, et pourquoi pas dans telle étagère, tel rayon ?

3d

Un beau dimanche du mois de mars, quatre membres du CODRennes se sont donc retrouvés aux pieds de la bibliothèque. Papier et crayons en main, nous avons rapidement défini l’objectif : cartographier le quatrième étage (Littérature) de la bibliothèque afin d’indiquer précisément où se trouvaient chaque tranche de cote.

La cote est un système de classification des ouvrages, que l’on retrouve par exemple sur la tranche des livres. La classification de Dewey est la plus utilisée, et propose de diviser le fonds de la bibliothèque en dix classes, elles-mêmes subdivisées, etc.
Ce système est noté avec des chiffres, par exemple : 641.5 -> Livres de cuisine. Plus d’informations sur Wikipédia

Nous n’avions pas réfléchi au préalable à une méthode particulière pour notre prise de notes : nous nous sommes simplement réparti l’espace afin de travailler chacun sur une partie de l’étage.

A la fin de l’opération (cela a été assez rapide : un peu moins d’une heure), nous nous sommes retrouvés pour comparer les données collectées. Nous avons constaté que nous avions tous adopté à peu près la même méthode, qui nous semblait la plus logique. Dans un second temps, nous sommes revenus sur cette méthode, afin de la rendre la plus claire possible, compatible avec la partie technique (entrer les informations dans une base de données) et surtout reproductible pour les autres étages.

Une carte et des données

D’un côté, nous avons tracé un rapide schéma représentant l’étage vu du dessus, avec ses étagères et ses points de repère (porte d’entrée, poteaux, bornes informatiques).

Sans titre 4

D’autre part, il nous fallait représenter le contenu d’une étagère. Mais qu’est-ce qu’une étagère au fait ? C’est un meuble qui a deux faces, ces deux faces sont découpées en rayons et en colonnes, ce qui forme des cases.

Jelizawjeta_P._Bookshelf_1

Finalement, une étagère ressemble beaucoup à un tableau. Le plus simple est donc de ranger nos données sur papier dans des tableaux. Dans chaque case, nous avons indiqué les cotes que nous trouvions dans les cases des étagères.

Pour relier les tableaux à la carte, chaque étagère a un numéro, et ses deux faces s’appellent A et B.

Sans titre 3

Sur place, plusieurs questions se sont posées : jusqu’à quel niveau de détail est-il raisonnable d’aller ? (profondeur des cotes, position exacte du livre dans l’étagère, voire dans la case) Comment indiquer que plusieurs cotes différentes sont présentes dans une case ? Comment indiquer au contraire qu’une même cote s’étend sur des rayons, voire des étagères entières ? Comment gérer les cas spécifiques, les sélections, les périodiques, les BDs ?

Dans un premier temps, nous avons choisi de mettre de côté la Mezzanine (étage ados) et le rez-de-chaussée (étage enfants) car la disposition et la structure des rayonnages sont trop différents de ceux des autres étages.

Une première feuille de route pour cartographier

Lors d’une deuxième session, nous sommes retournés à la Bibliothèque pour tenter de cartographier les étagères de l’ensemble des étages. Le but n’était cette fois pas de relever les cotes, mais simplement de situer les étagères, et de noter combien de rayons et de colonnes chacune contenait.

cartobibli3

Nombre du bas : numérotation – nombre du haut : nombre de rayons en hauteur – longueur en petits carreaux : nombre de colonnes.

Nous avons entré ensuite ces informations dans un tableur, ce qui nous a permis d’arriver aux chiffres suivants : sur les cinq étages supérieurs de la bibliothèque se trouvent 135 étagères, soit environ 1000 rayons et un total de plus de 4000 cases !

A partir de ce premiers tableau, nous pouvons facilement générer et imprimer les tableaux vierges qui, associés à une carte de l’étage, vont permettre de continuer la collecte des cotes sur les autres étages de la bibliothèque. Avis aux bonnes volontés, si on organisait un atelier ? :)

Des idées d’applications

Au delà de l’idée de représenter de manière originale le plan des étages de la bibliothèque (tout est à inventer : un plan de métro ? des continents ? en 3D ?), nous avons envisagé la possibilité de représenter les informations de façon dynamique.

Par exemple, à la suite d’une recherche sur le catalogue, l’utilisateur apprend que le document qu’il cherche se trouve dans la bibliothèque des Champs Libres ou une bibliothèque de quartier. On peut alors imaginer lui suggérer la façon de s’y rendre, en transports en commun, puis lui indiquer exactement le chemin à parcourir sur place et dans les rayonnages pour trouver son bonheur.

maq

Ces informations pourraient également donner lieu à des jeux de piste, des statistiques…

Et ensuite ?

Ce petit projet est une très bonne expérimentation du principe de crowdsourcing, c’est à dire que les habitants peuvent aller directement chercher et construire les données. Il est facilement reproductible dans d’autres bibliothèques, d’autres lieux…

De notre côté, le travail n’est pas fini : nous souhaitons aller jusqu’au bout de l’idée et proposer des prototypes de représentations des données ou d’applications. Il nous reste donc plusieurs étapes :

  • Finir de collecter les cotes sur les autres étages
  • Entrer ces informations dans une base de données structurée
  • Relier les cotes entrées avec la classification Dewey afin de pouvoir manipuler des thématiques compréhensibles et non plus des chiffres (d’ailleurs, nous cherchons toujours une version brute des quatre premiers niveaux Dewey, en xml ou csv par exemple, si un de nos lecteurs a ça sous la main :) )
  • Concevoir et réaliser des visualisations avec ces données, en nous appuyant sur les idées et besoins des utilisateurs des bibli, mais aussi des bibliothécaires eux-mêmes
  • Renouveler l’expérience dans les autres bibliothèques de Rennes ?

Voilà pour un premier aperçu de nos préoccupations actuelles. Un évènement public sera organisé dans les prochains mois, et permettra aux personnes intéressées de voir l’avancement des projets et d’échanger avec nous et nos interlocuteurs à la Bibliothèque.

D’autre part, si vous souhaitez dès maintenant faire des remarques, poser des questions, ou nous aider sur les tâches listées ci-dessus, n’hésitez pas ! Toutes les idées sont les bienvenues, en nous contactant ou en laissant un commentaire ici-même.

A bientôt,

Léa

Sylvain (dit “l’Ingénieur”), Florian (Database Guru) et Benoît (let’s design this, fools)

 

Schémas et maquettes : Collectif Open Data Rennes, CC-BY.
Photo d’étagère : Jelizawjeta P., CC-BY, sur Wikimedia Commons


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

Posted on

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 :

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

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


Les bibliothèques de Rennes Métropole à l’heure de l’Open Data

Posted on

Depuis 2010, Rennes Métropole s’est lancée dans l’open data et a ouvert des données d’horizons variés. Un domaine reste malgré tout plutôt pauvre, c’est celui de la culture. Pourtant Rennes ne manque pas d’acteurs publics ou privés liés à la culture sous toutes ses formes. Le terreau est riche et fertile.

Un acteur a quand même commencé à proposer certains jeux de données, il s’agit de la bibliothèque des Champs Libres, avec ses statistiques de fréquentations par heure et par jour. Ces données sont intéressantes car elles permettent de percevoir la distribution des visites tout au long de l’année et peut-être en faire des corrélations (va-t-on plus à la bibliothèque lorsqu’il fait froid ? quand il pleut ? le printemps est-il plus propice à la lecture ? etc.). Le Collectif Open Data Rennes s’est d’ailleurs appuyé sur ces données pour en proposer un jeu de visualisations. La culture nourrit la culture.

Néanmoins, nous pensons qu’il y a plus à faire avec l’information qu’une bibliothèque peut générer et manipuler au quotidien: nombre de documents empruntés, retournés, en retard, emprunts par heure ou jour, quelle section d’une bibliothèque est la plus dévalisée. Bien entendu on peut ajouter aussi son catalogue, l’âme d’un tel lieu.

Une approche en douceur

Initialement, lorsque vous souhaitez travailler sur des données d’un acteur public, il est bon de faire un tour sur leur site afin de voir ce qui est accessible, même si ce n’est pas programmatiquement exploitable. Ainsi les Champs Libres possèdent une section évoquant l’histoire et les chiffres, notamment ceux liés à la bibliothèque.

Mais nous parlons d’open data, nous voulons des données structurées. Si aucun jeu de données ou d’API n’est proposés librement par l’acteur public en question, il est temps de prendre contact avec eux pour en discuter. La manière pour le faire dépend très largement de la politique d’ouverture de la commune et des institutions qui en dépendent, ainsi que de l’acteur lui même. Bien entendu, une sensibilisation à l’open data et à ses enjeux est un préalable important pour que l’acteur s’engage dans l’initiative. La prise de contact peut se faire par email mais il est probable qu’une entrevue de visu sera plus productive. Trouver le bon interlocuteur va requérir toute votre sagacité. Dans le cas de la Bibliothèque, ils étaient déjà engagés dans une démarche d’ouverture des statistiques, et nous avons eu la chance de les avoir rencontrés au travers de réunions sur le sujet à la Cantine Numérique Rennaise. Par ailleurs, Léa étant en très bon rapport avec des membres de la bibliothèque facilitant ainsi les premiers échanges.

Ne jamais hésiter à ouvrir la discussion, si vous trouvez le bon interlocuteur.

Un jeu de patience donnant/donnant

Dans le cas où l’acteur répond positivement à la demande d’ouverture de certaines de ses données, vous allez devoir vous armer de patience. En effet, l’existence d’une donnée ne signifie pas qu’elle soit facilement accessible ou exploitable. L’open data demande un effort et un processus qui peut se révéler complexe ou coûteux, au moins en temps.

Par ailleurs, afin de justifier ce surcoût, il est possible que l’acteur public ou privé propose d’abord un jeu de données simples afin de voir l’engouement à son égard. Cela peut faire bondir les défenseurs de l’open data qui estiment que les données ne doivent pas être prises en otage, mais le pragmatisme est de mise dans l’action publique. Par conséquent, un jeu de donnée basique attisant les appétits, il peut se révéler judicieux de montrer qu’il y a effectivement une attente réelle pour plus de données. Le collectif, sous l’impulsion de Léa, a ainsi proposé l’opération #biblioviz.

Une fois que la discussion est engagée, il convient alors de faire un état des lieux des données qu’une bibliothèque manipule et celles qui peuvent intéresser la collectivité, et enfin lesquelles entrent dans le cadre légal de l’open data.

Des contraintes à prévoir

Techniques

Les communes possèdent des fonds patrimoniaux bien antérieurs aux nouvelles technologies sans parler des mouvements d’ouvertures comme l’open data, l’open content, voire l’opensource et le logiciel libre (on parle de dizaines d’années pour les logiciels, et des centaines d’années pour certain bien du patrimoine). Ces considérations ne sont pas entrées en ligne de compte dans les appels d’offres de logiciels tels que les SIGB. Par conséquent, il est fort à parier que le logiciel équipant votre bibliothèque soit fermé (qu’il soit privateur ou privé, en tout cas non-libre d’accès). Cela pose des difficultés certaines pour l’ouverture des données, sans parler de requérir parfois une licence spécifique d’un montant substantiel. C’est le cas des bibliothèques des Rennes Métropole et ce qui a poussé le collectif à contourner cette contrainte en aspirant le catalogue via le moteur de recherche. Nous y reviendrons dans un prochain article.

Légales et politiques

La culture n’est pas un domaine simple lorsqu’il s’agit d’accéder à des données. Celles-ci sont gardées jalousement et/ou sont simplement trop complexes et coûteuses à rendre disponibles. Par ailleurs, la culture est le monde du droit : droit d’auteur, droits voisins, etc. Il peut se révéler très complexe pour un acteur de savoir comment l’open data s’inscrit dans ce contexte. Dans tous les cas, les acteurs de la culture se doivent d’être prudents avec les données, car il peut ne pas leur appartenir le droit de les mettre à disposition.

Compétences métier

Comme tout domaine, la bibliothèque a ses métiers, avec ses codes, ses règles, et son vocabulaire. Lorsque le Collectif a rencontré la Bibliothèque, il a d’abord fallu expliquer certain termes employés (rien que SIGB par exemple). De même, les données peuvent être classées et codifiées selon une norme spécifique à un métier. Cette contrainte est indéniablement une occasion de s’intéresser et de discuter du métier de la bibliothèque, et d’écouter ses acteurs et ses professionnels.

Demandeur mais aussi acteur

La démarche de l’open data doit se faire avec de la patience au ventre. Il est en effet indispensable de se remémorer que les acteurs publics ou privés, même lorsqu’ils sont moteurs, prendront le temps qu’il faut pour libérer leurs données. Il existe un temps incompressible dont il faut tenir compte, et prendre patience afin de respecter le planning des différents interlocuteurs.

Malgré tout, il est possible, comme avec le catalogue des bibliothèques, de déjà vous faire une idée des données que vous pourriez traiter et ainsi aiguiller votre interlocuteur.

L’opendata propose au citoyen un outil supplémentaire pour agir sur sa vie locale.

Conclusion

Les bibliothèques de Rennes Métropole semblent accueillir avec bienveillance l’idée d’un accès à leurs données. Mais pour des raisons de contraintes techniques liées à leur SIGB ainsi qu’à des impératifs liés à leur planning, il apparaît clair au Collectif qu’une partie du travail devra se faire par des moyens indirects tels que nous évoquions plus haut. Nous présenterons ce travail lors d’un prochain article.