Sei sulla pagina 1di 86

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 1 di 86

Ministero per i Beni e per le Attivit Culturali Direzione Generale per i Beni Librari e gli Istituti Culturali

CAPITOLATO TECNICO SULLEVOLUZIONE DEI PROGETTI BIBLIOTECA DIGITALE ITALIANA E NETWORK TURISTICO CULTURALE, ARCHIVIO DIGITALE DELLA MUSICA E RETE DELLA MUSICA ITALIANA

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 2 di 86

INDICE
0. Premessa .................................................................................................................................5 0.1. Terminologia gergale.......................................................................................................5 1. Quadro di riferimento .............................................................................................................8 1.1. I progetti in corso.............................................................................................................8 1.1.1. Il progetto Biblioteca Digitale Italiana e Network Turistico Culturale.................9 1.1.1.1. Il Portale BDI&NTC..........................................................................................9 1.1.1.2. La BDI e i progetti di digitalizzazione.............................................................10 1.1.1.3. Servizi e contenuti del primo nucleo del Portale.............................................10 1.1.2. Il progetto ADM ..................................................................................................12 1.1.2.1. Obiettivi e funzionalit di ADM......................................................................12 1.1.2.2. Standard e modelli di riferimento per ADM....................................................13 1.1.2.3. Caratteristiche salienti dei nodi ADM .............................................................14 1.2. Caratterizzazione delle attivit per la conservazione e la fruizione dei beni musicali ..15 1.2.1. Conservazione.........................................................................................................15 1.2.2. Catalogazione..........................................................................................................16 1.2.3. Digitalizzazione ......................................................................................................16 1.2.4. Informatizzazione ...................................................................................................16 1.2.4.1. Metadati ...........................................................................................................17 1.2.4.2. Indici ................................................................................................................17 1.2.4.2.1. Testuali......................................................................................................17 1.2.4.2.2. Multimediali..............................................................................................17 1.2.4.3. Dati...................................................................................................................18 1.2.5. Fruizione .................................................................................................................18 1.2.6. Interoperabilit........................................................................................................18 1.3. Documentazione di riferimento .....................................................................................19 2. Oggetto del progetto .............................................................................................................21 2.1. Obiettivi proposti ...........................................................................................................21 2.2. Scenario di integrazione tra i progetti attivi e i potenziali nuovi sviluppi.....................22 2.3. Architettura di massima .................................................................................................22 2.3.1. Rete ADM...............................................................................................................23 2.3.2. Extranet ADM.........................................................................................................24 2.3.3. Rete non ADM ....................................................................................................24 2.3.4. Rete ReMI...............................................................................................................24 2.3.5. Interfaccia ReMI-Portale BDI&NTC .....................................................................25 3. Descrizione del progetto .......................................................................................................26 3.1. Evoluzione del progetto Biblioteca Digitale Italiana e Network Turistico Culturale 26 3.1.1. Profilazione dei servizi ...........................................................................................26 3.1.1.1. Statistiche .........................................................................................................26 3.1.1.2. Servizi di news.................................................................................................26 3.1.1.3. Servizi di ricerca..............................................................................................26 3.1.1.4. Prospettazione dei risultati...............................................................................27 3.1.1.5. Cronologia delle ricerche (utenti registrati).....................................................27 3.1.1.6. Segnalibri per salvare le ricerche (utenti registrati).........................................27 3.1.1.7. Salvataggio delle preferenze di ricerca (utenti registrati)................................27 3.1.1.8. Segnalibri per salvare documenti di interesse (utenti registrati)......................28 3.1.1.9. Configurazione della prospettazione analitica (utenti registrati).....................28 3.1.1.10. Acquisti ..........................................................................................................28 3.1.1.11. Messaggi dagli amministratori.......................................................................28

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 3 di 86

3.1.1.12. Servizio di e-mail su novit ...........................................................................28 3.1.2. Profilazione degli utenti..........................................................................................28 3.1.2.1. Utente Internet .................................................................................................28 3.1.2.2. Fornitori di informazioni .................................................................................29 3.1.2.3. Utenza di gestione Portale ...............................................................................29 3.1.3. Profilazione dei fornitori di informazioni ...............................................................29 3.1.4. Metadati caratterizzanti...........................................................................................29 3.1.5. Internazionalizzazione del Portale..........................................................................30 3.2. Evoluzione del progetto ADM ...................................................................................34 3.2.1. Profilazione dei servizi ...........................................................................................36 3.2.1.1. Servizi per utenti comuni .................................................................................36 3.2.1.2. Servizi per ammi nistratori ...............................................................................36 3.2.2. Profilazione degli utenti..........................................................................................36 3.2.3. Profilazione dei fornitori di informazioni ...............................................................37 3.2.4. Metadati caratterizzanti...........................................................................................37 3.2.5. Indicizzazione, trattamento e reperimento di contenuti musicali ...........................37 3.3. Tecnologie di riferimento ..............................................................................................38 3.3.1. Metodiche standard dei procedimenti di digitalizzazione ......................................38 3.3.1.1. Audio ...............................................................................................................38 3.3.1.1.1. Nastri magnetici........................................................................................39 3.3.1.1.2. Supporti vinilici ........................................................................................39 3.3.1.1.3. Altri supporti.............................................................................................40 3.3.1.1.4. Riversamenti nel dominio digitale............................................................40 3.3.1.2. Immagini ..........................................................................................................40 3.3.1.2.1. Manoscritti, diapositive, immagini e fotografie stampate ........................41 3.3.1.2.2. Riversamenti nel dominio digitale............................................................42 3.3.1.3 Video.................................................................................................................42 3.3.1.3.1. Pellicole e supporti magnetici...................................................................43 3.3.1.3.2. Riversamenti nel dominio digitale............................................................43 3.3.2. Standard di codifica ................................................................................................44 3.3.2.1 Informazione testuale........................................................................................44 3.3.2.2. Informazione musicale simbolica....................................................................45 3.3.2.3. Informazione audio..........................................................................................46 3.3.2.4. Informazione grafica........................................................................................47 3.3.2.4.1. Scansione di manoscritti, partiture a stampa e monografie ......................47 3.3.2.4.2. Fotografie digitali e scansione di fotografie .............................................48 3.3.2.5. Informazione video..........................................................................................48 3.3.3. Standard di comunicazione e sicurezza ..................................................................49 3.3.3.1. Protocolli..........................................................................................................49 3.3.3.2. Infrastrutture di comunicazione .......................................................................50 3.3.3.3. Sicurezza dei sistemi ........................................................................................50 3.3.3.4. Backup .............................................................................................................51 3.3.4. Standard DRM ........................................................................................................52 3.3.4.1. Definizione di attori e funzioni del sistema DRM...........................................52 3.3.4.2. Organizzazione degli oggetti digitali da includere nel DRM ..........................52 3.3.4.3. Specifiche del framework DRM......................................................................53 3.3.4.4. Sistemi di pagamento .......................................................................................55 3.3.4.5. Moduli SW di front-end del framework DRM ................................................55 3.3.5. Standard di interfaccia uomo-macchina .................................................................55 3.3.5.1. Aspetti ergonomici e usabilit .........................................................................56 3.3.5.2. Aspetti di interazione .......................................................................................57

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 4 di 86

3.3.5.3. Interfacce multimediali multimodali ...............................................................58 3.3.5.4. Accessibilit e usabilit per utenti con problemi .............................................58 3.3.6. Standard di validazione e tuning delle prestazioni .................................................59 3.3.6.1. Prestazioni delle applicazioni software............................................................60 3.3.6.2. Usabilit dellinterfaccia uomo-macchina .......................................................60 3.3.6.3. Prestazioni delle infrastrutture di comunicazione............................................61 3.3.7. Qualit e prestazioni dei servizi Web .....................................................................62 3.3.7.1. La soddisfazione degli utenti ...........................................................................62 3.3.7.2. Indici di prestazione Web ................................................................................63 3.3.7.3. Problemi delle applicazioni Web legati alla rete .............................................65 4. Applicazioni software...........................................................................................................66 4.1. Database periferico standard..........................................................................................67 4.2. Applicazione standard di gestione dei dati ....................................................................67 4.3. Database centrale ...........................................................................................................67 4.4. Applicazione di interrogazione del database centrale....................................................68 4.5. Filtri ...............................................................................................................................69 5. Attuazione del progetto.........................................................................................................71 5.1. Attivit e infrastrutture nel transiente di sviluppo dei sistemi informatici ....................71 5.2. Attivit di funzionamento a regime dei sistemi informatici ..........................................72 5.3. Documentazione del progetto ........................................................................................72 5.3.1. Documentazione utente...........................................................................................73 5.3.1.1. Wizard del Portale ...........................................................................................73 5.3.2. Documentazione tecnica del team di sviluppo .......................................................73 5.4. Workplan del progetto ...................................................................................................73 5.4.1. Rilasci e validazione intermedi...............................................................................74 5.5. Piano economico del progetto........................................................................................76 5.5.1. Impatto economico per i nodi periferici .................................................................76 5.5.2. Previsioni di spesa per il nodo centrale ..................................................................77 5.5.3. Dimensionamento dello spazio su disco nel nodo centrale ....................................77 5.5.4. Progettazione, realizzazione e ottimizzazione del database centrale......................82 5.6. Fornitura di sistemi informatici hardware .....................................................................82 5.6.1. Oggetto della fornitura............................................................................................83 5.6.2. Certificazioni e requisiti tecnici richiesti ................................................................83 5.6.3. Consegna, installazione e configurazione delle apparecchiature............................84 5.6.4. Collaudo delle apparecchiature hardware...............................................................84 5.6.5. Offerta .....................................................................................................................84 5.7. Manutenzione dei sistemi informatici............................................................................85 5.7.1. Interventi in garanzia ..............................................................................................85 5.7.2. Servizi di manutenzione..........................................................................................85 5.7.3. Oneri e responsabilit .............................................................................................86

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 5 di 86

0. PREMESSA
Il presente documento ha la funzione di definire gli obiettivi e le principali caratteristiche tecniche dellarea di progetto del Ministero Beni e Attivit Culturali per la conservazione e la fruizione dei beni culturali musicali italiani, con particolare riferimento al Portale denominato Network Turistico Culturale. Il documento si articola in tre parti: quadro di riferimento; oggetto del progetto; descrizione del progetto. La prima parte descrive per sommi capi la situazione attuale, dando anche una visione sistematica delle funzioni istituzionali specifiche delle attivit di conservazione e fruizione dei beni culturali musicali. La seconda parte definisce loggetto dellarea di progetto che questo documento delinea. La terza parte definisce gli obiettivi da perseguire per realizzare quanto definito nella seconda parte, specificando: cosa deve essere realizzato; come deve essere realizzato, fino ad un livello di analisi che si articoli in: requisiti funzionali di progetto, da ritenere come caratteristiche mandatorie nellesecuzione delle attivit di progetto; indicazioni funzionali di progetto, da ritenere come raccomandazioni da considerare e interpretare efficacemente nellesecuzione delle attivit di progetto. In altre parole, ai requisiti funzionali di progetto corrisponde un solo come, alle indicazioni funzionali di progetto corrispondono diversi possibili come. La terza parte, tutta o limitatamente alle componenti specifiche, pu essere considerata come documento di specifica metodologica di base per successivi documenti di progetto nella medesima area ovvero larea della conservazione e della fruizione dei beni culturali musicali.

0.1. Terminologia gergale


nodo: unit per il trattamento digitale dellinformazione connesso a una o pi reti informatiche rete: insieme di nodi caratterizzato da specifiche architetture hardware, software e di comunicazione intranet: rete chiusa (per laccesso necessario appartenere a un insieme qualificato di nodi), in cui ogni nodo pu fungere sia da distributore che da fruitore di informazioni, distribuita logisticamente in unarea limitata (per esempio in un edificio o in un gruppo di edifici limitrofi) extranet: rete chiusa (per laccesso necessario appartenere a un insieme qualificato di nodi), in cui ogni nodo pu fungere sia da distributore che da fruitore di informazioni, distribuita logisticamente in unarea ampia (per esempio diverse citt o regioni)

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 6 di 86

Internet: rete aperta (per laccesso non necessario appartenere a un insieme qualificato di nodi), in cui ogni nodo pu fungere sia da distributore che da fruitore di informazioni, distribuita logisticamente in tutto il mondo informazione: un elemento di conoscenza che permette di rappresentare unentit (o un aspetto di unentit) astratta o concreta; esempio: il colore di un violino dato: un elemento descrittivo di uninformazione (o un aspetto di uninformazione), codificato in accordo con un modello interpretativo; esempio i numeri con cui codifico il colore di un violino metadato: un dato orientato allidentificazione, alla catalogazione e in generale - alla classificazione degli elementi descrittivi di uninformazione; per esempio il tipo di strumento musicale (il violino) teca: raccolta (o archivio o collezione) organizzata di materiali, orientata alla conservazione degli elementi che la compongono teca digitale: raccolta (o archivio o collezione) organizzata di materiali digitali, orientata alla conservazione degli elementi che la compongono teca multimediale: raccolta (o archivio o collezione) organizzata di materiali multimediali (testi letterari, audio, immagini, video), orientata alla conservazione degli elementi che la compongono teca multimediale digitale: raccolta (o archivio o collezione) organizzata di materiali multimediali (testi letterari, audio, immagini, video) digitali, orientata alla conservazione degli elementi che la compongono interfaccia multimodale: interfaccia che utilizza pi modalit di comunicazione sovrapposte o alternate per svolgere la stessa funzione o per integrarne diversi aspetti OPAC: On-line Public Access Catalog, cataloghi accessibili on-line (intranet, extranet, Internet) applicazione software: programma (o insieme di programmi) dedicato allo svolgimento di una specifica funzione di interazione uomo-macchina e/o di elaborazione dellinformazione filtro software: programma (o insieme di programmi) dedicato allestrazione di sottoinsiemi da insiemi di dati, in accordo con specifici criteri di selezione e/o raccolta; pu comprendere funzioni di (de)codifica e/o (de)cifrazione client: nodo che funge da fruitore di informazioni server: nodo che funge da distributore di informazioni Portale: servizio che opera da mediatore di informazione verso gli utenti di una rete - e in particolare di Internet - permettendo a questi di raggiungere una grande quantit delle risorse esistenti mediante un unico punto di ingresso

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 7 di 86

criptare/cifrare: codifica convenzionale segreta delle informazioni usata per precludere il tentativo di accesso non autorizzato. Il procedimento opposto, detto decriptare, pu essere effettuato da chi conosce il codice decriptare/decifrare: interpretazione e traduzione di codice criptato in un chiaro linguaggio. Rappresenta il processo inverso alla crittografia DRM: acronimo di Digital Rights Management. Sistema per la descrizione, gestione, protezione, monitoraggio ed interscambio legale di informazione digitale protetta da diritti dautore e propriet industriale TCP/IP: acronimo di Transmission Control Protocol/Internet Protocol. Protocollo di controllo della trasmissione via Internet HTTP: acronimo di Hypertext Transfer Protocol, protocollo per il comunicazione di servizi Web via Internet S-HTTP: acronimo di Secure - Hyper Text Transfer Protocol. Protocollo per la creazione di trasmissioni sicure a livello di sessione SSL: acronimo di Secure Socket Layer. Protocollo per la creazione di trasmissioni sicure a livello di trasporto TLS: acronimo di Transport Layer Security; rappresenta levoluzione di SSL ODRL: acronimo di Open Digital Rights Language, linguaggio open per la definizione di diritti digitali in un sistema DRM REL: acronimo di Rights Expression Language, sistema per la definizione di diritti digitali in un sistema DRM. ODRL un esempio di REL URI: acronimo di Uniform Resource Identifier, protocollo per il reperimento di oggetti digitalizzati UPS: gruppo di continuit per la salvaguardia dei sistemi hardware da black-out e cadute improvvise di corrente internazionalizzazione: prodotto tale da permettere di esportare/importare facilmente contenuti dal/nel prodotto in fase di localizzazione per le diverse comunit di utenti previste comunit di utenti: insieme di uno o pi paesi con lingue, religioni e culture comuni pre-restauro: restauro eseguito fisicamente sul supporto originale post-restauro: restauro eseguito nel dominio digitale

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 8 di 86

1. Q UADRO DI RIFERIMENTO
Per dare un quadro di riferimento allargomento del presente documento sono qui brevemente descritti gli elementi di base rispetto alla conservazione e fruizione di beni culturali musicali italiani. Nella prima parte sono inquadrati i progetti in corso che assumono particolare rilevanza nellarea della conservazione e della fruizione della cultura musicale italiana: il progetto Biblioteca Digitale Italiana e Network Turistico Culturale e il progetto ADM. Del primo sono caratterizzate le componenti BDI Biblioteca Digitale Italiana e NTC Network Turistico Culturale, con particolare riferimento alle relazioni con le campagne di digitalizzazione di archivi musicali italiani. Del secondo, sono caratterizzati obiettivi e funzionalit, standard e modelli di riferimento per ADM, specificit dei singoli nodi. Nella seconda parte sono caratterizzate le attivit che richiesto svolgere per ottenere il duplice obiettivo della conservazione degli archivi di beni musicali e della relativa fruizione per un grande pubblico culturale e turistico: a tal fine viene data una visione sistematica schematica delle specifiche tematiche e relative metodologie per la conservazione, la catalogazione, la digitalizzazione, linformatizzazione (metadati, indici testuali e multimediali, dati testuali e multimediali), la fruizione e linteroperabilit dei vari archivi di beni musicali italiani. E infine indicata la documentazione di riferimento che viene considerata sottesa alla trattazione del presente documento.

1.1. I progetti in corso


In ambito nazionale, gi alcuni progetti promossi dalla Pubblica Amministrazione si sono rivolti nella direzione di uno sviluppo di nuovi sistemi gestionali e produttivi di formazione della conoscenza. In particolare, in ambito Ministero per i Beni e le Attivit Culturali: il sistema SBN Musica: la procedura in ambiente personal computer per la catalogazione della musica a livello locale e lo strumento per lalimentazione in differita della base dati. I dati recuperati mediante tale software vengono infatti riversati sulla base dati Musica. LICCU concede in uso gratuito SBN Musica agli enti ed alle istituzioni che ne fanno richiesta e che assicurano linvio periodico dei loro dati allICCU. Fino ad oggi stato stipulato l'accordo per l'uso del software SBN Musica con oltre 60 biblioteche. SBN Musica gestisce una lista di riferimento con circa 100.000 nomi, le tabelle dei codici per la catalogazione SBN (codici di lingua, di paese, di natura del documento, etc.) e le liste di controllo per gli elementi specifici della catalogazione musicale (organico, forma musicale, tonalit); Il Progetto Servizio Bibliotecario Nazionale (SBN), promosso nellambito del Ministero dalla Direzione Generale per i Beni Librari e gli Istituti Culturali; il Progetto Mediateche 2000, gi avviato verso la fine degli anni novanta con lo scopo di promuovere lo sviluppo di infrastrutture polifunzionali multimediali in grado di erogare servizi di formazione avanzata e diffusione della cultura; il progetto ADM, un modello di servizio integrato per la ricerca, la consultazione e l'accesso a documenti che contengono musica notata e documenti fonici; ha come partner la Biblioteca Nazionale Marciana (Venezia), Biblioteca Nazionale Universitaria (Torino) e la Discoteca di Stato (Roma); il Progetto Biblioteca Digitale Italiana, promosso dal MBAC, allo scopo di individuare, sperimentare e proporre ad una pi larga comunit di istituzioni culturali, le linee

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 9 di 86

strategiche ed operative di sviluppo delle Biblioteche verso la gestione dei documenti digitali; il Progetto Network Turistico Culturale e la sua evoluzione; il Progetto per la digitalizzazione di 200.000 documenti fonici della Discoteca di Stato; il Progetto per la digitalizzazione del primo lotto di materiali musicali dallArchivio Storico Ricordi. e, con una vista trasversale su un pi vasto ambito della Pubblica Amministrazione, il Progetto e-government, a carattere multidisciplinare, con lobiettivo principale di colmare il digital divide tra le potenzialit offerte dallo sviluppo della Information Technology ed i servizi resi ai cittadini.

1.1.1. Il progetto Biblioteca Digitale Italiana e Network Turistico Culturale


Il progetto Biblioteca Digitale Italiana e Network Turistico Culturale si concretizza nella realizzazione di un sito (www.Internetculturale.it) che offre ai propri utenti un viaggio nella cultura italiana e nel mondo dei servizi messi a disposizione dagli operatori della cultura con informazioni di natura didattica, professionale e istituzionale, riguardanti i beni e le attivit culturali italiane. Oltre a comprendere progettazione, implementazione e aggiornamento del sito, il progetto consiste anche nel reperire dalle biblioteche le risorse digitali e tradizionali ritenute di interesse. Tramite l'OPAC SBN (Servizio Bibliotecario Nazionale) si pu anche effettuare una ricerca bibliografica, semplice o avanzata, di opere dall'inizio della stampa fino ai giorni nostri possedute negli archivi di 2300 biblioteche italiane ed appartenenti a universit, enti locali, istituzioni pubbliche e private, operanti in diversi settori disciplinari. La sezione Percorsi Culturale invece, propone percorsi di conoscenza in pi lingue con Percorsi 3D. Infine, la sezione Mostre offre 20 mostre in formato digitale complete di testi ed immagini e rassegne specifiche su alcuni degli autori pi importanti del panorama letterario italiano. Il progetto stato realizzato con il patrocinio del ministero per i Beni e le Attivit Culturali, il Dipartimento per i Beni Archivistici e Librari, la Direzione Generale per i Beni Librari e gli Istituti Culturali e l'ICCU (Istituto Centrale per il Catalogo Unico delle Biblioteche Italiane e per le Informazioni Bibliografiche). 1.1.1.1. Il Portale BDI&NTC Il Portale della Biblioteca Digitale Italiana e Network Turistico Culturale www.Internetculturale.it propone un sistema di accesso integrato alle risorse digitali e tradizionali di biblioteche, archivi ed altre istituzioni culturali italiane, promuovendo e valorizzando la conoscenza e la fruibilit del patrimonio turistico-culturale sia a livello nazionale che internazionale. Gli utenti della rete possono fruire nel Portale di un insieme di informazioni di natura didattica, professionale e istituzionale riguardanti i beni culturali italiani e le attivit cui fanno riferimento. Il Portale offre allutente, specialistico o generico che sia, la possibilit di avviare una ricerca secondo le proprie esigenze, accedendo sia alle informazioni bibliografiche sia ai contenuti digitali provenienti da diverse sorgenti informative. La versione attualmente in linea propone un primo nucleo di informazioni e di servizi messi a disposizione dal progetto. Il progetto stato promosso dalla Direzione Generale per i Beni Librari e gli Istituti Culturali (DGBLIC) del Ministero per i Beni e le Attivit Culturali e realizzato dallIstituto Centrale per il Catalogo Unico delle Biblioteche Italiane e per le Informazioni Bibliografiche (ICCU), che ha

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 10 di 86

gestito il progetto, coordinato i vari partner, implementato le nuove funzionalit e integrato i servizi del Portale con quelli gi attivi nel proprio sito. La DGBLIC tutela e valorizza il patrimonio librario nazionale attraverso le 46 Biblioteche statali, promuove la diffusione del libro e della cultura in Italia e all'estero, sostiene e vigila sugli istituti culturali quali Accademie e Fondazioni. La Direzione Generale cura inoltre la promozione della lettura e del libro all'interno del Paese e nell'ambito della Comunit internazionale e l'incentivazione economico-finanziaria del settore. LICCU, referente tecnico-scientifico della DGBLIC, istituzionalmente promuove e coordina lattivit di catalogazione e documentazione del patrimonio librario conservato nelle biblioteche pubbliche. In particolare, lICCU cura la realizzazione del Servizio Bibliotecario Nazionale (SBN), rete informatizzata di servizi nazionali, alla quale sono collegate circa 2300 biblioteche italiane per la creazione del catalogo collettivo nazionale in linea gestito dallICCU. LIstituto inoltre promuove e coordina i censimenti nazionali dei manoscritti e delle edizioni del XVI secolo posseduti dalle biblioteche in Italia. 1.1.1.2. La BDI e i progetti di digitalizzazione Nel 2001, nellambito della III Conferenza Nazionale delle biblioteche, stato ufficialmente dato il via al progetto denominato Biblioteca Digitale Italiana (BDI). Nello stesso anno stato istituito un Comitato Guida presieduto dal professor Tullio Gregory e composto da esperti del mondo bibliotecario statale e regionale, del mondo archivistico e museale, delluniversit e della ricerca per definire delle linee guida. Una delle direttrici emerse stata quella di raccordare le iniziative di livello nazionale con il contesto comunitario e internazionale. Pertanto, in linea con iniziative di altri paesi europei, il primo progetto ad essere avviato nellambito della BDI stato la scansione in formato immagine dei cataloghi delle biblioteche pubbliche italiane. LICCU in questo contesto ha avuto il duplice ruolo di ente digitalizzatore e di responsabile del monitoraggio del programma. Successivamente sono stati finanziati progetti riguardanti il patrimonio musicale, conservato presso biblioteche pubbliche statali e conservatori di musica, e la digitalizzazione delle pubblicazioni periodiche di particolare valore storico e culturale. Le biblioteche, consapevoli dellutilit per lutenza, hanno accolto con entusiasmo lavvento del digitale, dando il via a vari progetti di digitalizzazione. LICCU, inoltre, su indicazione del Comitato Guida, stato incaricato di realizzare un censimento dei progetti di digitalizzazione conclusi, o in fase di elaborazione, sia per evidenziare le attivit svolte, sia per evitare duplicazioni. Da questo riscontro emerso un grande fervore in questo ambito. Il passo successivo, in linea con altre nazioni europee, stato quello di realizzare un network a carattere turistico-culturale che potesse offrire allutenza, in modo strutturato, tutte le risorse digitali e quelle bibliografiche tradizionali di maggior spessore. 1.1.1.3. Servizi e contenuti del primo nucleo del Portale RICERCA BIBLIOGRAFICA. Tramite l'OPAC SBN (Servizio Bibliotecario Nazionale) possibile effettuare una ricerca bibliografica, semplice o avanzata, di opere dallinizio della stampa fino ai giorni nostri possedute negli archivi di 2300 biblioteche italiane ed appartenenti a universit, enti locali, istituzioni pubbliche e private, operanti in diversi settori disciplinari. Altra ricerca fattibile nei Cataloghi storici che offrono la digitalizzazione dei cataloghi a volume e a scheda di 35 biblioteche italiane. Inoltre consentito all'utente l'accesso ai Cataloghi speciali, in particolare alle basi dati Bibman e Manus per i manoscritti, e a Edit16 che, relativamente alle edizioni XVI sec., consente l'accesso ad archivi di autori, titoli, editori, marche tipografiche e il collegamento alle relative immagini digitalizzate (frontespizi, colophon, marche).

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 11 di 86

ACCESSO ALLE COLLEZIONI DIGITALI. Il repertorio delle collezioni digitali descrive i fondi digitalizzati o in corso di digitalizzazione disponibili presso biblioteche, archivi e altre istituzioni culturali in Italia. L'obiettivo quello di consentire agli utenti Internet di identificare e localizzare le collezioni digitali disponibili e, ove possibile, consultarle direttamente on-line. La ricerca di immagini e materiale digitale effettuata mediante l'utilizzo di strumenti allavanguardia in questo settore, come il sistema internazionale standard SDX per laccesso alle schede delle collezioni digitali. PERCORSI CULTURALI. Questa sezione propone suggestivi percorsi di conoscenza che, offerti in pi lingue, permettono la diffusione di fonti anche inedite, configurandosi come una vera e propria mappa geografico-culturale. Lofferta si articola in quattro moduli: Mostre, Viaggi nel testo, Itinerari turistico-culturali e Percorsi 3D: Mostre: 20 mostre in formato digitale complete di testi ed immagini, rassegne specifiche su alcuni degli autori pi importanti del panorama letterario italiano e accurate mostre fotografiche capaci di restituire atmosfere ed immagini ormai perse nel tempo; esposizioni che riassumono gli importanti progetti di promozione e valorizzazione del patrimonio culturale realizzati dalle biblioteche pubbliche statali nel corso degli anni; Viaggi nel testo: unarticolata proposta di percorsi monografici strutturati per ipertesti che illustrano la vita e lopera di importanti personalit della musica e della letteratura italiana (Verdi, Petrarca, ecc.). In questarea possibile accedere, tra laltro, a Rinascimento Virtuale percorso realizzato dalla Biblioteca Medicea Laurenziana, che illustra i risultati acquisiti e gli strumenti impiegati per la riproduzione e la decifrazione degli antichi palinsesti greci; possibile, inoltre, scaricare opere di letteratura italiana tradotte in spagnolo nellambito del progetto Un Mare di Sogni che si propone di diffondere la cultura italiana in America Latina; Itinerari turistico-culturali: una serie di itinerari che coniugano contenuti culturali ad informazioni di carattere scientifico su istituzioni, documenti, oggetti. I primi tre percorsi tematici illustrano: i luoghi di maggiore rilevanza scientifica e tecnologica del territorio toscano, le testimonianze della storia e della cultura del Piemonte e gli itinerari toscani dei viaggiatori francesi e inglesi dalla fine del XVII secolo ai primi del XIX secolo; Percorsi 3D: veri e propri viaggi tridimensionali che offrono allutente la possibilit di muoversi in ambienti virtuali, ricostruiti grazie allausilio di tecnologie allavanguardia. Il visitatore pu aggirarsi liberamente per la sala della Tribuna di Galileo, dove unesposizione degli strumenti scientifici e degli affreschi restituisce le atmosfere proprie di un periodo cruciale nella storia del pensiero scientifico, oppure ancora pu perdersi tra le musiche e la storia dellOpera di Parma, riassunte attraverso le immagini dei compositori, i libretti dopera e le locandine depoca. GESTIONE DELLA CONOSCENZA. La classificazione dei dati informativi stata realizzata mediante un sistema KM (Knowledge Management), ovvero di gestione della conoscenza. Pertanto sono stati analizzati i contenuti informativi tratti da un elevato numero di siti web, dal catalogo OPAC SBN e da documenti digitalizzati, dotati di record MAG; quindi sono state approntate 3 aree tematiche (letteraria, scientifica e musicale) con la collaborazione di singoli Centri di Eccellenza: il Dipartimento di Italianistica dellUniversit La Sapienza di Roma, l'Istituto e Museo di Storia della Scienza di Firenze, la Casa della Musica di Parma, e con lutilizzo del software Verity 5.5, attraverso unapplicazione appositamente sviluppata per il progetto.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 12 di 86

