GIOTTO: IL DIGITAL LIBRARY

Транскрипт

1 Giotto IL DIGITAL LIBRARY MANAGEMENT SYSTEM DEL CINECA Redatto da: Matteo Bertazzo, Angelo de Florio, Ugo Contino Verificato da: Approvato da: Distribuito a: Proposta di servizio protocollo n. Rev. Emessa in data 1

2

3 1 Premessa Giotto come digital library management system Architettura del servizio Sintesi dei servizi offerti Descrizione analitica dei servizi Back-office: interfaccia di catalogazione SERVIZIO di Ingestion Ingestion Google Books Servizio Repository Backup Archiviazione contenuti e metadati Indicizzazione, ricerca, ricerca poliedrica API Giotto OAI-PMH Provider Visualizzatori Integrazione U-GOV ricerca (OAI-Harvester) Modulo di integrazione MOODLE Integrazione L2L Integrazione EBSCO Servizio oembed Mediamosa Transcoding Servizo di Streaming Servizio di trasformazione OCR Concettualizzazione di documenti testuali Visualizzazione di immagini ad alta risoluzione (Mappe) Hosting del portale Digital Library Moduli di integrazione DRUPAL

4

5 1 PREMESSA Giotto, il Digital Library Management System del Cineca, nasce da una collaborazione con l Università La Sapienza di Roma, condotta negli ultimi tre anni e nell ambito del progetto della Sapienza Digital Library. Alla base di Giotto c è l idea di raccogliere in un unico sistema di deposito digitale la produzione intellettuale di un ateneo, passata e futura, già nata digitale (born-digital) o tradotta in formato digitale attraverso un processo di digitalizzazione. L obiettivo che si è voluto realizzare è quello di integrare in un unico repository diversi tipi di materiali quali: digitalizzazione di libri (antichi e moderni) stampe ed altro materiale originale produzione scientifica digitale (tesi di laurea e dottorato, materiale scientifico, etc.) immagini in formato digitale materiale audiovisivo materiale audio materiali didattici (anche per uso nei corsi in elearning) User Generated Content materiale specifico (schede di scavo archeologico, materiale di archivio, dataset). Importante sottolineare come il progetto che ha portato alla realizzazione della piattaforma Giotto, nasca con una visione consortile, ovvero con l idea di creare una infrastruttura ed un insieme di Servizi Digital Library basati su tecnologie innovative, sull uso di specifiche aperte, di software Open Source, di standard e sull interoperabilità, che potessero consentire una facile e rapida adozione da parte delle altre università del consorzio. Tutto ciò ha portato alla realizzazione nell arco di un triennio di un infrastruttura complessa e flessibile, modulare e ricca di funzionalità, fruibile sia come un unicum o come un sottoinsieme di servizi, con un livello di granularità tra macro e micro funzioni completamente gestibile dall utente in fase di configurazione. Questa infrastruttura permette di gestire l intero ciclo di vita di una risorsa digitale o digitalizzata: dall immissione o ingestion nell infrastruttura, alla metadatazione, alla catalogazione fino alla dissemination (browsing, ricerca, visualizzazione) e alla 5

6 preservation (su questo punto è previsto un completamento delle attività nell arco del 2014). Cuore della soluzione ed elemento caratterizzante della piattaforma è la possibilità che ha l utente di agire su ognuna delle fasi precedentemente descritte attraverso un insieme di interfacce standard (API RESTful), dalla transcodifica di un immagine alla richiesta delle risorse di una collezione, alla visualizzazione di un filmato al download di un documento. Altro elemento importante ed innovativo da sottolineare in Giotto è l impiego di un framework di modellazione dei contenuti che definisce non solo le risorse digitali trattati ma anche i servizi a loro associati, legando la tipologia di un oggetto digitale (libro digitalizzato; mappa scansionata; filmato multimediale) al visualizzatore più adatto (book reader, media player, etc.). Grazie all astrazione della loro rappresentazione nel deposito il numero di tipologie di oggetti e i servizi a essi associati sono facilmente estensibili, aumentando gli ambiti di applicazione del Servizio Digital Library agli oggetti più diversi come dataset scientifici, modelli tridimensionali, etc. Giotto si caratterizza quindi come un deposito di risorse digitali facilmente fruibile, un archivio ragionato e moderno basato su standard internazionali di metadati, un motore di ricerca potente e veloce ma anche come un insieme di servizi e interfacce software da usare come elementi di base per costruire il proprio servizio, per erogare le risorse dal proprio Portale, per effettuare ricerche da altre applicazioni o solo per mostrare una risorsa digitale dentro un corso in e-learning, sfogliando un antico codice digitalizzato all interno di un nuovo codice digitale (si veda la figura successiva che definisce questo scenario di integrazione reso possibile dalla piattaforma Giotto). 6 Figura 1 - Scenario di integrazione Digital Library Management System e servizi dell Ateneo

7 2 GIOTTO COME DIGITAL LIBRARY MANAGEMENT SYSTEM Il sistema Giotto si ispira a best practice internazionali, a modelli conformi al modello OAIS, a specifiche e standard internazionali (ISO-16363, METS, MODS, PREMIS, OAI-PMH) in modo da garantire la massima interoperabilità con altri sistemi alla base di progetti nazionali e internazionali (per es. Europeana o OpenAire) e di supportare tipologie di risorse digitali e metadati eterogenei. Elementi alla base della soluzione tecnologica realizzata sono l impiego di software open source e l interoperabilità, l integrazione e la modularità della piattaforma. Grazie a ciò il servizio può essere declinato sia nella realizzazione di portali Digital Library chiavi in mano, sia nell integrazione con altri servizi già presenti in Ateneo (come Portali di Ateneo, U-GOV Ricerca, piattaforme e-learning, etc.) che, infine, in modo selettivo accedendo e sfruttando puntualmente micro-servizi di digital library specifici (come servizi di transcodifica o di visualizzazione). Il modello di riferimento che ha ispirato il disegno del Servizio è quello definito nell ambito del progetto DELOS Network of Excellence on Digital Libraries in cui sono identificate e caratterizzate le componenti dell architettura di un Digital Library Management System, le classi di attori coinvolti e i loro specifici requisiti. E proprio in riferimento al manifesto e al modello DELOS schematizzato nella figura sottostante che il Giotto realizza un Digital Library Management System (DLMS), poiché fornisce l infrastruttura tecnologica e informativa necessaria a realizzare e gestire un sistema Digital Library, incorporando una suite di funzionalità di base ed integrando applicazioni e strumenti aggiuntivi per il supporto a servizi specializzati per la realizzazione di funzionalità avanzate. Figura 2 - DELOS Reference Model for Digital Libraries Quello che Giotto permette quindi di realizzare è una filiera produttiva che può essere usata per implementare in tutto o in parte l insieme dei processi richiesti da uno 7

8 specifico Ateneo. Nella costruzione della filiera sono infatti coinvolti aspetti sia tecnologici che organizzativi, come schematicamente illustrato nella successiva figura. Figura 3 - Processi di filiera nella gestione di risorse digitali Facendo riferimento alla Figura 3 è possibile identificare i seguenti processi: Processi di Catalogazione E la fase in cui le risorse e le collezioni vengono catalogate sia in termini descrittivi che strutturali, vengono caricati gli eventuali contenuti digitali e viene automaticamente prodotto un pacchetto di versamento (SIP, Submission Information Package) che a sua volta viene salvato in un area di deposito. Processi di Management In questo macroprocesso successivo procedure automatiche monitorizzano l area di deposito ed effettuano l acquisizione automatica (ingestion) dei pacchetti SIP. Dopo la fase di archiviazione dei contenuti e dei metadati delle risorse e delle collezioni avviene la loro indicizzazione per alimentare il processo di ricerca (search). In base alla tipologia di risorsa digitale vengono creati eventuali oggetti digitali derivati adatti alle forme di dissemination previste dal servizio (immagini a risoluzioni minori, codifica di filmati per lo streaming, etc.). Infine nella fase di enrichment, avviene l arricchimento delle risorse digitali con l aggiunta di informazioni ottenuta tramite estrazione di testo (OCR), generazione automatica di metadati semantici, identificazione della lingua di un testo, etc. 8

