Tauro: Un Innovativo Motore Di Ricerca Per Documenti Xml

TauRo: un innovativo motore di ricerca per documenti XML Paolo Ferragina, Alida Isolani, Tommaso Schiavinotto 11 luglio 2008

La lunga esperienza del CRIBeCu prima e di Signum poi nell’ambito dell’analisi testuale informatizzata ci ha spinto a partecipare con un contributo originale, e auspichiamo significativo, alla sfida recente della digitalizzazione e analisi informatica dei testi letterari. La definitiva affermazione del formato XML da un lato, e dei motori di ricerca alla Google dall’altro, offrono una stimolante opportunit`a tecnologica per la fruizione di grandi quantit` a di dati su normali PC o anche su dispositivi portatili quali smartphone e palmari; ma pongono anche numerose difficolt`a algoritmiche e sistemistiche il cui superamento costituir` a la nuova sfida intrapresa con il progetto TauRo descritto in questo articolo. La descrizione delle caratteristiche algoritmiche di TauRo e delle motivazioni sottostanti il suo progetto, non possono prescindere dall’esperienza maturata dal gruppo testi di Signum nel corso di questi ultimi 10 anni. I nostri primi esperimenti di codifica testuale erano stati effettuati su SGML, e avevano portato alla definizione di alcuni primordiali algoritmi per l’Information Retrieval su testi marcati citiamo Le Vite di Giorgio Vasari1 online. Questa esperienza pionieristica ci aveva permesso di comprendere quali fossero i limiti di un “normale” motore di ricerca testuale applicato a tali documenti, e quali fossero le effettive necessit`a di chi operava nel difficile contesto della digitalizzazione di fonti letterarie delle pi` u svariate tipologie, forme e caratteristiche. Il risultato di questa esperienza era stata la realizzazione di un motore di ricerca, denominato TReSy 2 , che risultava sufficientemente efficiente ed efficace da gestire i problemi tipici dellanalisi testuale XML. TReSy stato applicato con successo su varie collezioni di testi marcati XML-TEI3 , quali per esempio Le Vite vasariane e il pi complesso Vocabolario della Crusca in edizione elettronica. 1 http://vasari.signum.sns.it 2 TReSy

Text Retrieval System, motore di ricerca per documenti XML sviluppato dal CRIBeCu a partire dal 1998. 3 TEI Text Encoding Iniziative http://tei-c.org/

1

