Aller au contenu
Tamil
ActualitéDoc

Protocole Z39.50/SRU

Z39.50 est un protocole de recherche d'information, normalisé aux États-Unis (norme ANSI/NISO Z39.50) puis à l'international (ISO 23950) ; il est maintenu par la Bibliothèque du Congrès. Il permet à un logiciel d'interroger le catalogue d'une autre bibliothèque et d'en récupérer les notices, quel que soit le logiciel qui gère ce catalogue. Les bibliothèques l'utilisent depuis les années 1990 pour partager leurs notices : un catalogueur récupère la notice d'un document déjà catalogué ailleurs au lieu de la saisir entièrement.

Z39.50 fonctionne entre un client et un serveur. Le client se connecte au serveur sur un port réseau dédié et lui envoie une requête : chaque critère de recherche y est décrit par des attributs numériques (titre, auteur, ISBN...), selon un profil commun, le profil Bib-1. Le serveur répond par le nombre de notices trouvées, puis envoie les notices demandées dans le format choisi par le client (UNIMARC, MARC21...).

SRU (Search/Retrieve via URL) est l'équivalent de Z39.50 pour le web, défini lui aussi par la Bibliothèque du Congrès. La requête est une simple adresse web (URL), écrite dans le langage de requête CQL ; le serveur répond en XML. SRU est plus simple à mettre en œuvre et à interroger ; beaucoup de serveurs proposent les deux protocoles.

Le diagramme suivant montre les échanges d'une recherche par ISBN : en Z39.50, le client ouvre une connexion (Init), envoie la requête (Search), demande les notices trouvées (Present) puis ferme la connexion (Close) ; en SRU, une seule requête web suffit.

Échanges entre un client et un serveur Z39.50 et SRU

Koha met en œuvre les deux rôles :

  • Client — Koha interroge les catalogues d'autres bibliothèques pour en récupérer des notices.
  • Serveur — Koha répond aux requêtes d'autres logiciels, qui récupèrent les notices de son catalogue.

Client

Koha contient un client Z39.50/SRU : il interroge des catalogues distants, appelés serveurs ou cibles, que la bibliothèque définit une fois pour toutes dans l'administration. Ces serveurs sont ensuite proposés dans plusieurs modules de Koha : catalogage, autorités, acquisitions.

Le catalogueur qui crée une notice commence ainsi par la chercher dans un catalogue de référence (le Sudoc, la BnF, la Bibliothèque du Congrès...), puis il la récupère et la complète, au lieu de la saisir entièrement.

Définir les serveurs

Les serveurs se définissent dans Administration > Serveurs Z39.50/SRU, avec les boutons Ajouter un serveur Z39.50 et Ajouter un serveur SRU. Les paramètres d'un serveur sont fournis par l'établissement qui le propose :

Champ Contenu
Nom du serveur Nom affiché aux catalogueurs.
Adresse du serveur, Port, Base de données Adresse du catalogue distant.
Identifiant, Mot de passe Pour les serveurs qui demandent une identification.
Présélectionné Serveur coché par défaut dans les recherches.
Rang Ordre d'affichage des serveurs.
Attributs Attributs de recherche ajoutés à chaque requête envoyée au serveur (voir plus bas).
Syntaxe Format des notices demandées : UNIMARC, MARC21... (voir plus bas).
Encodage Jeu de caractères des notices envoyées par le serveur : utf8, MARC-8, ISO 5426... (voir plus bas).
Délai Temps d'attente maximal de la réponse, en secondes.
Type de notice Bibliographique ou Autorité : détermine les modules qui proposent le serveur.
Fichier(s) XSLT pour la transformation des résultats Feuilles de style appliquées aux notices reçues (voir plus bas).
Limite de site Réserve le serveur aux sites choisis.

Un serveur SRU a en plus des options propres à SRU : options de connexion et correspondance entre les champs de recherche de Koha et les index du serveur.

À l'installation, Koha propose quelques serveurs d'exemple, dont la Bibliothèque du Congrès et la Bibliothèque nationale de France.