9 Applicazioni Quest ultimo macroprocesso rappresenta le modalità di sfruttamento dei diversi servizi di ricerca e dissemination offerti dal Servizio Digital Library che sono a disposizione dell Ateneo. Browsing di collezioni e risorse per gerarchie e metadati, motore di ricerca (sui metadati e full-text sui contenuti) e filtri a faccette, visualizzatori specializzati per tipo di risorsa sono disponibili in due forme: come API a granularità fine con cui i programmatori possono realizzare le proprie applicazioni e come building blocks integrati in piattaforme come Drupal o Moodle con cui l Information Architect può costruire il proprio Portale o applicazione web. 9

10 3 ARCHITETTURA DEL SERVIZIO Il servizio si basa su una architettura service-oriented organizzata su tre livelli. Di questi, il livello di integrazione, rappresentato in figura e denominato Digital Library Service Delivery Platform, costituisce il cuore della soluzione: realizza un modello astratto e semantico delle entità e delle loro relazioni nella Digital Library e al tempo stesso permette sia la comunicazione interna tra tutte le componenti e i servizi integrati al livello inferiore che l accesso da parte del layer applicativo a tutte le funzionalità Digital Library in primis il livello di repository - esposte verso utenti o applicazioni esterne (come aggregatori OAI-PMH). Il livello applicativo, in particolare il Portale Digital Library, ma potenzialmente una qualsiasi applicazione anche mobile - in grado di sfruttare servizi web, ha quindi a disposizione una interfaccia Digital Library (API RESTful) omogenea e stabile, unico punto di accesso verso tutti i servizi che integra, semplifica e rende trasparente l utilizzo del repository e dei sistemi e servizi ad esso connessi. Facendo riferimento al percorso che una risorsa segue all interno del DLMS è possibile distinguere le seguenti funzionalità offerte da questa specifica architettura: Acquisizione delle risorse digitali - il servizio fornisce la funzionalità di deposito e ingestion in conformità con il modello OAIS: il processo di acquisizione delle risorse digitali (i Submission Information Package, SIP METS), forniti in modalità bulk, dropbox o provenienti da harvesting OAI-PMH, vengono elaborati da procedure 10 Figura 4 - Architettura del servizio Giotto

11 automatiche in modo coordinato con tutte le altre componenti del servizio. Questi processi, monitorabili da parte dell ateneo, prevedono controlli di integrità dei file, controlli antivirus, file characterization e integrazione con il processo di transcodifica. Transcodifica - il servizio sfrutta i servizi anche esterni, come i due servizi open source ConceptMapper e Mediamosa - integrati per ottenere, in base al tipo di risorsa digitale in ingresso, nuove forme di rappresentazione digitale utili alla dissemination (transcodifiche audio-video, conversioni di immagini, estrazione di thumbnail) o alla fase di ricerca e discovery (transcodifiche OCR, analizzatori della lingua, estrattori di testo o analizzatori semantici). Il deposito digitale - le funzioni di memorizzazione e gestione dei contenuti (nelle varie forme adatte alla conservazione e alla dissemination), dei metadati (descrittivi, tecnici amministrativi e strutturali), dei derivati e delle informazioni di autorizzazione sono svolte dal repository open source Fedora Commons integrato nel servizio. Il repository fornisce anche i servizi web di accesso di accesso e management sfruttati dallo strato di integrazione del servizio digital library. Le entità digital library sono rappresentate nel repository attraverso modelli atomistici in base alla tipologia (immagini, mappe, book-scan, testi, audio-video, collezioni organizzative e di risorse). Indicizzazione e ricerca - la funzione è affidata al motore di ricerca open source SOLR: con l integrazione realizzata l indice dei contenuti, metadati, relazioni e dei derivati (trascrizioni OCR, annotazioni semantiche, testi) è allineato con il repository e attraverso la API di accesso le informazioni possono essere sfruttate dal portale per la ricerca e il browsing a faccette delle risorse digitali. Dissemination - l'accesso alle risorse digitali e ai servizi da parte dell utente avviene attraverso il Portale Digital Library, realizzato con il CMS open source Drupal opportunamente esteso con nuovi moduli Digital Library integrato con specifici visualizzatori open source. Il Portale è stato integrato anche per condividere con il servizio Digital Library le informazioni di autenticazione e autorizzazione sulle risorse digitali. Altre forme di dissemination sono realizzate attraverso il protocollo OAI-PMH (esposizione DC e MODS) e le API di fruizione, che permettono di cercare, selezionare e fruire risorse Digital Library in altri ambienti (un esempio è l integrazione realizzata con la piattaforma LCMS Moodle). 11

12 4 SINTESI DEI SERVIZI OFFERTI Denominazione Descrizione sintetica Note Back-office: interfaccia di catalogazione Interfaccia di catalogazione di collezioni e risorse digitali, gestione del workflow di conferimento, upload degli oggetti digitali ed esportazione SIP secondo application profile Giotto basato su METS/MODS. Personalizzazione delle form di immissione su specifiche dell Ateneo. Descrizione di risorse non descritte in altri sistemi esterni. Servizio di Ingestion Ingestion Google Books Servizio Repository, Backup e archiviazione contenuti e metadati Indicizzazione, ricerca, ricerca poliedrica API Giotto OAI-PMH Provider Visualizzatori Integrazione U-GOV ricerca (OAI- Harvester) Servizio di ingestion di pacchetti SIP conformi all application profile Giotto basato su METS/MODS Servizio di ingestion di pacchetti conformi all application profile Giotto basato su METS/MODS e metadati/contenuti prodotti da google Books (gestione JPEG2000, hocr) Servizio comprendente lo storage fino a 30TB di dati, compresivi del frutto delle elaborazioni dei derivati Indicizzazione di metadati, relazioni e contenuti testuali e servizio di ricerca basato su motore di ricerca Apache SOLR API di ricerca e di accesso ai contenuti e metadati presenti nel repository. Accesso ai servizi offerti dal sistema Giotto. Servizio di dissemination basato su protocollo OAI-PMH Visualizzatori specifici per risorse digitali complesse: BookReader, IIPImageViewer (immagini ad alta risoluzione), Player audio video HTML5/Adobe Media Servizio di harvesting basato su protocollo OAI-PMH personalizzato per la raccolta dei metadati esposti dal servizio U-GOV Ricerca Basato su indice SOLR definito per SDL 12

13 Modulo di integrazione MOODLE Integrazione L2L Integrazione EBSCO Servizio oembed Servizio di transcodifica audio video (Mediamosa) Servizo di Streaming Servizio di trasformazione OCR Concettualizzazione di documenti testuali Transcodifica e delivery di immagini ad alta risoluzione (Mappe) Hosting del portale Digital Library Modulo di integrazione per la piattaforma Moodle che permette la ricerca e visualizzazione di risorse SDL all interno di corsi e-learning Servizio di ingestion di risorse L2L in Giotto Servizio di espansione della ricerca Giotto con risultati provenienti da un sistema EBSCO Discovery Service Servizio di esposizione di risorse e metadati in formato oembed Servizio di transcodifica audio-video basato su piattaforma DAM Mediamosa Servizio di streaming basato su piattaforma Mediamosa Servizio di transcodifica di immagini in testo basato su software ABBY Finereader ed integrato con workflow di ingestion Servizio di identificazione e classificazione di concetti all interno di documenti testuali Servizio di transcodifica di immagini ad alta risoluzione in immagini in formato JPEG2000 e la delivery tramite server dedicato Hosting del portale Giotto (opzionale) Attivo per le sole risorse classificate in Giotto come aperte Il servizio prevede l elaborazione di un documento alla volta Il servizio prevede l elaborazione di un massimo di due documenti contemporanei 13

