Lo studio che presentiamo si inserisce in un contesto di ricerca, quello sul reference virtuale, relativamente gio­vane poiché la sua storia comincia circa trent’anni fa.

Per dare un riferimento più preciso, segnaliamo che nel 2006 B. Sloan pubblica Twenty years of virtual re­ference in cui, riferendosi al report relativo a un studio del 1986 sull’uso dell’e-mail dell’Health Sciences Cen­ter come strumento di reference, ricorda quello che egli stesso definisce essere una pietra miliare: «[…] what I believe may be the first journal article devoted to virtual reference». A nostro avviso, l’altro passag­gio storico significativo di questo ambito disciplinare si verifica intorno alla fine degli anni Novanta, quando il reference virtuale vive una svolta decidendo di usare le live chat come mezzo di comunicazione con i propri utenti.

Si amplia a questo punto il concetto di virtual (o digital) reference, che acquisisce due nuovi attributi: sincrono e asincrono. Taher descrive in maniera molto semplice e chiara la differenza tra le due tipologie di assistenza, usando come punto di vista preferenziale l’intervista all’utente:

L’assistenza online e in tempo reale ha posto imme­diatamente i bibliotecari di fronte alle difficoltà di con­durre un’intervista non in compresenza con l’utente. La comunità si è dovuta orientare tra nuove modalità di comunicazione e interazione. In modo particolare negli Stati Uniti, dove Lankes nel 2004 testimonia una fervente attività attorno al digital reference, si moltiplicano gli studi relativi alla gestione delle interviste all’utenza e le abilità necessarie ai bibliotecari per po­ter affrontare il nuovo mezzo di assistenza. Nel 2002 l’IFLA pubblica la prima edizione delle linee guida per il reference digitale.

Il reference digitale sincrono comincia a essere esplo­rato nelle nuove possibilità che offre: nel 2003 Marstel­ler e Mizzy studiano le trascrizioni delle conversazioni del primo anno completo di attività della chat della Carnegie Mellon University. In particolare analizzano le differenti tipologie delle richieste degli utenti, delle domande dei bibliotecari e delle risposte degli utenti. Si scontrano però con una carenza di strumenti di­sponibili per questo tipo di lavoro: la letteratura offre ancora pochi studi sui metodi di analisi, soprattutto quelli elaborati non risultano standardizzati:

Quindi i due autori sviluppano uno schema che categorizzi le diverse tipologie di domande e risposte ot­tenute dalle trascrizioni. I dati ricavati dalla loro analisi vengono registrati in un foglio di calcolo e analizzati con l’aiuto degli statistici.

Nello stesso anno, sempre alla Carnegie Mellon, Gerlich e Berard lanciano la sperimentazione della READ Scale, una scala divisa in sei livelli di competenza ri­chiesta al bibliotecario per fornire il servizio di referen­ce appropriato alla domanda ricevuta.

Un anno più tardi Hirko e Ross propongono un ac­curato manuale sulla formazione per i bibliotecari di reference virtuale, che fornisce appendici con esercizi, esempi di transazioni tra bibliotecari e utenti, strumenti per migliorare l’utilizzo di hardware, software e glossari. Sempre nel 2004 la Reference User and Service Association (RUSA) divulga le Guidelines for implementing and maintaining virtual reference services.

Per diversi anni gli studi sul reference digitale sincrono si concentrano sulle competenze da sviluppare da par­te dei bibliotecari e per comprendere i comportamenti degli utenti. Ogni ricerca elabora una propria proce­dura di analisi, ma i procedimenti sono difficilmente ripetibili perché basati essenzialmente su un’iniziale lettura ed etichettatura delle conversazioni pressoché manuali, per poi riportare i dati rilevati in software che li rielaborino e li valutino da un punto di vista statistico. Presso la Biblioteca di Giurisprudenza dell’Univer­sità di Georgetown, Morais e Sampson producono un’analisi dei contenuti delle conversazioni avvenute tramite chat: osservano i comportamenti tenuti dagli utenti e dai bibliotecari per comprendere le tipologie di domande dei primi e quindi classificare i loro bisogni informativi. In questo caso gli autori hanno stampato le conversazioni e uno staff selezionato si è occupato di classificare le chat per tipologie secondo criteri prestabiliti.

Il reference digitale, dove le live chat acquisiscono un peso sempre maggiore, costituisce un bacino estremamente ricco di informazioni e di dati cui ricorrere per interpretare, sviluppare e migliorare i servizi di as­sistenza all’utenza. Per esempio forniscono dati per migliorare l’usabilità dei siti delle biblioteche, ma sempre attraverso una preliminare analisi manuale, con successiva codifica della tipologia dei contenuti; infine i dati ottenuti sono trattati con diversi software per fare un conteggio statistico e poi frequenziale.

Fino a questo punto abbiamo potuto osservare come, principalmente in ambito statunitense, le trascrizioni delle chat siano state analizzate da un punto prevalen­temente manuale e statistico, per poter comprendere i bisogni informativi dell’utenza o per meglio definire l’impiego o la formazione del personale bibliotecario addetto al reference digitale.

