/home/nicomo/ - nicolas morin

Z39.50 : une norme en mutation - 2001

[Note: ce texte date de 2001; pour des informations plus à jour voir, en français le site de Dominique Lahary, en anglais directement le site de la norme.]

Jadis, quand le SIGB de votre bibliothèque était moderne, il avait une " couche Z39.50 " : vos notices USMARC pouvaient être envoyées à un client qui les recevait, par exemple, en UKMARC. Hier, vous aviez persévéré dans la modernité, vous aviez ajouté une " passerelle Z39.50 " au SIGB de votre bibliothèque : vos notices USMARC pouvaient être envoyées à un client qui les recevait en UKMARC via le web. Aujourd'hui, " l'intégrateur " auquel vous faites appel vous propose d'être tout à fait moderne, et d'acquérir un "portail" qui permet d'interroger en même temps, grâce à Z39.50, votre SIGB et le système de Gestion Electronique de Documents (GED) que vous lui avez acheté.... Bref : la norme Z39.50, qu'on donne régulièrement pour morte, semble avoir des capacités étonnantes à se renouveler. Ce texte cherche donc d'une part à décrire la norme, qu'on voit partout sans trop savoir à quoi elle ressemble, et d'autre part à montrer ses évolutions récentes ou en cours, qui font qu'elle pourrait bien s'adapter à un paysage documentaire profondément modifié par l'Internet.

Présentation de la norme Z39.50

" Z39.50 " renvoie à la norme ANSI/NISO Z39.50, reprise dans la norme NF ISO 23950 : Information et documentation - Recherche d'information (Z39.50) : Définition du service de l'application et spécification du protocole.[1] Cette norme permet l'interrogation de bases de données hétérogènes : il s'agit d'une normalisation non pas des données elles-mêmes, mais des requêtes, c'est-à-dire du dialogue qui a lieu, dans le cadre d'une architecture client-serveur, entre un utilisateur et une ou plusieurs ressources (bibliographiques ou non). L'utilisateur dispose d'un Client Z39.50 (Origine) qui dialogue avec un Serveur Z39.50 (Cible).

Les services

La norme propose 11 " services " (facilities) possibles entre le client et le serveur. Une session élémentaire utilisera 4 services seulement, qui pourront être dits " services de base " (core services) : initialisation, search, retrieval, termination. Les 7 autres services (Result-set-delete, Browse, Sort, Access Control, Accounting/ Resource Control, Explain, Extended Services) pourront être dits " services étendus ".


Les " services de base "

· Initialisation. Il s'agit d'un dialogue préalable à l'interrogation elle-même, dans lequel le client et le serveur s'accordent sur ce qu'il est possible de faire entre eux. Deux éléments sont importants à ce stade. D'une part le client et le serveur se " présentent " : ils déclarent en particulier l'un et l'autre la version de Z39.50 qu'ils utilisent (un client version 3 (1995) et un serveur version 2 (1992) travailleront en version 2) et, plus généralement, le serveur annonce son profil.[2] D'autre part le serveur annonce, par une série de réponses oui/non, les services qu'il propose et les services qu'il ne propose pas.

· Search. Le client envoi une requête au serveur en respectant le profil indiqué préalablement par le serveur, c'est-à-dire en se limitant aux " champs " que le serveur a déclaré pouvoir traiter. Par exemple, si le serveur Z39.50 utilise le profil bib-1, le client pourra faire une interrogation non seulement sur l'auteur et le titre, mais sur les mots RAMEAU, sur l'ISBN, etc. en utilisant les opérateurs booléens et un opérateur de proximité. Sa requête peut éventuellement viser non pas l'ensemble de la base mais un ensemble de résultats précédemment obtenu. Le client décide aussi à ce stade de l'affichage qu'il souhaite : par exemple, en UNIMARC ; et il défini la liste des champs à afficher s'il y a un petit nombre de résultats (small record format) ou s'il y a un nombre moyen de résultats (medium record format), le client définissant lui-même les notions de petit et de grand nombre de résultats.
Le service search comporte déjà une première réponse du serveur, qui indique le résultat global de la recherche et affiche les premiers résultats selon les paramètres demandés par le client lors de la requête initiale.

· Retrieval. Ce service se décompose en deux parties : le service Present et le service Segment.
Present permet au client de demander l'affichage des résultats qui n'ont pas été envoyés par le serveur dans le cadre de search, par tranches de résultats (par ex. les résultats 15-20, 54, 65-67), en spécifiant le format d'affichage attendu (par ex. UNIMARC, LCMARC, Simple Unstructured Text (SUTRS), etc.). Le client peut donner un nom à cet ensemble de résultats en vue d'une utilisation ultérieure. Le serveur peut répondre en conséquence ou, si cela n'est pas possible, proposer un diagnostic de réponse.
Segment permet au client de segmenter l'ensemble résultat en un certain nombre d'unités plus petites. Ce service permet d'optimiser les transmissions sur le réseau.

