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 testua-
le informatizzata ci ha spinto a partecipare con un contributo originale, e auspichiamo
significativo, alla sfida recente della digitalizzazione e analisi informatica dei testi let-
terari. La definitiva affermazione del formato XML da un lato, e dei motori di ricerca
alla Google dall’altro, offrono una stimolante opportunità tecnologica per la fruizione
di grandi quantità di dati su normali PC o anche su dispositivi portatili quali smart-
phone e palmari; ma pongono anche numerose difficoltà algoritmiche e sistemistiche il
cui superamento costituirà la nuova sfida intrapresa con il progetto TauRo descritto
in questo articolo.
La descrizione delle caratteristiche algoritmiche di TauRo e delle motivazioni sot-
tostanti 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 co-
difica 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 appli-
cato a tali documenti, e quali fossero le effettive necessità di chi operava nel difficile
contesto della digitalizzazione di fonti letterarie delle più 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ù sofisticate funzionalità di ricerca e analisi dei testi letterari. Queste funzionalità
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ù sofisticate funzionalità
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ù sofisticate ed evolute.
Un motore di ricerca ha lo scopo di recuperare da una collezione di testi le in-
formazioni 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à di ricercare sia nel contenuto testuale del documento che
nella sua struttura codificata, appunto, tramite il formato XML. Ciò inevitabilmente
consente all’utente di progettare interrogazioni più sofisticate e selettive, cosı̀ da ren-
dere il suo processo di analisi dei testi potenzialmente più 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à “data centric”, ovvero con-
sentono di gestire documenti strutturati in campi e con forte regolarità 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à “document centric” (ad esempio eXist 4 e Gala-
TeX 5 ), ovvero per trattare documenti con struttura irregolare, pochi campi e molto
testo, quali appunto le fonti letterarie. Il nostro studio si è 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à di un motore di ricerca è 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ù selettive. Recentemente il W3C ha esteso le funzionalità di XQuery
verso ricerche per contenuto più sofisticate, dette full-text, ma sono pochissimi i motori
di ricerca che hanno già recepito e realizzato queste funzionalità:

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à;

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ù
efficiente in tempo e spazio rispetto a GalaTeX. Attualmente eXist è il motore di ricerca
per XML “di riferimento internazionale” grazie al suo elevato numero di funzionalità
in ricerca e alla sua efficienza. La valutazione dell’utilizzo di eXist nel nostro ambito di
interesse ci ha portato però 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à che un motore di ricerca dovrebbe offrire per soddi-
sfare 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à.
Oltre alle sofisticate tipologie di ricerca sul contenuto testuale, previste dal W3C, è
necessario fornire all’utente la possibilità 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à di restituzio-
ne dei risultati, in quanto questa è 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à è 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ù 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ò
dunque essere trascurata dai motori di ricerca sviluppati per esso.
Nell’ottica più propriamente informatica, un motore di ricerca XML dovrebbe inol-
tre consentire il suo utilizzo su più piattaforme (Desktop, palmari, cellulari) e su
collezioni documentali geograficamente distribuite (biblioteche, musei, soprintenden-
ze, 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 fun-
zionalità permettendo lo sviluppo di strumenti di text mining sempre più sofisticati
come, ad esempio, l’estrazione di frasi o pattern ritenuti rilevanti (motivi ), la naviga-
zione 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à di fornire suggerimenti all’utente per le sue ricerche in
base a quelle pregresse o al suo profilo. Non è 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ò il più
complesso e quindi costituisce, per la sua caratteristica mancanza di uniformità, il
banco di prova più stimolante e significativo.
Precedentemente avevamo introdotto eXist, quale motore di ricerca XML più diffuso
ed efficiente nel panorama internazionale. A questo punto risulta inevitabile chiedersi
se eXist offra le funzionalità 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à della struttura del documento : eXist non è stato in grado di indicizza-
re alcuni documenti presenti nella Biblioteca Virtuale Online (BiViO)6 , che pre-
senta 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) è il tag con il relativo contenuto. Per i nostri
scopi è preferibile una maggiore flessibilità 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 colle-

zione di documenti indicizzata, non sono soggette ad alcuna fase di compressione,
con un conseguente incremento dello spazio totale occupato dal motore di ricer-
ca. Questo potrebbe compromettere lo sviluppo di applicazioni su supporti con
ridotte capacità di memoria, o su collezioni testuali di grandi dimensioni.