1.1.2. Il progetto ADM


L'Archivio Digitale della Musica (ADM) si propone di sperimentare e di mettere a regime un modello di servizio integrato per la ricerca, la consultazione e l'accesso a documenti che contengono musica notata, con possibilit di navigazione dal record bibliografico relativo ad una partitura alla sua immagine digitalizzata, e all'eventuale documento sonoro digitalizzato corrispondente, attraverso tecnologie di distribuzione in rete di immagini e suoni. Si intende in tal modo rispondere alle esigenze di consultazione e ricerca di un'utenza differenziata, non solamente specialistica, che va dall'appassionato di musica, allo studente di conservatorio, al musicologo. Nato nel 1997, il Progetto di un Archivio Digitale della Musica Veneta del Settecento (ADMV) vedeva originariamente la partecipazione della Biblioteca Nazionale Marciana di Venezia, con le sue fondame ntali collezioni manoscritte e a stampa di musiche settecentesche, la Biblioteca Nazionale Universitaria di Torino, in cui conservata la pi importante ed organica raccolta di musiche di Antonio Vivaldi e la Discoteca di Stato. Tale iniziativa si oggi trasformata nel progetto ADM (Archivio Digitale della Musica). ADM si propone di mettere a regime un servizio innovativo di documentazione musicale, di tipo multimediale, che - utilizzando le tecnologie di distribuzione in rete di immagini e suoni renda possibile accedere: alle descrizioni dei documenti musicali in formato testo; alle immagini digitalizzate delle partiture; alle corrispondenti registrazioni sonore. Questo nuovo servizio, disponibile in rete, punta a rispondere alle esigenze di consultazione e ricerca di fasce di utenza differenziate, dallo specialista musicologo all'esecutore delle musiche, dallo studente di conservatorio al semplice appassionato. Particolare cura quindi posta nella progettazione di interfacce differenziate di ricerca e degli strumenti di navigazione fra i vari tipi di documenti componenti l'archivio. Il progetto ha grande rilevanza dal punto di vista scientifico e culturale, per le sue finalit di fruizione pubblica di un patrimonio di eccezionale importanza e, ad un tempo, di tutela di materiali rari e soggetti ad usura, per i contenuti di innovazione tecnologica, per la coerenza con le iniziative internazionali sulle biblioteche digitali. Il gruppo di lavoro ADM ritiene che il progetto possa pertanto costituire un modello da estendere ad altre istituzioni culturali o a collezioni di documenti di diverso tipo. 1.1.2.1. Obiettivi e funzionalit di ADM Il progetto ADM, sotto il nome di ADMV, inizialmente prevedeva l'integrazione funzionale di alcune basi di dati locali, e in particolare: quella della Biblioteca Nazionale Universitaria di Torino, che avrebbe proceduto alla catalogazione ed alla scansione digitale del proprio fondo di partiture - autografe e non - di Antonio Vivaldi, la collezione pi ricca ed organica esistente (27 volumi per un totale di 7786 carte); della biblioteca nazionale marciana, che tratter in maniera analoga le partiture manoscritte di Alessandro e Benedetto Marcello (65 volumi); la base di dati della Discoteca di Stato, che avrebbe digitalizzato e reso disponibili in rete un certo numero di esecuzioni delle musiche degli autori citati. Ovviamente si trattava di una parte piccola, ma significativa dell'universo della musica veneta, di cui il progetto intendeva costituire solo un primo nucleo, in vista di ulteriori sviluppi e dell'adesione di nuovi partner. Secondo le specifiche di ADMV, l'utente, locale o remoto, pu accedere tramite un normale browser di rete con protocollo HTTP al web server ADMV. Questultimo ospita il sito ADMV, con

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 13 di 86

tutte le informazioni sui servizi previsti, e costituisce il punto di partenza per navigare verso gli OPAC locali (Biblioteca Nazionale Marciana, Biblioteca Nazionale Universitaria di Torino, Discoteca di Stato) contenenti i dati di bibliografia musicale. E inoltre possibile condurre la ricerca simultanea sugli OPAC locali tramite un client z39.50. Non esiste, quindi, una base dati ADMV, se non come insieme virtuale di archivi locali, secondo un modello distribuito. L'esito della ricerca un record bibliografico (ad es. la descrizione di una partitura musicale), a partire dal quale possibile visualizzare l'immagine della partitura e delle sue parti componenti. Qualora si voglia accedere al documento sonoro, la navigazione porta alla visualizzazione dei record bibliografici relativi ai dischi o nastri che contengono le esecuzioni musicali e di qui, individuata l'esecuzione di interesse, all'ascolto del documento sonoro digitalizzato. stata prevista anche una ricerca per incipit musicale, suonato su tastiera MIDI, che permette l'individuazione del record bibliografico del documento sonoro e il conseguente ascolto. 1.1.2.2. Standard e modelli di riferimento per ADM Argomento centrale per ADMV prima e per ADM poi luso corretto e coerente degli standard, sia di carattere tecnologico (dettati sostanzialmente dal mercato) sia di carattere funzionale. Fra questi ultimi, possibile operare unulteriore distinzione tra: standard relativi ai record bibliografici; standard relativi agli oggetti digitali. Per quanto riguarda i primi, il progetto prevede l'adozione di UNIMARC, nel formato di alimentazione dell'OPAC di indice SBN, per le varie tipologie di materiali. A questo proposito sono state concordate con ICCU alcune integrazioni alla griglia, al fine di gestire i codici di genere musicale, il codice di riproduzione su microforma, i collegamenti alla descrizione bibliografica del libretto e/o del documento sonoro corrispondente ad una partitura, e i collegamenti con gli oggetti digitali. La corretta formalizzazione del collegamento del record bibliografico con l'oggetto digitale consente di gestire in modo efficace le fasi di esportazione del record dall'applicativo gestionale e di importazione nell'applicativo OPAC, garantendo l'operativit delle funzioni di navigazione dall'OPAC verso la base dati degli oggetti digitali. Per quanto riguarda gli oggetti digitali, il processo di definizione di standard di natura funzionale non ancora giunto ad esiti ben definiti, come si pu evincere dall'esame dei maggiori progetti internazionali. Il gruppo ADM ha lavorato alla definizione di un certo numero di metadati, intesi come insiemi di informazioni relative agli oggetti digitali, funzionali soprattutto all'uso che di tali oggetti verr fatto sia dagli utenti sia dallo staff della biblioteca. Nell'individuazione dei metadati necessari, le linee guida rispondono principi di economia e di non ridondanza, al fine di facilitare la successiva gestione dei metadati; si inoltre scelto esplicitamente di ridurre al minimo i dati di natura descrittiva. Esigenze di tale natura devono essere soddisfatte a livello di record bibliografici. Il progetto ADM si occupato anche del processo di digitalizzazione del materiale originario, delineando tre fasi operative: Acquisizione degli oggetti digitali; Archiviazione permanente degli oggetti digitali; Gestione degli oggetti digitali (per l'accesso, la conservazione, ...). Il software di gestione del processo in grado, per ciascuna di queste fasi, di acquisire e mantenere i relativi metadati (es. indirizzi univoci di rete, numeri identificativi del record bibliografico da cui parte il collegamento, tipo e formato del file, fattore di compressione, tipo di apparato e software di scansione, data delle operazioni, condizioni di fruibilit dell'oggetto). Per quanto riguarda la digitalizzazione del suono, il modello di riferimento costituito dal progetto di audiovideoteca digitale della RAI, ritenuto particolarmente interessante sia per gli

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 14 di 86

standard adottati che per le procedure organizzative molto rigorose usate nelle linee di riversamento. Dal punto di vista delle immagini, nelle campagne di digitalizzazione di partiture presso la Biblioteca Marciana di Venezia, sono stati prodotti TIFF a 600 dpi, JPEG a 300 dpi e JPEG a 72 dpi, tutti in forma to 24 bit RGB. 1.1.2.3. Caratteristiche salienti dei nodi ADM Da una ricerca condotta sugli attuali nodi ADM, sono emerse alcune caratteristiche comuni e determinati tratti distintivi gi allinterno del ristretto novero dei centri coinvolti. Un primo aspetto indagato riguarda i contenuti culturali delle teche interpellate: la Discoteca di Stato dispone di audio, video e immagini, con una chiara vocazione alla multimedialit; la Biblioteca Marciana di Venezia condivide prevalentemente immagini di partiture, ossia partiture manoscritte digitalizzate. Per un ipotetico nodo si delineano dunque scenari molto eterogenei riguardo i contenuti culturali: audio, partiture, immagini, video, testi (in formato analogico, originariamente digitale o risultato di una campagna di digitalizzazione). Anche la composizione percentuale dei contenuti culturali tra nodo e nodo pu risultare estremamente varia: la Discoteca di Stato ad esempio privilegia i contenuti audio-video, mentre la Biblioteca Marciana le partiture e le relative scansioni. Le tipologie di supporti presenti nelle teche rispecchiano leterogeneit di cui si scritto pocanzi: dalle monografie alle partiture, dallaudio (cilindri di cera, lacche, 78gg, 45gg, 33gg, nastri open-reel, musicassette, CD-Audio, DAT) al video (VHS, Betacam SP, U-MATIC, DV DVCAM, DVD video). E necessario inoltre prevedere la possibilit di supporti atipici (in quanto non ancora emersi), come nel caso delle piante di scena o delle scenografie di un teatro dopera. In un contesto tanto variegato, non semplice effettuare delle stime sulla consistenza numerica per ciascuna tipologia di supporto. Per questo motivo, il presente documento conterr valutazioni parametrizzate per le risorse (spazio su disco, velocit di trasmissione in rete, costi economici,). Si pu comunque ipotizzare che ciascuna teca metta in condivisione un numero di supporti dellordine delle migliaia per ciascuna tipologia. Alcuni standard ancora recenti, quali il DVD video, sono ancora poco presenti nelle teche (ordine delle decine o delle centinaia), ma avranno un tasso di crescita molto elevato nellimmediato futuro. Viceversa, altre tipologie di supporto (quali i vinili) risultano tecnologicamente superate, e quindi il loro numero rimarr relativamente stabile. A questo proposito, comunque necessario tenere conto delle acquisizioni di materiale di particolare valore o delle donazioni. Nel dimensionamento delle risorse per la realizzazione di un sistema, fondamentale tener conto non solo dellattuale consistenza numerica dei supporti presenti, ma anche dei tassi di crescita stimati. Per quanto riguarda le campagne di digitalizzazione nei nodi aderenti ad ADM, la situazione in continua evoluzione: presso la Discoteca di Stato sono attualmente disponibili circa 2.500 brani audio per la consultazione in rete (Intranet a media qualit, Internet a qualit ridotta limitata ai primi 30), e si prevede di realizzare circa 20000 brani nel corso del prossimo anno; presso la Biblioteca Marciana si conclusa la prima campagna di scansione ed in corso il popolamento dellOPAC e della teca digitale. Un altro aspetto inerente la tipologia di supporti e la loro quantit riguarda larticolazione dei supporti stessi in originali, copie di servizio e riversamenti in digitale degli originali. La tipica situazione in ADM la creazione di una copia di backup dei riversamenti in digitale. Solitamente, in assenza di oggetti digitali non esiste copia di servizio. Lo stato dellarte differisce da quella che potrebbe essere la situazione futura, con numerose copie del materiale originale a disposizione per i prestiti, come gi auspicato da numerose teche non appartenenti a ADM. Prestando attenzione ai metadati descrittivi e amministrativo/gestionali, gli standard ADM coincidono in generale con le indicazioni ICCU.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 15 di 86

Standard di catalogazione: ISBD (PM), regole di descrizione dei manoscritti musicali, Dublin Core (http://dublincore.org/); Standard di codifica dei record catalografici: UNIMARC (http://www.ifla.org/VI/3/p1996-1/sec-uni.htm) e relativi update; Standard per la gestione degli oggetti digitali: MAG 1.5 (http://www.iccu.sbn.it/schemag.htm), NISO (implementato: http://www.niso.org/pdfs/DataDict.pdf; versione corrente: http://www.niso.org/standards/resources/Z39_87_trial_use.pdf), entrambi in formato XML. Per i metadati stato adottato lo standard MAG emanato dal Gruppo italiano di studio sui Metadati Amministrativi e Gestionali coordinato dallICCU. La versione pubblicata la 1.5, ma presto sar resa disponibile la versione 2.0 che comprende anche le sezioni audio e video, e che rappresenta il riferimento in ambito ADM. Gli standard di catalogazione adottati sono la Guida SBN per le intestazioni, le tabelle descrittive (datazione, nazionalit, lingua, ecc.), gli ISBD(NBM) per la parte descrittiva e la presentazione dei dati, il formato UNIMARC per le tabelle codificate. Questi standard sono stati scelti perch indicati dallICCU come riferimento per la catalogazione e i metadati. In particolare, alla Biblioteca Marciana vengono adottati metadati descrittivi (record catalografici) delle partiture manoscritte originali, e metadati amministrativi e gestionali (in formato XML) degli oggetti digitali. Invece, presso la Discoteca di Stato, i riversamenti conservativi su supporto digitale non contengono metadati in formato numerico ma delle brevi schede tecniche che descrivono gli strumenti utilizzati per il riversamento e le caratteristiche del supporto originale di provenienza. Le informazioni relative ai supporti sono rilevate per fini conservativi e riguardano la tipologia e la produzione dei supporti (per i nastri analogici marca, tipo e numero della partita, per i dischi casa discografica e matricola del disco, ecc.). Le informazioni associate ai contenuti riguardano lo standard di registrazione, limmagine stereofonica, data e luogo di registrazione degli originali. Considerando gli standard di codifica dellinformazione multimediale, le teche ADM propongono il broadcast wave 24bit/48KHz (con lipotesi di digitalizzate nel prossimo futuro a 96 KHz), mentre per lascolto in rete locale si adotta la codifica MP3 con compressione a 256 Kbps 44.100 stereo, e per la consultazione via Internet la codifica MP3 con compressione a 32 Kbps 22050 Hz con file tagliato a 30. Le immagini vengono attualmente digitalizzate in formato TIFF a 600 dpi, JPEG a 300 dpi e JPEG a 72 dpi, a seconda delle esigenze qualitative. Per quanto riguarda il video, non stato ancora stabilito uno standard di riferimento. Gli standard proposti nel presente capitolato, in buona parte coincidenti con quelli concordati tra nodi ADM, verranno affrontati nel corso del prossimo capitolo.

1.2. Caratterizzazione delle attivit per la conservazione e la fruizione dei beni musicali
Questo paragrafo traccia una visione delle funzioni istituzionali specifiche, caratterizzanti le attivit di conservazione e fruizione dei beni culturali musicali.

1.2.1. Conservazione
Attivit volte al mantenimento dei beni culturali nelle condizioni originali al momento dellacquisizione.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 16 di 86

Principali aspetti considerati: logistici; ambientali: temperatura; umidit; qualit dellaria; stato di conservazione dei beni culturali: analisi; diagnosi; restauro dei materiali (nel caso di beni informatizzati, restauro dei supporti informativi).

1.2.2. Catalogazione
Attivit volte alla raccolta e trascrizione su opportune schede cartacee e/o informatiche di informazioni descrittive dei beni culturali conservati. Tali informazioni si riferiscono in parte a modalit descrittive standardizzate e in parte a modalit descrittive specifiche della singola teca.

1.2.3. Digitalizzazione
Attivit volte al trasferimento dellinformazione dal dominio dei beni culturali originali alla rappresentazione in digitale. In taluni casi, consente la conservazione e la riproduzione fedele del bene culturale originale (suoni, immagini, video); in altri, consente solo una rappresentazione multimediale di un bene culturale, che non pu essere n conservato n riprodotto pienamente nel dominio digitale (si pensi ad un oggetto materiale, per esempio, come una sedia, un costume, una parrucca, una scenografia o altro).

1.2.4. Informatizzazione
Attivit volte allintegrazione di dati digitali derivati dalla digitalizzazione di beni culturali in ambienti informatici (tipicamente e principalmente: database e web). Nel caso di attivit volte a rendere fruibili i beni culturali digitalizzati, possono essere considerate attivit di restauro dei contenuti informativi specifiche per il tipo di fruizione (tipo di media, condizione di fruizione, etc.) di volta in volta definito. E qui opportuno rammentare che un bene culturale digitale testuale e/o multimediale (testo, audio, immagine, video) ed un bene immateriale: codificabile; conservabile; trasmissibile; riproducibile; cedibile. Il prodotto culturale digitale acquista aspetti di materialit per la conservazione (supporti informativi), per la trasmissione (reti) e in generale per la riproduzione e le cessione. Elementi immateriali: metadati, dati, informazioni, ontologie; simbolici (codici testuali e non); subsimbolici (segnali).

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 17 di 86

Elementi materiali: canali mediali temporali (memorie, supporti informativi); spaziali (canali di trasmissione, reti). Linformatizzazione di beni culturali deve considerare tanto gli elementi informa tivi immateriali quanto gli elementi spazio-temporali materiali. Di particolare rilevanza la distinzione tra informazione e dati. Si intende per informazione lentit da rappresentare o rappresentata in digitale, mentre si intende per dati la codifica in una certa forma dellinformazione stessa. Perci sono possibile vari insiemi di dati in corrispondenza con la medesima informazione. Per esempio, dato un brano musicale nella sua forma audio esistono svariate codifiche corrispondenti (vari formati, vari livelli di qualit, varia configurazione dei canali audio, etc.). 1.2.4.1. Metadati Sono costituiti dai seguenti elementi informativi simbolici: elementi descrittivi derivati dalla catalogazione; elementi descrittivi di caratteristiche; dei beni culturali originali; dei supporti informativi prodotti mediante digitalizzazione; dei procedimenti di digitalizzazione e di eventuale restauro dei supporti informativi; codici di identificazione dei beni culturali originali; codici di identificazione dei supporti informativi prodotti mediante digitalizzazione; elementi descrittivi di aspetti logistici; elementi descrittivi di aspetti anagrafici; altri elementi descrittivi. Ognuna delle voci qui sopra elencate opportuno faccia riferimento a uno standard comunemente recepito. 1.2.4.2. Indici Sono costituiti da elementi informativi finalizzati allaccesso ai dati secondo vari criteri. Permettono di costruire tabelle per accedere rapidamente ai dati 1.2.4.2.1. Testuali Sono indici costituiti da caratteri alfanumerici per accedere a metadati e/o beni (o parti di beni) culturali testuali o multimediali. Per esempio il nome di un artista, di un editore o il modello di un nastro magnetico o una data o altro ancora, elementi che consentono laccesso tanto alle informazioni dei cataloghi tradizionali quanto ai file degli archivi multimediali (senza peraltro consentire alcun accesso direttamente allinterno degli stessi). 1.2.4.2.2. Multimediali Sono indici per accedere ai contenuti di beni (o parti di beni) culturali multimediali (anche accesso direttamente allinterno degli stessi). Per esempio una immagine o un frammento audio o un frammento di partitura o un frammento di video possono permettere di accedere a immagini, suoni, partiture rispettivamente in accordo con un criterio di uguaglianza o pi tipicamente di similarit tra lindice e la porzione di contenuto multimediale individuata.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 18 di 86

1.2.4.3. Dati Sono i contenuti dei beni culturali digitalizzati. Possono a loro volta essere testuali (per esempio sequenze di caratteri alfanumerici sotto forma di file di dati ASCII o UNICODE) o multimediali (per esempio suoni sotto forma di file di dati WAV o MP3, o immagini sotto forma di file JPEG o TIFF, o video sotto forma di file MPEG). E tipico avere dati in diversi formati caratteristici rispetto ai diversi servizi in corrispondenza con il medesimo contenuto informativo (per esempio i file JPEG o TIFF per le pagine di partitura in formato grafico per il download sul web o per la conservazione in archivio, rispettivamente).

1.2.5. Fruizione
Attivit volte a rendere disponibili per la fruizione i beni culturali in originale e/o tramite i beni informatizzati. Nel primo caso si tratta delle tradizionali forme di fruizione. Nel secondo caso possono essere considerate varie possibilit: fruizione on line mediante streaming (distribuzione della riproduzione dei dati); fruizione on line mediante download (distribuzione dei file di dati); fruizione mediante supporti informativi (CD, DVD, altro); fruizione presso stazioni informatiche di accesso per consultazione dei cataloghi e dei relativi contenuti testuali e multimediali.

1.2.6. Interoperabilit
Attivit volte alla fruizione integrata di servizi e/o dati propri di archivi, applicazioni software, reti vari. Il conseguimento dellinteroperabilit di servizi e dati elemento essenziale per il conseguimento di risultati ottimali a parit di investimento. Il conseguimento dellinteroperabilit legato alladozione degli standard (v. Paragrafo 3.3) di: codifica; comunicazione; sicurezza; DRM; interfaccia uomo-macchina; validazione e tuning delle prestazioni. Linteroperabilit consente di usare metadati, indici e dati prodotti presso una teca tanto presso unaltra teca quanto per la fruizione in punti di consultazione o tramite un Portale o pagine web. Linteroperabilit dei servizi (per esempio luso di un servizio del Portale allinterno di unapplicazione software di una teca o viceversa) richiede una progettazione unitaria e una realizzazione coerente dellinsieme di applicazioni software di interesse. Sembra pertanto non realistico allo stato attuale dei sistemi sinora sviluppati pensare a questa possibilit a breve e forse anche a medio periodo. E per una possibilit a cui tendere con opportune attenzioni di metodo nella progettazione e nella attuazione dei progetti da qui in avanti.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 19 di 86

1.3. Documentazione di riferimento


1. Advanced Computer System Elettra 2.0 - Audio Transcription System - Overview 2. Autorit per lInformatica nella Pubblica Amministrazione, Deliberazione 30 luglio 1998 - Regole tecniche per luso di supporti ottici, Art. 2, comma 15, della legge 24 dicembre 1993, n. 537, G.U. 19 agosto 1998, n. 192 http://www.cnipa.gov.it/site/_contentfiles/00128200/128263_CR%2018_1998.pdf 3. DECRETO LEGISLATIVO recante il "CODICE DEI BENI CULTURALI E DEL PAESAGGIO", ai sensi dell'articolo 10 della legge 6 luglio 2002, n. 137. 4. Dublin Core Metadata Initiative (DCMI) DCMI Metadata Terms http://dublincore.org/documents/dcmi-terms/ 5. International Association of Music Libraries, Rpertoire International des Sources Musicales Plaine & Easie Code http://www.cilea.it/music/lezioni/plaineeasycode.htm 6. International Federation of Library Associations and Institutions (IFLANET) IFLA UNIMARC Core Activity http://www.ifla.org/VI/8/up.htm 7. ISO/IEC DIS 9126-1 Information Technology. Software product quality: quality model. http://www.iso.org 8. ISO 9241-10 Ergonomic requirements for office work with visual display terminals (VDTs): Dialogues principles http://www.iso.org 9. ISO 9241-11 Ergonomic requirements for office work with visual display terminals (VDTs): Guidance on usability http://www.iso.org 10. Istituto Centrale per il Catalogo Unico delle biblioteche italiane e per le informazioni bibliografiche Guida a una descrizione catalografica uniforme dei manoscritti musicali http://www.iccu.sbn.it/gdmm.pdf 11. Ministero per i Beni e le Attivit Culturali, Biblioteca Palatina di Parma Progetto DI.MU.SE. http://www.bibpal.unipr.it

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 20 di 86

12. Ministero per i Beni e le Attivit Culturali, Istituto Centrale per il Catalogo Unico delle Biblioteche italiane e per le Informazioni Bibliografiche Capitolato tecnico per la Digitalizzazione dei cataloghi manoscritti, a volume e a scheda, posseduti dalle biblioteche pubbliche italiane http://www.iccu.sbn.it/PDF/capidati_digicat.pdf 13. Ministero per i Beni e le Attivit Culturali, Istituto Centrale per il Catalogo Unico delle Biblioteche italiane e per le Informazioni Bibliografiche Capitolato tecnico per la Digitalizzazione di manoscritti dei fondi musicali di Biblioteche italiane http://www.iccu.sbn.it/PDF/Capimusica.pdf 14. Ministero per i Beni e le Attivit Culturali, Istituto Centrale per il Catalogo Unico delle Biblioteche italiane e per le Informazioni Bibliografiche La Biblioteca Digitale Italiana ed il Network Turistico Culturale 15. Ministero per i Beni e le Attivit Culturali, Istituto Centrale per il Catalogo Unico delle Biblioteche Italiane e per le Informazioni Bibliografiche Mappatura Dublin Core / UNIMARC http://www.iccu.sbn.it/dubluni.html 16. MPEG - Motion Picture Expert Group http://www.chiariglione.org/mpeg/ 17. Progetto ADMV Sistema di Digitalizzazione e Gestione dei Documenti Sonori della Discoteca di Stato (SDGDS) - User Requirements Document 18. Raiss, Gianluigi Progettazione ed usabilit dei sistemi accessibili in "Informazioni, anno II - nuova serie n. 5 settembre-ottobre 2000", Autorit per lInformatica nella Pubblica Amministrazione http://www.cnipa.gov.it/site/_contentfiles/00463300/463379_5_2000.pdf 19. UNESCO/ICA/IFLA Guidelines for digitization projects for collection and holdings in the public domain, particularly those held by libraries and archives http://www.ifla.org/VII/s19/pubs/digit-guide.pdf 20. World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) http://www.w3.org/WAI/

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 21 di 86

2. O GGETTO DEL PROGETT O


Loggetto del presente documento la definizione delle attivit di progetto dellarea di progetto del Ministero Beni e Attivit Culturali per la conservazione e la fruizione dei beni culturali musicali italiani, caratterizzandone gli obiettivi e le principali caratteristiche tecniche, con particolare riferimento al Portale denominato Network Turistico Culturale. Due i filoni principali: la conservazione dellinformazione e dei supporti informativi musicali: catalogazione dei supporti dellinformazione musicale; conservazione e restauro (ove necessario) dei supporti dellinformazione musicale; comunicazione e condivisione dei beni musicali con le teche convenzionate; la fruizione dellinformazione e dei supporti informativi musicali: disponibilit di informazione musicale mediante web, supporti informativi, accesso fisico alle teche e a mostre; restauro di informazione musicale finalizzato allo specifico modo di fruire; strumenti di navigazione e ricerca specifici per linformazione musicale integrati con gli strumenti generali. Alcune considerazioni generali sono preliminari alla definizione degli obiettivi da perseguire: il Portale rivolto allutente generico, italiano o straniero; un servizio web; la Rete della Musica Italiana rivolta alloperatore professionale, o attivo presso uno dei nodi facenti parte della rete stessa o studioso di ente accettato; una extranet eterogenea i cui livelli di integrazione possono seguire una logica di crescita dinamica; la Rete della Musica Italiana il principale - ma non esclusivo - Fornitore di informazioni musicali del Portale.

2.1. Obiettivi proposti


Le attivit di progetto descritte in questo documento si propongono di definire strategie e individuare tecnologie per: massimizzare i risultati globali; minimizzare i costi; facilitare lingresso di nuovi nodi e valorizzare il Portale del ministero; in particolare, fornire funzionalit e prestazioni affidabili, efficienti ed omogenee al visitatore del Portale; facilitare lingresso di nuovi nodi e valorizzare la Rete della Musica Italiana, a partire dalla sua forma attuale di rete ADM, da allargare, anche con modalit eterogenee; in particolare, fornire funzionalit (anche avanzate) e prestazioni affidabili ed efficienti alloperatore professionale che accede alla rete; il perseguimento degli obiettivi complessivi suggerisce di mantenere indipendenti il sistema ADM e il Portale. Al fine di conseguire gli obiettivi qui esposti, sono considerate linee guida da seguire: analisi, integrazione e revisione delle tipologie di standard da adottare e delle architetture da implementare: attivit basate su unanalisi sistematica e comparativa tra tutti i metadati finora messi in campo nei vari ambiti dei progetti in corso, finalizzata allintegrazione "globale", anche al fine di identificare - alla luce della eterogeneit delle varie teche quelle intersezioni "allargate" che sono funzionali ai servizi per il Portale e per i nodi della

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 22 di 86

Rete della Musica Italiana, e particolarmente per i nodi della rete ADM (caratterizzando i diversi casi in modo specificamente distinto); valutazione dei contenuti da erogare nei diversi servizi anche rispetto alle diverse profilazioni di utenti, preservando l'identit delle singole teche afferenti ai servizi sul Portale; sicurezza e DRM, in base a criteri di: riservatezza; opportunit; valore economico.

2.2. Scenario di integrazione tra i progetti attivi e i potenziali nuovi sviluppi


I progetti ADM e Biblioteca Digitale Italiana e Network Turistico Culturale sono nati in tempi diversi con obiettivi diversi. In entrambi gli ambiti si deve perseguire un triplice obiettivo: consolidamento delle funzionalit attuali; ampliamento delle funzionalit e della base di conoscenza; standardizzazione di: metadati; procedimenti di digitalizzazione; codifiche digitali di dati multimediali; applicazioni software di base; essenzialit delle infrastrutture tecnologiche, al fine di ottimizzare le sinergie tra i progetti limitandone i costi di gestione. A tal fine si configura uno scenario di integrazione tra i progetti che ne mantiene lautonomia pur rafforzandone i meccanismi di erogazione di servizi sia nellambito professionale della musica che in quello pi generale del Portale. Larchitettura di massima di questo scenario descritta nel paragrafo seguente. Le strategie generali sono basate sui seguenti criteri guida: flessibilit massima rispetto allingresso di nuovi nodi nellambito professionale della musica ovvero i fornitori di informazioni e gli utenti potenzialmente interessati nella condivisione di contenuti culturali musicali; alimentazione della base di conoscenza del Portale sicura e non onerosa da parte dei fornitori di contenuti culturali musicali; erogazione sicura ed efficiente sul Portale di servizi inerenti contenuti culturali musicali, anche nelle forme multimediali consentite dalle tecnologie correnti, orientati a unutenza tanto nazionale quanto internazionale.

2.3. Architettura di massima


I contenuti del presente paragrafo fanno riferimento alla figura seguente:

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 23 di 86

Rete ADM
Postazioni Extranet
OPAC OPAC

Extranet
Interfaccia ADM-Extranet

Rete ReMI
(evoluzione di ADM)

Teca digitale

Data Server

Teca digitale

Data Server

Nodo ADM

Nodo ADM

Biblioteca Digitale Italiana Network Turistico Culturale (BDI&NTC)


OPAC OPAC generale

OPAC

Filtro ADM-BDI&NTC
Teca digitale

Data Server

Teca digitale

Data Server

Filtro ReMI-Portale

Teca digitale generale

Data Server

Nodo ADM

Interfaccia ReMI-Portale

Portale BDI&NTC

Filtri custom (non ADM)


OPAC

Interfaccia Internet
Teca digitale

Data Server
OPAC

Internet
Server

Nodo non ADM

Nodo non ADM

Postazioni utente Postazioni utente

Server

Figura 1. Architettura di massima del progetto

Ciascun oggetto presente in tale figura verr opportunamente illustrato e commentato, al fine di fornire una chiara visione ad alto livello del sistema da implementare nella sua globalit. Le principali entit coinvolte sono: la rete ADM (gi esistente), il sistema BDI&NTC (gi esistente, da ampliare) e la rete ReMI (evidenziata in grigio, non ancora realizzata).

2.3.1. Rete ADM


La rete ADM costituita da nodi che aderiscono agli standard, ai protocolli e alle indicazioni propri dellArchivio Digitale della Musica. Ciascun nodo ADM costituito da un OPAC e da una teca digitale. Attualmente, la rete ADM gi in essere e contiene tre nodi attivi (Biblioteca Marciana di Venezia, Biblioteca Nazionale di Torino e Discoteca di Stato). E inoltre previsto che lICCU rappresenti un quarto nodo ADM, al fine di ospitare i contenuti culturali e gli OPAC delle entit tecnologicamente non predisposte ad entrare in rete. La rete ADM si interfaccia con lesterno tramite un Portale dedicato, consultabile allindirizzo http://193.206.197.121:8080/admv/index.jsp. La cooperazione tra nodi ADM consiste nella (eventuale) risoluzione della stessa query di ricerca sui diversi indirizzi IP, corrispondenti ai diversi nodi partecipanti. Il futuro di ADM, prospettato anche dal presente capitolato, un suo allargamento tramite il coinvolgimento di altre entit interessate. Gli standard e i protocolli imposti da ADM ai partecipanti sono validi e consolidati, pertanto laderenza alle indicazioni ADM non costituisce un limite alla partecipazione al progetto ReMI. Al contrario, ADM viene preso a modello per il progetto ReMI, che ne vuole rappresentare la naturale evoluzione.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 24 di 86

2.3.2. Extranet ADM


La Extranet mostrata in Figura 1 si allaccia alla rete ADM tramite uninterfaccia ADMExtranet. Il presente capitolato non si occupa di definire la Extranet dal punto di vista operativo e funzionale. Ci si limita ad indicare lo scopo generico della Extrane t, ossia offrire contenuti culturali molto specifici e di alta qualit a unutenza altamente specializzata nel campo musicale e/o musicologico. Agli estremi opposti, le due interpretazioni della Extranet sono: laccesso alla struttura ADM solo da postazioni interne ai nodi (una Intranet altamente specializzata e qualificata); laccesso alla struttura ADM da parte di utente (potenzialmente) generici via Internet, come attualmente avviene tramite lindirizzo sopra riportato. La scelta di cosa la Extranet debba rappresentare non oggetto del presente capitolato, ma riguarda piuttosto i nodi ADM. La Extranet fa comunque parte dellarchitettura globale ReMI che si vuole illustrare in questa sede.

2.3.3. Rete non ADM


I nodi coinvolti nel progetto ReMI ma non aderenti ad ADM vanno a costituire la cosiddetta rete non ADM. Non si tratta di una vera e propria rete, in quanto i suoi nodi - in generale - non dialogano reciprocamente. Essi rappresentano piuttosto delle entit isolate, che verranno a collaborare indirettamente grazie alla rete ReMI. Non va comunque esclusa a priori la possibilit che un certo numero di nodi non ADM costituisca unaltra sottorete, e che dunque tale parte della rete non ADM in realt consenta il dialogo tra i nodi aderenti. La situazione attuale non consente a nodi esterni ad ADM di mettere il proprio patrimonio culturale a disposizione di BDI&NTC, a meno di non aderire ad alcuni stringenti protocolli di gestione dellinformazione e di comunicazione. Un nodo non ADM di interesse per ReMI deve essere caratterizzato da contenuti culturali appartenenti allambito della musica e dalla presenza di un OPAC (o dal desiderio di realizzarne uno in futuro). Invece, non vincolante la disponibilit di una teca digitale. Un nodo ReMI pu restare esterno ad ADM per svariati motivi, tra cui: la non completa aderenza agli standard e ai protocolli ADM; lutilizzo di risorse hardware, software e gestionali incompatibili; la scelta politica di non condividere materiale con ADM; e cos via

2.3.4. Rete ReMI


La Rete della Musica Italiana (rete ReMI) data dallinsieme dei nodi potenzialmente interessati nella condivisione di contenuti culturali in materia musicale. Essa diventa una rete anche dal punto di vista funzionale nel momento in cui si rapporta con il sistema BDI&NTC. In altre parole, ReMI ingloba al proprio interno la rete ADM (che rete nel vero senso della parola) e la rete non ADM (costituita, come si visto, da nodi potenzialmente isolati), proponendo allesterno (ossia al sistema BDI&NTC) uninterfaccia unica. Lobiettivo omogeneizzare gli eterogenei nodi aderenti e nasconderne le differenze, in termini di protocolli adottati, di sistemi hw/sw, di prestazioni. Questo ha impatto non solo sulla interoperabilit tra Portale BDI&NTC e rete ADM estesa, ma anche sulle prestazioni che contraddistinguono il sistema complessivo. Alle considerazioni su prestazioni e soddisfazione degli utenti sar dedicato il Paragrafo 3.3.7 del presente capitolato. Come pi volte precisato, ReMI costituisce levoluzione di ADM. Perch ADM, riconosciuto come valido strumento di integrazione e condivisione dellinformazione musicale, richiede di essere

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 25 di 86

trasformato (per meglio dire: esteso) in qualcosa di diverso? Al momento, i costi di ingresso in ADM dal punto di vista delle risorse umane, hardware, software sono tali da scoraggiare ladesione da parte di ulteriori nodi. Inoltre, diffuso il timore di possibile perdita dellautonomia gestionale, amministrativa e intellettuale sul materiale ceduto a (per meglio dire: condiviso in) ADM. La soluzione proposta, consistente nel creare il sistema ReMI, dovrebbe risolvere questi inconvenienti e superare leffetto deterrente legato ad ADM. Si sottolinea, comunque, che ReMI non va ad alterare il preesistente ADM n limita la sua autonomia, rappresentando piuttosto unevoluzione che mira a coinvolgere il numero maggiore possibile di entit al momento esterne. Si evidenzia inoltre lalto valore degli standard e dei protocolli scelti in ambito ADM, e dunque uno degli obiettivi di ReMI allargare ADM portando alladesione di nuovi nodi in ADM (e di conseguenza in ReMI, secondo lo schema in Figura 1).

2.3.5. Interfaccia ReMI-Portale BDI&NTC


Laspetto caratterizzante di ReMI la presenza di uninterfaccia che omogeneizzi sotto tutti i punti di vista il sistema BDI&NTC con i nodi ADM e non. Tale interfaccia si colloca idealmente allinterno di BDI&NTC, in quanto rappresenta a tutti gli effetti un componente hw/sw legato al Portale e non alla rete ReMI. Come pi volte detto, per, la rete ReMI non lo a tutti gli effetti se non in relazione alla fruizione tramite il Portale. Linterfaccia ReMI-Portale viene alimentata dai nodi ADM e non ADM tramite un insieme di filtri. In particolare, lOPAC dellinterfaccia strutturato come gli OPAC di ADM, mentre la teca digitale ospita oggetti digitali selezionati dai singoli nodi e opportunamente degradati in qualit e in durata, da utilizzare come campionario dei contenuti digitali di alta qualit. A titolo di esempio, si cita il thumbnail a bassa qualit delle fotografie e delle scansioni, la versione tagliata a 30 dei brani musicali e la condivisione del 10% delle pagine delle monografie. E implicito che gli oggetti digitali ad alta qualit (salvo diversa decisione da parte del singolo nodo detentore) rimangano non solo di propriet del nodo stesso, ma anche fisicamente collocati nella teca digitale locale. Inoltre, il singolo nodo potrebbe scegliere di non condividere alcun materiale digitale, inviando solo metadati bibliografici. I filtri che alimentano linterfaccia ReMI-Portale sono di semplice realizzazione nel caso dei nodi ADM, in quanto si limitano ad effettuare una copia ragionata dei metadati locali, senza intervenire sui loro formati e sullorganizzazione dellinformazione. Diverso il caso degli n nodi non ADM, che potenzialmente aderiscono a n standard differenti per la catalogazione, lorganizzazione di dati e metadati e via dicendo In tal caso, sar cura del Fornitore realizzare soluzioni ad hoc per ciascun nodo. Per quanto riguarda gli oggetti digitali, in entrambi i casi i filtri effettuano operazioni di cifratura e di compressione. Una descrizione pi dettagliata del funzionamento dei filtri si trova nel Paragrafo 4.5.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 26 di 86

3. D ESCRIZIONE DEL PROGETTO


Questo capitolo dedicato a tracciare le linee evolutive dei due progetti in essere, ADM e BDI&NTC, e a definire le tecnologie di riferimento per lattuazione del presente progetto, con particolare attenzione agli standard metodologici e qualitativi da adottare.

3.1. Evoluzione del progetto Biblioteca Digitale Italiana e Network Turistico Culturale
Per una efficace fruizione del materiale musicale digitale che sar ospitato nel sistema BDI&NTC si profiler in questa parte unevoluzione del progetto stesso, con delle modifiche che possano essere il meno possibile incidenti sui servizi gi presenti, ma che consentano un loro accrescimento volto al trattamento specifico dellinformazione musicale e delle sue caratteristiche peculiari e distintive. Verr altres posta particolare enfasi allinternazionalizzazione del Portale, che consenta gi in fase di progettazione di avere ben standardizzate le procedure atte a rendere fruibile il patrimonio culturale italiano ad un numero sempre maggiore di comunit di utenti.

3.1.1. Profilazione dei servizi


Ai servizi gi presenti sul Portale BDI&NTC dovranno esserne aggiunti alcuni che siano legati maggiormente ai nuovi ambiti musicali, o comunque di interesse generale ma non previste nel progetto attuale. In particolare i servizi di ricerca saranno potenziati secondo le specifiche riportate nei paragrafi successivi. 3.1.1.1. Statistiche In diversa evidenza rispetto agli altri contenuti editoriali del Portale ci saranno delle pagine riservate alla presentazione di statistiche globali, contenenti informazioni sul patrimonio (numero di documenti, divisi per tipologia), statistiche di accesso al Portale, statistiche sulla fruizione dei contenuti (classifiche dei documenti pi consultati/acquistati, dei nodi con maggior numero di documenti consultati/acquistati, ) 3.1.1.2. Servizi di news Verr fornito un sistema RSS per il recupero automatico da parte degli utenti delle news immesse dal personale di gestione del Portale, riguardanti ad esempio nuovi eventi in programma, nuove acquisizioni di documenti, ecc. 3.1.1.3. Servizi di ricerca Sar possibile effettuare tre tipi di ricerca: semplice, di base o avanzata. Nella ricerca semplice verr presentato un unico campo da compilare, con semplicemente la possibilit di includere un numero di parole qualsiasi separate da spazi, oppure di racchiudere frasi fra doppi apici () per una ricerca esatta di frasi intere.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 27 di 86

La modalit di ricerca di base presenter i tre campi principali titolo, autore e tipologia del materiale (audio, video, immagine). La modalit di ricerca avanzata fornir una maschera completa per la ricerca in base a diversi parametri relativi ai metadati di interesse: Sottoinsieme da concordare dei metadati MAG 2.0 e UNIMARC indicati nel Paragrafo 3.1.4; Per modalit di fruizione (free, a pagamento); Per data di immissione (per cercare solo fra le novit inserite di recente). 3.1.1.4. Prospettazione dei risultati Saranno disponibili due tipi di prospettazione dei risultati di una ricerca: in forma sintetica oppure in forma analitica. Nella prospettazione sintetica dei risultati verranno visualizzati semplicemente i metadati principali dei documenti, evidenziando con lutilizzo di icone la presenza di tipi di dati multimediali associati. Nella prospettazione analitica dei risultati verranno visualizzati tutti i metadati relativi ai documenti trovati (gli utenti registrati potranno configurare il tipo di metadati visualizzati). In entrambe le tipologie di prospettazione dei risultati sar possibile unimmediata funzionalit di ricerca di documenti correlati a quelli visualizzati, con la possibilit, ad esempio, trovata una partitura del Bolero di Ravel, di ottenere linsieme di altre partiture dello stesso brano, delle esecuzioni registrate in formato audio e/o video dello stesso. Questo consentir anche agli utenti inesperti di effettuare una navigazione type-free attraverso diversi percorsi tematici concatenati. 3.1.1.5. Cronologia delle ricerche (utenti registrati) Durante la singola sessione di navigazione, lutente avr a disposizione una lista che terr traccia delle ricerche effettuate, memorizzandone i criteri, con la possibilit di effettuare nuovamente una ricerca scelta dalla lista. Il numero massimo di elementi della lista sar impostato dalla gestione del Portale. 3.1.1.6. Segnalibri per salvare le ricerche (utenti registrati) Dalla lista delle ricerche della sessione corrente lutente avr la possibilit di salvare gli elementi di suo interesse in una lista globale che verr mantenuta alle successive autenticazioni. Il numero massimo di elementi della lista sar impostato dalla gestione del Portale. 3.1.1.7. Salvataggio delle preferenze di ricerca (utenti registrati) Lutente potr salvare globalmente una serie di opzioni di ricerca avanzata, per consentire, dopo lautenticazione, di trovare gi selezionati i criteri di proprio interesse (ad esempio, un utente potr decidere di voler cercare sempre documenti di tipo video provenienti da un dato archivio, non dovendo ad ogni ingresso nel Portale reinserire queste opzioni). Lutente avr altres a disposizione una lista di profili in cui salvare le preferenze di ricerca, con un profilo da presentare di default e gli altri selezionabili attraverso una lista nella pagina di ricerca avanzata.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI 3.1.1.8. Segnalibri per salvare documenti di interesse (utenti registrati)

Pag. 28 di 86

Lutente potr mantenere dei segnalibri associati a documenti trovati in seguito a ricerche, con la possibilit di organizzarli in una struttura a cartelle. Laggiunta di segnalibri avverr direttamente dalla pagina di prospettazione dei risultati e i segnalibri saranno mantenuti ai successivi ingressi con autenticazione. 3.1.1.9. Configurazione della prospettazione analitica (utenti registrati) Lutente potr mantenere salvata la lista di metadati da visualizzare durante la prospettazione analitica dei risultati delle ricerche. Questo permetter di decidere quali metadati escludere dalla prospettazione e sar salvato alle successive autenticazioni. 3.1.1.10. Acquisti Verranno fornite le operazioni comuni di gestione carrello degli acquisti e pagamento degli stessi. Verr mantenuta una lista consultabile degli acquisti effettuati dallutente. 3.1.1.11. Messaggi dagli amministratori Lutente potr leggere i messaggi mandati dal personale di gestione contenuti, con le uniche possibilit di mantenere il messaggio o di cancellarlo. 3.1.1.12. Servizio di e-mail su novit Lutente avr la possibilit di ricevere per posta elettronica gli avvisi di presenza di news globali e/o relative ad un singolo Fornitore di informazione.

3.1.2. Profilazione degli utenti


I servizi gestiti dal Portale verranno differenziati per tipologia di utenza. Da questo punto di vista ci sono tre macro categorie: utenti Internet: utenti generici, che possono accedere sia anonimamente, sia in seguito ad una registrazione, che consenta una migliore qualit dei servizi offerti e una configurabilit degli stessi; fornitori di informazioni: un accesso speciale riservato agli stessi nodi che forniscono i materiali per la popolazione della base di dati; utenza di gestione Portale: accesso privilegiato per consentire un aggiornamento dei contenuti del Portale, statistiche di accesso riservate ed altre strumenti redazionali. Naturalmente chiaro che anche il livello di sicurezza sar dipendente dalla tipologia di accesso, considerando il livello di privilegi propri delle tre categorie. 3.1.2.1. Utente Internet Lutente generico Internet avr a disposizione due tipi di accesso: un accesso anonimo ed uno conseguente una preventiva registrazione al Portale. Anche se i contenuti e le tipologie di

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 29 di 86

interrogazione rimangono gli stessi, lutente registrato avr la possibilit di mantenere salvate delle opzioni di ricerca e di visualizzazione che verranno mantenute ai successivi accessi. La procedura di registrazione dovr essere facoltativa ma al tempo stesso fornire un valore aggiunto, consentendo da un lato una maggiore personalizzazione della navigazione da parte degli utenti, e dallaltro un maggiore controllo degli accessi da parte della gestione del Portale, e, attraverso le statistiche, di una sua migliore evoluzione. 3.1.2.2. Fornitori di informazioni Attraverso opportuni meccanismi di sicurezza (HTTPS, IP-filtering), il personale dei fornitori di informazioni pu utilizzare servizi specifici non disponibili agli utenti comuni. Una prima possibilit sar quella di inserire proposte di modifica alle pagine del Portale relative alle informazioni specifiche del nodo stesso e alle sue news. Le proposte di modifica saranno vagliate dal personale di gestione del Portale, che dopo laccettazione proceder alla pubblicazione. Unulteriore possibilit consentita al personale dei fornitori di informazioni sar quella di poter visionare senza limitazione di diritti il proprio materiale multimediale ospitato dal Portale, per verificarne la corretta fruibilit. 3.1.2.3. Utenza di gestione Portale Attraverso lutilizzo di interfacce web protette, il personale di gestione del Portale avr a disposizione alcune funzionalit riservate: gestione news globali, che saranno dinamicamente aggiunte alle pagine relative del Portale; gestione pagine relative ai singoli nodi (aggiornabili anche dietro richiesta dei nodi stessi), che saranno dinamicamente aggiunte alle pagine relative del Portale; gestione anagrafica utenti, per laggiunta/cancellazione/modifica dei dati degli utenti, per la gestione di gruppi di utenti (in base ai dati da loro inseriti in fase di registrazione), per linvio di messaggi a utenti singoli, gruppi di utenti e a tutti gli utenti; funzionalit statistiche, con statistiche pi avanzate e senza problemi di riservatezza dei contenuti rispetto a quelle visionabili dagli utenti Internet.

3.1.3. Profilazione dei fornitori di informazioni


Lentit principale fornitrice di informazioni al Portale da individuarsi nellinterfaccia ReMI-Portale, alimentata dai nodi. Lalimentazione dellinterfaccia avverr tramite una serie di filtri software sviluppati ad hoc per il recupero dei metadati (obbligatori almeno per quanto riguarda il sottoinsieme Dublin Core) e degli eventuali dati messi a disposizione. Per una descrizione pi dettagliata sul funzionamento dei filtri, si rimanda al Paragrafo 4.5, mentre i metadati caratterizzanti saranno oggetto del prossimo paragrafo.

3.1.4. Metadati caratterizzanti


Occorre prima di tutto dividere i metadati tra quelli relativi agli oggetti sottoposti a digitalizzazione e quelli relativi al materiale digitale derivato. I primi corrispondono al sottoinsieme di pertinenza dello standard UNIMARC mentre i secondi derivano dallo standard MAG 2.0.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 30 di 86

Gli standard UNIMARC e MAG individuano un insieme piuttosto vasto di metadati, includendone alcuni di scarso interesse per lutente comune del Portale. Per questo occorrer limitare il set di metadati su cui basare le ricerche avanzate e che verranno prospettati nella forma analitica dei risultati di una interrogazione, pur prevedendo il recupero di tutti i metadati compatibili con gli standard allinterno dellinterfaccia ReMI-Portale. Lelenco seguente indica il sottoinsieme minimo di metadati da prendere in considerazione per ricerche avanzate e prospettazione dei risultati; resta intesa una loro singola caratterizzazione in accordo con le codifiche UNIMARC e MAG: Incipit letterario (in formato testuale); Incipit musicale (in formato PEC e/o XML); Autore; Titolo; Forma musicale (Sonata, Preludio, Fuga, ); Tonalit; Codici identificativi (ISBN, ISRC, ); Organico; Formato delloggetto (Manoscritto, vinile, videocassetta, ); Durata; Soggetti; Lingua; Paese; Luogo di pubblicazione, registrazione, rappresentazione, ; Data di pubblicazione, registrazione, rappresentazione, ; Personaggi del cast; Localizzazione; Informazione sulle collezioni; Dimensioni dei file digitali; Informazioni sullapparecchiatura di digitalizzazione; Informazioni sul tipo di codifica dei file digitali (JPG, TIFF, MP3, ); Informazioni sulla qualit dei file digitali (dpi, numero colori, bitrate, );

3.1.5. Internazionalizzazione del Portale


Linternazionalizzazione del Portale deve avvenire seguendo tre fasi distinte: 1. una prima fase di globalizzazione; 2. una seconda fase di internazionalizzazione; 3. una terza ed ultima fase di localizzazione e traduzione. 1) Globalizzazione Nella fase di globalizzazione si devono definire tutte le attivit di progettazione e gestione del Portale su scala globale definendo le comunit di utenti a cui il Portale dovr rivolgersi; le specifiche internazionali del prodotto, identificando le esigenze di ciascuna comunit di utenti di destinazione. Tali specifiche devono essere definite in funzione del contesto socio-culturale delle comunit selezionate; per esempio, la scelta della comunit di utenti indiane deve prevedere tra le specifiche internazionali, un opportuno uso della figura della mucca in quanto considerato animale sacro. 2) Internazionalizzazione

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 31 di 86

