SAMM - Report 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

RepoRt di pRogetto »

Progetto SAMM-StuDIo DI fAttIbIlItà

la pubblicazione fa parte dei risultati di un progetto finanziato nell’ambito del bando della regione toscana

Misura/linea: 1.1.d realizzazione di progetti di ricerca in materia di scienze socio economiche e umane - bANDo

regIoNAle 2008 Per Il SoStegNo A ProgettI DI rICerCA CoNgIuNtI trA gruPPI DI IMPreSe e orgANISMI DI rICerCA

IN MAterIA SCIeNZe eCoNoMICHe e uMANe

Sostegno ai progetti di ricerca congiunti tra gruppi di imprese e organismi di ricerca in materia di scienze socio-economiche e umane

ProgrAMMA oPerAtIVo regIoNAle toSCANA (Por-Creo 2007/2013) ASSe 1, lINeA D’INterVeNto 1.1 D

PArtNer Del Progetto

Dr Wolf s.r.l. (capofila)

Via Ponte alle Mosse 43/a, 50144 firenze

www.drwolf.it

Museo di Storia Naturale

dell’università degli Studi di firenze

Via la Pira 4, 50121 firenze

http://www.msn.unifi.it

eDA Servizi soc. coop.

Via Pellas 20 A/b, 50141 firenze

www.edaservizi.it

1

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

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

RepoRT DI pRogeTTo2

3

pRIMA FASeAnAlISI DeI CATAloghIe DeglI ARChIVI

1.1In 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

Zoologia

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)Collezioni elmintologiche “VeRMeS”

circa 4.300 sì no

Mineralogia 39.291 sì sì (completo)

Botanica circa 5.000.000 sì sì (parziale)

AnAlISI DeI CATAloghI e DeglI ARChIVI

RepoRT DI pRogeTTo4

1.2Tutti gli archivi informatici e le relative applicazioni sono stati 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.3parallelamente, 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.4Dato 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.5per 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.

5AnAlISI DeI CATAloghI e DeglI ARChIVI

1.6l'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.

RepoRT DI pRogeTTo6

7

SeConDA FASeReAlIzzAzIone e ApplICAzIone DellA nuoVA SCheDA CATAlogRAFICA

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.1la 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:

RepoRT DI pRogeTTo8

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.

9

2.2la 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 e 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.


RepoRT DI pRogeTTo10

2.3Sulla 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.

11ReAlIzzAzIone e ApplICAzIone DellA nuoVA SCheDA CATAlogRAFICA

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 a 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;•


2.4Infine è 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

13

pagina di Modifica dati di una scheda iccd

pagina di gestione per le taBelle di supporto



pagina di visualiZZaZione delle schede in forMato denorMaliZZato

15

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 archiviola 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 schedaI 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 43.000 schede:

tipo QuerY QuerY risultati teMpo

Su numero archivio 5.3816 1 4’’

Su numero archivio 99.999 (non esistente) 0 4’’

Su specie bauxite 8 20’’

Su specie quarzo 4.631 15’’

Su specie argento 237 15’’

Su specie aaaaaa (non esistente) 0 20’’



17ReAlIzzAzIone e ApplICAzIone DellA nuoVA SCheDA CATAlogRAFICA

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). Suc-cessivamente ha ripetuto la stessa operazione sull'applicazione prototipale.

Questi sono stati i tempi di esecuzione:

ApplICATIVo oRIgInARIo ApplICATIVo pRoToTIpAle

4. comparazione dei tempi di immissioneCome 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.


19

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 •stati 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.

TeRzA FASeDIChIARAzIone DI FATTIBIlITà

DIChIARAzIone DI FATTIBIlITà


Documents

SAMM - Report progetto