Attributs — Une requête Z39.50 décrit chaque critère de recherche par des attributs numériques, définis par le profil Bib-1 : @attr 1=4 pour une recherche sur le titre, @attr 1=7 sur l'ISBN, @attr 5=1 pour tronquer le terme à droite, etc. Koha construit lui-même la requête à partir du formulaire de recherche. Le champ Attributs ajoute un texte au début de toutes les requêtes envoyées à ce serveur, à lui seul :

  • Attribut exigé par un serveur — Certains serveurs ne répondent que si un attribut est présent. C'est le cas qui a motivé l'ajout de ce champ dans Koha : un serveur qui exigeait l'attribut de structure, @attr 4=1 (rechercher une expression).
  • Interprétation des termes — Un attribut change la façon dont le serveur interprète les termes. Avec @attr 5=1, les termes sont tronqués à droite : une recherche sur le titre sur la télévision donne 404 notices dans le Sudoc ; 415 avec la troncature.
  • Filtrer les résultats — Le champ n'est pas prévu pour cela, mais comme son texte est placé devant la requête, on peut y ajouter un critère fixe, combiné à la recherche avec @and. Avec @and @attr 1=31 1996, toutes les recherches sur ce serveur sont limitées aux documents publiés en 1996 : la recherche précédente ne donne plus que 16 notices dans le Sudoc. Le serveur doit connaître l'index utilisé : @and @attr 1=54 eng (langue anglaise) n'a aucun effet sur le Sudoc. Pour garder la recherche sans filtre, on déclare le même serveur deux fois, sous deux noms, avec et sans attributs.

Le champ est vide pour la plupart des serveurs. Les attributs que reconnaît un serveur figurent dans sa documentation, par exemple le profil Z39.50 publié par l'Abes pour le Sudoc.

Syntaxe — La syntaxe est le format MARC dans lequel Koha demande les notices au serveur. Koha ne convertit pas une notice d'un format MARC à un autre : il la lit comme si elle était dans le format de son propre catalogue. Une notice MARC21 reçue dans un Koha en UNIMARC est donc inutilisable : le titre est en 245 au lieu de 200, l'auteur en 100 au lieu de 700, etc. Un Koha en UNIMARC ne peut utiliser que des serveurs qui fournissent de l'UNIMARC, et un Koha en MARC21 que des serveurs qui fournissent du MARC21. Beaucoup de serveurs proposent les deux formats, comme le Sudoc : on choisit alors celui du catalogue Koha. Une conversion d'un format à l'autre par une feuille de style XSLT (voir plus bas) est possible en théorie, mais c'est un travail important, que Koha ne fournit pas.

Encodage — Koha enregistre ses notices en Unicode, encodé en UTF-8. Les serveurs Z39.50 n'envoient pas tous leurs notices en UTF-8 : beaucoup de serveurs anciens utilisent l'ISO 5426 (catalogues UNIMARC) ou le MARC-8 (catalogues MARC21). L'encodage indiqué pour le serveur est celui des notices qu'il envoie : Koha les convertit automatiquement en UTF-8 à leur réception puis le note dans la notice (position 26-29 du 100$a en UNIMARC, position 9 du label en MARC21). Si l'encodage indiqué n'est pas le bon, la conversion abîme les caractères accentués : télévision devient par exemple télévision. Quand un serveur propose de l'UTF-8, comme le Sudoc, on le choisit : il n'y a pas de conversion. Les serveurs SRU envoient leurs notices en XML, toujours en UTF-8 : l'encodage n'est pas utilisé.

Où les serveurs sont utilisés

Catalogage — Les serveurs de type Bibliographique sont proposés :

  • en page d'accueil du module Catalogage, avec Dériver une nouvelle notice via Z39.50/SRU ; la flèche à côté du bouton permet de choisir la grille de catalogage de la future notice (par défaut, la Grille de catalogage par défaut) ;
  • sur une notice, dans le menu Modifier, avec Remplacer la notice par Z39.50/SRU ;
  • dans l'éditeur MARC, avec le bouton de recherche Z39.50/SRU, qui remplace la notice en cours de saisie ;
  • dans l'éditeur avancé, où les serveurs sont des Cibles de recherche.

La recherche — Une fenêtre s'ouvre, avec le formulaire de recherche et la liste des serveurs. Le catalogueur coche les serveurs à interroger (Tout sélectionner, Tout désélectionner ; les serveurs Présélectionnés sont déjà cochés), puis cherche par ISBN, ISSN, titre, auteur, sujet, année, numéro de notice, indice Dewey, mot quelconque... Depuis une notice ou depuis l'éditeur, le formulaire est prérempli avec les données de la notice : ISBN, titre, auteur... Koha interroge tous les serveurs cochés en même temps et affiche leurs résultats ensemble, 20 par page.