Una voce fuori dal coro è Mungin, che in un recente studio concentra le sue attenzioni non su un obiettivo prestabilito, ma utilizza un’analisi dei dati prettamente qualitativa al fine di individuare le criticità del servizio:

In Europa l’introduzione di sistemi di virtual reference basati su chat è avvenuta solo successivamente. Nel 2002 Bakker presenta un progetto olandese di imple­mentazione di virtual reference attraverso il software QuestionPoint cui intende partecipare la Royal Library. Rösch nel 2003 illustra una panoramica sull’atti­vazione del servizio di virtual reference in alcune bi­blioteche universitarie tedesche. In Spagna, presso la biblioteca dell’Universidad de Sevilla, nel 2009 è stato avviato un progetto di implementazione del vir­tual reference utilizzando LibraryH3lp. In Inghilterra una pubblicazione di Haerkoenen, Blackmore e Be­adle descrive l’attivazione di un servizio di live chat alla Cardiff University.

La scena universitaria italiana registra un numero an­cora esiguo di progetti legati all’utilizzo di strumenti di assistenza sincrona operati online. Al momento i siste­mi bibliotecari di ateneo delle università di Parma e di Torino sono esempi di realtà che offrono ai loro utenti un servizio di live reference dedicato.

Per quanto riguarda l’aspetto relativo al monitoraggio dei servizi di virtual reference legati alla chat sincrona, ci sembra doveroso precisare che a differenza della fervida attività statunitense, in Europa vi è scarsa trac­cia di progetti analoghi. Uno dei più significativi, og­getto di un articolo del 2014, consiste nell’analisi del servizio di reference online offerto dall’Universidad de Sevilla in cui, basandosi sulla scala READ, viene esa­minata la diversa tipologia delle richieste degli utenti. A differenza dei progetti di analisi già citati, tutti orien­tati in primo luogo al miglioramento della qualità della comunicazione tra utente e operatore, la ricerca og­getto del presente articolo si colloca all’interno di una tipologia prettamente legata all’analisi di tipo quantita­tivo e statistico volta alla creazione automatica di FAQ (frequently asked questions). In letteratura, lo studio che per finalità si inserisce in una posizione maggior­mente affine alla nostra è quello sviluppato nel 2009 dalla University of Notre Dame (USA) da Jones, Kayongo e Scofield. Nel progetto in questione, l’analisi delle conversazioni di reference tramite chat è stata utilizzata al fine di produrre una lista di FAQ che, a differenza della semplice esposizione su una pagina web in formato elenco, consenta di consultare le FAQ stesse attraverso un motore di ricerca.

Il Sistema bibliotecario dell’Università degli studi di To­rino, da quando ha inaugurato il servizio di reference digitale sincrono, ha potuto raccogliere moltissimi dati grazie alle caratteristiche del software adottato che salva le conversazioni in log. I dati cui ci si riferisce nel lavoro oggetto del presente articolo sono i contenuti stessi delle conversazioni.

La combinazione di due professioni, il bibliotecario di reference e il linguista computazionale, ha permesso un’inversione delle azioni di indagine finora descritte nella letteratura citata. Il punto di partenza sono state l’analisi e l’estrazione automatica di informazioni. Solo successivamente è stato necessario un intervento manuale che all’interno del nostro progetto ha portato alla produzione di FAQ.

Il Sistema bibliotecario di ateneo dell’Università di To­rino ha lanciato il servizio di reference sincrono il 20 gennaio 2014 nell’ambito dell’uscita in produzione di TUTTO, nome con cui si è ribattezzato il discovery tool Primo di Ex Libris. La chat si serve del softwa­re statunitense SnapEngage, semplice e intuitivo da installare e usare: a differenza degli instant messenger (per esempio Skype) non richiede necessariamente la creazione da parte dell’utente di un account né di una comunità di contatti per poter comunicare con gli altri. TUTTO, certamente molto intuitivo nelle sue funzioni, era una novità per gli utenti dell’Università di Torino (da ora in avanti UniTO). In quanto punto di accesso uni­ficato alle risorse bibliografiche di UniTO, per la prima volta presentava agli utenti una ricerca integrata: con un’unica interfaccia infatti diventava possibile ricercare i dati bibliografici provenienti sia dal catalogo, sia dalle piattaforme editoriali. Questo richiedeva però alcune abilità nel reperimento dei documenti, per esempio saper distinguere tra risorse elettroniche e cartacee, capire come accedere al documento selezionato, sa­pere applicare filtri ecc.

Per un bibliotecario, queste sono le consuete difficoltà di un utente, ma nel caso di TUTTO è importante con­siderare che ci trovavamo in un ambiente differente da quello della biblioteca fisica: il discovery è del tutto simile a un motore di ricerca con un singolo box dove inserire i termini e con la possibilità di cercare e di col­legarsi a documenti di diverse nature.

Ciò comporta alcuni presupposti quali la capacità dell’utente di sapersi orientare in un ambiente proget­tato con un proprio linguaggio e con particolari mo­dalità di accesso agli oggetti in esso contenuti. Per questo come è importante imparare a orientarsi nella biblioteca fisica, interpretandone il linguaggio, le scrit­te esplicative e le modalità di accesso ai documenti in essa disponibili, così la chat in TUTTO era necessaria per aiutare gli utenti a capire le indicazioni bibliografi­che e in che “direzione” andare per reperire i contenu­ti. Inoltre qualcuno doveva fornire le “chiavi” per aprire le porte della biblioteca virtuale che gli utenti avevano deciso di consultare.