Durante la fase di internazionalizzazione, si progetta ed ingegnerizza il Portale affinch: il Portale soddisfi, per ogni comunit di utenti, le specifiche internazionali definite nella fase precedente; la gestione del Portale multilingue sia efficiente sotto il profilo del processo di localizzazione e sotto il profilo economico. Vanno perci identificati ed elencati tutti i contenuti testuali e multimediali da sottoporre alle fasi di localizzazione e traduzione, e va scelta l'architettura software che permette di operare facilmente sui contenuti al fine della localizzazione. In questa fase si adottano accorgimenti per una ottimale localizzazione del software e dei media, ad esempio: una chiara separazione tra le parti di codice e quelle da quelle di interfaccia utente; sistemi di sviluppo basati sullo standard Unicode per la gestione del testo in qualsiasi lingua; creazione di immagini con un formato multilivello, come previsto dal prodotto Adobe Photoshop: ad ogni layer corrisponde una differente comunit di utenti, in modo poter operare sul solo testo senza influenzare la grafica. Il risultato di questa fase la produzione di un documento, detto localization kit, che documenta i metodi e il processo di localizzazione, e di un insieme di moduli software in grado di estrarre i contenuti testuali e multimediali che vanno localizzati e tradotti, e reinserirli nel Portale una volta trasformati, ottimizzando cos le fasi di localizzazione e traduzione. In ultimo vanno specificati i metodi e la piattaforma di testing del Portale, tenendo presente le diverse interfacce che si andranno a generare in funzione delle comunit di utenti selezionate (v. Paragrafo 3.3.6). Tra gli aspetti fondamentali per la gestione del Portale multilingue vi sono, per ogni comunit di utenti selezionata: insieme di caratteri della lingua in uso; direzionalit della scrittura; formato della valuta; sistema di scrittura di data e ora; metodo di ordinamento dei caratteri. E prevista la possibilit di aggiungere ulteriori parametri, se in fase di internazionalizzazione di una particolare comunit di utenti si dovesse reputare opportuna una tale scelta. Per comprendere me glio le problematiche inerenti questi parametri caratteristici, analizziamo le problematiche da affrontare con diverse comunit di utenti. Innanzitutto, citiamo i principali sistemi di scrittura esistenti: Cinese Tradizionale Cinese semplificato Giapponese Coreano Arabo Ebraico Greco Latino Cirillico Brahninico e derivati Thai E utile ricordare che gli utenti con sistema di scrittura inglese rappresentino una minoranza. Ognuno di questi sistemi di scrittura necessit di uno proprio protocollo per la identificazione della propria comunit di utenti. La ISO fornisce due diversi standard, distinguendo la lingua dallo stato: ISO-3166 per il codice stati e ISO-639 per il codice lingue. Di seguito, sono forniti alcuni esempi:

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 32 di 86

