Il progetto SAMM - Museo di Storia Naturale

1
uno studio per la migrazione degli archivi catalografici del
Museo di Storia Naturale dell’Università degli Studi di Firenze
alla scheda nazionale dell’Istituto Centrale per il Catalogo e
la Documentazione
Il progetto SAMM (Studio di fattibilità per la definizione di una
metodologia e la realizzazione di un sistema informatico di
ausilio per il recupero degli archivi catalografici di beni culturali
naturalistici e il loro allineamento con gli standard ICCD), finanziato
dalla Regione Toscana attraverso il Bando regionale 2008 per il
sostegno a progetti di ricerca congiunti tra gruppi di imprese
e organismi di ricerca in materia di scienze socioeconomiche e
umane, stanziato su fondi provenienti dal programma POR FESR
2007 - 2013 ATTIVITA' 1.1 LINEE D'INTERVENTO D, ha avuto come
obiettivo la valutazione di fattibilità di una migrazione degli archivi
catalografici del Museo di Storia Naturale dell’Università degli Studi
di Firenze (MSN-UNIFI) alla scheda nazionale definita dall’Istituto
Centrale per il Catalogo e la Documentazione (ICCD) attraverso l'uso
di un innovativo sistema informatico di supporto all'estrazione e
alla riconciliazione dell'informazione esistente.
La valutazione di fattibilità è stata suddivisa in varie fasi >>
2
Report di progetto
3
analisi dei cataloghi e degli archivi
PRIMA fase
Analisi dei cataloghi
e degli archivi
1.1
In primo luogo è stata effettuata un'analisi quantitativa dei dati disponibili, sia da un punto di vista dei vari media
(database esistenti e relative tecnologie o materiale cartaceo) sia dal punto di vista delle tipologie di schede utilizzate.
Successivamente sono state valutate le metodologie per la riconciliazione dei dati e del lessico utilizzato.
La descrizione qualitativa e quantitativa del patrimonio informativo disponibile ha permesso di elencare quanti e quali
dati le varie sezioni del Museo possiedono.
Questa attività ha prodotto i seguenti risultati, che presentiamo in forma tabellare:
SEZIONE
SOTTOSEZIONE
N. CAMPIONI
CATALOGHI CARTACEI
ARCHIVI INFORMATIZZATI
Uccelli
circa 10.000
sì
sì (completamento in corso)
Mammiferi
circa 22.000
sì
sì (completo)
Anfibi
26.495
sì
sì (completo)
Rettili
40.253
sì
sì (parziale, 1/3)
Crostacei
circa 4.300
sì
sì (parziale, 1/3)
Isopodi
9.170
no
sì (completo)
Echinodermi
2.090
sì
no
Pesci
17.743
sì
sì (parziale, 1/8)
Insetti
circa 27.000
sì
sì (parziale, 1/7)
Molluschi continentali
circa 28.000
sì
sì (completo)
circa 4.300
sì
no
Mineralogia
39.291
sì
sì (completo)
Botanica
circa 5.000.000
sì
sì (parziale)
Zoologia
Collezioni
Elmintologiche “VERMES”
4
Report di progetto
1.2
Tutti gli archivi informatici e le relative applicazioni sono state analizzati per evidenziarne funzionalità, difetti, lacune.
Per ogni archivio elettronico sono state valutate le tecnologie utilizzate, l'organizzazione dei dati e le interfacce di utilizzo.
Inoltre sono stati evidenziati i problemi legati alla presenza di dati in formato non standard, con errori di battitura o
non strutturati.
È stato effettuato un tentativo di riconoscimento automatico di caratteri presenti su schede cartacee, per un eventuale
digitalizzazione, ma il tentativo non ha prodotto risultati soddisfacenti.
1.3
Parallelamente, nella prima fase del progetto è stata condotta un'approfondita analisi delle specifiche delle schede di
catalogazione prodotte dall'Istituto Centrale per il Catalogo e la Documentazione (ICCD) riguardanti i Beni Naturalistici.
Questa analisi ha permesso di comprendere la peculiare struttura che queste specifiche possiedono e di evidenziare
alcune ambiguità ed errori. Successivamente, è stata costruita una struttura dati capace di rispettare in pieno le
specifiche.
1.4
Dato che lo studio di fattibilità comprendeva oltre alla mappatura dei dati lo studio di nuove interfacce di interazione
tra il sistema di archiviazione e gli utenti umani, è stato prodotto un report sullo stato dell'arte sui sistemi esistenti per
la catalogazione museale. Questa attività ha consentito di preparare la progettazione delle interfacce per l'applicazione,
grazie all'analisi dei sistemi di catalogazione esistenti, mettendone in evidenza pregi e difetti. Tra i sistemi analizzati
citiamo Aleph 500, Amicus, Sebina, TinLib, Easycat, Innopac Milennium.
1.5
Per poter preparare la migrazione dei dati e soprattutto per identificare le regole di migrazione è stata effettuata
infine l'analisi dei dati dei database. Per ognuno dei campi e per ognuna delle tabelle degli archivi elettronici analizzati
sono state estratte le liste di frequenza dei valori in essi contenuti.
Le liste di frequenza consistono in un elenco dei valori distinti che sono presenti in un campo, accompagnati dal
numero di occorrenze del valore. Queste liste costituiscono il modello estensionale degli archivi elettronici. L'analisi di
queste liste ha permesso ai catalogatori di rilevare incongruenze, errori di battitura, disomogeneità. Data la struttura
sostanzialmente non gerarchica delle informazioni di tutti gli archivi analizzati, il modello intensionale dei dati è
elementare ed è stato derivato direttamente dall'analisi della struttura delle tabelle.
analisi dei cataloghi e degli archivi
1.6
5
L'ultima attività di questa fase è consistita nella scelta di alcuni database del Museo di Storia Naturale da analizzare
e migrare. Questi database hanno rappresentato il caso studio dello studio di fattibilità. Gli archivi scelti per il caso
studio sono stati:
• Mineralogia: l'intero archivio in formato Microsoft Access.
• Zoologia: gli archivi in formato DBF di Mammiferi, Uccelli
• Botanica: l'intero archivio in formato Microsoft Access dell'Erbario Centrale Italiano, gli archivi in formato DBF
dell'Erbario Webb e della collezione Labillardière.
La scelta di questi archivi copre i tre tipi di schede di Beni Naturalistici ICCD e i più importanti tipi di tecnologie utilizzati
nelle varie sezioni del Museo.
6
Report di progetto
Realizzazione e applicazione della nuova scheda catalografica
7
Seconda fase
Realizzazione e
applicazione della nuova
scheda catalografica
Le attività della seconda fase sono state svolte con lo scopo di progettare l'architettura del sistema per la migrazione
semiautomatica degli archivi elettronici del Museo di Storia Naturale di Firenze verso il formato ICCD. È stato inoltre
valutato l'incremento delle performance che l'adozione dell'applicazione può comportare.
2.1
La prima attività di questa fase ha permesso di definire la metodologia necessaria per la riconciliazione e migrazione
dei dati provenienti dagli archivi elettronici del Museo di Storia Naturale.
Per ogni campo degli archivi originali è stato identificato quando possibile il campo corrispondente nella scheda ICCD
nel quale copiare il valore originario.
Questo mapping “semplice” non è stato sempre possibile per i vari motivi (nel seguito ne elenchiamo alcuni
esemplificativi):
• due o più campi degli archivi originali, non soltanto uno, potevano costituire la fonte dei valori per un campo della
scheda ICCD.;
• era necessario fare look-up su tabelle di supporto esterne dalle quali ricavare uno o più valori;
• l'informazione nell'archivio originario era presente in forma non strutturata, all'interno di un campo di testo
semplice. In questo caso sono state identificate regole di estrazione di informazione dal testo basate sulla
tokenizzazione, la ricerca di parole chiave all'interno del testo e l'uso di espressioni regolari. L'applicazione di
queste regole poteva portare a diversi tipi di risultati:
8
Report di progetto
la ricerca di una parola chiave all'interno del testo poteva permettere la valorizzazione di un certo campo nella
scheda ICCD con un'altra parola chiave o con il testo cercato;
-- la corrispondenza con un'espressione regolare poteva permettere di estrarre un valore, che, a sua volta,
poteva essere utilizzato per fare look-up all'interno di tabelle di supporto;
-- talvolta è stato necessario cercare testo all'interno di più campi per ottenere il valore da usare nel campo
della scheda ICCD;
La ricerca del testo all'interno di campi non strutturati è stata molto frequente in tutti gli archivi analizzati e ha
influenzato in maniera determinante la scelta degli strumenti utilizzati per la riconciliazione.
• il valore del campo nella scheda ICCD poteva essere scelto solo all'interno di un vocabolario chiuso e i valori del
vocabolario differivano da quelli nell'archivio originario;
• alcuni campi della scheda ICCD per essere compilati necessitavano di un'elaborazione complessa di informazioni
esterne;
• alcuni campi della scheda ICCD potevano essere compilati senza avere valori negli archivi originari (specialmente
quelli più generici, non specifici del bene naturalistico; es. TSK, LIR, NCTR...).
--
In alcuni casi non è stato possibile determinare regole automatiche che con assoluta certezza permettessero di
effettuare il mapping. Per questi casi si è deciso di lasciare che il sistema effettuasse comunque una mappatura, ma
che marcasse i campi mappati come 'non sicuri', in maniera che in un secondo momento il catalogatore potesse rivedere
'a mano' questi casi dubbi.
Queste e altre problematiche sono state evidenziate ed elencate attraverso una comparazione tra gli archivi esistenti
e la scheda ICCD condotta congiuntamente da personale informatico (DrWolf) e dai responsabili della catalogazione dei
vari archivi (Museo di Storia Naturale). Queste analisi hanno prodotto tabelle di regole che, per ogni campo della scheda
ICCD, descrivono in maniera discorsiva i metodi per effettuare il mapping.
Realizzazione e applicazione della nuova scheda catalografica
2.2
9
La seconda attività è consistita nell'analisi dei requisiti del sistema informatico. L'analisi ha prodotto le seguenti
conclusioni:
• il sistema doveva essere web based;
• il sistema doveva consentire l'autenticazione e la profilazione degli utenti;
• il sistema doveva presentare un'interfaccia coerente e unificata per l'inserimento e la modifica dei dati progettata
in maniera da mostrare tutti i campi della scheda ICCD di competenza;
• il sistema doveva presentare un'interfaccia coerente tra tutte le aree disciplinari per l'inserimento e la modifica dei
dati, progettata in maniera da mostrare solo un numero limitato di campi, diversi a seconda dell'area disciplinare.
L'intento era quello di riproporre sul nuovo sistema la maschera di inserimento dati che i catalogatori utilizzano
attualmente, in maniera da rendere la curva di apprendimento la meno ripida possibile;
• il sistema doveva implementare un meccanismo semplice e intuitivo per il passaggio tra le due interfacce di
inserimento;
• il sistema doveva presentare un interfaccia basilare di ricerca per tutti i campi della scheda ICCD;
• il sistema doveva presentare un'interfaccia coerente tra tutte le aree disciplinari per la ricerca semplice ed
avanzata su un numero di campi ridotto. L'intento era quello di creare uno strumento di ricerca evoluto che
soddisfacesse le normali esigenze di ricercatori e catalogatori che non hanno generalmente bisogno di effettuare
query su tutti i campi della scheda ICCD, ma solo su quelli specifici della loro area disciplinare;
• il sistema doveva presentare un'interfaccia coerente tra tutte le aree disciplinari per la presentazione dei risultati
di una ricerca;
• il sistema doveva presentare un'interfaccia di gestione delle tabelle di supporto;
• il sistema doveva implementare un meccanismo semplice e intuitivo per il passaggio dalle interfacce di gestione
dati a quelle di ricerca;
• il sistema doveva presentare un'interfaccia per l'upload dei database originari;
• il sistema doveva avere un meccanismo automatico per la storicizzazione delle catalogazione dei diversi beni. Le
specifiche ICCD prevedono che ogni volta che un dato di catalogazione di un bene viene modificato e o aggiunto,
si debbano aggiungere opportuni paragrafi che registrino le variazioni. Questo compito doveva essere svolto dal
sistema e non esplicitamente dagli utenti catalogatori.
10
Report di progetto
2.3
Sulla base dei requisiti ottenuti nel corso dell'attività precedente è stata definita l'architettura modulare per l'estrazione,
la trasformazione e il caricamento dei dati.
L'architettura progettata ruoterà intorno ad una Business Logic (BL) implementata in Java EE su application server JBoss
(http://www.jboss.org/jbossas).
La BL sfrutterà standard tecnologici diffusi e di provata qualità. In particolare verrà utilizzato il framework Seam
(http://seamframework.org) per l'integrazione tra interfacce grafiche, EJB e sistema di persistenza dei dati. Grazie a
Seam e a l'utilizzo di Hibernate (http://www.hibernate.org/) come layer di persistenza, la gestione dei dati su database
potrà essere effettuata sfruttando la filosofia di programmazione ad oggetti (con evidenti vantaggi nella realizzazione
del codice, nella sua modularizzazione, nel riuso e nella manutenzione) e risultando sostanzialmente indipendente
dall'RDBMS sottostante.
Tutte le operazioni saranno veicolate attraverso un'interfaccia web, che implementerà tutte le WUI descritte nell'attività
precedente. L'interfaccia web sarà integrata con la BL grazie al framework Seam e sfrutterà le più moderne e diffuse
tecnologie per la realizzazione di applicazioni web. In particolare dovranno essere utilizzate le librerie JSF (http://
javaserverfaces.java.net/), Facelets (http://java.net/projects/facelets/), RichFaces (http://www.jboss.org/richfaces/),
Primefaces (http://www.primefaces.org/).
Durante la progettazione e la realizzazione delle WUI, saranno seguiti principi di semplicità d'uso, responsività, continuo
feedback, immissione dati assistita e validata. Le WUI dovranno avere un aspetto quanto più possibile “desktop-like”
e avere comportamenti simili a quelli delle applicazioni client non web, in maniera da rendere il passaggio dai vecchi
sistemi al nuovo meno difficoltoso per gli utenti catalogatori.
Il sistema si appoggerà ad un RDBMS per la persistenza dei dati sia di natura catalografica che di utilità per l'applicazione.
L'RDBMS scelto è MySQL 5.1 (http://www.mysql.org), database gratuito edopen source ampiamente diffuso sia in ambito
di ricerca che industriale (come detto in precedenza, comunque, l'architettura è indipendente dall'RDBMS, quindi una sua
sostituzione non comporterà problemi).
Data la natura delle regole di riconciliazione dati, molto eterogenea, non è stato ritenuto possibile l'utilizzo di un
programma esterno adibito solo alla migrazione; in altre parole, non è stato ritenuto possibile che un programma
esterno potesse con facilità adattarsi alle molteplici esigenze che le regole di riconciliazione richiedono. Per questo si
è proposto di implementare le regole di estrazione all'interno della BL, sfruttando tutta la potenza e la flessibilità di un
linguaggio di programmazione di alto livello quale Java.
Realizzazione e applicazione della nuova scheda catalografica
11
La migrazione dei dati avverrà secondo la seguente procedura:
• upload dell'archivio originario
• trasformazione di formato, dal formato originario (Microsoft Access, DBIV) a SQL standard
• importazione dell'SQL sul db di supporto
• per ogni campione dell'archivio originario
-- creazione nuova scheda, se il campione non è presente
-- modifica scheda esistente, in caso di modifiche ad un campione esistente
Come evidenziato dalla procedura e per ragioni di comodità, tutti gli archivi prima di essere migrati dovranno essere
trasformati in SQL e portati sul database dell'applicazione. Questa procedura, governata dalla BL, sfrutterà alcuni
programmi di utilità esterni:
Access To MySQL (http://bullzip.com/products/a2m/info.php), per la conversione dal formato mdb a MySQL;
• Microsoft Access, per la conversione dal formato DBIV.
La piattaforma software per la riconciliazione dati Pentaho Data Integration (http://kettle.pentaho.org/) verrà usata
come layer di controllo tra la BL e gli strumenti esterni di accesso/conversione dei db originari.
Particolare attenzione è stata data alla definizione di una metafora di interazione con l'utente per la riconciliazione del
dato, specificando alcuni vincoli per la progettazione dell'interfaccia:
• tipi di utenza; generalmente sia gli utenti esterni, sia i ricercatori, che i catalogatori posseggono elevate competenze
nel campo dell'area disciplinare di interesse e, spesso, nel campo della catalogazione in genere, mentre dal punto
di vista informatico possono non essere aggiornati;
• formazione; è necessario per tutti gli utenti avere un'applicazione il più possibile simile a quelle attualmente
utilizzate per minimizzare i tempi di formazione;
• tipo di architettura; è stata scelta un'implementazione web-based. Questo comporta necessariamente una minore
responsività ai comandi impartiti dall'utente;
Per questi motivi è stato deciso di utilizzare i seguenti principi nella realizzazione delle interfacce che coinvolgono
utenti non amministratori:
• utilizzo di validazione dei dati inseriti (obbligatorietà, obbligatorietà di contesto...);
• utilizzo di menù a tendina, completamento automatico e suggerimenti (anche per minimizzare gli errori di
battitura);
• utilizzo di valorizzazione automatica di campi (es. nel caso della sistematica dei minerali);
• utilizzo di sistemi di feedback;
• personalizzazione delle interfacce di ricerca e gestione dati a seconda delle aree disciplinari;
12
Report di progetto
2.4
Infine è stato realizzato un sistema prototipale che costituisse il punto di partenza per lo sviluppo di un'applicazione
completa.
Nel seguito alcuni screenshot del prototipo realizzato.
La pagina di benvenuto
La pagina di login
Una pagina di ricerca con la presentazione dei risultati
Realizzazione e applicazione della nuova scheda catalografica
Pagina di modifica dati di una scheda ICCD
Pagina di gestione per le tabelle di supporto
13
14
Report di progetto
Pagina di visualizzazione delle schede in formato denormalizzato
15
Realizzazione e applicazione della nuova scheda catalografica
Pagina per l’esportazione delle schede in formato ICCD
L'applicazione realizzata, essendo un prototipo, non implementa tutte le funzionalità necessarie per un uso in un
contesto reale, ma dimostra la fattibilità del progetto.
Il prototipo realizzato è stato utilizzato per misurare la variazione di performance per alcune attività di
catalogazione:
1. Migrazione archivio
La funzione di esportazione riesce a migrare 400 schede in 2 minuti e 20 secondi, con una velocità media di 2,86
schede/sec.
2. Ricerca singola scheda
I tempi variano molto a seconda del tipo di ricerca e di quanti risultati la ricerca produce.
Riportiamo qui alcuni tempi indicativi delle performance, considerato un archivio di 43000 schede:
TIPO QUERY
QUERY
RISULTATI
TEMPO
Su numero archivio
53816
1
4’’
Su numero archivio
99999 (non esistente)
0
4’’
Su specie
bauxite
8
20’’
Su specie
quarzo
4631
15’’
Su specie
argento
237
15’’
Su specie
aaaaaa (non esistente)
0
20’’
16
Report di progetto
Realizzazione e applicazione della nuova scheda catalografica
17
3. Inserimento scheda (solo campi dell'archivio originario e campi obbligatori per la scheda ICCD)
Per effettuare questo test, l'utente catalogatore ha scelto a caso 10 campioni. Ha fatto una stampa di ognuno di essi
e ha aggiunto i valori non presenti nella scheda originaria, ma che devono essere inseriti nella scheda ICCD in quanto
obbligatori.
Dopodiché ha simulato un nuovo inserimento nell'archivio originario (cambiando soltanto il numero di archivio). Successivamente ha ripetuto la stessa operazione sull'applicazione prototipale.
Questi sono stati i tempi di esecuzione:
Applicativo originario
Applicativo prototipale
4. Comparazione dei tempi di immissione
Come si vede nonostante il prototipo e il sistema su cui è in esecuzione non siano ottimizzati e dotati di tutte le
funzionalità, i tempi di immissione sono comparabili: c'è un peggioramento di circa il 20%. Questo peggioramento,
però, è compensato dal fatto che il sistema prototipale valorizza automaticamente alcuni campi (quelli di natura più
archivistica) e dal fatto che la scheda compilata è esportabile immediatamente in formato ICCD.
18
Report di progetto
dichiarazione di fattibilitÀ
19
terza fase
dichiarazione
di fattibilitÀ
La terza e ultima fase, ha comportato il compimento delle seguenti attività:
• 3.1 Analisi dei costi e dei tempi necessari relativi alla ingegnerizzazione della piattaforma informatica. Sono stati
quantificati i costi per la realizzazione dell'intera applicazione con tutte le funzionalità implementate, del testing
e del deployment.
• 3.2 Analisi delle risorse umane e dei tempi necessari per la migrazione delle schede con il sistema definito. Sono
state quantificati i tempi e le risorse umane necessarie per la migrazione dei dati originari verso il formato
ICCD.
Possiamo concludere che la migrazione degli archivi elettronici del Museo di Storia Naturale di Firenze è realizzabile,
grazie a strumenti informatici innovativi realizzabili con tecnologie attualmente disponibili. L'applicazione informatica
permetterà una migrazione veloce anche se non completamente automatica.
Una volta migrati, i dati del Museo saranno compatibili con lo standard nazionale ICCD.
20
Report di progetto