14 5 DESCRIZIONE ANALITICA DEI SERVIZI 5.1 BACK-OFFICE: INTERFACCIA DI CATALOGAZIONE Il servizio, realizzato attraverso il CMS open source Drupal, si pone l obiettivo di rendere disponibili in Giotto nel minor tempo possibile nuove risorse digitali, già digitalizzate o pronte per la digitalizzazione, mantenendo al tempo stesso una adeguata qualità di metadatazione. L impiego del CMS Drupal e il completo sfruttamento delle sue funzionalità (native, moduli ad-hoc, tassonomie) permette di realizzare delle interfacce di catalogazione complesse e pienamente rispondenti ai requisiti espressi dall Ateneo. Lo strumento permette: la catalogazione di metadati descrittivi di collezioni e risorse digitali la definizione e l utilizzo di vocabolari controllati (utilizzabili sia come filtri in fase di inserimento sia come validatori a posteriori per controllare quanto inserito dall'utente) la clonazione di schede descrittive, per massimizzare la produzione da parte degli editor il caricamento (upload) e l associazione di contenuti digitali alle risorse digitali la gestione delle partizioni delle collezioni la validazione delle risorse digitali tramite un workflow edit/approve/reject l associazione ad un local identifier l esportazione verso un pacchetto di SIP di ingestion così come definito e supportato dal sistema Giotto Lo strumento di Catalogazione è infatti integrato con il processo di Ingestion del servizio di Digital Library: le risorse digitali (metadati e contenuti) e le collezioni generate attraverso questo strumento sono esportate sotto forma di pacchetti SIP (Submission Information Package) e ricondotte al normale flusso di ingestion per poi essere archiviate nel repository. L'intera operazione di generazione e successiva ingestion, a scelta dell'utente, può essere completamente automatizzata oppure segmentata al fine da sottoporre ad un controllo più stringente l'evoluzione della generazione dei contenuti/metadati. 14

15 Lo strumento, che permette la catalogazione secondo i requisiti selezionati dall Ateneo - che si rifanno agli standard di settore (ISAD e ISAAR) - prevede la gestione di queste tipologie di entità: Risorse: ogni risorsa digitale, sia esso una immagine, un libro, un video, un frammento audio, una cartografia, un oggetto 3D, un software, ecc ; Collezioni / Partizioni: una collezione rappresenta una raccolta di Risorse. Essa può essere suddivisa in Partizioni (ad esempio Serie, Sottoserie, Raccolta, Fascicolo, Sottofascicolo, ecc ); Soggetti Versanti / Produttori: authority file per la gestione dei soggetti fornitori delle collezioni e/o partizioni di collezioni Partizioni delle collezioni Nello sviluppare lo strumento è stata posta particolare attenzione alla distinzione tra i vari livelli di rappresentazione di un oggetto digitale. Per evitare ogni ambiguità vengono inseriti i metadati relativi ad ognuna delle seguenti entità: Real Physical Object (RPO): l oggetto fisico (ad esempio un dipinto, un edificio, un libro, ecc ); Digital Representation Object (DRO): un oggetto digitale ottenuto attraverso la digitalizzazione di un RPO; Digital Primary Object (DPO): un oggetto "born digital" cioè un oggetto digitale che non è un DRO. Durante la fase di metadatazione è possibile utilizzare vocabolari controllati, in particolare si è deciso di adottare il Thesaurus PICO 4.3 (Portale della Cultura Italiana) per una prima soggettazione, il Nuovo Soggettario di Firenze per un livello più approfondito, VIAF (Virtual International Authority File) e VID-SBN per i nomi di persona e di Ente, e il TGN (Thesaurus of geographic names Getty) e/o Geonames per i toponimi e il Thesaurus multidisciplinare NSF. Alcuni di questi sono stati importati come tassonomie all interno dello strumento, altri sono referenziati. Il ciclo di produzione delle Collezioni e Risorse prevede l utilizzo di profili di utenti differenti (eventualmente collassabili) al fine di distinguere le tipologie di attività nel workflow implementato. Si è quindi previsto di distinguere un soggetto atto all'inserimento dei metadati/contenuti, un soggetto preposto alla validazione di quanto inserito e un soggetto amministratore con compiti di supervisione (ad es. gestione utenti e relativa associazione alle collezioni) e monitoraggio dei contenuti (ad 15

16 es. adeguamento tassonomie). Lo strumento prevede la possibilità di effettuare l upload diretto o indiretto delle risorse. L upload indiretto prevede il caricamento preventivo delle risorse attraverso un canale FTP/WebDAV. Il workflow inizia con la creazione di una Collezione e delle sue eventuali Partizioni da parte dell Administrator. Egli poi associa alle Collezioni ed alle Partizioni i relativi Soggetti Versanti e Produttori. Dopodiché gli Editor creano le Risorse digitali all interno di ogni Collezione e Partizione. Le risorse così create sono risultano visibili soltanto all interno dello strumento di Catalogazione ma con la successiva eventuale approvazione da parte di un Validator esse diventano disponibili per l esportazione verso il repository. L esportazione può avvenire a livello di singole risorse o di intera collezione in quanto all'utente è consentita la scelta delle risorse digitali da esportare. Per l utente è inoltre possibile scegliere se esportare un SIP contenente i soli metadati o comprensivo di oggetti digitali. 5.2 SERVIZIO DI INGESTION L Ingestion rappresenta la fase di conferimento delle risorse digitali all'interno del sistema Giotto; il processo è funzionale alle successive fasi di archiviazione, gestione dei dati, amministrazione, preservation planning e accesso previste dal modello OAIS. Le risorse delle quali si desidera effettuare l'ingestion sono, singolarmente, organizzate in SIP conformi nella struttura e nei contenuti al profilo METS definito dall'infrastruttura Giotto. Un pacchetto SIP può quindi indifferentemente contenere una collezione (un raggruppamento logico di risorse digitali) o una singola risorsa digitale (con anche i contenuti o solo i metadati) Nell ambito dell'infrastruttura Giotto con il termine risorsa digitale si intende un information package (OAIS - IP) composto da metadati (che descrivono la risorsa dal punto di vista del contenuto, amministrativo, strutturale, di provenienza,...) e dagli oggetti digitali ovvero i file. La risorsa digitale può essere anche sovrapposta concettualmente all'entità Intellettuale definita nello standard PREMIS che rappresenta un'unità informativa (un libro, una fotografia, un sito web) che può essere rappresentata da diversi supporti (analogici e digitali) e da diversi formati. Inoltre, poiché il servizio ha adottato Fedora Commons (FC) come repository, la risorsa digitale può anche essere ascritta alla definizione FC di Oggetto Digitale e di Content Model Architecture. Una risorsa digitale è quindi composta dall'insieme degli oggetti digitali (i file multimediali che ne rappresentano il contenuto) e dai metadati che 16