· Termination. Ce service permet simplement au client ou au serveur de clore la session.

Les " services étendus "

· Result-set-delete, qui est parfois considéré comme un service de base, permet simplement au client de supprimer un ensemble résultat.

· Access Control et Accounting-Resource Control vont de pair : il s'agit pour le serveur de contrôler l'accès à ses ressources (par exemple d'interdire le déchargement de notices) et de " tenir les comptes " (c'est-à-dire de dire au client qu'il a fait tant de requêtes, que son ensemble résultat comprend tant de résultat, éventuellement que cela lui coûte tant et qu'il lui reste tant de crédit…)

· Sort est un service (rarement) offert par le serveur qui trie les résultats de la requête. La plupart du temps, cependant, il est possible de réaliser cette opération directement sur le client, ce qui économise des ressources réseau.

· Browse (Scan) permet d'obtenir l'affichage non plus de résultats correspondant à une requête mais d'une liste à partir d'un point de départ : le client doit pouvoir spécifier le point d'entrée dans la liste (par exemple : auteur personne physique = proust), le nombre d'entrées à afficher, éventuellement le nombre d'entrées à afficher avant le point de départ.

· Extented services permet au client (origine) de créer et de gérer sur le serveur des " ensembles de travail " (task packages). Il peut ainsi :
- sauvegarder un ensemble résultat lors d'une session normale, le nommer et le réutiliser ultérieurement, éventuellement pour ajouter des données à cet ensemble ou supprimer cet ensemble ;
- sauvegarder une requête sur le serveur (i.e. créer un " profil de recherche "). Ce service peut être combiné avec la possibilité de définir une recherche périodique pour construire dans le cadre d'un service de type " push ".
- commander un item (dans le cadre du prêt entre bibliothèques) ;
- mettre à jour la base de données. Ce service entre dans le cadre des fonctions de catalogage : il rend possible la modification des notices dans la base.
- définir des spécifications pour l'exportation de résultats et " invoquer " ces spécifications : le client peut ainsi paramétrer plusieurs modèles pour l'exportation des résultats et les utiliser à volonté.

· Explain. Ce service existe dans la version 3 de Z39.50. Il s'agit pour le serveur de créer une base de données interrogeable par le client et indiquant tous les services qu'il propose et leurs caractéristiques, de préciser ce que contiennent les bases de données qu'il propose, de dire quels services sont payants, etc. Le client trouve ici plus facilement des informations plus complètes que ce qu'il peut obtenir lors du service Init.

Les profils

Un profil Z39.50 spécifie les options et les paramètres d'utilisation du protocole quand ces choix sont laissés libres par la norme. Un profil peut être conçu pour spécifier l'utilisation de Z39.50 par une application (par exemple un SIGB) ; il peut être conçu pour l'utilisation de Z39.50 par plusieurs applications (par exemple un SIGB et un logiciel de prêt entre bibliothèques) ; il peut enfin être conçu pour l'utilisation de Z39.50 avec un autre protocole (par exemple TCP).
Le profil restreint donc les choix offerts par la norme pour en optimiser l'utilisation au profit d'une communauté ou d'un environnement. Un élément obligatoire de la norme sera obligatoire dans le profil ; un élément optionnel dans la norme pourra être obligatoire, optionnel ou exclus dans le profil.
Dans son profil, le serveur annonce : son adresse (adresse IP, port), la liste de la ou des base(s) de données qu'il propose, sa version de Z39.50, le ou les jeu(x) de caractères qu'il connaît. Surtout, le serveur annonce ses " ensembles d'attributs " (attribute sets) et ses " formats de réponse " (record syntaxes). La Z39.50 Maintenance Agency recense actuellement près d'une trentaine de profils. Mais le profil le plus courant est le profil bib-1 : c'est le premier en date, c'est le plus riche, c'est celui qui a été développé par la communauté des bibliothèques, principale utilisatrice de la norme. Dans ce qui suit, nous parlerons des ensembles d'attributs et des formats de réponse à partir du cas du profil bib-1.

Les ensembles d'attributs

Il y a 6 ensembles d'attributs :

 

Les formats de réponse