Quindi inizialmente la chat integrata in TUTTO aveva lo scopo di guidare nell’uso del discovery, per dare istru­zioni e valorizzare il servizio; ma presto si è rivelata an­che un termometro di grande importanza per cogliere le esigenze degli utenti. Man mano si sono evidenziate delle vere e proprie casistiche di problematiche che han­no portato l’Ufficio Servizi bibliografici digitali di UniTO a investire nell’analisi delle conversazioni avvenute in chat. Il frutto di questo lavoro è stata la produzione di una lista di frequently asked question (da qui in poi FAQ).

In gran parte delle occasioni, l’utente apre la chat per­ché ha bisogno di aiuto per avviare la propria ricerca e non conosce i servizi bibliografici a sua disposizione. Oppure perché non ha gli strumenti per comprendere il mancato accesso ai contenuti di un documen­to: “Sto facendo una ricerca per la tesi ma non trovo niente! - Devo iniziare la tesi e ho bisogno di cercare materiale, da dove parto? - Ho trovato un libro ma non capisco in quale biblioteca devo andare - Perché ho trovato un articolo, ma non riesco a scaricarlo?”.

Nell’esperienza maturata in questi quasi tre anni di lavoro in chat, abbiamo potuto cogliere che i nostri utenti prima di contattarci partono dai motori di ricerca o dai siti istituzionali del Sistema bibliotecario e delle biblioteche UniTO.

Spesso Google è il mezzo con cui iniziano la vera e propria ricerca bibliografica, limitandosi a inserire nel box il titolo dell’articolo, o una stringa o il nome della piattaforma editoriale che sanno essere di loro riferi­mento. Certamente in risposta si ottengono moltissimi risultati, ma quando arriva il momento di aprire un full text e si è off-campus, si verifica il primo “stop” della ricerca. Oppure, partendo dai siti delle istituzioni bi­bliotecarie dell’ateneo, il grosso scoglio è capire quale sia il servizio più efficace per selezionare il materiale bibliografico o la fonte più appropriata.

L’insieme di queste motivazioni, riflessioni e domande ci ha portati ad aggiungere un accesso alla chat di assistenza sul sito del Sistema bibliotecario di ateneo. A questo punto è stato necessario ricalibrare l’azio­ne del bibliotecario-operatore di chat: dalle istruzioni sull’uso del discovery, abbiamo ampliato la nostra as­sistenza anche all’uso di altri servizi forniti in ateneo per la ricerca bibliografica.

Le chat sono state affrontate con le tradizionali tecni­che di intervista di reference, considerando che una delle parti più complesse di questo aspetto è la nego­ziazione della domanda.

Spesso il richiedente non ha ancora chiaro il suo biso­gno e non sempre l’oggetto della sua richiesta d’esor­dio corrisponde alla sua vera esigenza. Per esempio: “Cerco il libro “X” e non trovo niente!” il più delle volte significa non che l’utente ha cercato il libro con TUTTO o col catalogo e non l’ha trovato, ma che lo ha cercato attraverso il web (magari anche navigando nel nostro sito), senza individuare lo strumento specifico con cui eseguire la ricerca.

Il reference digitale sincrono è spesso definito in let­teratura quick o ready reference perché ritenuto un tipo di assistenza rapido, dove difficilmente è possibile approfondire il problema posto o curare la qualità di una risposta. Fatte salve le situazioni in cui l’affluenza di utenti sia molto alta (più richieste in simultanea per ciascun operatore), non è detto che si debbano avere per forza scambi sintetici. Molto dipende dalla dinami­ca che si stabilisce tra utente e bibliotecario. La cosa più importante che un operatore di chat deve fare è interpretare rapidamente la predisposizione o meno di chi lo contatta a ricevere istruzioni dettagliate. Quin­di è fondamentale avviare una conversazione in modo da trattenere l’utente in chat per fornirgli il maggior numero possibile di informazioni utili a soddisfare la sua domanda, senza però arrivare ad annoiarlo. Come suggerito da Bridgewater e Cole:

Non solo. Gli utenti che usano una live chat stanno agendo online, cercano le informazioni bibliografiche o l’accesso a queste ultime possibilmente dallo stesso ambiente, ovvero il web. In caso di interruzioni della ricerca, di impossibilità di capire come accedere a una fonte, il reference sincrono offre la possibilità di chie­dere e risolvere nell’immediato il problema, cioè risulta utile: l’utente non avrà bisogno di fermarsi nella sua attività, magari per avviare uno scambio di e-mail con la biblioteca, che per quanto rapido, richiederà nel­la migliore delle ipotesi qualche ora, o addirittura non dovrà lasciare la sua postazione di lavoro per recarsi fisicamente in biblioteca per la soluzione di una que­stione magari di tipo tecnico.