Ricerche strutturali : eXist, come pressoché 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 è 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 è 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
è una delle esigenze più 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ù 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é su quelli semantici.
L’analisi di testi cosı̀ marcati può risultare difficoltosa per i motori di ricerca XML più
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à possa incontrare un motore di ricerca XML tradizio-
nale 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 è di Venezia con annotazioni di Arnoldo
<note>Arnaldo da Villanova.</note> 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é 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é sono separate dal contenuto del tag <note> . La nota,
peraltro, non fa parte del testo vero e proprio, ma, oltreché 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 è tenuto a conoscere le modalità
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ò
far emergere durante una ricerca:

[. . . ]Per <c>E</c>ndimione biso<lb />gna[. . . ]

La ‘E’ di ‘Endimione’ è marcata come maiuscola significativa perché iniziale di un nome

proprio: una ricerca eseguita con un motore tradizionale non troverebbe però la parola
‘Endimione’ perché, come si è già visto, questa risulterebbe divisa in più parti dal tag
<c>. Lo stesso si può dire per la parola ‘bisogna’ divisa dal tag puntuale <lb/> che
indica la fine di una linea.
L’esperienza maturata presso Signum ha dimostrato come sia necessario sviluppa-
re dei motori di ricerca che prevedano funzionalità di indicizzazione sufficientemente
flessibili e potenti da poter gestire correttamente fenomeni strutturali di questo tipo.
A questo scopo è 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 (<c>E</c>ndimione
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 cono-
scenza che il codificatore ha del linguaggio di marcatura. Va da sé che questa cate-
gorizzazione non è fissata a priori, ma può essere specializzata di volta in volta dal
codificatore in base alle necessità e alle caratteristiche del documento XML.

2 TauRo
Il nome TauRo nasce dall’acronimo di Text Retrieval componendo il nome delle corri-
spondenti lettere dell’alfabeto greco: Tau e Ro.
Le innovazioni che il motore TauRo presenta sia rispetto a TReSy che rispetto al-
lo stato dell’arte, precedentemente illustrato, riguardano le specifiche funzionalità 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’in-
tento di renderlo utilizzabile anche dall’utente finale e non solo dall’esperto software,
è espresso in termini di sintassi XML. Tale linguaggio verrà illustrato nel prossimo
paragrafo; successivamente sarà illustrata l’architettura del sistema, progettata con lo
scopo di ottenere la flessibilità necessaria per il suo utilizzo nei diversi scenari appli-
cativi commentati nel paragrafo 1.2; infine verrà mostrato il protocollo di comunica-
zione 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 è 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à 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
è 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 è tenuto
a utilizzare direttamente tale linguaggio, piuttosto potrà interagire con un’applicazione
demandata alla costruzione dell’interrogazione in TRQL. Al fine di esemplificare l’uso
di TRQL mostriamo un esempio:

7
 Select
<libro anno=’1721’>
<titolo xml var=’$t’>
<xml exact>storia</xml exact>
</titolo>
<autore xml var=’$a0 ></autore>
</libro>
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 inter-
rogazione relativa alla Select risultano diversi gli elementi da valutare. Dal punto
di vista della struttura del documento, la ricerca viene ristretta ai tag <libro> nel
cui contenuto siano presenti il tag <titolo> e il tag <autore>. Inoltre è 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 <titolo>. Più in generale, la ricerca
di una parola nel testo è 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, rispettiva-
mente, 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</xml error> 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 sem-
plicità 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 pre-
fissata. Le parole sono specificate utilizzando una combinazione degli operatori
precedenti. Ad esempio, è 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 exact>
<xml prefix>gr</xml prefix>
</xml proximity>

Per ogni ricerca è 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 del-
l’attributo speciale xml var adottato per dichiarare una variabile. TauRo associa ad
una variabile i risultati della ricerca relativi al tag in cui è dichiarata. È possibile
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 è la parola che
ha soddisfatto il criterio di ricerca. Nell’esempio sono presenti le variabili $t e $a:
la prima è legata ai risultati relativi al tag <titolo>, la seconda a quelli del tag
<autore>. Le variabili dichiarate con xml var (nell’esempio $t e $a) compaiono an-
che nella clausola Return con lo scopo di indicare come dovranno essere formati gli
snippet. Se nel documento biblioteca.xml, oggetto della ricerca, è presente il libro
‘Storia Fiorentina’ di Benedetto Varchi, lo snippet relativo a tale occorrenza apparirà
in questo modo:
autore: <autore>Benedetto Varchi</autore>
titolo: <titolo>Storia Fiorentina di Messer Benedetto Varchi
</titolo>
Va da sé che il linguaggio fornisca altri meccanismi per ottenere formati di snippet
più 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:

• è possibile visualizzare il valore di un attributo di un tag, ignorandone il contenu-

to, mediante l’associazione di $x all’attributo. Sintassi: $x[nome attributo ].

• è possibile estrarre il testo intorno all’occorrenza relativa a $x indicando l’ampiez-

za della finestra in numero di parole. Sintassi: $x.win(ampiezza finestra ).

• è possibile restituire un tag che contiene l’elemento corrispondente a $x, speci-

ficando 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ù piattaforme (Desktop, palmari, cellulari) e su collezioni

documentali geograficamente distribuite (biblioteche, musei, soprintendenze, etc.). A
tal fine, l’architettura del sistema è stata organizzata in tre moduli (Fig. 1):

• interfaccia verso l’applicazione dell’utente;

• risoluzione dell’interrogazione;

• estrazione degli snippet;

Il primo modulo è TR-API – TauRo Application Programming Interface – che riceve

l’interrogazione in TRQL dall’applicazione con cui l’utente interagisce. L’interrogazio-
ne 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 (possibilmen-
te memorizzata in formato compresso), estrae gli snippet secondo il formato indicato
nella clausola Return dell’interrogazione, e li restituisce all’applicazione che dovrà
presentarli all’utente.
In dettaglio, il modulo TR-Solver riceve l’interrogazione validata e la trasforma in
una propria rappresentazione attraverso la quale è possibile scomporre l’interrogazio-
ne completa in interrogazioni elementari (risolte attingendo alle informazioni presenti
nell’indice relativo alla collezione di documenti). Successivamente i risultati delle inter-
rogazioni 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
è in grado di accedere direttamente ai documenti ed estrarne le informazioni necessarie

10
(per scansione): a parità di tempo, però, la mole di dati elaborabile è 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à

TRIL – TauRo Interface Language – è il protocollo di comunicazione tra i moduli di
TauRo. Il protocollo è 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à principali possono essere raggruppate in quattro categorie:

Invio interrogazione : viene creato un messaggio incapsulando l’interrogazione in TR-

QL e aggiungendo la richiesta di invio dei risultati. Tale richiesta può 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 ri-

chieste per implementare le funzionalità 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 ren-
derà 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 quan-

do è necessario accedere ad una singola collezione di documenti memorizzata lo-
calmente. Questo scenario è tipico della consultazione di documenti su CD-ROM
o, più in generale, nel caso in cui uno studioso abbia la necessità 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 tra-
sparente ai documenti sfruttando un’applicazione che include TR-API. Possibili

11
 (a) Scenario client-server (b) Scenario distribuito: i do- (c) Scenario distribuito: i do-
cumenti sono dislocati in più cumenti sono ripartiti tra i
biblioteche 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 consulta-

zione 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 di-

versi sistemi dove viene eseguita un’istanza del modulo TR-DM. Nel caso più
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 è tenuto
a sapere se i documenti siano centralizzati (come nel caso precedente) o distri-
buiti. Un esempio di applicazione distribuita è dato da un sistema coordinato
di soprintendenze, musei o biblioteche (Fig. 2(b)). In generale ogni ente si oc-
cupa della memorizzazione e della gestione dei propri documenti, ma le ricerche
sono eseguibili sull’unione delle collezioni. Un altro esempio può 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à autonoma rispetto alle
risorse e ai collaboratori (Fig. 2(c)).

La disponibilità di un linguaggio di interrogazione potente e intuitivo (quale TRIL)

e la struttura modulare dell’architettura ci hanno permesso di avviare una prima spe-
rimentazione 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à di TauRo un qualunque utente, in qualunque parte del mondo, anche at-
traverso dispositivi mobili quali smart-phone e palmari, potrà creare e gestire via Web
la propria collezione di testi XML che potrà consultare mediante interrogazioni formu-
late attraverso una interfaccia web (per utenti meno esperti) o mediante TRIL (per

12
utenti esperti). Ci auspichiamo che la facilità di utilizzo, la versatilità e la potenza di
TauRo, risultino i fattori determinanti per la sua diffusione nell’ambito dell’ indicizza-
zione 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à 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