Un client Z39.50 peut demander au serveur le format d'affichage qu'il souhaite pour ses réponses. Il peut s'agir d'un format MARC (Z39.50 autorise l'utilisation des formats Unimarc, Intermarc, CCF, Usmarc, Ukmarc, Normarc, Librismarc, Danmarc, Finmarc, MAB, Canmarc, SBN, Picamarc, Ausmarc, Ibermarc), mais aussi de SUTRS (Simple Unstructured Text, c'est-à-dire du texte ASCII, présenté en lignes de 72 caractères), de GRS-1 (Generic Record Syntax : un langage permettant la représentation d'entrées de bases de données), de XML et de quelques autres formats secondaires comme OPAC (un format qui simule, à l'affichage, une fiche ISBD) ou Summary (utilisé pour l'affichage des premiers résultats par le serveur dans la phase search de la session).[4]
La demande émane du client (origine) et le serveur (cible) si conforme… dans la mesure du possible : si cela n'est pas possible, le serveur envoie la réponse dans un format qu'il connaît. Etant donné le développement historique de Z39.50 dans le monde des bibliothèques, presque tous les serveurs Z39.50 sont capables de fournir des données dans un ou plusieurs formats MARC, mais ils sont plus rarement capables d'utiliser d'autres formats que MARC.

 

Les spécificités d'un profil tiennent pour l'essentiel au paramétrage de deux éléments : les attributs d'usage et les formats de réponse. C'est ici le serveur qui a la main : un serveur doté d'un profil bib-1 sera donc très performant pour l'exploitation de bases de données bibliographiques traditionnelles en format MARC, mais ne permettra pas d'exploiter des documents XML. A l'inverse, un profil " généraliste " permettra d'exploiter un éventail plus vaste de ressources, mais sera beaucoup moins performant (par exemple, le bath profile ne permet pas, à l'inverse de bib-1, de faire une interrogation sur les mots MESH ou les mots RAMEAU). Dès lors, il devient nécessaire pour exploiter pleinement les ressources documentaires d'un établissement, de bâtir des architectures complexes comprenant plusieurs serveurs Z39.50. On peut imaginer, par exemple, d'utiliser d'une part un serveur Z39.50 utilisant le profil bib-1 pour exploiter les bases de données bibliographiques en format MARC, et d'autre part un serveur Z39.50 utilisant un profil permettant l'exploitation de bases de données en plein-texte. Les deux serveurs pouvant dialoguer simultanément avec un unique client (web) par l'intermédiaire d'une passerelle Z39.50.

Evolutions de la norme


La nouvelle architecture d'attributs

Le Z39.50 Implementors Group (ZIG) a constaté un certain nombre de difficultés liées à la position tout à fait particulière du profil bib-1, qui est tout à la fois le profil général, c'est-à-dire le plus courant, et le plus spécialisé, puisqu'il est très développé pour tout ce qui concerne les formats MARC. Le ZIG a donc décidé de regrouper ceux des ensembles d'attributs qui étaient communs à plusieurs communautés d'utilisateurs dans une nouvelle architecture d'attributs, et de laisser ensuite chaque communauté développer les attributs spécifiques dont elle pourrait avoir besoin. Dans cette nouvelle architecture, deux ensemble d'attributs sont particulièrement importants : les " classes d'attributs " (Utility attribute set) et les " attributs interdisciplinaires " (Cross domain attribute set). La logique des classes d'attributs est la suivante : au lieu d'avoir à choisir parmi la liste des attributs d'usage de bib-1 entre " auteur personne physique " et " auteur ", la nouvelle classe d'attributs propose un point d'accès " nom ", qui est éventuellement précisé par un choix sémantique (" nom de personne "), un choix fonctionnel (" auteur "), etc. Quant aux attributs interdisciplinaires, il s'agit de réduire les points d'accès à un plus petit dénominateur commun qui garantira la " portabilité " de la recherche d'un domaine à l'autre : en fait, les points d'accès sont ici ramené à un ensemble de 11 attributs tirés du Dublin Core.
La logique d'ensemble de cette nouvelle architecture d'attributs est donc clairement de promouvoir l'interdisciplinarité et la généralité (non-spécificité) de la norme. C'est aussi la logique du Bath profile.

Le Bath profile

Le Bath profile est un profil Z39.50 officiel, créé en août 1999 et géré par la Bibliothèque Nationale du Canada.[5] C'est un profil modulable, qui identifie trois niveaux de " besoins fonctionnels " (functionnal requirements) :

Pour chaque domaine, le Bath profile propose plusieurs niveaux de conformité (conformance levels 0, 1 and 2), qui vont du moins au plus complexe.
Ainsi par exemple le domaine A niveau 0 permettra des recherches sur auteur, titre et sujet, tandis que le domaine A niveau 1 permettra en sus des recherches sur les mots clé en utilisant des troncatures.

