Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
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à:
2. ricerca di frasi;
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);
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.
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:
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);
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.
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
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
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:
9
Figura 1: Schema dell’architettura di TauRo
• risoluzione dell’interrogazione;
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.
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:
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
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