Il progetto TauRo intende proporsi non come una evoluzione tecnologica del pur glorioso TReSy, ma come uno strumento software innovativo, modulare e sofisticato che consenta la memorizzazione compressa, e l’analisi/ricerca efficiente di pattern arbitrari in grandi collezioni di documenti XML disponibili su un unico PC, o distribuite in cluster di PC possibilmente dislocati in varie parti della rete Internet. Rispetto agli strumenti attualmente disponibili nel panorama internazionale, TauRo offre ulteriori e pi` u sofisticate funzionalit` a di ricerca e analisi dei testi letterari. Queste funzionalit`a sono state progettate al fine di tenere profondamente conto delle caratteristiche attuali della codifica di testi letterari intesa non tanto come formato per l’interscambio dei dati ma come complesso sistema di rappresentazione, interpretazione e studio dei testi. In questo modo, TauRo supporta la realizzazione di nuove e pi` u sofisticate funzionalit`a di ricerca strutturale e per contenuto, completamente assenti nei motori di ricerca moderni per XML.

1 Lo scenario e le esigenze Vista la crescente esigenza da parte degli umanisti di strumenti che agevolino l’analisi dei testi, la ricerca informatica si sta impegnando nello sviluppo di motori di ricerca dalle caratteristiche sempre pi` u sofisticate ed evolute. Un motore di ricerca ha lo scopo di recuperare da una collezione di testi le informazioni che soddisfano l’interrogazione posta da un utente. I motori di ricerca tradizionali, come Google per il Web, considerano principalmente la parte testuale dei documenti permettendo la ricerca di parole al suo interno. I motori di ricerca XML offrono invece la possibilit` a di ricercare sia nel contenuto testuale del documento che nella sua struttura codificata, appunto, tramite il formato XML. Ci`o inevitabilmente consente all’utente di progettare interrogazioni pi` u sofisticate e selettive, cos`ı da rendere il suo processo di analisi dei testi potenzialmente pi` u efficiente ed efficace, a patto di avere motori di ricerca progettati ad hoc. Attualmente, il panorama scientifico e industriale offre diversi motori di ricerca per l’indicizzazione di documenti XML: la maggior parte di essi sono orientati all’utilizzo in modalit`a “data centric”, ovvero consentono di gestire documenti strutturati in campi e con forte regolarit`a quali i dati di tipo tabellare ordini di vendita, dati scientifici e simili. Poche sono invece le soluzioni per la gestione di XML in modalit`a “document centric” (ad esempio eXist 4 e GalaTeX 5 ), ovvero per trattare documenti con struttura irregolare, pochi campi e molto testo, quali appunto le fonti letterarie. Il nostro studio si `e concentrato dunque su questa ultima tipologia di documenti e motori di ricerca, e per essi abbiamo studiato e individuato i requisiti fondamentali che un motore di ricerca moderno dovrebbe offrire per essere considerato utile agli occhi di un umanista. 4 W.

Meier, eXist: An Open Source Native XML Database, in Lecture Notes In Computer Science, London 2002. http://www.exist-db.org/ 5 E. Curtmola, S. Amer-Yahia, P. Brown, M. Fernandez, GalaTex: A Conformant Implementation of the XQuery Full-Text Language, AT&T Technical Report, 2004. http://www.galaxquery.com/galatex/

2

1.1 I motori di ricerca XML Per poter usufruire appieno delle funzionalit`a di un motore di ricerca `e necessario utilizzare il suo linguaggio di interrogazione. Entrambi i motori di ricerca eXist e GalaTeX, citati in precedenza, utilizzano un’estensione di XQuery, linguaggio definito dal W3C e considerato oramai lo standard per l’interrogazione di collezioni documentali XML. XQuery (XML Query Language) consente di formulare interrogazioni elementari sul contenuto testuale dei documenti, di rintracciare elementi – tag e attributi – che rispettino determinati vincoli, o di combinare questi due tipi di ricerche cos`ı da ottenere interrogazioni pi` u selettive. Recentemente il W3C ha esteso le funzionalit`a di XQuery verso ricerche per contenuto pi` u sofisticate, dette full-text, ma sono pochissimi i motori di ricerca che hanno gi` a recepito e realizzato queste funzionalit`a: 1. ricerca di parole singole; 2. ricerca di frasi; 3. gestione di stopwords (eliminazione di parole frequenti); 4. ricerca per suffissi, prefissi, infissi; 5. ricerca per proximity (le parole ricercate devono comparire, al massimo, ad una distanza prefissata l’una dall’altra); 6. ricerca per proximity con ordinamento (viene specificato l’ordine in cui le parole devono comparire); 7. utilizzo di operatore di congiunzione (AND); 8. utilizzo di operatore di disgiunzione (OR); 9. utilizzo di operatore di negazione (NOT); 10. normalizzazione delle parole e di entit`a; 11. ranking (ordinamento secondo un qualche criterio di rilevanza). Sia eXist che GalaTeX implementano una propria estensione per ricerche full-text di XQuery. In particolare, GalaTeX offre la prima realizzazione conforme alle direttive del W3C, detta TeXQuery, ma ottiene tale primato a scapito delle prestazioni in tempo (efficienza) e spazio (grosse dimensioni per l’indice). Diversamente eXist offre una realizzazione ridotta di XQuery, che manca del supporto al ranking, ma risulta pi` u efficiente in tempo e spazio rispetto a GalaTeX. Attualmente eXist `e il motore di ricerca per XML “di riferimento internazionale” grazie al suo elevato numero di funzionalit`a in ricerca e alla sua efficienza. La valutazione dell’utilizzo di eXist nel nostro ambito di interesse ci ha portato per` o ad identificare numerose sue limitazioni, che descriveremo diffusamente nel seguito, e che quindi hanno motivato lo sviluppo di TauRo.