In questa sede tralasceremo la metodologia con cui sono state trattate in questi tre anni le richieste per le ricerche bibliografiche (ci riferiamo alla costruzione di stringhe, uso di thesauri, ricerche di documenti ecc.); ci concentreremo invece sulle richieste legate ai servizi offerti dal Sistema bibliotecario di UniTO.

Abbiamo già accennato alla possibile difficoltà degli utenti di selezionare i servizi per la ricerca e di accede­re alle risorse elettroniche quando sono off-campus. Sono proprio queste le richieste che ricorrono sta­bilmente nelle nostre live chat da quando abbiamo inaugurato il servizio. La costante frequenza con cui alcune domande vengono poste è diventata motivo di riflessione dell’ufficio, facendo sorgere la necessità di creazione di un modello di FAQ mirato e calibrato sui bisogni emersi.

Le chat già avvenute costituivano il bacino da cui estrapolare le domande e le risposte su misura per i nostri utenti.

SnapEngage raccoglie in log e mette a disposizione in file di testo le conversazioni avvenute tra utenti e ope­ratori. In tre anni è stata collezionata una quantità di materiale molto significativa e difficile da analizzare ma­nualmente, per un totale di 2.636 scambi, sia sincroni che asincroni. Quindi è stato fissato il primo obiettivo: cercare in maniera sistematica nelle chat domande e risposte già formulate e già elaborate, così da non doverle produrre ex novo. In caso di risposta positiva, avremmo avuto l’individuazione di problematiche reali già trattate e risolte, meccanizzando l’analisi.

La prima operazione è stata quella di selezionare delle parole chiave (keyword) che facessero emergere i bi­sogni informativi degli utenti.

Vista la quantità di scambi avvenuti, non era possibile effettuare manualmente un’estrazione dei termini; si è quindi praticata una “tokenizzazione” del file testuale che ci ha permesso il conteggio delle occorrenze di ogni parola.

Essendo lo scopo del nostro lavoro la stesura di FAQ sui servizi offerti dal Sistema bibliotecario di ateneo, è stata operata una cernita sul risultato ottenuto da tale conteggio. Infatti, per il momento, sono stati scartati i termini strettamente legati alle ricerche bibliografiche (titoli di documenti), alle discipline, alle banche dati e tutte quelle parole che nelle loro funzioni sono para­gonabili a stopword. Questa selezione è avvenuta in base a due criteri: il primo basato sulle competenze di reference dei bibliotecari-agenti della chat e sulla loro esperienza maturata nel corso della gestione del servizio. Il secondo è stato fornito dai dati numerici ricavati dal conteggio, che ha in effetti confermato l’in­cidenza di alcuni termini, compresi quelli selezionati dai bibliotecari.

È importante chiarire che le conversazioni sono sta­te analizzate facendo la ricerca delle stesse keyword prima negli interventi degli utenti e poi in quelli degli agenti. Date le due diverse matrici, gli output hanno restituito liste di termini con valori delle occorrenze molto diversi. Abbiamo ritenuto quindi significativi i risultati dei conteggi fatti nelle battute degli utenti. Queste certamente rappresentavano le richieste ge­nuinamente formulate da chi è il destinatario del servi­zio in elaborazione.

Il passo successivo è stato ricercare la lista di keyword nelle richieste degli utenti; quindi di associare a ogni loro intervento la successiva risposta dell’agente.

Il risultato di questo procedimento ha permesso di ot­tenere in maniera automatica coppie di scambi, molti dei quali con un significato compiuto e in larga parte in grado di esprimere una domanda con la relativa ri­sposta.

Ciò ha comportato due risultati: il primo è stata un’a­nalisi automatica delle conversazioni utente/bibliotecario, con un notevole risparmio di tempo rispetto al lavoro manuale. Il secondo, ancora più importante, è stato l’ottenimento di richieste reali e con i termini con­sueti degli utenti; successivamente, quello di risposte già articolate e soprattutto provate come utili perché già verificate durante l’assistenza sincrona. Nel cor­so di quest’ultima, infatti, è possibile accompagnare l’utente finché non riesce nel suo intento, superando il rischio di frustrazione tanto diffuso in chi approccia sistemi non familiari.

Sono numerose le problematiche emerse durante le nostre assistenze, ma quella che è ricorsa e ricorre più frequentemente è la configurazione del Proxy Uni­TO per l’accesso ai contenuti digitali off-campus. Per esemplificare il lavoro di analisi dei contenuti fin qui descritto, la useremo come oggetto di osservazione. La richiesta di assistenza per l’accesso “da casa” rive­la una lacuna nelle informazioni possedute dall’utente. Google è uno strumento fondamentale, garantisce in maniera quasi certa una risposta a qualunque richie­sta gli sia posta (non entreremo in questo caso nel merito della valutazione qualitativa dal punto di vista accademico delle fonti da cui provengono le risposte del motore di ricerca). Ma Google indicizza pagine web, che sono sempre, o quasi, accessibili. In definiti­va, se Google mi dice che esiste una risposta alla mia domanda, allora penso di poterla anche leggere.