17 accompagnano la risorsa e descrivono il suo contenuto intellettuale e digitale. L oggetto informativo è costituito da un file METS e da uno o più oggetti digitali che possono costituire parti o componenti dell'oggetto digitale. Le informazioni che in terminologia OAIS possono essere considerate il PDI (Preservation Description Information) sono anch esse contenute nel file METS. Il pacchetto informativo, oltre che ad una risorsa digitale, può essere relativo ad una Collezione di Risorse: un raggruppamento di entità raccolte sulla base di un legame logico, tematico, gestionale o tramite una relazione di altra natura. Il Servizio Giotto mette quindi a disposizione un modulo di deposito che permette di caricare i SIP destinati all ingestion all interno del repository. Il modulo di deposito supporta due diversi workflow: uno manuale, in cui il producer effettua il caricamento in un area di staging dalla quale il personale CINECA avvia manualmente in una secondo momento l ingestion, e uno automatico, in cui il producer effettua il caricamento in un area dalla quale una procedura software avvia il workflow dell ingestion. In entrambi i casi il caricamento può avvenire sfruttando tre diverse modalità: caricamento via FTP caricamento via WebDAV caricamento tramite utilizzo del servizio DropBox (richiede che il producer sia fornito di uno o più account DropBox sui quali è stato fornito accesso all applicazione DropBox Servizio Digital Library CINECA ) Una volta rilevata la presenza di un nuovo file la procedura ha inizio con la decompressione del file, ne viene verificato il contenuto mediante antivirus e la conformità della struttura. Il contenuto del METS viene quindi validato e viene controllato il checksum dei vari file contenuti nello zip. Passati i controlli preliminari viene avviato il parsing del contenuto del file METS che porterà alla creazione della struttura di oggetti da inserire nel repository (a una risorsa digitale corrisponde infatti una struttura di oggetti più complessa sul repository ottimizzata per la successiva fase di fruizione e compatibile con le necessità di preservation). Durante la generazione della nuova gerarchia di oggetti viene eseguita anche la caratterizzazione dei file, un processo che, come da best-practice, valida ed estrae metadati tecnici dai file dei contenuti. Al termine della generazione della nuova gerarchia di oggetti questa viene caricata direttamente nel repository. 17

18 Figura 5 - Workflow del processo di Ingestion In caso di errore in una qualsiasi fase dell'intero workflow il SIP viene spostato in una directory adibita al salvataggio dei pacchetti rigettati e viene fatto rollback di eventuali variazioni apportate al repository mentre invece in caso di uscita senza errori il SIP viene archiviato in apposita area deputata alla conservazione degli oggetti già inseriti (si faccia riferimento alla fig.5 per una visione completa del workflow del processo di ingestion). Terminato il caricamento nel repository l'ingestion viene completata mediante l'avvio di una serie di processi definiti di transcoding atti all'integrazione/trasformazione dei contenuti inseriti (riconoscimento mediante ocr dei contenuti testuali delle immagini, conversione delle immagini a bassa risoluzione, indicizzazione dei contenuti, ecc) allo scopo di migliorarne/completarne la fruibilità mediante interfaccia web Ingestion Google Books Il workflow di ingestion prevede la compatibilità verso i SIP generati secondo la struttura di prevista dal servizio di digitalizzazione Google. Tale struttura presenta alcune differenze rispetto alla struttura del SIP previsto dal profilo di ingestion Giotto. La differenza principale nei pacchetti provenienti dal servizio digitalizzazione Google è la presenza già all'interno del SIP del risultato del riconoscimento del testo dalle immagini e di tutte le informazioni di supporto quali la collocazione in ogni parola nelle varie pagine (per consentire la gestione dell'highlight). Per questa tipologia di pacchetti è stato quindi implementato un workflow di ingestion che prevedesse alcune operazioni aggiuntive per l'adeguamento dei dati contenuti nel SIP laddove non fossero pienamente conformi al profilo Giotto. Per le fasi successive 18

19 all'ingestion è stato inoltre necessario prevedere alcune varianti nella catena delle attività di transcodifica in modo che comunque il risultato al termine di vari processi fosse totalmente equivalente ai book di altra provenienza 5.3 SERVIZIO REPOSITORY Il backend per la gestione dello storage dei contenuti offerto dall'infrastruttura consente la gestione, nella sua configurazione base di un'area dati con una disponibilità di storage comprensivo anche dei risultati dei servizi di transcodifica e delle varie attività di enrichment dei contenuti propedeutici alla piena fruibilità dei contenuti digitali e alla compatibilità con gli standard di preservation. Il sistema è conforme alle rigide e consolidate policy di storage Cineca quindi costantemente monitorato e regolarmente sottoposto a backup conservativo su supporti ad alta garanzia di conservazione. La sua piena integrazione nell'infrastruttura di rete Cineca garantisce estrema flessibilità alla soluzione in termini di prestazioni essendo possibile prevedere migliorie alla soluzione base includendo sezioni di storage a prestazioni più elevate per particolari necessità o di dimensioni maggiori per moli di dati eccedenti le capacità di base. L'infrastruttura Giotto prevede nativamente l'erogazione del servizio in alta affidabilità mediante nodi replicati a valle di una componente di load balancing. Anche per questa caratteristica però la flessibilità del sistema consente di prevedere installazioni che consentano la massimizzazione dell'uso dell'area di storage a scapito della ridondanza dei nodi oppure l'incremento dell'affidabilità della soluzione prevedendo al replica anche di aree nativamente non previste Backup Tutta l'infrastruttura Giotto è adeguatamente ridondata e gestita mediante le policy Cineca. Su tutti i dati caricati viene eseguito un backup giornaliero automatico di tipo incrementale con schedulazione automatica pilotata dal server, attraverso l infrastruttura di backup CINECA basata su Tivoli Storage Manager. I sistemi sono costantemente monitorati da procedure automatiche H Archiviazione contenuti e metadati In seguito all acquisizione di un pacchetto SIP, in base alla tipologia di entità specificata nel METS (specifica tipologia di risorsa digitale o collezione), vengono generati i pacchetti AIP che sono oggetto di archiviazione nel repository. 19

20 I pacchetti AIP che trovano una corrispondenza all interno del modello OAIS nella definizione di AIU (Archival Information Unit) per quanto riguarda gli oggetti e di AIC (Archival Information Collection) per quanto riguarda le collezioni, vengono archiviati indipendentemente dalla tipologia all interno del repository sfruttando i meccanismi offerti dal software Fedora Commons. Fedora Commons si basa su due concetti fondamentali, quello di Fedora Digital Object e quello di Fedora Content Model Architecture, entrambi sfruttati a pieno dall'infrastruttura Giotto. Il Fedora Digital Object, utilizzabile per rendere persistenti e fornire le caratteristiche essenziali di molteplici tipologie di oggetti digitali (come immagini, documenti, dataset, ma anche metadati), è un building block fondamentale del Content Model Architecture ed è alla base delle funzionalità del repository stesso. L astrazione possibile con i Content Model - un modello formale che descrive le caratteristiche e i servizi dei contenuti digitali - riduce lo sforzo di cattura, acquisizione, archiviazione, gestione, preservazione, validazione, trasformazione e accesso dei contenuti digitali, fornendo anche un metodo di classificazione degli stessi. Sono utilizzabili anche come template per la generazione di interfacce, per guidare i workflow che agiscono sui contenuti, per descrivere la struttura dei sotto componenti o per l applicazione di policy. In secondo luogo attraverso la Content Model Architecture i contenuti digitali non sono definiti in base al formato dei file o in base alla tecnologia e incorporano i servizi che agiscono sui contenuti stessi. Questo permette di disaccoppiare il fatto di fruire una risorsa digitale da una specifica tecnologia permettendo di raggiungere le caratteristiche essenziali del contenuto aumentando la possibilità di godere di un contenuto rispetto al cambio di formato e delle tecnologie. I Content Model comprendono tutte le possibili caratteristiche che permettono la persistenza e la delivery del contenuto, incluse informazioni strutturali, semantiche e di interazione rispetto alle entità che riferiscono ad altri Content Model e sono memorizzati nel repository come ogni altro oggetto digitale presente nel repository. Con la definizione dei Content Model si ottiene quindi una descrizione formale (XML), validata, preservata, storicizzata della struttura degli AIP. I documenti XML che definiscono la struttura dei Content Model, essendo memorizzati nel repository, sono inoltre accessibili via web. Partendo dai Content Model di base offerti da Fedora Commons (le funzioni di base del repository stesso si basano su questi modelli) sono stati definiti nuovi modelli per estensione attraverso un linguaggio formale per arrivare alla definizione delle varie tipologie di oggetti gestiti da Giotto. La Content Model Architecture permette quindi il riuso dei modelli e la loro condivisione anche a livello di differenti community che hanno in comune l impiego del repository Fedora Commons. Tutti gli oggetti Fedora Commons che rappresentano le risorse digitali e le collezioni acquisite tramite ingestion (denominati oggetti padre ) afferiscono ad un modello chiamato Common Metadata che definisce un insieme di metodi e di datastream sia obbligatori che 20