3

1.2 Il motore di ricerca ideale Analizziamo adesso le funzionalit` a che un motore di ricerca dovrebbe offrire per soddisfare le specifiche esigenze degli studiosi di testi letterari. I requisiti delineati dal W3C possono infatti essere considerati come un punto di partenza interessante ma, viste le caratteristiche dei testi letterari marcati secondo lo standard TEI, tali requisiti devono essere integrati prevedendo alcune importanti peculiarit`a. Oltre alle sofisticate tipologie di ricerca sul contenuto testuale, previste dal W3C, `e necessario fornire all’utente la possibilit`a di ricercare insiemi di parole che possiedano caratteristiche grafiche simili, oppure ricercare parole che differiscano graficamente di poco rispetto a quella specificata nell’interrogazione. Un aspetto non meno rilevante da considerare riguarda la modalit`a di restituzione dei risultati, in quanto questa `e strettamente legata ad eventuali operazioni di post-processing che potrebbero essere effettuate su di essi al fine di estrarre ulteriori informazioni, possibilmente grazie ad altri strumenti software tipici del text mining. Per offrire questa flessibilit` a `e necessario prevedere un meccanismo di restituzione dei risultati che consenta una loro efficiente contestualizzazione, attraverso una serie di informazioni aggiuntive che includano, oltre al risultato vero e proprio (documento, numero di linea, posizione assoluta in parole e caratteri, . . . ), anche il testo che lo circonda (snippet) possibilmente privo della marcatura XML per consentirne una sua pi` u efficace visualizzazione, e dati sulla struttura logica e semantica dell’occorrenza. Si noti che le prime due informazioni sono tipiche dei motori di ricerca per il Web, la terza invece costituisce una caratteristica saliente dei documenti XML che non pu`o dunque essere trascurata dai motori di ricerca sviluppati per esso. Nell’ottica pi` u propriamente informatica, un motore di ricerca XML dovrebbe inoltre consentire il suo utilizzo su pi` u piattaforme (Desktop, palmari, cellulari) e su collezioni documentali geograficamente distribuite (biblioteche, musei, soprintendenze, etc.), adottando tecniche di compressione allo stato dell’arte per ridurre i costi di trasmissione e memorizzazione indotti dalle grandi collezioni testuali XML da esso indicizzate. La struttura del software dovrebbe inoltre essere aperta all’aggiunta di nuove funzionalit` a permettendo lo sviluppo di strumenti di text mining sempre pi` u sofisticati come, ad esempio, l’estrazione di frasi o pattern ritenuti rilevanti (motivi ), la navigazione dei testi secondo diversi ‘percorsi’ (ottenuti possibilmente da ontologie o pattern frequenti), la realizzazione di interfacce speciali per la fruizione su dispositivi palmari o smart-phone, e la possibilit` a di fornire suggerimenti all’utente per le sue ricerche in base a quelle pregresse o al suo profilo. Non `e difficile immaginare come questo tipo di software possa essere utilizzato in contesti diversi da quelli strettamente letterari, quali le collezioni documentali della pubblica amministrazione, gli archivi biologici, la manualistica, le collezioni legislative, etc.. Il contesto letterario rimane per`o il pi` u complesso e quindi costituisce, per la sua caratteristica mancanza di uniformit`a, il banco di prova pi` u stimolante e significativo. Precedentemente avevamo introdotto eXist, quale motore di ricerca XML pi` u diffuso ed efficiente nel panorama internazionale. A questo punto risulta inevitabile chiedersi se eXist offra le funzionalit` a del motore di ricerca ideale su descritto, e in quale misura

4