De même pour ce qui est de l'affichage des données :

Il n'est pas possible d'entrer ici réellement dans le détail du Bath profile, mais la logique en est claire : du domaine A au domaine C ont s'éloigne de plus en plus des formats MARC et donc des bibliothèques, tandis que du niveau 0 au niveau 2 (qui n'est pas encore développé) ont enrichi les possibilités de recherche et d'affiche.
Pour une bibliothèque qui souhaiterait se doter grâce à Z39.50 d'une passerelle entre ses diverses ressources, un serveur Bath profile paramétré selon le domaine A, niveau 1 serait particulièrement intéressant puisqu'il permettrait de traiter tant des formats MARC (rien n'est perdu par rapport au profil bib-1 à ce niveau [7]) que du format XML.

ZNG : Z39.50 Next Generation

Tout ce qui précède concerne la norme telle qu'elle existe actuellement. ZNG, en revanche, n'a pas encore d'existence réelle en dehors des spécifications proposées par le ZIG lors de sa réunion de juin 2001.[8] ZNG vise à rendre compatible Z39.50 et les technologies web (XML et HTTP). C'est-à-dire qu'il s'agit de faciliter et simplifier l'implémentation de la norme tout en préservant ses acquis. Dit d'une autre façon encore : ZNG permet, tout en conservant la richesse de la norme, de sortir du cadre étroit des formats MARC dans lesquels elle a été essentiellement exploitée jusqu'à présent, pour travailler dans un espace " orienté web ", où les formats bibliographiques cohabiteront avec XML. Bref, c'est le grand toilettage.
Sans entrer dans trop de détails techniques, signalons les principaux changements apportés par ZNG.

L'innovation principale proposée par ZNG consiste peut-être à abandonner la notion de session : il n'y a plus de connexion permanente mais une série de séquences requête/réponse utilisant les commandes HTTP GET ou POST. Cependant, pour permettre la continuité du travail de recherche, le serveur conserve en mémoire l'ensemble résultat issu d'une requête ; il spécifie aussi dans sa réponse le nom qu'il attribue à cet ensemble d'une part, et d'autre part le temps pendant lequel il le conservera en mémoire. Si une nouvelle requête est effectuée sur l'ensemble résultat, le serveur défini une nouvelle durée de sauvegarde, et il n'efface l'ensemble résultat que si celui ci est inactif pendant le temps établi.
Conséquence de l'abandon de la notion de session au profit d'un fonctionnement requête/réponse de type web, les services Search et Present de Z39.50 sont supprimés et fusionnés dans un unique service Search/Retrieve. La requête comprendra principalement les informations suivantes :

La réponse envoyée par le serveur sera toujours en XML, éventuellement incluant un autre format pour les enregistrement (embedded database records) : par exemple, une notice UNIMARC encapsulée dans une réponse en XML.

Comme on le voit, ZNG, comme la nouvelle architecture d'attributs du Z39.50 classique ou le Bath Profile cherche à favoriser l'interopérabilité de la norme et à assurer son adaptation à l'environnement web dans lequel évoluent les systèmes d'information actuels.

  1. La norme est gérée par le Z39.50 Implementors Group (ZIG), dont l'activité est hébergée par la Bibliothèque du Congrès : cf. Z39.50 Maintenance Agency Cf. également National Information Standards Organisation : Z39.50 resource page
  2. Le "profil" correspond au paramètrage du serveur. Par analogie entre la norme Z39.50 et les normes bibliographiques, on pourrait dire que Z39.50 correspond au format MARC, et que les différents profils correspondent aux différents formats UNIMARC, USMARC, etc. La notion est détaillée plus loin.
  3. Cf. SCD Lyon 3. Profil du serveur Z39.50. Ou encore: SCD de l'Université de Reims. Profil Z39.50
  4. La Z39.50 Maintenance agency recense les record syntaxes retenus dans le cadre de la norme : cf. la liste à l'adresse http://lcweb.loc.gov/z3950/agency/defns/oids.html#5
  5. cf http://www.nlc-bnc.ca/bath/
  6. Cf Bibliothèque nationale du Canada. [The Bath profile] Appendix D: eXtensible Markup Language Document Type Definition for Dublin Core Simple.
  7. Si ce n'est le degré de précision de la recherche en MARC : mais l'exemple de la configuration du serveur de Lyon 3 laisse à penser que le profil bib-1 est trop riche et n'est que très partiellement utilisé.
  8. Pour ZNG, cf. Z39.50 Implementors Group. The ZNG Initiative

© 2001-2007 - nicolas.morin => gmail.com