21 opzionali. Gli oggetti del repository che hanno al loro interno, sotto forma di datastream, dei contenuti afferiscono ad ulteriori content model in base alla tipologie di risorsa digitale che rappresentano. Questi oggetti sono per convenzione denominati figli. Ogni oggetto del repository ha un identificativo univoco denominato PID (Persistent Identifier). Gli oggetti padre hanno il PID ottenuto concatenando un prefisso al PID contenuto nel SIP che lo ha generato mentre gli oggetti figli, oltre ad avere una relazione che li lega all oggetto padre, hanno un identificativo ricavato gerarchicamente dall identificativo del padre (fig.6). Tutte le relazioni tra gli oggetti, tra padre e figlio ma anche tra oggetto e collezione di appartenenza (nell'architettura adottata ne esistono molte altre tipologie qui non menzionate per brevità), vengono espresse mediante relazioni RDF ed inserite in uno specifico datastream. Figura 6 - Rappresentazione e archiviazione dei SIP Le funzionalità offerte dal repository vengono sfruttate anche per l'implementazione del versioning degli AIP. L AIP originale è quello ottenuto con la prima ingestion del relativo SIP. Ingestion successive comportano il versioning di tutti i datastream che non sono di contenuto. Uno specifico progetto ha la libertà di estendere il versioning anche a quest ultimi. In questo caso la funzionalità sfruttata è quella di audit : ogni 21

22 modifica effettuata su un oggetto (anche il semplice cambiamento della label dell oggetto) viene registrata in uno specifico datastream di sistema non modificabile. 5.4 INDICIZZAZIONE, RICERCA, RICERCA POLIEDRICA Il servizio Giotto integra, tra le altre funzionalità, un motore di ricerca realizzato mediante il software open source Apache Solr. Le informazioni indicizzate comprendono: 22 i metadati descrittivi delle risorse e delle collezioni le relazioni tra le risorse - o parti di esse - e le collezioni il testo dei documenti testuali o quello ricavato dalle operazioni di transcodifica (OCR) L accesso al motore di ricerca è mediato dallo strato di integrazione in modo da ottenere risultati conformi alle regole di autorizzazione espresse a livello SDP e di repository. Le informazioni contenute nell indice del motore di ricerca sono costantemente aggiornate rispetto alle informazioni che sono presenti nel repository: nella fase di ingestion infatti, ad ogni variazione del contenuto del repository (aggiunta, modifica o eliminazione di un oggetto) viene notificata a tutti i sistemi integrati l'indicazione dell identificativo e dell'operazione effettuata. Anche l aggiornamento di un solo metadato, ottenuto mediante l ingestion di un pacchetto SIP privo del contenuto digitale, si riflette quindi in tempo reale sull aggiornamento dell indice del motore di ricerca. Il motore di ricerca prevede la definizione di uno schema utilizzato per definire sia gli elementi che costituiscono l indice sia le loro proprietà. Vi è una parte dello schema che è considerata core e che definisce elementi comuni a tutte le entità della Digital Library e informazioni strutturali (usate nel browsing). Una parte è invece configurabile in fase di definizione di progetto e riguarda ad esempio informazioni quali lo score dei risultati di ricerca (che ne influenzano l ordine) o il trattamento del full-text (definizione di stopwords, sinonimi, etc.). Le opzioni di ricerca sono molteplici in modo da offrire all'utente un ventaglio molto ampio di criteri e consentire il raggiungimento del risultato desiderato mediante percorsi estremamente differenziati. Dai metadati descrittivi di una risorsa digitale è

23 possibile individuare le risorse vicine rispetto a un subset definito di metadati (funzionalità che è ad esempio sfruttata nella pagina di una risorsa digitale esposta dal modulo di integrazione Drupal, che propone le risorse simili a quella principale proprio sulla base di questa funzionalità). Sono inoltre possibili ricerche full text all interno dei contenuti testuali (o alla trascrizione in testo di immagini derivanti da processi di digitalizzazione quando disponibile). Tra le opzioni di ricerca offerte degna di nota è la classificazione a faccette che permette di catalogare un singolo asset digitale sotto più categorie (le faccette), ciascuna descrittiva di una aspetto (o faccia) particolare dell asset. Questa funzionalità è ad esempio impiegata nella pagina dei risultati di ricerca, dove le faccette vengono esposte per categorie dalle widget del modulo SOLR della Digital Library. La selezione di una faccetta aggiunge un filtro a cascata che restringe i risultati di ricerca in quella categoria. Uno specifico servizio denominato di Advanced Search permette di combinare in una sola richiesta numerosi criteri e filtri di ricerca relativi ai diversi metadati indicizzati. Tramite questa chiamata è quindi possibile sfruttare il motore di ricerca utilizzando il linguaggio di interrogazione implementato da SOLR. In questo caso l output generato è quello restituito nativamente dal motore di ricerca. Il form di ricerca avanzata esposto dal modulo Drupal SOLR for DL utilizza questa modalità di interrogazione per costruire un interfaccia complessa che rende disponibile diversi criteri di ricerca che l utente può combinare per focalizzarsi sul suo obiettivo con estrema precisione. In aggiunta alla precedente è esposta una chiamata di Simple Search che permette di interrogare il motore di ricerca in modo semplificato indicando un set di keyword minimale, le tipologie di risorse di interesse e il campo da utilizzare per l ordinamento. Le funzionalità di ricerca e browsing avanzato permettono inoltre la navigazione (e la ricerca) sulla base delle informazioni contenute nei metadati descrittivi. L indicizzazione riguarda i metadati, le relazioni tra gli oggetti presenti nel repository e i contenuti testuali originali e derivati da trascrizioni automatiche o da analisi semantiche. Questa tipologia di navigazione risulta essere molto performante e, grazie al costante allineamento fra indice e contenuti del repository, risulta particolarmente efficiente su alcune modalità di browsing specifico. Il servizio implementa il browsing di strutture organizzative, collezioni e tipologie di contenuti e la modellazione e descrizione delle strutture organizzative e delle collezioni di oggetti digitali. Entrambe le tipologie di entità possono essere organizzate in modo gerarchico o combinate tramite l uso di relazioni. Anche in questo caso viene sfruttata la funzionalità di faceting consentendo il browsing a faccette delle risorse digitali presenti nella Digital Library. Un clic su una faccetta serve perciò come filtro istantaneo in una schermata di browsing come quella fornita dai moduli Drupal. 23

24 5.5 API GIOTTO L accesso a tutti servizi offerti dal Servizio Digital Library è offerto attraverso una serie di API invocabili da una qualsiasi applicazione client. Tutte le API sono implementate attraverso servizi REST e possono fondamentalmente essere ricondotte a tre tipologie distinte: API per il recupero del contenuto degli oggetti che forniscono generalmente una risposta in forma binaria (es. un immagine, un pdf, un video, ecc) API per la navigazione dei metadati o della gerarchia della DL le cui risposte sono sempre in formato JSON API di gestione/amministrazione con risposta in formato JSON Le risposte alle API in formato JSON riportano sempre un codice di successo/errore con l'eventuale causa di fallimento della chiamata. Alcune delle API implementate integrano funzionalità di autenticazione/autorizzazione implementata estendendo e integrando quanto messo a disposizione dal repository sottostante. Dal punto di vista delle autenticazioni infatti Giotto centralizza sia rispetto al frontend che rispetto al backend la gestione degli utenti risultando compatibile con una persistenza implementata su database ma anche con servizi esterni quali LDAP. Per quanto riguarda le autorizzazioni invece la gestione di base implementata dal repository viene estesa ed arricchita da Giotto in modo da eliminarne le rigidità. Le API oltre a fornire un'interfaccia comune per l'accesso alle funzionalità di Giotto si occupano anche di fornire uno strato di separazione con il backend incrementandone in questo modo la scalabilità e l'affidabilità. Risulta infatti trasparente all'utente la presenza di una infrastruttura in alta affidabilità sul backend mantenuta sincronizzata proprio dal layer software di separazione. Questa separazione consente inoltre di rendere completamente indipendente il portale di frontend che si interfaccia al sistema invocando le API rendendolo quindi equivalente ad un qualsiasi altro client che utilizza il servizio. Nella figura seguente sono mostrati due casi tipici di utilizzo delle API di Giotto: utilizzate internamente per l ingestion dei materiali digitali; utilizzate esternamente attraverso chiamate specifiche allo strato di astrazione dei servizi della DL. 24

25 Figura 7 - Esempi di utilizzo delle API di Giotto 5.6 OAI-PMH PROVIDER Il servizio Giotto è conforme allo standard di interoperabilità OAI-PMH agendo implementando sia il ruolo di OAI Provider che il ruolo di OAI Harvester. Tale standard, pubblicato dall'open Archive Initiative, consente la raccolta e la trasmissione secondo un protocollo condiviso di metadati di risorse digitali presenti in archivi distinti. Il doppio ruolo (harvester e provider) implementato da Giotto consente quindi la facile integrazione nel repository di collezioni aventi sorgenti esterne al repository stesso rese disponibili da altri OAI-PMH Provider e, al tempo stesso rendere tali dati e/o altri aggiuntivi fruibili mediante il medesimo standard. Un esempio di implementazione della funzionalità è nell'integrazione in Giotto dei contenuti di U-GOV Ricerca, l Area Funzionale U-GOV progettata per la gestione e il monitoraggio delle attività di ricerca a livello di Ateneo. L'integrazione consente l'esposizione dei metadati di U-GOV Ricerca (in formato MODS) che mediante protocollo OAI-PMH vengono memorizzati nel repository, automaticamente indicizzati e resi ricercabili e disponibili per la consultazione tramite le interfacce di accesso. 5.7 VISUALIZZATORI Il servizio Giotto espone dei visualizzatori specifici in base alla tipologia di contenuto visualizzato. Lo specifico visualizzatore da utilizzare è una delle informazioni definite nel modello dell'oggetto. Nell'attuale release sono previsti le seguenti associazioni tipologie/visualizzatori: Libri: per i libri scannerizzati composti da sequenze di immagini e trascrizioni OCR viene aperto il lettore di libri open source IA Bookreader. Il lettore 25

26 permette di sfogliare il libro a pagina singola, doppia, con griglia di miniature delle pagine e anche di effettuare ricerche full text grazie alla trascrizione OCR. Il visualizzatore gestisce anche l'highlight del testo trovato nelle pagine come risultato delle ricerche. E infine possibile lo sfogliamento automatico temporizzato delle pagine.; Immagini: le immagini vengono aperte alla dimensione massima disponibile dalla finestra del browser all interno della lightbox se il modulo lightbox2 è istallato altrimenti direttamente nel browser; Documenti PDF: i file pdf vengono demandati alle impostazioni del browser dell utente; Video/Audio: i video vengono visualizzati da un player standard html5 e flash erogato mediante la piattaforma di streaming multimediale integrata in Giotto; Mappe: le mappe vengono visualizzate all interno della lightbox tramite il visualizzatore open source djatoka. E' possibile scorrere la mappa oltre l area della finestra ed effettuare lo zoom. Facendo doppio clic o usando l icona con la lente di ingrandimento l utente scatena una richiesta allo strato SDP che genera l immagine alla risoluzione desiderata a partire dall oggetto digitale originale nel repository. Le sezioni di mappa a diversa risoluzione sono presenti nella cache del sistema ed erogate dall imageserver. Nella figura 8 è mostrato un esempio di visualizzazione di un testo (corredato di metadati strutturali) tramite il renderer IA Bookreader. Figura 8 - Accesso ad un testo digitalizzato tramite il visualizzatore di Giotto 26

27 5.8 INTEGRAZIONE U-GOV RICERCA (OAI-HARVESTER) L integrazione di questo servizio rientra nelle attività di supporto allo standard di interoperabilità OAI-PMH. U-GOV Ricerca è l Area Funzionale U-GOV progettata per la gestione e il monitoraggio delle attività di ricerca a livello di Ateneo. Offre le basi per razionalizzare l utilizzo delle risorse, ottimizzare la gestione dei progetti, verificare il raggiungimento degli obiettivi, valutare i risultati e le competenze acquisite. U-GOV Ricerca, ereditando da U-GOV le fondamenta architetturali e lo strato di orchestrazione dei processi, offre anche la necessaria flessibilità per sostenere l evoluzione e la trasformazione delle attività di gestione della ricerca scientifica. Tra le risposte di U-GOV Ricerca alla complessità e alla dimensione che oggi caratterizzano l area della ricerca vi è l apertura controllata dei metadati verso sistemi esterni. Con l implementazione di standard quali OAI-PMH, U-GOV Ricerca fornisce alle università un veicolo per la realizzazione di archivi aperti sul web facilitando la reperibilità e la fruibilità dei propri risultati della ricerca su motori di ricerca nazionali ed internazionali. Il Servizio Digital Library supporta il protocollo OAI-PMH sia agendo da OAI Provider che come OAI Havester, permettendo la raccolta dei metadati esposti da U-GOV Ricerca, quindi a valle di un processo di validazione e autorizzazione. Tramite la funzionalità di harvesting OAI-PMH è possibile definire collezioni della Digital Library alimentate da risorse digitali esposte da OAI-Provider esterni e nel caso di U-GOV Ricerca è possibile ad esempio definire una collezione alimentata con i Prodotti della Ricerca di uno specifico dipartimento dell ateneo. I metadati esposti da U-GOV Ricerca (in formato MODS) vengono memorizzati nel repository e automaticamente indicizzati, resi ricercabili e disponibili per la consultazione tramite il Portale SDL e le interfacce di accesso. Il servizio offre quindi i seguenti vantaggi: i ricercatori e quindi l Ateneo hanno la possibilità di valorizzare i Prodotti della Ricerca rendendoli ricercabili e maggiormente visibili tramite il Servizio Digital Library. le comunità di ricerca e gli studenti hanno la possibilità di ricercare, selezionare e raggiungere i Prodotti della Ricerca e il patrimonio digitale dell Ateneo in modo trasparente da un unico punto, la Digital Library di Ateneo. 27

28 5.9 MODULO DI INTEGRAZIONE MOODLE Moodle è il Learning Management System open source più diffuso in Italia in ambito universitario e scolastico. Tra le molteplici funzionalità, la piattaforma permette la creazione di corsi e-learning fornendo ai docenti la possibilità di creare contenuti ex-novo, di inserire collegamenti a risorse web interne ed esterne e attingendo a repository esterne opportunamente integrate. Dalla versione 2.0 di Moodle quest ultima possibilità è resa disponibile attraverso la funzionalità moodle repository, che permette di cercare e sfruttare in modo trasparente contenuti già caricati nel LMS o presenti in repository esterne. Il Servizio Digital Library mette a disposizione un plugin repository per Moodle che utilizza le API di ricerca e accesso del servizio per estendere il set di repository supportati nativamente dal LMS (tra gli altri Flickr, YouTube e Wikimedia). Questo servizio permette ad un docente Moodle di arricchire i propri corsi e-learning con risorse presenti nella Digital Library di Ateneo utilizzando i classici strumenti di editing che già utilizza normalmente (editor WYSIWYG) ottenendo inoltre: Durante la fase di fruizione lo studente può visualizzare i contenuti provenienti dalla Digital Library in un ambiente diverso, rimanendo nel contesto didattico creato dal LMS e soprattutto mantenendo la possibilità di interagire attraverso le funzionalità offerte dal visualizzatore fornito dal Servizio Digital Library. Lo sfruttamento dei servizi applicativi del Servizio Digital Library permette il riuso e la valorizzazione dei contenuti prodotti dall Ateneo INTEGRAZIONE L2L Cineca fornisce il servizio L2L (Live To Learning) che consente di trasformare in modo quasi completamente automatico le lezioni in aula in contenuti da distribuire via e-learning in modalità asincrona. L2L registra la lezione, la sincronizza con eventuali presentazioni, estrapola e gestisce i metadati dei contenuti. L'integrazione con la piattaforma Giotto prevede la creazione e la conservazione delle lezioni L2L direttamente all'interno del repository e la fruizione mediante l'infrastruttura di streaming INTEGRAZIONE EBSCO Il sistema EBSCO Discovery Service (EDS) permette di raccogliere e rendere accessibili in un unico punto i metadati relativi sia alle pubblicazioni scientifiche 28

29 disponibili in abbonamento che i metadati provenienti dal catalogo OPAC. Il Servizio Digital Library è stato integrato con il sistema EDS in modo da rendere possibile una ricerca integrata tra le risorse presenti e indicizzate nel repository e quelle aggregate in EDS. Sfruttando le API di EDS è stata aggiunto ed esposto un nuovo micro-servizio che permette la costruzione di interfacce di ricerca nelle quali si possono proporre agli utenti sia risorse della Digital Library che risorse provenienti dal catalogo OPAC o censiste tra le pubblicazioni aggregate in EDS. L'integrazione consente all Ateneo il riuso e la valorizzazione di un servizio acquisito aumentando la visibilità delle risorse presenti negli archivi e nelle biblioteche derivanti da abbonamenti a riviste. Le community dell Ateneo hanno inoltre la possibilità di espandere le ricerche effettuate nella Digital Library verso il catalogo OPAC e le altre fonti presenti in EDS SERVIZIO OEMBED oembed è uno standard per l'inclusione di contenuti erogati da un sito web in una pagina esterna. Giotto affianca alla modalità tradizionale di accesso ai contenuti mediante l'uso di token temporali e verifica utente l'erogazione degli stessi secondo lo standard oembed. E' stata quindi creata una specifica API aggiuntiva in grado di comunicare in modalità totalmente conforme allo standard ed erogare parte dei contenuti secondo questa modalità. Il servizio di esposizione oembed è disponibile per le sole risorse classificate in SDL come aperte MEDIAMOSA TRANSCODING Tra i vari servizi di transcodifica previsti successivamente all'ingestion troviamo quelli specifici per contenuti audio/video. Per questa tipologia di contenuti è stato integrato il servizio di trancoding erogato da Cineca mediante piattaforma Mediamosa. Mediamosa è un software open-source, appartenente alla famiglia dei Digital Asset Management Systems (DAMS), che consente la gestione, conservazione, trasformazione ed erogazione di contenuti multimediali compatibile con la quasi generalità dei formati audio/video. 29

30 Sul sistema Mediamosa vengono creati una serie di profili in modo da definire tutte le operazioni di transcodifica audio/video da eseguire sui file di contenuto ricevuti. Al termine dell'ingestion, dopo aver salvato il contenuto nel repository, Giotto procede con il caricamento del contenuto sul server Mediamosa specificando, in base alla tipologia di file, il profilo di transcodifica da applicare. Una volta ricevuto il file Mediamosa si occuperà di generare i transcodificati secondo le direttive del profilo indicato (si veda lo schema della figura successiva, per un esempio di trattamento dei contenuti video tramite la piattaforma Mediamosa). Figura 9 - Lavorazione dei file video attraverso il DAMS collegato a Giotto 5.14 SERVIZO DI STREAMING Il servizio Mediamosa erogato da Cineca viene integrato anche per l'erogazione dei contenuti audio/video mediante le funzionalità di streaming. Il file caricato sulla piattaforma Mediamosa al termine dell'ingestion (eventualmente convertito mediante il profilo di transcoding) viene reso accessibile in streaming attraverso apposite API esposte dalla piattaforma Giotto SERVIZIO DI TRASFORMAZIONE OCR Questo servizio di transcodifica permette il riconoscimento automatico del contenuto testuale nelle immagini. Qualora l'ingestion rilevi oggetti di tipo immagine contenti testo (es. la pagina di un libro scansionato) richiede l'esecuzione della transcodifica una volta concluso il caricamento nel repository. Il servizio di OCR in aggiunta al riconoscimento dei contenuti testuali (che verranno poi passati al servizio di indicizzazione per le ricerche full-text) genera una mappa con le coordinate di tutte le parole contenute nell'immagine (HOCR). Queste informazioni, indicizzate dal motore di ricerca, consentono a visualizzatori specifici di evidenziare i 30

31 risultati delle ricerche direttamente nelle pagine dove sono stati rilevati. Il processo OCR è realizzato tramite il software FineReader Engine per Linux prodotto da ABBYY, azienda leader di mercato nello sviluppo di software per la conversione dei documenti, l acquisizione dati e di soluzioni linguistiche. L utilizzo del software tramite API REST è mediato da un motore di transcodifica che permette la gestione di richieste contemporanee e di gestire tutto il flusso di lavorazione. Il software è stato selezionato sulla base di analisi condotte sia internamente che da parte di grandi progetti Digital Library internazionali ed è stato integrato con l obiettivo di realizzare un servizio di OCR scalabile, robusto ed affidabile sia per la gestione di specifiche applicazioni che per supportare grandi elaborazioni batch. Tra le caratteristiche più rilevanti il riconoscimento multi-lingua tramite l utilizzo di dizionari (sono supportate più di 190 lingue incluse lingue nazionali antiche e moderne), la capacità di trascrivere testo anche se organizzato in colonne o in modo strutturato nella pagina e i formati di output prodotti. Il servizio di trasformazione OCR integrato in SDL prevede un nodo di elaborazione e una contemporaneità di elaborazione di un documento. In figura 10 è schematizzato il processo di lavorazione di un oggetto digitale proveniente da una scansione digitale di un testo. Figura 10 - Processo di lavorazione di un file proveniente da una scansione di un libro antico 5.16 CONCETTUALIZZAZIONE DI DOCUMENTI TESTUALI Concept Mapper è lo strumento integrato nel Digital Library Management System del CINECA che consente di estrarre i concetti più rilevanti dai contenuti di tipo testuale. Realizzato dal CINECA come web service per l analisi automatica di documenti, è 31

32 stato sviluppato all interno del progetto europeo Papyrus - Cultural and historical digital libraries dynamically mined from news archives, per l analisi di news digitali (nell ambito dell attività Targeted Multimedia Content Analysis). Concept Mapper, sfruttando la conoscenza disponibile nelle diverse risorse linguistiche accessibili on-line (Wikipedia, EuroVoc, e altre ontologie, dizionari e thesauri specialistici), consente di analizzare il contenuto di qualsiasi documento con l obiettivo di: 32 identificare i concetti più rilevanti nel contesto del documento e/o in relazione al dominio di riferimento; annotare automaticamente parti del testo con i concetti corrispondenti ed eventualmente con il link alla pagina della fonte che ne fornisce la definizione e la descrizione; associare metadati semantici quali le categorie di appartenenza dei concetti, la traduzione in altre lingue, o altre informazioni disponibili nelle fonti utilizzate; mappare il contenuto del documento su un ontologia specifica. L analisi semantica, in quanto attività di assegnazione di un significato, un senso, all espressione linguistica si concretizza nel processo di disambiguazione che è possibile grazie alle risorse linguistiche utilizzate. Sia Wikipedia che le altre fonti specialistiche (dizionari, thesauri, ontologie) hanno infatti collezioni di sinonimi, utilizzate per identificare il concetto in maniera univoca, e consentono di calcolare misure di vicinanza semantica che possono essere sfruttate per la disambiguazione. Concept Mapper si compone di quattro moduli che eseguono in sequenza le quattro principali fasi dell analisi: a. analisi linguistica e individuazione delle frasi nominali, b. identificazione del concetto corrispondente tramite un processo di disambiguazione, c. selezione in base alla rilevanza e d. associazione (eventuale) del concetto ad una ontologia specifica. Concept Mapper è una delle componenti di analisi che sono state sviluppate dal Cineca ed integrate nel prototipo della Digital Library Papyrus (insieme all Audio Analyst e a sistemi di classificazione automatica). Il suo scopo, in questa applicazione, è analizzare il contenuto di news di tipo tecnico scientifico (in particolare nell ambito delle energie rinnovabili e delle biotecnologie) in diverse lingue (inglese, francese e tedesco) e in diversi formati (sia testo che video, nel qual caso l analisi viene fatta su trascrizioni del parlato) per arricchire il contenuto di metadati semantici e per mapparlo all Ontologia delle News.

33 I metadati vengono sfruttati dal prototipo all interno della Semantic Search, che, a differenza della Keyword Search, aggiunge alla ricerca full text la ricerca tra i sinonimi e le categorie associate al testo (metadati). Il mapping all ontologia viene invece sfruttato all interno della Cross Discipline Search che indirizza la ricerca all Ontologia della Storia e, da questa, all Ontologia delle News. L utente che cerca, ad esempio, wind power, troverà solo 40 documenti con la semplice ricerca full text, ne troverà 150 sfruttando i metadati (la ricerca è allargata a wind energy in quanto sinonimo di wind power ) e ne troverà 117 sfruttando le ontologie (solo i documenti che in specifico trattano di energia eolica sono stati classificati sotto il corrispondente concetto dell ontologia, mentre i rimanenti documenti con tutta probabilità citano questo tipo di energia nel contesto più ampio delle energie rinnovabili). Questa applicazione ha richiesto la creazione di due contesti di dominio (uno per le energie rinnovabili e l altro per le biotecnologie) e può essere facilmente estesa a qualunque altro dominio, a tipologie di documenti diversi dalle news e a lingue diverse. La lingua è infatti uno dei parametri del Concept Mapper, che, nello specifico, individua il dump di Wikipedia, la versione di EuroVoc e quali fonti specialistiche utilizzare e il tipo di parsing del testo da operare nella prima fase dell analisi. Anche il dominio è un parametro del Concept Mapper, che in particolare individua quale contesto utilizzare per il calcolo della rilevanza e, eventualmente, su quale ontologia mappare la conoscenza estratta dal documento. Mentre una lingua deve essere obbligatoriamente definita (di default l inglese), non è necessario che sia definito un dominio specifico. In questo caso la selezione dei concetti si baserà unicamente sulla rilevanza interna al documento. Concept Mapper effettua un tagging automatico dei contenuti testuali - o dai quali può essere estratto del testo - presenti nel repository Giotto. I concetti così individuati vanno ad arricchire i metadati descrittivi già associati alle entità digitali (MODS) e permettono di offrire all utente una nuova "dimensione" (facet) durante la fase di browsing. I concetti vengono rappresentati internamente in formato SKOS, utilizzando come identificativo la URI DBPedia che descrive il concetto, a scopo sia di indicizzazione che di collegamento con i Linked Data. Anche i risultati di concettualizzazione vengono inviati al servizio di indicizzazione in modo di consentire all'utente ricerche su di essi. Il servizio Concept Mapper integrato in SDL prevede l elaborazione della tipologia di risorse Document, per le quali il sistema provvede all estrazione del testo e all identificazione della lingua. 33

34 Il servizio di concettualizzazione prevede la possibilità di elaborare un massimo di due documenti contemporanei VISUALIZZAZIONE DI IMMAGINI AD ALTA RISOLUZIONE (MAPPE) La gestione delle mappe prevede alcuni specifici accorgimenti dettati dalla particolare natura di questa tipologia di contenuti. Le immagini ricevute sono tipicamente ad altissime risoluzioni e di notevoli dimensioni. La generazione di un'immagine statica a bassa risoluzione non garantirebbe all'utente la possibilità di concentrarsi su un dettaglio mediante l'utilizzo delle funzioni di zoom tipicamente utilizzate nella visualizzazione. E' stato quindi implementato un servizio di transcodifica che consente la conversione delle immagini ad alta risoluzione in formato JPEG2000. Tale formato risulta particolarmente efficiente nella compressione e rende possibili compressioni differenziate su una stessa immagine da una zona all'altra permettendo così all'utente di concentrarsi su un particolare ingrandendo una particolare zona mantenendo risoluzioni meno spinte sulle altre. A causa dello scarsa compatibilità con i vari browser del formato JPEG2000 è stato integrato uno specifico visualizzatore (IIP Image viewer) utilizzato per l'erogazione dei contenuti. Il visualizzatore è stato a sua volta integrato con il server open source Adore Djatoka che permette lo streaming dei tile ottenuti dall immagine JPEG HOSTING DEL PORTALE DIGITAL LIBRARY Il Servizio prevede l hosting del Portale Sapienza Digital Library e la manutenzione ordinaria. In assenza di un sistema unificato di gestione degli utenti e di un sistema SSO è previsto il supporto di personale CINECA per la creazione di account di redazione o di specifici gruppi di utenti. I moduli Digital Library del CMS Drupal saranno aggiornati rispetto alle nuove funzionalità sviluppate sul DLMS. Il Servizio durante l anno 2014 prevede la pubblicazione di una nuova release del Portale Digital Library funzionale allo sfruttamento dei nuovi servizi e degli sviluppi apportati al DLMS. 34

35 Moduli di integrazione DRUPAL Drupal è un CMS open source molto diffuso, dall architettura modulare, flessibile e scalabile, utilizzato da numerose realtà istituzionali, accademiche oltre che da privati. I portali universitari, sia pubblici che di servizi, realizzati da CINECA sono realizzati con Drupal. La struttura di Drupal, in particolare nelle sue ultime incarnazioni, permette di costruire vere e proprie applicazioni web integrate con servizi esterni come nel caso dei Servizi Digital Library. La creazione di nuove funzionalità in Drupal avviene tramite la scrittura di moduli. Per implementare la Digital Library in un Portale Drupal sono stati scritti quattro moduli: Digital Library CINECA SOLR for Digital Library CINECA DL auth Monitoring ingestion e transcoding I primi due moduli forniscono componenti architetturali al Portale Drupal sotto forma di pagine e blocchi per la visualizzazione di risorse e risultati di ricerca e non richiedono l istallazione di ulteriori moduli Drupal di terze parti (viene soltanto consigliato il modulo Lightbox2 per una più agevole visualizzazione di immagini e filmati). Il terzo modulo fornisce un interfaccia in Drupal per la gestione delle autorizzazioni di collezioni e risorse all interno del repository. Il modulo di monitoraggio dell ingestion e transcoding è invece un modulo di servizio che fornisce un interfaccia Drupal per controllare lo stato di avanzamento di detti processi. Questa modalità di integrazione garantisce la possibilità di esporre i contenuti della Digital Library attraverso componenti standard di Drupal e la realizzazione di browsing selettivi su alcune porzioni di collezioni, ad esempio all interno di un percorso tematico in un Portale generalista. 35

36