di efficienza ed efficacia. Al proposito abbiamo condotto una serie di esperimenti su collezioni testuali tipiche del nostro contesto di indagine; i risultati sono stati deludenti. Complessit` a della struttura del documento : eXist non `e stato in grado di indicizzare alcuni documenti presenti nella Biblioteca Virtuale Online (BiViO)6 , che presenta testi dalla struttura complessa e irregolare, ma dalle dimensioni abbastanza ridotte. Restituzione dei risultati : l’elemento minimale restituito da una interrogazione su eXist (e quindi di formato XQuery) `e il tag con il relativo contenuto. Per i nostri scopi `e preferibile una maggiore flessibilit`a nella creazione degli snippet, cos`ı come la restituzione di informazioni strutturali aggiuntive, come ampiamente commentato in precedenza. Compressione : la struttura dati di indicizzazione generata da eXist cos`ı come la collezione di documenti indicizzata, non sono soggette ad alcuna fase di compressione, con un conseguente incremento dello spazio totale occupato dal motore di ricerca. Questo potrebbe compromettere lo sviluppo di applicazioni su supporti con ridotte capacit` a di memoria, o su collezioni testuali di grandi dimensioni. Ricerche strutturali : eXist, come pressoch´e tutti i motori di ricerca esistenti, non consente di gestire la marcatura del documento XML in modo flessibile rispetto alla corretta interpretazione ed elaborazione del testo. Non `e possibile infatti, a tempo di indicizzazione e di ricerca, distinguere le varie funzioni (editoriale, linguistico, strutturale, stilistico,....) che i tag possono giocare all’interno di un testo letterario in formato XML. E quindi non `e possibile per lo studioso di testi letterari sfruttare queste distinzioni per formulare ricerche sofisticate, o addirittura per trovare tutti i risultati rilevanti per le sue interrogazioni. Questa `e una delle esigenze pi` u sentite in ambito umanistico, e ad essa dedicheremo il prossimo paragrafo.