Les résultats — Le tableau des résultats indique, pour chaque notice, le serveur qui l'a fournie, le titre, l'auteur, l'année, l'édition, l'ISBN, ainsi que les Champs supplémentaires choisis dans les préférences (voir plus bas). Le menu de chaque résultat propose trois actions :

  • Prévisualisation MARC — Affiche la notice reçue, champ par champ, sans l'importer : pour vérifier qu'elle est complète, ou comparer les notices de plusieurs serveurs.
  • Prévisualisation ISBD — Affiche la notice sous forme de fiche, plus lisible.
  • Importer — Ouvre l'éditeur MARC avec la notice choisie, dans la grille de catalogage choisie au départ. Le catalogueur la vérifie, la complète (par exemple avec l'indexation locale) puis l'enregistre. Rien n'est ajouté au catalogue tant que la notice n'est pas enregistrée. Pour une nouvelle notice, Koha signale à l'enregistrement si une notice semblable existe déjà dans le catalogue.

Le bouton de chaque résultat reprend la dernière prévisualisation utilisée (MARC ou ISBD), ce qui permet de passer d'une notice à l'autre d'un clic. Un clic sur une ligne du tableau ouvre aussi le menu des actions. Faire une autre recherche revient au formulaire ; Effacer le formulaire de recherche le vide.

Quand la notice reçue remplace une notice existante, les règles de fusion de notices de la source z3950 s'appliquent si elles sont activées : elles permettent par exemple de conserver l'indexation locale.

Autorités — Les serveurs de type Autorité sont proposés de la même façon dans le module Autorités, pour créer une notice d'autorité à partir d'un serveur, ou pour remplacer une autorité existante.

Acquisitions — Dans un panier, Ajouter au panier > À partir d'une source externe cherche le titre à commander sur les serveurs bibliographiques. La notice choisie est importée dans le catalogue avec la ligne de commande : il n'est pas nécessaire de la cataloguer avant de la commander.

Préférences

  • AdditionalFieldsInZ3950ResultSearch — Champs ou sous-champs MARC affichés dans la colonne Champs supplémentaires des résultats de recherche bibliographique, pour aider à choisir la bonne notice. Par exemple 010$a, 210$c, 215$a pour l'ISBN, l'éditeur et la pagination en UNIMARC.
  • AdditionalFieldsInZ3950ResultAuthSearch — La même chose pour les autorités.
  • z3950NormalizeAuthor et z3950AuthorAuthFields — En UNIMARC, à l'import d'une notice, reconstruisent le champ de l'auteur dans Koha (la mention de responsabilité, 200$f) à partir des champs de noms indiqués (700,701,702 par défaut).

Transformer les notices reçues

Une notice reçue d'un serveur n'est pas toujours prête à entrer dans le catalogue : champs propres au catalogue d'origine, exemplaires, numéro de notice à déplacer... Koha peut appliquer une ou plusieurs feuilles de style XSLT à chaque notice reçue d'un serveur, avant de l'afficher dans les résultats. On les déclare dans le champ Fichier(s) XSLT pour la transformation des résultats du serveur, séparées par des virgules : elles s'appliquent l'une après l'autre.

  • Un simple nom de fichier est cherché dans le répertoire xslt des gabarits de l'interface professionnelle, où Koha livre quelques feuilles de style : Del995.xsl supprime les champs d'exemplaires UNIMARC (995) de la notice reçue, Del952.xsl ceux du MARC21.
  • Un chemin absolu (qui commence par /) désigne une feuille de style personnalisée, enregistrée en dehors des fichiers de Koha pour ne pas être écrasée lors d'une mise à jour, par exemple dans /var/lib/koha/<instance>/xslt/. Le fichier doit être lisible par l'utilisateur de l'instance Koha.

Les feuilles de style s'appliquent aux recherches des modules Catalogage, Autorités et Acquisitions, mais pas à celles de l'éditeur avancé, qui reçoit les notices sans transformation.

Exemple : le Sudoc

Le Sudoc, le catalogue collectif des bibliothèques de l'enseignement supérieur, est interrogeable par Z39.50. L'Abes propose un profil Z39.50 public, sans identification :

Champ Valeur
Nom du serveur Sudoc
Adresse du serveur carmin.sudoc.abes.fr
Port 10646
Base de données abes-z39-public
Identifiant, Mot de passe vides
Syntaxe UNIMARC
Encodage utf8
Type de notice Bibliographique
Fichier(s) XSLT pour la transformation des résultats /var/lib/koha/<instance>/xslt/sudoc-ppn.xsl

Le port 10646 renvoie les notices en UTF-8. Le Sudoc propose aussi les ports 210 (ISO 5426) et 8859 (ISO 8859), qui demandent de choisir l'encodage correspondant.

