« Papa, c’est quoi un SRU ? »

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 ? »