1.3 Smart-tag Durante l’analisi e la digitalizzazione dei testi, il codificatore ha l’obiettivo di aderire il pi` u fedelmente possibile al testo originale, conservandone informazioni sulla struttura (suddivisione in capitoli, note a margine, pagine, versi, etc.) e sugli aspetti puramente stilistici (maiuscole significative, grassetto, corsivo, etc.), oltrech´e su quelli semantici. L’analisi di testi cos`ı marcati pu` o risultare difficoltosa per i motori di ricerca XML pi` u comuni, solitamente progettati per dati con una struttura regolare (es. tabelle) e in cui non si facciano assunzioni sulla semantica della marcatura. Per comprendere quali difficolt` a possa incontrare un motore di ricerca XML tradizionale durante la risoluzione di una interrogazione, mostreremo degli esempi. Iniziamo con un esempio in cui si verifica un cambio di contesto rispetto al piano testuale principale: 6 http://www.bivionline.it.

5

[. . . ] La mia edizione ` e di Venezia con annotazioni di Arnoldo <note>Arnaldo da Villanova. medico di Como accresciute da Giovanni Curione [. . . ] Supponiamo che allo studioso interessi trovare la frase “Arnoldo medico di Como” nella fonte intervallata dalla nota. Un motore di ricerca tradizionale non restituirebbe alcun risultato, perch´e prenderebbe in considerazione unicamente la parte testuale nella sua sequenza di parole adiacenti; le porzioni ‘Arnoldo’ e ‘medico di Como’ non risultano infatti contigue poich´e sono separate dal contenuto del tag <note> . La nota, peraltro, non fa parte del testo vero e proprio, ma, oltrech´e collocata spazialmente altrove, afferisce a un piano semantico diverso; le parti della frase in oggetto, dunque, sono a tutti gli effetti contigue e lo studioso, che non `e tenuto a conoscere le modalit`a di codifica del testo, si aspetterebbe giustamente di recuperare quella occorrenza. Il secondo esempio illustra i problemi che la marcatura di una lettera maiuscola pu`o far emergere durante una ricerca: [. . . ]Per Endimione bisogna[. . . ] La ‘E’ di ‘Endimione’ `e marcata come maiuscola significativa perch´e iniziale di un nome proprio: una ricerca eseguita con un motore tradizionale non troverebbe per`o la parola ‘Endimione’ perch´e, come si `e gi` a visto, questa risulterebbe divisa in pi` u parti dal tag . Lo stesso si pu` o dire per la parola ‘bisogna’ divisa dal tag puntuale che indica la fine di una linea. L’esperienza maturata presso Signum ha dimostrato come sia necessario sviluppare dei motori di ricerca che prevedano funzionalit`a di indicizzazione sufficientemente flessibili e potenti da poter gestire correttamente fenomeni strutturali di questo tipo. A questo scopo `e stato definito il concetto di smart-tag7 (tag intelligenti). Per poter distinguere come i tag debbano essere trattati rispetto al testo, abbiamo individuato tre classi di marcatori: Jump-tag : rientrano in questa categoria i tag che indicano un cambio di contesto temporaneo (come <note> nell’esempio precedente); il contenuto del tag, in questo modo, viene distinto dal testo vero e proprio; Soft-tag : questi tag non comportano un cambio di contesto; nel caso in cui l’elemento di apertura o di chiusura del tag sia presente all’interno di una stringa di caratteri non separati da spazio, questa stringa forma un’unica parola (Endimione viene considerato come Endimione); Split-tag : rientrano in questa categoria i tag a cui viene attribuito un significato analogo al separatore di parola; non viene, dunque, cambiato il contesto e le parole vengono effettivamente considerate divise. 7 L.

Lini, D. Lombardini, M. Paoli, D. Colazzo, C. Sartiani, TReSy: A Text Retrieval System for XML Documents, in Augmenting Comprehension: Digital Tools for the History of Ideas, ed by H. Short, G. Pancaldi,D. Buzzetti, Luglio 2001. Office for Humanities Communication Publications 2001.

6

` possibile classificare i tag all’interno di queste tre categorie sfruttando la conoE scenza che il codificatore ha del linguaggio di marcatura. Va da s´e che questa categorizzazione non `e fissata a priori, ma pu`o essere specializzata di volta in volta dal codificatore in base alle necessit` a e alle caratteristiche del documento XML.

2 TauRo Il nome TauRo nasce dall’acronimo di Text Retrieval componendo il nome delle corrispondenti lettere dell’alfabeto greco: Tau e Ro. Le innovazioni che il motore TauRo presenta sia rispetto a TReSy che rispetto allo stato dell’arte, precedentemente illustrato, riguardano le specifiche funzionalit`a di analisi lessicografica sulla parte testuale dei documenti, la gestione degli smart tag, e soprattutto la definizione di un linguaggio di interrogazione proprietario che, nell’intento di renderlo utilizzabile anche dall’utente finale e non solo dall’esperto software, `e espresso in termini di sintassi XML. Tale linguaggio verr`a illustrato nel prossimo paragrafo; successivamente sar` a illustrata l’architettura del sistema, progettata con lo scopo di ottenere la flessibilit` a necessaria per il suo utilizzo nei diversi scenari applicativi commentati nel paragrafo 1.2; infine verr`a mostrato il protocollo di comunicazione tra i moduli che compongono l’architettura software di TauRo per illustrarne il funzionamento complessivo.

2.1 Il linguaggio di interrogazione Un linguaggio di interrogazione ha il compito di definire come le ricerche debbano essere sottoposte al motore di ricerca. Nel nostro caso si `e deciso di definire un linguaggio, TRQL - TauRo Query Language, che permetta di eseguire le tipologie di interrogazione accennate nel paragrafo 1, di specificare i dati sui quali tale interrogazione debba essere effettuata, e di specificare le modalit`a di restituzione dei risultati. Un’interrogazione in TRQL ha il seguente formato: Select Q From F Result R Dove Q indica l’interrogazione vera e propria espressa attraverso un formalismo XML, F `e la lista dei documenti su cui effettuare la ricerca, e R definisce il formato degli snippet che verranno restituiti come risultato dell’interrogazione. L’utente finale non `e tenuto a utilizzare direttamente tale linguaggio, piuttosto potr`a interagire con un’applicazione demandata alla costruzione dell’interrogazione in TRQL. Al fine di esemplificare l’uso di TRQL mostriamo un esempio:

7

Select <xml exact>storia From biblioteca.xml Return autore: $a titolo: $t

