Resumo

  • A consulta Type-3 da WAIS, descrita na RFC 1625, podia levar tanto as palavras iniciais do leitor quanto um documento inteiro ou trecho selecionado como feedback de relevância; o servidor devolvia citações ordenadas, não os documentos.
  • O servidor não guardava o conjunto de resultados para uma apresentação posterior. Para obter uma citação, o cliente enviava outra solicitação Search com Doc-ID, formato e, se necessário, um intervalo de bytes, linhas ou parágrafos.
  • A RFC 1625 definiu a interface entre consulta e resposta, não uma escala de relevância comparável entre servidores, um inventário completo de instalações nem uma explicação para o declínio posterior da WAIS.

O documento entrou na pergunta

Em junho de 1994, uma RFC informativa descreveu como a WAIS usava o Z39.50-1988. O texto afirmou expressamente que não especificava um Internet Standard. Uma preocupação prática era manter simples a interface entre cliente e servidor: o cliente poderia enviar o texto do leitor sem transformá-lo em uma consulta Type-1 específica do servidor nem conhecer todos os atributos Z39.50 aceitos por ele.

A WAIS chamou esse formato de texto livre de consulta Type-3. Mas a consulta não era uma frase isolada. Podia combinar as palavras iniciais (“seed words”) digitadas pelo leitor com uma lista de objetos documentais. Cada objeto podia ser o documento inteiro ou uma parte dele e trazia Doc-ID, tipo, código de fragmentação e posições inicial e final. O código indicava se a faixa era medida em bytes, linhas ou parágrafos.

Esse segundo componente permitia o feedback de relevância: selecionar um documento ou trecho e procurar outros semelhantes. O cliente não precisava primeiro reduzir o trecho a palavras-chave e depois descartar o material que motivou a busca. Podia enviar o próprio objeto na consulta seguinte, junto com o texto digitado. O servidor continuava responsável por pesquisar sua base; o protocolo dizia o que poderia atravessar a interface, sem impor um algoritmo de classificação idêntico para todos os índices.

Essa história é mais específica do que dizer que “a Internet aprendeu a pesquisar”. A WAIS era um sistema de recuperação de informação em rede formado por clientes, servidores, bases de dados e protocolo. O relatório de ferramentas da RFC 1689, de agosto de 1994, descreveu os primeiros clientes WAIS como capazes de receber consultas em linguagem natural e registrou mais de 100 bases de dados e 5.000 usuários no mundo. São números de um relatório contemporâneo sobre ferramentas, não um censo auditado de forma independente nem uma medida da adoção posterior.

Uma classificação não era a resposta

A resposta do servidor trazia uma lista de WAIS Citations. Cada citação podia incluir uma manchete, uma classificação de relevância, formatos disponíveis, Doc-ID e comprimento em bytes. A RFC 1625 normalizou a pontuação máxima para 1.000. Isso ajudava a ordenar os itens de uma resposta; não tornava comparáveis as pontuações de servidores diferentes, não provava que o primeiro documento fosse objetivamente relevante e não mostrava que o leitor encontrara uma resposta útil.

A citação apontava para um objeto no servidor, mas não carregava seu conteúdo. Essa diferença definia a recuperação. A RFC 1625 descreveu a WAIS como stateless: o servidor não armazenava o conjunto de resultados e podia apagá-lo assim que enviasse a resposta. Por isso, a WAIS não usava o recurso Present do Z39.50 nesse fluxo. Para obter o item escolhido, o cliente enviava outra solicitação Search, desta vez com uma consulta Type-1 que informava Doc-ID e formato desejado. Também podia indicar posições inicial e final.

A resposta de recuperação podia conter um documento ou apenas uma parte. A RFC explica que textos completos e imagens podiam ultrapassar o buffer de recebimento do cliente; por isso, era possível pedir o conteúdo em blocos. Essa é uma justificativa de projeto e uma opção, não a prova de que todo cliente fazia a recuperação por partes. Receber o trecho solicitado também não significa que o documento completo foi obtido: é preciso comparar o intervalo pedido com o efetivamente retornado.

Há, portanto, três registros: o que o leitor enviou, o que o servidor ordenou e o que o cliente recuperou depois. A busca Type-3 podia reunir palavras digitadas e um trecho escolhido. A citação indicava um formato de um objeto mantido no servidor. Uma segunda solicitação obtinha uma faixa delimitada. Tratar as três etapas como um único “resultado de busca” apaga onde a interpretação, o armazenamento e a recuperação aconteceram.

O endereço tinha um contexto próprio

A especificação de URLs publicada mais tarde em 1994 definiu formas wais: para uma base de dados, uma busca dentro dela e um documento específico. Também advertiu que essa URL não servia como endereço genérico para qualquer serviço Z39.50. O esquema identificava o serviço e o tipo de destino; não tornava toda citação um recurso acessível em qualquer lugar.

Em 2005, outra RFC preservou o esquema histórico de URI wais: e acrescentou uma observação curta: o protocolo WAIS não havia sido amplamente implementado e quase não restavam servidores em uso. É um registro de estado datado, não uma explicação para o declínio. As fontes disponíveis não permitem atribuí-lo a um sucessor específico nem dizer que o ciclo de feedback causou a adoção geral da busca na Web.

O paralelo mais próximo nesta série é o artigo de Sofia Ren sobre a bibliografia de livros da RFC 1432, de 1993: ali a questão era se um registro, preço ou contato ainda ajudava alguém a obter um livro. Este artigo trata de outra camada: como o documento escolhido entrava na próxima consulta, como o servidor ordenava as citações e como o cliente pedia depois um objeto e um intervalo. A tese aqui é o mecanismo do protocolo, não a atualização do catálogo.

Fontes e limites da evidência

A fonte principal é a RFC 1625, com contexto contemporâneo na RFC 1689. O limite do esquema URI aparece na RFC 1738; a observação histórica posterior, na RFC 4156. Nenhuma delas apresenta um inventário completo de implementações, uma comparação de pontuações entre servidores ou uma história causal do declínio da WAIS.