Progetto MARSILIUS il motore di ricerca dell`Ateneo fiorentino

Progetto MARSILIUS
il motore di ricerca dell’Ateneo fiorentino
Premessa
Con il crescere della quantità di informazione a disposizione degli utenti della rete, uno dei
problemi fondamentali è la difficoltà di selezionare con la maggior precisione possibile ciò
che interessa. Per questa ragione negli ultimi anni l’attenzione si orientata verso i sistemi di
ricerca e filtraggio delle informazioni.
Se questo aspetto è assolutamente evidente sulla scala globale dell’intera rete Internet, non
è meno importante in situazioni molto più limitate ma molto complesse e articolate come
un’università.
L’utente che si trova davanti alla scatola nera “Università di Firenze” e ha bisogno di trovare
un’’informazione specifica deve poter disporre di strumenti efficaci ed efficienti per
raggiungere questo scopo. Sicuramente una valida organizzazione dei contenuti del sito web
è una condizione necessaria, ma se le informazioni contenute sono molte, non è sufficiente.
Per questa ragione è sempre più necessario che l’Ateneo si doti di uno strumento specifico
per reperire le informazioni, cioè un motore di ricerca dedicato, che vada a sostituire l’attuale
motore di ricerca implementato da CSIAF nel 2005 su sollecitazione di alcuni uffici
dell’Ateneo (Segreteria Organi collegiali, ufficio Redazione Siti Web e ufficio Comunicazione
Interna e Sviluppo Organizzativo) che indicizza solo parte dei documenti del sito di Ateneo e
non risulta essere adeguato alle esigenze complessive.
Tale strumento sarebbe utile anche al raggiungimento dell’obiettivo C “Accesso alle
informazioni sulla didattica” del progetto “Potenziamento e sviluppo dei servizi informatici di
supporto alla didattica per gli studenti” cofinanziato dalla Fondazione del Monte dei Paschi di
Firenze, in quanto consentirebbe un facile reperimento delle informazioni attualmente
disperse in molti siti: sito di Ateneo, di Facoltà e di Corso di Studio.
Un motore di ricerca consiste in realtà di tre entità logicamente distinte:
il web crawler, che scandaglia sistematicamente un insieme di siti web e ne cataloga le
risorse (pagine web, documenti pdf ecc.), inserendo in un database le informazioni rilevanti;
l’indexer, che opera sulle informazioni precedentemente catalogate creando gli indici utili a
identificarle:
il searcher, che consente agli utenti di formulare una richiesta, effettua la ricerca sugli indici e
fornisce le risposte ottenute.
Anche se in linea di principio è possibile avere applicazioni distinte corrispondenti alle tre
entità, ragioni di efficienza e di facilità di interfacciamento suggeriscono di adottare soluzioni
integrate fin dalla nascita. D’ora in poi useremo quindi il termine “motore di ricerca”, o MdR
per indicare il sistema completo delle sue tre componenti.
Situazione
Il fattore principale di cui tenere conto è che non esiste UN sito web dell’Università di
Firenze, ma una galassia di siti, nati in tempi diversi e spesso molto diversi fra loro, orbitanti
attorno al sito “principale”. Un MdR per l’Ateneo deve quindi poter effettuare un crawling
periodico dei diversi siti.
In secondo luogo i siti non si differenziano solamente per l’aspetto grafico, ma per
l’organizzazione delle informazioni e per la tipologia delle “pagine”. Un ampio sottoinsieme
utilizza pagine dinamiche fornite da un Content Management System (il site CMS-format
CSIAF), ma sono molti anche i siti che ospitano solo pagine HTML statiche. Esistono poi siti
con contenuti dinamici eterogenei e soprattutto un vasto insieme di documenti statici in vari
formati: pdf, doc, rtf, ppt ecc.
Tipologie di Motori di Ricerca
Il mercato offre fondamentalmente due tipi di soluzioni:
• software
• appliance
Software
La soluzione software prevede l’utilizzo di un set di applicazioni corrispondenti ai tre
componenti di un MdR. All’interno di questa tipologia è importante distinguere fra soluzioni
proprietarie e open source.
Software proprietario
In questo ambito i prodotti sono molteplici e di vario livello. Tutti sono caratterizzati dal
prevedere una stretta integrazione di crawler, indexer e searcher.
Vantaggi:
il software è tipicamente pacchettizzato e di facile installazione;
unico referente tecnico;
facile reperibilità e fruizione della documentazione.
Svantaggi:
il software presenta vari livelli di “chiusura”; non è facile se non impossibile, effettuare
modifiche.
le licenze sono costose.
Software open source
Anche nel mondo open source i prodotti sono molteplici, ma in realtà pochi quelli che
sembrano fare capo a progetti attivi e supportati da un’ampia comunità.
In questo ambito è stato possibile effettuare alcuni test su prodotti specifici.
SWISH-E
Da alcuni anni l’indexer e il searcher di SWISH-E vengono utilizzati in Ateneo per indicizzare
sezioni specifiche del sito principale, in particolare i verbali di Senato Accademico, Consiglio
di Amministrazione e Nucleo di Valutazione, il Bollettino ufficiale e il notiziario.
Mentre l’indicizzazione di questi set di documenti non ha presentato grandi problemi, i test di
utilizzo del crawler si sono rivelati problematici (lentezza, irraggiungibilità di alcuni link, veri e
propri crash).
SWISH-E è stato realizzato per lo più in C, con alcuni moduli in Perl. La conoscenza di
quest’ultimo linguaggio è essenziale per effettuare modifiche di medio livello al sistema.
Terze parti forniscono un’interfaccia PHP per realizzare l’interfaccia del searcher.
Lucene - Nutch - Solr
Lucene è specificamente una libreria di funzioni creata nell’ambito del superprogetto Apache.
Al suo interno è stato realizzato Nutch, che è fondamentalmente un crawler e un indexer. In
esso esiste una funzionalità di searcher molto semplificata, dato che il vero searcher è Solr.
La loro integrazione tuttavia non è out-of-the-box e richiede un complesso lavoro di
integrazione.
Le esperienze fatte con Nutch indicano che si tratta di un software valido e sicuramente
adatto a gestire situazioni complesse, anche superiori a quella dell’Ateneo. Questa capacità
si paga in termini di difficoltà di configurazione e resta aperta la questione di integrare il
seacher Solr con Nutch, operazione per la quale si rileva la necessità di un notevole knowhow specifico.
Lucene, Nutch e Solr sono realizzato in linguaggio Java e utilizzano al meglio la piattaforma
Tomcat di Apache (anche se altri motori servlet sono utilizzabili).
Sphider
Sphider è un MdR sviluppato per situazioni medio-piccole ed è realizzato interamente in PHP
con il supporto del database MySQL. Entrambi questi ambienti sono largamente utilizzati sui
sistemi dell’Ateneo, e ciò facilita la possibilità di apportare modifiche per adeguare il software
alle necessità che possono manifestarsi in corso d’opera.
Nei test effettuati si è rivelato molto facile da installare e configurare, tuttavia va rilevato che
le funzionalità offerte non sono molto avanzate, almeno nella versione esaminata. Esiste
infatti una release Spider-plus molto più avanzata che utilizza una versione di PHP al
momento non disponibile per il test e che sembra garantire prestazioni superiori in termini di
precisione nella ricerca.
Appliance dedicate
Una appliance è un sistema computerizzato progettato per svolgere un determinato compito
molto specifico come, in questo caso, ospitare un MdR. Tali sistemi sono noti come Web
Search Appliance.
Vantaggi:
ottimizzazione delle risorse;
la Server Farm non è gravata da speciali oneri di manutenzione e gestione, come accade in
tutti i casi di soluzione di tipo software.
Svantaggi:
si tratta sempre di sistemi “chiusi”, dove le possibilità di intervento sono limitate a un set
stabilito a priori dal fornitore.
Prodotti sul mercato
Esistono vari appliance sul mercato internazionale, fra cui abbiamo rilevato degne di
interesse:
ƒ
ƒ
ƒ
ƒ
Google
Thunderstone
Index Engines
Infolibrarian
Al di là delle caratteristiche, fra essi solo Google è presente in forze in ambito italiano e ciò di
fatto lo rende l’unica scelta disponibile qualora si scelga questa tipologia di sistemi.
Tenendo conto dello “svantaggio” sopra indicato, si sono esaminate con attenzione le
possibilità di configurazione e di adeguamento a realtà complesse del sistema offerto da
Google, constatando che sono molto ampie e in grado di soddisfare le più varie esigenze.
Si è rilevato inoltre che l’appliance di Google è stata adottata dalle Università di: Torino,
Palermo, Ferrara, Modena e Reggio, Verona.
A cura dell’Ufficio Siti Web – CSIAF
Il materiale tecnico e le informazioni contenute nel presente documento sono di
natura strettamente confidenziale e di esclusiva proprietà del CSIAF. Non è consentita
la divulgazione e la riproduzione totale o parziale senza esplicita autorizzazione.