In questo esempio si richiede al motore di ricerca di restituire la coppia ‘autore, titolo’, per ogni libro pubblicato nel 1721 e nel cui titolo compaia la parola ‘storia’ fra quelli presenti nel documento biblioteca.xml. Analizzando la porzione di interrogazione relativa alla Select risultano diversi gli elementi da valutare. Dal punto di vista della struttura del documento, la ricerca viene ristretta ai tag nel cui contenuto siano presenti il tag e il tag . Inoltre `e possibile esprimere ulteriori restrizioni sui valori degli attributi: anno=’1721’. I tag e gli attributi con prefisso xml fanno parte della specifica sintassi di TRQL (quindi sono riservati e non utilizzabili per la marcatura di un documento), a differenza degli altri tag e attributi che invece sono gli stessi presenti nel documento oggetto della ricerca. Nell’esempio, il tag <xml exact> ha lo scopo di attivare la ricerca esatta della parola ‘storia’ limitata al contenuto del tag . Pi` u in generale, la ricerca di una parola nel testo `e limitata al contenuto del tag che, nell’interrogazione, include <xml exact>. Ulteriori tipi di ricerca sul testo vengono espressi utilizzando altri tag speciali: xml prefix, xml suffix, xml contains : permettono ricerche di parole, rispettivamente, per prefisso, suffisso e infisso; xml error : permette di ricercare parole che differiscono dalla parola specificata per un numero fissato di discordanze: elisioni, aggiunte e variazioni di caratteri. Ad esempio scrivendo: <xml error max error=’2’>storia si cercano tutte le parole che differiscono al massimo di due caratteri dalla parola storia (historia, gloria, studia etc.); xml regexp : permette di ricercare parole attraverso le espressioni regolari. Per semplicit` a non ci soffermeremo su queste, basti sapere che sono utili per ricercare motivi ricorrenti all’interno di parole nel testo. xml proximity : permette di ricercare parole che si trovano entro una distanza prefissata. Le parole sono specificate utilizzando una combinazione degli operatori precedenti. Ad esempio, `e possibile recuperare le occorrenze della parola storia

8

adiacente ad una parola che inizia con ‘gr’ (‘storia greca’, ‘grande storia’. . . ) specificando l’interrogazione <xml proximity max dist=’1’> <xml exact>storia <xml prefix>gr

Per ogni ricerca `e inoltre possibile indicare se debbano essere distinte le lettere maiuscole dalle minuscole, oppure se debbano queste essere considerate equivalenti. L’ultimo aspetto su cui vogliamo attirare l’attenzione del lettore riguarda l’uso dell’attributo speciale xml var adottato per dichiarare una variabile. TauRo associa ad ` possibile una variabile i risultati della ricerca relativi al tag in cui `e dichiarata. E associare una variabile sia ai tag del documento che a quelli speciali per la ricerca nel testo; in quest’ultimo caso il risultato corrispondente alla variabile `e la parola che ha soddisfatto il criterio di ricerca. Nell’esempio sono presenti le variabili $t e $a: la prima `e legata ai risultati relativi al tag , la seconda a quelli del tag . Le variabili dichiarate con xml var (nell’esempio $t e $a) compaiono anche nella clausola Return con lo scopo di indicare come dovranno essere formati gli snippet. Se nel documento biblioteca.xml, oggetto della ricerca, `e presente il libro ‘Storia Fiorentina’ di Benedetto Varchi, lo snippet relativo a tale occorrenza apparir`a in questo modo: autore: Benedetto Varchi titolo: Storia Fiorentina di Messer Benedetto Varchi Va da s´e che il linguaggio fornisca altri meccanismi per ottenere formati di snippet pi` u complessi, rispetto a quello indicato nel precedente esempio. Li elencheremo qui di seguito, facendo riferimento all’occorrenza di una variabile $x dichiarata con xml var: • `e possibile visualizzare il valore di un attributo di un tag, ignorandone il contenuto, mediante l’associazione di $x all’attributo. Sintassi: $x[nome attributo ]. • `e possibile estrarre il testo intorno all’occorrenza relativa a $x indicando l’ampiezza della finestra in numero di parole. Sintassi: $x.win(ampiezza finestra ). • `e possibile restituire un tag che contiene l’elemento corrispondente a $x, specificando il numero di livelli di differenza. Sintassi: $x.anc(livello ). Se, ad esempio, livello fosse uguale a uno, lo snippet sarebbe formato dal tag padre che contiene direttamente l’elemento associato a $x.