en-UK inglese Inghilterra en-US inglese USA fr-FR francese Francia fr-CA francese Canada it-IT italiano Italia it-CH italiano Svizzera E importante notare come ogni lingua pu essere associata a pi stati. Chiaramente tale lingua differir, stato per stato (per esempio, linglese britannico differente da quello statunitense). Vediamo ora le principali caratteristiche di tre sistemi di scrittura presi come esempio: giapponese, indiano e latino. Sistema di scrittura giapponese: Diffusione geografica: Giappone Tipo di caratteri: misto - 4 sistemi, usati per scrivere contenuti diversi Kanji - ideografico caratteri ereditati da sistema cinese (numero di caratteri joyo kanji: 1945 car) Hiragana - fonetico sillabico, per scrivere particelle grammaticali. (46 car) Katakana - fonetico sillabico, usato per scrivere parole straniere (46 car), Romaji - fonetico alfabetico, caratteri latini e numeri arabi europei NB. una singola frase giapponese pu contenere sequenze di caratteri appartenenti a tutti e 4 i sistemi di scrittura. Direzionalit: sinistra-destra, verticale da destra a sinistra (tradizionale, poco usato) Separatore tra parole: no Sistema di ordinamento: 3 diversi sequenza di scrittura tratti basato su radicali fonetico Sistemi di traslitterazione in caratteri latini: non stamdardizzato Sistema di scrittura indiano Diffusione geografica: India Diversi sistemi di scrittura derivati dal brahminico: devangari, gujarati, punjabi, bengali, oriya, tamil, telugu, kannada, malayala. Il devangari il sistema di scrittura del sanscrito e della lingua hindi, la lingua ufficiale in india (oltre all'inglese). Tipi di carattere: fonetico Numero caratteri: circa 50 caratteri Direzionalit: monodirezionale sinistra-destra Separatore tra parole: spazio Forma dei caratteri; si modifica in funzione della parole, a causa delle legature Sistema di ordinamento: fonetico (?) Sistemi di traslitterazione in caratteri latini: fonetico (?) Complessit computazionale: elevata, in quanto i caratteri vengono collegati e composti non necessariamente nell'ordine in cui vengono scritti e pronunciati Sistema di scrittura latino Diffusione geografica: Europa occidentale, USA, Australia, America latina, Vietnam, Filippine.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 33 di 86

Tipo di caratteri: fonetico Numero caratteri: 26 lettere base di cui 5 vocali. Diacritici: accenti, dieresi, barre. Direzionalit: monodirezionale sinistra-destra Stili: due stili di scrittura (maiuscolo e minuscolo). Separatore tra parole: spazio Forma dei caratteri; 5 caratteri cambiano forma se sono finali di parola Sistema di ordinamento: fonetico NB In alcuni paesi le lettere dell'alfabeto latino sono in numero diverso: Finlandese e Svedese hanno 29 lettere (26 + , , ) Norvegese ha 29 lettere (26 + , , ) Turco ha 29 lettere modificate (8 vocali e 21 consonanti). Fino al 1928 era scritto in Arabo In altri paesi dove la scrittura arrivata con i missionari si usano meno lettere (es: Hawai, 12 lettere)

Le tabelle mostrate qui di seguito, evidenziano come diversi sistemi di scrittura possiedano metodi per la rappresentazione dei caratteri, delle date, delle ore, ecc. fortemente eterogenei. Per il raggruppamento dei decimali, allinterno del sistema di scrittura latino esistono diversi modi per raggruppare i decimali: Italia USA Russia Francia 1.234,56 1,234.56 1.234 56 1 234,56

Anche la rappresentazione dei numeri negativi varia da comunit a comunit: Italia USA Arabia 1234,567 ($ 1,234.567) ? ,???,??` -

E evidente che la gestione di un portale rivolto allintera comunit mondiale sia complessa e articolata. Ogni comunit possiede caratteristiche linguistiche e culturali proprie e le tecnologie informatiche forniscono standard e soluzioni ad hoc per ognuna di loro. E perci necessaria una preventiva progettazione ed ingegnerizzazione del portale rispetto alla internazionalizzazione, affinch sia possibile gestire tutte queste realt nella maniera pi semplice ed automatica possibile. In altre parole, il portale deve essere internazionalizzato affinch laggiunta di nuove comunit di utenti ne eviti lintera riprogettazione. 3) Localizzazione e traduzione La fase di localizzazione e traduzione ha lobiettivo di trasformare tutti gli oggetti mediali originali (secondo i metodi e le procedure delineati nel localization kit) in equivalenti, adatti alle diverse realt locali previste. Si parla di localizzazione per la trasformazione degli oggetti audio, video, audio-video e per le immagini. Si parla invece di traduzione per la trasformazione del solo testo. Operativamente, in queste fasi si effettuano le vere e proprie trasformazioni degli oggetti digitali eseguendo: doppiaggio audio-video e ritocco di video o immagini, per quanto concerne la localizzazione;

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 34 di 86

trasformazione del testo da una lingua ad unaltra, per quanto concerne la traduzione.

3.2. Evoluzione del progetto ADM


ADM rappresenta un progetto di eccellenza nel panorama dei servizi integrati di ricerca, consultazione e accesso a documenti riguardanti la musica notata. Le motivazioni del tentativo di estendere ADM passano necessariamente per lanalisi critica di quanto stato finora realizzato, sia nei suoi aspetti positivi sia in quelli meno riusciti. Una prima considerazione riguarda il numero di nodi aderenti alla piattaforma ADM. Gli elementi costitutivi di ADM si limitano ai nodi precedentemente citati: Biblioteca Nazionale Marciana di Venezia, Biblioteca Nazionale Universitaria di Torino e Discoteca di Stato. Si tratta di tre realt di eccellenza assoluta nel panorama della cultura italiana, proprietarie di un immenso capitale bibliografico e multimediale. Nonostante questo, il numero di nodi risulta troppo esiguo perch la rete ADM attuale possa davvero essere considerata di portata nazionale e internazionale. Innanzi tutto, si tratta di realt grandi nel panorama delle biblioteche e mediateche italiane, realt presumibilmente dotate di un buon budget per poter affrontare i compiti di digitalizzazione, catalogazione secondo accurati standard e organizzazione dei risultati. In altre parole, una prima causa del limitato successo (in termini di nodi aderenti) del progetto ADM si pu identificare negli alti costi dingresso nella rete. Analizzando questa motivazione in maggior dettaglio, si possono accennare alcune delle voci di spesa legate allinfrastruttura hardware e software richiesta: progettazione e predisposizione della rete; acquisto di macchine ad hoc; acquisto di licenze per i sistemi operativi e per i DBMS; formazione del personale; catalogazione e immissione dei dati bibliografici; eventuale digitalizzazione dei materiali conservati. Il presente capitolato cerca di proporre valide risposte ai problemi elencati, in modo da incentivare un numero via via crescente di nodi ad aderire alliniziativa di cui sono stati antesignani ADMV prima e ADM poi. Tra le alternative da valutare, ad esempio, vi un maggior interesse rivolto al mondo open source, il che abbatterebbe i costi di ingresso per quanto riguarda le licenze software. Unaltra strada che sar investigata consiste nellideazione di forme graduali dintegrazione nella rete complessiva, ad esempio con ladozione di standard meno stringenti per i nodi che desiderassero partecipare al progetto ReMI con un grado di interazione inferiore rispetto a ADM. Un altro aspetto di cui tenere conto la necessit di evitare eccessive imposizioni ai nodi entranti. Infatti, una politica assai stringente su infrastrutture hardware e software e su standard di codifica e salvataggio dellinformazione adeguata alla gestione di un numero esiguo di nodi, facilmente coordinabili tra loro. Il desiderio di attirare un numero ingente di nodi deve invece consentire un buon grado di eterogeneit, in modo da non interferire con lautonomia gestionale e decisionale delle realt locali. Daltro canto, non ipotizzabile gestire in modo univoco ed omogeneo una situazione complessa senza imporre dei vincoli da rispettare. Questa apparente contraddizione pu in verit essere risolta escogitando un ventaglio di soluzioni ad hoc anzich imponendo una rigida struttura comune. Proseguendo nella disamina dei problemi legati ad ADM, a motivazioni di carattere economico e gestionale si vanno poi a sommare legittime preoccupazioni su aspetti finora poco investigati dal progetto. Ad esempio, non particolarmente chiara la politica di detenzione dei diritti sul materiale originale e digitalizzato del singolo nodo. Inoltre, sono state finora tralasciate le

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 35 di 86

problematiche legate alla sicurezza e al digital rights management, aspetti che dovranno trovare risposte convincenti nellinfrastruttura offerta ai futuri nodi. Traendo le conclusioni da unanalisi storico-critica, lobiettivo della presente proposta salvaguardare leterogeneit delle risorse e difendere i diritti dei nodi partecipanti, cercando parimenti di incentivare nella maggior misura lingresso di nuovi nodi nel progetto. Questo pu avvenire semplificando le procedure di ingresso, rilassando i vincoli imposti da ADM sugli standard, escogitando strumenti affinch limpatto economico delliniziativa sia inizialmente contenuto e in ogni caso graduale. Nel corso del proprio funzionamento autonomo, ADM ha poi presentato alcuni problemi derivanti dalla sua attuale impostazione architetturale. Tali problemi finora non hanno rivestito una particolare rilevanza, viste le finalit di ADM, ma potrebbero rivelarsi critici nellottica dellintegrazione dei contenuti ADM nel portale BDI&NTC. Innanzi tutto, palese limpossibilit di garantire lerogazione di servizi 24 ore su 24 e 7 giorni su 7 da parte dei server ADM, che, in effetti, non erano stati progettati per questo tipo di servizio continuativo. La platea internazionale cui si rivolge il progetto ReMI differisce sensibilmente dallutenza specializzata prevista in ADM, il che richiede una disponibilit molto maggiore nellerogazione di servizi. Si sottolinea inoltre la scarsa tolleranza da parte del generico utente Internet di fronte a un disservizio da parte di un fornitore di informazioni, come si avr modo di approfondire nel corso del Paragrafo 3.3.7. Quanto detto impone ladozione di una soluzione ad alta affidabilit e in grado di garantire la massima disponibilit. Un altro problema evidente in ADM e risolto dallarchitettura ReMI concerne lomogeneit nel comportamento dei nodi. In parte, questo aspetto gi stato toccato precedentemente, nel parlare della disponibilit. Esistono per altre caratterizzazioni specifiche, quali i tempi di risposta e i livelli di servizio offerti, che vanno omogeneizzati al fine di rendere trasparente allutente le eterogeneit della rete sottostante. Le considerazioni fin qui effettuate trovano ancora una volta riscontro nella soddisfazione globale degli utenti dei servizi Web, come descritto pi compiutamente nel corso del Paragrafo 3.3.7. In definitiva, un ulteriore punto di forza della presente proposta consiste nel migliorare il livello dei servizi rispetto a quanto offerto da ADM allutente finale, innanzi tutto omogeneizzando il modo di presentarsi da parte dei singoli nodi (tempi di risposta, interfacce, qualit di servizio) e introducendo ove necessario nuove funzionalit. Il progetto ADM non verr in alcun modo intaccato dalla presente proposta; piuttosto, unaccurata disamina delle sue caratteristiche salienti e una politica che invogli lavvicinamento di nuovi nodi potrebbe incentivarne un ampliamento. Si ritiene per opportuno sovrapporre alla struttura ADM unintelaiatura comune, in grado di ospitare al proprio interno tanto nodi ADM quanto nodi indipendenti da ADM, ossia sottoposti a un numero meno stringente di vincoli. Questa infrastruttura sar in grado di dialogare direttamente con ADM, e non imporr alcuno sforzo aggiuntivo ai nodi ADM e ai nodi che vorranno essere ADM-compatibili, supportando nel contempo altri soggetti. La percezione del progetto complessivo che i nuovi nodi dovranno avere si pu articolare nei seguenti punti: massimo riutilizzo del lavoro finora svolto nella catalogazione, digitalizzazione e organizzazione del materiale in loro possesso; impatto economico inizialmente modesto e comunque graduale; facilit di ingresso e di interfacciamento con il resto della rete; miglioramento delle funzionalit di gestione dei nodi (prestiti interbibliotecari, prestiti al pubblico, ...); offerta di nuove funzionalit (preservazione di dati e materiali tramite digitalizzazione, commercializzazione delle risorse multimediali,...); piena tutela della propria autonomia decisionale;

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 36 di 86

piena tutela dei diritti sul materiale originale e digitalizzato. Attraverso levoluzione del progetto ADM si intende far nascere una Rete della Musica Italiana (ReMI), ossia un insieme di nodi che intendano fornire una risposta professionale allutente specializzato in ambito musicale.

3.2.1. Profilazione dei servizi


I servizi messi a disposizione agli utenti ReMI dovranno essere il pi possibile orientati alla particolare tipologia di professionisti musicisti/musicologi che saranno i loro naturali fruitori. Si ritiene necessario limitare il pi possibile laccesso anonimo alla banca dati, per mantenere traccia degli utenti e dei loro trascorsi. 3.2.1.1. Servizi per utenti comuni Lutente comune dovr avere a disposizione uninterfaccia di ricerca documenti che consenta di operare sul pi alto numero possibile di metadati, presumibilmente tutti quelli presenti nello standard MAG e nei corrispettivi UNIMARC specificati nel Paragrafo 3.2.4. Naturalmente buona parte dei servizi riservati agli utenti presentati nel Paragrafo 3.1.1 possono essere implementati anche a livello di nodo ReMI, consentendo una visione dassieme omogenea rispetto al Portale ed integrando con funzionalit aggiuntive. Data la particolarit del tipo di utenza, alcune considerazioni sulla velocit di reperimento di materiale ad alta ed altissima qualit possono essere delineate: se infatti allinterno del Portale occorre tener conto dei tempi di fruizione del materiale cercato, in ambito ReMI lutente potrebbe essere ben disposto ad aspettare un tempo molto maggiore, a fronte di una qualit eccellente del materiale. 3.2.1.2. Servizi per amministratori Gli amministratori di nodo ReMI potranno disporre liberamente del materiale ivi contenuto, avendo in aggiunta alcune funzionalit di gestione del sistema e degli utenti. Si consiglia ad esempio di prevedere un sistema di gestione diritti, che permetta di creare una differenziazione dei privilegi relativi a singole categorie di utenti e/o a singoli utenti. Una soluzione gi adottata in altri ambiti prevede che gli amministratori abbiano a disposizione una griglia che su un asse presenta gli utenti e sullaltro i privilegi disponibili: mediante una serie di caselle di spunta vero/falso situate nelle intersezioni, possibile un controllo avanzato dei diritti.

3.2.2. Profilazione degli utenti


I servizi dei nodi ReMI dovranno prevedere almeno una differenziazione in due macrocategorie di utenti: Amministratori: hanno a disposizione una serie di strumenti per configurare laccesso al sistema e possono usufruire senza limitazioni dei servizi riservati agli utenti comuni Utenti comuni: hanno la possibilit, dopo una registrazione obbligatoria, di consultare la banca dati, e di richiedere materiale di loro interesse Attraverso ladozione del sistema di profilazione utenti esposto nel paragrafo precedente, potranno essere create categorie specializzate con diritti specifici.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 37 di 86

3.2.3. Profilazione dei fornitori di informazioni


I nodi che partecipano attraverso una condivisione dei propri dati/metadati alla rete ReMI possono essere divisi macroscopicamente in tre categorie: nodi gi facenti parte di ADM; nodi con OPAC e teca digitale non facenti per parte di ADM; nodi con OPAC senza teca digitale. Anche se la qualit dellinformazione presente sia a livello di dati che di metadati nei nodi ADM indiscutibile, dovr essere posta particolare attenzione nel considerare la grande eterogeneit dei nodi invece esterni ad ADM, per non correre il rischio di rendere difficile la condivisione del loro patrimonio culturale.

3.2.4. Metadati caratterizzanti


I metadati presentati nel Paragrafo 3.1.4 caratterizzano anche i dati presenti in ReMI. Naturalmente, data la connotazione pi specialistica degli utenti che procederanno alle consultazioni, risulta ancora pi importante fornire unimplementazione quanto pi completa possibile dei metadati, anche pensando a eventuali omissioni, utili invece a qualche singolo nodo. Per consentire una maggiore adattabilit del database occorrer prevedere una serie di campi aggiuntivi (tipizzabili o meno) che potranno essere utilizzati dal singolo nodo per inserire dei metadati specifici (ad esempio, se una teca contiene anche una collezione di marionette, potr utilizzare i campi aggiuntivi per inserirne materiali, dimensioni, ...)

3.2.5. Indicizzazione, trattamento e reperimento di contenuti musicali


A livello sperimentale possono essere utilizzate delle tecnologie avanzate per indicizzare, trattare e reperire contenuti musicali, ad esempio attraverso metriche di valutazione di similarit, adottando soluzioni informatiche allavanguardia che forniranno un valore aggiunto allinformazione culturale presente nei nodi, sempre basandosi su di essa. Attraverso ladozione di una codifica dellinformazione musicale multi-livello XML, ed opportuni tool software di sincronizzazione lutente pu, per esempio, navigare allinterno dellinformazione musicale agendo indipendentemente ed in maniera sincronizzata sulla partitura, sui relativi file audio (contenenti le diverse esecuzioni) o sulla corrispondente informazione video. Per esempio, possibile ascoltare un pezzo audio (o audio/video) selezionando sempliceme nte il corrispondente insieme di note in partitura. Oppure, possibile ascoltare un brano audio, visualizzando istante per istante, la nota o laccordo corrispondente, attualmente in esecuzione; un tale sistema potrebbe essere visto come un simulatore del comportamento di un ascoltatore che segue nellaudio le note che legge dalla partitura. Tramite un opportuno tool di riconoscimento automatico di frasi melodiche di un brano audio, altres possibile ricercare contenuti musicali (preventivamente codificati, segmentati ed indicizzati con codifica multi-livello) tramite qurey by content: lutente pu fischiettare la melodia del pezzo da ricercare da un microfono o inserirla tramite tastiera MIDIm ed il sistema automaticamente andr a riconoscere linsieme dei pezzi pi simili alla melodia inserita.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 38 di 86

3.3. Tecnologie di riferimento


Questo paragrafo dedicato a definire le tecnologie di riferimento per lattuazione del progetto con particolare attenzione agli standard metodologici e qualitativi da adottare per quanto riguarda: i procedimenti di digitalizzazione di audio, immagini e video; la codifica dellinformazione nelle forme testuali, musicali simboliche, audio, grafiche, video; gli standard di comunicazione, sicurezza e backup; le tecnologie standard di gestione della propriet intellettuale e delleconomia relativa; gli aspetti delle interfacce uomo-macchina in relazione allergonomia, allinterazione, allusabilit e allaccessibilit; i requisiti e i metodi di validazione e tuning delle prestazioni; i criteri di riferimento per la qualit e le prestazioni dei servizi Web.

3.3.1. Metodiche standard dei procedimenti di digitalizzazione


Il primo passo in direzione del riversamento conservativo degli archivi musicali consiste nell'assicurarsi che i supporti originali siano idonei alla digitalizzazione. In molti casi, infatti, essi devono essere pre-trattati, e in un certo senso, "restaurati" affinch le informazioni musicali e foniche originali possano essere convertite in formato digitale senza perdita di dati. Sfortunatamente, oltre a non presentare uno stato di conservazione soddisfacente, spesso una parte dei supporti conservati negli archivi versa in una condizione critica, poich rischia di deteriorarsi completamente ed in breve tempo. Questa condizione pu riguardare tanto i supporti magnetici quanto quelli cartacei. L' idea di fondo che guida le procedure di digitalizzazione dei supporti che i contenuti musicali devono essere acquisiti "cos come sono" senza interventi di restauro, che potranno essere eventualmente proposti in un secondo tempo. Tuttavia le procedure standard per il riversamento conservativo dei contenuti fonici comprendono, oltre a un certo numero di compiti, anche alcune operazioni concernenti il ricondizionamento dei supporti deteriorati. Schematicamente, le procedure adottate sono le seguenti: se necessario, pre-restauro dei supporti originali con opportune pulizie e trattamenti; digitalizzazione e organizzazione in tracce dei contenuti; masterizzazione in doppia o triplice copia di ciascuna registrazione originale su supporto ottico; classificazione delle registrazioni originali e delle registrazioni su CD-R o DVD-R mediante l' impiego di attributi che corrispondono a quelli predisposti nel database; se necessario, post-restauro del materiale digitalizzato tramite opportuni software di editing. 3.3.1.1. Audio Per il riversamento audio, generalmente la metodologia applicata la seguente.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 39 di 86

1. Ascolto preliminare del supporto, acquisito tramite scheda audio o sistema hardware dedicato, in modo da individuare i livelli minimi e massimi di suono ed eventuali disturbi audio gi riscontrabili. In questa fase necessario: a. regolare il livello del volume di registrazione sul software di acquisizione; b. impostare i parametri di acquisizione (per esempio, nel caso si utilizzi il CD-DA: 44.100 KHz, 16 bit, stereo); c. ascoltare preliminarmente i campioni del supporto per individuare eventuali picchi (e quindi fenomeni di clipping) e ritarare i livelli di ingresso del canale line in, con il mixer specifico del software utilizzato. 2. Acquisizione dei dati. a. attivazione della modalit record del software di acquisizione e contemporanea attivazione della modalit play del riproduttore (per esempio avvio del piatto del giradischi); b. controllo, in fase di acquisizione, dei livelli del suono. 3. In fase di acquisizione viene creato un file unico. Segue uneventuale operazione di separazione delle tracce, che avviene tramite individuazione, sulla forma donda, dei marker inseriti manualmente o automaticamente dal software di acquisizione (per esempio in presenza di silenzi di durata superiore a un numero di secondi preimpostati); a. tale operazione va compiuta congiuntamente allascolto di testa e coda dei singoli brani per accertare il corretto posizionamento dei marker e lindividuazione della traccia in modo univoco; b. segue lassegnazione di un nome univoco e di un numero progressivo alle tracce individuate. 4. Registrazione su supporto ottico tramite il software stesso. In alternativa o in aggiunta: a. creazione di un CD di dati: in tal modo i file WAV sono leggibili utilizzando un PC ma non sono riconoscibili da un lettore di Compact Disc audio; b. creazione di un CD audio con file in formato MP3. 3.3.1.1.1. Nastri magnetici Mentre per la gran parte dei nastri sufficiente un lavoro di pulizia manuale, eseguito svolgendo e riavvolgendo il nastro e utilizzando speciali detergenti, i nastri che presentano problemi di ossidazione, che hanno subito processi di stiramento o che hanno assorbito umidit, necessitano di un trattamento di cottura prima del trasferimento in digitale. Ci consente di eliminare i difetti che altrimenti si presenterebbero nella fase di svolgimento del nastro: ad esempio, i cigolii dovuti all'attrito eccessivo nei confronti delle guide e delle testine del registratore, oppure il progressivo incupimento del suono dovuto al rilascio di materiale magnetico. Un esempio di trattamento (pre-restauro) pu essere il seguente: si pongono i nastri in un incubatore ad una temperatura fra i 45C e i 54C. Tale temperatura deve essere raggiunta gradualmente (in 25 - 30 minuti), mentre i "tempi di cottura" possono variare dalle 24 alle 36 ore. Una volta che i nastri abbiano riacquistato buona parte delle caratteristiche originali, il contenuto fonico viene digitalizzato e contestualmente immagazzinato su supporto digitale. 3.3.1.1.2. Supporti vinilici Per i supporti vinilici, deve essere effettuato un ascolto preventivo del campione da digitalizzare. Tale analisi deve generare una catalogazione dei dischi rispetto a eventuali artefatti e distorsioni generate dalla degradazione del materiale conservato. Pi nel dettaglio, le degradazioni possono essere generate da macchie, polvere, graffi o una loro combinazione (macchie + graffi, graffi + polvere, ecc.). E perci necessario identificare, per ogni materiale, il tipo di degradazione fisica presente e le conseguenti distorsioni audio generate (clipping, scratch, background noise,

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 40 di 86

ecc.). Su tali artefatti possibile agire con opportune operazioni di post-restauro eseguite nel dominio digitale. 3.3.1.1.3. Altri supporti Per altri supporti (per esempio i cilindri in cera) necessario definire i problemi che essi possono presentare allascolto, definendo, come gi mostrato per vinili e nastri, eventuali operazioni di pre-restauro e post-restauro. 3.3.1.1.4. Riversamenti nel dominio digitale Il riversamento di supporti gi digitalizzati richiede particolare attenzione per quanto riguarda: i passaggi nel dominio analogico, con conseguenti operazioni di conversione digitaleanalogico e anologico-digitale; le conversioni audio necessarie per rendere compatibile la codifica audio originale con quella di destinazione. E fondamentale evitare eventuali passaggi nel dominio analogico durante il riversamento di materiali gi digitalizzati. Le operazioni devono essere eseguite con opportuni tool di copia, agendo direttamente sulla codifica numerica. Per esempio, per il riversamento di CD audio, possibile utilizzare un software di ripping. Se i formati di codifica di origine e destinazione non coincidono (per esempio da DAT 48 KHz a CD-DA 44.1 KHz), necessario eseguire operazioni di conversione agendo sempre in dominio digitale tramite editor audio ad hoc. Tali funzioni di processing devono essere eseguite riducendo al minimo lintroduzione di eventuali artefatti audio. Definiamo le seguenti operazioni di elaborazione: ricampionamento: consigliabile eseguire questa conversione tra valori di frequenze di campionamento multipli tra loro (esempio, da 96 KHz a 48 KHz). In ogni caso, importante configurare opportunamente (anche per via euristica) il filtro anti-alias riducendo al minimo il rumore di ricampionamento introdotto; riquantizzazione: consigliabile eseguire questa conversione tra valori di bit di quantizzazione multipli tra loro. In ogni caso, importante scegliere opportunamente (anche per via euristica) il sistema di anti-alias (dithering, noise-shaping, etc.) pi opportuno, riducendo al minimo il rumore di riquantizzazione introdotto; ricodifica di canale: nel caso di ricodifiche da stereo a mono, occorre controllare che loperazione di mixaggio tra i due canali non abbia generato clipping e distorsioni. Se necessario, possibile eseguire operazioni di normalizzazione (peak o RMS) al fine di sfruttare tutta la dinamica fornita dalla scala di quantizzazione utilizzata. 3.3.1.2. Immagini Per il riversamento di immagini necessario: scegliere uno scanner adeguato al tipo di materiale da digitalizzare (dimensione dei supporti, possibilit di scansione a contatto o di procedimento di prelievo dellimmagine mediante fotografia); visionare preventivamente i materiali per valutare opportune operazioni di pre e post restauro; eseguire la scansione del materiale cartaceo o fotografico; salvare limmagine digitalizzata in un formato coerente con gli standard adottati, definendo: formato ed eventuale tipologia di compressione;

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 41 di 86

dimensione e risoluzione (DPI); profondit di colore. Terminata la scansione, si procede alla catalogazione delloggetto digitale e alla successiva archiviazione su supporto ottico. 3.3.1.2.1. Manoscritti, diapositive, immagini e fotografie stampate Questo paragrafo fa riferimento alla Normativa ICCD per lacquisizione digitale delle immagini fotografiche e al Capitolato tecnico ICCU per la Digitalizzazione di manoscritti dei fondi musicali di Biblioteche italiane. La scansione ottica deve essere effettuata con attrezzatura appropriata, nel pieno rispetto della normativa vigente in tema di sicurezza del lavoro. Il materiale da sottoporre a digitalizzazione decisamente eterogeneo per quanto riguarda la tipologia,i contenuti, lo stato di conservazione e il valore storico dei supporti in oggetto. Per tali motivi, risulta difficile dare indicazioni di validit generica. E per possibile individuare una serie di linee guida, con particolare riferimento ad alcuni casi peculiari. Nel caso di materiali di gran pregio e/o estremamente delicati, le modalit di ripresa (apertura dei volumi, illuminazione, manipolazione) dovranno essere tali da non arrecare loro danno, e a tal fine il responsabile dellattivit verificher in particolare per ciascun volume il posizionamento, lapertura e la possibilit di ripresa a pagina singola o a doppia pagina, ove richiesto. Nel caso di volumi rilegati, le immagini saranno acquisite appoggiando i piatti della legatura su una superficie idonea e rivolgendo verso lalto la superficie da riprodurre. Si avr cura nello sfogliare le pagine e non sar esercitata alcuna pressione sul manoscritto, in particolare sui dorsi delle legature. Durante tutte le operazioni connesse alla digitalizzazione il personale addetto dovr indossare appositi guanti di cotone o altre idonee forme di protezione al contatto. La riproduzione deve avvenire con lutilizzo di lampade a luce fredda (5400 Kelvin), prive di componente ultravioletta. Considerata la deperibilit del materiale manoscritto, si esclude lutilizzo di scanner piatti o che prevedano pressione sui volumi. Invece, nel caso di materiali meno pregiati, le soluzioni per procedere alla digitalizzazione sono molteplici. Rimane lesigenza di produrre immagini di alta qualit e di non arrecare danno al materiale originale soggetto a digitalizzazione. A questo scopo, i responsabili dei nodi coinvolti nelle campagne di digitalizzazione potranno individuare la soluzione pi idonea a seconda delle esigenze riscontrate. Lacquisizione in formato digitale di qualit deve tenere nella giusta considerazione alcune problematiche tipiche, quali: imperfezioni della stampa; deterioramento della carta e dello stampato; qualit della stampa; stili di scrittura. Per migliorare la qualit del prodotto digitale, talora si possono rendere necessari trattamenti preliminari, ovviamente in modo compatibile con le caratteristiche fisiche del supporto. Tra questi, citiamo a scopo puramente esemplificativo la possibilit di eliminare: ditate, utilizzando mollica di pane;

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 42 di 86

inchiostro, tamponando con un batuffolo di cotone imbevuto d'acqua ossigenata a 10 volumi oppure con acido ossalico diluito (1 parte d'acido e 9 d'acqua). La pagina va poi asciugata tra due carte assorbenti; polvere, spolverando spesso i supporti con pennelli dalle setole lunghe e molto morbide. Si pu rendere necessario pulire il dorso e i tagli, pagina per pagina (soprattutto all'attaccatura del dorso); umido, tamponando (batuffolo di cotone) con una miscela d'acqua calda (40C ca.) e bicarbonato di calcio (1 cucchiaio in 1/2 litro d'acqua). Dopo aver lasciato agire qualche minuto (10/12), si asciuga la pagina tra due carte assorbenti. Ripetere l'operazione se necessario facendo asciugare bene la carta fra un trattamento e l'altro per non indebolirla; unto, applicando una miscela di polvere di magnesia e benzina. Si copre poi con carta assorbente e si mantiene chiuso il supporto (con un peso sopra) per circa 8 ore. Per maggiori approfondimenti su tecniche e strumenti di digitalizzazione, si rimanda a: UNESCO/ICA/IFLA Guidelines for digitization projects for collection and holdings in the public domain, particularly those held by libraries and archives http://www.ifla.org/VII/s19/pubs/digit-guide.pdf Ministero per i Beni e le Attivit Culturali, Biblioteca Palatina di Parma Progetto DI.MU.SE. http://www.bibpal.unipr.it 3.3.1.2.2. Riversamenti nel dominio digitale Le problematiche del riversamento di supporti gi digitalizzati richiede attenzioni analoghe a quelle gi illustrate nel riversamento dellaudio. Anche in questo caso fondamentale: evitare inutili passaggi nel dominio analogico; in eventuali trasformazioni tra codifiche di origine e destinazione differenti, evitare problemi nella ricodifica dei parametri; per esempio cercare di ridurre al minimo rumori di ricampionamento e riquantizzazione. 3.3.1.3 Video Anche per riversare un video necessario, come per gli altri supporti, valutare se siano necessarie operazioni di pre-restauro e post-restauro tramite opportuna visione preventiva del materiale da digitalizzare. Acquisire un video unoperazione immediata, ma opportuno fare attenzione alla corretta impostazione dei parametri di digitalizzazione. Nel caso si faccia uso di personal computer generico, il programma di cattura viene solitamente fornito con il software della scheda di acquisizione video o presente nel software di editing (esempi: Adobe Premiere, Ulead Media/Video Studio, Avid, ecc.). Prima di acquisire, occorre impostare alcuni parametri che riassumiamo di seguito: dimensione del riquadro video: indica la larghezza e laltezza del fotogramma. Un accorgimento essenziale quello di catturare alle dimensioni con cui si intende lavorare, altrimenti il programma di montaggio dovr ogni volta ricompilare il filmato per aumentare/diminuirne le dimensioni;

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 43 di 86

formato: solitamente il formato di cattura AVI (Audio Video Interleaved), in quanto in fase di editing risulta il pi versatile. Nella compilazione finale potr invece essere scelto il formato desiderato; codec: se si in possesso di una scheda con codec hardware, la scelta cadr su di esso. Altrimenti si dovranno eseguire alcune prove per scegliere i codec software pi performanti sul sistema selezionato; audio: le impostazioni audio sono a discrezione, ricordando che sempre meglio catturare alla massima qualit consentita. Una volta effettuata lacquisizione, possibile effettuare operazioni di montaggio e restauro del materiale digitalizzato. Infine, si effettua la catalogazione del materiale digitalizzato e la sua successiva registrazione su supporto ottico. 3.3.1.3.1. Pellicole e supporti magnetici Offriamo inizialmente una panoramica delle diverse tipologie di pellicole video professionali comunemente utilizzate, con alcune caratteristiche legate alla loro degradazione in qualit: Pellicole a base nitrato: usati fino agli anni 50, sono instabili chimicamente e altamente infiammabili, anche se offrono per contro robustezza meccanica e una qualit video buona; devono essere adottate precauzioni per il danneggiamento chimico e linfiammabilit; Pellicole a base acetato: le pi utilizzate, soffrono per del rilascio dellacido acetico, che viene accelerato in ambienti con temperature e/o umidit elevate; la pellicola necessita di particolare attenzione nel caso presenti degrado visibile; Pellicole a base poliestere: introdotte dopo gli anni 50, sono molto meno deteriorabili di quelle a base nitrato e acetato, con una durata stimata 5-10 volte superiore; Pellicole che presentano scotch di giunzione: fino al 1975 lutilizzo dello scotch per giuntare diverse porzioni di pellicole era diffuso; in questo caso occorre una manutenzione preventiva che stabilizzi il materiale unito. Per diminuire il pi possibile la possibilit di degrado delle pellicole esse devono essere conservate in ambienti con condizioni controllate (tipicamente una temperatura di 5C e unumidit del 25%). La digitalizzazione delle tipologie di pellicole sopra esposte pu avvenire con un trasferimento real-time con apparecchiature professionali TELECINE oppure utilizzando degli scanner ad alta risoluzione, ottenendo una qualit superiore ma con tempistiche molto dilatate. Per quanto riguarda i supporti magnetici non cinematografici, esistono diverse tipologie di nastri (1, 2, , Betacam, VHS), con caratteristiche chimiche diverse tra i diversi produttori di supporti; in generale se il materiale risulta degradato esso pu essere restaurato preventivamente con uno o pi cicli di pulizia. Per la digitalizzazione dei nastri video non professionali occorre prestare particolare attenzione ai differenti standard video PAL e SECAM, visto che una grande parte della degradazione della qualit dellimmagine pu scaturire proprio da questo primo passaggio. Infine occorre segnalare che un problema sentito anche nella digitalizzazione in campo video, come in quello audio, la disponibilit di apparecchiature di riproduzione compatibili con i supporti pi datati. 3.3.1.3.2. Riversamenti nel dominio digitale Le problematiche del riversamento di supporti gi digitalizzati richiedono attenzioni analoghe a quelle gi considerate nel riversamento dellaudio e delle immagini.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 44 di 86

3.3.2. Standard di codifica


Nel presente capitolo verranno dettate le linee guida che opportuno seguire nelle scelte sulla codifica di informazioni in formato digitale. A questo proposito risulta evidente quanto una standardizzazione delle scelte consenta da un lato di mantenere unomogeneit dei risultati complessivi disponibili agli utenti, e dallaltro di fornire una serie di risposte ai nodi che non hanno ancora avviato unopera di digitalizzazione e che vogliano essere immediatamente compatibili con i servizi prospettati in questo documento e allo stesso tempo operare le migliori scelte possibili. I formati saranno distinti fra quelli relativi alla conservazione in altissima qualit del materiale digitalizzato e quelli deputati alla fruizione a media o bassa qualit, normalmente accessibile attraverso i servizi del Portale. Le prerogative specifiche delle due categorie di codifiche sono diverse. Per la conservazione ad altissima qualit, il problema principale proprio il raggiungimento delleccellenza di rappresentazione digitale, risultando invece poco importante loccupazione di spazio su disco da parte del file. Per la fruizione, invece, deve essere posta particolare attenzione alla dimensione del documento digitale, che dovr essere trasportato sulla rete dal nodo allinterfaccia ReMI-Portale e poi agli eventuali utenti che ne facciano richiesta. 3.3.2.1 Informazione testuale Per il trattamento di originali costituiti prevalentemente da informazione testuale, esistono due strade possibili: la scansione del testo ed il suo salvataggio in forma grafica (trattato nel paragrafo 3.3.1.3.2), oppure il riversamento in codifica testuale ottenuta tramite un software OCR (Optical Character Recognition) ed una successiva revisione manuale. A fronte di una mole di lavoro maggiore, si guadagna la possibilit di riutilizzare il testo digitalizzato per altre finalit (ad esempio, la consultazione da parte di non vedenti). Occorre prima di tutto considerare che il singolo nodo deve scegliere formati che garantiscano la maggiore qualit possibile, riservando invece al Portale materiali da utilizzare a scopo di preview o di consultazione gratuita a bassa qualit. Per la codifica dellinformazione testuale possono essere profilate tre scelte che coniugano completezza di informazione e contenimento delle dimensioni in forma digitale: Codifica TXT, fortemente comprimibile, che contiene il contenuto senza immagini e informazioni di formattazione del testo (senza possibilit di impedire il riutilizzo del testo); Codifica RTF, ben comprimibile, che incorpora contenuto testuale, immagini e formattazione, compatibile con tutti i sistemi pi diffusi (senza possibilit di impedire il riutilizzo del testo e delle immagini); Codifica PDF, gi compressa, che rappresenta il documento nella sua forma originale, visualizzabile con il download gratuito di Adobe Reader, disponibile per tutte le piattaforme pi diffuse. E previsto un controllo evoluto dei diritti di modifica, selezione e stampa. E necessario evidenziare che lo stesso tipo di codifica pu risultare pi o meno efficace in funzione del materiale da rappresentare: ad esempio, un file TXT di un testo di analisi musicale in cui sono presenti centinaia di immagini di partitura rappresenterebbe una quantit minima dellinformazione contenuta nelloggetto digitalizzato. In questo senso, risultano percorribili due strade, utilizzabili anche insieme, per portare linformazione originaria in media e bassa qualit: (1) un netto taglio del materiale, e (2) la scelta di una codifica che non rappresenti appieno la totalit dellinformazione.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 45 di 86

Nel formato TXT necessario utilizzare la codifica Unicode, che permette di rappresentare i caratteri presenti in lingue diverse dallitaliano. Per contenere spazio di memorizzazione preferibile inoltre adottare lo standard UTF-8, vista la predominanza di lingue diverse dalle est/sud asiatiche, che invece offrirebbero maggiore compattezza con luso dellUTF-16. Per la conservazione (presso la teca digitale) e per la fruizione (dal Portale) vengono infine delineate le seguenti linee guida: Tipo di dato Conservazione del documento completo con formattazione semplice Conservazione del documento solo testuale Fruizione a media qualit del documento completo Fruizione a medio-bassa qualit del documento con formattazione semplice Fruizione a bassa qualit del documento completo Fruizione a bassa qualit del documento con formattazione semplice Tipo di codifica RTF con immagini a 600 dpi TXT PDF 300 dpi RTF con immagini a 144 dpi PDF 72 dpi RTF con immagini a 72 dpi

La scelta di non utilizzare il formato PDF come standard di conservazione ad alta qualit deriva dal fatto che i file di questo tipo non sono facilmente modificabili (ad esempio per correggere eventuali errori riscontrati successivamente alla creazione). 3.3.2.2. Informazione musicale si mbolica Lo standard attualmente adottato allinterno di ADM per la codifica di informazione musicale simbolica il PEC (acronimo di Plaine & Easie Code, talvolta noto come Plain & Easy Code). Relativamente agli incipit musicali, in ADMV per ogni unit bibliografica stato creato e/o corretto almeno un incipit musicale con il codice PEC. Nell'OPAC ADMV, tali incipit sono graficamente visualizzabili su pentagramma secondo soluzioni tecnologiche in via di definizione. Vantaggi di PEC: estrema compattezza; codifica plain-text; indipendenza dalla piattaforma; completezza ai fini della rappresentazione simbolica minimale richiesta; standard sostenuto dallInternational Association of Music Libraries e dal Rpertoire International des Sources Musicales; facilit di conversione in qualsiasi altro formato di codifica musicale simbolica, volto tanto alleditoria (NIFF, MusicXML, Finale) quanto allesecuzione (MIDI, CSound). Svantaggi di PEC: gestione problematica di melodie con simboli atipici e/o estranei alla tradizione musicale occidentale; estensioni non ancora previste per la polifonia; scarsa ricezione dello standard in ambito commerciale e accademico; scarsa leggibilit da parte dellutente musicalmente colto (strumentista, compositore, musicologo,), nonostante limmediatezza del formato testuale; impossibilit di effettuare sincronizzazioni con oggetti multimediali internamente al formato. Da una breve analisi, evidente che i vantaggi nellapplicare PEC a incipit musicali monodici spesso si trasformino in difetti in un contesto di maggior respiro. Ad esempio, lestrema compattezza di PEC rispetto alla verbosit di un linguaggio basato su XML va a scapito della

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 46 di 86

leggibilit e della flessibilit. Analogamente, PEC si rivela completo dal punto di vista della sintassi e della grammatica musicale solo in un ambito relativamente ristretto (brevi incipit monodici appartenenti alla cultura musicale occidentale). Peraltro, questo il contesto cui PEC si rivolge, come le stesse specifiche dichiarano:
Documentation of music manuscripts requires a short music incipit. As a general principle that should be taken: for instrumental music from the first violin or the highest part; for vocal music from the highest voice and the first violin or the highest instrumental part. The incipit should be not too long and not too short and musically as senseful as possible. It should contain at least 3 bars or 10 non-repeated notes. In its typewritten version the code should be written on a single line. Special characters preceding the content of the code should be omitted in MARC format subfields.

PEC facilmente convertibile in qualsiasi formato, dunque potr essere adottato nei nodi periferici (soprattutto nei nodi che presentano una base di dati con numerose codifiche PEC gi attuate) e convertito in un formato pi adeguato nella base di dati centrale. In particolare, seguendo le linee guida ispiratrici del progetto, il formato della base di dati centrale dovr essere una codifica XML che presenter le seguenti caratteristiche: indipendenza dalla piattaforma; leggibilit; estensibilit; completezza grammaticale e sintattica nella rappresentazione simbolica di qualsiasi partitura; facilit di lettura da parte dellutente dotato di preparazione musicale; rappresentazione multi-livello dellinformazione musicale; possibilit di effettuare sincronizzazione con oggetti multimediali; supporto da parte dei principali software di editoria musicale. La conversione dal formato PEC a una codifica basata su XML (e viceversa) avverr per via automatica tramite la realizzazione di semplici filtri software. Invece, larricchimento dei dati di origine, ad esempio a fini di sincronizzazione della partitura con oggetti multimediali, deve essere compiuto con strumenti software da sviluppare ad hoc. 3.3.2.3. Informazione audio In funzione del tipo di servizio fornito, linformazione audio in formato digitale deve essere codificata con differenti standard. Gli oggetti digitalizzati possono essere conservati, fruiti in alta qualit o resi disponibili sotto forma di preview a bassa qualit per il download e lo streaming. Per ogni tipologia di servizio, si profilano le seguenti scelte: per la conservazione dei contenuti audio, la codifica di riferimento PCM con frequenza di campionamento 96 KHz (o 192 KHz) e parola di quantizzazione a 24 bit, con codifica di canale stereo. Essa rappresenta la miglior codifica attualmente esistente nel mercato in termini di qualit audio percepita. E adottata dallo standard del DVD Audio. In alternativa, per motivi specifici, si pu optare per la codifica CD-DA (PCM con frequenza di campionamento 44,1 KHz e parola di quantizzazione a 16 bit), standard de facto nel mercato dei supporti ottici audio; per la fruizione ad alta qualit, linformazione audio deve essere codificata in MPEG-1 Layer 3 (MP3) a 48 (o 44.1) KHz, con codifica di canale stereo non compressa e bitrate pari a 256 Kbit/s. Lo standard MP3 rappresenta un buon compromesso in termini di qualit ed occupazione di spazio ed inoltre fortemente radicato nel mercato dellaudio digitale;

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 47 di 86

per il preview a bassa qualit, si codificano circa 30 secondi del brano audio ritenuti significativi (per esempio i primi 30 secondi) con MPEG-1 Layer 3 (MP3) a 32 (o 22,05) KHz, con codifica di canale mono e bitrate pari a 32 Kbit/s; per i servizi di streaming si suggerisce la piattaforma SHOUTcast perch gratuita, si appoggia a Winamp player audio free ampiamente utilizzato e supporta le codifiche audio MP3. 3.3.2.4. Informazione grafica Il contenuto del presente paragrafo si basa sulle indicazioni in materia dettate dal Capitolato tecnico ICCU per la Digitalizzazione di manoscritti dei fondi musicali di Biblioteche italiane. Linformazione grafica qui considerata nella sua versione digitale, ossia come risultato di campagne di digitalizzazione o come insieme di oggetti nativamente in formato digitale. Linformazione grafica pu essere genericamente definita come linsieme di contenuti fruibili tramite il senso della vista. Il testo e il video, pur facendo parte dellinformazione grafica, saranno trattati separatamente per via delle loro caratteristiche pi specifiche. Restringendo il campo dindagine alla grafica intesa come immagini statiche, si pu comunque procedere a unulteriore caratterizzazione degli oggetti digitali da trattare. Infatti, da un lato si pongono i documenti con informazioni di natura testuale e simbolica (manoscritti, partiture, monografie), mentre dallaltro si trovano documenti di grafica generica (fotografie, scansioni di disegni e di layout grafici complessi). Pur trattandosi comunque di immagini, la grafica generica ha caratteristiche intrinsecamente diverse da partiture e monografie. Fra i tratti distintivi pi salienti, vanno citati i seguenti: in generale, la grafica generica richiede lutilizzo di vaste palette di colori, mentre per i documenti a stampa sufficiente supportare una scala di grigi. Esistono comunque numerose eccezioni: si pensi ai codici miniati o alle monografie con immagini a colori; le dimensioni fisiche delle fotografie digitali e di quelle analogiche (oggetto di digitalizzazione) sono standard, mentre su manoscritti, partiture e monografie pu sussistere una grande eterogeneit. 3.3.2.4.1. Scansione di manoscritti, partiture a stampa e monografie Per ciascuna pagina dei documenti da digitalizzare verr prodotto un file immagine. Per quanto riguarda le indicazioni sulla digitalizzazione, si rimanda al Paragrafo 3.3.1.2.1. Qualora richiesto dai responsabili di progetto, si deve prevedere la digitalizzazione delle legature, dei fogli di guardia e di eventuali carte bianche. Accanto a ciascuna pagina da riprendere potr essere posizionata e scandita la scala millimetrica. Tale indicazione, in particolare, deve necessariamente trovare applicazione nel caso di manoscritti. Per ogni pagina si otterranno tre immagini di diverso formato: 1. TIFF 6.0 non compresso, con risoluzione di almeno 600 dpi ottici e una profondit colore di 24 bit RGB per dimensioni delloriginale inferiori o uguali ad A4, e con risoluzione di 600 dpi ottici e una profondit colore di 24 bit RGB per dimensioni superiori ad A4. Tale immagine destinata alla conservazione fuori linea e come copia di sicurezza (master); 2. JPEG compresso a 300 dpi e con una profondit di colore di 24 bit RGB, destinato alla consultazione in rete locale; 3. JPEG compresso a 72 dpi di risoluzione, o inferiori, con profondit colore di 24 bit RGB e un fattore di riduzione da definire in funzione di unagevole consultazione su rete locale e geografica, tale da consentire la piena leggibilit del contenuto ma non la riproduzione per scopi commerciali.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 48 di 86

Secondo la struttura del sistema prevista nel presente capitolato, loggetto digitale nel formato 1) viene ospitato nella teca del nodo locale. Le immagini nei formati 2) e 3) sopra indicati sono destinate alla trasmissione via rete e perci dovranno essere il pi possibile compatte, ma la buona qualit e la buona leggibilit a video anche sotto ingrandimento sono requisito indispensabile del processo di acquisizione. Verranno concordati di comune accordo tra i nodi aderenti i parametri medi pi opportuni per quanto riguarda il rapporto qualit/compressione. Va sempre previsto il ricorso a programmi di miglioramento e fotoritocco (rimozione del bordo nero esterno, correzione delle micro-rotazioni, rafforzamento del contrasto con filtri di smoothing e di riduzione del rumore, ecc.) 3.3.2.4.2. Fotografie digitali e scansione di fotografie Tra i molteplici campi di applicazione della fotografia al patrimonio culturale musicale, vanno ricordati a titolo di esempio i ritratti di grandi autori e interpreti, le fotografie di scena, le immagini di oggetti fisici non digitalizzabili in altro modo (ad esempio, costumi, attrezzi di scena, marionette,). Nel caso di materiale fotografico, viene meno la necessit di porre una scala millimetrica in corrispondenza della fotografia da digitalizzare. Qualora la fotografia ritraesse un oggetto fisico, si suggerisce invece lapplicazione di una scala millimetrica in corrispondenza del soggetto della fotografia. Non sussiste in generale la necessit di effettuare operazioni di fotoritocco. Si pu comunque prevedere un intervento migliorativo sistematico sul livello di contrasto e dei colori, da effettuare tramite strumenti software commercialmente reperibili (ad esempio, Adobe Photoshop). Le immagini fotografiche presenti nelle teche sotto forma di oggetti digitali possono provenire da due differenti fonti: si pu trattare di fotografie digitali native, acquisite tramite fotocamere digitali, o di digitalizzazioni di fotografie tradizionali su supporto cartaceo. Nel caso in cui la fotografia debba essere digitalizzata (trasferimento da supporto analogico a digitale tramite operazioni di scansione), si suggeriscono i formati di salvataggio dellinformazione gi introdotti precedentemente, ossia: 1. TIFF 6.0 non compresso, con risoluzione di almeno 600 dpi ottici e una profondit colore di 24 bit RGB per dimensioni delloriginale inferiori o uguali ad A4, e con risoluzione di 600 dpi ottici e una profondit colore di 24 bit RGB per dimensioni superiori ad A4; 2. JPEG compresso a 300 dpi e con una profondit di colore di 24 bit RGB, destinato alla consultazione in rete locale; 3. JPEG compresso a 72 dpi di risoluzione, o inferiori, con profondit colore di 24 bit RGB e un fattore di riduzione da definire in funzione di unagevole consultazione su rete locale e geografica, tale da consentire la piena fruibilit del contenuto ma non la riproduzione per scopi commerciali. A questo proposito, si propongono tecniche di marcatura del contenuto con scritte in sovrimpressione da apporre automaticamente sulla versione di media e bassa qualit. Se invece la fotografia stata scattata in formato digitale, per la versione di alta qualit di cui al punto 1) si manterr il formato generato dalla fotocamera digitale. Le versioni di qualit inferiore deriveranno dal formato di cui sopra secondo le indicazioni riportate ai punti 2) e 3). 3.3.2.5. Informazione video Linformazione video quella che pi di ogni altra necessita di notevoli quantit di spazio su disco: basti pensare che per una comune sequenza devono essere memorizzate 25 immagini ogni secondo, oltre naturalmente alla traccia audio. Risulta quindi evidente che gli standard di codifica avranno caratteristiche di qualit (e, di conseguenza, di dimensione) molto diversi, andando a

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 49 di 86

confrontare le scelte utilizzate dai nodi per la conservazione in alta qualit del materiale e i file presenti sul Portale per una fruizione da parte degli utenti Internet o a scopi di preview. Gli standard di codifica che si presentano come scelte possibili per linformazione video sono: MPEG1: creato nel 1993, utilizzato su canali con banda di circa 1 Mbps, ha trovato applicazione nello standard VideoCD, ed ha una qualit comparabile al VHS; MPEG2: creato nel 1995, utilizzato in tutti i contesti in cui occorre alta qualit senza la possibilit o la volont di gestire dati non compressi, trova applicazione nella TV digitale, nel DVD, nellelaborazione video professionale; arriva a utilizzare una banda di 20Mbps; AVI: basato sullutilizzo di vari tipi di codec, che lutente deve necessariamente avere installato sulla propria macchina, ha caratteristiche di qualit diverse e dipendenti dal codec scelto; RealVideo: il formato pi utilizzato nello streaming video, consente di non effettuare il download dellintero filmato, implementando una funzione di buffering dei dati; la qualit da considerarsi accettabile a scopi di preview. Per la digitalizzazione e la conservazione presso la teca del materiale ad alta qualit, si suggerisce ladozione dello standard MPEG2, creando dei master su DVD, oppure dello standard HDTV per laltissima qualit, con risoluzioni che arrivano a 1920x1080 pixel. Per la fruizione da parte degli utenti Internet, risultano essere buone soluzioni la scelta dellAVI compresso DivX per un download a media qualit e il RealVideo come streaming a bassa qualit (il che semplifica al massimo leventuale procedura di download del codec e delle applicazioni proprietarie necessarie per la fruizione del materiale).

3.3.3. Standard di comunicazione e sicurezza


Tutte le comunicazioni e gli interscambi tra i vari nodi del sistema avvengono via Internet tramite opportuni canali fisici. I messaggi interscambiati tra Portale e nodi periferici contengono generalmente informazioni strettamente private. Inoltre, il sistema in questione intrinsecamente eterogeneo, e prevede la possibile e continua aggiunta di nuovi nodi. E dunque necessario utilizzare un set di strumenti H/W e S/W per la comunicazione che favorisca linteroperabilit tra realt eterogenee, allo stesso tempo impedendo che un generico utente possa impossessarsi illegalmente di informazioni riservate. 3.3.3.1. Protocolli La piattaforma di comunicazione via Internet prevede gli standard TCP/IP ed HTTP per lo scambio di messaggi generici via Internet. Come protocolli per la sicurezza, si prevedono TLS (evoluzione di SSL) ed S-HTTP: TLS [www.openssl.org] lavora a livello di socket, tra TCP ed HTTP, e permette una trasmissione sicura tramite crittografia con chiavi a 128 bit; S-HTTP invece opera a livello HTTP e permette una connessione sicura a livello di trasporto tramite installazione lato client di certificati digitali. Luso incrociato di TLS ed S-HTTP permette di creare sessioni di lavoro con autenticazione, e sistemi di trasporto sicure. Per linterscambio di oggetti digitalizzati tra nodi periferici e Portale, la cifratura SSL non sufficientemente sicura in quanto un PC di potenza medio-alta in grado di trovare la chiave e decifrare il m essaggio in un periodo piuttosto breve (nellordine di grandezza di poche ore). E perci previsto luso di blowfish, come ulteriore algoritmo di cifratura degli oggetti digitali da usare in cascata ad SSL (v. Paragrafo 3.3.4).

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 50 di 86

Per le operazioni di interrogazione di metadati e ricerca di oggetti digitalizzati si fa riferimento ad una serie di protocolli che, come detto precedentemente, favoriscano linteroperabilit e la facilit di comunicazione tra nodi intrinsecamente eterogenei. Tali standard sono Z39.50, SRW/U: Z39.50: standard ampiamente in uso in ambiti bibliotecari che fornisce funzionalit di ricerca su cataloghi web OPAC SRW/U: protocollo web basato su SOAP/HTTP ed XML, che fornisce le medesime funzioni dello Z39.50, semplificando per limplementazione e la manutenzione. Essendo basato su SOAP, protocollo promosso da W3C, i messaggi trasmessi sono file XML composti da tre diverse parti, una intestazione che descrive il tipo di messaggio (envelope), il modo in cui esso deve essere processato, la descrizione dei dati trasportati e una convenzione per rappresentare richieste di servizi e risposte tra Portale e nodi. 3.3.3.2. Infrastrutture di comunicazione Nodi e Portale devono prevedere la strumentazione H/W e S/W per la connessione ad Internet. Per favorire la qualit del servizio fornito in termini di efficienza e velocit di comunicazione, Portale e nodi fornitori di oggetti digitalizzati devono prevedere un allacciamento alla rete permanente, tramite banda larga. E invece sufficiente una semplice connessione per nodi fornitori di soli metadati. Per favorire la sicurezza dellintero sistema, Portale e nodi periferici devono essere provvisti di un opportuno firewall SW o HW, evitando cos possibili intrusioni da parte di generici utenti esterni non autorizzati. Ogni nodo deve definire la porta o le porte TCP su cui le comunicazioni dovranno avvenire col Portale. 3.3.3.3. Sicurezza dei sistemi Sia il Portale che i fornitori di servizi devono prevedere un sistema di UPS per la salvaguardia dei dati in caso di improvviso guasto elettrico. Nella scelta dellUPS occorre valutare i seguenti parametri: UPS singolo o multiplo: Si pu optare per UPS singolo o multiplo in funzione del numero di PC da trattare. In presenza di un unico PC, si prevede la presenza di un UPS singolo. Nel caso si debbano gestire pi PC, si pu scegliere la soluzione dellUPS multiplo o di un UPS singolo per ogni PC. A differenza degli UPS multipli, quello singoli hanno una durata di vita minore ma sono pi semplici da gestire; potenza erogata dallUPS: importante definire per quanto tempo lUPS dovr mantenere attivo il PC o i PC dal momento del guasto ed in funzione di questo valore, scegliere la potenza erogata in funzione di quella nominale fornita dal PC. Per esempio, un U che PS fornisce una potenza di 100KWatt/ora ad un PC con potenza nominale di 100KWatt, in grado di tenere attivo il PC per unora intera dal momento del guasto; operazioni da eseguire in caso di guasto: lUPS pu eseguire un shotdown del sistema, eseguendo tutte le operazioni di backup e chiusura nel periodo di attivit fornito dallUPS e/o chiamare automaticamente una persona di riferimento che avr il compito di recarsi sul posto per ripristinare la situazione. Tale persona (o tali persone) dovr fornire disponibilit 24 ore su 24, per lintero anno solare.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI 3.3.3.4. Backup

Pag. 51 di 86

Le procedure di backup sono fondamentali per laffidabilit e il ripristino in caso di guasti ed errori. Infatti, se la configurazione hardware dei dischi RAID completamente ridondata, la possibilit di guasto contemporaneo ed irreparabile su entrambi i vettori di informazione minima. Potrebbe per rendersi necessario il ripristino di uno stato precedente della base di dati a seguito di un intervento errato volontario o involontario (cancellazione di tuple, alterazione degli schemi, ecc.). Inoltre, se la configurazione hardware dellinterfaccia tra ReMI e Portale necessariamente molto solida, non si pu garantire altrettanto per i sistemi locali ai nodi. In tal caso, anche la probabilit di guasto meccanico aumenta, e la disponibilit di backup recenti diventa lunico strumento per non perdere dati preziosi. Il presente paragrafo fornisce indicazioni sulle possibili procedure di backup in generale. In altre parole, vengono individuati metodi standard indipendenti dalla stabilit e dalla robustezza dei sistemi hardware e software sottostanti. In particolare, si riconoscono due grandi categorie di backup: a singolo supporto (basati su supporto unico, ad esempio su nastro) e a libreria. Ovviamente, necessario individuare una tipologia di supporto caratterizzata da adeguata capacit, grande affidabilit, lunga durata garantita e compatibilit futura. Nel caso di backup a singolo supporto, una volta determinata la consistenza numerica dei supporti contemporaneamente disponibili, si pu adottare la seguente procedura standard: realizzare un backup totale del database in ciascun giorno della settimana, ogni volta su un nastro differente; procedere in questo stesso modo sulla seconda settimana, mantenendo come campione della prima settimana un nastro scelto a caso sui 7 precedentemente realizzati; i restanti 6 nastri possono essere sovrascritti e dunque riutilizzati; utilizzare lo stesso algoritmo sulla scala temporale dei mesi: allo scadere del mese, scegliere un supporto campione sui 4-5 relativi alle settimane del mese trascorso, e riutilizzare i restanti; per quanto riguarda gli anni, invece potrebbe essere utile mantenere i 12 supporti campione dei singoli mesi. Un metodo che aggiunge ulteriore sicurezza al protocollo effettuare tali operazioni in differita di un passo temporale. In altre parole, in ogni generico istante si avr: 1 backup per ogni giorno della settimana corrente e di quella precedente, 1 backup alla settimana per il mese corrente e per quello precedente (esclusa ovviamente la settimana di cui sono disponibili tutti i backup); 1 backup al mese per tutti i mesi trascorsi, indipendentemente dallanno. Questo algoritmo porta a recuperare un gran numero di nastri prima di congelarne il contenuto in modo definitivo. La procedura proposta viene normalmente utilizzata per dispositivi di backup a singolo nastro, in cui si vuole avere una disponibilit del dato (retention) con granularit sempre minore nel tempo. Generalmente essa serve per il ripristino logico del dato: ad esempio, una tabella da un file di dump e non un intero data file, che potrebbe renderebbe il database non consistente. Per dispositivi di backup a libreria, si pu ancora usare la procedura proposta, ma generalmente si utilizzano meccanismi pi avanzati, quali ad esempio: utilizzo di tutti i nastri in modalit parallela (striping dei dati sui nastri utilizzando tutti i driver di scrittura); viene usato quando la quantit di nastri per la rotazione permette di avere diversi mesi di on-line, quindi quando le risorse sono abbondanti rispetto alle esigenze; creazione di pool di archiviazione: sono supporti dedicati che contengono i dati con granularit scelta (es. settimanale: ogni settimana viene copiato da nastro, che non appartiene al pool di archiviazione, un full backup) e che possono essere estratti; gli altri

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 52 di 86

nastri, che non appartengo al pool di archiviazione, vengono utilizzati a rotazione continuamente. Esistono poi altre soluzioni ibride, in cui si interviene per tipologia di sistema con mix di backup incrementali, differenziali e/o completi. Esistono inoltre altre tematiche di backup (es. ondine, neartime, offline) che convergono su tecnologie/metodologie di archiving e disaster recovery. I maggiori fornitori hardware di librerie di backup sono HP, Qualstar e StorageTek. Essi propongono soluzioni ad alta capacit ed affidabilit. Ad esempio, la tecnologia Linear Tape Open (LTO) Ultrium arriva ad archiviare su nastro singolo pi di 200 GByte di dati non compressi e garantisce 100.000 operazioni di lettura e scrittura senza guasti, nonch pi di un milione di passaggi del nastro senza guasti. Per occupazioni di spazio superiori, la soluzione da adottare si basa non pi su supporto singolo ma su librerie di supporti.

3.3.4. Standard DRM


Le tecnologie DRM contengono un set di metodi e strumenti standard che permette ai proprietari di contenuti di controllarne laccesso e di definirne le politiche di gestione e fruizione. Nel caso di teche digitali e portali multimediali inerenti materiali musicali necessario considerare le tecnologie DRM come una componente necessaria ed essenziale per tre motivazioni principali: riservatezza: i contenuti multimediali delle teche digitali sono tipicamente caratterizzati rispetto alle funzioni di chi accede agli stessi negli ambiti delle proprie attivit professionali e/o di consultazione; opportunit: i contenuti multimediali delle teche digitali costituiscono il principale elemento di identit delle teche stesse ed perci opportuno che ne mantengano il controllo, soprattutto per quanto riguarda i pi elevati livelli qualitativi di codifica; valore economico: i contenuti multimediali delle teche digitali hanno un potenziale valore economico che deve essere opportunamente protetto, anche al fine di proteggere il valore delle campagne di digitalizzazione e informatizzazione che ne hanno permesso la realizzazione. Per sviluppare una tale piattaforma necessario definire gli attori e le funzioni del sistema di sicurezza, pianificare ed organizzare gli oggetti digitali da inglobare nel DRM ed infine progettare ed implementare il framework software. 3.3.4.1. Definizione di attori e funzioni del sistema DRM Il sistema di sicurezza coinvolge sia il Portale che i singoli nodi ADM / non ADM, e deve fornire una piattaforma tale da permettere di agire sugli oggetti digitali con: interventi di protezione a priori, per impedire laccesso e luso improprio di materiali digitali a utenti del Portale; interventi di controllo a posteriori e tracking automatico, per riconoscere leventuale appropriazione di oggetti digitali da parte di utenti del Portale. 3.3.4.2. Organizzazione degli oggetti digitali da includere nel DRM La fase di organizzazione e pianificazione di diritti e materiali, basilare per un corretto sviluppo e successivo mantenimento del framework DRM. In questo stadio si devono definire gli oggetti digitali protetti ed i relativi diritti, i proprietari di tali diritti, ed eventuali licenze. Pi precisamente necessario:

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 53 di 86

elencare gli oggetti digitali da proteggere con DRM; elencare tutte le tipologie di diritti digitali e licenze; identificare i proprietari dei diritti digitali previste al punto precedente; associare ad ogni oggetto digitale i corrispondenti diritti; definire gli aspetti economici derivati dalla fruizione degli oggetti digitali protetti. E altres necessario svolgere tali operazioni ogni qualvolta un nuovo attore, oggetto o diritto digitale entrasse a far parte del sistema. 3.3.4.3. Specifiche del framework DRM Il framework DRM deve prevedere: un linguaggio per la definizione dei diritti (REL) ed un metodo per lidentificazione ed il reperimento degli oggetti digitali protetti; sistemi per la protezione degli oggetti digitali; gestione delle licenze; sistemi di pagamento; front-end per la creazione ed assegnazione dei diritti digitali e moduli software per la gestione e fruizione degli oggetti digitali. In fase di digitalizzazione, ogni oggetto digitale deve essere identificato con un codice univoco, differente per ogni contenuto mediale: ISRC per loggetto audio; ISMN per loggetto grafico di partitura; ISBN per il testo; EAN per loggetto audio-visuale. Ogni singolo oggetto digitale deve poi essere identificato con un codice univo DOI, ottenuto dagli identificativi precedentemente elencati, su cui il sistema DRM si appogger per eseguire le proprie operazioni (esempio: ISBN: 10.1234/isbn8880622013 dove 10.1234 il prefisso assegnato all'editore e isbn8880622013 l'ISBN della pubblicazione registrata). Infine, per il reperimento fisico degli oggetti testuali e multimediali in locale e via Internet si utilizza il sistema di indirizzamento URI. Come linguaggio REL per la definizione dei diritti digitali preferibile ODRL. ODRL e DOI sono tecnologie indipendenti dalla piattaforma, perci rendono il framework DRM maggiormente interoperabile, facilitando cos la comunicazione tra i vari attori del sistema. Il framework DRM deve prevedere sistemi di protezione a priori tramite cifratura e a posteriori attraverso sistemi di tracciamento automatico delle transazioni. E invece facoltativa la scelta di utilizzare sistemi di controllo a posteriori tramite tecniche di watermarking. Per la protezione a priori durante lintescambio degli oggetti digitalizzati tra nodi periferici e Portale, richiesta la cifratura con algoritmo di crittografia simmetrico blowfish. Si opta per questo algoritmo in quanto non brevettato e di pubblico dominio, computazionalmente veloce e tra i pi sicuri attualmente in commercio. Le chiavi private generate devono avere lunghezza pari ad almeno 128 bit. Per interventi di controllo a posteriori, il Portale deve fornire un sistema di tracking automatico delle transazioni effettuate sugli oggetti digitali. Per ogni oggetto, il Portale deve salvare -in un opportuno file di LOG- tutte le informazioni relative alle transazioni effettuate (nome utente, identificativo oggetto digitale, tipo di fruizioni, ecc.), fornendo la possibilit di effettuare ricerche mirate o creare statistiche e su tali dati. E inoltre previsto, ma non richiesto in questa fase, luso di tecniche di watermarking per interventi a posteriori, al fine di riconoscere leventuale copia illegale o luso improprio di un oggetto digitalizzato. E compito del Portale creare oggetti digitali muniti di watermark. Come sistema di watermarking si pu optare per un prodotto commercialmente reperibile (per esempio

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 54 di 86

AudioKey, MP3Stego, Nabster) o per uno sviluppo ad hoc del software. In entrambi i casi comunque necessario definire la lunghezza della parola di watermark ed il livello di sicurezza che si vuole ottenere in termini di numero di possibili degradazioni applicabili alloggetto digitale, affinch il watermark resti comunque visibile. Infine, necessario definire il livello di percettibilit acustica del watermark inserito e valutare se la qualit audio cos ottenuta pu essere ritenuta soddisfacente per i servizi di fruizioni da fornire. Ogni qual volta il Portale riconosce la presenza nei nodi periferici di nuovi materiali da rendere fruibili sul Portale, deve immagazzinarli automaticamente nel database centrale eseguendo le seguenti operazioni, illustrate in Figura 2: lato nodo periferico, compressione e successiva cifratura delloggetto digitalizzato tramite blowfish; trasmissione delloggetto digitalizzato compresso e cifrato e della relativa chiave tramite protocollo sicuro S-HTTP / TSL; TSL esegue una ulteriore cifratura e ci significa proteggere la chiave con cifratura singola e loggetto con cifratura doppia, aumentando cos la sicurezza nella trasmissione; lato Portale, decifratura delloggetto digitalizzato, successiva archiviazione nel database ed aggiornamento del file di LOG. La gestione delle licenze centralizzata, e perci gestita dal Portale affinch lutente possa eseguire solo operazioni on-line general purpose. Tale scelta giustificata dalla maggiore affididabilit e sicurezza che un tale sistema fornisce rispetto alla gestione decentralizzata lato client, maggiormente vulnerabile a possibili attacchi e manomissioni.

Rete ADM
Postazioni Extranet
OPAC OPAC

Extranet
Interfaccia ADM-Extranet

Rete ReMI
(evoluzione di ADM)

Teca digitale

Data Server

Teca digitale

Data Server

Nodo ADM
Compressione

Nodo ADM

+
Cifratura

Biblioteca Digitale Italiana Network Turistico Culturale (BDI&NTC)


TS L
OPAC OPAC generale

OPAC

S-H TTP /

Teca digitale

Data Server

Teca digitale

Data Server

Teca digitale generale

Data Server

Decifratura

Nodo ADM

Interfaccia ReMI-Portale

Portale BDI&NTC
/T SL

OPAC

HT TP

/ TP HT S-

/T

SL

L TS

Interfaccia Internet

S-

Teca digitale

Data Server
OPAC

Internet

Nodo non ADM

Compressione

+
Cifratura
Server

Compressione

SHT TP

Nodo non ADM

+
Cifratura

Postazioni utente Postazioni utente

Server

Figura 2. Trasferimento sicuro dei dati multimediali

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI 3.3.4.4. Sistemi di pagamento

Pag. 55 di 86

Il portale deve fornire opportuni sistemi di pagamento, integrandosi con quelli standard previsti dal mondo bancario. Tutti le transazioni economiche tra portale e utenti Internet devono avvenire tramite protocollo sicuro S-HTTP / TSL, ed opportuna autenticazione da parte dellutente. Nellambito di questo progetto, la fase di realizzazione prevede il pagamento tramite carte di credito e carte prepagate, contemplando il circuito Bancomat solo in una fase successiva, con ladesione al sistema Bankpass, una modalit operativa impiegata dalle banche per i pagamenti via Internet. Linterfaccia tra Portale e sistemi di pagamento bancari avviene tramite POS virtuale che permette di effettuare transazione on-line tramite carte di credito e carte prepagate con riscontro immediato sul risultato della richiesta di pagamento. 3.3.4.5. Moduli SW di front-end del framework DRM I vari moduli SW che compongono il fornt-end del framework devono soddisfare le specifiche minime qui di seguito riportate. E comunque prevista la possibilit di ampliarle, in funzione delle necessit che via via si possono presentare. In fase di creazione il front-end deve permettere: la creazione dei diritti digitali tramite ORDL specificandone il proprietario (o i proprietari); la validazione o revisione dei diritti digitali nei materiali gi esistenti, in un flusso di interscambio. In fase di gestione e commercializzazione il front-end deve fornire: funzioni di trading per lassegnazione di diritti e licenze ad utenti e attori del sistema; funzioni di repository per laccesso e la fruizione agli oggetti digitali protetti in funzione dei diritti digitali associati ad utenti ed attori del sistema. In fase di implementazione, si prevede la possibilit di impiegare sia tecnologie sviluppate ad hoc che SDK o tool gi esistenti, come per esempio Fairplay (Apple), Windows Media (Microsoft), Helix (Real Network) o LWDRM (Fraunhofer).

3.3.5. Standard di interfaccia uomo-macchina


Uninterfaccia uomo-macchina un sistema multimediale multimodale di elementi informativi che consente il controllo di azioni capaci di tradurre un atto umano in istruzioni comprensibili per i sistemi informativi (premere il tasto con il simbolo delle forbici per segnalare a un editor di testo lintenzione di tagliare una porzione di scritto, selezionare il simbolo dellaltoparlante per ascoltare la riproduzione di un brano audio, etc.). La funzione dellinterfaccia come spazio di comunicazione tra luomo e lapplicazione software pu essere attribuita solo ed esclusivamente a condizione che linterfaccia stessa sia dotata di un adeguato formato rappresentazionale. Linterfaccia di un editor di suono prima di mettere lutente in condizioni di manipolare laudio deve infatti comunicare a questultimo la sua funzione, in modo che non possa essere scambiato, ad esempio, con un browser per la navigazione in rete. Tutto ci significa che la prima funzione dellinterfaccia deve essere quella di comunicare la funzione dellapplicazione software (la sua destinazione duso) e in secondo luogo la sua modalit duso (come utilizzare loggetto). La priorit comunicativa di carattere generale (la destinazione duso) deve evidenziare la funzione informativa dellinterfaccia rispetto alla sua funzione operativa. Lutente deve essere messo in condizione di non fraintendere la funzione dellapplicazione SW. Nel proporre un adeguato formato rappresentazionale, necessaria lindividuazione di opportuni codici comunicativi, per i quali lergonomia classica inizia un tipo di intervento sistematico e metodologico proponendo regole di progettazione comuni per qualsiasi artefatto

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 56 di 86

destinato alluso umano. In questo senso, nella progettazione di interfacce, si segnalano due discipline: il disegno industriale per quanto riguarda gli aspetti pi generali della comunicazione e lergonomia cognitiva per quanto riguarda questioni pi specifiche relative alle modalit duso. 3.3.5.1. Aspetti ergonomici e usabilit Nella progettazione e sviluppo dellinterfaccia del software in oggetto, necessario prendere in considerazione gli aspetti ergonomici e di usabilit. L'ergonomia classica si occupa delle interazioni uomo-macchina-ambiente sotto il profilo operativo. Pi recentemente il campo dindagine e di intervento ergonomico ha investito lambito dei processi psicologici e della percezione, originando lergonomia cognitiva. A differenza dellergonomia classica quella cognitiva pone al centro della propria attenzione tutti quei processi che richiedono l'acquisizione e l'uso della conoscenza. L'ergonomia cognitiva studia le interazioni uomo-macchina-ambiente in cui entrano in gioco fattori cognitivi ed emotivi, legati alle dinamiche di percezione, apprendimento, memorizzazione e problem solving e lo studio dei pi importanti fenomeni ad essi collegati, con una branca principale ed estesa che la cosiddetta HCI (Human-Computer Interaction) ovvero lo studio delle dinamiche interattive uomo-computer. Dal punto di vista dellergonomia cognitiva lusabilit di unapplicazione software fortemente condizionata dalla correttezza del modello mentale del progettista in relazione allutente a cui lartefatto destinato. La logica di progettazione dovr rispecchiare la logica dinterazione applicata dallutente, secondo i profili stabiliti per lapplicazione. E necessario considerare che il formato in cui l'informazione in input viene presentata influenza in modo cruciale la performance dei soggetti in un dato compito cognitivo. La definizione di usabilit dell'International Standard Organization (ISO) recita: "efficacia, efficienza e soddisfazione con i quali gli utenti raggiungono determinati obiettivi in determinati ambienti." (ISO 9241, Ergonomic requirements for office work with visual display, Part 11) Per efficacia si intende il grado di raggiungimento di un obiettivo. La misura dell'efficacia pone in relazione gli obiettivi prefissati con l'accuratezza e completezza dei risultati raggiunti. Lefficienza pu essere definita come l'ammontare dello sforzo da impiegare per portare a termine un compito. La misura dell'efficienza si basa sul rapporto tra il livello di efficacia e l'utilizzo di risorse, che pu essere misurato, per esempio, in termini di numero di errori che l'utente compie prima di completare un compito, o in termini di tempo impiegato per raggiungere il proprio scopo. Se l'utente riesce a completare un compito senza errori, il sistema pi efficiente di un altro che invece costringa l'utente all'errore. In ogni caso, il metodo pi classico per la misura dell'efficienza il conteggio del tempo impiegato per svolgere un compito. Chiaramente, maggiore la velocit, maggiore l'efficienza. La misura della soddisfazione descrive l'utilit percepita dell'intero sistema da parte dei propri utenti, e il livello di comfort avvertito dall'utente nell'utilizzare un determinato prodotto. Si tratta di un aspetto dell'usabilit molto pi soggettivo e difficile da misurare, rispetto ai parametri di efficienza ed efficacia. Per, in molti casi, pu essere considerato il parametro pi importante. Probabilmente, il modo pi semplice per misurare la soddisfazione percepita dagli utenti nell'utilizzo di un prodotto quello di interrogarli in proposito (User Acceptance Test). Ci pu essere fatto per mezzo di un questionario o di una intervista ovvero annotando ogni commento pronunciato dalle persone durante l'utilizzo del sistema. Anche se un'analisi qualitativa della soddisfazione degli utenti un buon indicatore, pu essere utile quantificare gli atteggiamenti nei riguardi di un prodotto. Per esempio, il ricercatore pu essere interessato a confrontare due differenti prodotti in termini di atteggiamenti degli utenti nei loro confronti o a verificare se un prodotto raggiunga determinati livelli (benchmark) di soddisfazione: a questo scopo, sono stati sviluppati diversi questionari standard e strumenti basati sull'intervista per misurare la componente di soddisfazione dell'usabilit.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 57 di 86

I tre fattori principali sopra citati, per essere valutati, debbono essere scomposti in sub-fattori, e, infine, in misure di usabilit. I sub-fattori in questione, sempre secondo la definizione ISO, sono (part 12): chiarezza, discriminabilit, concisione, coerenza, individuabilit, leggibilit, comprensibilit: questi fattori riguardano il modo in cui l'informazione deve essere presentata e rappresentano l'aspetto statico, esteriore, grafico, dell'interfaccia; adeguatezza al compito, auto-descrizione, controllabilit, conformit alle aspettative dell'utente, tolleranza dell'errore, possibilit di personalizzazione, adeguatezza all'apprendimento: questi fattori concernono il lato pi prettamente cognitivo dell'interazione utente-interfaccia. Dal momento che non esistono parametri universalmente riconosciuti per la progettazione delle interfacce Web, lusabilit si avvale di una serie di principi, definiti euristiche, che offrono indicazioni generali sulla base delle quali i realizzatori possono orientare le proprie scelte in fase di progettazione. Si tratta di principi che hanno un elevato valore predittivo perch rappresentano la sintesi dei problemi di usabilit pi frequenti. 3.3.5.2. Aspetti di interazione Prima di fornire indicazioni orientate al progetto e allo sviluppo, diamo qualche considerazione derivata da ricerche scientifiche nel campo dellinterazione uomo-macchina. Nelle applicazioni software di tipo browser: pi del 90% degli eventi di interazione navigazionale: 52% degli eventi: link following; 41% degli eventi: bottone back; solo il 2% delle URL visitate digitato esplicitamente; sono molto frequenti i modelli di navigazione hub&spoke, con pagina centrale a cui si ritorna dopo le esplorazioni; il tempo di permanenza nella visita di una pagina web generalmente inferiore ai 5 secondi e difficilmente superiore ai 10; le principali difficolt sono dovute a: disorientamento (dove sono? dove devo andare?); digressioni (la sindrome del telecomando); troppa informazione (la sindrome del museo); smarrimento dellinformazione trovata (risolvibile usando bookmark e strumenti analoghi). In sintesi, nelle pagine web si suggerisce unarchitettura dellinformazione basata sulla creazione di sistemi consistenti e funzionali per la navigazione, la grafica, la struttura delle pagine e la titolazione, in modo che lutente sappia dove andare, che cosa fare, e sia incoraggiato a tornare. Considerazioni analoghe valgono per le applicazioni software pi in generale. Tra le organizzazioni tipiche dellinformazione (lineare, gerarchica, a matrice, a rete, ibrida) nelle e tra le pagine dellinterfaccia uomo-macchina, e in particolare nelle pagine web, certamente da privilegiare unorganizzazione ibrida che fornisca contemporaneamente la flessibilit dellorganizzazione a rete e la strutturazione delle organizzazioni lineari e gerarchiche opportunamente combinate. I criteri di aggregazione dellinformazione nelle pagine di interazione delle applicazioni software e nelle pagine web devono essere principalmente: organizzazione content driven (si raggruppano contenuti fra loro simili); organizzazione user driven (si raggruppano contenuti di interesse per una medesima categoria di utenti); organizzazione task driven (si raggruppano contenuti relativi a uno stesso compito).

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 58 di 86

Inoltre, al fine di soddisfare le esigenze di interazione, le applicazioni software devono essere realizzate fornendo le seguenti caratteristiche funzionali: interrompibilit: ogni utente deve essere in grado di interrompere lattivit in corso in qualunque istante; degrado morbido: quando si arriva a una richiesta che il sistema non in grado di soddisfare, questo non comporta la terminazione dellinterazione; accesso e orientamento: strumenti che consentano di arrivare agilmente allinformazione desiderata e di sapere in che luogo del sistema informativo ci si trovi; per laccesso sono da considerare di utilit elementi informativi quali: indice dei contenuti ecco come strutturata linformazione, e dove si trovano le varie parti, indice analitico ecco dove si parla di questo argomento, rimandi nel testo ecco dove trovi altre informazioni su questo argomento, segnalibro ecco dove sei arrivato a leggere, per lorientamento sono da considerare di utilit elementi informativi quali: header, footer, numero di paginaecco dove ti trovi, titoli, sottotitoli qui inizia questo argomento, FAQ, risposte alle domande pi frequenti. 3.3.5.3. Interfacce multimediali multimodali In relazione allambito specifico dellinformazione musicale, sono da considerare aspetti legati allinterazione con informazione multimediale secondo approcci di multimodalit, in parte da considerare come tecnologie disponibili ma ancora in fase di sperimentazione. In particolare: partiture: riconoscimento automatico della codifica simbolica dellinformazione musicale contenuta (OMR Optical Music Recognition); inserimento di informazione musicale in partitura con interfaccia multimodale (tastiera musicale, mouse, tastiera ASCII, pedali); indicizzazione automatica mediante riconoscimento di frasi e caratteristiche musicali nelle partiture; ricerca di informazione musicale integrata tra parole chiave e frammenti di partitura; audio: indicizzazione automatica mediante riconoscimento di caratteristiche musicali nei segnali audio; trascrizione automatica audio/MIDI; ricerca di informazione musicale integrata tra parole chiave e frammenti audio; riproduzione di audio digitale da vari formati; riproduzione audio di sequenze MIDI; partiture/audio: sincronizzazione automatica di segnali audio musicali con le relative partiture; ricerca di informazione musicale integrata tra parole chiave, frammenti audio e frammenti di partitura. 3.3.5.4. Accessibilit e usabilit per utenti con problemi Lusabilit di un prodotto software ad elevato grado di interattivit, quale per esempio unapplicazione di tipo multimediale multimodale, richiede particolare cura nel progetto

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 59 di 86

dell'interfaccia uomo-macchina, delle funzioni da essa offerte e delle modalit di interazione in funzione degli obiettivi dell'applicazione. Il progetto di uninterfaccia deve avere come obiettivo il trasferimento appropriato dell'informazione, anche tramite l'individuazione delle metafore di dialogo pi opportune, la scelta appropriata di segni e simboli grafici, la definizione dei modelli di utente e di sistema e delle modalit di selezione e navigazione nella applicazione, nonch dell'aspetto del prodotto. L'analisi riguarda le modalit di integrazione di media testuali, visuali, audio e gestuali nel trasferimento dell'informazione e lo sviluppo di moduli software per la derivazione delle misure dei parametri di interazione dell'utente con l'interfaccia per arrivare ad una stima dell'usabilit. In considerazione di queste motivazioni, le applicazioni software, e in particolare quelle che permettono laccesso ai contenuti di un Portale, devono essere realizzate tenendo conto delle raccomandazioni WAI (Web Accessibility Initiative) elaborate per conto del W3C (World Wide Web Council). Il W3C si proposto lobiettivo di promuovere il massimo grado di "usability" del Web da parte delle persone con disabilit, in collaborazione con varie organizzazioni in tutto il mondo e attraverso lo sviluppo di cinque aree primarie di intervento: tecnologie, linee guida per la progettazione del software, strumenti tecnologici, addestramento, ricerca e sviluppo. In particolare si deve far riferimento, nella progettazione delle applicazioni software, alle "Web Content Accessibility Guidelines" del 5 maggio 99 il cui obiettivo principale quello di promuovere laccessibilit dei siti. Queste raccomandazioni mirano a rendere il contenuto dei siti pi accessibile per tutti gli utenti, a prescindere dallinterfaccia uomo-macchina usata (browser per PC, browser a voce, telefono cellulare etc.) o dalle condizioni di utilizzo (mani libere, ambienti rumorosi o poco illuminati etc) incluse quindi le difficolt dellutente. Le linee guida non scoraggiano luso di contenuti pi sofisticati quali video, immagini suoni etc. ma piuttosto spiegano come rendere un contenuto multimediale pi accessibile ad un pubblico pi vasto ed eterogeneo. In ogni caso nello sviluppo di una pagina Web va considerato che lutente che accede ad un sito pu trovarsi ad affrontare diverse difficolt legate ai mezzi che usa, allambiente in cui opera o infine alle proprie esigenze personali speciali. Lapproccio proposto migliora laccessibilit del sito per gli utenti in generale ma in particolare, per ciascuna delle tipologie di difficolt analizzate, rende possibile una migliore accessibilit alle informazioni in Internet per intere categorie di persone con disabilit o esigenze speciali. Per attuare queste linee progettuali specifiche necessario articolare diverse aree tematiche; per esempio: barriere architettoniche, ausili, riabilitazione, informazione medica, normativa, mobilit, turismo, disabilit al femminile, tecnologia del Portale. Lobiettivo quello di tarare sin dallinizio i servizi sulle reali (da conoscere) esigenze degli utenti. La fase di attuazione progettuale per ogni area tematica prevede le seguenti fasi operative: ricerca, raccolta ed elaborazione delle informazioni necessarie alla realizzazione del servizio in oggetto; creazione e gestione delle relative pagine web sul Portale; sviluppo di servizi a valore aggiunto per i disabili sulla specifica tematica; servizio di call center telefonico di informazione, formazione e consulenza sulla specifica tematica.

3.3.6. Standard di validazione e tuning delle prestazioni


Le prestazioni di un sistema di elaborazione possono essere definite in molti modi diversi. Il singolo utente del sistema interessato a ridurre il tempo di risposta, cio il tempo fra l'inizio e il completamento di un lavoro (detto anche tempo di esecuzione). I gestori del sistema sono invece spesso interessati ad aumentare il throughput, ossia la quantit di lavoro eseguita nell'unit di tempo.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 60 di 86

I due approcci sono differenti, ma devo essere tenuti ugualmente in considerazione. Come si sottolineer nel capitolo dedicato alla soddisfazione degli utenti, questi sono interessati soprattutto al tempo di risposta. Per sviluppare tecniche che consentano di migliorare le prestazioni, importante comprendere e ridurre le differenti fonti di ritardo nel tempo di risposta rilevato dagli utenti finali. I ritardi introdotti da tutti i componenti, hardware e software, coinvolti nellesecuzione di un servizio sono cumulativi. Dunque, al fine di diminuire il tempo di risposta end-to-end, necessario dapprima individuare e quindi migliorare le singole componenti nella catena, e principalmente quelle pi lente. Nel progettare e implementare un sistema quale la rete ReMI per fondamentale anche il throughput, che nel caso specifico consiste nella capacit di rispondere alle richieste simultanee di molti utenti. 3.3.6.1. Prestazioni delle applicazioni software Le prestazioni di unapplicazione software non possono prescindere dallhardware su cui lapplicazione deve girare. In definitiva, la misura delle performance del software deriva in realt da una valutazione complessiva. La misura delle prestazioni di un sistema di elaborazione il tempo. Il tempo di esecuzione di un programma misurato generalmente in secondi o suoi sottomultipli. Comunque il tempo pu essere inteso in modi diversi: tempo assoluto (absolute time), tempo di risposta (response time), o tempo trascorso (elapsed time). Tutti questi termini indicano il tempo totale per completare un lavoro, includendo gli accessi ai dischi, gli accessi alla memoria, le attivit di ingresso e uscita, il sovraccarico dovuto al sistema operativo, quindi in sostanza tutte le attivit per portare a termine un lavoro. Tuttavia i calcolatori lavorano spesso in time-sharing e pu accadere che un processore stia lavorando su pi programmi contemporaneamente; in questa situazione il sistema pu cercare di massimizzare la produttivit complessiva anzich minimizzare l'elapsed time di un singolo programma. Di conseguenza utile distinguere tra il tempo trascorso ed il tempo durante il quale il processore ha lavorato con un determinato obiettivo: il tempo di esecuzione della CPU, detto anche tempo di CPU, tiene conto di questa distinzione ed il tempo speso dalla CPU nell'elaborazione richiesta per raggiungere un obiettivo, non includendo il tempo speso nell'attesa di compiere operazioni di I/O o per eseguire altri programmi. In ogni caso, il tempo di risposta percepito dall'utente il tempo trascorso nell'esecuzione del programma e non il tempo di CPU. Obiettivo primario per la soddisfazione del singolo utente dunque minimizzare il tempo trascorso nellesecuzione del programma. Questo obiettivo deve essere perseguito secondo le seguenti direttive: effettuando una fase approfondita di analisi dei requisiti; ottimizzando il codice; migliorando lusabilit; operando il tuning delle prestazioni in fase post-produzione. 3.3.6.2. Usabilit dellinterfaccia uomo-macchina Per quanto riguarda lusabilit di un sistema con interfaccia uomo-macchina, ci si rif allarticolo Progettazione ed usabilit dei sistemi accessibili di Gianluigi Raiss, in N.5 Informazioni, Autorit per lInformatica - ANNO II Set-Ott 2000. La ISO/IEC 9126-1, norma che definisce un modello delle caratteristiche qualitative di un prodotto software, descrive il termine qualit del software come la capacit di un prodotto di aiutare determinati utenti a raggiungere determinati obiettivi con efficacia, efficienza, sicurezza e soddisfazione, in determinati contesti duso. Il messaggio trasmesso semplice: lobiettivo di un

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 61 di 86

progetto di informatizzazione non fornire un prodotto senza difetti o ricco di funzionalit o tecnologicamente innovativo, ma la produttiva interazione tra un sistema software e lutente che ne fa uso. Per essere pi precisi, linterazione deve consentire laumento dellefficienza delle persone nello svolgere i loro compiti lavorativi, senza che ci comporti inutili costi aggiuntivi alla organizzazione, n disagi, pericoli o motivi di insoddisfazione allutente, od impatti non desiderati sul contesto duso e/o sullambiente, n lunghi tempi di apprendimento, assistenza, manutenzione. Secondo unaltra recente norma ISO, la 9241-11, lusabilit da intendersi come la capacit di un prodotto di agevolare uno specifico utente nel raggiungimento di specifici obiettivi con efficacia, efficienza e soddisfazione in uno specifico contesto duso. Secondo la norma ISO 9241, un sistema usabile quello che si adatta al contesto nel quale lavora lutente, permettendogli di utilizzare al meglio le conoscenze che gi possiede, incrementando la sua produttivit e la qualit del risultato ottenuto tramite lutilizzo dellapplicazione informatizzata. Si tratta, evidentemente, di obiettivi non strettame nte tecnologici e tantomeno correlati a caratteristiche interne del prodotto. Le sottocaratteristiche che la norma ISO/IEC 9126 attribuisce allusabilit sono la comprensibilit (la capacit di un prodotto software di mettere in condizione lutente di capire se appropriato alle esigenze, e come pu essere utilizzato per svolgere un determinato compito in determinate condizioni duso), la apprendibilit (la capacit del prodotto software di mettere in grado lutente di apprenderne luso), la operabilit (la capacit del prodotto software di mettere in condizione lutente di compiere operazioni con il prodotto e di mantenerne il controllo). Il livello di possesso di tali requisiti misura in un sistema la distanza tra il designer model, ovvero il modello del sistema informatico e delle sue modalit duso posseduto dal progettista, e lo user model, il modello di funzionamento del sistema che lutente si costruisce e che regola la sua interazione col sistema stesso. Quanto pi i modelli sono vicini, tanto pi il sistema da considerarsi usabile. In questo senso, il livello di usabilit di un prodotto software la risultante del sistema prodotto - utente che lo usa - contesto di utilizzo. Per specificare correttamente il requisito di usabilit di un sistema informatico, necessario identificare: gli obiettivi posti al sistema ; le componenti del contesto duso, inclusi utenti, processi, attrezzature, ambiente; i valori attesi dallutente di efficacia, efficienza e soddisfazione nelluso. Questi elementi devono essere decomposti nelle loro componenti, fino a quando sia possibile identificarle con attributi misurabili e verificabili. Ad esempio, gli utenti devono essere descritti per conoscenze, esperienze, formazione, attributi fisici, capacit motorie e sensoriali e raggruppati per classi in base alle affinit. I processi interessati dallinformatizzazione devono essere descritti dettagliatamente, inclusa lallocazione di attivit tra le risorse umane e quelle tecnologiche. Oltre che alle funzioni svolte, gli elementi in entrata ed in uscita, le trasformazioni prodotte, i passi eseguiti, devono essere correlati agli obiettivi da raggiungere. Lambiente di utilizzo del sistema deve essere descritto in termini fisici, ambientali (ad es: temperatura, umidit), sociali e culturali. Un esempio di attributi del contesto duso nella tabella in Annex A della norma ISO 9241. I requisiti-base che deve possedere un sistema applicativo usabile sono definiti dalla norma ISO 9241-10. 3.3.6.3. Prestazioni delle infrastrutture di comunicazione Innanzi tutto, necessario analizzare le caratteristiche dei carichi di lavoro, al fine di identificare le cause delle fluttuazioni di traffico sulla rete. Tali fluttuazioni infatti contribuiscono alla congestione temporanea dei componenti di rete e divengono cos fonte primaria di incrementi nel tempo di risposta.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 62 di 86

Come accennato precedentemente, un primo fattore da valutare nella valutazione delle performance legato alle prestazioni delle applicazioni software. A questo proposito, noto che a livello applicativo il carico di lavoro trasmesso alla rete si distribuisce in blocchi di traffico intenso (burst), il che provoca ulteriore congestione. La complessit dellinfrastruttura di rete e il comportamento dei protocolli di trasposto e di rete scelti giocano un ruolo fondamentale nella propagazione delle fluttuazioni dal livello di applicazione al livello di collegamento. La larghezza di banda, per quanto concerne la rete ReMI, deve essere bilanciata in modo da consentire il rapido trasferimento di oggetti multimediali. Si segnala che, comunque, la larghezza di banda non lunico dei fattori a limitare lefficienza di un sistema basato su uninfrastruttura di rete. Rifacendosi anche allo schema sotto riportato, riguardo il tempo di risposta da capo a capo (end-to-end) possibile affermare che le sue componenti principali ricadano in tre categorie principali: lato client, lato server e architetture e protocolli di rete. La rete ReMI deve essere progettata in modo da ridurre al massimo i ritardi end-to-end sui differenti rami evidenziati nel diagramma dellarchitettura generale. Si ricorda che talvolta i nodi ReMI sono contemporaneamente client e server.

Figura 3. Comunicazione end-to-end tra fruitore e fornitore di informazioni

In conclusione, le scelte proposte riguardo le infrastrutture di comunicazione devono dunque tenere in giusta considerazione i protocolli e gli schemi di collegamento gi noti in letteratura e comunemente adottati. Le decisioni sulle tecnologie da adottare devono in ogni caso essere guidata anche dalle considerazioni sulle prestazioni del sistema finale, considerato nella sua interezza.

3.3.7. Qualit e prestazioni dei servizi Web


3.3.7.1. La soddisfazione degli utenti Affrontando la tematica della qualit dei servizi Web, si toccano ambiti distinti ma interdipendenti: lefficienza, lefficacia, la sicurezza e la disponibilit del sistema. Lobiettivo primario da conseguire la soddisfazione degli utenti. Un sito lento fonte di insoddisfazione, che si traduce sul breve termine nellabbandono del percorso di visita corrente, e sul lungo termine nella mancata fidelizzazione dellutente, che non torner pi sul sito in oggetto. Da una ricerca condotta nel 2001 da Forrester, emerge che il 42% degli utenti insoddisfatti dalle prestazioni di un sito Web non lo visiter pi. Da un sondaggio di Radio24 Il Sole 24Ore di gennaio 2001, risulta che il difetto del Web maggiormente evidenziato e fastidioso per gli utenti la lentezza di collegamento (53% dei votanti). La soddisfazione dellutente pu essere considerata come un bilancio tra pazienza e frustrazione. Allaumentare dei tempi di risposta, diminuisce la pazienza e aumenta la frustrazione. Quando poi la frustrazione supera la soglia della pazienza, scatta linsoddisfazione. Un primo aspetto interessante la quantificazione statistica dei livelli di soglia di sopportazione. Come viene percepito il tempo da parte delle persone? Certo esiste una componente

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 63 di 86

psicologica difficile da indagare, per alcuni dati sperimentali possono rendere il discorso pi oggettivo. Unattesa inferiore a 1/10 di secondo d la percezione di un evento immediato; lattesa di 1 secondo corrisponde al botta e risposta tra interlocutori; un tempo di attesa di 10 secondi corrisponde a un dialogo in cui le risposte sono ragionate. A questo punto, si ipotizzino tre livelli di soddisfazione da parte dellutente: pienamente soddisfatto, mediamente soddisfatto, insoddisfatto. Da ricerche condotte su un campione di utenti e documentate in [1], risulta che allaccesso di una pagina Web statica lutente risulta pienamente soddisfatto per un tempo di risposta inferiore a 5 secondi, mediamente soddisfatto tra i 5 e i 10 secondi e certamente insoddisfatto dopo 10 secondi. I tempi di visualizzazione nel browser di una pagina dinamica sono certamente superiori, in quanto al tempo di risposta del server e al tempo di trasmissione della pagina sulla rete va aggiunto il tempo di calcolo della pagina dinamica (risoluzione di query, costruzione del layout, ). Gli utenti possono esser resi pi tolleranti tramite un continuo feedback da parte del sistema, ad esempio grazie a barre di avanzamento (soluzione poco adatta alle interfacce Web) o al cosiddetto incremental loading. Questultimo stratagemma consiste nel caricare la pagina un pezzo per volta, inviando per prime le informazioni utili e salienti e successivamente quelle di contorno. Una tipologia specifica di incremental loading consiste nel partizionare i risultati su pi pagine. In tal modo, anche le ricerche con un gran numero di risultati possono essere condotte e visualizzate in un tempo relativamente breve e soddisfacente per lutente. Grazie allincremental loading, gli intervalli di sopportazione (espressi in secondi) si ridistribuiscono nel modo seguente: utente pienamente soddisfatto: t < 10 (caso medio); t < 30 (caso ottimistico); utente mediamente soddisfatto: 10 < t < 30 (caso medio); 30 < t < 60 (caso ottimistico); utente insoddisfatto: t > 30 (caso medio); t > 60 (caso ottimistico). Questo perch lutente viene messo al corrente dei tempi di attesa richiesti, il che lo predispone positivamente allemissione differita nel tempo dei risultati. Un altro aspetto fondamentale della soddisfazione degli utenti legato al numero di passi della navigazione. Infatti, la frustrazione di cui si precedentemente parlato cumulativa, ossia aumenta con il procedere della navigazione. Contemporaneamente, la soglia di sopportazione dellutente decresce. Ci implica che poche pagine lente possano soddisfare pi di tante pagine veloci. Nelle navigazioni con molti passi l'utente tende a smarrirsi; da qui discende la necessit di garantire percorsi di navigazione sufficientemente rapidi nel fornire risultati, soprattutto allutente affezionato che in grado di muoversi con scioltezza attraverso le pagine dellinterfaccia Web. Le aspettative degli utenti verso le prestazioni del sistema dipendono anche dalloperazione eseguita. In generale, sulla base dellesperienza pregressa, allutente noto che determinate operazioni richiedano pi tempo e pi risorse computazionali rispetto ad altre. Ad esempio, una ricerca specialistica (molti criteri, pochi risultati attesi) o generica (pochi criteri, molti risultati attesi) comporta solitamente unalta tolleranza ai tempi di attesa, purch il sistema dia segni di reattivit. Viceversa, assai bassa la tolleranza dellutente di fronte ad attese di altro genere, ad esempio in conseguenza della pressione del tasto Back o dellapertura di una pagina di contenuti statici. 3.3.7.2. Indici di prestazione Web Per valutare le prestazioni del sistema cos come vengono percepite dallutente finale, necessario introdurre alcuni indici di prestazione per il Web. Tali indici sono pesantemente influenzati da fattori quali i tempi di connessione, i tempi di risoluzione delle query, le dimensioni degli oggetti digitali da trasmettere, e via dicendo. Tra gli indicatori che forniscono maggior risalto alle prestazioni percepite dallutente finale, si segnala:

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 64 di 86

la latenza, ossia il tempo che intercorre tra listante in cui lutente invia una richiesta e quello in cui cominciano ad arrivare i risultati; la risposta, ossia il tempo che intercorre tra listante in cui lutente invia una richiesta e quello in cui tutti i risultati sono arrivati; il throughput, ossia la frequenza con la quale vengono elaborate le richieste da parte del server. In fase di progettazione del sistema, di tuning delle prestazioni, di testing e di verifica, lobiettivo minimizzare la latenza e la risposta percepite dallutente finale, e massimizzare il throughput da parte del sistema centrale. Le prestazioni di un sistema complesso possono essere migliorate facendo leva su molteplici aspetti. Innanzi tutto, la connettivit a Internet deve essere ottimale, in funzione delle visite contemporanee previste e del tipo di traffico generato. Ad esempio, una consultazione di metadati ha un impatto molto inferiore sulle risorse del sistema rispetto al download di un oggetto multimediale. Larchitettura del sistema centrale deve prevedere pi connessioni in uscita verso Internet. Gli ISP coinvolti devono presentare connessioni dirette ai principali backbone, e dunque devono essere selezionati sulla base del numero di hop necessari per raggiungere le dorsali. Un altro aspetto di fondamentale importanza la replicazione delle risorse contese, tramite caching e content distribution services. Questultimo approccio si chiarisce secondo la seguente definizione:1 Content Distribution Networks attempt to reduce user response time by caching content closer to the end user. The primary focus of this approach has been on web-based applications. A content distribution network consists of a network of caching proxy servers to which clients are directed transparently using various wide-area load balancing schemes. The caching approach works well for data that is static and unchanging, e.g. images, video clips, etc.

Figura 4. Replicazione delle risorse contese tramite caching e content distribution services

Policy based Management of Content Distribution Networks - Dinesh C. Verma, Seraphin Calo, and Khalil Amiri, Members, IEEE, IBM Thomas J Watson Research Center, PO Box 704, Yorktown Heights, NY 10598

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI 3.3.7.3. Problemi delle applicazioni Web legati alla rete

Pag. 65 di 86

Tra gli elementi di criticit per unapplicazione basata su rete, vanno annoverati: la connettivit del sito (provider, housing oppure hosting, service level agreement), anche in funzione dei provider POP utilizzati dagli utenti tipici; la congestione di rete; i fenomeni periodici (quali il carico della rete in funzione dellorario). Gli elementi di criticit possono essere investigati innanzi tutto comprendendo se si tratti di problemi congiunturali, periodici o costanti. Secondo la categoria di problema, si pu pensare a un diverso bilanciamento delle risorse, a un tuning apposito o a un upgrade di uno o pi elementi del sistema. La qualit della connessione va misurata nei casi tipici, ossia con gli utenti pi rappresentativi del sito. Ci comporta unanalisi (e talvolta una riconsiderazione) dellarchitettura di interconnessione. Rilevati dei problemi di connettivit, possibile rinegoziare i Service Level Agreement con i provider, scegliere un nuovo provider che garantisca una migliore qualit di servizio (ad esempio, una connessione migliore con lutenza tipica) o rivedere larchitettura del sistema. A questo proposito, i possibili interventi anche successivi al rilascio del sistema si dettagliano in: potenziamento delle risorse hardware (server, apparati di rete, replicazione di risorse, installazione di strumenti di bilanciamento del carico e di caching); revisione delle politiche di content management; tuning delle applicazioni custom; revisione delle politiche di sicurezza; replicazione geografica dei contenuti.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 66 di 86

4. A PPLICAZIONI SOFTWARE
Questo capitolo dedicato a specificare le caratteristiche della architettura software che si intende realizzare e le funzionalit di alto livello delle applicazioni software da progettare e implementare. Lo schema riportato in Figura 5 comporta la realizzazione di 5 tipologie di software: 1. database periferico; 2. applicazione di gestione dei dati locali; 3. database centrale; 4. applicazione di interrogazione del database centrale; 5. filtri. Si parla di tipologie di software in quanto i punti 1), 2) e 5) comporteranno probabilmente ladozione di soluzioni ad hoc, nel rispetto delle caratteristiche dei nodi periferici coinvolti.

Rete ADM
Postazioni Extranet
OPAC OPAC

Extranet
Interfaccia ADM-Extranet

Rete ReMI
(evoluzione di ADM)

[1]
Teca digitale

[1]
Data Server
Teca digitale

Data Server

Nodo ADM

[2] Applicazione gestionale

Nodo ADM

[2] Applicazione gestionale

Biblioteca Digitale Italiana Network Turistico Culturale (BDI&NTC)


OPAC OPAC generale

OPAC

[1]
Teca digitale

[3]
Data Server

[5] Filtro ADM-BDI&NTC


[2] Applicazione gestionale

Teca digitale

Data Server

Filtro ReMI-Portale

Teca digitale generale

Data Server

Interfaccia ReMI-Portale

Portale BDI&NTC

Nodo ADM

[4] Applicazione centrale

OPAC

[5] Filtri custom (non ADM)


Interfaccia Internet Data Server
OPAC

[1]
Teca digitale

Internet
[2] Applicazione gestionale

Nodo non ADM

[1]
Server

Nodo non ADM

[2] Applicazione gestionale

Postazioni utente Postazioni utente

Server

Figura 5. Architettura software di massima

In merito alle cinque tipologie di software citate, un generico nodo periferico che voglia entrare in ReMI deve disporre (o dotarsi) di un database periferico e di un'applicazione per la gestione dei dati e dei metadati relativi. La condivisione di una teca digitale non strettamente necessaria. Si pu trattare di soluzioni fornite ex-novo da ReMI al nodo locale (in tal caso, si tratter di soluzioni standard sviluppate per un caso generico) o di soluzioni integrate con le infrastrutture hardware e software gi esistenti. Il sistema ReMI, invece, dovr realizzare un filtro specifico per il nodo, al fine di catturarne le informazioni e metterle in condivisione sulla rete ReMI.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 67 di 86

In definitiva, il Fornitore dovr ipotizzare una serie di casistiche da gestire, a partire da quella di un nodo che dispone solo di contenuti culturali in formato non digitale per arrivare a quella di un nodo mediamente informatizzato secondo standard proprietari.

4.1. Database periferico standard


Il database periferico standard viene installato sui nodi fornitori di informazione al fine di creare una teca digitale ed eventualmente un OPAC. Rimangono esclusi da questo discorso i nodi che gi dispongono di una propria base di dati che rispetta i requisiti minimi per collegarsi al sistema di interfaccia ReMI-Portale. Il Fornitore deve proporre una soluzione standard, adeguata ad ogni tipologia di nodo entrante e alleterogeneit dellinformazione da esso aggiunta alla rete ReMI. Sar comunque necessario prevedere interventi di personalizzazione in risposta a particolari esigenze da parte dello specifico nodo periferico. E necessario ipotizzare inoltre soluzioni spurie, per nodi che presentano gi un proprio OPAC ma che si vogliono dotare di una teca digitale. In tal caso, il database proposto deve essere in grado di interfacciarsi con le soluzioni esistenti. E facolt del Fornitore proporre un DBMS adeguato alla gestione del database proposto, ferma restando la necessit di supportare eventuali integrazioni con sistemi pre-esistenti. Si segnalano in particolare due casi da ritenere tipici: nodo ADM: dispone gi di una propria base di dati per lOPAC e per la teca digitale. In tal caso, non si rende necessaria linstallazione di un database periferico; nuovo nodo non ADM: non dispone n di OPAC n di teca digitale, e quindi adotta la soluzione standard proposta.

4.2. Applicazione standard di gestione dei dati


I singoli nodi aderenti al progetto ReMI dovranno disporre di unapplicazione che consenta di gestire i dati di catalogo e gli oggetti digitali in loro possesso o oggetto di future campagne di digitalizzazione. Si sottolinea che lapplicazione sar destinata solo al trattamento dei dati locali, non accedendo a dati presenti su nodi esterni. Lo scopo primario dellapplicazione quello di fornire ai nodi che non hanno nulla del genere un pacchetto completo che consenta di iniziare progetti di digitalizzazione, e gestire in un solo ambiente integrato i dati catalografici e i metadati degli oggetti digitali. In tal modo si creer una soluzione standard che si interfacci correttamente con il Portale, fornendo tutti i metadati previsti dagli standard UNIMARC e MAG. Lapplicazione dovr essere modulare e personalizzabile per le esigenze del singolo nodo, che potrebbe avere gi alcune applicazioni che coprono alcune delle esigenze offerte, o che potrebbe avere bisogno di un adattamento delle funzionalit in relazione alleterogeneit dei materiali presenti.

4.3. Database centrale


Il database centrale dovr ospitare copia di tutti i dati catalografici disponibili sui singoli nodi ed importati tramite i filtri (v. Paragrafo 4.5). Oltre ai dati catalografici, dovranno essere disponibili

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 68 di 86

anche eventuali copie a diversa qualit dei materiali multimediali digitali delle teche, tipicamente compressi ed eventualmente ridotti in termini di estensione temporale o spaziale, sulla base degli specifici accordi con il Ministero per i Beni e le Attivit Culturali e dei servizi che si prevede di erogare. Per questo la macchina che ospiter il database dovr consentire unalta scalabilit in termini di spazio di memorizzazione; una possibile indicazione delloccupazione dei dati di una singola teca presentata nel paragrafo 5.5.3. E opportuno ricordare che il successo del progetto nella sua totalit dipende in larga misura dalle prestazioni di ricerca e consultazione; a tal proposito, opportuno prevedere anche lintervento di un esperto di ottimizzazioni sul DBMS, in modo da velocizzare le operazioni pi consuete.

4.4. Applicazione centrale

di

interrogazione

del

database

Allinterno del Portale trova posto unapplicazione che permette uninterrogazione integrata dei metadati e degli oggetti digitali connessi. Tale applicazione destinata allinterrogazione sia da parte dei nodi ReMI, che possono in questo modo accedere alla consultazione del proprio materiale e di quello dellintera rete, sia da parte di utenti Internet comuni, che attraverso una opportuna profilazione vedano limitate eventualmente le proprie capacit di accesso ai materiali. Lapplicazione in oggetto si occupa di interrogare in maniera integrata ed evoluta il database centrale che duplica le informazioni catalografiche dei singoli nodi e che integra eventuali sample multimediali del materiale disponibile, estraendo dati e informazioni sulla base delle richieste (query) dellutente. In particolare, linterfaccia grafica nasconde tutti i dettagli implementativi e svincola lutente dalla necessit di conoscere un linguaggio dinterrogazione quale lSQL per reperire informazioni da un database. Unaltra funzione fondamentale del software consiste nellaggregazione di dati eterogenei. Se ad esempio lutente interessato alla partitura di unopera lirica, lapplicazione non solo estrae lelenco di schede catalografiche in tal modo caratterizzate, ma deve mostrare anche tutti gli oggetti multimediali relativi (tra cui scansioni della partitura stessa, eventuali fotografie di scena, bozzetti, figurini, registrazioni e via dicendo). Lapplicazione deve essere progettata e realizzata in modo da soddisfare i requisiti minimi elencati nei successivi sottoparagrafi. Requisiti minimi da soddisfare Usabilit e accessibilit Nellimplementazione software, sono deprecate tutte le tecnologie che richiedono plug-in, che si applicano solo ad alcuni dei browser reperibili o che contravvengono le regole sullaccessibilit e lusabilit del software dettate dal W3C. Interazione tra OPAC e teca digitale Lapplicazione deve consentire di interrogare i dati presenti in OPAC e teca digitale in modo integrato. Si pone grande enfasi sulla presentazione efficace dei risultati, il che comporta percorsi di navigazione intuitivi e diretti tra i dati di catalogo degli oggetti in OPAC e gli oggetti corrispettivi

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 69 di 86

nella teca digitale. Per oggetto corrispettivo sintende non solo il risultato della digitalizzazione delloggetto originario, ma anche tutti gli oggetti digitali in qualche modo imparentati. Ad esempio, si consideri la partitura del Barbiere di Siviglia di Giochino Rossini. Essa presente in un nodo periferico come documento cartaceo catalogato nellOPAC. Inoltre, disponibile la digitalizzazione delle singole pagine, presenti nella teca digitale del nodo nei vari formati grafici previsti. Si ipotizzi che il nodo disponga inoltre di n esecuzioni dellopera in questione, nella versione analogica (vinile), nella versione digitalizzata da analogico (CD audio) e in formato digitale nativo (DAT). Si supponga infine la disponibilit anche di una registrazione in VHS. Tutto il materiale citato, si tratti di schede di catalogo o di oggetti digitali, in qualche modo relativo al Barbiere di Siviglia, pertanto lapplicazione dovr presentare intuitivamente allutente lenumerazione di tutti gli oggetti connessi e dovr fornirgli link diretti per accedervi. Internazionalizzazione Lapplicazione deve gestire gli accessi da parte di utenti potenzialmente non di lingua italiana. Le raccomandazioni su usabilit e internazionalizzazione fornite dal presente capitolato nei Paragrafi 3.1.5 e 3.3.5 trovano applicazione anche per quanto riguarda il software in esame. In particolare, necessario rispettare al riguardo le regole dettate dal W3C. Standard di qualit e prestazioni I requisiti sulle prestazioni devono far riferimento a quanto detto nel Paragrafo 3.3.6. Si riconosce, comunque, il fatto che molti aspetti interni o esterni allapplicazione possono avere un impatto determinante sulla sua qualit percepita dagli utenti. Innanzi tutto, sulle prestazioni globali dellapplicazione incidono: le caratteristiche HW/SW della macchina che funge da server; il numero di utenti contemporaneamente collegati al servizio; la struttura e le caratteristiche della rete a cui collegato il server; il DBMS scelto per ospitare le basi di dati. Perci, per quanto concerne i tempi di risposta allutente, solo alcuni aspetti dipendono dalla realizzazione pi o meno efficiente dellapplicazione. La velocit di trasmissione delle pagine e dei dati, i tempi di risoluzione delle query (tempi di calcolo della risposta alle interrogazioni), il carico di lavoro cui sono sottoposti il server e la rete sono tutti aspetti che dipendono da implementazioni, dimensionamenti e ottimizzazioni estranee allapplicazione. Ci detto, nel progettare, sviluppare, realizzare e validare il software, necessario porre grande attenzione alle prestazioni. Si suggerisce luso di tecnologie di comprovata efficienza nel generare pagine dinamiche di risultati (ad esempio, ASP o PHP).

4.5. Filtri
I filtri si occupano di alimentare il database centrale sul sistema di interfaccia ReMI-Portale. Il compito fondamentale dei filtri omogeneizzare i dati presenti nei nodi locali, sia a livello catalografico che per quanto concerne gli oggetti multimediali digitali, e alimentare di conseguenza il database centrale. Si evidenzia che i database periferici non ricadono necessariamente in un caso standard, e dunque possono basarsi su DBMS differenti, avere schemi differenti, contenere dati di tipologia eterogenea e non rispettare specifiche sui metadati. Per questi motivi, si suggerisce di basare le funzionalit dei filtri su protocolli di interoperabilit quali OAI-PMH e Web Services.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 70 di 86

I filtri non importano nel database centrale esclusivamente schede di catalogo e metadati, ma si occupano anche di alimentare il database con oggetti multimediali digitali. Per via della limitata disponibilit di risorse sul sistema di interfaccia, prevedibile che gli eventuali oggetti multimediali digitali rappresenteranno comunque una versione limitata e compressa rispetto agli originali, ma questa condizione va verificata sulla base delle scelte dei singoli nodi. Nel caso di trasmissione di oggetti digitali, assumono dunque particolare rilevanza le tecniche di compressione e di criptaggio dei dati. In questa visione i filtri devono: comprimere e criptare linformazione prelevata dai nodi periferici prima della trasmissione al database centrale; decriptare linformazione prelevata dai nodi periferici allarrivo sul database centrale.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 71 di 86

5. ATTUAZIONE DEL PROGETT O


Questo capitolo dedicato alla specifica degli elementi essenziali che dovranno caratterizzare i progetti dei candidati fornitori. Per lattuazione del progetto il Fornitore dovr presentare una proposta tecnica comprendente: la descrizione dettagliata dellarchitettura di sistema proposta; le caratteristiche dettagliate degli applicativi software usati e/o da realizzare; le caratteristiche dettagliate dei servizi da erogare; le modalit con cui il Fornitore intende realizzare il progetto, con particolare attenzione alle tecnologie di riferimento indicate al Paragrafo 3.3 di questo documento. Oltre alla proposta tecnica, il Fornitore dovr inoltre presentare il piano di progetto, con caratteristiche coerenti con quanto descritto al Paragrafo 5.4. In caso di aggiudicazione, il Fornitore si impegner a: definire un piano dettagliato del progetto; accettare attivit di controllo in corso dopera; accettare milestone di verifica del lavoro svolto; assicurare una collaborazione continuativa con la controparte.

5.1. Attivit e infrastrutture nel transiente di sviluppo dei sistemi informatici


Lattivit di progettazione e sviluppo dellintero sistema ReMI va a coprire un arco di tempo significativo, quantificato nel paragrafo 5.4. - Workplan del progetto. Nel lasso di tempo che porta dalla fase di progettazione ai rilasci intermedi e alla messa in produzione, dunque necessario prevedere soluzioni transienti che consentano lavanzamento parallelo di task di analisi, implementazione, testing e verifica su aree differenti del progetto. In particolare, pu essere parallelizzato lo sviluppo delle soluzioni sui nodi locali e sul nodo centrale (progettazione dei database, realizzazione degli schemi prescelti, popolamento dei database, applicazioni di gestione e interrogazione). Nel transiente, lelemento pi problematico costituito dai filtri previsti dal sistema ReMI per far comunicare i sistemi eterogenei che costituiscono i fornitori di informazioni. In questo caso, auspicabile avviare immediatamente lo sviluppo del filtro per un caso ritenuto standard (ad esempio, per limportazione dei dati dai nodi ADM), procedendo dunque in parallelo con le altre attivit. A seguire, saranno realizzati i filtri tra un particolare sistema e linterfaccia ReMI-Portale a seconda della rilevanza dei fornitori di informazione e della consistenza numerica dei nodi abilitati a partecipare a ReMI grazie a tale filtro. Le soluzioni parziali dovranno essere testate su ambienti di simulazione, prima della pubblicazione in rete. Lintero progetto, nel dimensionamento delle risorse umane, hardware e software, deve prevedere un duplice ambiente: un ambiente di sviluppo per limplementazione, il testing e la verifica delle soluzioni software; un ambiente di produzione, su cui vengono trasferiti i risultati provenienti dallambiente di sviluppo solo una volta verificati e ritenuti affidabili.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 72 di 86

La soluzione proposta consente di proseguire lo sviluppo anche in fase successiva al rilascio intermedio o finale, senza compromettere la funzionalit e la qualit del lavoro precedentemente pubblicato. Inoltre, vista limminente partenza di progetti di digitalizzazione locali ai nodi fornitori di informazione, necessario prevedere soluzioni temporanee per salvare i dati, i metadati e gli oggetti digitali che ne derivano, in attesa della realizzazione delle basi di dati definitive e della pubblicazione dei software gestionali. I diversi soggetti coinvolti nel progetto complessivo (database, software gestionale, filtri, software di interrogazione, digitalizzazione e campagne di popolamento di dati e metadati) dovranno essere periodicamente interpellati sullo stato di avanzamento dei sottoprogetti ad essi affidati, e dovranno confrontarsi sulle interfacce tra le diverse branche di sviluppo.

5.2. Attivit di funzionamento a regime dei sistemi informatici


Anche dopo il rilascio della soluzione definitiva, il sistema ReMI dovr essere sottoposto ai cicli di sviluppo, test e verifica suggeriti dallIngegneria del Software. In particolare, necessario prevedere una verifica periodica delle funzionalit del sistema, sia nel complesso sia per quanto riguarda le sottoparti in cui possibile suddividere il progetto. Nella soluzione a regime, necessario valutare il degrado delle prestazioni del sistema al crescere del numero di nodi fornitori di informazioni, allaumentare della mole di dati gestiti, al variare della composizione dellinformazione e al crescere del numero di utenti fruitori. Il risultato di tale analisi deve portare allottimizzazione del sistema, intesa come ridistribuzione dei carichi di lavoro e delle risorse disponibili o come reperimento di nuove risorse umane, hardware e software. E necessario che tutti i soggetti coinvolti nel progetto siano disponibili in merito ad eventuali modifiche da operare anche in fase post-produzione e alla manutenzione delle parti di propria competenza. Nel caso in cui la disponibilit fosse limitata alla fase di progetto e sviluppo, la documentazione messa a disposizione deve essere sufficiente al pieno trasferimento del know-how.

5.3. Documentazione del progetto


Il Fornitore dovr fornire, prima, durante, o alla conclusione del progetto (in relazione al tipo di documento) la seguente documentazione: Piano di progetto, in cui saranno indicate le metodologie di sviluppo, le fasi, le responsabilit e i coinvolgimenti, unitamente ad una pianificazione dei tempi con punti di verifica e validazione; Piano dei test, in cui verranno definite le loro tipologie, i casi di prova, i risultati attesi, i criteri di conformit dei risultati e le condizioni del testing; Specifiche dei requisiti utente; Rapporto di esecuzione dei test; Codice sorgente; Manuale di collaudo; Manuale utente; Manuale di installazione e gestione.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 73 di 86

5.3.1. Documentazione utente


I manuali utenti, previsti per ogni componente del sistema che interessi un utente finale, nel dettaglio dovranno essere redatti in italiano e prevedere: il dettaglio delle funzionalit previste dal componente del sistema ; la descrizione delle tipologie dutenza che utilizzeranno il componente; le funzionalit di accesso allhelp on line e ai wizard; per ogni funzionalit: le modalit di accesso, le finalit, prerequisiti, screenshot di esempio, dati previsti in input e in output; in appendice: i possibili messaggi di errore, con descrizione dei modi di risoluzione dei problemi, e un glossario con i termini tecnici utilizzati. I manuali utenti dovranno essere presentati dal Fornitore sia in forma cartacea che in forma elettronica (su CD, preferibilmente in formato PDF). Dovr altres essere previsto un help on-line per ogni componente applicativo. 5.3.1.1. Wizard del Portale Lapplicazione di interrogazione integrata nel Portale dovr prevedere degli strumenti che guidino lutente alle prime armi nella familiarizzazione con le funzioni previste e le modalit di fruizione. In questottica, sono disponibili due tipologie di cosiddetti wizard: un wizard-illustra-funzioni: costituito da un tour guidato alle funzionalit offerte dal Portale, ed assimilabile ad una specie di help on-line interattivo; un wizard-guida: per lutente che non ha lesatta evidenza di cosa cercare, ma che attraverso una serie di domande venga condotto mediante un percorso semplificato a risposte nucleari verso dei risultati altrimenti ottenibili con richieste immediate ma complesse.

5.3.2. Documentazione tecnica del team di sviluppo


Particolare attenzione dovr essere rivolta dal Fornitore nel produrre una vasta e dettagliata documentazione tecnica relativa alle soluzione progettate, implementate e testate dal team di sviluppo. I codici sorgente, ad esempio, dovranno essere largamente commentati, con eventualmente degli allegati che illustrino particolari soluzioni adottate con strumenti idonei a rendere pi semplice la comprensione e lapplicabilit di interventi a posteriori.

5.4. Workplan del progetto


Le tappe principali che dovranno essere considerate dal Fornitore allinterno del piano di progetto sono elencate di seguito: La durata complessiva del progetto prevista di 9 mesi. Linizio del progetto da intendersi come la data di inizio effettivo dei lavori; E prevista una fase della durata di circa 1 mese dedicata allanalisi e alla redazione della documentazione preliminare (piano di progetto, piano dei test, ).

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 74 di 86

5.4.1. Rilasci e validazione intermedi


Fatta salva la possibilit di accordi specifici fra Fornitore e committente, vengono previste delle validazioni intermedie in cui verr sottoposto lo stato di avanzame nto, adottando soluzioni che consentano di valutarne oggettivamente la corrispondenza ai piani di lavoro. Le validazioni intermedie vengono identificate in (figura 6): 1 mese dalla partenza del progetto: verifica dellanalisi preliminare e approvazione del piano di progetto, di test, ; 3 mesi dalla partenza del progetto: verifica dello stato di sviluppo dei prototipi delle applicazioni pertinenti al progetto; 6 mesi dalla partenza del progetto: rilascio della versione beta delle applicazioni pertinenti al progetto; 8 mesi dalla partenza del progetto: risultati dei primi test di integrazione; 9 mesi dalla partenza del progetto: consegna e collaudo del prodotto.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 75 di 86

Figura 6: gantt dei rilasci e delle validazioni intermedi

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 76 di 86

5.5. Piano economico del progetto


Il presente paragrafo dedicato alla valutazione dei costi del sistema informatico proposto. Tale valutazione riguarder i componenti hardware e software, e si articoler in costi per i nodi periferici e costi per il sistema centrale. Nellimpossibilit di prevedere con certezza la quantit di dati e metadati da gestire e il tasso di crescita della quantit di informazioni in ReMI, verranno fornite nel seguito stime parametrizzate. In altre parole, i costi saranno calcolati non in valore assoluto ma in funzione di grandezze via via esplicitate. Le cifre dichiarate devono essere considerate puramente indicative, in quanto fortemente sensibili a variazioni legate al mercato, alla stipula di contratti e convenzioni particolarmente vantaggiosi, a iniziative di sponsorizzazione. In tabella viene fornito lelenco di tutte le attivit che possono richiedere interventi di carattere economico: Acquisto, manutenzione e gestione dellhardware Campagne di digitalizzazione (ivi compresi eventuali interventi di pre e post restauro) Gestione, mantenimento ed evoluzione del portale Internazionalizzazione del portale Progettazione e sviluppo di sistemi DRM e gestione sicurezza Progettazione ed implementazione applicazione standard gestione dei dati Progettazione ed implementazione applicazione di interrogazione del database centrale Progettazione ed implementazione del database centrale Progettazione ed implementazione del database periferico standard Ottimizzazione database centrale Ottimizzazione database periferici Valutazione e testing delle applicazioni Implementazione dei filtri portale e nodi non ADM Implementazione filtri portale e nodi ADM

5.5.1. Impatto economico per i nodi periferici


Limpatto economico delladesione al progetto ReMI da parte dei nodi periferici cosa complessa da valutare. Innanzi tutto, i costi dipendono fortemente dalla situazione pre-esistente a livello di servizi informatici allinterno del singolo nodo. Inoltre, volendo coinvolgere il maggior numero possibile di realt, doveroso immaginare situazioni fortemente eterogenee. Per un nodo che gi aderisce agli standard ADM ed dotato di un sistema informatico, i costi di adesione sono praticamente nulli. Per un nodo che dispone di un sistema informatico minimale (almeno un PC collegato a Internet) e di una teca digitale non rispondente a tutti o ad alcuni standard ADM, i costi di adesione al sistema ReMI rimangono assai contenuti. Infatti, sar sufficiente completare eventualmente il set di dati catalografici minimi, anche in formato proprietario. Questa operazione ha un costo valutabile in giorni-uomo e dipendente dalla quantit di dati da completare. Le operazioni di conversione e filtraggio dei dati e dei metadati in formato compatibile ReMI saranno a carico del sistema centrale. Per un nodo che dispone di un sistema informatico minimale (almeno un PC collegato a Internet) e vuole dotarsi di una teca digitale, vanno considerati: i costi di digitalizzazione del materiale (apparecchiature, operatori, supporti);

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 77 di 86

i costi di immissione dei metadati, di acquisto delle licenze di un DBMS (se non presente), di progettazione del database. In questo caso, si suggerisce di aderire agli standard individuati da ADM, in modo da poter partecipare non solo alla extranet ReMI, ma anche alla intranet specialistica ADM. Infine, per un nodo completamente sprovvisto di sistemi informativi vanno aggiunte alle voci di spesa precedentemente elencate quelle relative allacquisto di almeno una postazione. Si tratta di costi hardware dellordine di qualche migliaio di Euro, cui vanno aggiunte le eventuali licenze del sistema operativo e del DBMS. A questo proposito, esistono soluzioni Open Source di grande valore: ad esempio, Linux come sistema operativo e MySQL come DBMS. Inoltre, necessario indagare sullaccessibilit a Internet, che pu avvenire anche tramite modem analogico su linea telefonica tradizionale. Questa soluzione risulta, per, poco pratica per la trasmissione al sistema centrale di materiale multimediale, e parimenti per linvio di oggetti digitali agli eventuali acquirenti. Si suggerisce pertanto di considerare un accesso a Internet a banda larga (ADSL o fibra).

5.5.2. Previsioni di spesa per il nodo centrale


Nellarchitettura ipotizzata per la rete ReMI, il nodo centrale riveste una particolare importanza. I punti salienti cui prestare attenzione nel dimensionamento delle risorse del sistema sono i seguenti. Il sistema posto nel nodo centrale deve essere completamente affidabile nel suo funzionamento, 24 ore al giorno e 7 giorni su 7. Il nodo centrale deve rispondere alle risposte di un numero medio di n utenti concorrenti. Inoltre, tale sistema deve essere in grado di gestire un database di notevoli dimensioni, soggetto a una crescita costante. Per quanto riguarda la tolleranza ai guasti, si ipotizza un sistema ridondato con ripresa a caldo e dischi in configurazione RAID 0 + 1. La connettivit di rete deve essere sufficiente a supportare n utenti concorrenti e il download fluido di oggetti multimediali. Una configurazione adeguata per il server centrale si compone di: macchina multiprocessore dotata di 4 processori Intel Pentium 4; sistema operativo proprietario e customizzato, basato su UNIX; 8 GB di RAM; 2 dischi interni SCSI da 72 GB; n dischi esterni da 72 GB in configurazione RAID 0 + 1, corrispondenti a 36n GB di spazio reale su disco (per una stima del parametro n, si rimanda al prossimo paragrafo).

5.5.3. Dimensionamento dello spazio su disco nel nodo centrale


Lo spazio su disco un aspetto assai critico di un sistema centralizzato di gestione dellinformazione. Come pi volte ricordato, gli elementi da valutare sono: 1. la quantit di spazio richiesta in funzione del numero e del tipo di oggetti da memorizzare; 2. la previsione del tasso di crescita dello spazio occupato, che a sua volta si articola in: a. crescita conseguente alladesione di nuovi nodi; b. crescita periodica dovuta allimmissione di nuovi materiali da parte dei nodi preesistenti; Il punto 1 pu essere stimato sulla base delle informazioni attualmente disponibili riguardo i nodi ADM. Il punto 2a pi complesso da valutare, in quanto i nodi destinatari del progetto ReMI sono eterogenei per composizione numerica e qualitativa del materiale. In altre parole, molto dipende dalla tipologia e dalla quantit di oggetti digitali messi in condivisione dalle teche. La presente

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 78 di 86

proposta parte dallipotesi che il materiale digitale di alta qualit rimanga fisicamente nella teca che ne detiene la propriet, quindi il dimensionamento dello spazio su disco nel nodo centrale si basa su materiale opportunamente degradato. Questa considerazione ha un forte impatto soprattutto per quanto riguarda i contenuti audio e video: ben diversa loccupazione di spazio di un file MP3 a 320 Kbps della durata di 10 minuti rispetto a quella di un MP3 a 64 Kbps tagliato a 30 secondi. Infine, il punto 2b dipende dagli investimenti (in termini di risorse economiche, umane e computazionali) stanziati dai singoli nodi per le campagne di digitalizzazione. Quanto detto finora evidenzia le difficolt di operare una stima precisa dello spazio su disco, anche limitandosi alla prima fase del progetto. Ma la soluzione ai dubbi avanzati insita nella modularit e nella forte scalarit del nodo centrale. Nel momento in cui lo spazio su disco previsto si riveli insufficiente, possibile aggiungere nuovi dischi in configurazione RAID a quelli preesistenti. Inoltre, la tecnologia del disk storage in continua evoluzione, per cui ipotizzabile per il futuro anche la sostituzione dei dischi con altri supporti pi capienti, veloci e affidabili. Nella tabella che segue, si riportano alcuni valori medi di occupazione di spazio in relazione ai formati di file e alle loro caratteristiche intrinseche. Per i formati compressi, la dimensione effettiva dipende non solo dal livello qualitativo desiderato ma anche dalle caratteristiche delloggetto da comprimere: unimmagine pressoch monocromatica sar compressa molto pi efficacemente dallalgoritmo JPEG rispetto a una figura ricca di colori e con contorni netti.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI


Categoria
Testo breve

Pag. 79 di 86
Estensione
txt rtf doc pdf txt rtf doc pdf tif, tiff jpg, jpeg

Descrizione dellesempio
Blocco di testo corrispondente a un paragrafo di media lunghezza. Tale quantit risulta adeguata alla caratterizzazione testuale di un oggetto multimediale.

Formato
Plain text non formattato Rich Text Format Microsoft Word Acrobat Plain text non formattato Rich Text Format Microsoft Word Acrobat TIFF (compressione LZW) JPEG

Caratteristiche
500 caratteri, senza formattazione 500 caratteri, con formattazione minima 500 caratteri, con formattazione minima 500 caratteri, con formattazione minima 72000 caratteri, senza formattazione 72000 caratteri, con formattazione minima 72000 caratteri, con formattazione minima 72000 caratteri, con impaginazione complessa e pagine a colori 2126 x 1391 pixel, 300 DPI (18 x 11,78 cm) 2126 x 1391 pixel, 300 DPI (18 x 11,78 cm) Qualit 12 in Photoshop (massima qualit, compressione minima) 2126 x 1391 pixel, 300 DPI (18 x 11,78 cm) Qualit 8 in Photoshop (alta qualit) 2126 x 1391 pixel, 300 DPI (18 x 11,78 cm) Qualit 5 in Photoshop (media qualit) 2126 x 1391 pixel, 300 DPI (18 x 11,78 cm) Qualit 0 in Photoshop (minima qualit, compressione massima) 532 x 348 pixel, 300 DPI (4,5 x 2,95 cm) 532 x 348 pixel, 300 DPI (4,5 x 2,95 cm) Qualit 12 in Photoshop (qualit massima, compressione minima) 532 x 348 pixel, 300 DPI (4,5 x 2,95 cm) Qualit 8 in Photoshop (alta qualit) 532 x 348 pixel, 300 DPI (4,5 x 2,95 cm) Qualit 5 in Photoshop (media qualit) 532 x 348 pixel, 300 DPI (4,5 x 2,95 cm) Qualit 0 in Photoshop (minima qualit, compressione massima) 6800 x 9900 pixel, 600 DPI (29 x 42 cm) 24 bit RGB Non compresso 6800 x 9900 pixel, 300 DPI (29 x 42 cm) 24 bit RGB Qualit 12 in Photoshop (qualit massima, compressione minima) 567 x 827 pixel, 72 DPI (20 x 29 cm) 24 bit RGB Qualit 5 in Photoshop (media qualit)

Dimensione
500 Byte 4 KByte 20 KByte 3 KByte 80 KByte 250 KByte 300 KByte 100 KByte 4 MByte 1 MByte

Testo esteso

Libretto di unopera di Verdi (Falstaff) convertito in vari formati. La porzione considerata corrisponde ad alcune pagine di testo, in numero variabile a seconda del formato e dellimpaginazione.

Fotografia

Fotografia di scena acquisita con fotocamera digitale e convertita in vari formati, non ridimensionata.

JPEG JPEG JPEG

jpg, jpeg jpg, jpeg jpg, jpeg

400 KByte 250 KByte 77 KByte

Fotografia

Fotografia di scena acquisita con fotocamera digitale e convertita in vari formati, ridimensionata al 25% delle dimensioni originali.

TIFF (compressione LZW) JPEG

tif, tiff jpg, jpeg

350 KByte 170 KByte

JPEG JPEG JPEG

jpg, jpeg jpg, jpeg jpg, jpeg

45 KByte 30 KByte 15 KByte

Scansione

Scansione di una pagina di partitura, ai livelli di risoluzione, compressione e profondit di colore previsti dal Capitolato tecnico ICCU per la digitalizzazione di manoscritti dei fondi musicali di biblioteche italiane.

TIFF 6.0 (non compresso)

tif, tiff

200 MByte

JPEG

jpg, jpeg

9 MByte

JPEG

jpg, jpeg

140 KByte

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI


Categoria
Audio

Pag. 80 di 86
Estensione
wav aif, aiff flac rm rm rm rm mp3 mp3 mp3 mp3 wav aif, aiff flac rm rm rm rm mp3 mp3 mp3 mp3 avi mpg avi mov rm

Descrizione dellesempio
Traccia acquisita da CD ( qu'a vu le vent d'ouest, preludio per Ce pianoforte di C. Debussy).

Formato
PCM Wave (CD-audio) AIFF FLAC 1.1.1 RealAudio RealAudio RealAudio RealAudio MPEG layer 3 MPEG layer 3 MPEG layer 3 MPEG layer 3 PCM Wave (CD-audio) AIFF FLAC 1.1.1 RealAudio RealAudio RealAudio RealAudio MPEG layer MPEG layer MPEG layer MPEG layer AVI MPEG-2 DIVX 5.0 QuickTime RealMedia

Caratteristiche
Durata: 3 41; stereo; non compresso Durata: 3 41; stereo; non compresso Durata: 3 41; stereo; compr. senza perdita Durata: 3 41; stereo; 100 Kbps Durata: 3 41; stereo; 64 Kbps Durata: 3 41; stereo; 56 Kbps Durata: 3 41; stereo; 28,8 Kbps Durata: 3 41; stereo; 320 Kbps Durata: 3 41; stereo; 192 Kbps Durata: 3 41; stereo; 128 Kbps Durata: 3 41; stereo; 64 Kbps Durata: 30; mono; non compresso Durata: 30; mono; non compresso Durata: 30; mono; compresso senza perdita Durata: 30; mono; 100 Kbps Durata: 30; mono; 64 Kbps Durata: 30; mono; 56 Kbps Durata: 30; mono; 28,8 Kbps Durata: 30; mono; 320 Kbps Durata: 30; mono; 192 Kbps Durata: 30; mono; 128 Kbps Durata: 30; mono; 64 Kbps Durata: 1; 720x576 pixel; qualit eccellente Durata: 1; 720x576 pixel; qualit eccellente Durata: 1; 640x480 pixel; qualit buona Durata: 1; 640x480 pixel; qualit buona Durata: 1; 320x240 pixel; qualit discreta

Dimensione
38 MByte 38 MByte 15 MByte 2,5 MByte 1,7 MByte 900 KByte 450 KByte 8,5 MByte 5,3 MByte 3,5 MByte 1,7 MByte 2,5 MByte 2,5 MByte 1,8 MByte 380 KByte 250 KByte 127 KByte 64 KByte 1 MByte 704 KByte 470 KByte 235 KByte 216 MByte 60 MByte 10 MByte 20 MByte 5 MByte

Audio

Traccia acquisita da CD ( qu'a vu le vent d'ouest, preludio per Ce pianoforte di C. Debussy), tagliata a 30 secondi e portata in bassa qualit.

3 3 3 3

Video

Sequenza audio-video di 1 minuto tratta da DVD ad alta definizione

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 81 di 86

Una volta salvati gli oggetti musicali su file system o in un database, alle dimensioni effettive va aggiunta una quantit variabile di spazio (trascurabile nel caso di oggetti di grandi dimensioni). Ad esempio, si consideri un nodo contenente:
Composizione del materiale
Spartiti Videocassette Vinili CD audio Monografie DVD Materiale fisico vario

Numero di oggetti
7000 6000 6000 1000 16000 100 5000

Caratteristiche del singolo oggetto


50 pagine A4 60 minuti 45 minuti 60 minuti 100 pagine A4 (due facciate per foglio) 60 minuti descrivibile con 3 fotografie digitali

Per ospitare le digitalizzazioni di tutti i contenuti culturali elencati, la teca locale al nodo richiederebbe approssimativamente:
Composizione del materiale
Spartiti

Occupaz. spazio
7000 x 50 pag x 100 KB/pag 6000 x 60 min x 60 MB/min 6000 x 45 min x 7 MB/min 1000 x 60 min x 7 MB/min 16000 x 50 pag x 50 KB/pag 100 x 60 min x 60 MB/min 5000 x 3 fotografie x 4 MB/fotografia

Caratteristiche della digitalizzazione


PDF alta qualit 600 dpi MPEG-2 720x576 pixel qualit eccellente FLAC 1.1.1 compresso senza perdita FLAC 1.1.1 compresso senza perdita PDF alta qualit 600 dpi MPEG-2 720x576 pixel qualit eccellente TIFF 2126 x 1391 pixel, 300 dpi 18 x 11,78 cm

Videocassette

Vinili

CD audio

Monografie

DVD

Materiale fisico vario

Totale = 35 GB + 21 TB + 1,9 TB + 420 GB + 40 GB + 360 GB + 60 GB = 24 TB (circa) Per ospitare la versione a bassa qualit di tutti i contenuti culturali elencati, la teca dellinterfaccia ReMI-Portale richiederebbe approssimativamente:
Composizione del materiale
Spartiti

Occupaz. spazio
7000 x 5 pag x 50 KB/pag 6000 x 1 min x 3 MB/min 6000 x 30 sec x 8 KB/sec 1000

Caratteristiche della digitalizzazione


PDF bassa qualit 144 dpi 10% della partitura RealMedia 320x240 pixel bassa qualit tagliato a 1 minuto MP3 64 Kbps mono MP3

Videocassette

Vinili

CD audio

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI


x 30 sec x 8 KB/sec Monografie 16000 x 5 pag x 25 KB/pag 100 x 1 min x 3 MB/min 5000 x 3 fotografie x 50 KB/foto 64 Kbps mono PDF bassa qualit 144 dpi 10% della monografia RealMedia 320x240 pixel bassa qualit tagliato a 1 minuto JPEG 532 x 348 pixel, 72 dpi (4,5 x 2,95 cm) Qualit 5 in Photoshop (media qualit)

Pag. 82 di 86

DVD

Materiale fisico vario

Totale = 1,75 GB + 18 GB + 1,44 GB + 240 MB + 2 GB + 300 MB + 750 MB = 46 GB (circa) Alcune osservazioni sugli esempi sopra riportati: i formati compressi (con e senza perdita) permettono di calcolare una stima media sulloccupazione di spazio, ma non valori precisi, fortemente dipendenti dalle caratteristiche intrinseche del materiale codificato; i formati scelti e riportati sono a puro titolo di esempio; non sono stati calcolati gli overhead legati allorganizzazione dei file su file system o in un DBMS; non si tenuto conto delloccupazione di spazio dovuta alla ridondanza dei dati, dipendente ad esempio dalle configurazioni RAID prescelte. Nel caso di RAID 0 + 1, ogni disco completamente ridondato e dunque loccupazione di spazio teorica viene in pratica raddoppiata.

5.5.4. Progettazione, realizzazione e ottimizzazione del database centrale


La struttura proposta per il database OPAC del sistema interfaccia BDI &NTC ricalca in gran parte la struttura degli OPAC della rete ADM. Dunque, le risorse dedicate allo sviluppo di tale database dovrebbero risultare limitate, e quantificabili quanto meno in 2 mesi/uomo di lavoro svolto da professionisti. Altrettante risorse devono essere previste per le fasi di realizzazione, validazione, e ottimizzazione del database risultante. In totale, il numero di mesi/uomo per portare a termine lopera sul database centrale non sar inferiore a 4 mesi/uomo. Le attuali quotazioni di un professionista in materia si aggirano intorno a 1100 /giorno. Ai suddetti costi vivi legati al lavoro di professionisti, necessario aggiungere i costi delle licenze per il DBMS prescelto. I trascorsi del progetto ADM e il recente passato di BDI &NTC spingono verso ladozione di Oracle 10. Il prezzo pieno di una licenza Oracle 10 di 5000$ circa, ma necessario tener conto di eventuali agevolazioni legate a sponsorizzazioni e rapporti di partnership.

5.6. Fornitura di sistemi informatici hardware


Nel corso del presente capitolo, verranno presentate alcune indicazioni sulla fornitura dei sistemi informatici, spaziando dallanalisi dei requisiti hardware e software alle attivit di acquisto, installazione, collaudo e manutenzione. Le apparecchiature hardware, in particolare, dipenderanno fortemente dalle richieste dei singoli committenti. In riferimento alla Figura 1, si nota come lacquisto di hardware coinvolga tanto il sistema

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 83 di 86

di interfaccia ReMI-Portale quanto i nodi periferici, che considerati singolarmente presentano una situazione assolutamente disomogenea sulla dotazione informatica gi a disposizione e su quella richiesta. E dunque ipotizzabile la coesistenza di pi fornitori e di pi committenti, sebbene nel corso del capitolo per semplicit si designi unicamente la figura del Fornitore e dellIstituto (il generico committente). Analogamente, le richieste dei singoli committenti saranno meglio dettagliate in capitolati specifici per la fornitura di hardware e software.

5.6.1. Oggetto della fornitura


Loggetto della fornitura verr di volta in volta specificato nel Capitolato tecnico di fornitura di sistemi informatici per un particolare Istituto committente. Tale capitolato evidenzier in modo dettagliato le funzionalit e i servizi richiesti dallIstituto in questione, e mostrer con chiarezza le linee guida da seguire nel realizzare la fornitura. I contenuti di tale capitolato specifico sono da intendersi pi puntuali e precisi rispetto a quanto genericamente affermato nel corso del presente capitolo. Il capitolato specifico potr essere redatto secondo due modalit distinte: indicando esattamente la tipologia e la consistenza numerica delle apparecchiature e dei moduli software da fornire; indicando con precisione le caratteristiche funzionali della fornitura, e lasciando al Fornitore la possibilit di suggerire specifiche implementazioni.

5.6.2. Certificazioni e requisiti tecnici richiesti


Il Fornitore dovr allegare allofferta tecnica la seguente documentazione: certificazione ISO 9001:2000 del costruttore delle apparecchiature e del Fornitore dei servizi, nonch la dichiarazione di persistenza delle predette certificazioni; tali certificazioni potranno essere prodotte anche in copia, purch sottoscritte dal legale rappresentante del Fornitore, o suo delegato; dichiarazione, redatta secondo i criteri definiti dalla norma UNI CEI EN 45014:1990 Criteri Generali per la dichiarazione di conformit rilasciata dal Fornitore, versione italiana della norma europea EN 45014:1989 General criteria for suppliers declaration of conformity, attestante la sussistenza dei requisiti di conformit alle certificazioni richieste per le apparecchiature oggetto di fornitura, con puntuale riferimento alla marca e modello offerto che andr riportato nella stessa dichiarazione. Tale dichiarazione dovr essere sottoscritta dal legale rappresentante del Fornitore, o suo delegato; descrizione tecnica dei prodotti offerti, corredata da depliant, dalla quale dovranno risultare le caratteristiche tecniche dei prodotti. Tale descrizione richiesta esclusivamente a titolo informativo, fermo restando limpegno del Fornitore allosservanza delle caratteristiche minime richieste per le apparecchiature oggetto della presente fornitura. In tale descrizione dovranno essere indicati fra laltro anche le dimensioni fisiche, le caratteristiche elettriche e ambientali di esercizio delle apparecchiature offerte; dichiarazione descrittiva dei servizi offerti attestante la corrispondenza dei medesimi alle caratteristiche richieste ed, eventualmente, le caratteristiche migliorative.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 84 di 86

Le caratteristiche minime prestazionali dei sistemi server saranno valutate sulla base del benchmark da parte degli organismi indipendenti quali TPC-C e dovranno essere dichiarate dal Fornitore. Per ogni installazione dovr essere fornita tutta la documentazione relativa alle apparecchiature hardware (hardware technical reference, operator&service guide, installation guide, ecc.). La documentazione dovr essere redatta in lingua italiana, o in subordine in lingua inglese, e dovr essere resa disponibile su supporto cartaceo (manuali), CD-ROM o DVD-ROM.

5.6.3. Consegna, installazione e configurazione delle apparecchiature


Il Fornitore dovr provvedere, a proprio esclusivo onere: a definire e rendere noto allIstituto, in sede di stipula, il nominativo del capo progetto che sar responsabile unico della consegna ed installazione della fornitura; consegnare, entro il termine concordato con lIstituto, un Calendario operativo nel quale dovranno essere indicati, in modo puntuale ed esaustivo, le modalit ed i tempi di consegna delle componenti hardware e software, di esecuzione dei servizi e di pianificazione delle attivit (il termine di presentazione del calendario operativo viene solitamente individuato in circa 10 (dieci) giorni solari dalla data di comunicazione di aggiudicazione della gara); alla consegna e posa in opera delle apparecchiature e delle eventuali componenti accessorie; allinstallazione e configurazione delle apparecchiature secondo le specifiche indicate dallIstituto; allinstallazione e configurazione del Sistema Operativo prescelto secondo le specifiche indicate dallIstituto; alla verifica e la messa in funzione delle apparecchiature. Le componenti oggetto di fornitura dovranno essere consegnate ed installate (solitamente entro 30 giorni solari dalla data di comunicazione di aggiudicazione della gara) presso i locali del committente. Dovr essere prevista una penale per ogni giorno lavorativo di ritardo, rispetto al termine previsto per la consegna della fornitura. Saranno a carico del Fornitore tutte le spese relative al trasporto, alla consegna, allinstallazione ed alla configurazione della fornitura.

5.6.4. Collaudo delle apparecchiature hardware


Il collaudo delle apparecchiature e del software fornito a corredo verr effettuato in contraddittorio tra le parti (Fornitore ed Istituto), su richiesta dellIstituto, entro 15 (quindici) giorni dallavvenuta consegna ed installazione della fornitura da parte del Fornitore.

5.6.5. Offerta
L'offerta sar considerata impegnativa per un periodo di 90 (novanta) giorni a decorrere dalla data di scadenza del termine di presentazione delle offerte.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 85 di 86

5.7. Manutenzione dei sistemi informatici


Il sistema descritto nella proposta tecnica del Fornitore dovr offrire un livello di disponibilit di 24 al giorno per tutto lanno. Per raggiungere questo livello di affidabilit, nella proposta tecnica si dovranno presentare le caratteristiche di manutenzione hardware e software del sistema, con una durata minima di 36 mesi a partire dalla data di collaudo e con una modalit di intervento on site. Dovranno essere descritte le modalit di notifica e di presa in carico dei malfunzionamenti (telefono, fax, email, ) ed esplicitamente i servizi gratuiti e a pagamento compresi nellofferta di assistenza e quelli a pagamento non compresi nellofferta.

5.7.1. Interventi in garanzia


Il Fornitore dovr garantire il corretto funzionamento dellintero sistema, fornendo, per una durata di 12 mesi dalla data di collaudo, un servizio di correzione degli errori che eventualmente si presenteranno durante lutilizzo. La casistica di malfunzionamenti e guasti si articola su due livelli di gravit, che implicano diverse caratteristiche di intervento: problemi gravi: bloccano lattivit del sistema o la limitano fortemente; lintervento deve avvenire entro le 9,00 del giorno successivo alla chiamata, e il ripristino delle funzionalit entro il primo giorno lavorativo successivo alla chiamata; altri problemi: non bloccano lattivit del sistema e non la limitano fortemente; lintervento deve avvenire entro il giorno lavorativo successivo alla chiamata, e il ripristino delle funzionalit entro 3 giorni lavorativi successivi alla chiamata. In generale il tempo di risoluzione dei problemi riscontrati sar di 5 giorni lavorativi dalla chiamata, salvo diverso accordo tra le parti. Sono a carico del Fornitore, oltre gli oneri del predetto servizio di assistenza in garanzia, tutte le parti di ricambio che fosse necessario sostituire a seguito di guasti e/o malfunzionamenti delle apparecchiature fornite. Il Fornitore dovr utilizzare parti di ricambio di qualit e nuove di fabbrica.

5.7.2. Servizi di manutenzione


Il Fornitore dovr fornire, per quanto riguarda la manutenzione hardware e software del sistema, le caratteristiche di durata, le tipologie di intervento e il personale coinvolto allinterno della proposta tecnica. Ci sar oggetto di valutazione per laggiudicazione del contratto di realizzazione. Le attivit di manutenzione riguarderanno sia la manutenzione preventiva che quella correttiva: manutenzione preventiva: attraverso lottimizzazione e laggiornamento periodici del sistema, volta a mantenere la perfetta funzionalit dei componenti e a prevenirne i malfunzionamenti; manutenzione correttiva: consiste nella riparazione dei guasti hardware, con leventuale sostituzione delle parti difettose e con il successivo collaudo. Per ogni richiesta di assistenza correttiva, il Fornitore inserir la segnalazione nel proprio sistema di gestione, assegnandogli un identificativo di chiamata, che dovr comunicare allIstituto.

Capitolato tecnico sullevoluzione dei progetti BDI&NTC, ADM e ReMI

Pag. 86 di 86

Il sistema di gestione del Fornitore dovr garantire il tracciamento della segnalazione (stato dellintervento) in tutte le sue fasi, fino alla chiusura della stessa. Per ogni intervento di manutenzione dovr essere redatta da un incaricato dellIstituto e dal tecnico del Fornitore, che ha eseguito lintervento, una nota dintervento, associata ad un numero identificativo. Su tale nota dovranno essere riportate almeno le seguenti informazioni: numero identificativo della nota dintervento; numero identificativo della chiamata (creato dal sistema di gestione del Fornitore); data e ora di segnalazione del guasto da parte dellIstituto; data e ora di presa in carico del guasto da parte del Fornitore; data e ora di inizio intervento on-site; data e ora ripristino delle apparecchiature; nominativo del tecnico che ha effettuato lintervento; nominativo del referente dellIstituto; descrizione dettagliata del problema/guasto; soluzione adottata; esito della chiamata. Alla fine di ogni trimestre, il Fornitore dovr produrre un documento Elenco degli interventi contenente tutti gli interventi effettuati nel corso di tale periodo e le note di intervento ad essi associate, sia per quanto riguarda la presa in carico delle segnalazioni di malfunzionamento, sia per quanto riguarda il ripristino in loco delle apparecchiature.

5.7.3. Oneri e responsabilit


Il Fornitore dovr garantire che le prestazioni dei servizi sopra citati vengano svolte con la cura e la diligenza richieste dalle circostanze da personale specializzato. LIstituto si riserva la facolt di richiedere la sostituzione, motivandola, del personale impiegato nelle attivit di assistenza ove questi non risultasse di gradimento allIstituto stesso. Il Fornitore si impegna a conformarsi e a far conformare il proprio personale, impiegato nei servizi oggetto della presente fornitura, alle procedure formali di sicurezza vigenti nellIstituto per laccesso ai locali dello stesso. Il Fornitore riconosce a proprio carico tutti gli oneri inerenti all'assicurazione del proprio personale occupato nella esecuzione del presente servizio e dichiara di assumere in proprio ogni responsabilit in caso di infortuni e/o di danni arrecati eventualmente da detto personale alle persone ed alle cose, sia dell'Istituto che di terzi, in dipendenza di colpa o negligenza nella esecuzione delle prestazioni stabilite.