Post on 20-Nov-2014
description
ALMA MATER STUDIORUM - UNIVERSITÀ DI BOLOGNA FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALI
CORSO DI LAUREA TRIENNALE IN INFORMATICA
SISTEMA CONFIGURABILE PER IL
COLLEGAMENTO ASSISTITO DI DOCUMENTI
NON STRUTTURATI A DOCUMENTI
STRUTTURATI IN UN EDMS ATTRAVERSO
L’UTILIZZO DEI MOTORI DI RICERCA
Tesi di laurea in
BASI DI DATI E SISTEMI INFORMATIVI
Relatore
PROF. DANILO MONTESI
Presentata da
ALESSANDRO BONDI
Matricola n. 0000100333
Anno Accademico 2007/08
Sessione III
2
Parole chiave:
documento
information retrieval
collegamento
meta motore
sistema di voto
3
TAVOLA DEI CONTENUTI
Tavola dei contenuti ................................................................................................ 3
Indice delle figure ................................................................................................... 7
Abstract ................................................................................................................... 9
Introduzione .......................................................................................................... 11
Premessa ............................................................................................................ 11
Obiettivi ............................................................................................................ 11
Organizzazione .................................................................................................. 11
1 La gestione documentale .............................................................................. 13
1.1 Definizioni ............................................................................................ 13
1.2 Il problema: la strutturazione di documenti non strutturati .................. 14
1.3 Il vantaggio nell‟utilizzare documenti strutturati .................................. 15
1.4 Il ciclo di vita di un documento: workflow documentale ..................... 16
2 Information Retrieval ................................................................................... 19
2.1 Introduzione .......................................................................................... 19
2.1.1 Nascita dell‟Information Retrieval .................................................... 20
2.1.2 Fasi del reperimento delle informazioni............................................ 20
2.1.3 Luhn e l‟IR ........................................................................................ 20
2.2 Sistemi di IR ......................................................................................... 24
2.2.1 Definizione del sistema ..................................................................... 24
2.2.2 Componenti di un sistema di IR ........................................................ 24
2.2.3 Processo di reperimento .................................................................... 25
2.3 Indicizzazione della collezione ............................................................. 25
2.3.1 Tecniche di indicizzazione ................................................................ 25
2.3.2 Semplificazione di documenti testuali .............................................. 26
2.3.3 Algoritmi di stemming ...................................................................... 27
2.3.4 Considerazioni sui moduli linguistici ................................................ 27
2.4 Modelli di IR ......................................................................................... 28
2.4.1 Modello booleano .............................................................................. 28
2.4.2 Modello fuzzy ................................................................................... 28
2.4.3 Modello probabilistico ...................................................................... 29
2.4.4 Modello vettoriale ............................................................................. 29
4
2.4.5 Modello cluster .................................................................................. 30
2.5 Valutazione dei sistemi di IR ................................................................ 30
2.5.1 Valutazione di rilevanza .................................................................... 30
2.5.2 Criteri di valutazione ......................................................................... 31
2.5.3 Misure di efficacia e parametri di valutazione .................................. 32
2.5.4 Precision e recall ............................................................................... 33
2.6 Web information retrieval ..................................................................... 34
2.6.1 I dati sul web ..................................................................................... 34
2.6.2 Evoluzione dei web search engine .................................................... 34
2.6.3 Web search engine – Indicizzazione e risultato ................................ 35
2.7 Collaborative filtering ........................................................................... 36
2.7.1 L‟aspetto umano ................................................................................ 36
2.7.2 Sistemi automatici ............................................................................. 36
2.7.3 Problematiche .................................................................................... 37
2.7.4 Tipologie ........................................................................................... 37
2.7.5 Algoritmi di predizione ..................................................................... 38
2.7.6 Raccolta delle preferenze .................................................................. 39
3 Meta motori di ricerca e Sistemi di voto ...................................................... 41
3.1 I meta motori di ricerca ......................................................................... 41
3.1.1 I meta motori di ricerca ..................................................................... 41
3.1.2 Formulazione delle query per i singoli motori .................................. 42
3.1.3 Raggruppamento dei risultati ............................................................ 42
3.2 Sistemi di voto ...................................................................................... 43
3.2.1 Le procedure di voto e i meta motori di ricerca ................................ 43
3.2.2 Il metodo Borda Count ...................................................................... 43
3.2.3 Esempio di applicazione del metodo Borda Count ........................... 44
4 Collegamento di documenti con la tecnica dei meta motori di ricerca ........ 45
4.1 Proposta di soluzione ............................................................................ 45
4.1.1 Utilizzo delle meta informazioni come punto di partenza ................ 45
4.1.2 Specifica ............................................................................................ 45
4.1.3 Entità di riferimento .......................................................................... 46
4.1.4 Diagramma ER .................................................................................. 49
5
4.1.5 Algoritmo generale ............................................................................ 49
4.2 Macroanalisi dei blocchi principali ....................................................... 50
4.2.1 Configurazione delle QueryString .................................................... 50
4.2.2 Esecuzione delle QueryString e prima elaborazione dei risultati ..... 52
4.2.3 Post-Filtering: Merge dei risultati e gestione dei duplicati ............... 52
4.3 Aspetti implementativi .......................................................................... 52
4.3.1 Inizializzazione dei collegamenti ...................................................... 52
4.3.2 Esecuzione della procedura ............................................................... 52
4.3.3 Grado di affidabilità delle query e dei motori di ricerca ................... 53
4.3.4 Modalità di interazione con i motori di ricerca ................................. 53
4.3.5 Gestione dei tipi di dato e della formattazione dei valori ................. 53
4.3.6 Controllo di accesso .......................................................................... 54
5 Prodotti e tecnologie utilizzate ..................................................................... 55
5.1 KarthaDoc ............................................................................................. 55
5.1.1 Presentazione ..................................................................................... 55
5.1.2 Funzionalità ....................................................................................... 55
5.1.3 Tecnologia ......................................................................................... 56
5.2 Google Mini (search appliance) ............................................................ 58
5.2.1 Presentazione ..................................................................................... 58
5.2.2 Funzionalità ....................................................................................... 58
5.2.3 Il supporto concreto offerto ............................................................... 59
5.2.4 Motivazioni relativi alla soluzione integrata ..................................... 59
5.2.5 Differenze tra Google Mini e Google Mini ....................................... 59
5.3 Web service ........................................................................................... 60
5.3.1 Definizione W3C............................................................................... 60
5.3.2 Funzionamento dei web service ........................................................ 61
5.3.3 Principali vantaggi............................................................................. 62
5.3.4 Svantaggi e problematiche ................................................................ 62
6 Ricerca futura ............................................................................................... 65
6.1 Utilizzo di sistemi informativi diversi .................................................. 65
6.2 Usabilità relativa alla configurazione delle query ................................ 65
6.3 Utilizzo dei coefficienti di rilevanza (relevance scores) ...................... 66
6
6.4 Interazione con l‟utente per la verifica dei risultati .............................. 67
6.4.1 Metodo “Feedback” (eBay) ............................................................... 67
6.4.2 Metodo “Pool” (quiz, sondaggi, etc.) ................................................ 68
6.5 Falsi negativi e autoapprendimento ...................................................... 68
6.5.1 Azioni da parte degli utenti relative ai falsi negativi ........................ 68
6.5.2 Meccanismi di autoapprendimento ................................................... 69
Conclusioni ........................................................................................................... 71
Riferimenti bibliografici........................................................................................ 73
Appendice A – Presentazione ............................................................................... 77
Frontespizio ....................................................................................................... 77
Gestione documentale ....................................................................................... 78
Collegamento tra documenti strutturati e documenti non strutturati ................ 80
Information Retrieval ........................................................................................ 81
Meta motori di ricerca ....................................................................................... 83
Sistemi di voto .................................................................................................. 84
Proposta di soluzione del problema .................................................................. 85
Algoritmo generale............................................................................................ 86
Sviluppi ............................................................................................................. 87
Conclusioni ....................................................................................................... 88
Riconoscimenti ...................................................................................................... 91
Colophon ............................................................................................................... 93
7
INDICE DELLE FIGURE
Figura 1 Diagramma di frequenza delle parole: l'ascissa rappresenta le singole
parole in ordine di frequenza. ......................................................................................... 21
Figura 3.1 Algoritmo semplificato di un meta motore di ricerca .......................... 41
Figura 4.1 Diagramma ER .................................................................................... 49
8
9
ABSTRACT
«Prendi la direzione opposta all ’abitudine
e quasi sempre farai bene.»
Jean-Jacques Rousseau
Pensiamo a quanti documenti di vitale importanza vengano persi o
dimenticati al l‟interno di una qualsiasi rete aziendale. Va da sé che la
mancata fruizione di queste informazioni può comportare un danno
economico perché i l loro recupero può essere laborioso o, nella
peggiore delle ipotesi , può non avvenire.
I documenti costi tuiscono la base del patrimonio informat ivo di
qualsiasi realtà : i l vero valore aggiunto è riuscire ad individuare e a
conservare le relazioni al l‟ interno di questo sistema.
La ricerca nel set tore documentale oggi è orientata verso i l
problema della strut turazione dei documenti non strutturat i al fine di
poter costruire queste relazioni tra documenti al l ‟apparenza eterogenei
tra loro. Ribaltando i l concetto, è invece più semplice ottenere
documenti non st rut turati a part ire da documenti strutt urati definendo
per ogni t ipologia di documento un template da dare in pasto ad un
sistema automatico.
La domanda potrebbe essere quindi così posta: come è possibile
ricercare collegamenti tra documenti strutturati e non strutturati
attraverso questo “nuovo” documento ottenuto?
L‟ idea, nata durante la let tura di pubblicazioni riguardanti i l
problema della strutturazione, è stata questa:
da un documento strutturato è possibile ottenere una query di
ricerca (t ramite un template opportunamente costruito posso
così ottenere questo “nuovo” documento);
è possibile ricercare questi collegamenti dando in pasto la
query generata ad un motore di ricerca che ha
10
precedentemente indicizzato tutt i i documenti non
strutturati .
In questo progetto di tesi sono indicate alcune metodologie e
tecniche, nuove e antiche, opportunamente adattate e connesse per
rintracciare e mantenere queste relazioni così importanti .
11
INTRODUZIONE
«Tutto ciò che è scrit to unicamente per far
piacere all ’autore è senza valore.»
Blaise Pascal
Premessa
Il presente lavoro è finalizzato al la progettazione di un
componente software (nella fatt ispecie, un web service) per i l supporto
al collegamento tra documenti strutturat i e non strutturati .
Obiettivi
Lo scopo della tesi è di progettare un sistema configurabile per i l
collegamento assist i to di documenti non strutturati a documenti
strutturati in un sistema di gestione documentale.
Tale componente deve essere realmente applicabile e di facile
uti l izzo, grazie all ‟ interfaccia web e alla stesura di procedure che
guidano l‟utente passo per passo.
La progettazione verrà effettuata a l ivello generale pensando ad un
componente integrabile in diversi sistemi informativi , anche se nello
specifico si farà riferimento ad un sistema di gestione documentale.
La st ruttura del servizio dovrà quindi essere f lessibile,
configurabile ed allo stesso tempo indipendente, al fine di rispondere
alle esigenze di ogni singolo t ipologia di documento.
Dovranno comunque di volta in volta essere prese in
considerazione le peculi ari tà del sistema informativo in analisi per
permettere un ‟ integrazione che allo s tesso tempo sia efficace ed
efficiente.
Organizzazione
Nella presente tesi verranno descrit te tutte le fasi della
progettazione.
12
Nel capitolo 1 verranno esposti gli aspett i r elativi al la gestione
documentale, al fine di chiari re i concett i di base ed individuare i l
problema proposto.
Nel capitolo 2 verranno esposti i concett i generali relativi al
mondo dell‟ Information ret rieval , disciplina che è alla base del
funzionamento dei motori di ricerca.
Nel capitolo 3 verrà analizzata la struttura dei meta motori di
ricerca e come i sistemi di voto vengano in aiuto nella compilazione del
risultato finale.
Nel capitolo 4 verrà proposta la soluzione del problema attraverso
la destrutturazione dei documenti strutturati , con l ‟aiuto dei meta
motori di ricerca.
Nel capitolo 5 si descriveranno i prodot ti e le tecnologie che sono
state considerate nel la pratica per l ‟analisi in questione.
Nel capitolo 6 saranno delineati gli spunti di ricerca futuri emersi
dalla t rat tazione.
Infine, verranno riportate alcune note conclusive.
13
1 LA GESTIONE DOCUMENTALE
«Pensiamo per concett i genera li , ma
viviamo di particolari .»
Alfred North Whitehead
1.1 Definizioni
Un documento può essere visto come un ‟ informazione organizzata
o un oggetto, t rat tato come unità.
Un documento non-strutturato è un documento senza un formato
specifico (ad esempio, un fi le di testo); un documento semi-strutturato
è un documento diviso in sezioni o paragrafi (ad esempio, un testo
formattato o una pagina web) .
I meta data (meta informazioni ) sono informazioni strutturate che
descrivono singoli oggett i per fornire conoscenze aggiuntive per
trovare, gestire , controllare, capire o preservare tal i oggett i .
Un l inguaggio di annotazione ( l inguaggio di markup ) è un sistema
formale per scambiare o pubblicare informazioni in modo strutturato.
XML è un l inguaggio di annotazione che fornisce un formato per la
descrizione di dati strutturati , che consente di dichiarare con maggior
precisione i l contenuto dei dati e di ottenere risultat i più s ignificativi
nelle ricerche eseguite su diverse piattaforme (definisce in modo non
ambiguo la st ruttura dei dati contenuti nel docu mento).
Un documento strutturato è un documento che al suo interno
contiene un l inguaggio di annotazione che definisca le informazioni di
base relative al documento stesso (es. l‟autore di un documento, i l
cl iente a cui fa riferimento una fattura, i l mitte nte di un messaggio di
posta elettronica). La strutturazione dei documenti è un aspetto
importante dato che permette di elaborare i documenti in modo
automatico (archiviazione) e renderli facilmente recuperabil i ed
interpretabil i .
14
Una classe di documento (document class ) è la definizione delle
meta informazioni che sono contenute in un documento strutturato (es.
art icolo, fat tura, messaggio di posta elettronica). In l inguaggio XML,
un documento st rutturato è un ‟ istanza di documento mentre una classe
di documento è quel l ‟ insieme di regole che l ‟ istanza di documento deve
rispettare.
La gestione dei documenti (document management ) è i l processo di
acquisizione, condivisione, tracciamento, revisione e distr ibuzione di
documenti e delle informazioni in essi conte nute.
Un sistema di gestione documentale (document management system
– DMS) è un sistema automatico di supporto alla creazione, uti l izzo e
manutenzione per la creazione di documenti (non dati ).
Un records management system (RMS) è un sistema per
l‟ identi ficazione, la classificazione, l ‟archiviazione e, a volte, la
cancellazione di record (rappresentati da singoli documenti).
Un sistema di gest ione documentale elettronica (EDMS) è un
sistema completo software e hardware per la gestione documentale;
include servizi di indicizzazione e ricerca dei documenti , acquisizione,
OCR, mass storage, gestione del worflow e della
condivisione/collaborazione.
Un electronic records management system (ERMS ) è un sistema
automatico per gest ire la creazione, l ‟util izzo, la manutenzione e la
distribuzione di record elettronici; questi sistemi mantengono delle
informazioni contestuali appropriate (metadata) e collegamenti tra
record al fine di evidenziare i l loro contenuto.
1.2 Il problema: la strutturazione d i documenti non
strutturati
La maggior parte delle informazioni aziendali (circa l ‟80%) è
composta da documenti non strutturati , mentre gli at tuali sistemi di
gestione documental i non sono in grado di gesti re tal i documenti senza
un consistente intervento umano. Fino a poco tempo fa l ‟unico modo
che si aveva per gestire un documento di questo t ipo era la sua let tura
15
da un operatore e la successiva indicizzazione manuale all ‟ interno di un
EDMS. [Mur03]
Recentemente sono nati sistemi di auto classificazione e di auto
estrazione che riescono ad estrarre da documenti elett ronici non
strutturati o da documenti cartacei st rutturati (at traverso un sistema di
OCR) le informazioni necessarie per una loro indicizzazione automatica
o un loro inserimento in un sistema di gestione documentale.
Il problema della strutturazione di documenti non st rutturati
rimane comunque uno dei punti chiave della ricerca in campo
documentale, data la mole di informazioni che deve essere gesti ta ogni
giorno dalle aziende e dalla necessità di trasfor mare ogni singolo
documento in una componente del proprio patrimonio informativo.
1.3 Il vantaggio nell ’utilizzare documenti strutturati
L‟util izzo di strumenti per la strutturazione dei documenti è la via
più efficace ed economica per gestire le informazioni. La st rutturazione
delle informazioni è un processo naturale della mente umana spesso
sottovalutato o considerato implicito , ma l ‟umanità ha sempre
considerato questo processo come fondamentale nella stesura di
documenti (basti pensare all ‟util izzo di sommari , indici , divisione in
capitoli /paragrafi). [MR96]
La strutturazione dei documenti permette di:
elaborare i documenti in maniera automatica in processi di
archiviazione o di es trazione dati ;
effettuare ricerche efficaci in una base documentale;
rendere i l contenuto del documento faci lmente recuperabile
ed interpretabile;
identificare, elaborare ed estrarre qualsiasi parte di
documento.
L‟archiviazione di tal i documenti risulterà tanto dettagliata quanto
la finezza della granulari tà della classe di docume nto, superando così
gli inconvenienti dell ‟archiviazione dei documenti come fi le interi .
Generalmente un documento st rutturato viene quindi visto come un
16
insieme ordinato di nodi et ichettati , organizzato gerarchicamente con
una st ruttura ad albero, permett endo un‟ulteriore gestione della
struttura gerarchica che a sua volta avvia una catena di elaborazione
automatica del documento (es. sistemi di gestione automatica del
workflow in cui ogni processo aziendale viene accompagnato dalla
relativa documentazione che passa di elaborazione in elaborazione).
[GalCap03]
1.4 Il ciclo di vita di un documento : workflow
documentale
Parlando del ciclo di vita di un documento occorre considerare i l
lavoro dei sistemi di gestione documentale, i l cui compito è proprio di
seguire potenzialmente tutto i l ciclo di vita di un documento, dalla sua
creazione in poi, gestendo aspett i che spaziano dalla memorizzazione
alla ricerca, dalla condivisione fra i dipendenti al la pubblicazione su
Internet (tra le funzioni cri t iche anche la defin izione dei diri t t i di
accesso ai documenti e la forma in cui essi possono essere visualizzati
o stampati ) . Tali sis temi possono anche interfacciarsi con i sistemi di
workflow, un aspetto particolarmente uti le quando i documenti sono
parte di un processo ben definito (per esempio l ‟approvazione di
acquisti ) che vede coinvolte più figure aziendali .
Analizziamo ora i l processo di creazione e gestione di un
documento condiviso.
La prima azione è la creazione del documento (anche detta check-
in): questa non si esaurisce con la sola scri t tura del documento, ma è
necessaria la sua archiviazione tenendo conto delle meta informazioni
ad esso associate che rappresentano i l documento (quasi) a prescindere
dal proprio contenuto (es. autore, data di creazione, progetto di
riferimento). Tali informazioni sono essenziali nella logica
organizzativa della gestione di un documento strutturato.
È comunque diffici le creare elementi di catalogazione oggett ivi
per chi deve progettare tutte le categorie in cui devono essere
organizzati i documenti: un documento può appartenere a più categorie,
17
oppure l ‟utente che deve scegliere dove classificare i l proprio
documento (alcuni sistemi uti l izzano allora sistemi automatici di
categorizzazione semantica che si basano sul algoritmi di text mining ).
Per quanto riguarda l ‟archiviazione del documento, i l sistema deve
conservare non solo i l documento fis ico, ma anche l ‟ insieme dei
metadati a esso associati . Normalmente si parla di repository , anche se
in realtà l ‟archiviazione fisica del documento è effettuata in un fi le
system e quella dei metadati in un database relazionale. Si crea
successivamente una serie di collegamenti fra i due archivi tenendo
presente che l ‟utente, per accedere a un fi le (sul fi le system), deve
passare dal database che conserva i metadati collegati a quel fi le.
L‟architettura quindi normalmente è a tre l ivell i : i l cl ient (ult imamente
un browser) , i l server di gestione e i due elementi di archiviazione
(repository) .
A questo punto i l documento inizia a viaggiare log icamente
nell‟azienda e viene uti l izzato per acquisire conoscenza e per prendere
decisioni. Si parla quindi di workflow documentale definendolo come
un modello "a t re R": routes (processi: la sequenza di passi), rules
(azioni: ciò che va fatto) e roles (persone: chi lo deve fare) . Il
workflow documentale, che va ben dist into dal workflow di processo,
assume diversi aspett i a seconda del t ipo di processo: sequenziale,
condizionale, "t ime driven" (scandito dal tempo) o parallelo. [NW00]
In questo t rattato non analizzeremo gli aspett i propri di una
gestione di workflow non essendo oggetto del lavoro di tes i , ma questa
breve analisi è importante per capire l ‟effett iva importanza della meta
informazioni associate ad un documento.
18
19
2 INFORMATION RETRIEVAL
«La verità si r i trova sempre nella
semplicità, mai nella confusione.»
Isaac Newton
2.1 Introduzione
L'Information ret rieval ( IR) (let teralmente “recupero
d'informazioni”) è l ' insieme delle tecniche uti l izzate per i l recupero
mirato dell ‟informazione in formato elettr onico. Per "informazione" si
intendono tutt i i documenti , i metadati , i fi le presenti al l ' interno di
banche dati o nel world wide web.
L' IR è un campo interdisciplinare che nasce dall ' incrocio di
discipline diverse. L' IR coinvolge la psicologia cognitiva, l 'architettura
informativa, la fi losofia, i l design, i l comportamento umano
sull 'informazione, la l inguistica, la semiotica, la scienza
dell ' informazione e l ' informatica.
Per recuperare l ' informazione, i sistemi IR usano i l inguaggi di
interrogazione basat i su comandi tes tuali . Due concett i s ono di
fondamentale importanza, query ed ogget to :
le query ("interrogazioni") sono stringhe di parole -chiavi
rappresentanti l ' informazione richies ta: vengono digitate
dall 'utente in un sistema IR (per esempio, un motore di
ricerca);
un oggetto è un 'enti tà che mantiene o racchiude informazioni
in una banca dati (un documento di testo, pe r esempio, è un
oggetto).
Una t ipica ricerca di IR ha come input un comando dell 'utente. Poi
la sua query viene messa in relazione con gl i oggett i presenti nella
banca dati . In risposta, i l sistema fornisce un insieme di record che
soddisfano le condizioni richieste.
20
Spesso i documenti stessi non sono mantenuti o immagazzinati
direttamente nel sistema IR, ma vengono rappresentati da loro su rrogati
(i motori di ricerca del Web sono le applicazioni più note ed ovvie delle
teorie di Information Retrieval).
2.1.1 Nascita dell’ Information Retrieval
Il termine IR fu coniato nel 1952 da Calvin Mooers che tra l‟altro
formulò la “legge di Mooers” che è s icuramente un riferimento da non
perdere mai di vista nella progettazione di sistemi di IR :
«Un sistema di reperimento delle informazioni tenderà a non
essere usato quando trovare le informazioni è più noioso e doloroso
che non trovarle».
I primi studi t ra i l ‟50 e i l ‟60 posero le basi della analisi stat ist ica
del l inguaggio che è quella disciplina che ha l‟obiett ivo di definire
leggi di distribuzione di probabil i tà che permettano di elaborare i
modell i di rappresentazione applicabil i a qualunque contesto
l inguistico. Nel caso dell‟ IR ciò ha lo scopo di ott imizzare
l‟individuazione dei termini indicatori del contenuto.
2.1.2 Fasi del reperimento delle informazioni
Le due fasi fondamentali per i l reperimento delle informazioni
sono:
1. la rappresentazione del conten uto dei documenti;
2. la rappresentazione del fabbisogno informativo dell‟utente.
Tecnicamente la rappresentazione del contenuto del documento
consiste nella “indicizzazione” cioè nel processo di selezione dai
documenti di termini indice “specifici” ed “esaus tivi” adatt i a
rappresentarne i l contenuto.
2.1.3 Luhn e l ’IR
Ma fu l‟analisi di Luhn nel 1958 che diede una spinta s ignificativa
con la definizione che la capacità dei termini di discriminare i l
contenuto dei documenti è massima nella posizione intermedia t ra i 2
l ivell i di cut -off della distribuzione di frequenza.
21
Egli asseriva che la frequenza con cui alcune parole compaiono in
un testo forniscono un parametro importante del significato delle
parole. Inoltre dice che i l posizionamento di queste parole all ‟ interno
delle frasi è un al tro parametro che indica i l significato e quindi
l‟ importanza delle frasi . Quindi l ‟ importanza e i l significato di una
frase è dato dalla combinazione di questi due fattori . Possiamo
affermare che la frequenza con cui alcune parole compaiono in un testo,
può essere usata per rappresentare un documento [Luh58].
Se pensiamo all ‟ indicizzazione automatica dei test i , possiamo
immaginare l ‟ importanza di questo principio, infatt i se per un essere
umano è facile capire l ‟ importanza di un tes to e individuarne gli
argomenti trat tat i , per un calcolatore questo è molto più complicato.
Come può capire l ‟argomento trattato in un testo? E come può capirne
l‟ importanza? La frequenza con cui le parole compaiono in un testo può
dare un grande aiuto, an che se non basta contare le parole e vedere
quella che compare più volte per classificare un documento
Figura 1 Diagra mma di frequenza del le pa role: l 'a sc i ssa ra ppresenta le
s ingole parole in ordine di frequenza .
22
Luhn usò la legge di Zipf [Zip49] per specificare due “cut -off”,
uno alto e uno basso. La l inea di cut -off al ta , taglia tutte le parole che
occorrono troppo frequentemente e che quindi non sarebbero indicative
per rappresentare un testo, in i tal iano immaginiamo la congiun zione “e”
oppure gli art icoli . Il cut -off basso invece serve per eliminare le parole
che compaiono troppo raramente e che quindi non sono indicative per
identificare un testo; immaginiamo che in un art icolo compaia una volta
la parola “addizione”, non sarebbe sufficiente per dire che i l testo tratta
di ari tmetica.
Oltre a questo, Luhn stabil ì una regola basata su delle tecniche di
conteggio per stabil i re a quale frequenza le parole sono da considerarsi
più significative e quindi più uti l i per discriminare i l contenuto del
testo. Questa funzione raggiunge i l suo picco a metà via tra i due cut -
off, per poi scendere nelle due direzioni, avvicinandosi al lo zero in
corrispondenza delle due l inee di cut -off . A questo punto appare chiaro
che una parte molto importante del lavoro è definire i punti di cut -off:
ancora adesso vi è una buona dose di arbit rarietà nel definire questi
l imiti .
Luhn uti l izzò questa tecnica per definire dei sommari automatici
dei test i , successivamente è stata uti l izzata per stabil ire l ‟ importanza
delle parole da indicizzare. Successivamente la regola di Luhn fu
raffinata, normalizzando le sue misure rispetto alla frequenza di ogni
parole nel testo totale, quindi se una parola compare 4 volte in una
frase e 200 volte nel testo totale, l ‟ importanza della parola sarà 4/200.
L‟analisi automatica dei test i si è r ivelata ovviamente molto
importante per quanto riguarda l ‟ indicizzazione di questi . Un indice è
formato da un insieme di termini chiamati termini indice, che sono
ricavati dai test i per l ‟appunto indicizzati . Due importanti fat tori per
valutare un indice sono esaustività e specifici tà. Per ogni indice
l‟esaustività è definita dal numero di “topic” (argomenti) indicizzati ,
mentre la specifici tà è l ‟abil i tà di un indice di descrivere a fondo un
23
argomento. La specifici tà venne defini ta [Kar04] come la precisione
con cui un documento è indicizzato.
È comunque intuibile che questi fat tori sono diffici lmente
quantificabil i : quantificarl i è molto importante per aumentare
l‟efficacia del reperimento dei documenti , infatt i un indice con alta
esaustività porta ad avere un alto r ichiamo ([documenti ri levanti
reperit i] /[documenti ri levanti totali reperit i e non -reperit i]) e una bassa
precisione ([documenti ri levanti reperit i] /[documenti totali reperit i]) .
(d‟altra parte una bassa esaustività porta ad un ‟alta precisione e ad un
basso richiamo). La stessa cosa si veri fica con la specifici tà , più alta è
questa maggiore è la precisione e mi nore è i l richiamo e viceversa
(precisione e richiamo sono due grandez ze inversamente proporzionali ,
al l‟aumentare di una diminuisce l ‟altra)
Un modo per controllare esaustività e specifici tà di un indice è
quello di pesare i termini indice ed ovviamente c i sono molti t ipi di
pesatura. L‟ idea di Luhn (la frequenza con cui un termine compare in
un testo) può essere usata come pesatura del termine e c ome indice
della sua importanza, assegnando ad ogni termine un peso direttamente
proporzionale alla frequenza con cui compare nel testo. Se
consideriamo importante la specifici tà d i un termine, che è assunta
essere inversamente proporzionale al numero di documenti in cui i l
termine indice compare allora la pesatura maggiore sarà associata,
contrariamente al caso precedente, ai termini che compaiono in meno
documenti .
La differenza t ra i due metodi di pesatura è che uti l izzando la
frequenza dei termini si pone enfasi sulla descrizione dei contenuti
mentre la pesatura basata sulla specifici tà pone l ‟accento sull ‟abil i tà
dei termini di discriminare un documento dall ‟altro.
24
2.2 Sistemi di IR
2.2.1 Definizione del sistema
Un Sistema di IR è progettato per svolgere al meglio i l processo di
IR. Esso dovrà portare a termine al meglio tutt i i passi di questo
processo.
Inizialmente, prima che i l processo di reperimento abbia inizio, è
necessario disporre di una base di dati testuale. È quindi necessario
specificare i documenti da uti l izzare, le operazioni da effettuare sul
testo per rendere più veloce la ricerca dei documenti ed i l modello (ad
esempio un t ipo di s truttura particolare che ha i l testo e qua li sono gli
elementi che possono essere reperit i) .
Una volta che è stata definita la visione logica dei documenti , si
costruisce un indice del testo. Un indice è la struttura dati principale in
quanto esso permette una rapida ricerca all ' interno di grosse quanti tà di
dati . Le risorse, intermini di tempo e spazio di memorizzazione,
impiegate nella fase di indicizzazione sono giustificate dalle minor
risorse necessarie per le (notevolmente più numerose) operazioni di
interrogazione. [Dem04]
2.2.2 Componenti di un s istema di IR
Da un punto di vista formale, un sistema di Information Retr ieval è
rappresentabile da una “quadrupla” (D, Q, F, R) composta da
[BaeNet99] :
un insieme di rappresentazioni logiche dei documenti D;
un insieme di rappresentazioni logiche dei fabbisogni
informativi Q (le query);
i l modello di riferimento per la rappresentazione dei
documenti e delle richieste e delle relazioni tra loro, F ;
una funzione di “ranking” R(Q i , D j ) che associa un numero
reale non negativo ad una query e ad un documento,
ordinando i documenti recuperati per soddisfare la richiesta.
25
2.2.3 Processo di reperimento
Data una collezione indicizzata, i l processo di reperimento può
essere svolto nel modo seguente [BaeNet99]:
1. L'utente specifi ca i l suo bisogno informativo che viene
trasformato nello stesso modo in cui sono stati t rasformati i
documenti presenti nella collezione (vengono cioè estratte le
radici dei termini e inseri t i termini simili a quell i specificat i
dall 'utente);
2. L'interrogaz ione viene processata per ottenere quell i che
sono i documenti reperit i . Come visto, un reperimento dei
documenti rapido è possibile grazie alla precedente fase di
indicizzazione. Prima che i documenti vengano mostrat i
al l 'utente, essi vengono ordinati con frontando e st imando
quali documenti sono più pertinenti rispetto ad altri
assegnando ad ognuno un Retrieval Status Value (RSV) detto
anche score. Questi valori assegnati vengono poi trasformati
in un ordinamento (rank) che viene presentato all 'utente;
3. L'utente analizza l ' insieme dei documenti che sono stati
reperit i ed indica ad esso quali documenti sono, a suo
giudizio, pert inenti al l ' interrogazione (in questo modo
possono essere eseguite operazioni di relevance feedback per
riformulare l ' interrogazione a l fine di renderla più corretta).
2.3 Indicizzazione della collezione
2.3.1 Tecniche di indicizzazione
Le tecniche di indicizzazione studiate per le basi di dati
relazionali non sono adatte per i sistemi di Information Retrieval.
L‟indice più uti l izzato è l‟indice i nverti to:
vengono scansionat i i documenti e creato un elenco di
coppie (termine, Document ID);
l‟elenco viene ordinato per termine;
26
i termini che compaiono più volte nel lo stesso documento
collassano in un unico elemento, al quale viene aggiunta la
frequenza del termine;
i l risultato viene memorizzato in due fi le: i l fi le del
Dizionario e i l fi le dei Posting.
Tale tecnica è valida per query semplici (insiemi di termini);
modifiche sono necessarie se si vogliono gestire alt re t ipologie di query
(frasi , prossimità ecc.).
2.3.2 Semplif icazione di documenti testuali
Ai documenti vengono applicate diverse procedure per
semplificare i termini che contengono:
uno stream di testo viene t rasformato in un elenco di token
candidati a diventare entry dell‟indice;
vengono eliminate le “stopwords”, cioè i termini molto
frequenti nella l ingua in cui è scri t to i l testo che non sono
quindi significativi per capire l 'argomento trattato dal testo
(ad esempio gli art icoli e le congiunzioni);
vengono divise le parole contenenti un tratt ino (de-
hyphenation);
vengono eliminate le parole contenenti ci fre;
vengono gesti te le trasformazioni minuscole/maiuscole;
vengono estratte le radici mediante algoritmi di stemming
per non fare dis t inzioni tra singolari , plurali , verbi
coniugati ;
vengono gesti t i i s inonimi attraverso dei thesauri (in questo
punto è anche possibile valutare eventuali dizionari per la
traduzione di termini tra l ingue diverse;
se l inguisticamente possibile, una parola viene ridotta alla
sua radice grammaticale (lemmati zation).
Queste operazioni permettono di ottenere una visione logica dei
documenti originali , anche se in cert i casi può essere necessario gesti re
27
varie eccezioni. L‟uti l izzo di tal i tecniche comunque non sempre
migliora la quali tà delle risposte ad una query.
2.3.3 Algoritmi di stemming
Nel l inguaggio naturale le parole sono formulate con diverse
varianti morfologiche, sebbene si ri feriscano a un comune concetto (ad
esempio: comunicare, comunicati , comunicazione, comunicatore). Per
stemming s i intende i l raggruppare queste parole individuando la loro
radice morfologica (stem). Applicato ad un sistema di Information
Retrieval ( IR), i termini chiave della query o del documento sono
rappresentati dagli stem piuttosto che dal le parole originarie.
Util izzando lo stemming, un sistema di IR può:
permettere all‟utente di formulare query senza preoccuparsi
di specificare ogni variazione morfologica delle parole
cercate;
migliorare la precis ion e la recall , specialmente per query
corte;
ridurre la dimensione del dizionario di termini chiave.
I risultat i sull‟uti l i tà dello stemming sono stati abbondantemente
studiati per l‟inglese, con risultati controversi . Lingue più complesse
dal punto di vista morfologico (l ingue germaniche, romanze, finnico…)
richiedono approcci più sofi st icati , ma i benefici si rivelano più
significativi .
Esistono generatori che si appoggiano sulla conoscenza di una
particolare l ingua (che permettono maggiore efficacia ma scarsa
adattabil i tà), mentre i generatori “language - independent” ut i l izzano un
approccio statist ico per inferire le regole di formazione delle parole
(che sono quindi vantaggiosi per sistemi IR multi l ingua e non
necessitano di un esperto per ogni l ingua, e neppure di formalizzare le
regole) . [GavVal05]
2.3.4 Considerazioni sui moduli l inguistici
I moduli l inguistici sono dipendenti dal l inguaggio usato nel testo.
Si possono quindi verificare problemi nel caso in cui i l testo contenga
28
parole scri t te in diversi l inguaggi o in casi di l inguaggi che possono
creare problemi aggiunti (ad es empio, i l giapponese).
Questi moduli anno dei benefici in termini di precisione della
ricerca e dimensione dell ' indice, ma le t rasformazioni del tes to possono
rendere più diffici le la ricerca all 'utente.
Per questi motivi non tutt i sono concordi sull 'oppo rtunità di usarl i
(ad esempio, non sono uti l izzati da molt i Web Search Engine).
2.4 Modelli di IR
2.4.1 Modello booleano
La query consiste in una l ista di termini da confrontare con i
termini usati per la descrizione della collezione di documenti . Il
confronto è basato sulla logica booleana usando normalmente i t re
operatori AND, OR e NOT
Il confronto può essere migliorato trasformando i termini usati per
la descrizione dei documenti in altr i più precisi con tecniche di
stemming o con uso di thesaurus.
Il modello booleano permette quindi di associare alla coppia
termine- documento solo i valori 1 e 0 .
I problemi del modello booleano sono causati da:
peso dei termini (con una pura espressione booleana la
valutazione è solo sulla presenza/assenza del termine);
ordine di precedenza dei termini;
interpretazione scorretta degli operatori .
2.4.2 Modello fuzzy
La logica fuzzy permette di associare ad ogni coppia termine -
documento un pero compreso t ra 0 e 1. Questa logica è uti le nella
soluzione di problemi complessi che non sono formalizzabil i in un
algoritmo deterministico. Possono essere invece descrit t i
quali tat ivamente attraverso espressioni l inguistiche
Un insieme fuzzy è caratterizzato da una funzione di correlazione
che consente di esprimere i l grado di rappresentabil i tà d i un termine T
rispetto al contenuto di un documento D.
29
2.4.3 Modello probabilist ico
L‟identificazione dei concett i si basa sul la teoria
dell‟informazione di Shannon. Il ranking dei documenti è basato su
modelli probabil ist ici (stat ist ica soggett iva basata su mo dell i
bayesiani). Questo modello è uti le per le ricerche su contesti non
conosciuti .
Secondo Shannon, i l contenuto informativo di un “messaggio” è
rappresentato dalla sua probabil i tà di presentarsi in un insieme di
messaggi possibil i : maggiore è la probabi l i tà di realizzarsi , minore è i l
contenuto informativo. È abbastanza intuit ivo che sarà i l messaggio
meno probabile a portare la massima quanti tà di informazione quando si
presenta.
In termini semplici , i l teorema di Bayes parte dalla considerazione
che non tutt i gli eventi siano direttamente osservabil i .
Se non possiamo osservare l ‟evento A la probabil i tà “a priori” di A
sarà P(A) . Però se un evento A è in qualche modo connesso ad un
evento B che possiamo osservare, la probabil i tà a posteriori di A sarà
P(A/B) . Il teorema di Bayes stabil isce come calcolare la probabil i tà “a
posteriori” di A a partire dalla probabil i tà, nota, di B.
In termini di Information Retrieval, identificato un set di
documenti che si sa essere rispondenti al la query (evento B), è
possibile calcolare per gli al tri documenti la probabil i tà che hanno di
essere ri levanti .
2.4.4 Modello vettoriale
Nel modello spazio vettoriale sia la query che i l documento sono
rappresentati come vettori in uno spazio n -dimensionale:
D i = (d i 1 , d i 2 , …, d in)
Qj = (q j 1 , q j 2 , …, q j n)
dove d i k e q j k rappresentano i valori del termine k nel documento
D i e nella query Q j .
30
I valori di un termine possono essere semplicemente 0 o 1 per
indicare la sua presenza/assenza nel documento/query oppure possono
rappresentare i l peso del termine nel documento o la query.
2.4.5 Modello cluster
Un cluster è un gruppo omogeneo di documenti che sono tra loro
più fortemente associati di quanto lo siano con documenti in altri
gruppi.
Il clustering consente di raggruppare automaticamente un insieme
di documenti (ad esempio i l risultato di una ricerca). In questo senso i l
clustering è una forma di “unsupervised classi fication”, cioè uno
strumento di aggregazione dei documenti quando non si abbiano classi
predefinite.
L‟ algoritmo più semplice di clustering (a singolo l ivello senza
overlap) fa uso di:
una misura di similari tà;
un valore di soglia che definisce l‟appartenenza al cluster;
“centroidi” o “medoidi”, documenti più rappresentativi per
ciascun cluster.
La ricerca avviene in due fasi:
1. si confronta la query solo con i centroidi dei cluster;
2. si confronta la query con i documenti dei cluster selezionati .
2.5 Valutazione dei sistemi di IR
2.5.1 Valutazione di ri levanza
Per l ‟utente i l documento ri levante per una query può essere i l
documento che [Olo]:
risponde precisamente alle esigenze dell ‟utente ;
risponde parzialmente alle esigenze dell ‟utente ;
suggerisce una fonte di informazioni ;
fornisce informazion i contestuali sull‟argomento di
interesse;
richiama alla memoria dell ‟utente altre conoscenze .
I fat tori che influenzano la valutazione di ri levanza sono [Sar75] :
31
Utente: i l contesto dell‟ interrogazione e i l imiti posti
al l ‟ interrogazione;
Interrogazione: s t ruttura e classificazione delle
interrogazioni ;
Chi effettua la ricerca: esperienza e percorsi cognitivi di chi
effettua la ricerca ;
Ricerca: modali tà di formulazione della ricerca ;
Documenti recuperat i .
2.5.2 Criteri di valutazione
I cri teri di valutazione di un sistema di IR possono essere così
definit i [CMK96]:
1. la copertura della base documentale ( la misura con cui i l
sistema definisce gli indici di ri levanza);
2. i l tempo di risposta (l‟intervallo tra l‟invio della richiesta
e l‟ottenimento del r isultato);
3. i l modo di presentazione del risultato;
4. lo sforzo che l‟utente deve compiere per ottenere le sue
risposte;
5. la percentuale di materiale ri levante che è stato
recuperato;
6. la percentuale di material e recuperato che è
effett ivamente ri levante.
In alt ri termini:
1. precisione e recall ;
2. contesti di applicabi l i tà;
3. facil i tà di ricerca da parte dell‟utente;
4. facil i tà di analisi dei risultat i ;
5. semplicità di implementazione.
È importante considerare che oltre alle metriche tradizionali di
performance dei sistemi di Data Retrieval, occorre considerare la
“soddisfazione” degli utenti (possono essere presi in considerazione
32
svariati fat tori nel misurare la soddisfazione di un utente, dipendenti
dal t ipo di utente e di applicazione).
Sono state anche sviluppate collezioni di documenti di test per
poter fornire un confronto reale t ra sistemi diversi (ad esempio, la
collezione TREC).
2.5.3 Misure di ef f icacia e parametri di valutazione
Possiamo dividere i documenti in quattro categorie:
documenti ri levanti ri tornati (veri posit ivi);
documenti ri levanti non ri tornati (falsi negativi);
documenti non ri levanti ri tornati (falsi posit ivi);
documento non ri levanti non ri tornati (veri negativi).
Le misure di efficacia uti l izzata per la valutazione dei sis temi di
IR sono quatt ro:
Recall : percentuale di documenti ri levanti recuperati sul
totale dei documenti ri levanti presenti nell‟ insieme;
Precisione: percentuale di documenti ri levanti sul totale dei
documenti recuperat i ;
Silenzio: percentuale di documenti ri levanti non recuperati
sul totale dei documenti ri levanti presenti nell‟ insieme ;
Rumore: percentuale di documenti non ri levanti sul totale
dei documenti recuperati .
33
Le misure effett ivamente ri levanti sono Recall e Precisione, visto
che Silenzio e Rumore possono essere calcolate da queste due.
2.5.4 Precision e recall
Questi due parametri vanno quindi considerati contestualmente, e
possiamo quindi dividere valutare un sistema in quatt ro categori e:
bassa precisione, basso recall (abbiamo pochi documenti
ri levanti in mezzo a tanti documenti non ri levanti);
bassa precisione, al to recall (abbiamo quasi tutt i i documenti
ri levanti , che però sono “mischiati” a tanti documenti non
ri levanti);
alta precisione, basso recall (quasi tutt i i documenti
resti tuit i sono ri levanti , anche se sono una piccola
percentuale tra tutt i i documenti ri levant i) ;
alta precisione, al to recall (l ‟insieme dei documenti ri levanti
è molto simile a quello dei documenti resti tuit i , i l caso
ovviamente migliore).
Considerando uno solo dei valori , la valutazione non sarebbe
esaustiva:
se considerassimo solo la misura Recall , un motore che
ri torna tutt i i documenti della collection sarebbe considerato
perfetto (Recall = 1);
se considerassimo solo la misura Precision, un motore che
ri torna solo un documento (che sicuramente viene
considerato ri levante) sarebbe considerato perfetto
(Precision = 1).
Può essere anche introdotta una misura combinata, che chiamiamo
F , che bilancia l ‟importanza di Precision e Recall :
La definizione delle costanti dipende dal bilanciamento che
l‟utente da ai valori di Precision e di Recall : soli tamente viene
34
ut i l izzato i l parametro oppure che considera l‟esatto
bilanciamento tra i due valori .
L'uti l izzo di Precision e Recall per la valutazione di un sistema di
IR può comportare inoltre diversi problemi:
la dist inzione verit iera tra documento ri levante e non
ri levante , che dovrebbe essere e ffet tuato tra utenti
considerati “esperti” ;
la divisione tra documento ri levante e non ri levante non
può essere sempre netta , ma ci potrebbero essere casi in
cui possano essere uti l izzati pesi compresi tra 0 e 1 (come
avviene nella logica fuzzy) ;
la misura è influenzata dal dominio di applicazione
(collezione e query) : uno stesso sistema può avere ott ime
prestazioni in un determinato dominio ma non in un altro .
2.6 Web information retrieval
2.6.1 I dati sul web
Il Web può essere visto come una col lezione non struttur ata di
informazioni, dist ribuita e di dimensioni imponenti . C‟è da considerare
inoltre che esistono sul web documenti di t ipi diversi (test i , immagini,
suoni, video, etc. ). Il reperimento di informazioni sul web può avvenire
in tre modi diversi:
ricerca di retta via URL;
ricerca mediante navigazione (browsing e uti l izzo di l ink tra
pagine);
util izzo di servizi per la ricerca quali motori di ricerca e/o
directory.
Ovviamente l‟ IR entra in gioco nella struttura dei motori di
ricerca.
2.6.2 Evoluzione dei web search engine
Si possono individuare tre generazioni di motori di ricerca sul
web:
35
prima generazione, che uti l izzano solo dati testuali e
algoritmi di calcolo della frequenza di parole;
seconda generazione, che uti l izzano i dati specifici del web
(quali analisi dei l ink e dei test i associati , memorizzazione
dei cl ick effettuati dagli utenti nei risultat i delle ricerche);
terza generazione (in fase sperimentale) , che è incentrata sui
reali bisogni dell‟utente e non sulle singole query (analisi
semantiche, analisi del testo, determinazione del contesto,
interazione con l ‟utente).
2.6.3 Web search engine – Indicizzazione e risultato
Un motore di ricerca sul web è del tutto simile ad un sistema di IR:
possiamo considerare una pagina web come un documento in un sistema
di IR, anche se possono differire in st rut tura.
Attenzione particolare va però portata verso due aspett i : la
creazione della collezione e l ‟interazione con l ‟utente.
In fase di indicizzazione vanno considerati i seguenti aspett i :
scalabil i tà, data la mole dei dati ;
affidabil i tà, data la distribuzione dei dat i tra server diversi;
volati l i tà, dato l‟aggiornamento continuo di contenuti e di
URL;
ridondanza, data la replicazione delle informazioni;
quali tà, data la possibil i tà di presenza di errori o di
informazioni obsolete;
eterogeneità, data dalla struttura e dei t ipi di dati diversi (a
l ivello di t ipi di fi le ma anche di l ingue, al fabeti ,
strutture…) ;
recupero, date le modali tà di inserimento nella collezione
(segnalazione diretta dei proprietari dei documenti o agente
software – crawler – che attraversa i l web per indicizzare
nuovi documenti).
A l ivello di interazione vanno ben definit i due aspett i :
specifica delle richieste da parte dell‟utente;
36
presentazione dei risultat i .
2.7 Collaborative filtering
2.7.1 L’aspetto umano
Il collaborative fi l tering adotta un approccio complementare che
t iene maggiormente conto delle implicazioni sociali del procedimento
di raccomandazione. Invece di raccomandare elementi simili a quell i
che l‟utente ha dimostrato di gradire in passato, es so raccomanda
elementi che altri utenti simili hanno dimostrato di gradire. Ad un
l ivello umano, questa tecnica è uti l izzata ogni volta che qualcuno basa
le proprie azioni (ad esempio, andare o meno a vedere un fi lm) sui
consigli ricevuti dal le persone che egli sa soli tamente essere d‟accordo
con lui (t ipicamente gli amici) [GNO92].
2.7.2 Sistemi automatici
I computer permettono di automatizzare questo processo e di
applicarlo ad un più grande numero di utenti . In generale, non è
necessario specificare quali sono le persone con gusti simili perché esse
vengono individuate dal sistema in maniera automatica .
Il collaborative fi l tering lavora in parte associando ai documenti
del computer la storia del loro uti l izzo. Ad esempio gli oggett i che noi
usiamo nella vita di tutt i i giorni si logorano, le pagine di un l ibro si
stropicciano, la ri legatura si sgualcisce, i bordi delle pagine si
macchiano con le impronte delle dita. Gli oggett i più consumati sono
quell i più uti l izzati ed inoltre i l logorio rappresenta un indice per
l‟informazione relativa contenuta nel l‟oggetto [HSR95].
Il collaborative fi l tering riesce a superare alcune delle l imi tazioni
dell‟approccio content based. Non è necessario che gli oggett i da
fi l trare siano analizzabil i in maniera automatica da un computer oppure
che esseri umani provvedano ad estrarne le caratterist iche descrit t ive.
Inoltre i l sistema può raccomandare a l l‟utente oggett i che sono
molto differenti dal punto di vista del contenuto da quell i che esso ha
gradito precedentemente a ragion del fatto che si basa sul le opinioni
37
degli al t ri utenti . Infine le raccomandazioni sono basate sulla quali tà
degli oggett i p iuttosto che su proprietà più oggett ive degli stessi .
2.7.3 Problematiche
Tuttavia i l collaborative fi l tering presenta anche qualche
problema:
gli oggett i appena inseri t i nel sistema non hanno ancora
ricevuto voti e quindi le previsioni relat ivamente ad essi non
sono possibil i . In seguito le predizioni saranno influenzate
esclusivamente dai pochi utenti che le hanno valutate per
primi;
in maniera simile un utente che entra nel sistema non avendo
ancora espresso voti non può essere confrontato con gli al t ri
sulla base delle sue opinioni e quindi non è possibile fargli
raccomandazioni;
l‟utente comunque per essere comparato con gli al tri e
ricevere i suggerimenti deve fare lo sforzo di esprimere la
sua opinione sul maggior numero possibile di oggett i e
questo richiede uno sforzo da parte dell‟utente;
in molti domini i l numero degli oggett i eccede di molto i l
numero che ogni individuo può assorbire e valutare e quindi
i l grado di sovrapposizione tra due utent i è molto basso;
se i l numero di utenti non è eccessivamente elevato ci
possono essere individui con gusti inusuali che non
beneficiano del sis tema in quanto le loro opinioni non
concordano né discordano in maniera decisa con alcuno degl i
al tri .
2.7.4 Tipologie
Il collaborative fi l tering può essere diviso in due t ipologi e:
passivo e att ivo. Al momento abbiamo considerato l‟esistenza di un
unico database in cui vengono memorizzati i voti espressi dagli utenti
relativamente agli oggett i e le raccomandazioni sono basate sulle
opinioni di persone simili per gusti : questo vien e detto in-place Col
38
laborative Fil tering o passive collaborative f i l tering , perché non c‟è
diretta connessione né conoscenza tra la persona che decide un voto e
gli utenti che giungono in seguito e r icevono raccomandazioni sulla
base di questi voti aggregati .
Un altro approccio al collaborative fi l tering si fonda sulla pratica
comune per cui le persone riferiscono ai loro amici o colleghi di
interessanti documenti . Tale approccio viene denominato active Col
laborative Fil tering perché c‟è l ‟intento da parte della persona che
cerca e valuta un oggetto di condividerne la sua conoscenza con
particolari persone
Le due tecniche hanno due fi losofie di base opposte ( in una
l‟utente t ira verso sé stesso l‟informazione, mentre nell‟alt ra la
comunità spinge l ‟informazione verso l‟utente [CHI97]. Nel passive
collaborative fi l tering i l sistema lavora meglio se la convergenza di
voti sullo stesso insieme di documenti è più alta; al contrario, i l
beneficio dell‟active collaborative fi l tering aumenta con la divergenza
dei documenti trovat i .
2.7.5 Algoritmi di predizione
Possono essere identificate due maggiori classi di algori tmi di
predizione basati sulla memoria (memory-based ) e basati sul modello
(model-based) [BHK98] .
Gli algoritmi memory-based mantengono un database di tutte le
preferenze espresse dagli utenti per gli oggett i e , per ogni predizione ,
eseguono una qualche computazione su tutto i l database .
D‟alt ro canto, quell i model-based prima compilano le preferenze
degli utenti in un modello descrit t ivo di utenti (oggett i e voti ): le
raccomandazioni sono poi basate esclusivamente sul modello .
I metodi basati sulla memoria rimandano ogni computazione al
momento della previsione : sono quindi più semplici ed intuit ivi in
genere e sembrano funzionare piuttosto bene in pratica . I nuovi dati
possono essere aggiunti incrementalmente e facilmente : questo
approccio può però diventare computazionalmente costoso in termini
39
s ia di spazio occupato che di tempo impiegato per ogni predizione a
mano a mano che i l database cresce (è quindi diffici lmente scalabile) ed
in più non si riescono a recuperare informazioni aggiuntive.
Nei sistemi basati sul modello , i l modello stesso può offri re
un‟ informazione che va al di l à delle sue capacit à predit t ive (ad
esempio evidenziando certe correlazioni dei dati offrendo motivazioni
intuit ive delle raccomandazioni o semplicemente rendendo le
assunzioni più esplicite) . I requisit i di memoria per i l modello sono
generalmente minori di quell i necessari per trat tenere l ‟ intero database:
le predizioni possono essere calcolate velocemente una volta che i l
modello è stato generato anche se i requisit i di tempo per compilare i
dati in un modello possono essere proibi t ivi e aggiungere un nuovo voto
potrebbe richiedere una ricompilazione completa .
2.7.6 Raccolta delle pre ferenze
I sistemi di collaborative fi l tering si possono differenziare a
seconda che essi operino su preferenze esplicite piuttosto che su misure
implicite estratte dall ‟att ività dell‟utente. I primi si riferiscono alla
si tuazione per cui un utente esprime in maniera cosciente la sua
preferenza per un oggetto (soli tamente su una scala numerica discreta)
[HSR95] .
I voti implicit i invece possono essere estratt i dall ‟att ività di
browsing: ad esempio, nel caso di sistemi che raccomandano sit i web ,
tal i informazioni possono essere raccolte in seguito ad azioni
dell‟utente come:
inseri re una pagina nei bookmarks;
i l tempo di let tura presunta (per quanto riguarda art icoli on -
line);
dalla storia degli acquisti (ad esempio nei punti vendita on-
line);
l ink presenti in alt re pagine.
40
41
3 META MOTORI DI RICERCA E SISTEMI DI
VOTO
«I progressi fondamentali hanno a che fare
con la reinterpretazione delle idee di base.»
Alfred North Whitehead
3.1 I meta motori di ricerca
3.1.1 I meta motori di ricerca
Un meta motore di ricerca può essere visto come un ‟unica
interfaccia di un sis tema modulare che può eseguire query in parallelo
su più servizi di ricerca contemporaneamente , fornendo risultati con un
l ivello di quali tà maggiore rispetto a quell i ottenuti con un singolo
motore. Per raggiungere questo scopo è necessario in generale seguire
un algoritmo che può essere così semplif icato [SelEtz96] :
Inserimento della
query di ricerca
Formulazione delle query per i
singoli motori
Esecuzione delle query sui
singoli motori (e attesa dei
risultati)
Raggruppamento dei risultati
Eliminazione dei duplicati
Restituzione dei risultati
Figura 3 .1 Algori t mo sempl i f icato d i un meta motore di r icerca
42
Analizzeremo solo i due aspett i che più ci interessano: la
formulazione delle query per i singoli motori e i l raggruppamento dei
risultat i .
3.1.2 Formulazione delle query per i singoli motori
I motori di ricerca forniscono soli tamente un‟interfaccia di
interrogazione per parole chiave o maschere per la ricerca avanzata. In
questo caso noi dobbiamo fornire al singolo motore di ricerca una query
specifica, opportunamente configurata. Fondamentalmente questo
processo prevede un‟eventuale sviluppo di adapter per la conversione di
query t ra standard non compatibil i (ad esempio, l ‟uti l izzo o meno di
operatori logici AND, OR, NEAR) o t ra metodi di interazione diversi .
Nel nostro caso specifico, questa conversione non è necessaria perché
uti l izziamo un solo motore di ricerca, ma è da analizzare nel caso di
integrazione con sistemi di IR diversi tra loro) .
3.1.3 Raggruppamento dei risultati
Il problema del raggruppamento dei risultat i è i l più complesso da
affrontare, dato che non si può formulare una st rategia generale a causa
di questi fat tori che possono caratterizzare un meta motore:
util izzo di un coeff iciente di ri levanza dei singoli risultat i
(relevance scores) o di una mera classi fica (ranks);
auto-apprendimento ( training data ) o meno del meta motore
attraverso meccanismi statist ici e probabil ist ici (ad esempio,
l‟util izzo dei teoremi di Bayes ai fi l t ri relativi al la posta
indesiderata).
Il primo fattore dipende dalla scelta dei singoli motori di r icerca:
se anche uno solo resti tuisce i risultat i sotto forma di classi f ica, siamo
obbligati a seguire questa strada. Il secondo invece dipende dalla
complessità dell ‟algoritmo di aggregazione uti l izzato. [AslMon01]
Ci possiamo quindi trovare di fronte a quattro possibil i strade da
seguire: in questa trattazione, per rimanere in am bito generale,
considereremo la strada dei risultat i sot to forma di classifica e i l non
uti l izzo di meccanismi di auto -apprendimento.
43
3.2 Sistemi di voto
3.2.1 Le procedure di voto e i meta motori di r icerca
In generale, un sis tema di voto permette agli elettori di poter
scegliere tra più opzioni. Ogni sistema deve contenere regole per
definire la validità dei voti e come essi devono essere aggregati per
ottenere un risultato finale. Gli studi compiuti in tal senso hanno dato
vita nel diciottesimo secolo alla "Teoria del Voto", una branca
scienti fica che ha le sue radici nella poli t ica, dall ‟economia e dalla
matematica.
Un sistema di voto può essere considerato un algoritmo di
aggregazione nel momento in cui consideriamo di dover combinare le
preferenze multiple degli elettori . Queste procedure non sono
direttamente applicabil i ai meta motori in quando assumono la presenza
di pochi candidat i rispetto al numero di votanti : analizzando
l‟aggregazione dei r isultat i delle ricerche invece ci troviamo di fronte
allo scenario opposto in quanto abbiamo tanti candidati (i risultat i delle
ricerche) di fronte a pochi elettori (i s ingoli motori che resti tuiscono
una classi fica di preferenza). [AslMon01]
È stato dimostrato che l ‟algoritmo ott imale in questo secondo caso
è i l metodo Borda Count in quanto soddisfa tutte le proprietà
simmetriche che ci si aspetta da un ragionevole sistema elettorale
[Saa98] [Saa01].
3.2.2 Il metodo Borda Count
Il metodo Borda Count è stato formal izzato da Jean-Charles de
Borda nel 1770 riprendendo i l metodo di voto uti l izzato nel Senato
Romano. Il suo funzionamento è i l seguente [Bor81]:
ogni elettore classif ica un insieme fissato di n candidati in
ordine di preferenza;
per ogni votante, al primo candidato della l ista vengono
assegnati n punti , al secondo n-1 , al terzo n-2 e così via;
44
se ci sono candidati che non sono stati inseri t i nella
classi fica, essi si dividono equamente i punti non assegnati
dal singolo elettore;
i l candidato al quale viene assegnato i l maggior punteggio
vince le elezioni (con lo stesso cri terio è possibile quindi
determinare una classifica finale).
Si può quindi t rovare l ‟analogia con i meta motori di ricerca:
l‟insieme dei risultat i sono i “candidati”;
i singoli motori di r icerca sono gli “elet tori” che esprimono
una classi fica di preferenza.
Grazie a questo possiamo uti l izzare i l metodo Borda Count per
aggregare i risultat i dei vari motori di r icerca (sempre considerando i l
caso la dei risultat i sotto forma di classifica e i l non uti l izzo di
meccanismi di auto-apprendimento).
A l ivello di performance, è stato sperimentato che le prestazioni di
questo metodo inoltre sono abbastanza buone. [AslMon01]
3.2.3 Esempio di applicazione del metodo Borda Count
Supponiamo che l ‟Assemblea debba eleggere un Consigli o. I
candidati sono 20, mentre i posti disponibil i sono 9. Ogni elettore può
indicare 5 nominativi in ordine di preferenza.
Allo spoglio delle schede, verranno assegnati i seguenti punti (per
ogni scheda):
cinque punti al primo della l ista;
quattro punti al secondo;
tre punti al terzo;
due punti al quarto;
un punto al quinto.
Alla fine dello scrut inio, verranno sommati i vari punteggi ot tenuti
ad ogni candidato e i primi 9 risulteranno elett i .
45
4 COLLEGAMENTO DI DOCUMENTI CON LA
TECNICA DEI META MOTORI DI RICERCA
«L’arte o è plagio o è rivoluzione.»
Paul Gauguin
4.1 Proposta di soluzione
4.1.1 Utilizzo delle meta informazioni come punto di partenza
Nel mondo dei sistemi di gestione documentale i l problema del
collegamento tra documenti di t ipo strutturato e documenti di t ipo no n
strutturato è reale e di non facile soluzione, e la strutturazione di
documenti non strutturati è un procedimento molto complesso.
Possiamo però ribal tare i l problema: a parti re da ogni documento
strutturato generiamo una o più query di ricerca, che diam o in pasto a
motori di ricerca diversi . Per fare questo, definiremo delle query
(attraverso template) per ogni classe di documento (possiamo anche
definire su quali singoli motori debbano essere eseguite queste query).
Possiamo inolt re associare a questi query template dei coefficienti di
ri levanza (una query può essere più ri levante di un‟alt ra), così come
possiamo definire questi coefficienti per i singoli motori (un motore
può essere più affidabile di un alt ro).
Quindi a part ire da un documento non strut turato possiamo
ottenere dei “documenti non strutturati” (le istanze delle query al
singolo documento) da dare in pasto ad un motore di ricerca.
Eseguendo i processo di reperimento a partire da queste query
possiamo associare dei documenti non strutturati ai nostri documenti
strutturati (basta al largare i l concetto di meta motore, considerando
ogni query diversa come un motore di ricerca diversa).
4.1.2 Specif ica
In questo progetto di tesi si vuole affrontare questa tematica
uti l izzando uno o più motore di ricerca (nel caso, un Google Mini) che
46
agiscono sui contenuti non strutturati presenti nella knowledge base di
un‟azienda in cui sia presente un sis tema documentale di records
management (nel caso, KarthaDOC).
Verrà quindi proposto un algoritmo generale per la soluzione di
questo problema e verranno nella fatt ispecie analizzati due blocchi
fondamentali :
i l sistema per la generazione di st ringhe di ricerca (a partire
dalle meta-informazioni associate ad un documento
strutturato presente nel DMS) ;
l‟ interpretazione dei risultat i ottenuti al fine di individuare i
possibil i collegamenti tra le due t ipologie di documento.
4.1.3 Entità di ri ferimento
4.1.3.1 Classi di documento
DocumentClass = ( DC_Identifier , DC_Name)
DC_Identifier: Ident ificativo della classe di documento
DC_Name: Nome della classe di documento
4.1.3.2 Meta informazioni relative alla classe di documento
DocumentClassMeta = ( DCM_Identifier , DC_Identif ier , DC_Name,
DC_Type )
DCM_Identifier: Identificativo della definizione di meta
informazione
DC_Identifier: Ident ificativo d ella classe di documento
DC_Name: Nome della meta informazione
DC_Type: Tipo di dato del valore
4.1.3.3 Documento
Document = ( D_Identifier , DC_Identif ier , D_Description)
D_Identifier: Identif icativo del documento
DC_Identifier: Identificativo della classe di docu mento di
riferimento
D_Description: Descrizione del documento
47
4.1.3.4 Meta informazioni associate al documento
DocumentMeta = ( DM_Identifier , D_Identif ier , DCM_Identif ier ,
DM_Value )
DM_Identifier: Identificativo della meta informazione
D_Identifier: Identif icativo del documento di ri ferimento
DCM_Identifier: Identificativo della definizione di meta
informazione di ri ferimento
DM_Value: Valore della meta informazione
4.1.3.5 Stringhe di ricerca
Query = ( Q_Identi f ier , DC_Identif ier , Q_Pattern, Q_RateMoltiplicator
)
Q_Identifier: Identif icativo della query
DC_Identifier : Identificativo della DocumentClass a cui la
query fa ri ferimento
Q_Pattern: Pattern testuale della query s tring
Q_RateMoltiplicator: fat tore di moltipl icazione che indica
l‟affidabil i tà della query (una query restri t t iva avrà valori
tendenti a 1, query meno rest ri t t ive valori più bassi)
4.1.3.6 Motori di ricerca uti l izzati
SearchEngine = ( SE_Identifier , SE_Name, SE_RateTrust )
SE_Identifier: Identi ficativo del motore di ricerca
SE_Name: Nome del motore di ricerc a
SE_RateTrust: fat tore di moltiplicazione che indica
l‟affidabil i tà del motore di ricerca (ad esempio, un fattore 1
indica che mi fido del Rate resti tuito, valori minori indicano
un‟affidabil i tà minori).
4.1.3.7 Associazione di query ai motori di ricerca
SEQuery = ( SE_Identi f ier , Q_Identif ier )
48
4.1.3.8 Is tanza della query per i l documento specificato
QueryIstance = ( Q_Identif ier , D_Identif ier , QI_Text )
Q_Identifier: Identif icativo della query di riferimento
D_Identifier: Identif icativo del documento a cui la query fa
riferimento
QI_Text: Testo del la query di ricerca per i l documento
specificato
4.1.3.9 Risultati di una ricerca (ottenuti dal singolo motore di ricerca
per una singola query)
SEResult = ( SER_Identifier , SE_Identi f ier, Q_Identi f ier , D_Identif ier ,
SER_Path, SER_Title, SER_Posit ion, SER_Rate )
SER_Identi fier: Identificativo dell risultato
SE_Identifier: Ident ificativo del motore di ricerca a cui i l
risultato fa ri ferimento
Q_Identifier: Identif icativo della query a cui i l risultato fa
riferimento
D_Identifier: Identi f icativo del documento a cui i l risultato
fa riferimento
SER_Path: Path del documento non strutturato ottenuta dal
motore di ricerca
SER_Title: Titolo ot tenuto dal motore di ricerca
SER_Posit ion: Posizione del risultato nel la SERP
SER_Rate: Punteggio calcolato col metodo Borda Count
SEResultList = array of SEResult
4.1.3.10 Risultato finale di una ricerca (ottenuta dall ‟unione dei vari
risultat i )
CollateResult = (CR_Path, D_Identif ier , CR_Title, CR_Rate )
CR_Path: Path del documento non strutturato
D_Identifier: Identi f icativo del documento a cui i l risultato
fa riferimento
CR_Title: Titolo associato
49
CR_Rate: Punteggio finale
CollateResultList = array of CollateResult
4.1.4 Diagramma ER
Document
PK D_Identifier
FK1 DC_Identifier
D_Description
DocumentMeta
PK DM_Identifier
FK1 D_Identifier
FK2 DCM_Identifier
DM_Value
Query
PK Q_Identifier
FK1 DC_Identifier
Q_Pattern
Q_RateMoltiplicator
SearchEngine
PK SE_Identifier
SE_Name
SE_RateTrust
SEQuery
PK,FK1 Q_Identifier
PK,FK2 SE_Identifier
SEResult
PK SER_Identifier
FK1 Q_Identifier
FK1 SE_Identifier
FK2 D_Identifier
SER_Path
SER_Title
SER_Position
SER_Rate
CollateResult
PK CR_Path
PK,FK1 D_Identifier
CR_Title
CR_Rate
QueryIstance
PK,FK2 Q_Identifier
PK,FK1 D_Identifier
QI_Text
DocumentClass
PK DC_Identifier
DC_NameDocumentClassMeta
PK DCM_Identifier
FK1 DC_Identifier
DC_Name
DC_Type
Gestione Documentale
Conf. Motori di ricerca
Calcolo dei risultati
F igura 4 .1 Diagra mma ER
4.1.5 Algoritmo generale
INPUT: D_Identi f ier
OUTPUT: CollateResult*
Per ogni Query associata alla DocumentClass
50
o Creo i l documento QueryIstance con i valori presenti
nei DocumentMeta relativi al Document preso in
considerazione.
Per ogni SearchEngine collegato al la Query presa in
considerazione
o Eseguo la Query
o Ottengo una SEResultList
o Per ogni SEResult
Se non è già presente in CollateResult List ,
inserisco i l risultato in CollateResult List con
CR_Rate = 0 (Discriminante: SER_Path =
CR_Path)
Per ogni SEResult presente in ogni SEResultList
o Calcolo i l Punteggio col metodo Borda Count
o Calcolo i l SER_Rate in base all ‟affidabil i tà della
Query e del SearchEngine: SER_Rate = Punteggio *
Q_RateMoltiplication * SE_RateTrust
o Aggiorno la CollateResult aggiungendo, ove SER_Path
= CR_Path , i l relativo punteggio ottenuto: CR_Rate =
CR_Rate + SER_Rate
Ordino la CollateResultList in base al valore CR_Rate
decrescente
4.2 Macroanalisi dei blocchi principali
4.2.1 Configurazione delle QueryString
In fase di configurazione delle DocumentClass devono essere
definit i i template per una o più stringhe di ricerca, che a loro volta
possono essere singolarmente eseguite su uno o più motori di ricerca.
Questi template verranno istanziati a part ire dai meta -dati associati ad
un singolo documento strutturato.
Pertanto è possibile definire stringhe diverse per ogni singolo
motore di ricerca, oppure una stessa str inga può essere eseguita su più
motori . Questo può essere uti le per diversi motivi:
51
motori di ricerca diversi possono avere diverse regole di
sintassi;
posso definire più st ringhe per trovare ri ferimenti al lo stesso
oggetto (ad esempio, uti l izzando dei sinonimi o diverse
combinazioni di meta-dati e/o testo l ibero);
Esempio di questa metodologia la t rovi amo nella tecnologia
relativa agli Adapters di Documentum, in cui però assist iamo anche alla
conversione automatica di stringhe di ricerca in base alla sintassi
accettata dai singoli motori di ricerca.
Nella nostra realtà questa funzionali tà risulta superf lua in quanto
l‟util izzo di diversi motori di ricerca è concetto che rimane a l ivello
teorico/sperimentale, in quando nella maggioranza dei casi reali di
uti l izzo verrà uti l izzato i l Google Mini (o un alt ro sistema sviluppato
da KarthaDOC, denominato INDEXER).
4.2.1.1 Configurazione della query
La query può essere configurata in divers i metodi:
Metodo 1: Definizione diretta del pattern nella forma:
testo libero $metatag1$ testo testo $metatag2 ;
Metodo 2: Definizione tramite XML nella forma
<query>
<pattern>
testo libero <metatag name=”metatag1” />
testo testo <metatag name=”metatag2” />
</pattern>
<search_engine name=”gsa” />
<search_engine name=”yahoo” />
</query>
4.2.1.2 Generazione delle QueryString
A parti re da ogni singolo documento, i l sistema provvede a
generare le query sosti tuendo i marker presenti nei template con i valori
contenuti nei metadati associati al documento.
52
4.2.2 Esecuzione delle QueryString e prima elaborazione dei
risultati
Le query precedentemente generate vengono eseguite sui motori di
ricerca definit i : avremo quindi come risultato un insieme di
SEResultList (una per ogni query eseguita su ogni singolo motore di
ricerca).
In questa fase viene eseguito un primo adattamento del rating di
ogni singolo risultato, uti l izzando i fat tori di moltiplicazione pre -
impostati :
SER_Rate = Punteggio * Q_RateMoltiplication *
SE_RateTrust
4.2.3 Post-Filtering: Merge dei risultati e gestione dei duplicati
I risultat i ottenuti andranno inseri t i nella CollateResultList . Punto
cri t ico di questa fase è generalmente la gestione dei ri sultat i duplicati
(cioè, un path è presente in più SEResultList ).
Grazie al metodo Borda Count , prima di elaborare ogni singola
l ista (virtualmente una l ista di “preferenze”) aspetteremo di poterle
avere tutte per poter quindi creare questo elenco virtuale di “candidati”
per poter applicare così i l metodo senza ulteriori complicazioni.
4.3 Aspetti implementativi
4.3.1 Inizializzazione dei collegamenti
Ad ogni i terazione del ciclo di ricerca di collegamenti , i
collegamenti precedentemente trovati possono essere rimoss i in modo
tale da avere sempre un elenco di risultat i aggiornati .
Solo quando vi sono informazioni immesse dall ‟utente relative al
collegamento stesso, tal i informazioni devono rimanere ed essere prese
in considerazione, in base ai casi .
4.3.2 Esecuzione della procedura
La procedura di ricerca automatica dei collegamenti può essere
eseguita:
53
ad ogni apertura di documento (rallenta i l sistema ma è
quella che recepisce meglio i l cambiamento della base
documentale) ;
on-demand (viene richiesto manualmente dall ‟utente
l‟aggiornamento globale dei collegamento oppure di una
sezione di documenti oppure di un singolo documento) ;
come servizio schedulato (viene programmato
l‟aggiornamento globale ad intervall i predefinit i , ad esempio
ogni notte) .
4.3.3 Grado di aff idabil i tà delle query e dei motori di ricerca
Un punto focale per l‟efficacia del sis tema è l ‟assegnazione del
grado di affidabil i tà al le singole query ed ai motori di ricerca uti l izzati .
Per definire al meglio questi parametri sarà necessario svolgere
una sperimentazione uti l izzando come sistema valutazione quell i di un
classico sistema di Information Retrieval .
4.3.4 Modalità di interazione con i motori di r icerca
Non essendo definito uno stan dard universale per l ‟interazione ai
motori di ricerca, sarà necessario sviluppare un connettore per ogni t ipo
di motore uti l izzato: ad esempio, potranno essere sviluppati sistemi che
agiscono via API, via Webservices , sia XML diretto oppure anche
sistemi di puro pars ing del risultato del motore se non è prevista dallo
stesso un‟integrazione con altri sistemi.
4.3.5 Gestione dei t ipi di dato e della formattazione dei valori
Un aspetto uti le può essere la formattazione dei vari valori , in base
al t ipo di dato. In questo caso occorre analizzare quali siano i t ipi di
dato soggett i a queste formattazioni specifiche (o addiri t tura a
l inguaggi specifici1).
Ad esempio, una data potrebbe essere espressa in vari format i:
25/03/2009 (formato europeo);
25 marzo 2009 (st i le europeo);
03/05/2009 (formato americano);
1 Per sempl ic i t à suppo niamo che le t rad uzio ni vengano e f fe t tua te da l motore
d i IR ut i l izza to .
54
25th of March 2009 (st i le americano);
2009-03-05 (formato SQL).
Deve quindi essere possib ile definire, in fase di configurazioni
delle query, i l formato corretto da uti l izzare per l ‟istanza in oggetto.
4.3.6 Controllo di accesso
Deve essere possibile applicare ai path ottenuti un meccanismo di
controllo dei privilegi di accesso finalizzato a rendere protetto i l
servizio da utenti non autorizzat i , salvaguardando la sicurezza e la
riservatezza dei documenti .
55
5 PRODOTTI E TECNOLOGIE UTILIZZATE
«Non è suff iciente possedere una buona
mente. L ’ importante è saperla usare nel modo
giusto.»
Cartesio
5.1 KarthaDoc
5.1.1 Presentazione
KarthaDoc è uno st rumento che consente di gesti re , archiviare e
consultare tutto i l flusso documentale aziendale, rappresenta la
soluzione ai problemi derivanti dalla gestione documentale cartacea, è
un valido supporto per l ‟organizzazione aziendale, ott imizza i processi
aziendali e ne riduce i costi . Consente inoltre di gestire , archiviare e
consultare tutto i l flusso documentale aziendale, rappresenta la
soluzione ai problemi derivanti dalla gestione documentale cartacea, è
un valido supporto per l ‟organizzazione aziendale, ott imizza i processi
aziendali e ne riduce i costi .
5.1.2 Funzionalità
Le funzionali tà di KarthaDoc si sviluppano in tre fasi:
Gestire.
In KARTHADOC la catalogazione dei documenti vuol dire
organizzare per classi tutt i i documenti dello stesso t ipo che
vengono inseri t i in un unico contenitore. Ad ogni classe
sono associate delle chiavi di ricerca che id enti ficano in
maniera univoca ogni documento inseri to. Con
KARTHADOC è quindi possibile gesti re grandi volumi di
documenti , sempre in l inea con facil i tà di ricerca ad alta
velocità, anche attraverso la gestione integrata di fax ed
email .
56
Archiviare.
La st ruttura del software permette l ‟archiviazione e
l‟ indicizzazione automatica dei documenti prodotti
al l‟ interno dell ‟azienda, provenienti da sistemi ERP o da
qualsiasi al tra fonte digitale, evitando la scansione dei
documenti cartacei e riducendo drasticamen te le incombenze
del personale. I documenti archiviati possono essere legati
fra loro in maniera t rasversale, legami bi -direzionali , oppure
essere correlati vert icalmente in dossier.
Consultare.
Una volta archiviat i i documenti sono disponibil i per la
consultazione. Le chiavi ed i campi di indicizzazione
permettono la ricerca veloce del documento e la sua
visualizzazione in formato „copia conforme, anche
richiamato direttamente sulla maschera front end di un
applicativo esterno (gestionale).
5.1.3 Tecnologia
KARTHADOC è stato sviluppato con i l supporto della tecnologia
.NET di Microsoft ma anche con una completa compatibil i tà con la
tecnologia open dei web services.
Sono previste funzioni API di creazione, ricerca, visualizzazione,
copia, invio fax, invio mail , acquisizione da spool, funzioni di
integrazione dati (autoload), invocab il i con metodo OLE o Socket Tcp,
funzionali tà di integrazione completa con emulatori di terminale
programmabili (Client Access AS400 ecc).
Il cl ient web è stato realizzato secondo un a rigida ripart izione a
l ivell i :
1. Risorse e Base Dati separate (multipiattaforma e
multidatabase)
2. Logica Applicativa con tecnologia SOAP XML (standard
W3C)
57
I Web services realizzano l ‟ intera logica dell ‟archiviatore
mettendo a disposizione una interfaccia s tandard basata sulle tecnologie
SOAP e XML. I vantaggi di tale ripart izione sono:
indipendenza dal l ivello presentazione che può essere
interamente riscri t to mantenendo inalterata la Logica;
possibil i tà di integrare funzioni di gestione documentale
(Ricerca, Creazione, Visualizzazione, Cancellazione,
Note…) in portali esistenti o in altri applicativi an che non
Web in modo t rasparente;
affidabil i tà ;
facil i tà di installazione e configurazione .
Lo sviluppo di un client web personal izzabile avviene att raverso
l‟util izzo di due tool: KarhaGate e KarthaBridge.
Kartha Gate semplif ica l ‟ integrazione con KarthaDoc uti l izzando i l
l ivello di presentazione come ponte verso la logica. Questo avviene
attraverso l ‟ invocazione URL a pagine del l ivello presentazione che
permettono di effettuare alcune operazioni di base (visualizzazione ,
ricerca , creazione). Questo permette:
Integrazione con altri applicativi senza ridisegnare le pagine
Web;
Basso tempo di sviluppo;
Possibile divisione tra si to/programma integrato e
documentale.
KarthaBridge integra gli applicativi non web (ERP) con una logica
di chiamate via socket che generano eventi in pagine Web. Attraverso
un demone Java in ascolto su una porta socket tcp parametrica effettua
i l parsing del messaggio in arrivo ed effet tua la chiamata all ‟opportuna
pagina di KarthaGate. Questo permette:
Un sistema Multipiattaforma;
La migrazioni delle integrazioni già real izzate con olwsock e
DDE2OLE verso i l nuovo applicativo ;
58
La semplificazione dei processi di integrazione stretta t ra
gestionale e KarthaDoc in ambiente Web .
Con l‟util izzo di JavaSock e KarthaBridge è possibile proporre
l‟ integrazione stretta tra KarthaDoc e altri applicativi in ambiente
Multipiattaforma e Web Based.
KarthaDoc è in grado di delegare completamente la prob lematica
di accesso all ‟applicativo Active Directory, tramite i l quale i l sistema
decide che t ipo di servizi sono disponibil i .
5.2 Google Mini (search appliance)
5.2.1 Presentazione
La crescente mole di informazioni digital izzate ha posto le aziende
nella condizione di gestire database sempre più vasti e complessi .
Google Mini è un prodotto pensato e progettato per la
piccola/media impresa che necessita di migliorare l ‟accesso e la
condivisione dell ‟ informazione, mantenendo l imitati i costi e
soprattutto le at t ivi tà di manutenzione: offre una soluzione snella, a
rapida installazione, i l più possibile autonoma ma che nello stesso
tempo offre i l valore aggiunto desiderato. Tecnicamente è una
soluzione “appliance”, ovvero con sistema operativo e software
applicativo preinstallat i , una conseguente fase di installazione
veramente veloce e semplice, spiccate capacità di self -learning che ne
riducono al minimo le att ività di manutenzione e ri levanza nella
generazione dei risultat i di ricerca.
5.2.2 Funzionalità
Google Mini è in grado di indicizzare i l contenuto dei portali
internet/ intranet e più di 200 t ipi di fi le memorizzati in cartelle
condivise grazie ad un crawler ad elevate prestazioni. I risultat i
possono essere res ti tuit i al l ‟utente direttamente dal motore stesso
oppure possono essere passati al lo stesso portale di accesso
intranet/ internet e quindi trasformati uti l izzando la grafica, i template e
gli st i l i dell ‟azienda. È inoltre in grado di integrarsi con i sistemi di
sicurezza standard aziendale al fine di verificare che tra i risultat i
59
rest i tuit i non ci siano documenti ai quali l ‟utente non abbia poi accesso
in let tura. Le API di cui Google Mini è dotato permettono di realizzare
in maniera molto semplice questa integrazione con i repository di
informazioni aziendali e con i web/fi le server.
5.2.3 Il supporto concreto offerto
Google Mini offre la possibil i tà di effet tuare una ricerca veloce su
tutt i i documenti aziendali , consentendo all ‟operatore di poter offri re
immediatamente tutte le risposte all ‟ interlocutore, oppure può essere un
concreto supporto decisionale perché mette a disposizione le
informazioni proprio nel momento della scelta o della decisione.
La soluzione Google Mini è completamente autonoma e isolata
rispetto al motore Google online, non riceve informazioni e non ne
invia. L‟unica relazione, peraltro indiretta , col motore on -line è
l‟util izzo degli algoritmi che Google sviluppa grazie all ‟enorme
esperienza fatta con miliardi di ricerche giornaliere su google.com
5.2.4 Motivazioni relativi alla soluzione integrata
La soluzione “appliance” garantisce che l ‟hardware sia
correttamente dimensionato per supportare le prestazioni del motore di
ricerca e che sia di semplice installazione (infatt i dopo aver dato
l‟ indirizzo IP alla macchina, i l software è già installato e si p assa
subito alla fase di configurazione). Una soluzione software
richiederebbe notevoli conoscenze informatiche presso i l cl iente per
essere installata, lascerebbe al cl iente la responsabil i tà sull ‟util izzo
dell‟hadrware corretto basandosi su l iste di serv er cert ificati che
cambiano di anno in anno e renderebbe più complessa la fase di
manutenzione.
5.2.5 Differenze tra Google Mini e Google Mini
La soluzione Google Mini è pensata per la media e grande azienda,
in quanto fornisce r ispetto a Google Mini delle possi bil i tà avanzate di
personalizzazione e di integrazione con i sistemi del cl iente. Le
principali differenze tra le due piattaforme riguardano la t ipologia di
repository indicizzati e le integrazioni con sistemi di sicurezza. Per
60
quanto riguarda i l primo pun to, Google Mini è in grado di indicizzare
anche i database, i Document Management Systems come, ad esempio,
Lotus Notes, Documentum, Livelink, Filenet, Sharepointetc ed è dotata
di un‟API di feeding che rende possibile caricare manualmente
nell‟ indice della macchina i documenti che si desidera vengano
indicizzati . Per quanto riguarda i l secondo punto, quello della
sicurezza, Google Mini è in grado di integrarsi con sistemi avanzati di
autenticazione e autorizzazione, come i sistemi di Single Sign On,
offrendo delle API per integrare i sis temi di sicurezza proprietari e
personalizzati . Per quanto riguarda le funzionali tà offerte all ‟utente,
un‟alt ra differenza è che su Google Mini vengono rese disponibil i le
funzionali tà avanzate di ricerca e di fi l tering bas ate sui metadati , olt re
alla possibil i tà di influenzare percentualmente i pesi assegnati dagli
algoritmi ai diversi documenti e al la disponibil i tà di funzioni avanzate
di classificazione e categorizzazione.
5.3 Web service
5.3.1 Definizione W3C
Secondo la definizione data dal World Wide Web Consortium
(W3C) un Web Service (servizio web) è un sistema software progettato
per supportare l ‟ interoperabil i tà tra diversi elaboratori su di una
medesima rete; caratterist ica fondamentale di un Web Service è quella
di offrire un‟ interfaccia software (descrit ta in un formato
automaticamente elaborabile quale, ad esempio, i l Web Services
Description Language) uti l izzando la quale altri sistemi possono
interagire con i l Web Service stesso at t ivando le operazioni descri t te
nell‟ interfaccia tramite apposit i "messaggi" inclusi in una "busta" (la
più famosa è SOAP): tal i messaggi sono, soli tamente, trasportati
tramite i l protocollo HTTP e formattati secondo lo standard XML.
Proprio grazie all ‟util izzo di standard basati su XML, t ramite
un‟architettura basata sui Web Service (chiamata, con terminologia
inglese, Service oriented Architecture - SOA) applicazioni software
scri t te in diversi l inguaggi di programmazione e implementate su
61
diverse piattaforme hardware possono quindi essere uti l i zzate, tramite
le interfacce che queste "espongono" pubblicamente e mediante
l‟util izzo delle funzioni che sono in grado di effettuare (i "servizi" che
mettono a disposizione) per lo scambio di informazioni e
l‟effettuazione di operazioni complesse (quali , ad esempio, la
realizzazione di processi di business che coinvolgono più aree di una
medesima azienda) sia su reti aziendal i come anche su Internet: la
possibil i tà dell ‟ interoperabil i tà fra diversi software (ad esempio, tra
Java e Python) e diverse piatta forme hardware (come Windows e Linux)
è resa possibile dall ‟uso di standard "aperti".
Il consorzio OASIS (Organization for the Advancement of
Structured Information Standards) ed i l W3C sono i principali
responsabil i dell ‟architettura e della standardizzaz ione dei Web
Service; per migliorare l ‟ interoperabil i tà tra le diverse implementazioni
dei Web Service l ‟organizzazione WS-I sta inoltre sviluppando una
serie di "profil i" per meglio definire gli standard coinvolti .
5.3.2 Funzionamento dei web service
Il protocollo di base per i Web service è http , che si occupa di
mettere in comunicazione i l servizio web con l ‟applicazione che intende
usufruire delle sue funzioni.
Oltre ad HTTP però, i servizi web uti l izzano molti al t ri standard
web, tutt i basati su XML, t ra cui :
XML Schema;
UDDI (Universal Description, Discovery and Integration) ;
WSDL (Web Services Description Language) ;
SOAP (Simple Object Access Protocol) .
È importante sottolineare che XML può essere uti l izzato
correttamente tra piattaforme differenti (Linux, Windows, Mac) e
differenti l inguaggi di programmazione. XML è inoltre in grado di
esprimere messaggi e funzioni anche molto complesse e garantisce che
tutt i i dati scambiat i possano essere uti l izzati ad entrambi i capi della
connessione. Si può quindi dire che i Web service sono basati su XML
62
ed HTTP e che possono essere uti l izzati su ogni piattaforma e con ogni
t ipo di software.
5.3.3 Principali vantaggi
I Web service permettono l ‟ interoperabil i tà tra diverse
applicazioni software e su diverse piattaforme
hardware/software;
Utilizzano un formato dei dati di t ipo testuale, quindi più
comprensibile e più facile da uti l izzare per gli sviluppatori
(esclusi ovviamente i trasferimenti di dat i di t ipo binario);
Normalmente, essendo basati sul protocollo HTTP, non
richiedono modifiche alle regole di sicurezza uti l izzate come
fi l tro dai fi rewall;
Sono semplici da uti l izzare e possono essere combinati l ‟uno
con l‟altro (indipendentemente da chi l i fornisce e da dove
vengono resi disponibil i) per formare servizi "integrati" e
complessi;
Permettono di riuti l izzare applicazioni già sviluppate;
Fintanto che l ‟ interfaccia rimane costante, le modifiche
effettuate ai servizi rimangono trasparenti ;
I servizi web sono in grado di pubblicare le loro funzioni e
di scambiare dati con i l resto del mondo;
Tutte le informazioni vengono scambiate attraverso
protocoll i "aperti".
5.3.4 Svantaggi e problematiche
5.3.4.1 Performance
I Web service presentano performance drasticamente inferiori
rispetto ad altri metodi di comunicazione uti l izzabil i in rete. Questo
svantaggio è legato alla natura stessa dei servizi web. Essendo basati su
XML ogni trasferimento di dati richiede l ‟ inserimento di un notevole
numero di dati supplementari (i tag XML) indispensabil i per la
descrizione dell ‟operazione. Inoltre tutt i i dati inviati richiedono di
essere prima codificati e poi decodificati ai capi della connessione.
63
Queste due caratter ist iche dei Web service l i rendo no poco adatt i a
flussi di dati intensi o dove la velocità dell ‟applicazione rappresenti un
fattore cri t ico.
5.3.4.2 Il protocollo HTTP
Quando si sviluppa un Web service è necessario tener conto del
protocollo di base. È quindi indispensabile disporre di un ‟applicazione
terza che gestisca le richieste HTTP oppure è necessario includerla
direttamente nel codice del nostro programma qualora si desideri la sua
totale indipendenza. Va detto comunque che generalmente i l codice che
implementa un Web service viene fatto e seguire da un Web server (es.
Apache) t ramite CGI (per es. con Python) o t ramite apposit i moduli
(vedi PHP). Eseguendo i l codice del Web service attraverso un server
web la gestione di HTTP è immediatamente assicurata.
64
65
6 RICERCA FUTURA
«Ogniqualvolta una teoria t i sembra essere
l’unica possibile, prendilo come un segno che
non hai capito né la teoria né i l problema che
si intendeva risolvere.»
Karl Popper
6.1 Utilizzo di sistemi informativi diversi
A livello generale possiamo considerare che motori di ricerca
diversi possono agire su sistemi informativi diversi; est remizzando, si
possono considerare motori di ricerca che agiscono su specifici domini
o sottoinsiemi di sis temi informativi .
Quindi teoricamente possiamo interagire con ogni sistema di IR,
creando i connettori opportuni (sia per la compilazione delle query che
per i l recupero dei risultat i) .
6.2 Usabilità relativa alla configurazione delle query
L'usabil i tà è defini ta dall ' ISO ( ISO 9241-11, “Ergonomics of
human-system interaction - Guidance on usabil i ty” ), come l 'efficacia,
l 'efficienza e la soddisfazione con le quali determinati utenti
raggiungono determinati obiett ivi in determinati contesti . In pratica
definisce i l grado di facil i tà e soddisfazione con cui l ' interazione uomo -
strumento si compie.
Il termine non si riferisce ad una caratterist ica intrinseca dello
strumento, quanto al processo di interazione t ra classi di utenti ,
prodotto e finali tà. È però d 'uso comune - per estensione - l 'uso di
questo termine in forma di aggett ivo (es: questo st rumento è
particolarmente usabile.)
Il problema dell 'usabil i tà si pone quando i l modello del progett ista
(ovvero le idee di questi riguardo al funzionamento del prodotto, che
trasferisce al design del prodotto stesso) non coincide con i l modello
66
dell 'utente finale (ovvero l ' idea che l 'utente concepisce del prodotto e
del suo funzionamento).
Il grado di usabil i tà si innalza proporzionalmente
all 'avvicinamento dei due modell i (modello del progett ista , e modello
dell 'utente).
Pertanto la definiz ione di questi due mode ll i può non essere
banale: ad esempio, dal punto di vista del progett ista potrebbe essere
uti l izzato un sistema a pattern replacement del t ipo
Decreto Legislativo $_Data_#_Estesa_$, n. $_Numero_$
“$_Titolo_$” pubblicato nella Gazzetta Ufficiale n.
$_NumeroGazzetta_$ del $_DataPubblicazione_#_Estesa_$
che, dal punto di vista del‟utente, potrebbe non essere familiare.
Questo dipende anche dal l ivello di conoscenza dell‟utente che dovrà
configurare le query.
6.3 Utilizzo dei coefficienti di rilevanza (relevance scores)
La funzione per i l calcolo del rating definit ivo di un collegamento
ri tengo debba avere i seguenti requisit i :
i l risultato deve essere sempre maggiore o uguale di ogni
singolo rating ottenuto, o in alt ri termini del valore massimo
di rating ottenuto (i l fat to che si trovi lo stesso risultato in
ricerche diverse è indice di maggior confidenza dello
stesso);
i l risultato deve essere uguale ad uno dei valori se e solo se
gli al tri sono uguali a zero (per lo stesso motivo)
l‟ incremento del valore massimo di rating deve dipendere in
maniera direttamente proporzionale dagl i al tri valori ;
la funzione deve godere della proprietà commutativa e
associativa (in particolare, avendo più di due valori i l
risultato non deve dipendere dall ‟ordine in cui considero
questi valori );
la funzione deve prendere in ingresso due valori al la volta,
al fine di poter essere uti l izzata in processi i terativi .
67
6.4 Interazione con l’utente per la verifica dei risultati
La verifica e la gestione del le interazioni precedentemente
effettuate dagli utenti risulta uti le per l ‟eliminazione di falsi posit ivi
(uti l izzando tecniche di collaborative fi l tering opportunamente
modificate e adattate al problema ).
6.4.1 Metodo “Feedback” (eBay)
Per ogni collegamento, oltre al fat tore di rate automatico, vien e
mantenuto una sorta di punteggio di feedback, in base alle indicazioni
degli utenti . Di default , tale valore viene impostato a zero.
Quando l‟utente accede per la prima vol ta ad un path collegato, gli
viene richiesta una valutazione del t ipo “L‟ informazione è collegata al
documento originale?” con tre opzioni possibil i : “Sì”, “No”,
“Indifferente”:
Se l‟utente sceglie “Indifferente”, i l puntegg io di feedback
rimane invariato;
Se l‟utente sceglie “No” i l punteggio di feedback viene
diminuito di un ‟unità;
Se l‟utente sceglie “Sì”, i l punteggio di feedback viene
aumentato di un ‟unità.
A questo punto si possono scegliere alcune strade:
i l punteggio di feedback viene visualizzato nell ‟elenco dei
risultat i ;
collegamenti con feedback posit ivo vengono portati in testa
all‟elenco;
collegamento con feedback negativo vengono portati in coda
all‟elenco;
i l punteggio di feedback influisce a run -time sul rate del
collegamento;
quando i l punteggio di feedback supera una certa soglia i l
path viene definit ivamente collegat o al documento;
68
quando i l punteggio di feedback è inferiore ad una certa
soglia i l collegamento viene rimosso (e non verrà più
inseri to in una futura re -indicizzazione);
sempre i l discorso delle soglie, ma invece di effettuare
l‟operazione diretta su un co llegamento viene inviata la
proposta dell ‟operazione all ‟amministratore di sistema;
Inoltre, ad ogni ruolo di utenza può essere associato un diverso
peso sul punteggio di feedback, magari anche relativo alla
DocumentClass in cui si sta operando.
6.4.2 Metodo “Pool” (quiz, sondaggi, etc. )
Per ogni collegamento viene mantenuta una media -voto (che, per
semplificare la vita degli utenti , può essere compreso tra 1 e 4) . Di
default , tale media è pari a 2 ,5.
Quanto l ‟utente accede per la prima volta ad un path collegato , gli
viene chiesta una valutazione numerica da 1 a 4 (del t ipo di quell i che
si trovano nei sondaggi).
Viene quindi mantenuta questa media voto, e in base ad essa
possono essere intraprese delle azioni simili a quelle indicate per la
gestione del punteggio di feedback.
6.5 Falsi negativi e autoapprendimento
6.5.1 Azioni da parte degl i utenti relative ai falsi negativi
Può essere prevista una maschera di ricerca, in cui l ‟utente può
effettuare una ricerca l ibera su tutto i l sistema informativo.
Nel caso in cui tra i risultat i di questa ricerca vi siano path
collegati che non risultano nell ‟associazione automatica, l ‟utente può
creare direttamente questo collegamento.
Può inoltre essere prevista l ‟associazione manuale di un path
diretto ad un documento.
A questo punto le associazioni manuali avr anno di defalt un rate
pari al massimo (salvo eventuali valutaz ioni feedback/pool).
69
6.5.2 Meccanismi di autoapprendimento
In un sistema di questo t ipo meccanismi di auto -apprendimento
sono diffici l i da valutare in questa fase: forse un o sbocco in tal senso
potrebbe essere un ‟analisi semantica delle query di ricerca l ibera da cui
deriva un collegamento manuale (che eventualmente potrebbero essere
mantenute in memoria e poi vagl iate dall ‟amministratore come
“proposta di modello di st ringa di ricerca”). Un aiuto, anche in questo
caso, può venire dagli studi di collaborative fi l tering che riguardano la
raccolta implicita delle preferenze.
70
71
CONCLUSIONI
«Non costringerai a esistere ciò che non
esiste.»
Parmenide
Il lavoro ha visto la realizzazione di un prototipo di un
componente software impostato in modo da soddisfare un primo livello,
basilare, di soluzione del problema.
L‟ interfaccia web e le procedure devono permettere all ‟utente una
gestione dei collegamenti in l inea con le propr ie aspettative.
Questo prototipo è facilmente integrabile in altri sistemi
informativi modificando tutto ciò che prettamente tecnologico e
specifico di ogni motore di ricerca o sistema documentale uti l izzato. La
struttura comunque flessibile, mantenuta in fase di analis i , lo rende
svincolabile dalla gestione specifica di documenti presa in
considerazione.
La fase di start -up di questa applicazione comprende quindi:
l‟analisi delle esigenze reali e del contesto di ri ferimento;
predisposizione dei moduli di i nterfaccia con i prodotti presi
in considerazione;
analisi e configurazione dei pattern relativi al le query di
ricerca;
ricerca empirica dei l ivell i di affidabil i tà delle singole query
e dei specifici motori di ricerca;
ultimo, non per importanza, far capi re agli utenti
l‟ importanza dell ‟ut il izzo di eventuali sistemi di interazione
finalizzati al l ‟ individuazione dei falsi posit ivi e/o negativi .
Le funzionali tà anal izzate e implementate non coprono tuttavia i l
panorama completo degli obiett ivi preposti : possono comunque essere
spunti di partenza per lo sviluppo di at t ività future, alcune delle quali
sono state comunque esplicitate ed t racciate.
72
73
RIFERIMENTI BIBLIOGRAFICI
«Solo un inventore sa come prendere a
presti to un ’ idea, ed ogni uomo è o dovrebbe
essere un inventore.»
Ralph Waldo Emerson
[AslMon01] Javed A. Aslam, Mark Montague , "Models for
Metasearch", Dartmouth College, 2001 .
[BaeNet99] R. Baeza-Yates e R. Neto, “Modern Information
Retrieval”, ACM Press, 1999.
[BHK98] J . Breese, D. Heckerman and C. Kadie "Empirical
analysis of predictive algorithms for collaborative fi l tering",
Proceedings of the Fourteenth Conference on Uncertainty in Arti ficial
Intell igence, Madison, 1998
[Bor81] J . C. Borda, “M´emoire sur les ´elections au scrutiny”,
Histoire de l ‟Acad´emie Royale des Sciences, 1781.
[CHI97] A.Chislenko, "Automated Collaborative Fil tering and
Semantic Transports", 1997,
http:/ /www.lucifer.com/~sasha/art icles/ACF.html , 10 gennaio 2009
[CMK96] Cleverdon C.W., Mills J . , Keen M., “Factors
Determining the Performance of Indexing Systems, Volume I - Design,
Volume II - Test Results” ASLIB Cranfield Project Cranfield, 1966.
[Dem04] Gianluca Demartini , “Una metrica di valutazione per
l‟information retriva: analisi cri t ica e sperimentazioni”, Università
degli Studi di Udine, Tesi di laurea specialist ica in Informatica, 2004.
[Eco00] "The mathematics of voting: Democratic symmetry", The
Economist , page 83, Marzo 2000 .
[GalCap03] Lil iana Galdi, Prof. Amedeo Cappell i , “ I Linguaggi di
markup per l ‟elaborazione del l inguaggio naturale”, Seminario di
Elaborazione del Linguaggio Naturale , Università di Pisa, 2003.
74
[GavVal05] Giulio Gavardi, Nicodemo Valerio, "Stemming",
Dipartimento di Matematica Pura ed Applicata dell 'Università di
Padova, Anno Accademico 2005/06 .
[GNO92] D. Goldberg, D. Nichols, B.M. Oki and D. Terry, "Using
collaborative fi l tering to weave an information tapestry",
Communications of the ACM, 35(12):61 -70, 1992
[HSR95] W. Hill , L. Stead, M. Rosenstein and G. Furnas,
"Recommending and evaluating cho ices in a virtual community of use",
Proc of CHI-95, pp 192-201, 1995
[Kar04] Karen Sparck Jones , “A statist ical interpretation of term
specifici ty and i ts application in retrieval ”, Journal of Documentation
pp. 493 – 502, I. 5, V. 60, 2004.
[Luh58] H. P. Luhn , “The Automatic Creation of Literature
Abstracts”, IBM Journal, pp. 159 -165, Aprile 1958.
[MR96] Peter Murray-Rust, "An introduction to Structured
Documents", Nottingham University, 1996 .
[Mur03] Rick Murphy, “Structuring the unstructured (document)”,
Ottobre 2003,
http:/ /findarticles.com/p/art icles/mi _qa3947/is_200310/ai_n9337103 ,
13 dicembre 2008.
[NW00] "Gestione documentale, una questione di orientamento",
Network World, http:/ /www.nwi.i t /nwi_arretrati /ap090001.htm, 13
dicembre 2008.
[Olo] Olocom Technology, “Information retrieval”
[Po04] Laura Po, “Progetto e realizzazione di un‟applicazione per
l‟archiviazione ott ica sosti tutiva di documenti”, Università di Modena e
Reggio Emilia, Tesi di laurea in Ingegneria Informatica, 2004.
[Saa01] Donald G. Saari , “Chaotic Elections! A mathematician
looks at voting” , American Mathematical Society, 2001.
[Saa98] Donald G. Saari , "Explaining All Three -Alternative Voting
Outcomes", Northwestern University, 1998 .
75
[Sar75] Saracevic Tefko, "Relevance: A Review of an d a
framework for the thinking on the notion in information science",
Journal of the American Society for Information Science, pp. 321 -343,
dicembre 1975.
[SelEtz96] Erik Selberg, Oren Etzioni , “The MetaCrawler
Architecture for Resource Aggregation on the Web”, University of
Washington, 1996.
[Sin01] Amit Singhal, "Modern Information Retrieval: A Brief
Overview", Bulletin of the IEEE Computer Society Technical
Committee on Data Engineering, Vol. 24 No. 4. pp. 35 -42, 2001
[Zip49] Zipf G.K. , “Human behaviour and the principle of least
effort”, Cambridge (Mass.) , Addison-Wesley Press, 1949.
76
77
APPENDICE A – PRESENTAZIONE
«E forse, i posteri mi ringrazieranno per
aver mostrato che gli antichi non conoscevano
tutto.»
Pierre de Fermat
Frontespizio
Pensiamo a quanti documenti di vitale importanza vengano persi o
dimenticati al l‟interno di una qualsiasi rete aziendale. Va da sé che la
mancata fruizione di queste informazioni può comportare un danno
economico perché i l loro recupero può essere laborioso o, nella
peggiore delle ipotesi , può non avvenire.
I sistemi di gestione documentale ci vengono in aiuto per risolvere
questa problematica, ma non riescono a soddisfare appieno le esigenze
degli utenti : ci rca l‟80% delle informazioni è contenuta in documenti
che non possono essere inseri t i in questi sistemi se non con un
dispendioso intervento umano.
L‟obiett ivo del lavoro di tesi è quindi i l collegamento assist i to tra
documenti strutturati e non strutturati al l‟interno di un sistema di
gestione documentale.
78
Nello specifico, è s tato progettato un componente software web -
based basato su un Google Mini, una soluzione hardware e software
integrata che applica la stessa capaci tà e produttività della ricerca
Google alla ricerca globale su tutt i i documenti present i nella rete
aziendale.
Analizzeremo i sis temi di gestione documentale e gli aspett i
posit ivi dell ‟uti l izzo di documenti strutturati : per raggiungere i l nostro
scopo faremo una panoramica sul mondo dell‟ IR e, prima di affrontare
la soluzione proposta, un‟analisi d ella struttura dei meta -motori di
ricerca e di come i sistemi di voto ci aiutino in questo settore.
Chiuderemo con alcuni spunti di sviluppo e alcune note conclusive.
Gestione documentale
Visto che non esiste una solida base scientifica e teorica
riguardante nello specifico i l mondo della gestione documentale, per
prima cosa chiariremo alcune definizioni e peculiari tà di questi sistemi.
La nostra unità di riferimento è i l documento , che può essere
un‟informazione organizzata oppure più generalmente un qu alsiasi
oggetto2.
Come documento non strutturato intendiamo un documento senza
formato specifico (ad esempio, un testo): possiamo anche introdurre la
2 Nel lo spec i f ico par t i r emo da l p resuppos to d i t ra t ta re document i in fo rmato
e le t t ro nico , a s sunz ione che no n può e ssere sempre sconta ta .
79
definizione di documento semi strutturato (ad esempio, un testo diviso
in capitoli e in paragrafi).
Come documento strutturato intendiamo invece un documento che
al suo interno contiene una struttura che definisce le informazioni di
base. Questa strut tura viene generalmente specificata attraverso
l‟uti l izzo di meta dati (informazioni che descrivono l‟oggetto p er
fornire delle conoscenze aggiuntive) dichiarati con l inguaggi di
markup3 (una serie di convenzioni s tandardizzate che descrive i
meccanismi di rappresentazione strutturali , semantici o presentazional).
In realtà la struttura di queste meta informazioni prende i l nome di
classe di documento , e i l documento stesso può essere quindi visto
come un‟istanza di questa classe4.
Un sistema di gestione documentale è un sistema completo per la
gestione automatica del ciclo di vita dei documenti (creazione, uti l izzo
e mantenimento). Nello specifico, penseremo ad un records
management system , in cui le classi di documento sono rappresentate da
tabelle e i l singolo documento att raverso un record.
Parlando dei sistemi d i gestione documentale bisogna analizzare
almeno tre aspett i :
i cri teri di catalogazione dei documenti (assegnazione
manuale o automatica di tag/categorie);
l‟architettura client -server-repository, ove i l repository è
suddiviso a sua volta in:
o fi le system, per i l salvataggio dei documenti;
o DBMS, per i l salvataggio dei metadati ;
o l‟insieme dei collegati tra fi le e record;
workflow documentale (3R):
o routes: processi , sequenze di passi;
o rules: azioni, cioè che va fatto sui documenti;
3 I l te rmine markup (o marca tura) der iva da l l ' ambien te t ipograf ico dove s i
usava marcare con annotaz ion i le par t i de l tes to che andavano evidenz ia te o
cor re t te , a l lo scopo d i segnalar le a l co mpo si to r e o a l da t t i lografo . 4 Cor r i spondenza con i l inguaggi XML: le c lass i d i document o sono espresse
a t t raverso DTD o XSD e i document i a t t raverso document i XML -Va l id ,
80
o roles: persone, chi può o deve fare qualcosa.
Collegamento tra documenti strutturati e documenti
non strutturati
Il collegamento tra documenti st rutturati e non st rutturat i può
avvenire attraverso un‟indicizzazione manuale (assegnazione manuale
delle meta informazioni ai document i non strutturati ) o attraverso
sistemi di auto-classificazione, estrazione automatica dei meta dati ).
Il vantaggio nell ‟uti l izzo di documenti s trutturati è i l poter rendere
i l contenuto del documento facilmente recuperare ed interpretabile, per
favorire i processi di ricerca, archiviazione ed estrazione di dati (non
bisogna dimenticare che la strutturazione delle informazioni è un
processo naturale della mente umana spesso sottovalutato o considerato
implicito!).
81
Information Retrieval
L' Information Retrieval t rat ta l ' insieme delle tecniche ut i l izzate
per i l recupero delle informazioni in formato elettronico .
Per recuperare le informazioni, i sistemi IR usano i l inguaggi di
interrogazione basat i su comandi testual i . I concett i fondamentali sono
quell i di query (stringa di parole chiavi) e oggetto (enti tà che racchiude
informazioni).
Formalmente, un sistema di IR è rappresentabile da una
“quadrupla” composta da:
D: insieme di rappresentazioni logiche dei documenti;
Q: insieme di rappresentazioni logiche dei fabbisogni
informativi (le query);
F: i l modello di r iferimento per la rappresentazione dei
documenti e delle richieste e delle relazioni tra loro;
R(Qi, Dj): una funzione di “ranking” che ordina i documenti
recuperati che soddisfano la richiesta.
Le tecniche di indicizzazione studiate per le basi di dati
relazionali non sono adatte per questi sistemi: esistono svariati t ipi di
indici uti l izzati , che comprendono anche algoritmi di semplificazione e
di “riduzione ai minimi termini” dei vocaboli presenti .
Il reperimento del le informazioni avviene att raverso questo
processo:
82
l 'utente specifica i l suo fabbisogno informativo att raverso le
query;
viene resti tuita una l ista di documenti , in ordine di
ri levanza;
l 'utente indica quali documenti sono a suo giudizio
pertinenti .
La valutazione generale dei sistemi di IR è in realtà sogget t iva e
può variare da utente ad utente, ma possiamo indicare dei cri teri
generali da considerare:
precisione (materiale recuperato effett ivamente ri levante) e
recall (materiale ri levante effett ivamente recuperato);
contesti di applicabi l i tà;
facil i tà di ricerca e di analisi dei risultat i ;
semplicità di implementazione.
Visto che i l problema comunque riguarda un ambiente web -based,
possiamo introdurre i l concetto di Web Information Retrieval
relativamente al mondo dei motori di r icerca (che sono a loro volta
sistemi di IR), considerando una pagina web come un documento.
Occorre comunque portare una grande attenzione verso gli aspett i di
creazione della collezione5 e di interazione con l 'utente
6.
5 Mole de i da t i , d is t r ib uz io ne de i document i t ra server d iver s i , vo la t i l i tà ,
r idondanza , q ua l i tà , e t e rogenei t à , recupero . 6 Spec i f ica de l le r ichie s t e , p resentaz ione de i r i su l t a t i .
83
Meta motori di ricerca
Abbiamo introdotto i l discorso dei motori di ricerca intesi come
sistemi di IR, ma a noi interessa in questo caso analizzare i l
funzionamento dei meta motori di ricerca: un meta motore
semplicemente è un 'interfaccia che svolge la sua interrogazione su più
motori di ricerca contemporaneamente.
I concett i relativi ai sistemi di IR sono gli stessi , anche se vi è una
maggiore complessità del processo di reperimento:
la query inseri ta dal l‟utente viene formulata (eventualmen te
tradotta) per i divers i motori di ricerca;
inizia i l processo di reperimento sul singolo motore (con la
relativa esecuzione delle query e l‟attesa dei risultat i);
i risultat i ottenuti vanno raggruppati ;
occorre gestire l‟eliminazione dei duplicati .
Il problema del raggruppamento dei risultat i è i l più complesso da
affrontare, dato che non si può formulare una st rategia generale a causa
di vari parametri che possono caratter izzare un singolo motore: per
rimanere in ambito generale, considereremo la st rada dei risultat i sotto
forma di classifica e i l non uti l izzo di meccanismi di auto -
apprendimento.
84
Sistemi di voto
Un sistema di voto elettorale contiene al suo interno regole per
definire come i voti devono essere aggregati per ottenere un risultato
finale.
Possiamo considerare i “candidati” come l‟insieme dei risultat i
ottenuti da un singolo motore (“elettore”). Queste procedure non sono
direttamente applicabil i ai meta motori in quando assumono la presenza
di pochi candidati rispetto al numero di votanti : nei meta motori ci
troviamo di fronte allo scenario opposto in quanto abbiamo tanti
candidati di fronte a pochi elettori .
In questo scenario ci viene in aiuto i l metodo Borda -Count, che
riprende i l metodo di voto del senato romano:
ogni elettore classif ica un insieme fissato di n candidati in
ordine di preferenza;
per ogni votante, al primo candidato della l ista vengono
assegnati n punti , al secondo n -1, al terzo n-2 e così via;
se ci sono candidati che non sono stati inseri t i nella
classi fica, essi si div idono equamente i punti non assegnati
dal singolo elettore;
i l candidato al quale viene assegnato i l maggior punteggio
vince le elezioni (con lo stesso cri terio è possibile quindi
determinare una classifica finale).
85
È stata dimostrata la sua efficacia in q uesto scenario, ed inoltre le
prestazioni sono “abbastanza buone”.
Proposta di soluzione del problema
Visto che la storia ci insegna che ottenere informazioni strutturare
a parti re da documenti non st rutturati è un procedimento molto
complesso, ribalt iamo il problema: a parti re da ogni documento
strutturato generiamo una o più query di ricerca, che diamo in pasto a
motori di ricerca diversi . Per fare questo, definiremo delle query
(attraverso template) per ogni classe di documento (possiamo anche
definire su quali singoli motori debbano essere eseguite queste query).
Possiamo inolt re associare a questi query template dei coefficienti di
ri levanza (una query può essere più ri levante di un‟alt ra), così come
possiamo definire questi coefficienti per i singoli motori (un motore
può essere più affidabile di un alt ro).
Quindi a part ire da un documento non strutturato possiamo
ottenere dei “documenti non strutturati” (le istanze delle query al
singolo documento) da dare in pasto ad un motore di ricerca.
Eseguendo i processo di reperimento a partire da queste query
possiamo associare dei documenti non strutturati ai nostri documenti
strutturati (basta al largare i l concetto di meta motore, considerando
ogni query diversa come un motore di ricerca diversa).
86
Algoritmo generale
Definiamo ora i l processo di reperimento:
per ogni query template associato alla classe di documento,
creo l ‟istanza della query relativa al singolo documento
grazie ai dati contenuti nelle meta informazioni;
per ogni motore di ricerca associato al query template,
eseguo i l singolo processo di reperimento;
genero l ‟elenco dei candidati7 (unisco tut t i gli URL);
per ogni l ista di risultat i , calcolo i l punteggio col metodo
Borda-Count;
per ogni punteggio, applico i l calcolo dei coefficienti di
ri levanza (query, motori);
sommo tutt i i punteggi e resti tuisco la classifica finale.
7 Con i s i s temi d i vo to t r ad iz ional i co no sco a p r io r i l ‟e lenco de i candida t i .
87
Sviluppi
Una volta definita la struttura e l‟algoritmo di funzionamento del
nostro componente, dobbiamo prestate una grande attenzione re lativa
alla configurazione dello stesso. Possiamo individuare cinque punti
fondamentali :
la definizione dei query template e la loro sperimentazione
per l ‟assegnazione dei coefficienti di ri levanza;
la selezione dei motori di ricerca e la loro sperimentazi one
per l ‟assegnazione dei coefficienti di aff idabil i tà;
la definizione delle modali tà di esecuzione della procedura
(schedulata, on demand, al l‟apertura di ogni documento);
la gestione della formattazione relativa al t ipo di dato della
meta informazione u ti l izzata (ad esempio, i vari formati di
scri t tura delle date: europeo, americano, europeo esteso…);
definizione dei privi legi di accesso ai vari URL che possono
essere diversi per utenti diversi .
Inoltre possiamo individuare alcuni spunti di ricerca inter essanti
riguardo al prototipo:
util izzo di motori di ricerca che possono agire su sistemi
informativi diversi8;
8 Nel ca so preso in e same s i t ra t tava d i un unico s i s tema in format ivo .
88
considerazioni relat ive all ‟usabil i tà e al la semplicità della
configurazione dei query template da parte dell ‟utente;
l‟uti l izzo di motori di ricerca che uti l izzano un meccanismo
di relevance scores piuttosto che di ranking.
Il punto più interessante riguarda l‟uti l izzo di sistemi di
collaborative fi l tering propri dei sistemi di IR per la valorizzazione
dell‟interazione con l‟utente, analizzando l ‟aspetto umano e la storia di
util izzo dei documenti grazie ad
sistemi di raccolta delle preferenze;
sistemi di feedback, in st i le eBay;
util izzo di un ulteriore sistema di voto per la valutazione dei
risultat i da parte del l‟utente;
al fine di poter implementare meccanismo di auto apprendimento e
di individuazione dei falsi negativi .
Conclusioni
Vista la forte implicazione del lato umano nella soluzione del
problema, questo componente deve essere realmente applicabile e di
facile uti l izzo.
La st ruttura del servizio deve quindi essere flessibile,
configurabile ed allo stesso tempo indipendente, al fine di rispondere
alle esigenze di ogni singolo t ipologia di documento e di ogni contesto
di riferimento.
89
Purtroppo a causa della premessa iniz iale non è f acile valutare
formalmente un sistema di questo t ipo, perché possiamo valutare la
precisione del sistema ma non i l suo recall (non sappiamo a priori quali
documenti siano stati “persi” all‟interno del sistema informativo), se
non uti l izzando del le collezioni di dati “ist i tuzionali” che vengono
comunemente uti l izzate per i l test dei sistemi informativi (ma i l
contesto reale di applicazione – un sistema di archiviazione di
documenti gestional i - è diverso data la molteplicità di formati di
documenti presenti nel sistema informativo).
La vera conclusione che possiamo raggiungere dopo l‟analis i della
problematica e la realizzazione del componente è che non si può
mettere la parola fine.
90
91
RICONOSCIMENTI
«Credo che i riconoscimenti siano una
delle sezioni più let te. È dove l ’autore, per un
breve istante, può distogliere la mente
dall’aridità del documento accademico per
esprimere anni di frustrazione e grat i tudine
accumulate.»
Håkon Wium Lie
Non farò nomi e cognomi onde evitare di dimenticare nessuno,
visto gli anni impiegati nella mia carriera universitaria e la molti tudine
di persone che mi hanno affiancato in questo cammino.
Il primo ringraziamento comunque non può non andare a chi ha
sponsorizzato i miei studi9.
Il secondo va ai docenti che ho incontrato nel la mia carriera
scolastica ed universitaria che, ognuno a modo suo, mi hanno trasmesso
informazioni ma soprattutto metodi di studio e di lavoro diversi t ra
loro: l‟impegno di ogni studente è quindi di riuscire ad effettuare un
“raggruppamento” ( tanto per r estare in argomento di tesi…) di tutte
queste conoscenze.
Un bacio ed un abbraccio vanno a tutt i coloro che hanno
sopportato i miei momenti di “ignoranza”10
causati dallo stress
universitario ed i vari disagi (in primis, la mia compagna e gli amici
più strett i) .
Un saluto va anche ai miei compagni di studi con cui ho affrontato
goliardicamente le tante ore passate in dipartimento ed ai colleghi che
mi hanno aiutato (implici tamente o esplici tamente) a raggiungere
questo t raguardo.
9 Studi , var ie , even tua l i…
10 E che tanto co nt inueranno a soppor tare…
92
Non posso lasciar fuori chi mi ha dato l‟opportunità di svolgere
questo lavoro di tesi , che mi ha dato l‟opportunità sì di ot tenere nuove
conoscenze ma soprattutto di farmi riscoprire la passione per la scienza
e per la ricerca che mi aveva spinto ad iscrivermi a questa Università.
Ora basta leggere, non siamo mica qua a dare i l colore ai pesci
rossi!
93
COLOPHON
«Un buon algoritmo è come un coltello
aff i lato: fa esattamente ciò che si suppone
debba fare applicando una quantità minima di
forza. Invece usare un algoritmo sbagliato per
risolvere un problema è come tagliare una
bistecca con un cacciavite: si può anche
arrivare ad un risultato accettabi le, ma
facendo sicuramente uno sforzo più grande di
quanto non fosse necessario, e inoltre i l
risultato non sarà certo elegante.»
Thomas H. Cormen, Charles E. Leiserson,
Ronald L. Rivest , "Introduzione agli algoritmi"
La versione stampata di questo documento è stata scri t ta con
Microsoft Word 2007 su Windows XP eseguito in ambi ente Parallel su
Max OSX 10.5.6. Le figure sono state realizzate con Microsoft Visio
2007.
La fonte t ipografica uti l izzata è stata i l Times New Roman
12pt/16pt: è un carattere t ipografico con grazie ideato nel 1931 da
Stanley Morison comparso poi per la prima volta i l 3 ottobre 1932 sul
quotidiano britannico The Times (venne rimpiazzato dopo ben 40 anni,
poiché le tecnologie di stampa erano completamente cambiate).
Gli esempi di codice sono scri t t i in Courier New 10pt : un carattere
monospazio (progettato per assomigliare ai caratteri delle macchine da
scrivere) creato da Howard "Bud" Kettler nel 1955, anche se i l design
apparve però per la prima volta nel 1950 e fu usato dall ‟IBM nelle
proprie macchine da scrivere che, non avendone l ‟uso esclusivo dal
punto di vista legale , è diventato presto uno standard per l ‟ industria
delle macchine da scrivere e per i programmatori che lo uti l izzano per
scrivere codice sorgente.
94
Tutto i l materiale r iportato e citato nel testo è di proprietà dei
rispett ivi autori: mi scuso se in alcuni punti ho omesso
involontariamente di ci tare delle fonti . Per la presentazione delle
tecniche e dei prodotti uti l izzati mi sono integralmente av valso di
documenti promozionali , tecnici e/o guide sul web: nella fat t ispecie mi
sono avvalso: dei documenti prodotti da Kartha per la presentazione di
KarthaDOC; del materiale messo a disposizione da Google riguardo i l
GSA; di materiale pubblicato su Wiki pedia e su HTML.IT r iguardo al
mondo web service come tributo per due portali che mi hanno dato
tanto in questi anni.
Questo volume è stato stampato in Ital ia .
Tutto i l materiale da me prodotto ex-novo è protetto dalle leggi
della Repubblica Ital iana sul copyright e sulla proprietà intel let tuale.
95
Atari 800XL (Fo nte: Wikipedia)
Alessandro Bondi è nato nel 1980 a Ravenna, ove ancora tuttora
risiede. Fin dalla tenera età appassionato di informatica ( inizia a
programmare intorno agli 8 anni grazie ad un vecchio Atari 800XL e
successivamente ad un Olivett i M-20), dopo aver frequentato l ‟Ist i tuto
Tecnico inizia a lavorare sia come libero professionista in ambito
consulenza e web sia come insegnante di informatica in alcuni ist i tuti
superiori (con parentesi lavorative in tutt ‟altro settore, come autista
soccorri tore d ‟ambulanza): nel frattempo intraprende, a ri lento, la
strada universitaria (si presenterà a discutere la tesi di laurea dopo
nove anni accademici). Nel 2005 prende la decisione di pa ssare dalla
l ibera professione al la realtà aziendale.
Attualmente è project manager, progett ista di applicazioni web e
analista programmatore PHP. Ha sempre mantenuto un grande rispetto
verso gli standard e verso tutto ciò che riguarda accessibil i tà e
usabil i tà , cercando di puntare verso lo "s tato dell 'arte". La sua passione
è l ' innovazione tecnologica.
Da un punto di vista extraprofessionale ha portato avanti numerose
att ività di volontariato (e non) in ambito cattolico, sociale e sportivo,
ad oggi purt roppo ridotte a causa di sopravvenuti problemi di salute.
Alessandro Bondi
www.alessandrobondi.com
alessandro.bondi@gmail .com