2.2 L’architettura software La progettazione di TauRo ha avuto come scopo principale la definizione di un sistema modulare che limitasse l’utilizzo delle risorse computazionali disponibili, questo in

9

Figura 1: Schema dell’architettura di TauRo un ottica di utilizzo su pi` u piattaforme (Desktop, palmari, cellulari) e su collezioni documentali geograficamente distribuite (biblioteche, musei, soprintendenze, etc.). A tal fine, l’architettura del sistema `e stata organizzata in tre moduli (Fig. 1): • interfaccia verso l’applicazione dell’utente; • risoluzione dell’interrogazione; • estrazione degli snippet; Il primo modulo `e TR-API – TauRo Application Programming Interface – che riceve l’interrogazione in TRQL dall’applicazione con cui l’utente interagisce. L’interrogazione ricevuta viene validata e sottoposta al modulo TR-Solver che si occupa della sua risoluzione e restituisce a TR-API una serie di risultati utili alla successiva estrazione delle occorrenze dal testo (snippet). Tali risultati sono poi inviati al modulo TR-DM – TauRo Document Manager – che dispone della collezione di documenti (possibilmente memorizzata in formato compresso), estrae gli snippet secondo il formato indicato nella clausola Return dell’interrogazione, e li restituisce all’applicazione che dovr`a presentarli all’utente. In dettaglio, il modulo TR-Solver riceve l’interrogazione validata e la trasforma in una propria rappresentazione attraverso la quale `e possibile scomporre l’interrogazione completa in interrogazioni elementari (risolte attingendo alle informazioni presenti nell’indice relativo alla collezione di documenti). Successivamente i risultati delle interrogazioni elementari vengono ricombinati e filtrati per ottenere quelli finali e definitivi. Nel caso in cui i documenti non siano stati ancora indicizzati (o nel caso in cui le risorse disponibili siano tali da non risultare conveniente la creazione di un indice), il sistema `e in grado di accedere direttamente ai documenti ed estrarne le informazioni necessarie

10

(per scansione): a parit` a di tempo, per`o, la mole di dati elaborabile `e inferiore rispetto al caso in cui la collezione di documenti sia stata indicizzata a priori. I tre moduli possono essere fusi in un’unica applicazione, oppure possono far parte di applicazioni distinte che comunicano attraverso la rete: in quest’ultimo caso le applicazioni e i dati possono risiedere su nodi diversi, anche distanti tra loro. In questo scenario i moduli comunicano attraverso un protocollo proprietario denominato TRIL, e descritto qui di seguito.

2.3 Protocollo di comunicazione e configurabilit` a TRIL – TauRo Interface Language – `e il protocollo di comunicazione tra i moduli di TauRo. Il protocollo `e basato su linguaggio XML e ha lo scopo di interfacciare i vari moduli nel caso in cui questi non facciano parte di una singola applicazione. Le sue funzionalit` a principali possono essere raggruppate in quattro categorie: Invio interrogazione : viene creato un messaggio incapsulando l’interrogazione in TRQL e aggiungendo la richiesta di invio dei risultati. Tale richiesta pu`o prevedere la restituzione di tutti i risultati, oppure la suddivisione dei risultati in blocchi. Questa comunicazione avviene da TR-API verso TR-Solver. Restituzione dei risultati : il formato di un risultato include diverse informazioni tra cui l’identificativo del documento in cui appare, e la posizione dell’occorrenza al suo interno. Questa comunicazione avviene da TR-Solver a TR-API. Richiesta di formazione snippet : Il protocollo mette a disposizione vari tipi di richieste per implementare le funzionalit`a descritte nella sezione 3.1 relativamente alla clausola Return. Questa comunicazione avviene da TR-API a TR-DM, utilizzando le informazioni ricevute da TR-Solver. Invio snippet : gli snippet sono scritti in XML in modo da essere incapsulati in TRIL. Questa comunicazione avviene da TR-DM a TR-API. Sebbene TauRo sia ancora in fase di sviluppo, la sua completa realizzazione render` a possibili diverse applicazioni, in diversi scenari, oltre quello standard di TReSy: single-user su singolo PC. In particolare prevediamo di utilizzare TauRo in tre diverse configurazioni architetturali, e quindi tre diversi scenari applicativi: Applicazione singola : i moduli formano un’unica applicazione. Questo accade quando `e necessario accedere ad una singola collezione di documenti memorizzata localmente. Questo scenario `e tipico della consultazione di documenti su CD-ROM o, pi` u in generale, nel caso in cui uno studioso abbia la necessit`a di analizzare testi memorizzati sul proprio computer o dispositivo mobile. Applicazione client-server : i documenti sono conservati su un sistema remoto, dove risiedono anche i moduli TR-Solver e TR-DM. L’utente accede in modo trasparente ai documenti sfruttando un’applicazione che include TR-API. Possibili