Come è ben noto, per accedere ai contenuti editoriali nella maggior parte dei casi è necessario un abbona­mento. Quando i nostri utenti UniTO fanno ricerca nel web o con i nostri servizi, lo fanno con un approccio ispirato a Google: se trovo la descrizione di un articolo mentre studio a casa perché non riesco anche a leg­gerne il full text?

Abbiamo poi utenti che hanno già consultato riviste elettroniche tramite le postazioni di una biblioteca o la rete d’ateneo, perciò sanno che UniTO vi è abbonata. Quando poi fanno la ricerca da casa, non avendo una sottoscrizione, ricevono una risposta negativa al ten­tativo d’accesso. La loro richiesta pertanto è se pos­sono usufruire dei contenuti editoriali tramite l’ateneo collegandosi da casa.

Infine, le richieste d’assistenza sono arrivate anche da utenti perfettamente consapevoli dell’esistenza del servizio proxy, ma che in quel momento avevano diffi­coltà nella gestione della configurazione.

Sulla base di queste premesse e sostenuti dal con­teggio delle occorrenze operato attraverso la “tokenizzazione”, sono state selezionate come keyword sull’argomento i termini “proxy” (574 occorrenze), “ac­cedere” (398 occorrenze) e “accesso” (199 occorren­ze), “riesco” (445 occorrenze).

Nel dettaglio: “proxy” ha permesso di estrarre quegli scambi che vedevano nella domanda dell’utente una richiesta di aiuto nella configurazione del servizio, se­gnalazioni di eventuali malfunzionamenti, di anomalie, di impossibilità di accesso ai contenuti o al servizio proxy stesso ecc.

Fanno eccezione quelle conversazioni in cui la keyword compare nel testo dell’utente perché ripetizione di un’i­struzione ricevuta precedentemente da un operatore.

“Accedere” e “accesso”, invece, sono state keyword utili a individuare le conversazioni in cui l’utente aveva formalmente capito la necessità di una procedura o di una via istituzionale per accedere a un servizio, com­preso quello della consultazione off-campus delle ri­sorse online. I termini sono stati scelti perché esprimo­no una certa competenza di linguaggio. Sottintendono la consapevolezza che per compiere alcune operazio­ni sono necessarie delle condizioni. Alle volte gli utenti le usano nel giusto contesto, altre volte no, ma sta a noi bibliotecari attribuire i giusti significati. Certamente, nell’ambito del nostro progetto, “accedere” e “acces­so” ci hanno permesso di estrarre conversazioni lega­te all’uso dei servizi e quindi anche del Proxy UniTO.

Il terzo termine “riesco” esprime il desiderio di raggiun­gere un obiettivo, di compiere un’azione: nel nostro caso è stato la chiave per individuare richieste di assi­stenza ad ampio spettro. Tra esse quelle di aiuto per modificare le impostazioni di navigazione.

Qui di seguito mostriamo un esempio di scambio con domanda e risposta estratto tramite la procedura au­tomatica cui sopra abbiamo accennato:

Questo caso mostra come il lavoro successivo alla sele­zione della coppia utile alla produzione di FAQ sia con­sistito semplicemente (e nella maggior parte dei casi) in un’opera di rieditazione e non di produzione di contenuti. La domanda infatti risulta già chiara e composta. La ri­sposta invece ha necessitato di piccole rielaborazioni, prevalentemente formali.

Nonostante la realizzazione di una pagina di FAQ sia un’operazione concettualmente semplice che consiste essenzialmente nella selezione mirata dei più signifi­cativi scambi comunicativi finalizzati alla risoluzione di un determinato problema, se svolta manualmente può rivelarsi particolarmente onerosa, richiedendo un quantitativo di tempo dedicato alle operazioni di anali­si e selezione proporzionale alle dimensioni della base di dati testuale su cui si intende agire. Proprio in virtù di questa valutazione, risulta evidente la necessità di orientarsi in direzione di una manipolazione automatica dei dati di testo, cosa possibile mediante l’utilizzo di metodologie e procedure tipiche della linguistica com­putazionale, in particolare di quella branca denominata linguistica dei corpora. Proprio l’applicazione di meto­dologie ormai consolidate nell’ambiente dell’elabora­zione delle lingue naturali a un settore relativamente di nicchia quale il reference bibliotecario rappresenta un importante elemento di novità sulla scena italiana, non­ché un fattore di innovazione all’interno del più gene­rale contesto biblioteconomico. La scelta di utilizzare una tecnologia di elaborazione dei dati mutuata da una tradizione più propriamente legata all’analisi elettronica dell’informazione linguistica è data dal fatto che l’in­sieme delle registrazioni della chat in nostro possesso costituisce una raccolta di dati che, opportunamente trattata, può essere considerata a tutti gli effetti un cor­pus linguistico secondo la seguente definizione:

