2. Information retrieval:
strumenti e strategie
4. Biblioteche e Opac
nel mondo
5. Biblioteche e Opac
in Italia
7. Le biblioteche
e gli Opac statunitensi
8. Opac specializzati,
archivi e musei
10. Banche dati: archivi
e host computer in Internet
11. Metarisorse generali
e informazioni per bibliotecari
Parte prima – Concetti e strumenti
2. Information retrieval: strumenti e strategie
[Introduzione]
Url, gli Uniform resource locator
Telnet, l'emulazione di terminale
L'architettura client/server
Www e ipertestualità
Dai Wais ai gateway Z39.50
Diacritici e caratteri accentati
Information retrieval, strategie di ricerca e operatori logici
Il raffinamento delle ricerche
Visualizzazione, ordinamento, scarico e stampa dei risultati
L'evoluzione delle interfacce tra caratteri e grafica
Altre interfacce: Wap e ambienti in 3D
Il futuro dell'information retrieval
I Wais (Wide area information service), come i Gopher e i Www, costituiscono uno strumento di Nir con architettura client/server e distribuita. Il protocollo usato in questo caso si chiama Z39.50, ed è uno standard di Ansi/Niso (un'organizzazione statunitense). Come i Gopher, i Wais sono stati sviluppati nel 1991 e sono lentamente scomparsi in quanto servizi a sé stanti dopo il 1994, sostituiti dal Www o comunque integrati nella rete dei Web.
Se i Wais come sistemi autonomi sono stati abbandonati, il loro protocollo, Z39.50, ha invece continuato ad evolversi, producendo interessanti risultati proprio nel caso delle risorse bibliografiche, con gateway tra Z39.50 e Http in grado di garantire l'accesso agli archivi mediante semplici interfacce Web. In pratica, gli utenti possono utilizzare un normale browser come Netscape o Explorer per interrogare le banche dati e i cataloghi che supportano lo standard Z39.50, ricercando i termini in tutti i campi in cui si articolano i record bibliografici, cumulativamente, oppure, sempre più spesso, campo per campo. Con Z39.50 è inoltre possibile la creazione di archivi indicizzati in full text, a testo completo, in modo abbastanza semplice. Il protocollo Z39.50, in definitiva, consente di usare delle funzioni di ricerca più complete di quelle che sarebbero possibili sfruttando soltanto il protocollo Http del Web.
Il posto degli ormai scomparsi Wais è stato preso dagli Zclient, dei software con architettura client/server sviluppati sfruttando il protocollo Z39.50 in modo più completo di quanto facessero i Wais. Tra questi, si ricordano per esempio Znavigator o Icone, prodotti disponibili in prova o gratuitamente. L’uso di questi e altri Zclient, a volte mai usciti dalla fase sperimentale, è consigliato solo per alcuni Opac o nel caso di ricerche particolari e molto sofisticate; in linea di massima, infatti, le interfacce di interrogazione dei cataloghi vengono ormai realizzate tramite dei gateway che non richiedono l’uso di uno specifico client Z39.50, ma che, come si è detto, sono utilizzabili tramite qualsiasi browser Web. Per i ricercatori più esperti, informazioni complete su Z39.50 si trovano a partire dall’indirizzo <http://www.niso.org/>. Dalla pagina <http://www.loc.gov/> è invece possibile informarsi su una serie di progetti e iniziative raccolti sotto la sigla Zing (Z39.50-international: next generation) finalizzati alla diffusione del protocollo Z39.50 in ambiti più estesi degli attuali, potenziandone le caratteristiche e aumentandone la versatilità.
Quanto detto fino a questo punto su Z39.50 è già sufficiente per utilizzare i gateway esistenti; per completezza si descrivono ancora i principali limiti tecnici legati all'impiego di questi strumenti, informazioni la cui conoscenza può comunque essere utile a chi, volendo interrogare un Opac, si trovi di fronte a un'interfaccia Http/Z39.50.
Il protocollo Z39.50 permette di interrogare più archivi, uno alla volta o contemporaneamente, attraverso una singola interfaccia e un singolo linguaggio di interrogazione, ottenendo risultati omogenei e semplificando le procedure di scarico e di stampa dei dati. Nel caso vengano interrogati più archivi, la ricerca eseguita tramite un gateway risulta però appiattita in direzione del minimo comun denominatore fra gli archivi stessi: tra un archivio che ha una struttura più complessa e uno che ha una struttura più semplice, un'interfaccia unificata realizzata con un Web si conforma di solito alla struttura più semplice.
Purtroppo l'utilizzo di gateway tra Http e Z39.50 sottopone quest'ultimo protocollo anche ad un notevole limite tecnico del primo, riducendo le possibilità di quella che è probabilmente la caratteristica più interessante dello Z39.50, ovvero la possibilità di «memorizzare» la sessione in corso e i suoi risultati.
Uno dei punti centrali e più controversi nelle passate implementazioni dei Wais e nelle attuali applicazioni del protocollo Z39.50, infatti, è la creazione o meno di connessioni «con una memoria». Il gopher protocol e l'Http sono «stateless»: ad ogni singola richiesta del client viene aperta una connessione che viene immediatamente chiusa non appena il client ha ricevuto la risposta. All'estremo opposto si trova il funzionamento di Telnet, che stabilisce una connessione permanente tra il calcolatore che contiene i dati e il terminale dell'utente, proprio come se quest'ultimo fosse un terminale di quel sistema; con Telnet, quindi, l'utente può avere a disposizione per tutta la sessione e fino alla chiusura del comando Telnet un'area dati personale in cui possono essere memorizzati i risultati delle sue prime ricerche. Con Telnet, la persistenza dello «stato» della connessione con l'archivio permette di sfruttare meglio e più a fondo le tecniche di raffinamento della ricerca per fasi successive, con algoritmi di ordinamento dei risultati, o utilizzando vari tipi di feedback, o ancora usando dei comandi per la creazione di subset personali del catalogo, ad esempio limitati per lingua e per data di pubblicazione.
I vecchi Wais creavano delle connessioni permanenti, in parte simili, da questo punto di vista, alle sessioni Telnet; i gateway tra Z39.50 e Web, invece, fino a poco tempo fa hanno dovuto sottostare alla natura stateless del protocollo Http, dove ogni richiesta viene trattata come se fosse la prima e l'unica, in modo atomico, senza che il sistema possa in qualche modo tenerne traccia. Le ultime realizzazioni di gateway sono tuttavia in grado di superare anche questo limite, costringendo il protocollo Http a simulare un comportamento «stateful». Del resto, anche tutte le implementazioni di applicazioni Web, oggi diffusissime, hanno sviluppato da tempo tecniche molto sofisticate per simulare delle sessioni continue e prolungate o addirittura interrotte e riprese - si pensi per esempio alla gestione di un carrello per gli acquisti on line - conservando in memoria i dati dell'utente e quindi superando l'atomicità che sarebbe caratteristica della navigazione con Http.