11

(a) Scenario client-server

(b) Scenario distribuito: i documenti sono dislocati in pi` u biblioteche

(c) Scenario distribuito: i documenti sono ripartiti tra i membri di un gruppo di ricerca

Figura 2: Possibili scenari di applicazione di TauRo; i moduli sono rappresentati in Fig. 1 campi di applicazione per questo scenario si trovano nell’ambito della consultazione dei testi di una singola biblioteca, della fruizione delle opere di un museo, o delle schede catalografiche di una soprintendenza (Fig. 2(a)). Applicazione distribuita : in questo caso i documenti possono essere ripartiti su diversi sistemi dove viene eseguita un’istanza del modulo TR-DM. Nel caso pi` u semplice un indice globale di tutti i documenti viene utilizzato dall’unica istanza del modulo TR-Solver per recuperare le occorrenze dei risultati senza dover accedere ai testi. Gli utenti si collegano al sistema utilizzando un’applicazione simile a quella descritta per le applicazioni client-server: l’utente non `e tenuto a sapere se i documenti siano centralizzati (come nel caso precedente) o distribuiti. Un esempio di applicazione distribuita `e dato da un sistema coordinato di soprintendenze, musei o biblioteche (Fig. 2(b)). In generale ogni ente si occupa della memorizzazione e della gestione dei propri documenti, ma le ricerche sono eseguibili sull’unione delle collezioni. Un altro esempio pu`o essere quello di un gruppo di ricerca che partecipa ad un progetto di realizzazione di un corpus digitale di testi creato incrementalmente e in modalit`a autonoma rispetto alle risorse e ai collaboratori (Fig. 2(c)). La disponibilit` a di un linguaggio di interrogazione potente e intuitivo (quale TRIL) e la struttura modulare dell’architettura ci hanno permesso di avviare una prima sperimentazione di TauRo per la creazione di un sistema-servizio di memorizzazione e fruizione di dati XML in Rete completamente e direttamente gestibile dall’utente in remoto tramite il suo browser preferito (Netscape, Firefox, Opera, . . . ). Grazie alle potenzialit` a di TauRo un qualunque utente, in qualunque parte del mondo, anche attraverso dispositivi mobili quali smart-phone e palmari, potr`a creare e gestire via Web la propria collezione di testi XML che potr`a consultare mediante interrogazioni formulate attraverso una interfaccia web (per utenti meno esperti) o mediante TRIL (per

12

utenti esperti). Ci auspichiamo che la facilit`a di utilizzo, la versatilit`a e la potenza di TauRo, risultino i fattori determinanti per la sua diffusione nell’ambito dell’ indicizzazione e ricerca di grandi collezioni documentali XML quali biblioteche digitali, ma non solo. In questo modo intendiamo contribuire fattivamente a quel processo avvincente di condivisone e fruibilit` a di risorse comuni e aperte in Rete, sullo stile della biblioteca digitale GoogleScholar8 e della recentissima esperienza GoogleBase9 , qui adattata e potenziata tramite TauRo alla gestione e interrogazione di testi particolari e complessi quali quelli letterari in formato XML.

8 http://scholar.google.com 9 http://base.google.com

13