Click here to load reader

SAMM - Report progetto

  • View
    221

  • Download
    0

Embed Size (px)

DESCRIPTION

Report progetto SAMM

Text of 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 nellambito 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 DINterVeNto 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

    delluniversit 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

  • 1Il 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 delluniversit degli Studi

    di Firenze (MSn-unIFI) alla scheda nazionale definita dallIstituto

    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 DellunIVeRSIT DeglI STuDI DI FIRenze AllA SCheDA nAzIonAle DellISTITuTo CenTRAle peR Il CATAlogo e lA DoCuMenTAzIone

  • RepoRT DI pRogeTTo2

  • 3pRIMA 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 uneventuale 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, uccelliBotanica: l'intero archivio in formato Microsoft Access dell'erbario Centrale Italiano, gli archivi in formato DBF dell'erbario Webb e della collezione labillardire.

    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

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

  • 92.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 uninterfaccia 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.

    ReAlIzzAzIone e ApplICAzIone DellA nuoVA SCheDA CATAlogRAFICA

  • 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 originariotrasformazione di formato, dal formato originario (Microsoft Access, DBIV) a SQl standardimportazione dell'SQl sul db di supportoper 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;

  • RepoRT DI pRogeTTo12

    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

    ReAlIzzAzIone e ApplICAzIone DellA nuoVA SCheDA CATAlogRAFICA

  • RepoRT DI pRogeTTo14

    pagina di visualiZZaZione delle schede in forMato denorMaliZZato

  • 15

    pagina per lesportaZione 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

    ReAlIzzAzIone e ApplICAzIone DellA nuoVA SCheDA CATAlogRAFICA

  • RepoRT DI pRogeTTo16

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

  • RepoRT DI pRogeTTo18

  • 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

  • RepoRT DI pRogeTTo20