Conserver le PPN et nettoyer la notice — Dans les notices du Sudoc, le champ 001 contient le PPN, l'identifiant de la notice dans le Sudoc. Or, dans la grille de catalogage UNIMARC de Koha, le 001 contient le numéro de notice Koha (biblionumber) : à l'enregistrement, Koha y écrit son propre numéro et le PPN est perdu. Pour le conserver, la feuille de style déclarée pour le serveur le déplace en 009.

Une notice du Sudoc contient aussi des champs qui n'ont pas forcément leur place dans le catalogue, par exemple le 035, qui donne les numéros de la notice dans d'autres catalogues (OCLC, BnF). La même feuille de style les supprime :

<?xml version="1.0" encoding="UTF-8"?>
<!-- Notices du Sudoc : le PPN, en 001, est déplacé en 009 et les champs
     inutiles au catalogue sont supprimés -->
<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:marc="http://www.loc.gov/MARC21/slim">

  <xsl:output method="xml" indent="yes" encoding="UTF-8"/>

  <!-- Le 001 devient un 009, avec la même valeur -->
  <xsl:template match="marc:controlfield[@tag='001']">
    <marc:controlfield tag="009">
      <xsl:value-of select="."/>
    </marc:controlfield>
  </xsl:template>

  <!-- Le 035 (numéros de la notice dans d'autres catalogues) est supprimé -->
  <xsl:template match="marc:datafield[@tag='035']"/>

  <!-- Tout le reste est recopié tel quel -->
  <xsl:template match="@* | node()">
    <xsl:copy>
      <xsl:apply-templates select="@* | node()"/>
    </xsl:copy>
  </xsl:template>

</xsl:stylesheet>

La feuille de style recopie toute la notice, sauf les champs pour lesquels elle a une règle (un xsl:template). Une règle vide, comme celle du 035, supprime le champ. On ajoute ainsi une ligne par champ à supprimer : <xsl:template match="marc:datafield[@tag='033']"/> pour le 033 (lien vers la notice de la BnF), etc.

Une règle peut aussi ne viser que certains champs. Celle-ci ne supprime que le 035 qui donne le numéro OCLC ; elle conserve celui de la BnF :

<xsl:template match="marc:datafield[@tag='035'][starts-with(marc:subfield[@code='a'], '(OCoLC)')]"/>

Feuille de style ou règles de fusion ? — Les règles de fusion de notices ne remplacent pas la feuille de style pour ce nettoyage :

  • Création ou remplacement — Les règles de fusion ne s'appliquent que quand une notice reçue remplace une notice existante (Remplacer la notice par Z39.50/SRU), jamais à la création d'une notice (Dériver une nouvelle notice via Z39.50/SRU). La feuille de style s'applique à toute notice reçue du serveur : création, remplacement, commande en acquisitions.
  • Un serveur ou tous — La feuille de style est propre au serveur Sudoc. Les règles de fusion de la source z3950 valent pour tous les serveurs Z39.50 à la fois : elles ne distinguent pas le Sudoc de la BnF.
  • Ce qu'elles font — La feuille de style transforme la notice reçue. Les règles de fusion décident, champ par champ, entre la notice existante et la notice reçue. Elles sont complémentaires : la feuille de style nettoie la notice du Sudoc, puis, lors d'un remplacement, les règles de fusion protègent les champs locaux de la notice existante (indexation locale, notes...).

Pour ne jamais reprendre le 035 d'une notice reçue, tout en gardant celui de la notice existante lors d'un remplacement, on combine donc les deux : la feuille de style supprime le 035 à la réception ; une règle de fusion source z3950, champ 035, Protéger conserve celui de la notice existante. Sans cette règle, le remplacement supprimerait le 035 de la notice existante, puisque la notice reçue n'en a plus.

Le 009 dans la grille de catalogage — L'éditeur MARC de Koha n'affiche que les champs définis dans la grille de catalogage ; il ne conserve à l'enregistrement que les champs affichés. Or la grille UNIMARC livrée avec Koha n'a pas de champ 009 : sans lui, le PPN est perdu à l'enregistrement, malgré la feuille de style. Dans Administration > Grille de catalogage MARC, pour chaque grille utilisée (Structure MARC) :

  1. Ajouter champ : étiquette 009, libellé PPN Sudoc, non répétable.
  2. Modifier les sous-champs du 009 : un champ de contrôle n'a qu'un sous-champ, @ (code laissé vide). Le placer dans l'onglet 0 et le rendre visible dans l'éditeur.

Résultat — La recherche de l'ISBN 2-912107-00-8 (Pierre Bourdieu, Sur la télévision) dans le Sudoc renvoie une notice qui commence ainsi :

001 285819003
003 http://www.sudoc.fr/285819003
005 20250627131136.000
010 ##$a978-2-912107-00-8$bbr.$d6 EUR
010 ##$a2-912107-00-8$bbr.$d30 FRF
035 ##$a(OCoLC)717330943

Après la feuille de style, la notice importée dans Koha commence ainsi :

003 http://www.sudoc.fr/285819003
005 20250627131136.000
009 285819003
010 ##$a978-2-912107-00-8$bbr.$d6 EUR
010 ##$a2-912107-00-8$bbr.$d30 FRF

Le 003 contient l'adresse pérenne de la notice dans le Sudoc. À l'enregistrement, Koha ajoute son propre 001, avec le numéro de la notice dans son catalogue.

Avec le PPN en 009, on peut ensuite afficher à l'OPAC un lien vers la notice du Sudoc : voir l'exemple de la page OPAC personnalisé, section Affichage des notices.

Serveur

Koha peut servir son catalogue en Z39.50/SRU : d'autres logiciels l'interrogent et en récupèrent les notices. Un autre Koha, un catalogue collectif, un logiciel de gestion de références bibliographiques peuvent ainsi chercher dans le catalogue de la bibliothèque et en copier les notices. Le serveur est indépendant du client : il n'utilise pas les serveurs définis dans Administration > Serveurs Z39.50/SRU.

Un travail d'administrateur système

Contrairement au client, le serveur Z39.50 ne se met pas en place depuis l'interface professionnelle. Aucune page de l'administration de Koha ne l'active : il faut intervenir sur le serveur informatique qui héberge Koha, avec les droits de l'administrateur (root). Le serveur Z39.50 est un programme à part, un démon, qui tourne en permanence à côté de Koha et attend les connexions des logiciels clients sur un port réseau. Le mettre en place demande de :

  • lancer des commandes sur le serveur pour activer et démarrer le démon, et veiller à ce qu'il redémarre avec le serveur ;
  • modifier des fichiers de configuration, qui ne sont accessibles que sur le serveur : port d'écoute, formats de notices proposés, correspondance entre les attributs Z39.50 et les index du moteur de recherche de Koha ;
  • ouvrir le port dans le pare-feu du serveur, éventuellement en le limitant à certaines adresses : sans cela, personne ne peut s'y connecter ;
  • surveiller le démon et ses journaux, comme tout service réseau.

C'est aussi une décision de sécurité : le serveur Z39.50 ouvre l'accès au catalogue à des logiciels extérieurs, sans identification. C'est pourquoi il n'est pas activé par défaut.

Deux façons de faire

Le serveur Z39.50 de Koha — Depuis Koha 19.11, Koha fournit son propre serveur Z39.50/SRU. Il fonctionne avec les deux moteurs de recherche de Koha, Zebra et Elasticsearch. Sur une installation par paquets Debian, on l'active pour une instance avec la commande koha-z3950-responder :

koha-z3950-responder --enable <instance>
koha-z3950-responder --start <instance>

L'activation copie les fichiers de configuration dans /etc/koha/sites/<instance>/z3950/ :

  • config.xml : le port d'écoute (2100 par défaut) et les formats proposés (MARC21, UNIMARC, MARCXML) ;
  • pqf.properties et attribute_mappings.yaml : la correspondance entre les requêtes Z39.50 et SRU et les index de Koha.

Les autres logiciels interrogent alors le serveur sur ce port, avec la base de données biblios (notices bibliographiques) ou authorities (autorités).

Ce serveur peut ajouter aux notices qu'il envoie l'état de leurs exemplaires (disponible, en prêt, perdu, en transit...), dans un sous-champ des champs d'exemplaires. C'est une option à activer dans config.xml (--add-item-status). La bibliothèque règle ensuite cet affichage depuis l'interface professionnelle :

  • la liste de valeurs autorisées Z3950_STATUS définit le texte de chaque état ;
  • la préférence z3950Status indique les exemplaires à toujours présenter comme non disponibles, par exemple ceux d'une collection de référence (ccode: [REF]).

Le serveur intégré à Zebra — Avec le moteur de recherche Zebra, Zebra peut lui-même servir de serveur Z39.50/SRU. On l'active à la création de l'instance (koha-create --enable-sru, port 7090 par défaut), ou ensuite en décommentant la section publicserver du fichier koha-conf.xml de l'instance, puis en redémarrant Zebra. Ce serveur est plus simple, mais il ne fonctionne pas avec Elasticsearch et n'ajoute pas l'état des exemplaires.

Dans les deux cas, ces opérations relèvent de l'administrateur système, ou de l'hébergeur de Koha : c'est à lui que la bibliothèque demande la mise en place d'un serveur Z39.50.