Partendo da tale assunto, risulta evidente che la prima operazione svolta sia stata la riunione dei numerosi sin­goli file di log in un unico documento; operazione che ha richiesto la massima attenzione affinché anche nel nuovo documento si potesse garantire il mantenimento della corretta sequenzialità temporale dei diversi scambi comunicativi. Il passo immediatamente successivo alla ricostituzione dei log in un file unitario ha riguardato le necessarie operazioni di pulitura dei dati stessi. In particolare, si è visto innanzitutto necessario procedere a un intervento di ricodifica di alcuni caratteri dal formato tipicamente utilizzato nelle pagine HTML allo standard UTF8 (ad esempio: “(” = “(” , “à” = “à”). A ciò ha fatto seguito la ricostruzione su una singola linea di quegli interventi degli utenti frazionati su più righe suc­cessive (Fig. 1), unitamente all’eliminazione di tutti i dati non testuali o non rilevanti per gli scopi del progetto.

Al fine di comprendere meglio la natura degli interventi svolti, è necessario in primo luogo esaminare le carat­teristiche strutturali del documento originale, descri­vendo quindi le modifiche apportate. Il primo aspetto su cui è necessario concentrare l’attenzione riguarda il formato del documento da elaborare. Nel nostro caso il file complessivo consiste in una sequenza di 2.636 interscambi formattati da SnapEngage stesso secon­do lo schema CSV (comma separated values). Per quanto concettualmente paragonabile a una tabella di database, questa tipologia di file rappresenta un do­cumento di testo in cui ogni singola riga (record) si compone di una serie prestabilita di campi separati da virgola. Rispetto a quanto si può evincere dalla Fig. 2, che a prima vista sembra non rispettare i termini appe­na indicati, è necessario precisare che la presenza di caratteri di invio (LF, line feed) all’interno dello scambio comunicativo tra i due interlocutori, dà inevitabilmente luogo alla frammentazione dell’intero record su righe multiple. Per quanto concerne le operazioni di filtrag­gio, è doveroso puntualizzare che questa elaborazione viene svolta in un secondo momento e può riguardare tanto campi specifici quali la durata della chat o l’in­dirizzo IP dell’utente, quanto righe intere caratterizza­te da contenuti non rilevanti ai fini di questo proget­to quali l’apertura di specifiche pagine web da parte dell’utente (“Visitor page reloaded”, Fig. 2). Sebbene a prima vista possano essere considerate superflue o scarsamente rilevanti, le attività appena menzionate rappresentano al contrario un fattore di primaria im­portanza: solo così facendo, infatti, è possibile rendere l’intero documento anonimo, eliminando eventuali rife­rimenti ai dati personali che possano portare all’iden­tificazione dell’utente. In aggiunta a quanto descritto, si è deciso di facilitare l’identificazione di ogni singola sessione di chat e, di conseguenza, rendere più age­voli le successive elaborazioni, mediante l’inserimento di un elemento di annotazione meta-testuale (comu­nemente noto con il termine markup) rappresentato dalla coppia di etichette compatibili con il formato XML <chat>…</chat> (Fig. 2). Come ultima conside­razione, è necessario segnalare che ogni chat si apre sempre con un messaggio automatico che comunica all’utente la disponibilità di fornire assistenza e la relativa policy sulla privacy. Trattandosi di un messaggio ripetuto e sempre identico nel tempo, abbiamo deci­so di eliminare tale incipit dal file pre-elaborato onde evitare operazioni su dati falsati che porterebbero a risultati fuorvianti.

Per quanto riguarda il testo della chat, è fondamenta­le chiarire che in questa seconda fase di preparazio­ne anch’esso ha dovuto affrontare un primo livello di manipolazione, subendo un processo automatico che prende il nome di “tokenizzazione”. A questo proposito:

Da quanto sopra, risulta pertanto evidente che que­sta elaborazione, indispensabile per garantire la cor­rettezza dei risultati prodotti, consiste essenzialmente nell’individuazione di ogni singolo elemento testuale dotato di valore semantico autonomo (token) per poi procedere, laddove necessario, alla sua successiva separazione dalle forme testuali attigue mediante un carattere di spazio (Fig. 2). È interessante segnalare che all’interno di questa fase, per quanto non diretta­mente utile ai fini della produzione del documento di FAQ, è stata prestata notevole attenzione anche alla corretta identificazione dei vari emoticon che gli interlocutori possono utilizzare all’interno del loro scambio comunicativo. Per motivi di completezza è opportuno segnalare che le conversazioni tra utente e operatore possono contenere forme invariabili complesse che da un punto di vista strettamente linguistico rappresen­tano voci lessicali autonome. Tali elementi sono stati oggetto di accurata selezione affinché fosse possibile gestirli come token unitari: queste forme, infatti, sono del tutto riconducibili a espressioni polirematiche, os­sia quei costrutti particolari il cui significato è indipen­dente e non desumibile dagli elementi lessicali che lo compongono (ad esempio “ferro da stiro” o “forza la­voro”). Pertanto, sulla base di queste valutazioni, sono stati predisposti specifici criteri di raggruppamento fi­nalizzati alla corretta gestione di:

• riferimenti bibliografici completi o parziali («A Head for an Eye: Revenge in the Cambodian Genocide Hin­ton, Alexander Laban American Ethnologist, 1998 Aug, Vol.25(3), pp.352-77»);
• nomi di case editrici o piattaforme editoriali (Franco Angeli; Science Direct);
• informazioni bibliografiche di natura amministrativa («In­ventario INP 4362 Collocazione P*126 B 07 Note 1 v.»);
• messaggi o avvisi di sistema (No Proxy Detected; Documento ammesso al prestito);
• luoghi o istituzioni (Palazzo Nuovo; Servizio bibliote­cario d’ateneo);
• nomi propri o marchi registrati (Isaiah Berlin; Macbo­ok Air).

In ultima istanza, bisogna considerare che all’interno dei file di log originali non sono registrati esclusivamente i contenuti delle comunicazioni svolte in moda­lità sincrona, ma anche le richieste che giungono nei periodi in cui il servizio di reference online in modalità sincrona non è attivo (162 occorrenze). Oltre a ciò, è anche presente un totale di 148 casi in cui l’utente ab­bandona il servizio senza stabilire un effettivo contatto con l’operatore. Questo comportamento dell’utenza si può verificare immediatamente dopo l’apertura del servizio, come risposta alla frase automatica di accoglienza (113 occorrenze) oppure come repentina interruzione della comunicazione e conseguente im­possibilità da parte dell’operatore di fornire risposta al quesito posto (35 occorrenze). Al fine di preservare l’integrità dei dati originali, senza tuttavia inquinare i contenuti utili per il progetto, si è deciso di filtrare que­sti interventi particolari salvandoli in file dedicati. Una volta ottenuto un documento di testo caratterizzato da 2.326 blocchi omogenei di righe di comunicazione sin­crona contenenti esclusivamente i dati relativi a ruolo dello scrivente (utente o operatore), orario e contenuto dello scambio intercorso (Fig. 3), i successivi passaggi rappresentano il cuore dell’elaborazione.

L’indagine basata sulla metodologia della linguistica dei corpora implica necessariamente l’utilizzo di stra­tegie di analisi di natura quantitativa e qualitativa. Dal punto di vista quantitativo, la messa in atto di modelli statistici quali la Legge di Zipf è divenuta ormai pras­si consolidata in quanto capace di fornire informazio­ni importanti sulle caratteristiche di un testo in base al suo lessico. L’approccio in questione rappresenta per l’universo linguistico l’alter ego della distribuzione gaussiana di un campione. Tuttavia, a differenza della curva di Gauss, capace di rappresentare graficamente i valori di una certa variabile espressione di un fenome­no noto (ad esempio la statura di tutte le persone di una data età, i voti di profitto di una classe di studenti ecc.), nel caso dell’analisi statistica applicata all’ambito linguistico, l’unico dato a noi disponibile è rap­presentato dalla modalità di utilizzo dei vari elementi lessicali (token) all’interno dell’opera di uno specifico autore. Pertanto, poiché il modello di Zipf si fonda sul presupposto empirico secondo cui, a livello lessicale, la comunicazione avvenga sfruttando il principio del “massimo risultato con il minimo sforzo”, da un punto di vista operativo tale modello si traduce in una funzio­ne di proporzionalità inversa tra il numero di occorren­ze proprie di un tokene la sua posizione (rango) all’in­terno di un elenco (lista di frequenze). Il rapporto tra i valori di rango e frequenza saranno quindi lo specchio della ricchezza lessicale propria del testo sottoposto ad analisi. In merito al caso specifico oggetto del pre­sente articolo, è opportuno sottolineare che allo scopo di ottenere un’immagine più chiara del linguaggio uti­lizzato, si è resa necessaria la creazione di due liste di frequenza distinte tra utente e operatore.

Oltre a ciò, poiché il sistema riconosce e gestisce in maniera diversa i caratteri maiuscoli rispetto alla loro controparte minuscola, alle liste già indicate sono stati aggiunti altri due elenchi in cui l’intero lessico è ricon­dotto alla sola variante minuscola. Quest’ultimo espe­diente si è rivelato estremamente utile per consentire lo svolgimento di calcoli statistici sul lessico utilizzato nel­la chat partendo da presupposti meno restrittivi poiché capaci di articolarsi su modelli differenti. Di conseguen­za, al fine di ottenere la lista di frequenze che ci ha per­messo di estrarre con elevata facilità la serie di parole chiave più rilevanti utilizzate dagli utenti nelle loro sva­riate richieste a favore dei servizi disponibili, si è ritenu­to necessario operare un filtraggio automatico di que­gli elementi lessicali caratterizzati tanto da frequenze estremamente elevate, quanto estremamente basse. La successiva operazione, svolta sull’elenco di parole chiave risultante dai precedenti passaggi, ha riguarda­to la meticolosa selezione manuale di quei termini che, sulla base di criteri semantici, si sono rivelati maggior­mente significativi. La lista ristretta così prodotta è sta­ta quindi utilizzata come base per l’estrazione automa­tica dei diversi contesti d’uso a partire dal documento “tokenizzato”. Questa elaborazione ha portato, come ultimo passaggio, alla creazione di un documento di sequenze omogenee di scambi costituiti dalle richieste di supporto da parte dell’utente a cui fanno seguito le relative risposte. Proprio tale documento rappresenta il risultato finale che può essere utilizzato per fornire un punto di riferimento primario per tutti i fruitori dei servizi bibliotecari dell’Università di Torino.

Il sistema di estrazione dei contesti di frase utili per la produzione del documento di FAQ è gestito da un algoritmo che opera un confronto tra la lista di parole chiave ordinate in base alla loro frequenza e i singoli token che compongono le varie righe di quel file di log già filtrato e riformattato secondo quanto descritto nei precedenti paragrafi. Una volta che questo confron­to abbia prodotto un esito positivo, il sistema inter­romperà l’attività in corso e memorizzerà il contenuto dell’intera riga, per poi spostarsi in quelle successive per verificare la presenza di eventuali ulteriori prose­cuzioni dell’intervento dell’utente oppure l’esistenza della risposta da parte dell’operatore. Sulla base di quanto indicato, risulta chiaro, quindi, come il sistema di estrazione operi utilizzando tre cicli iterativi nidificati che agiscono su elementi distinti. Il primo di questi cicli ha la funzione di scandire il vettore in cui si trovano immagazzinate le parole chiave dopo essere state ac­quisite dal loro file di origine. Il secondo ciclo, che si attiva immediatamente dopo la selezione della parola chiave, si occupa, per contro, di effettuare una scan­sione di tutti i token che compongono la riga del file di log presa in esame.

Dal risultato positivo del confronto dei due elementi lessicali di cui sopra, svolto mediante l’utilizzo di criteri di pattern matching fra stringhe di caratteri, si attiva il terzo processo iterativo che, a differenza dei prece­denti, opererà sulla struttura del file a livello di riga di testo. Proprio in questa fase, attraverso una verifica dell’autore dell’intervento comunicativo, distinto tra utente e operatore, il sistema sarà in grado di operare una corretta ricostruzione del blocco di domande e risposte. È bene chiarire che quanto finora descritto presuppone implicitamente l’esistenza di un ulteriore ciclo iterativo a monte avente compito di coordinare la lettura sequenziale delle singole righe del file di log originale con tutti i processi di elaborazione definiti nel corpo del programma. Questa funzione operativa, per quanto assolutamente fondamentale per il corretto funzionamento del sistema nel suo complesso, non è stata finora menzionata in quanto parte costitutiva e integrante del linguaggio stesso utilizzato per la re­alizzazione dei vari programmi di elaborazione. Il lin­guaggio in questione, adottato nella sua versione più recente, rappresenta la versione open source (certifi­cata dalla licenza GNU) di AWK, un prodotto ap­positamente progettato per facilitare la manipolazione di dati testuali e sviluppato originariamente in ambien­te UNIX nel 1977 da Alfred Aho, Peter Weinberger e Brian Kernighan, il creatore del famoso linguaggio di programmazione “C”.

Riassumendo, ai fini della produzione automatica del documento di FAQ sarà necessario eseguire la se­guente catena di elaborazione del file di log originale:

• pre-elaborazione del file di log in formato *.csv finaliz­zato alla ristrutturazione su unica riga del medesimo atto comunicativo frazionato su righe successive;
• produzione di un file di log opportunamente filtrato e “tokenizzato”, un file di richieste degli utenti inviate al di fuori del regolare orario di servizio e un file con richieste prive di risposta a seguito dell’abbandono della chat da parte dell’utente;
• creazione di due file di dati statistici distinti tra ope­ratore e utente, basati sui principi della Legge di Zipf;
• selezione delle parole chiave (keyword) dai file stati­stici strutturati in ordine decrescente;
• creazione automatica di FAQ sulla base di un elenco di keyword ordinato alfabeticamente.

Il progetto descritto ha raggiunto diversi obiettivi e ne pone di nuovi. L’elaborazione computazionale ha fa­cilitato l’elaborazione statistica delle chat avvenute in questi tre anni e, di conseguenza, il lavoro di analisi sia dal punto di vista semantico sia da quello biblioteconomico, in particolare per quanto riguarda il referen­ce. L’erogazione di servizi di un sistema bibliotecario necessita di una verifica accurata della riuscita degli intenti. Una richiesta è di per sé sintomo di un gap tra chi offre il servizio e chi lo usa. Cogliere questo messaggio e cercare di intervenire costituiscono il primo passo nella missione del bibliotecario.

La realizzazione di FAQ sulla base di richieste reali è stata la nostra iniziativa di partenza. L’implementazione della chat tra i nostri servizi prima e l’elaborazione delle conversazioni poi, infatti, ci hanno fornito nume­rosi spunti e hanno fatto emergere altrettante richieste e implicite esigenze da parte dei nostri utenti. Tutto ciò sarà oggetto delle nostre prossime attività di ricerca, sempre col supporto dell’approccio basato sul­la linguistica computazionale. In particolare, il passo successivo riguarderà l’utilizzo dei dati già elaborati al fine di condurre analisi mirate non solo a evidenziare i tratti in comune e le differenze tra il linguaggio espres­so dagli utenti e quello degli operatori, ma anche a evidenziare le reali necessità dell’utenza in un ottica di estensione e rafforzamento del servizio verso quelle realtà bibliotecarie non ancora direttamente coinvolte nel progetto. Anche in questo caso, l’unico scopo sarà quello di stabilire un dialogo, sia diretto che indiretto, con i nostri utenti per contribuire a rendere il mondo delle biblioteche un ambiente aperto, collaborativo e in continua crescita.