Résumé

  • La requête WAIS de type 3 décrite par la RFC 1625 pouvait contenir à la fois le texte saisi par le lecteur et un document entier ou une partie choisie comme retour de pertinence ; le serveur répondait par des citations classées, pas par les documents.
  • Le serveur ne conservait pas l’ensemble de résultats pour une présentation ultérieure. Pour récupérer une citation, le client envoyait une nouvelle requête Search avec le Doc-ID, le format et, si nécessaire, une plage d’octets, de lignes ou de paragraphes.
  • La RFC définissait l’enveloppe de la requête et de la réponse, pas une échelle de pertinence comparable partout, un recensement complet des déploiements ni une explication du recul ultérieur de WAIS.

Le document entrait dans la question

En juin 1994, une note informative décrivait la manière dont WAIS utilisait Z39.50-1988. Elle précisait expressément qu’elle ne définissait aucune norme Internet. Son objectif était pragmatique : maintenir une interface simple entre le client et le serveur. Le client pouvait transmettre le texte du lecteur sans le convertir en requête Type 1 propre au serveur ni connaître tous les attributs Z39.50 que celui-ci prenait en charge.

WAIS appelait cette forme en texte libre une requête Type 3. Mais la requête ne se réduisait pas à une chaîne. Elle pouvait réunir des « mots de départ » saisis par le lecteur et une liste d’objets documentaires. Un objet pouvait être un document complet ou un extrait, repéré par un Doc-ID, un type, un code de découpage et des positions de début et de fin. Le code indiquait si la plage se mesurait en octets, en lignes ou en paragraphes.

Ce second apport permettait le retour de pertinence : sélectionner un document ou une partie, puis rechercher des documents qui lui ressemblent. Le client n’avait pas à réduire lui-même le passage en mots-clés avant de l’oublier. Le passage pouvait entrer comme objet dans la requête suivante, à côté du texte saisi. Le serveur restait maître de la recherche dans sa base ; le protocole décrivait ce qui franchissait l’interface, pas un algorithme de classement universel appliqué par chaque index.

C’est une histoire plus précise que « l’Internet a appris à chercher ». WAIS était un système de recherche documentaire en réseau, avec clients, serveurs, bases de données et protocole. Le rapport d’état de la RFC 1689, publié en août 1994, indique que les premiers clients WAIS acceptaient des requêtes en langage naturel et mentionne plus de 100 bases et 5 000 utilisateurs dans le monde. Ce sont les chiffres d’un rapport contemporain sur les outils, pas un recensement indépendant ni une mesure de l’adoption ultérieure.

Le rang n’était pas la réponse

Le serveur renvoyait des WAIS Citations. Chacune pouvait inclure un titre, un rang de pertinence, les formats disponibles, un Doc-ID et une longueur en octets. La RFC normalisait le meilleur score à 1 000. Cela rendait une liste ordonnée lisible ; cela ne rendait pas comparables deux scores issus de serveurs distincts, ne prouvait pas que le premier document était objectivement pertinent et ne montrait pas que le lecteur avait trouvé une réponse utile.

Une citation désignait un objet sur un serveur ; elle n’en contenait pas le corps. Cette distinction déterminait la récupération. La RFC 1625 décrit WAIS comme sans état : le serveur ne stockait pas l’ensemble de résultats et pouvait le supprimer après avoir envoyé sa réponse. WAIS n’utilisait donc pas la fonction Present de Z39.50 pour ce parcours. Pour obtenir l’élément choisi, le client envoyait une nouvelle requête Search, cette fois avec une requête Type 1 qui indiquait le Doc-ID et le format voulu. Des termes de plage pouvaient fixer le début et la fin.

La réponse pouvait contenir le document ou seulement une partie. La RFC explique que le texte intégral et les images pouvaient dépasser le tampon de réception du client ; celui-ci pouvait donc demander des fragments. C’est la justification de la conception et une possibilité, pas la preuve que tous les clients procédaient ainsi. Un extrait n’était pas automatiquement le document complet : la plage demandée et celle effectivement renvoyée restaient à vérifier.

Trois traces se distinguent donc : les éléments fournis par le lecteur, les citations classées par le serveur et ce que le client récupérait ensuite. La requête Type 3 pouvait associer des mots saisis à un passage sélectionné. La citation pouvait pointer vers un format précis d’un objet hébergé. Une seconde requête rapportait une portion bornée. Tout réduire à un seul « résultat de recherche » masque le lieu où l’interprétation, le stockage et la récupération avaient lieu.

L’identifiant gardait son contexte

La spécification des URL publiée plus tard en 1994 donna à WAIS des formes distinctes pour désigner une base, une recherche dans cette base ou un document précis. Elle indiquait aussi qu’une URL wais: ne servait pas d’adresse générale à n’importe quel service Z39.50. Le schéma précisait le service et la nature de la cible ; il ne rendait pas toute citation accessible partout.

En 2005, une mise à jour conserva le schéma d’URI historique wais: et ajouta une note brève : le protocole WAIS n’était pas largement implémenté et presque aucun serveur WAIS n’était alors en service. Ce constat documente l’état décrit à cette date, sans expliquer ses causes. Les sources disponibles ne permettent pas d’affirmer qu’un successeur particulier l’a évincé ou que cette boucle de pertinence a provoqué l’adoption générale de la recherche en ligne.

Le voisin le plus proche dans cette série est l’article de Sofia Ren consacré à la bibliographie de livres de la RFC 1432 en 1993 : il demande si un livre, un prix ou un contact restait disponible. Le présent texte traite d’une autre couche : comment un document sélectionné alimentait une nouvelle requête, comment le serveur classait les citations et comment le client indiquait l’objet et la plage à récupérer. Il s’agit du mécanisme de recherche, pas de la fraîcheur du catalogue.

Sources et limites des preuves

La source principale est la RFC 1625, éclairée par le rapport contemporain RFC 1689. La limite des URI figure dans la RFC 1738 ; la note historique ultérieure se trouve dans la RFC 4156. Ces documents ne fournissent ni recensement complet des implémentations, ni référence de classement entre serveurs, ni histoire causale du recul de WAIS.