Resumen

  • La consulta Type-3 de WAIS descrita en RFC 1625 podía incluir las palabras iniciales del lector y un documento completo o un fragmento elegido como retroalimentación; el servidor respondía con citas ordenadas, no con los documentos.
  • El servidor no guardaba el conjunto de resultados para presentarlo más tarde. Para recuperar una cita, el cliente enviaba otra petición Search con Doc-ID, formato y, si hacía falta, un intervalo de bytes, líneas o párrafos.
  • RFC 1625 definió la interfaz de consulta y respuesta; no estableció una escala de relevancia comparable entre servidores, un censo completo de instalaciones ni la causa del posterior declive de WAIS.

El documento pasó a formar parte de la pregunta

En junio de 1994, una nota informativa describió cómo WAIS utilizaba Z39.50-1988. El propio documento advertía que no era una norma de Internet. Su propósito era concreto: mantener sencilla la conversación entre cliente y servidor. El cliente podía enviar el texto escrito por el usuario sin convertirlo en una consulta Type-1 específica ni conocer todos los atributos Z39.50 que aceptaba cada servidor.

WAIS llamó Type-3 a esa consulta en texto libre. Sin embargo, no era una cadena de palabras aislada. Podía combinar los “seed words” —el texto inicial del usuario— con una lista de objetos documentales. Cada objeto podía ser el documento entero o una parte, y llevaba Doc-ID, tipo, código de fragmentación y posiciones inicial y final. El código especificaba si el intervalo se medía en bytes, líneas o párrafos.

Ese segundo componente permitía la retroalimentación por relevancia: seleccionar un documento o parte de él y pedir otros parecidos. El cliente no necesitaba convertir primero el pasaje en una bolsa de términos y luego perder el objeto que había motivado la búsqueda. Podía enviarlo como parte de la siguiente consulta, junto con cualquier texto adicional. El servidor conservaba el control sobre cómo buscar en su propia base; el protocolo indicaba qué podía cruzar la interfaz, no imponía un algoritmo idéntico a todos los índices.

No es lo mismo que decir que “Internet aprendió a buscar”. WAIS era un sistema de recuperación de información en red, con clientes, servidores, bases de datos y protocolo. El informe de herramientas de RFC 1689, de agosto de 1994, describió que los primeros clientes WAIS aceptaban consultas en lenguaje natural y consignó más de cien bases de datos y 5.000 usuarios en todo el mundo. Son cifras de un informe contemporáneo, no un censo auditado por separado ni una medida de adopción posterior.

Una clasificación no era el documento

La respuesta del servidor era una lista de WAIS Citations. Cada cita podía incluir un titular, una puntuación de relevancia, formatos disponibles, Doc-ID y longitud en bytes. RFC 1625 normalizó la puntuación más alta a 1.000. Eso permitía ordenar una respuesta; no hacía comparables los valores de servidores distintos, no demostraba que el primer resultado fuese correcto ni acreditaba que el lector hubiera encontrado lo que buscaba.

La cita señalaba un objeto alojado en un servidor, pero no contenía su cuerpo. Esa diferencia determinaba el siguiente paso. RFC 1625 describe WAIS como un sistema sin estado: el servidor no almacenaba el conjunto de resultados y podía borrarlo al enviar la respuesta. Por ello, WAIS no utilizaba la función Present de Z39.50 en este recorrido. Para obtener el elemento elegido, el cliente enviaba una nueva petición Search mediante una consulta Type-1 que indicaba Doc-ID y formato. Podía añadir posiciones de inicio y fin.

La respuesta de recuperación podía ser un documento o solo una parte. RFC 1625 explica que los textos extensos y las imágenes podían superar el búfer de recepción del cliente; por eso se podía pedir el contenido por fragmentos. Es una razón de diseño y una opción, no la prueba de que todos los clientes dividieran cada descarga. Un pasaje solicitado tampoco equivalía automáticamente al documento íntegro: había que comprobar qué intervalo se pidió y cuál se recibió.

Quedan así tres registros distintos: lo que aportó el lector, lo que clasificó el servidor y lo que el cliente recuperó después. Type-3 combinaba palabras escritas y un pasaje seleccionado. La cita apuntaba a un formato de un objeto concreto. Una segunda petición obtenía un tramo delimitado. Llamar a todo ello un único “resultado” borra las fronteras entre interpretación, almacenamiento y recuperación.

La dirección también tenía un ámbito

La especificación de URL publicada más tarde, en 1994, definió formas wais: distintas para una base, una búsqueda dentro de ella y un documento individual. También aclaró que ese esquema no servía para direccionar cualquier servicio Z39.50. La sintaxis hacía explícitos el servicio y el tipo de destino; no convertía cada cita en un recurso disponible desde cualquier lugar.

En 2005, otra RFC conservó el esquema URI histórico wais: y añadió una nota de estado: el protocolo no estaba ampliamente implementado y casi no quedaban servidores WAIS en uso. Es una observación fechada, no una explicación causal. Los documentos disponibles no permiten atribuir el declive a un sucesor concreto ni afirmar que el ciclo de retroalimentación causara la adopción general de la búsqueda en Internet.

El antecedente más próximo en esta serie es el artículo de Sofia Ren sobre la bibliografía de libros de RFC 1432: allí la pregunta era si una ficha, un precio o un contacto todavía permitían conseguir una obra. Aquí el foco está en otra capa: cómo un documento seleccionado entraba en la consulta siguiente, cómo el servidor ordenaba las citas y cómo el cliente pedía después un objeto y un intervalo. La tesis es el mecanismo del protocolo, no la vigencia del catálogo.

Fuentes y límites de la evidencia

La fuente principal es RFC 1625, con contexto contemporáneo en RFC 1689. El límite del esquema URI aparece en RFC 1738; la nota histórica posterior, en RFC 4156. Ninguno ofrece un censo completo de implementaciones, una comparación de puntuaciones entre servidores o una explicación causal del declive de WAIS.