Resumen

  • ALIWEB dejó en manos de cada proveedor de información la selección de los recursos que describía, pero mantuvo la recolección y las búsquedas en un servicio central.
  • El piloto de 1994 demuestra que otros catálogos podían aprovechar un índice pequeño; no prueba que cubriera toda la Web ni que tuviera una adopción amplia.

A finales de 1993, publicar un documento en la Web ya no bastaba. Había que poder encontrarlo sin recorrer servidor por servidor ni pedirle a un robot que descargara cada página accesible. Las listas manuales aportaban contexto, pero sus responsables no podían seguir cada cambio o nuevo servicio. Un robot podía descubrir más recursos, aunque a costa de repetir solicitudes a los servidores y de perder la estructura que daba sentido a una colección.

El 30 de noviembre de 1993, Martijn Koster presentó ALIWEB como un experimento de indexación web «distribuida». Cada servidor anunciaría su contenido en un archivo local; un único sitio recuperaría y procesaría esos archivos; después se podría consultar la base combinada desde la Web. Según el artículo de conferencia de Koster, el piloto ya funcionaba en NEXOR desde octubre. En su anuncio del 30 de noviembre, Koster lo describía como un primer paso, no como una solución definitiva, e incluía una promesa llamativa: cuando aparecieran sistemas mejores, los datos deberían poder reutilizarse o convertirse con facilidad.

Esa promesa ayuda a entender la arquitectura. ALIWEB no descentralizó el buscador; repartió el control sobre el índice. El administrador del sitio decidía qué documentos y servicios merecían una ficha y aportaba su descripción. El operador de ALIWEB conservaba la lista de servidores participantes, fijaba cuándo recuperar cada archivo, validaba su formato, reunía las fichas aceptadas y ejecutaba la interfaz de búsqueda. El proveedor describía su propio sitio; el servicio central controlaba el camino por el que esa descripción se volvía visible desde otros sitios.

La entrada era un archivo de texto preparado, a menudo llamado /site.idx, basado en plantillas de Internet Anonymous FTP Archives (IAFA). Esos registros de atributo y valor podían describir varios objetos en un mismo archivo: tipo de plantilla, título, URI, descripción y palabras clave, por ejemplo. ALIWEB no intentaba deducir el sentido de cada página a partir de su marcado. Permitía que quienes conocían la estructura del sitio eligieran sus puntos de entrada más útiles sin borrar la organización interna. El ejemplo de Koster describe el material de Perl de NEXOR y su manual, no todos los archivos del servidor.

Participar exigía, aun así, un pequeño acuerdo operativo. El administrador registraba el servidor, el puerto y la ruta del archivo; indicaba un contacto responsable y podía establecer un intervalo mínimo entre recuperaciones. ALIWEB comprobaba que el archivo existiera y tuviera el formato esperado antes de aceptar el registro. Un proceso Perl independiente revisaba los archivos registrados, recuperaba las versiones modificadas y reconstruía la base combinada mediante cron de UNIX. La misma base podía consultarse en el formulario web de ALIWEB o integrarse en otro catálogo, entre ellos el CUI W3 Catalog.

La diferencia frente a un robot que recorría la Web era operativa, no absoluta. ALIWEB automatizaba la recolección y la consolidación, pero descargaba un archivo de índice señalado por el administrador en vez de seguir todos los enlaces y documentos accesibles del servidor. Así reducía el tráfico y permitía conservar el contexto del proveedor. El precio era que una página ausente del índice podía seguir siendo invisible aunque un robot hubiera podido alcanzarla. La frescura dependía del archivo publicado tanto como del recolector central.

Las cifras del piloto que publicó Koster muestran su alcance y sus límites. Cuando escribió el artículo, había 54 equipos registrados y 310 entradas en la base. El formulario sencillo de ALIWEB recibía unas 80 consultas diarias; el CUI W3 Catalog recurría a esa base más de 8.000 veces por semana. Los datos prueban que había un servicio operativo y una integración útil. No miden qué proporción de la Web estaba indexada, la calidad de los resultados ni cuántos servidores podían o querían mantener un archivo válido.

La dificultad de incorporación apareció pronto. Algunos administradores registraban un servidor sin aportar su índice, aparentemente porque habían llegado al formulario sin comprender el mecanismo. El equipo amplió la documentación y añadió comprobaciones inmediatas de presencia y formato. Persistían errores; el sistema los registraba y un programa ejecutado manualmente enviaba un correo a la persona responsable. No era una descentralización sin mantenimiento: el trabajo pasaba de rastrear cada página a crear, validar y actualizar un índice selectivo.

«Manual» tampoco significaba necesariamente que alguien tuviera que escribir cada línea a mano. Koster aceptaba que el archivo lo generara un programa siempre que conservara metadatos suficientes para filtrar los resultados. En 1995, otro proyecto de archivo documentó plantillas IAFA actualizadas a partir de cambios en el sistema de archivos y convertidas en índices de texto, Gopher y HTML. Ese artículo de la conferencia del W3C muestra que la plantilla podía alimentar distintas vistas; no demuestra que el corpus de ALIWEB migrara ni que el servicio alcanzara una adopción amplia.

El crecimiento planteaba un segundo límite. Koster reconocía que una base única para toda la Web podía volverse demasiado grande. Propuso repartir la recolección, duplicar el acceso a las búsquedas, separar bases por tema o crear una jerarquía de servicios ALIWEB. También esperaba que los archivos pudieran convertirse automáticamente a futuros sistemas de directorios. Eran posibilidades planteadas en el artículo, no funciones cuyo despliegue esté documentado. Su valor histórico está en que el formato debía sobrevivir al recolector central del piloto.

Una encuesta de 1994 sobre recuperación de información en red describía un campo todavía joven, donde la clasificación y otras prestaciones no estaban muy extendidas. ALIWEB convivía con listas manuales, el CUI W3 Catalog y enfoques con robots como JumpStation y la base de URL de RBSE; no fue la primera herramienta de búsqueda de la Web. Su aportación más acotada fue mostrar cómo las descripciones elegidas en origen podían recolectarse automáticamente y reutilizarse en otros sistemas.

La Nota 65 de Heng Lu sobre la primacía del código en funcionamiento sirve como lectura retrospectiva, no como prueba de lo que pensaba Koster: un formato puede prometer portabilidad, pero solo los sistemas que lo adoptan y ejecutan la vuelven real. El artículo documenta el piloto en funcionamiento y una integración con el W3 Catalog. No documenta adopción universal, un mandato sobre los editores web ni una migración completada. La distinción útil es triple: los proveedores decidían qué decía su sitio; ALIWEB decidía qué entraba en el índice compartido; y los sistemas futuros podían reutilizar el archivo sin heredar el servicio central del piloto.