SERVIZI DIGITAL LIBRARY Il Digital Library Management System CINECA

SERVIZI DIGITAL LIBRARY Il Digital Library Management System CINECA in collaborazione con Sapienza Università di Roma Rel. 1.0 White Paper Maggio 2013

CINECA Consorzio Interuniversitario Sede Legale, Amministrativa e operativa: Via Magnanelli, 6/3 40033 Casalecchio di Reno (BO) Tel. 051 6171485 www.cineca.it Altre sedi operative: Via R. Sanzio, 4 20090 Segrate (MI) Tel. 02 269951 Via Ciro il Grande, 16 00144 Roma Tel. 06 5929281 Via dei Tizii, 6 00185 Roma Tel. 06 444861 A cura di Matteo Bertazzo e Federico Giacanelli, con Andrea Buda, Ugo Contino, Franca Fiumana, Paolo Malfetti, Giorgio Pedrazzi, Massimo Spinelli, Stefano Spitoni, Roberta Turra, Salvatore Rago (CINECA) Danila Bigazzi, Fabrizo Guidotti, Sabina Parmeggiani (Art Director), Stefano Pinelli (Alterego s.r.l.) Gruppo di ricerca Sapienza Digital Library: Centro interdipartimentale di ricerca e servizi DigiLab Donatella Capaldi, Cecilia Carloni, Gianfranco Crupi, Maria Guercio, Silvia Ortolani, Giovanni Ragone, Silvio Salza, Marco Schaerf, Isabella Tartaglia Sistema Bibliotecario Sapienza Angela Di Iorio, Adriana Magarotto, Maura Quaquarelli, Giovanni Solimine, Ezio Tarantino Con la collaborazione di Francesca Cinquina, Manuela Corbosiero, Manuela Grillo Con il supporto di InfoSapienza CINECA Questo documento non può essere riprodotto o trasmesso in alcuna forma o attraverso alcun mezzo elettronico o meccanico, per alcun scopo, senza previa autorizzazione da parte di CINECA. Dipartimento Gestione dell Informazione e della Conoscenza.

INDICE IL DIGITAL LIBRARY MANAGEMENT SYSTEM CINECA... 5 Introduzione: dal Progetto Sapienza Digital Library al Digital Library Management System... 5 La genesi del progetto... 5 Il Digital Library Management System e il Servizio... 6 Processi di filiera... 7 Catalogazione... 8 Management... 8 Applicazioni... 8 Architettura del servizio... 9 Funzionalità e soluzioni software integrate... 9 Acquisizione delle risorse digitali... 9 Transcodifica... 9 Il deposito digitale... 9 Indicizzazione e ricerca... 9 Dissemination... 10 Le componenti dell architettura... 10 Componenti infrastrutturali e repository... 13 Digital Library Service Delivery Platform: la piattaforma API... 15 Catalogazione delle collezioni e delle risorse digitali... 19 Acquisizione delle risorse digitali... 21 Pacchetto informativo e pacchetto di versamento... 21 Submission Information Package... 22 Profilo METS... 23 Workflow di ingestion... 25 Monitoraggio della fase di ingestion... 29 Archiviazione dei pacchetti AIP... 29 Trattamento ed enrichment delle risorse digitali... 35 Il motore di transcodifica... 35 Le API di transcodifica... 36 Servizi di transcodifica e workflow di ingestion... 39 Monitoraggio dei processi di transcodifica... 40 Gestione autenticazioni e autorizzazioni... 41 Indicizzazione e ricerca... 43 Funzionalità di faceting... 43 Advanced e Simple Search... 43 La funzionalità di browsing... 44 Similarity... 44 Full-text search... 44 SERVIZI INTEGRATI... 45 Concept Mapper generazione automatica di metadati semantici per Digital Libraries... 47 Il processo di analisi... 47 Applicazioni... 49 Benefici... 51 1

2 Il servizio Multimedia Asset Management and Distribution MediaMosa... 53 Funzionalità del Servizio Mediamosa... 54 I vantaggi dell integrazione... 55 Servizio di registrazione di persistent identifier (DOI)... 57 Servizi basati sul DOI... 58 Servizio di streaming... 61 Descrizione... 61 Il servizio di streaming live... 62 Il servizio di streaming on-demand... 62 Pubblicazione: presentazione dei contenuti... 63 Servizio di Content Delivery Network (opzionale a richiesta)... 63 Servizio di trascrizione OCR... 65 Il software OCR utilizzato... 65 I vantaggi dell integrazione... 66 MODULI DI INTEGRAZIONE... 67 Integrazione con la piattaforma Learning Management System Moodle... 69 I vantaggi dell integrazione... 70 Integrazione con U-GOV Ricerca... 71 I vantaggi dell integrazione... 71 Integrazione con EBSCO Discovery Service... 73 I vantaggi dell integrazione... 73 Integrazione con il CMS Drupal... 75 I vantaggi dell integrazione... 75 Modello di integrazione "on the fly"... 75 I tipi di asset... 76 Modulo Digital Library CINECA e SOLR for Digital Library CINECA... 76 Pagine... 76 Blocchi... 80 Gli utenti e gli accessi... 89 Il client REST... 89 La cache... 89 Modulo DL Auth... 89 Modulo Ingestion Logs Digital Library CINECA... 91 Esempi di viste... 91 UNA REALIZZAZIONE: IL PORTALE SDL DELLA SAPIENZA... 95 Introduzione... 95 La prospettiva di Sapienza... 95 UN ESEMPIO: UN PROGETTO DI MUSEO VIRTUALE... 97 Il progetto MuVir... 97 Introduzione... 97 Caratteristiche generali del progetto... 97 Funzionalità del portale... 98 L impianto tecnologico... 101 Ingestion...102 Repository...104 La Personal Virtual Gallery...106

Portale MuVir...107 Search & Browsing...107 Faceting e full-text search...108 Visualizzatori...108 Immagini ad alta risoluzione...108 Gestione degli utenti e delle autorizzazioni...108 Conclusioni...109 IL CICLO DEI DIRITTI NELLA SAPIENZA DIGITAL LIBRARY. DOCUMENTO DI LAVORO.... 111 Sapienza Digital Library. Gli aspetti legali... 111 Il ciclo dei diritti... 111 I livelli di valutazione e controllo dei diritti... 112 Le entità del ciclo dei diritti in SDL... 113 I soggetti...113 Le azioni...114 Le relazioni...115 Gli oggetti...116 INFRASTRUTTURA CINECA... 117 3

IL DIGITAL LIBRARY MANAGEMENT SYSTEM CINECA Introduzione: dal Progetto Sapienza Digital Library al Digital Library Management System La genesi del progetto Il Digital Library Management System alla base del Servizio Digital Library Cineca è il frutto del Progetto Sapienza Digital Library, condotto in partnership da Cineca e dall Università Sapienza di Roma. Il Progetto Sapienza Digital Library nasce dall idea di raccogliere in un unico sistema di deposito digitale la produzione intellettuale della Sapienza passata e futura, già nata digitale (born-digital) o tradotta successivamente in formato digitale attraverso un processo di digitalizzazione. Il Progetto ha avuto come obiettivo iniziale quello di integrare 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 il cui copyright non sia stato ceduto), immagini in formato digitale, materiale audiovisivo, materiale audio, materiali didattici (anche per uso nei corsi in e- learning), User Generated Content, materiale specifico (schede di scavo archeologico, materiale di archivio, dataset). Tutto questo materiale digitale doveva essere anche organizzato e catalogato in modo da poter essere messo a disposizione dell intera comunità accademica. Le strutture dell'università di Roma "La Sapienza" possiedono un enorme patrimonio, nelle aree umanistiche come in quelle scientifiche, e la possibilità di valorizzare e di riutilizzare costantemente il patrimonio digitale costituisce un asset strategico riconosciuto come tale dalle maggiori università a livello internazionale e per questa ragione è oggetto di specifiche azioni e investimenti. Il Progetto SDL nasce sin dall inizio con una visione consortile, con l intenzione 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à, in modo da poter essere facilmente adottate e sfruttate dalle altre università consorziate. Il risultato dei tre anni di lavoro del Progetto è un infrastruttura complessa e flessibile, modulare e ricca di funzionalità che può quindi essere utilizzata nella sua totalità o in parte, con un livello di granularità tra macro e micro funzioni sotto il controllo dell utente. L 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 preservation (che sarà il tema principale durante il prossimo anno di Progetto). Su ognuna di queste fasi è possibile intervenire interagendo con l infrastruttura mediante 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. I servizi disponibili su un determinato tipo di oggetto digitale sono definiti all interno del modello della tipologia cui appartiene l oggetto. Grazie all astrazione della loro rappresentazione nel deposito il numero di tipologie di oggetti e i servizi ad esse associati sono facilmente estensibili, aumentando gli ambiti di applicazione del Servizio Digital Library agli oggetti più diversi come dataset scientifici, modelli tridimensionali, etc. Nella doppia valenza del termine inglese Library, da un lato quella di Biblioteca, dall altro quella di Libreria Software sta la vera chiave di lettura del Servizio Digital Library Cineca: un deposito di 5

risorse digitali facilmente fruibile, un archivio ragionato e moderno basato su standard internazionali di metadati, un motore di ricerca potente e veloce ma anche un insieme di servizi e interfacce software da usare come mattoncini 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. Il Digital Library Management System e il Servizio Il Servizio Digital Library fornisce l infrastruttura tecnologica e informativa necessaria a realizzare e a gestire un sistema Digital Library incorporando una suite di funzionalità di base, come la catalogazione, l archiviazione, l indicizzazione di metadati e contenuti e l accesso, e integrando applicazioni e strumenti per il supporto a servizi specializzati necessari alla realizzazione di specifiche funzionalità. Il servizio è stato progettato e realizzato con l adozione di best practice, modelli (conformi al modello OAIS), specifiche e standard internazionali (ISO-16363, METS, MODS, PREMIS, OAI- PMH) e ha come obiettivi primari quello di garantire la massima interoperabilità con analoghi sistemi alla base di progetti nazionali e internazionali (come Europeana) e quello di supportare tipologie di risorse digitali e metadati eterogenei. La soluzione tecnologica è stata realizzata prediligendo l impiego di software open source e l architettura tecnologica alla base del servizio si basa sull interoperabilità, sull integrazione e sulla modularità. Queste caratteristiche rendono sfruttabile il servizio 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 in modo selettivo accedendo e sfruttando puntualmente micro-servizi digital library specifici (come servizi di transcodifica). Scenario di integrazione Digital Library Management System e servizi dell Ateneo 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 6

le componenti dell architettura di un Digital Library Management System, le classi di attori coinvolti e i loro specifici requisiti. Con riferimento al manifesto e al modello DELOS schematizzato nella figura sottostante il Servizio Digital Library Cineca realizza un Digital Library Management System (DLMS) che 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. DELOS Reference Model for Digital Libraries Processi di filiera Il servizio Digital Library permette in definitiva la realizzazione di una filiera produttiva che può essere usata per implementare in tutto o in parte l insieme dei processi richiesti da uno specifico Ateneo. Nella costruzione della filiera sono infatti coinvolti aspetti sia tecnologici che organizzativi. Processi di filiera Le risorse digitali e le collezioni provenienti da un progetto di digitalizzazione o born-digital confluiscono nel sistema e affrontano il primo macroprocesso: 7

Catalogazione Risorse e 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. Management Nel successivo macroprocesso 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. 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. 8

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 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. Funzionalità e soluzioni software integrate Si descrivono le funzionalità e le soluzioni software integrate accompagnando una risorsa digitale - digitalizzata o born-digital - durante il viaggio che la porta dalla sua eventuale digitalizzazione e descrizione al repository, fino a raggiungere l utente finale sotto forma della sua rappresentazione digitale più adatta. 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, drop-box o provenienti da harvesting OAI-PMH, vengono elaborati da procedure 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, ralazioni 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. 9

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 Drupal1 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. Le componenti dell architettura Il cuore dell architettura adottata per il Servizio Digital Library è costituito da un layer di integrazione denominato Digital Library Service Delivery Platform (SDP), che ha come obiettivi primari l integrazione di tutti i servizi coinvolti e la loro esposizione verso il livello applicativo attraverso una API basata su web services di tipo RESTful: fornire una piattaforma API di servizi omogenea e stabile verso il livello applicativo, in particolare verso il Portale Digital Library, e che funge da unico punto di accesso verso tutti i servizi Digital Library; integrare e rendere trasparente l utilizzo del repository e dei sistemi e servizi connessi La figura sottostante esplicita i tre livelli così individuati e specifica gli standard adottati e i framework tecnologici sfruttati per la realizzazione del Servizio. Architettura visione macro Per quanto riguarda lo stack applicativo, il servizio Digital Library è realizzato attraverso l integrazione di software open source: Portale Digital Library: viene integrato il CMS Drupal2; 1 http://drupal.org/ 2 Drupal, www.drupal.org 10

Integration Layer: viene utilizzato Apache Camel3, è un framework dedicato espressamente al messaging, alla trasformazione e al routing di messaggi tra applicazioni, o tra specifiche parti della stessa applicazione; Repository: viene utilizzato il software Fedora Commons4, il quale integra a sua volta una serie di prodotti open source per la gestione, indicizzazione e trasformazione di contenuti digitali; Multimedia Asset Management Platform: viene utilizzato il software Mediamosa, che permette la transcodifica ed il delivery multiformato e multiprotocollo di contenuti audio-video; Visualizzatori: vengono utilizzati il software BookReader e Adore Djatoka, rispettivamente per la visualizzazione di book-scans e di immagini ad alta risoluzione. La figura sottostante fornisce una visione di dettaglio delle componenti software integrate per la realizzazione del servizio ed esplicita a livello applicativo alcuni degli scenari d uso realizzabili. Architettura - dettaglio delle componenti 3 Apache Camel, camel.apache.org 4 Fedora Commons è un Progetto del consorzio Duraspace, 501(c)(3) not-for-profit, http://duraspace.org/about_fedora 11

Componenti infrastrutturali e repository Da un punto di vista infrastrutturale l erogazione del Servizio Digital Library è basata sull integrazione di più componenti: Repository: piattaforma Fedora Commons (webapp J2EE, erogato su nodi replicati in load balancing) Middleware applicativo SDP per procedure di ingestion ed esposizione API DL (webapp J2EE, erogato su nodi replicati in load balancing) Motore di ricerca (Apache Solr, erogato su nodi replicati in load balancing) Server FTP / WebDAV per deposito dei contenuti da parte del cliente Portale DL per l erogazione dei contenuti della DL (CMS Drupal erogato in modalità farm su nodi replicati in load balancing) Sistema di conversione OCR (SW commerciale erogato su nodo dedicato) Applicazioni di supporto per image server, visualizzatori, convertitori di formato, webapps J2EE, applicativi di sistema (erogati su nodi replicati disitinti da repository e CMS) Alla base dell architettura è collocato il repository multimediale Fedora Commons replicato su due nodi gemelli in bilanciamento di carico e sotto backup quotidiano. I nodi sono esattamente replicati in modo da poter subentrare uno all atro in caso di malfunzionamenti. I due nodi repository sono mantenuti costantemente allineati da una procedura software appositamente sviluppata (mirroring). La descisione di sviluppo interno è stata presa dopo aver scartato una serie di altre procedure di allineamento in quanto non totalmente conformi ai rigidi vincoli posti sul Servizio. La disponibilità dei due nodi ha inoltre permesso di indirizzare le operazioni di ingestion su uno dei due nodi e in modo da non sovraccaricare il secondo nodo, mantenuto più scarico per meglio servire le richieste provenienti dal frontend. Il nodo dedicato all erogazione dei contenuti è mantenuto allineato mediante un procedura computazionalmente molto più leggera rispetto all intero workflow di ingestion. I due nodi sono classificati come: leader: nome che identifica il nodo sul quale vengono effettuate le operazioni di ingestion; follower: identifica la macchina dedicata all erogazione dei contenuti (in modalità read-only rispetto alle invocazioni di mangement previste dalla API) La procedura di allineamento intercetta tutte le operazioni di inserimento, cancellazione e modifica di un qualsiasi oggetto contenuto nel repository leader segnalandole mediante un sistema di messaggistica dedicato al nodo follower. Quest ultimo, alla ricezione di un messaggio, confronta ogni singolo datatstream locale dell oggetto segnalato con i datatstream dell oggetto sul nodo leader e, quando necessario, effettua l allineamento. Ogni oggetto caricato sul repository viene salvato sul file system in una directory che in base alla tipologia di datastream può essere gestita da Fedora Commons stesso o indirizzata in modo diretto (referenced datastream). La sezione metadati viene salvata in formato FOXML mentre eventuali file binari presenti negli oggetti figli vengono rinominati e salvati in una speciale gerarchia di directory gestita da un algoritmo interno a Fedora Commons (datastore). 13

Digital Library Service Delivery Platform: la piattaforma API L accesso a tutti servizi offerti dal Servizio Digital Library è offerto attraverso una serie di API invocabili da una qualsiasi applicazione client (Il Portale è da considerarsi a tutti gli effetti come un generico client). Tutte le API sono implementate attraverso servizi REST e possono fondamentalmente essere ricondotte a due 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 metatdati o della gerarchia della DL le cui risposte sono sempre in formato JSON Di seguito un elenco descrittivo (senza entrare nel dettaglio implementativo) delle funzioni esposte: /content/(user)/(address)/(pid)/part/(part) Funzione per la richiesta di generazione del token di autorizzazione per l accesso ai contenuti binari di un oggetto. Nella risposta (in formato JSON) vengono restituiti i link corredati di token per l accesso al contenuto richiesto /content/(token)/(hexcode)/(user)/(pid)/part/(part)/embedding Utilizzabile solo per alcune tipologie di oggetti, restituisce un frammento di codice, previa verifica delle credenziali, per l embedding di un contenuto in una pagine di un client /content/(token)/(hexcode)/(user)/(pid)/part/(part)/page Utilizzabile solo per libri e mappe, esegue l accesso, previa verifica delle credenziali, ad una pagina /content/(token)/(hexcode)/(user)/(pid)/part/(part)/direct Utilizzabile solo per alcune tipologie di oggetti, esegue l accesso, previa verifica delle credenziali, ad un contenuto /content/(token)/(hexcode)/(user)/(pid)/part/(part)/download Utilizzabile solo per alcune tipologie di oggetti, esegue il download, previa verifica delle credenziali, di un contenuto /transcode/ocr/submit Avvia l esecuzione del parsing OCR su un immagine /transcode/conceptmapper/submit Avvia il processo di riconoscimento dei concetti contenuti in un testo mediante il servizio Concept Mapper /transcode/pdf2thumbnail/submit Genera la thumbnail di un oggetto partendo da un binario in formato PDF 15

/transcode/jpeg2000thumbnail/submit Converte un immagine ad alta risoluzione in formato TIFF in un immagine in formato JPEG2000 /transcode/map2thumbnail/submit Genera la thumbnail di un oggetto prendendo in input un immgine in formato jpeg /transcode/mastertosource/submit Genera un immagine a bassa risoluzione data la corrispondente ad alta risoluzione /transcode/tikaservice/gettextbyresourceurl Esegue il riconoscimento del testo contenuto in un file in formato PDF /transcode/tikaservice/getlanguagebytext Esegue il riconoscimento della lingua del testo contenuto in un file in formato PDF /transcode/getstatus Verifica lo stato di avanzamento di un operazione di transcodifica dato l identificativo unico dell elaborazione /transcode/getresultbytoken Recupera il risultato di una operazione di transcodifica dato l identificativo unico dell elaborazione /asset/(pid)/type Restituisce il tipo di un oggetto dato il suo identificativo unico /asset/(pid)/descmetadata /asset/(pid)/summarymetadata Recupera un sottoinsieme dei metadati descrittivi /asset/(pid)/parent Restituisce la collezione di appartenenza di un oggetto /asset/(pid)/hierarchy Restituisce l intera gerarchia delle collezioni di appartenenza fino alla radice /asset/(pid)/contentpackaging Restituisce il METS completo dell oggetto /asset/(pid)/partscount Restituisce il numero di parti di cui è composto un oggetto /collections/(pid) 16

Restituisce la gerarchia contenuta (collezioni e oggetti) /collection/(pid)/descmetadata Restituisce i metadati descrittivi di una collezione /collection/(pid)/summarymetadata Restituisce un sottoinsieme dei metadati descrittivi di una collezione /collection/(pid)/suborgcollections Restiuisce l elenco delle collezioni organizzative contenute in una collezione /collection/(pid)/suborgcollectionscount Restituisce il numero di collezioni organizzative contenute in una collezione /collection/(pid)/subcollections Restiuisce l elenco delle collezioni contenute in una collezione /collection/(pid)/subcollectionscount Restituisce il numero di collezioni contenute in una collezione /collection/(pid)/memberscount Restituisce il numero di tutti gli oggetti (collezioni escluse) membri di una collezione /collection/(pid)/members Restituisce tutti gli oggetti (collezioni escluse) membri di una collezione. Per ogni oggetto viene restituito l identificativo unico, un sottoinsieme dei metadati descrittivi e il link alla thumbnail /collection/(pid)/parent Restituisce la collezione organizzativa di appartenenza di una collezione /collection/(pid)/hierarchy Restituisce l intera gerarchia delle collezioni organizzative di appartenenza fino alla radice /collection/(pid)/contentpackaging Restituisce il METS completo della collezione /(PID)/Type Restituisce il tipo di un oggetto /search Data una stringa in ingresso esegue una ricerca sui contenuti e sui metadati descrittivi /search/ebscosearch 17

Data una stringa in ingresso esegue una ricerca sul servizio EBSCO /search/simplesearch Data una stringa in ingresso esegue una ricerca solamente sul metadato descrittibo title /cataloging/(pid)/findobject Esegue la ricerca di un oggetto proveniente dall applicazione di Cataloging /thumbnail/(pid)/collectionthumbnailimage Restituisce la thumbnail di una collezione /thumbnail/(pid)/part/(part)/thumbnailimage Restituisce la thumbnail di un oggetto 18

Catalogazione delle collezioni e delle risorse digitali Il Servizio Digital Library offre uno strumento web-based di Catalogazione realizzato attraverso il CMS open source Drupal (già impiegato per la realizzazione del Portale SDL). L obiettivo fondamentale è quello di essere di semplice utilizzo, immediato e produttivo, in modo da rendere disponibili in rete quanto prima le risorse 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, mouli ad-hoc, tassonomie) hanno permesso di realizzare delle interfacce di catalogazione complesse che possono essere adattate ai requisiti di uno specifico ateneo. Lo strumento permette: la catalogazione di metadati descrittivi di collezioni e risorse digitali la definizione e l utilizzo di vocabolari controllati 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 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 SDL Lo strumento di Catalogazione è infatti integrato con il processo di ingestion del Servizio Digital Library: le risorse digitali (metadati e contenuti) e le collezioni generate attraverso questo strumento sono esportate sotto forma di pacchetti SIP e ricondotte al normale flusso di ingestion per poi essere archiviate nel repository. Lo strumento permette la catalogazione secondo gli standard di settore (ISAD e ISAAR) e produce e 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. 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 19

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 toponim 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 tre profili di utenti: Administrator: ha la possibilità di definire nuovi utenti ed associare loro il profilo Editor o Validator; ha inoltre la possibilità di associare un utente ad una o più collezioni di risorse e di modificare le tassonomie che alimentano i campi delle form di inserimento di Collezioni e Risorse; Editor: effettua l inserimento, modifica, cancellazione di descrizioni di entità digitali nelle collezioni sulle quali è stato associato con il profilo Editor) Validator: oltre a poter svolgere tutte le funzioni dell editor, valida i metadati a livello di item e a livello di collezione. 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 in uno stato di editing ed esistono soltanto all interno dello strumento di Catalogazione. Con l 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 intere collezioni. 20

Acquisizione delle risorse digitali In questa sezione verranno analizzate in dettaglio le funzionalità di ingestion - ossia di acquisizione dei pacchetti di versamento (SIP, Submission Information Package) dai produttori delle risorse digitali - e di creazione dei pacchetti di archiviazione (AIP Archive Package). Il processo di ingestion è funzionale alle successive fasi di archiviazione, gestione dei dati, amministrazione, preservation planning e accesso previste dal modello OAIS. Tra queste, le fasi di gestione, amministrazione e preservation planning saranno affrontate durante la progettazione e implementazione della nuova versione del Servizio Digital Library che avrà come obiettivo la realizzazione di un sistema di Long Term Digital Preservation. Pacchetto informativo e pacchetto di versamento Per il Servizio Digital Library il pacchetto informativo (che tramite il SIP è oggetto di ingestion) può essere relativo ad una risorsa digitale o ad una collezione, dove per collezione si intende solamente l entità e non le risorse che vi afferiscono. Nell ambito del Servizio Digital Library 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 Digital Library 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. Possiamo quindi affermare che ciò che essenzialmente struttura e compone una risorsa digitale è l'insieme degli oggetti digitali (i file multimediali che ne rappresentano il contenuto) e i metadati che 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. Oltre alle regole definite nel Profilo METS definito dal Servizio l oggetto informativo è sottoposto ai seguenti vincoli: è identificato univocamente all'interno del sistema e il suo identificativo può essere usato per la generazione di oggetti di livello gerarchico inferiore viene individuato nel sistema da un file METS nominato col medesimo identificativo e che contiene tutti i metadati utili e le informazioni necessarie per la corretta esecuzione dell'ingestion deve essere riconosciuto dal sistema come appartenente ad una specifica tipologia tra quelle definite dal Servizio Digital Library e come tale trattata per l attivazione di specifici servizi deve appartenere necessariamente ad una collezione (solo se la risorsa deve essere indicizzata e visionabile da un applicazione client mentre in caso di sola conservazione l appartenenza ad una colleazione non è vincolante) 21

Il pacchetto informativo, oltre che ad una risorsa digitale, può essere relativo ad altri due tipi di entità: la Collezione Organizzativa e la Collezione di Risorse. Ogni collezione deve essere descritta da un file METS specifico che contiene al suo interno i riferimenti utili ad individuare le risorse di appartenenza e le informazioni di sintesi per ogni risorsa. Una Collezione Organizzativa è un insieme di risorse digitali che sono gestite e/o prodotte nell'ambito di competenza di una struttura organizzativa qualsiasi dell'ateneo (dipartimento, biblioteca, centro, istituto, ecc). Vengono di seguito riportate le logiche che governano il modo in cui possono essere gestite le Collezioni Organizzative: una Collezione Organizzativa non può essere sotto-collezione di un'altra Collezione Organizzativa; le Collezioni Organizzative non sono quindi organizzate gerarchicamente ma si presentano in forma atomistica nei confronti dell'ateneo di riferimento; il materiale digitale di una Collezione Organizzativa può contenere al suo interno sia le risorse digitali singole (quindi le singole risorse non appartenenti a nessuna Collezione di Risorse possono essere associate direttamente alla Collezione Organizzativa che le ha prodotte) che organizzate e raccolte in Collezioni di Risorse Le Collezione di Risorse sono un raggruppamento di entità raccolte sulla base di un legame logico, tematico, gestionale o tramite una relazione di altra natura. La Collezione Organizzativa è anche una Collezione di Risorse considerando che le entità appartengono ad una struttura dell'ateneo, non solo dal punto di vista gestionale, ma anche da un punto vista logico. Una Collezione di Risorse deve necessariamente essere associata ad una Collezione Organizzativa. Anche per le Collezioni di Risorse sono definite delle logiche di base: una Collezioni di Risorse può contenere Oggetti Informativi di tipo diverso una Collezioni di Risorse è associata ad una ed una sola Collezione Organizzativa una Collezioni di Risorse non può "produrre" una Collezione Organizzativa una Collezioni di Risorse può contenere zero o più sotto-collezioni di risorse Submission Information Package La gestione delle procedure di ingestion richiede la ricezione di un pacchetto SIP strutturato secondo regole ben definite. Il SIP viene acquisito sotto forma di file ZIP, il nome deve coincidere con la base dell identificativo unico che verrà attribuito all oggetto e deve contenere una directory sempre con lo stesso nome. All interno di questa directory viene verificata la presenza di un file XML in formato METS e conforme al Profilo METS definito nel paragrafo successivo. Considerando le sole risorse digitali il SIP può contenere: solo metadati e quindi limitarsi a contenere solo il file METS che andrà a definire una nuova risorsa nel repository 22

i metadati e gli oggetti digitali, che conterranno un numero variabile di directory allo stesso livello del file METS Un pacchetto di ingestion non può essere sottoposto alla procedura di ingestion senza che questo abbia all'interno il file METS. E' prevista l'ingestion del solo file METS, con la possibilità di aggiornare successivamente il pacchetto di ingestion con gli oggetti digitali e il METS opportunamente aggiornato o, viceversa, effettuare l'ingestion di un solo file METS per aggiornare i metadati di un oggetto già presente nel repository. Il processo di ingestion prevede il versioning di tutte le tipologie di metadati e non dei contenuti testuali o binary (il versioning può comunque essere esteso ai contenuti in fase di configurazione della creazione degli AIP). Profilo METS In questa sezione si intendono fornire tutte le specifiche sulla struttura del METS utilizzato nel Servizio Digital Library (profilo) ad integrazione ed eventualmente limitazione delle definizioni fornite dallo schema di riferimento. Il file è strutturato in 5 macro-sezioni: metshdr, dmdsec, amdsec, filesec, structmap contenute nell elemento root nel quale già troviamo una serie di attributi di fondamentale importanza. METS Root Di questa sezione gli attributi attualmente sfruttati dal sistema sono: OBJID: rappresenta la base per l identificativo univoco di un oggetto digitale all interno di SDL che appone uno specifico prefisso ai fini della gestione interna. TYPE: rappresenta una tipologia di oggetto tra quelli riconosciuti dal sistema. Il valore di questo attributo andrà a definire la struttura dell AIP da generare e definirà l elenco delle operazioni di transcodifica che dovranno essere invocate al termine delle operazioni di ingestion Sono consentiti i seguenti valori: book_scan; image; map; audio; video; document; collection; org_collection LABEL: contiene una breve descrizione associata all oggetto digitale ed il suo valore si ritrova in vari punti del METS stesso, come per esempio nei datastreams contenenti i metadati dell oggetto (datastream con identificativo DC e descmetadata). I campi interessati sono: <dc:title>valore LABEL</dc:title> <mods:titleinfo usage="primary"> <mods:title>valore LABEL</mods:title> </mods:titleinfo> 23

metshdr Element In questo elemento vengono inserite informazioni relative alla data di creazione e di ultima modifica del file nonché informazioni che indicano se per l oggetto siano disponibili solo i metadati descrittivi oppure anche una rappresentazione digitale. All interno del metshdr vengono poi aggiunte una serie di dati che attualmente non influenzano la fase di ingestion ma recano informazioni generali quali il creatore del file mets, l ente responsabile della preservation degli oggetti digitali o altro ancora. dmdsec Element In questo elemento vengono inclusi i metadati descrittivi dell oggetto secondo due differenti standard di riferimento: Dublin Core e MODS (l insieme degli standard supportati è destinato ad ampliarsi in brevissimo tempo con l inclusione nell elenco del MARC21 e di alcuni altri standard della Library of Congress. Gli sviluppi per estendere la compatibilità anche a questi formati sono infatti arrivati alle fasi conclusive). Dal contenuto di entrambi i datastream vengono prelevati tutti i metadati descrittivi dell oggetto sui quali sono state definite (principalmente nel MODS) una serie di convenzioni quali per esempio la definizione della collezione di appartenenza dell oggetto Si rimanda ai paragrafi successivi per l analisi dettagliata delle altre relazioni indicate ma si evidenzia fin da ora la presenza di una serie di elementi utilizzati per identificare la tipologia dell oggetto e generati in base all attributo type nell elemento descritto ad inizio paragrafo. La maggior parte dei metadati descrittivi vengono prelevati senza applicare elaborazioni e inoltrati al motore di indicizzazione in modo che possano essere visualizzati, recuperati e filtrati dall utente in fase di navigazione. amdsec Element L elemento amdsec (Administrative metadata section) contiene una serie di metatdati tecnici che consentono al repository di gestire la Long Term Digital Preservation di una risorsa digitale, a queste si aggiungono informazioni per la gestione dei diritti di proprietà intellettuale sull oggetto. ect. La sezione amdsec contiene 4 sottoelementi principali, ciascuno opzionale e ripetibile: Technical metadata <techmd> Intellectual property rights metadata <rightsmd> Source metadata <sourcemd> Digital provenance metadata <digiprovmd> L elemento <techmd> contiene informazioni in merito alla generazione della risorsa digitale e quindi include informazioni di creazione, formato, caratteristiche, digest, etc etc. Lelemento <rightsmd> contiene informazioni di copyright e di licenza associata alle risorse digitali dell oggetto stesso. L element <sourcemd> è utilizzato per registrare le informazioni relative alla sorgente analogica di una registrazione digitale (es. il record MARC per un libro digitalizzato). Questo elemento non è rilevante per materiale born digital. L elemento <digiprovmd> : contiene informazioni sulla provenienza dell oggetto. Viene espresso utilizzando PREMIS. 24

filesec Element L elemento contiene i riferimenti ai file correlati. Si pensi per esempio ad un immagine ed alle loro molteplici varietà di formato, ad esempio TIFF, JPEG, PNG, etc etc. Per ciascun formato si fa riferimento ad un elemento all interno del quale vengono esplicitate le informazioni di specifico interesse come ad esempio MIMETYPE, SIZE, CHECKSUM, etc etc. structmap Element Questo elemento serve a delineare la struttura gerarchica per l'oggetto e i collegamenti fra gli elementi della struttura e i file di contenuto e i metadati che riguardano ciascun elemento. Lo structmap Element codifica la gerarchia attraverso una serie di elementi innestati. Allo stato attuale il Servizio Digital Library non sfrutta questo elemento (nessun caso d uso finora riscontrato). Workflow di ingestion L avvio del workflow di ingestion avviene collocando il pacchetto SIP in un apposita area di watching rappresentata da una directory monitorata da una procedura software che una volta rilevata la presenza di un nuovo file SIP avvia il processo di ingestion. Il Servizio Digital Library mette quindi a disposizione dell Ateneo (producers) 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 quattro 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 ) caricamento tramite utilizzo diretto dell API di ingestion esposta da SDP Una volta rilevata la presenza di un nuovo file questo viene trasferito in una directory di lavoro e rinominato. Da questo momento in poi eventuali errori causeranno l'uscita dalla procedura di ingestion e il trasferimento del file in apposita area di salvataggio dei SIP rigettati. Il seguente schema rappresenta tutte le fasi del processo di ingestion. 25

Workflow di ingestion - dettaglio dei processi La procedura ha inizio con la decompressione del file, ne viene verificato il contenuto mediante antivirus e la struttura (viene verificata la presenza di un file xml in formato METS generato da Sapienza che deve essere inserito all'interno di in una directory avente lo stesso nome del file xml e coincidente con la base dell identificativo dell'oggetto). Il contenuto del METS viene quindi validato e ne viene controllato del checksum dei vari file contenuti nello zip. 26

Passati i controlli preliminari viene generata una directory di lavoro all interno del SIP scompattato nella quale verranno creati i file generati dalla procedura. A questo punto viene avviato il parsing del contenuto del file xml. Verrà generato un file METS.xml per l'oggetto e tanti file METS_XXXXX.xml per ogni file esterno in quanto la struttura dell AIP prevede che nel repository questi diventino oggetti distinti legati all oggetto padre mediante una specifica relazione. Ad ogni oggetto figlio può essere associato un oggetto derivato il sui scopo è contenere i risultati delle operazioni di transcodifica eseguite al termine del workflow di ingestion. Si avrà quindi la seguente struttura: METS.xml: l'oggetto di riferimento del quale si sta facendo ingestion; METS_XXXX.xml: i-esimo figlio dell'oggetto METS_XXXX_DERIVATES.xml: derivato dell'i-esimo figlio In fase di generazione dei METS figli viene eseguita anche la caratterizzazione dei file mediante il tool manager FITS5. FITS identifica, valida ed estrae metadati tecnici per un ampio numero di formati di file. Si definisce tool manager in quanto si occupa di integrare una serie di tool sviluppati da terze parti tutti deputati alla caratterizzazione di specifici formati di file. Con questo paradigma si ottiene lo scopo di integrare, estendere e verificare i risultati dei singoli tool estendendo la compatibilità globale ad un ventaglio di formati decisamente più ampio rispetto a quanto ottenibile mediante l utilizzo di uno solo dei software integrati come evidenziato di seguito: 5 File Information Tool Set - http://code.google.com/p/fits/ 27

Identificazione Validazione Estrazione metadati Totale formati DROID x >1000 Exiftool x x ~200 FFident x ~50 File utility x >1000 JHOVE x x x 11 MediaInfo x x ~30 NLNZ ME x x ~20 Tool di file characterization integrati da FITS L'integrazione di tool differenti può anche portare a risultati discordanti che il sistema segnala in modo che possano essere corretti da configurazione (scegliendo per uno specifico formato solo uno degli output disponibili) oppure semplicemente riportati all'utente. Terminata senza errori la generazione dei file xml viene avviata la procedura di caricamento nel repository. Per quanto riguarda gli aspetti di autorizzazione attualmente non viene utilizzato il formato PREMIS ma viene inserita nel SIP una directory POLICY contenente un file con le definizioni in formato XACML. Sugli oggetti collection anche se non viene rilevata nessuna polocy nel SIP ne viene comunque creata una di default per la collection stessa e tutti gli oggetti contenuti. La gestione delle autorizzazioni verrà approfondito in uno dei paragrafi successivi. Come già anticipato, 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, in caso invece di uscita senza errori il SIP viene archiviato in apposita area deputata alla conservazione degli oggetti già inseriti. Terminata questa fase viene alimentata la coda dello scheduler di transcoding che, operando in background, si occupa di eseguire una serie di trasformazioni/integrazioni dei contenuti degli oggetti. Ad ogni variazione del contenuto del repository viene notificata a tutti i sistemi integrati l'indicazione dell identificativo e dell'operazione effettuata; in particolare, tra i sistemi integrati quello di indicizzazione (realizzato tramite il motore di ricerca open source Apache Solr) ha così la possibilità di mantenere aggiornato l indice dei contenuti interrogabile dalle applicazioni di frontend (in primis il Portale Digital Library Drupal). Allo stesso modo, in caso di eliminazione di un oggetto, il sistema genera un opportuno messaggio in modo che il motore di ricerca proceda con l eliminazione dall'indice. 28

Monitoraggio della fase di ingestion La fase di ingestion, che inizia dopo il deposito e il rilevamento di un nuovo SIP da parte del processo di watching, è monitorabile attraverso specifiche pagine del Portale che consentono di avere una visione macro (a livello di ingestion di un singolo pacchetto SIP) o di dettaglio (a livello di singola operazione effettuata durante la fase di ingestion). Il riepilogo delle operazioni effettuate è navigabile sia a livello globale per visualizzare l elenco delle sessioni di ingestion: che a livello di dettaglio della singola sessione al fine di meglio individuare eventuali cause di errore: Archiviazione dei pacchetti AIP 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 saranno oggetto di archiviazione nel repository. 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 29

Collection) per quanto rigarda le collezioni, vengono archiviati indipendentemente dalla tipologia all interno del repository sfruttando i meccanismi offerti dal software Fedora Commons. Gli strumenti di modellazione degli AIP nel repository Fedora Commons si basa su due concetti fondamentali, quello di Fedora Digital Object e quello di Fedora Content Model Architecture, entrambi sfruttati a pieno dal Servizio Digital Library. 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 interfaccie, per guidare i workflow che agiscono sui contenuti, per descrivere la stuttura 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. Partendo dai Content Model di base offerti da Fedora Commons (le funzioni di base del repository stesso si basano su questi modelli) si possono definire nuovi modelli per estensione attraverso un linguaggio formale. 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. 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. Modellazione degli AIP nel Servizio Digital Library Il Servizio Digital Library sfrutta a pieno la Content Model Architecture implementando un modello completamente atomistico. 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 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. 30

Identificativi degli AIP Ogni oggetto del repository ha un identificativo univoco denominato PID (Persistent Identifier). Gli oggetti padre hanno il PID ottenuto concatenando un prefisso al PID specificato nel file METS (METS header) contenuto nel SIP che lo ha generato e il file stesso che svolgeva la funzione di container del SIP (ZIP) è nominato con questo identificativo. Gli oggetti figli, oltre ad avere una relazione che li lega all oggetto padre, hanno un identificativo ricavato gerarchicamente dall identificativo del padre. Definizione degli AIU Gli oggetti padre sono in relazione con gli oggetti figli sulla base di relazioni RDF che descrivono anche la semantica della relazione stessa (modellazione atomistica). Vista l importanza del modello Common Metadata viene descritta la struttura in dettaglio; un oggetto di questo tipo contiene i seguenti datastream: DC datastream che contiene un insieme minimo di metadati derivati dal datastream descmetadata descritto sotto; ORIGINAL_DC - datastream contenente il DC originale presente nel file METS fornito con il SIP RELS-EXT - datastream che contiene le relazioni (ad esempio hascontentmodel, ismemberof o ismemberofcollection) espresse in formato RDF contentpackaging - datastream che contiene l intero file METS contenuto nel SIP descmetadata - datastream che contiene i metadati descrittivi presenti nel METS alla sezione dmdsec (ad esempio MODS, MARC21, ecc) contentmetadata - datastream che contiene la sezione structmap del METS fornito nel SIP premis_rightsstatement, premis_objects, premis_events - datastreams che contengono le informazioni PREMIS Come ogni Content Model Common Metadata definisce inoltre un set di metodi (servizi) che agiscono in lettura su questi datastream rendendoli disponibili nel sistema. La figura seguente rappresenta un pacchetto di versamento e la sua rappresentazione tramite Content Model Architecture come AIU (trattandosi di una risorsa digitale, nello specifico una immagine) nel repository. 31

Esempio di pacchetto di versamento e relativo AIU Come rappresentato in figura gli oggetti figli riferiscono a content model che definiscono datastream per i metadati tecnici (provenienti dal METS o estratti attraverso il tool di caratterizzazione) e per i contenuti digitali (nell esempio i datastream SOURCE e MASTER). All'interno del repository sono stati creati differenti Content Models in modo da caratterizzare il comportamento dei differenti tipi di risorse digitali. Sono attualmente definiti i seguenti Content Model: genericvideo genericaudio genericimage genericbook genericmap genericdocument Questi Content Model realizzano funzionalità strettamente legate alla tipologia e alla struttura dell'oggetto e portano a identificare per ognuno una esatta tipologia e a caratterizzarne il comportamento. Definizione degli AIC Il meccanismo della Content Model Architecture è sfruttato anche per l archiviazione delle collezioni in pacchetti AIC. Il Servizio Digital Library eclina le collezioni in due tipi: le Collezioni di Risorse e le Collezioni Organizzative. 32

Gli oggetti di questo tipo, oltre a derivare dal Content Model Common Metadata già descritto al paragrafo precedente, afferiscono a Content Model specifici che definiscono specifici servizi utili alla fruizione delle collezioni e ad ottenere le caratteristiche dei relativi membri. Di seguito uno schema che rappresenta una risorsa digitale e la collezione di appartenenza specificando le relazioni RDF e i Content Model coinvolti. La figura sottostante raffigura le strutture di un AIU che archivia una risorsa digitale di tipo immagine e di un AIC che archivia la collezione di appartenenza. Sono indicate le relazioni tra gli oggetti e in rosso i Content Model di riferimento per ciascun oggetto. Esempio di strutture AIU e AIC Versioning degli AIP Il Servizio Digital Library sfrutta le funzionalità offerte dal repository anche per implementare il 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 modifica effettuata su un oggetto (anche il semplice cambiamento della label dell oggetto) viene registrata in uno specifico datastream di sistema non modificabile. 33

Trattamento ed enrichment delle risorse digitali Le interfacce che costituiscono l API esposta dal Servizio Digital Library comprendono una serie di servizi che permettono di sfruttare funzionalità di trattamento ed enrichment delle risorse digitali presenti nel repository (comunemente raccolte sotto il termine transcoding). Tutti questi servizi sono usati sia internamente, nel contesto dei workflow stabiliti a valle della fase di ingestion, che raggiungibili da client e applicazioni dell Ateneo, che possono impiegarli direttamente sulla base di workflow stabiliti e gestiti autonomamente. Transcoding uso interno ed esterno dei servizi Il motore di transcodifica Considerate le caratteristiche delle elaborazioni di transcodifica (spesso sono operazioni CPU intensive e lunghe), il numero di operazioni che potenzialmente devono essere gestite (si pensi al numero di job di transcodifica generato dall ingestion di un libro digitalizzato) e il fatto che le richieste possono essere generate da workflow interni (ingestion) ed esterni (richiesta asincrona effettuata da una applicazione esterna), si è resa necessaria l introduzione di un componente denominato transcoding engine incaricato di ricevere le richieste e di effettuarne lo scheduling sulla base di regole specifiche per ogni tipo di elaborazione. L operazione di trasformazione di una mappa antica digitalizzata ad altissima risoluzione conferita in formato TIFF è molto diversa in termini di richiesta di risorse di elaborazione rispetto a quella di trasformazione di formato di una immagine acquisita in bassa risoluzione. E quindi necessario poter stabilire delle regole per ogni tipologia di elaborazione (come il numero di elaborazioni contemporanee gestite dal sistema). Alcuni servizi di transcodifica si basano inoltre sull output generato da un altro servizio di trasformazione ed è quindi necessario stabilire un ordine di produzione dei transcodificati. 35

Le API di transcodifica Il servizio di transcodifica è realizzato mediante l esposizione di uno specifico set di API implementate su un nodo dedicato ed esposte all esterno mediante l engine SDP. Quest ultimo si pone come proxy verso il motore di transcodifica. Il set di API esposte è molto granulare in modo da permettere alle applicazioni client l implementazione di workflow complessi mediante l invocazione di servizi differenti organizzati sulla base di specifiche regole di business. Ogni richiesta di transcodifica prevede una specifica invocazione esterna all API nella quale viene specificato il contenuto in input. Questa che crea una sessione di transcodifica alla quale viene attribuito un identificativo utilizzabile per verificare l avanzamento dell elaborazione e scaricare il risultato generato. Il contenuto in input e in output può essere rappresentato da un contenuto in formato binario, ad esempio un immagine, o testuale. Workflow di transcodifica Tutti i servizi elencati sono realizzati in modalità asincrona e la loro invocazione avvia un processo che si occupa dell elaborazione e che una volta ultimato ritorna al client in modo sincrono un identificativo di sessione da utilizzare per invocare due ulteriori servizi: /transcode/getstatus, per verificare lo stato dell elaborazione /transcode/getresultbytoken, per effettuare il download dei risultati dell elaborazione Di seguito la descrizione delle API disponibili: 36

Nome del servizio Dettagli CONCEPT MAPPER SERVICE Nome chiamata API /transcode/conceptmapper/submit Obiettivo Analisi semantica ed estrazione dei concetti da un testo Descrizione Concept Mapper è un servizio realizzato da Cineca che, sfruttando la conoscenza disponibile in diverse risorse linguistiche (Wikipedia, EuroVoc e altre ontologie, dizionari e thesaurus specialistici) consente di estrapolare da un documento testuale i concetti più rilevanti in relazione al contesto e al dominio del documento stesso. I concetti restituiti posso essere eventualmente linkati alle pagine Wikipedia per una descrizione approfondita. Il servizio riceve in input, oltre all URL dal quale prelevare il contenuto sul quale ricercare i concetti, una serie di parametri operativi quali la tipologia di risultato da restituire e la soglia oltre la quale considerare significativo un risultato. Al termine dell elaborazione viene generato un file RDF SKOS che viene inserito in un datastream Fedora Commons e indicizzato JPEG2000 SERVICE Nome chiamata API /transcode/jpeg2000/submit MAP TO THUMBNAIL Obiettivo Descrizione Nome chiamata API Conversione un file in formato TIFF in formato JPEG2000 Il servizio si occupa di eseguire una conversione di formato su un immagine ad alta risoluzione (tipicamente in formato TIFF). Al termine dell elaborazione viene generata in output la conversione in formato JPEG2000 per generare un file compatibile con il visualizzatore Adore Djatoka /transcode/map2thumbnail/submit SERVICE Obiettivo Generazione la thumbnail di una immagine ad alta risoluzione Descrizione Il servizio si occupa di creare una thumbnail per il contenuto digitale partendo da un immagine ad alta risoluzione. L elaborazione realizza una conversione dell input fornendo in output un immagine strutturata nel repository per essere utilizzata come thumbnail sfruttabile ad esempio da una interfaccia web Digital Library. OCR SERVICE Nome chiamata API /transcode/ocr/submit Obiettivo Riconoscimento del testo contenuto in una immagine 37

Descrizione La funzione implementa le funzionalità di riconoscimento del testo partendo da un immagine ricevuta in input. Il servizio demanda l elaborazione al software ABBYY FineReader. I test prestazionali hanno suggerito di installare l OCR su una macchina dedicata sgravando il nodo di transcoding del carico computazionale generato da tale elaborazione. Tale divisione è trasparente all utente che si interfaccia sempre e comunque al nodo di transcoding. Il servizio viene utilizzato ad esempio per ricavare il testo contenuto nelle immagini che costituiscono un book-scan PDF TO THUMBNAIL SERVICE Nome chiamata API /transcode/pdf2thumbnail/submit Obiettivo Descrizione Generazione di una thumbnail da un documento PDF Il servizio si occupa di generare la thumbnail di un contenuto digitale (un documento) ricevendo in input un file in formato PDF IMAGE TO JPEG SERVICE Nome chiamata API /transcode/mastertosource/submit Obiettivo Descrizione Generazione di immagini compresse (JPEG) a partire da immagini ad alta risoluzione Il servizio si occupa di convertire in formato JPEG un immagine ricevuta in input nei formati FITS, TIFF o JPEG2000. E utilizzato ad esempio per gestire book-scans di formato differente privi delle versioni compresse delle pagine acquisite TIKA SERVICE Nome chiamata API /tikaservice/gettextbyresourceurl /tikaservice/getlanguagebytext Obiettivo Descrizione Estrazione del testo da un file remoto e identificazione della lingua dato un testo Il primo servizio, data la URL di un documento remoto estrae il testo contenuto. Il secondo analizza il testo ed identifica la lingua in cui è scritto. Il servizio può essere usato ad esempio prima dell invocazione del servizio ConceptMapper per aumentare la qualità dei concetti estratti. MEDIAMOSA SERVICE Nome chiamata API /transcode/audiovideo/submit Obiettivo Transcodifica di un contenuto audiovideo in un formato e/o una codifica diversa Descrizione I servizi permettono di effettuare la transcodifica di un contenuto audiovideo in base 38

a un profilo predefinito. L elaborazione viene demandata al servizio Mediamosa integrato Servizi di transcodifica e workflow di ingestion Nel caso di processi di transcodifica derivanti da operazioni di ingestion i servizi di transcodifica entrano in gioco dopo che le risorse digitali sono state completamente archiviate nel repository. In questo caso l obiettivo di queste elaborazioni è quello di rendere più complete le informazioni di ogni risorsa digitale o di renderle più facilmente fruibili attraverso le interfacce e i visualizzatori. Il Servizio Digital Library utilizza i servizi di transcodifica seguendo un workflow dipendente dalla tipologia di oggetto digitale e dalla sua struttura. La tabella sottostante fornisce una descrizione dei workflow attualmente previsti rispetto alla tipologia di risorsa digitale: Tipologia di risorsa digitale Workflow Book-scan Generazione delle immagini delle pagine a bassa risoluzione (in caso di presenza delle sole immagini ad alta risoluzione) OCR sui contenuti delle singole pagine Document Generazione della thumbnail dal contenuto a bassa risoluzione Estrapolazione del contenuto testuale del documento Generazione della lista concetti mediante l'invocazione del servizio Concept Mapper Image Generazione del contenuto a bassa risoluzione (in caso di presenza del solo contenuto ad alta risoluzione) Map Generazione del contenuto in formato JPEG2000 partendo dal contenuto ad alta risoluzione Generazione della thumbnail della mappa dal contenuto a bassa risoluzione Video Upload del video verso il servizio Mediamosa e transcodifica (se necessaria) del contenuto in un formato fruibile attraverso il frontend Audio Upload del video verso il servizio Mediamosa e transcodifica (se necessaria) del contenuto in un formato fruibile attraverso il frontend Al termine dei processi di transcodifica i derivati vengono memorizzati nel repository del Servizio in datastream denominati rispettivamente: Book datastream SOURCE sull oggetto di tipo SOURCE datastream OCR_TXT, OCR_XML, OCR_PDF sul derivato del SOURCE Document datastream THUMBNAIL sul derivato del SOURCE datastream CONCEPTS sul derivato del SOURCE 39

Image Map Video Audio datastream TEXT sul derivato del SOURCE datastream SOURCE sull oggetto di tipo SOURCE datastream JPEG2000 sul derivato del MASTER datastream THUMBNAIL sul derivato del SOURCE Non viene generato nessun datastream in quanto viene invocato direttamente il servizio di streaming di Mediamosa Non viene generato nessun datastream in quanto viene invocato direttamente il servizio di streaming di Mediamosa Monitoraggio dei processi di transcodifica Considerato il meccanismo asincrono alla base dei servizi di transcodifica diventa essenziale poter monitorare lo stato delle elaborazioni. Il Servizio fornisce quindi un interfaccia di monitoraggio che permette di: visualizzare le informazioni di base di ogni processo di sapere quanti processi sono nelle code di esecuzione, divisi per tipologia controllare la corretta esecuzione e l avanzamento di ogni processo La figura sottostante è tratta dall interfaccia di monitoraggio e fotografa lo stato del transcoding engine in un determinante istante. Interfaccia di monitoraggio dei job di transcodifica Nel caso di processi di transcodifica derivanti da operazioni di ingestion ogni risultato viene istantaneamente reso fruibile dal Servizio alle applicazioni e quindi agli utenti che possono ad esempio accedervi dalle pagine del frontend. 40

Gestione autenticazioni e autorizzazioni La gestione delle autorizzazioni è stata separata su diversi livelli al fine di adeguarsi ad una una architettura complessa come quella SDL. Occorre quindi distinguere le diverse tipologie di accessi possibili al fine di fornire una visione complessiva del layer di sicurezza. L accesso primario avviene ovviamente da un generico client (DL Client), termine con il quale si intende una applicazione (web o meno) che ha la possibilità, tramite il Servizio Digital Library, di accedere, ricercare, gestire i contenuti presenti nel repository. Il Portale SDL rappresenta un esempio di DL Client realizzato attraverso il CMS Drupal che, connettendosi al Servizio Digital Library tramite l'api SDP, permette di fruire i contenuti via web. Per quanto riguarda invece l autenticazione è stata scelta una gestione integrata in modo da accentrare in un unico punto tale gestione. Vengono di seguito descritte le gestioni di autenticazione e autorizzazione sui 3 layer applicativi e le modalità di interazione: Portale SDP Fedora Autenticazione Portale La gestione dell'autenticazione sul portale è realizzata mediante la gestione utenti Drupal che memorizza i dati su un database mysql al quale accedono anche gli altri componenti SDL. Autenticazione SDP SDP non implementa particolari features di autenticazione per l'invocazione dei servizi REST implementati. Per i servizi che espongono contenuti il layer opera come proxy puro delegando l'autenticazione utente al layer di repository sottostante mentre per le altre invocazioni utilizza un account fisso creato per tale layer con diritti di amministrazione. Autenticazione Fedora Per il servizio di autenticazione è stato attivata il layer di sicurezza denominato FESL (Fedora Security Layer) integrandolo mediante un modulo custom con il database utenti Drupal in modo da condividere utenti e ruoli con il portale. Autorizzazioni Portale Le autorizzazioni in fase di navigazione sono totalmente delegate alla gestione utenti Drupal. Per le pagine che comportano l accesso a dei metadati di oggetti contenuti sul repository o ai loro contenuti la gestione prevede una ulteriore verifica delle credenziali di autorizzazione mediante il meccanismo descritto nel successivo paragrafo. Autorizzazioni SDP SDP implementa unai gestione delle autorizzazioni in due fasi: generazione/verifica token di accesso con verifica indirizzo IP client e scadenza temporale 41

proxy verso Fedora per la verifica delle autorizzazioni utente per l'accesso ad uno specifico oggetto/collezione Sono stati individuati una serie di servizi REST per i quali è stata giudicata necessaria la verifica dell'autorizzazione di accesso. In questi casi occorre invocare uno specifico servizio con url del tipo: /asset/<nome utente>/<indirizzo IP>/<PID oggetto>/part/<parte> La risposta alla funzione comporta la generazione di una serie di link corredati di token per l'accesso al contenuto richiesto. Prima della generazione del token, SDP verifica su Fedora l'autorizzazione dello specifico utente sullo specifico oggetto e, solo in caso di risposta positiva procede con la generazione dei link. In caso di utente non autorizzato non viene inserito nessun link nella risposta. In caso di utente autorizzato all'accesso SDP procederà con la generazione di un token applicando un algoritmo che permetta di vincolarne la validità alle invocazioni all'indirizzo IP del chiamante se provenienti entro uno specifico intervallo di tempo (configurabile e attualmente impostato in 300 secondi). Un esempio di link con token può essere il seguente: /asset/<token>/<time>/<nome utente>/<indirizzo IP>/<PID oggetto>/part/<parte>/download Prima di generare il token, SDP verifica su una tabella interna la presenza di una specifica grant che autorizzi l'invocazione del metodo richiesto sull oggetto richiesto per quello specifico utente. Sono infatti previste diverse modalità di accesso ai contenuti di un oggetto quindi esiste la possibilità di definire una serie di capability che realizzino differenti politiche in base all utente, all oggetto (e/o alla sua tipologia) e alla metodologia di accesso. Quanto SDP riceve una richiesta mediante un ink contenente un token questo viene verificato controllando struttura, indirizzo IP del chiamante e validità temporale. Passato il primo controllo verrà eseguito la verifica su Fedora dei diritti posseduti dall'utente. Solo in caso di successo di tutti i controlli verrà consentito l'accesso al contenuto richiesto. In caso di fallimento di uno dei controlli verrà restituto al client un errore di accesso negato. Autorizzazioni Fedora Fedora implementa la gestione delle autorizzazioni mediante il layer FESL che prevede la definizione di policy XACML inseribili in qualsiasi oggetto (non c'è legame tra l'oggetto nel quale risiede la policy e l'eventuale PID al quale effettivamente la policy si riferisce) mediante un datatstream chiamato FESLPOLICY. Nonostante XACML consenta un livello di granularità molto dettagliato nella definizione delle policy sia a livello di utente, sia di azione sia di risorsa per le esigenze del progetto SDL le specifiche richiedono semplicemente la concessione di permessi in lettura a specifici ruoli mappati sul database Drupal. 42

Indicizzazione e ricerca Come rappresentato nello schema di dettaglio dell architettura il Servizio Digital Library integra un motore di ricerca, in particolare il software open source Apache Solr. Le informazioni indicizzate comprendono: i metadati descrittivi delle risorse e delle collezioni le relazioni (che nel repository sono espresse in RDF) definite 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 tramite API specifiche descritte più sopra. Questo permette di ottenere dal motore di ricerca 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 le politiche di boosting (che influenzano l ordine dei risultati di ricerca) o il trattamento del full-text (definizione di stopwords, sinonimi, etc.). Funzionalità di faceting La classificazione a faccette 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. Advanced e Simple Search L API di Advanced Search esposta dal servizio 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 previsto 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 fa uso di 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. E inoltre 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. 43

La funzionalità di browsing Le funzionalità di ricerca e browsing avanzato permettono di navigare e ricercare gli oggetti della Digital Library sulla base delle informazioni contenute nei metadati descrittivi. L indicizzazione riguarda i metadati MODS, le relazioni tra gli oggetti presenti nel repository e i contenuti testuali originali e derivati da trascrizioni automatiche o da analisi semantiche. La navigazione tramite motore di ricerca SOLR è molto performante e, grazie al costante allineamento fra indice SOLR 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 espresse in RDF. 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. Similarity Il servizio DL sfrutta le funzionalità del motore di ricerca SOLR per permettere, dati i metadati descrittivi di una risorsa digitale, di individuare le risorse vicine rispetto a un subset definito di metadati (funzionalità MLT). questa funzionalità è 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à. Full-text search Un altra funzionalità che il motore di indicizzazione SOLR fornisce ai Servizi Digital Library è la ricerca full text all interno dei testi. La ricerca full-text è applicata a contenuti testuali o alla trascrizione in testo di immagini derivanti da processi di digitalizzazione (ad esempio libri moderni) quando disponibile. 44

SERVIZI INTEGRATI 45

Concept Mapper generazione automatica di metadati semantici per Digital Libraries 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, è 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: 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. Una demo del Concept Mapper, rel1.0, è presente su http://conceptmapper.cineca.it. Il processo di analisi Concept Mapper si compone di quattro moduli che eseguono in sequenza le quattro principali fasi dell analisi: 1) analisi linguistica e individuazione delle frasi nominali, 2) identificazione del concetto corrispondente tramite un processo di disambiguazione, 3) selezione in base alla rilevanza e 4) associazione (eventuale) del concetto ad una ontologia specifica. 47

Identificazione dei concetti Uno shallow parser analizza il testo e identifica tutte le frasi nominali presenti. Queste possono essere composte da un solo termine (un sostantivo) oppure da più termini (aggettivo e sostantivo come anidride carbonica, ma anche sequenze di sostantivi separati da preposizioni, come monossido di carbonio, o Presidente degli Stati Uniti d America ). Ogni frase nominale viene ricercata nelle diverse fonti disponibili tramite un exact match e, nelle pagine di Wikipedia, tramite una anchor search cioè sfruttando tutti i diversi modi (espressioni verbali alternative) in cui la pagina viene linkata all interno di Wikipedia stessa. Se la ricerca fallisce, la frase non è riconducibile a nessun concetto noto e viene scartata. Se la ricerca dà luogo a più risultati, scatta il processo di disambiguazione che tiene conto di tutti gli altri concetti già identificati per stabilire il contesto di riferimento. Ad esempio plant può riferirsi a un vegetale oppure ad un impianto industriale. Per entrambi i concetti è possibile calcolare la forza del legame (vicinanza semantica) con tutti gli altri concetti individuati nel contesto del documento in termini di numero di link condivisi, sia in entrata che in uscita, dalle rispettive pagine (internal relatedness, o item relatedness). Il concetto che risulta più vicino al contesto in cui plant compare è quello vincente. Il risultato di questa fase è un insieme di annotazioni, ottenute da diverse fonti, che associano a parti del testo il concetto corrispondente e un valore di rilevanza del concetto stesso, nonché la fonte di provenienza ed eventuali metadati aggiuntivi. Le diverse annotazioni sono armonizzate all interno del framework UIMA. Selezione I concetti più rilevanti, quelli che maggiormente riassumono il significato del documento, hanno alti valori di internal relatedness. Questo criterio è già sufficiente per operare una prima selezione dei concetti. Quando esiste un dominio di riferimento, può tuttavia essere utile generare un contesto di riferimento sulla base del quale calcolare l external relatdness (o domain relatedness). Questo valore indica la forza del legame tra ciascun concetto individuato nel documento ed i concetti rappresentativi di uno specifico dominio (derivabili, ad esempio, da una collezione più ampia di documenti). Le applicazioni finora realizzate, su documenti testuali, indicano infatti come criterio di 48

selezione ottimale una combinazione di entrambe le misure: internal relatedness + external relatedness > 0,5. Questo criterio consente di massimizzare correttezza e completezza dei concetti selezionati, rispetto a quelli manualmente giudicati rilevanti. L external relatedness assume ancora più importanza quando il documento risulta da una trascrizione del parlato. In questo caso il criterio ottimale si basa infatti su: frequenza * external relatedness > 0,45. Ciò è conseguenza del fatto che errori di riconoscimento vocale portano ad individuare concetti errati e quindi ad inquinare il contesto interno del documento, mentre rimane affidabile il contesto di dominio. Il criterio di selezione è uno dei parametri del Concept Mapper e può quindi essere configurato ad hoc per ciascuna applicazione. Mapping ad una ontologia Una volta che un concetto è stato individuato, disambiguato, validato e filtrato, è possibile, se l applicazione lo richiede, associarlo alla sua formalizzazione all interno di una ontologia. Il metodo di associazione sfrutta la struttura dell ontologia e le relazioni in essa definite per creare il contesto di riferimento di ciascun concetto dell ontologia (gruppo di concetti correlati). Il concetto identificato nel documento viene quindi mappato al concetto dell ontologia che massimizza la group relatedness, calcolata sempre sulla base dei link condivisi dalle rispettive pagine che descrivono il concetto, dove, questa volta, il contesto è dato dall ontologia piuttosto che dal contenuto del documento o dal dominio di riferimento. Applicazioni 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. 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 49

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 defalut 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. Altre applicazioni riguardano la Sapienza Digital Library, l e-learning (L2L) e la Navigazione Concettuale dell Offerta Didattica (EduMap). Nel primo caso, il Concept Mapper effettua un tagging automatico dei contenuti testuali - o dai quali può essere estratto del testo - presenti nel repository di Sapienza Digital Library. 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. Concept Mapper è inoltre integrato in L2L (Live to Learning), il servizio Cineca che consente di trasformare in modo semi-automatico le lezioni registrate dal vivo in oggetti pronti per la pubblicazione e l erogazione tramite una piattaforma e-learning. Concept Mapper analizza sia i contenuti testuali (slides) che le trascrizioni del parlato, fornendo i concetti e le relative temporizzazioni (in formato RDF SKOS) per un indicizzazione semantica del contenuto multimediale. Nell ambito dell offerta didattica, il Concept Mapper è la componente principale EduMap, un servizio che, sfruttando le descrizioni che i docenti pubblicano on-line dei propri insegnamenti, 50

fornisce una navigazione basata sui contenuti piuttosto che sulla struttura organizzativa della didattica dell Ateneo. In questa applicazione, la vicinanza semantica tra concetti calcolata dal Concept Mapper in fase di disambiguazione viene utilizzata per individuare i concetti più vicini e fornire una mappa grafica navigabile. Benefici Uno dei vantaggi del Concept Mapper, riguarda l efficacia dimostrata nell analisi delle trascrizioni del parlato. Grazie alla definizione di un contesto di riferimento, la maggior parte degli errori di riconoscimento viene infatti automaticamente eliminata. Uno degli elementi di novità rispetto ad altri strumenti analoghi che nel frattempo sono stati sviluppati, risiede infatti nella possibilità di indirizzare la selezione dei concetti sul dominio di interesse. Un ulteriore elemento di innovazione risiede nel metodo originale di individuare le corrispondenze tra la conoscenza estratta da un documento e la conoscenza formalizzata in un ontologia, tramite trasformazione di una annotazione del documento basata su Wikipedia e altre fonti specialistiche in una annotazione basata sull ontologia. Concept Mapper è di facile integrazione e può essere sfruttato da altre applicazioni ad esempio per raggruppare i documenti in categorie significative, per classificarli in categorie predefinite, per realizzare mappe di navigazione concettuale, per espandere i metadati attraverso i Linked Data, oltre che per un indicizzazione semantica dei contenuti da parte dei motori di ricerca. Pubblicazioni scientifiche Wikipedia based semantic metadata annotation of audio transcripts Giulio Paci, Giorgio Pedrazzi, Roberta Turra proceedings of the eleventh Workshop on Image Analysis for Multimedia Interactive Services (WIAMIS 2010) IEEE Computer Society, Los Alamitos, CA, USA (http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5617667 ) Wikipedia-based approach for linking ontology concepts to their realisations in text Giulio Paci, Giorgio Pedrazzi, Roberta Turra LREC 2010 (http://www.lrecconf.org/proceedings/lrec2010/summaries/132.html) 51

Il servizio Multimedia Asset Management and Distribution MediaMosa Il Servizio Digital Library integra una piattaforma di Multimedia Asset Management and Distribution basata sul software Mediamosa (www.mediamosa.org). La piattaforma è open source e lo sviluppo, la promozione e la governance sono affidate alla Mediamosa Foundation. Mediamosa è un middleware flessibile e scalabile e attraverso una interfaccia basata su API RESTful permettere di sfruttare funzionalità quali: gestione dei metadati e contenuti multimediali (e loro derivati da transcodifica) come servizi CRUD - Create, Read, Update, Delete) gestione degli upload di nuovi contenuti transcoding controllabile, scalabile e monitorabile verso un grande numero di formati e codec audiovideo (supporta gli stessi formati e codec gestiti da FFmpeg, il tool open source utilizzato per le transcodifiche) servizi di ricerca sui metadati descrittivi e tecnici creazione di thumbnail a partire dai video sia manuale che automatica (basata su regole personalizzabili) delivery in download e in streaming multiformato e multiprotocollo (basate su ticketing), sia con URI dirette agli streaming server che fornendo codice di embedding personalizzabile (ad esempio HTML5 con fallback Adobe Flash Media) gestione delle applicazioni client e delle relative autorizzazioni controllo granulare delle autorizzazioni sui contenuti rispetto agli utenti I servizi esposti dalla piattaforma possono essere utilizzati da applicazioni esterne (dette Mediamosa Client Application) che possono quindi demandare centralmente le funzioni di backend sui contenuti multimediali. La figura sottostante propone uno scenario di integrazione rispetto ai servizi Cineca. Mediamosa e servizi Cineca Oltre ad essere già integrata con il Servizio e-learning L2L di Cineca, le funzionalità di Mediamosa sono sfruttate anche nel Servizio Digital Library. 53

I contenuti digitali di tipo audiovideo acquisiti tramite il processo di ingestion vengono inviati a Mediamosa specificando un profilo di transcodifica opportuno e mantenendo un legame con la risorsa digitale a cui afferiscono nel repository Digital Library. Integrazione Servizio Digital Library e Mediamosa Il modello MediaMosa si basa sui concetti di asset e mediafile: un asset è composto da una serie di mediafile (il file originale e tutte le versioni transcodificate). In questo modo un asset può essere fruito usando una serie di protocolli e formati diversi dalle client application, nel caso specifico rappresentato nella figura precedente, da un portale digital library. Funzionalità del Servizio Mediamosa Si riportano di seguito le funzionalità offerte dal Servizio Mediaosa. Servizi CRUD - Create, Read, Update, Delete Questi servizi consentono di inserire e gestire gli oggetti all interno di MediaMosa; tramite queste funzioni è possibile associare i metadati descrittivi ad asset e mediafile e caricare i file dei media. MediaMosa supporta una selezione del Qualified Dublin Core QDC. E inoltre possibile definire le collection e associare gli asset alle collection. Servizi di Ricerca I servizi di ricerca consentono di ricercare oggetti all interno della piattaforma filtrando i dati sulla base dei metadati, collezioni e definendo stringhe di ricerca complessa. Servizio di Analisi Questo servizio estrae i metadati tecnici dai mediafile quali formato, risoluzione, bit rate ed è basato su FFMPEG. Servizio di Still Questo servizio estrae un fotogramma dai file video e lo converte in immagine. Servizi di Transcodifica Il servizio di transcodifica esegue il processo di conversione di un mediafile. Il servizio di transcodifica nativo della piattaforma è basato sullo strumento FFMPEG per i contenuti audio/video. Il servizio consente di configurare diversi profili di transcodifica che definiscono differenti parametri per la conversione del mediafile (di formato, di bit rate o di risoluzione). Per il servizio L2L, per esempio, si utilizzano i profili di transcodifica per la conversione in MP4 e per l estrazione della traccia audio MP3 per il podcast. E inoltre estensibile in quanto consente di aggiungere strumenti di conversione che si possono applicare a diverse tipologie di contenuti. I servizi di transcodifica sono stati estesi da Cineca sviluppando i seguenti moduli: 54

o Mosaico: consente di miscelare due flussi audio/video (librerie GStreamer) in un singolo video per la fruizione da dispositivi mobili o ConceptMapper: consente di analizzare semanticamente i testi delle slide e i testi della trascrizione del parlato estraendo i concetti e producendo un indice concettuale. Lo strumento che effettua l analisi concettuale dei testi è il servizio basato sul software open source Concept Mapper sviluppato da Cineca o Trascrizione (in fase di sviluppo): utilizza un servizio cloud per ricavare il testo dalla traccia audio di un contenuto audio/video Servizi di delivery I contenuti presenti su Mediamosa possono essere erogati sia in download che grazie agli streaming server integrati. L accesso ai contenuti è regolato mediante un meccanismo dinamico di generazione dei link che vengono prodotti da Mediamosa assieme al codice di embedding. L infrastruttura di streaming Cineca è basata e supporta le tecnologie Window Media Services, Helix Universal Server e Adobe Flash Media Interactive Server. I vantaggi dell integrazione L Ateneo ha la possibilità di ricondurre ad un unico modello e ad un unica piattaforma le filiere interne di produzione di contenuti multimediali, siano esse afferenti ad esempio alla comunicazione di Ateneo (portale, eventi interni/esterni) che alla didattica (videolezioni, contenuti audiovideo prodotti da docenti e studenti) Con il supporto multiformato e multiprotocollo e la possibilità di usare visualizzatori HTML5 è possibile fruire degli stessi contenuti da classi di dispositivi diverse, sia in terini di sistema operativo che di modelli di fruizione (web vs. mobile) 55

Servizio di registrazione di persistent identifier (DOI) I contenuti presenti in DL sono identificato da un PID locale che ne garantisce l unicità a livello di repository della DL. Le risorse intellettuali (IP) potrebbero essere meglio identificate attraverso l utilizzo di un Global Identifier fornito di un robusto meccanismo di risoluzione che ne garantisca appunto la persistenza. Fra i vari Global Identifier esistenti il DOI è senza dubbio quello maggiormente affermato a livello internazionale e costituisce lo standard più adottato nel mondo dei contenuti editoriali. Fra i vantaggi che possono derivare dall utilizzo del DOI per le risorse della library elenchiamo qui di seguito i principali: identificare in modo univoco la risorsa anche all esterno della DL; garantirne la persistenza, cioè la risorsa sarà sempre accessibile all utente finale se referenziata con il DOI; aumentare la visibilità della risorsa all esterno; garantire ed estendere la citabilità anche ai DataSet; i DOI possono essere abilitati per essere utilizzati in applicazioni di tipo Linked Data. se la risorsa ha un ISBN, questo può essere cliccabile in Internet. Cioè grazie all integrazione con il sistema di risoluzione del DOI, l ISBN oltre che ad essere un PID che identifica univocamente la risorsa ha anche un meccanismo di risoluzione che rende la risorsa accessiible via web. Il paragrafo che segue ha lo scopo di approfondire e dettagliare meglio le caratteristiche e i servizi legati al DOI. Informazioni di contesto In ambito editoriale, da tempo esiste un sistema internazionalmente condiviso per gestire riferimenti e citazioni di risorse correlate a pubblicazioni scientifiche. Tale sistema si basa sull utilizzo del DOI (Digital Object Identifier - www.doi.org). Ad oggi oltre 60 milioni di DOI sono stati assegnati ad articoli di riviste e, in misura crescente, a set di dati scientifici. Il DOI (Digital Object Identifier) è lo standard di identificazione e risoluzione in rete di contenuti digitali di diverso genere. È in particolare utilizzato per gestire il cross-linking tra articoli di riviste scientifiche online. Tutta la migliore produzione scientifica commerciale e non utilizza questo strumento per garantire la persistenza dei link delle referenze bibliografiche. medra (multilingual European DOI Registration Agency: www.medra.org) è l agenzia di registrazione DOI creata in joint venture tra AIE - Associazione Italiana Editori e Cineca. Opera nell Europa continentale ed è attualmente la seconda agenzia al mondo per numero di prefissi DOI allocati (dopo Crossref: www.crossref.org). Fornisce inoltre la tecnologia di gestione delle agenzie DOI di Nielsen Book Services e dell Ufficio delle pubblicazioni della Commissione Europea (OPOCE). Persistenza delle citazioni Il sistema di risoluzione utilizzato dal DOI (Handle System) consente di costruire link persistenti a alle risorse identificate. La persistenza dei link è dovuta al fatto che il DOI identifica la risorsa e non 57

la sua localizzazione (URL). In caso di spostamento della URL, è sufficiente aggiornare la relativa informazione nella banca dati DOI per garantire la persistenza dei link costruiti in passato anche da soggetti terzi (cd tecnologia n2l = urn to url ). Utilizzato quale strumento di citazione dei contenuti scientifici, il DOI assicura la persistenza dei riferimenti ogni qualvolta questi siano referenziati dalla comunità scientifica in pubblicazioni a stampa o digitali o all interno di altre risorse online. Metadata Interoperability Il sistema di gestione dei metadati associati al DOI consente di garantire livelli elevati di interoperabilità con i sistemi esistenti (standard o proprietari). Anche in questo caso l approccio del DOI è integrativo e non sostitutivo dei modelli già in essere. Infatti, al DOI possono essere associati schemi di metadati specifici a seconda del contesto di applicazione (DOI Application Profile). Nel caso in esame, è possibile utilizzare lo standard ONIX (per questo si veda le informazioni presenti sul sito: https://www.medra.org/it/metadata_td.htm Servizi basati sul DOI Servizio di Cross Linking (CL) e Forward Linking (FL) Il servizio di CL consiste nel creare una relazione fra un contenuto (articolo scientifico ad esempio) sui cui è stato registrato un DOI e la lista di reference presenti nello stesso. Nel caso in cui le singole reference abbiano già un DOI, questo viene fornito al registrante in modo da essere citato nelle reference in modo permanente. Il servizio di FL consiste nella possibilità per un editore di risalire, dato un oggetto su cui è stato registrato il DOI, alla lista di oggetti che hanno citato quel dato oggetto. Entrambi i servizi sono forniti al momento da medra, grazie alla collaborazione con CrossRef, che è un altra agenzia di registrazione DOI. Il Forward linking è un servizio che consente di scoprire come le pubblicazioni di un editore sono citate e di incorporare quella informazione direttamente nella piattaforma che gestisce le pubblicazioni online. Maggiore visibilità: Aderendo al servizio di Cross Linking e Forward Linking attraverso medra l editore ha quindi modo di inserire le informazioni sulle proprie pubblicazioni un repository di circa 46 milioni di contenuti. E a questo repository poi che la maggior parte degli editori scientifici internazionali fa riferimento per cercare le citazioni di interesse e per referenziarle nel proprio sito. Inoltre tale repository è accessibile a più di 1300 biblioteche internazionali. Esempio di CL: http://www.iop.org/ej/abstract/1367-2630/1/1/006/ Esempio di FL: http://www.bioone.org/perlserv/?request=get-abstract&doi=10.1653%2f0015-4040(2002)085%5b0001%3amasitp%5d2.0.co%3b2&ct=1 Multiple Resolution (MR) Il nuovo servizio di Multiple Resolution consente di associare a un singolo DOI più risorse o servizi relativi al contenuto identificato (più url). Con il servizio di Multiple Resolution l editore ha la possibilità di scegliere, per ogni sua pubblicazione identificata da un DOI, quali informazioni rendere accessibili per l'utente finale, aggregarle secondo aree tematiche omogenee e renderle disponibili da un unico punto di accesso. 58

Pop up che si visualizza al momento della risoluzione di un DOI registrato in MR in medra Esempi di MR: http://www.medra.org/it/mr_demo.htm La citazione di un DOI viene fatta sempre secondo le stesse regole definite per la risoluzione singola, ma al momento della risoluzione una interfaccia guida l'utente tra le diverse opzioni di risoluzione definite dal registrante per il proprio contenuto. Tale strumento consente di aumentare in modo molto significativo la visibilità e reperibilità in rete delle risorse relative ai CT, migliorando i servizi agli utenti. ISBN clickable Il servizio consiste nell integrare il codice ISBN all interno della sintassi DOI, rendendolo così azionabile in rete, grazie alla combinazione con il sistema di risoluzione. In altre parole, a partire da un ISBN è possibile creare anche attraverso procedure automatiche un link persistente riferito alla risorsa identificata. Esempio di ISBN cliccabile con MR: http://dx.doi.org/10.978.388414/2721 DOI sui dataset (Datacite) L utilizzo del DOI può essere utile per citare i dataset esattamente nello stesso modo in cui si possono citare altre sorgenti di informazione, come articoli o libri. La citazione dei Dati può essere utile per: consentire il facile riuso e la verifica dei dati per tracciare l impatto dei dati per creare una struttura che riconosca e premi i data producers Per approfondimenti si veda: http://www.datacite.org/ esempio di DOI di un dataset: http://dx.doi.org/10.1594/pangaea.726855 59

Come attivare i DOI per Digital Library Per consentire la registrazione di DOI su contenuti digitalizzati e presenti in DL, medra mette a disposizione 2 web service per la gestione dei DOI in ottica b2b: - medra WS consente di: depositare DOI e DOICitations in medra; interrogare la banca dati medra; - medra2cr WS consente di: depositare DOI e DOICitations in medra e in Crossref; interrogare la banca dati Crossref (cross-linking e cited-by query). Poiché i record DOI possono essere depositati in medra solamente se sono conformi al formato ONIX for DOI 2.0, in DL occorrerebbe effettuare una trasformazione dei record MODS presenti nella Digital Library in ONIX 2.0 e mandare tramite client WS le richieste al WS di medra. Il servizio di medra restituisce in modalità asincorna ad un servizio remoto della DL (servizio di Callback in HTTP) l esito della registrazione. 60

Servizio di streaming Descrizione Lo streaming è uno dei metodi più usati per il trasporto di audio e video su internet. Permette la fruizione del filmato in tempo reale, di pari passo con lo scaricamento continuo di frammenti di brano che non vengono salvati sul disco e consente di accedere a qualsiasi punto del brano attendendo al più qualche secondo. Lo streaming è particolarmente adatto per la trasmissione in diretta di eventi live o per la fruizione di contenuti multimediali molto lunghi, (diverse ore), codificati in precedenza (video on demand). Come si evince dalla figura si tratta un attività complessa divisa in fasi fra loro strettamente dipendenti che necessitano di diverse competenze: ripresa video, networking, multimedialità. CINECA è in grado di gestire la completa filiera produttiva oppure di prenderne in carico una parte integrandosi con i servizi di terze parti forniti dal cliente. In questo caso tralasciamo la parte di ripresa video e ci occupiamo direttamente del sistema di pubblicazione di flussi multimediali basato sulla redistribuzione di contenuti audio/video prodotti da un encoder da un punto della rete internet privilegiato. Nel seguito verranno illustrate le caratteristiche tecniche di dettaglio del servizio e dell infrastruttura che ospita il nodo di pubblicazione dei contenuti multimediali. Il servizio si avvale di server Windows Media, Helix Universal Server e Adobe Flash Media Server basati su un infrastruttura condivisa scalabile e ridondata; l erogazione del servizio avviene tramite collegamenti di rete ridondati per il servizio rivolto alle università e ai privati. I server di streaming sono ospitati nel datacenter CINECA in locali dotati di impianto di condizionamento, doppio circuito di alimentazione, gruppo di continuità e generatore elettrico. 61

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 H24. Per garantire la continuità del servizio viene implementato il monitoraggio automatico della connettività Internet e dei principali servizi applicativi con disponibilità del sistemista e intervento garantito da presidio on-site durante il normale orario d ufficio (8-19 dei gg. lavorativi dal lunedì al venerdì). E' garantito l intervento entro 4 ore lavorative dalla chiamata nel caso di malfunzionamenti che compromettano le funzionalità del sistema. CINECA fornisce supporto di secondo livello per la risoluzione dei problemi sull utilizzo della piattaforma mediante l impiego della coda del sistema di trouble ticketing (TTS) streamingsupp@cineca.it; l utilizzo dei servizi in produzione non prevede un contatto diretto dell utenza finale del cliente con il personale del CINECA. Il servizio di streaming live Con il servizio di streaming live è possibile erogare in rete contenuti multimediali audio/video in diretta. Il servizio è disponibile per i seguenti server: Windows Media Server; Helix Universal Server; Adobe Flash Media Server. Il server ospiterà un punto di pubblicazione del cliente per tutta la durata contrattuale ma al fine di garantire la qualità del servizio sarà disponibile soltanto su preavviso di almeno 24H dall evento da pubblicare. Il servizio di streaming on-demand Viene impiegato per la diffusione di contenuti audio e video precedentemente registrati e codificati. Il servizio è disponibile per i seguenti server: Windows Media Server; Helix Universal Server; Adobe Flash Media Server Il servizio si basa su un infrastruttura condivisa. Per ogni tipologia di server viene fornito un accesso per il caricamento di nuovi file audio/video in un area dedicata. 62

Pubblicazione: presentazione dei contenuti La fruizione di un contenuto audiovisivo in rete avviene nella sua forma più semplice tramite un player specifico per la codifica scelta o uno universale. E pratica comune arricchire l esperienza inserendo il player all interno di un sito web che correda l evento offrendo la presentazione, la pagina di aiuto, il programma, la scansione in giornate per eventi lunghi, le eventuali slide dei relatori e ogni altra informazione utile. CINECA offre il servizio di creazione e hosting delle pagine web sia con template standard sia con grafica personalizzata. E possibile l integrazione con il sito web del cliente dal caso più semplice della fornitura dei soli puntatori ai filmati fino alla consulenza sul codice XHTML specifico per il player scelto. Embedding dei filmati Lancio di un player esterno Eventuali meta-file per ridirezioni Slide scaricabili in multiformato (PDF, PowerPoint, PNG, JPEG, GIF) Riconoscimento delle impostazioni dell utente Integrazione con Forum/Chat Il servizio di statistiche fornisce reportistica accessibile web elaborata giornalmente raccogliendo e analizzando i file di log degli accessi ai contenuti audio/video. Servizio di Content Delivery Network (opzionale a richiesta) Per eventi che prevedono grossi volumi di utenti dislocati su reti topologicamente lontane dalle reti CINECA è possibile avvalersi dei servizi di Content Delivey Network di Akamai, il maggior fornitore di servizi di CDN a livello mondiale. CINECA è reseller dei servizi Akamai per l Italia. Il servizio di Content Delivery Network Akamai utilizza un infrastruttura su scala mondiale di oltre 14000 server dislocati presso 1100 ISP in 65 paesi, uno dei quali è presente direttamente nella sede Cineca di Roma. 63

Servizio di trascrizione OCR Il Digital Library Management System fornisce un servizio di trascrizione automatica delle immagini in testo. La funzionalità è resa disponibile dalla Digital Library API ed è quindi sfruttata sia internamente (ad esempio a seguito della fase di ingestion di un libro digitalizzato), sia esposta come micro-servizio sfruttabile in modo diretto (ad esempio uno specifico progetto). Integrazione e sfruttamento del servizio OCR flusso di ingestion e uso diretto Il software OCR utilizzato 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. Trascrizione OCR e formati di uscita Il testo contenuto nelle immagini da trascrivere (ad esempio file TIFF o JPG) può essere salvato in un file di testo, in un file XML con il layout della pagina, dove vengono identificati i paragrafie e per 65

ogni riga vengono salvate le coordinate dell area che la contiene, oppure in formato PDF, dove all immagine viene sovrapposto il testo trasparente (e quindi selezionabile) che è stato trascritto. I vantaggi dell integrazione L ateneo può sfruttare il servizio OCR sia durante l ingestion di risorse digitali sia in odo diretto mettendo quindi a disposizione di gruppi o progetti specifici (ad esempio di dematerializzazione) un servizio facilmente integrabile. Con la trascrizione del testo e la successiva indicizzazione l utente ha la possibilità di raggiungere le risorse attraverso una ricerca full-text (vedi figura sottostante). Il testo ottenuto con OCR è una base essenzaile per ulteriori analisi semantiche che permettono di identificare concetti all interno dei testi. Digital Library BookReader ricerca full-text tramite trascrizione XML 66

MODULI DI INTEGRAZIONE 67

Integrazione con la piattaforma Learning Management System Moodle Moodle 6 è 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). Questa integrazione 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). La figure sottostanti riportano sia il momento della ricerca e selezione di una risorsa Digital Library sia la visualizzazione della stessa all interno di Moodle. Integrazione Moodle - ricerca selezione di una risorsa 6 Moodle, http://moodle.org 69

Integrazione Moodle - visualizzazione in Moodle di una risorsa Digital Library I vantaggi dell integrazione 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. 70

Integrazione con U-GOV Ricerca (OAI-PMH 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 espoti 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. Integrazione U-GOV Ricerca - OAI Harvesting I vantaggi dell integrazione 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. 71

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

Integrazione con EBSCO Discovery Service Il sistema EBSCO Discovery Service (EDS) permette di raccogliere e rendere accessibili in un unico punto i metadati relativi sia alle pubblicazioni scientifiche 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. Esempio di ricerca integrata con risultati provenienti da EBSCO EDS (box "ALTRI RISULTATI ) I vantaggi dell integrazione L Ateneo riusa e valorizza un servizio acquisito aumentando la visibilità delle risorse presenti negli archivi, nelle biblioteche e derivanti da abbonamenti a riviste. Le community dell Ateneo hanno la possibilità di espandere le ricerche effettuate nella Digital Library verso il catalogo OPAC e le altre fonti presenti in EDS. 73

Integrazione con il CMS Drupal L accesso ai contenuti della Digital Library archiviati nel repository, inteso come consultazione, ricerca e visualizzazione alle risorse digitali, ma anche monitoraggio del servizio stesso, possono avvenire tramite l integrazione dei Servizi Digital Library con un portale realizzato con il CMS open source Drupal 7. Drupal è un CMS open source molto diffuso dall architettura modulare, flessibile e scalabile che viene usato da numerose realtà isituzionali, accademiche oltre che da privati. I portali universitari, sia pubblici che di servizi, realizzati da CINECA sono costruiti 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: 1 Digital Library CINECA 2 SOLR for Digital Library CINECA 3 DL auth 4 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. I vantaggi dell integrazione Possibilità di esporre i contenuti della Digital Library attraverso componenti standard di Drupal. Il costruttore di Portali usa i consueti strumenti per assemblare e personalizzare un Portale che ospiti parzialmente o totalmente la Digital Library Realizzazione di browsing selettivi su alcune porzioni di collezioni, ad esempio all interno di un percorso tematico in un Portale generalista. Modello di integrazione "on the fly" I dati sono letti "al volo" dal repository e renderizzati in formato xhtml per il browser. Non esiste uno strato di archiviazione in Drupal delle risorse digitali (tranne un sistema di cache descritto in seguito). Questo significa che le risorse non diventano nodi di Drupal. L'accesso al repository non è diretto, ma avviene dialogando con lo strato intermedio denominato Service Delivery Platform (SDP) che espone una serie di servizi REST. Tramite questi servizi il modulo DL CINECA può conoscere la struttura dei contenuti ed effettuare il rendering componendo il layout del sito Drupal (che è governato dal tema) con la i contenuti delle risorse digitali. Ogni risorsa digitale ha una scheda di dettaglio in cui vengono mostrati i metadati secondo due livelli di approfondimento: summary e metatdati estesi. Sono inoltre presenti i collegamenti che consentono di fruire del contenuto digitale binario vero e proprio: video, immagini, documenti. 7 http://drupal.org 75

I tipi di asset Durante lo sviluppo del modulo sono stati indicati un certo numero di TIPI di contenuti distinti che hanno possibilità di essere renderizzati in modo differente. i tipi attualmente supportati dal modulo DL CINECA sono: Aggregation Book Collection Document GenericDocument Image Map OrganizationalCollection ResearchProduct Video Modulo Digital Library CINECA e SOLR for Digital Library CINECA Il primo modulo implementa la connessione con il repository Digital Library e pernette l accesso alle collezioni e alle risorse nonché l integrazione con il servizio esterno EBSCO, descritto più avanti. Il secondo modulo abilita le funzioni legate al motore di ricerca SOLR, sia quella di ricerca diretta di risorse che di browsing delle collezioni. I due parametri indispensabili da impostare nelle rispettive schermate di configurazione sono l indirizzo dell interfaccia REST del repository nello strato SDP nel modulo DL CINECA e l indirizzo delle richieste per il motore SOLR nel modulo SOLR for DL CINECA. Una volta abilitati i due moduli verranno esposte nuove funzionalità sotto forma di pagine e blocchi. Pagine Il modulo DL CINECA mette a disposizione una pagina per ogni risorsa che risponde ad un url specifico. L'url è composto come nell'esempio: http://www.miosito.it/dl_cineca/detail/pid_risorsa Esiste una alias semplificato dell'url che risponde all'indirizzo: http://www.miosito.it/identifier/pid_risorsa L'impaginazione e l'estetica della pagina dipendono dal tema in uso per il sito secondo la logica dei contenuti, blocchi e temi di Drupal. 76

In questo esempio si noti il posizionamento tramite blocchi dei menu, del box di ricerca e delle risorse simili (che sono blocchi esposti dal modulo DL CINECA SOLR). Collezione In questa pagina viene mostrata la scheda di una collezione. Sono presenti gli elementi: Ttitolo Thumbnail Link di sharing sui social network Medatati principali (sempre visibili) Nomi (in un pannello a comparsa) Casella di ricerca nella collezione Elenco delle risorse digitali sottoforma di box: schede brevi con Titolo/thumbnail/autore/link di visualizzazione Risorsa In questa pagina viene mostrata la scheda di una risorsa digitale. Sono presenti gli elementi: Ttitolo Thumbnail (diverse per tipo di risorsa) Link di sharing sui social network Medatati principali (sempre visibili) Metadati estesi (in un pannello a comparsa) Bottone di download del file METS XML Bottone di download del file BibTex 77

Visualizzatori Cliccando sulla thumbnail della scheda della risorsa vengono aperti diversi tipi di visualizzatore corrispondenti ai diversi tipi di risorsa. Il servizio di visualizzazione e le sue caratteristiche sono codificate nel repository all interno del modello con cui l oggetto digitale viene rappresentato. Libri: per i libri scannerizzati composti da sequenze di immagini e trascrizioni OCR viene aperto il lettore di libri open source IA Bookreader 8. Il lettore 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 testo trovato viene evidenziato nella pagina scannerizzata. E anche 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 PDF: i file pdf vengono demandati alle impostazioni del browser dell utente Video: i video vengono visualizzati da un player standard html5 e flash Audio: Mappe: le mappe vengono visualizzate all interno della lightbox tramite il visualizzatore open source djatoka. é 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 cachate ed erogate dall imageserver. Esempio di visualizzazione di un libro. 8 http://openlibrary.org/dev/docs/bookreader 78

Esempio di visualizzazione di una mappa. Risultati della ricerca E la pagina generata dal modulo di ricerca SOLR for Digital Library CINECA quando l utente effettua una ricerca dal form compatto, da quello di ricerca avanzata o mediante clic su una faccetta (vedi più sotto). La pagina presenta una sequenza di risultati di lunghezza configurabile. Ognuno di essi è un box sintetico con titolo, thumbnail, descrizione e informazioni di contesto (il testo che racchiude la stringa cercata). Sono presenti due tipi di link: un link di approfondimento, su titolo e miniatura che apre la scheda della risorsa o della collezione corrispondente e un link visualizza che apre la lightbox sovrapposta alla pagina di ricerca per la visualizzazione diretta della risorsa. I risultati della ricerca possono essere filtrati e manipolati con i blocchi accessori descritti più sotto. 79

Blocchi Blocco Digital Library Questo blocco mostra un elemento, sia esso Risorsa o Collezione a partire dal relativo PID. Se è istallato il modulo SOLR il modulo mostra una serie di elementi corrispondenti ad un risultato di ricerca. In entrambi i casi la risorsa o l elenco di risorse può essere renderizzato in tre modalità differenti: Mini In questo tipo di visualizzazione viene mostrato per ogni risorsa il suo titolo e nel caso di una collezione viene indicato il numero di risorse che contiene. Il titolo è un collegamento che punta alla pagina di dettagli della risorsa stessa. Teaser la visualizzazione in modalità teaser attualmente prevede il titolo della risorsa, una miniatura, e il nome dell'autore principale della risorsa. Il titolo e la miniatura sono dei collegamenti alla pagina di dettaglio. 80

Full nella visualizzazione full sono mostrati tutti i metadati della risorsa (suddivisi in 2 insiemi: sommario e metadati estesi) e per ogni componente binario della risorsa è mostrata una miniatura e i relativi collegamenti per la visualizzazione nel browser e/o il download se previsto. Questo tipo di vista coincide con quella usata per il rendering della pagina di dettaglio di una risorsa (in questo caso il blocco deve essere posizionato nel contenuto principale della pagina). DL Collections/All Collections/Org Collections/DL Aggregations In questa famiglia di blocchi, versione specializzata del Blocco Digital Library, viene mostrato l elenco di tutte le collezioni presenti nel respository o di un loro sottoinsieme. Le collezioni sono infatti suddivisibili in 4 categorie. Il modulo DL CINECA espone un blocco per ciascuna di queste categorie: Collezioni di risorse digitali 81

Collezioni Organizzative Tutte le collezioni (a prescindere dal tipo) Aggregations Gli elementi vengono mostrati nelle tre modalità mini, teaser o full. Questi blocchi possono essere posizionati sempre visibili nella colonna di navigazione laterale per consentire un browsing rapido da una collezione ad un altra mentre si visualizzano le pagine delle collezioni stesse e delle risorse nel corpo centrale della pagina. Esempio di utilizzo del blocco "DL All Collections": DL Similar items E il blocco che racchiude l elenco delle risorse simili alla risorsa correntemente visualizzata nel corpo della pagina. Vengono mostrati dei box con titolo e thumbnail identici a quelli dell elenco risorse disponibili all interno della pagina di una collezione. DL Collection Slider E un blocco che mostra un carosello di miniature di tutte le collezioni presente che scorre automaticamente o con il click sulle frecce laterali. Ad ogni step di scorrimento cambia titolo e descrizione della collezione al centro dello slider. Cliccando sulla miniatura si va alla pagina della relativa Collezione. E un blocco adatto alla home page, pensato per un browsing rapido e per catturare l attenzione dell utente. 82

DL Collection Browser E il blocco più importante che può prendere da solo l intera pagina in cui è collocato, solitamente nella regione che ospita il contenuto principale. Nel DL Collection Browser vengono mostrate le schede brevi di tutte le collezioni del repository in una tabella a due colonne. Le schede contengono ciascuna, titolo, thumbnail, descrizione e alcuni dettagli della collezione. Sotto il titolo del blocco è disponibile una barra con cui l utente può filtrare le collezioni in tempo reale tramite tre classi di faccette predeterminate: per nome, per istituzione, per temi. Ognuna di esse apre, se cliccata, una pannello a scomparsa con l elenco delle faccette corrispondenti. Un clic su queste ultime filtrerà le collezioni nella pagina. DL Tagcloud La faccetta dei temi delle collezioni (il campo di indicizzazione "descmetadata.keyword" di SOLR) viene mostrata come sequenza cliccabile di temi formattata secondo lo standard del tagcloud: la 83

grandezza del font di un termine è proporzionale alla frequenza relativa di quel termine nel tagging delle collezioni. I tag sono collegamenti che portano alla pagina dei risultati della ricerca dove è stato applicato il filtro in base al tag cliccato. SOLR compact search form E il box di ricerca che solitamente si posiziona nella testata del sito o, con una piccola modifica, in home page in versione più grande. Il blocco mostra la tipica casella di ricerca con una tendina che permette di restringerla su un determinato tipo di risorsa digitale (testi, immagine, video, etc.). Un radio button consente di commutare l ambito di ricerca fra il repository della Digital Library o le sole pagine del Portale Drupal. SOLR advanced search form Questo blocco è composto da una serie di box in cui sono esplicitati tutti i filtri disponibili per la ricerca avanzata. Prende l intera pagina in cui è posizionato. I filtri implementati, sono: - tre livelli di criteri di ricerca sovrapponibili (parola chiave/nome/soggetto/full text) con operatori diversi (Inizia con/frase esatta/tutte le parole/qualsiasi parola) e operatori booleani - tipo di risorsa digitale - collezione di appartenenza - data - accesso pubblico/ristretto I risultati della ricerca vengono prodotti dalla stessa pagina della ricerca semplice e quindi possono essere ulteriormente raffinati utilizzando le faccette e la ricerca full text nei risultati. 84

Naviga E un blocco creato appositamente per l home page che elenca i tipi di oggetti digitali disponibili. Cliccando su uno di essi si scatena una ricerca SOLR che mostra tutte le risorse digitali appartenenti a quella tipologia. Blocchi relativi alla pagina dei risultati di ricerca SOLR Sono blocchi per filtrare la pagina dei risultati di ricerca, solitamente posizionati nella colonna a fianco dei risultati SOLR cerca nei risultati Box di ricerca full text all interno dei risultati visualizzati SOLR current search widget Blocco che elenca i criteri di ricerca attualmente selezionati. Ogni criterio è può essere disabilitato cliccando sulla x corrispondente. SOLR faceting widget E il blocco per il raffinamento della ricerca mediante clic sulle faccette. E diviso in tante sezioni quante sono le faccette impostate nella configurazione. Ogni sezione viene popolata con le faccette trovate. Un link su una di esse restringe i risultati per quella faccetta e popola il blocco SOLR current search widget. 85

SOLR create aggregations (alpha) Questo blocco consente la creazione di nuove aggregazioni. Verrà mostrato nella pagina dei risultati della ricerca un carrello virtuale. 86

Per aggiungere risorse al carrello si potrà usare il collegamento "(+) Aggiungi al Carrello aggregation" che comparirà in ogni item nei risultati (compare solo se nella pagina è presente il blocco del carrello). Quando la lista è completa e lo si ritiene opportuno si può procedere con la creazione dell' Aggregation tramite il collegamento in calce al carrello. Si verrà rediretti ad una pagina riassuntiva nella quale è necessario scecificare un PID identificativo della nuova risorsa da creare, un titolo, l'elenco dei PID delle risorse scelte (precompilato dal sistema) e lo schema di riferimento (al momento è disponibile solo MODS). 87

SOLR save filter as Block (alpha) Questo blocco mostra un collegamento nella pagina delle ricerche che consente il salvataggio della ricerca corrente. Verrà creato un nuovo blocco con la query a SOLR che riporta la ricerca e i filtri correnti. Questo consente ad esempio di creare un box con l'elenco di tutte le risorse che parlano di un certo argomento. La ricerca viene effettuata ad ogni rendering del nuovo blocco. EBSCO box Il modulo espone anche un blocco per la connessione automatica al motore di ricerca EBSCO. Il box contenuto nel blocco viene rendirazzo ad ogni invocazione del motore di ricerca. LA stringa cercata viene inviata un servizio REST esterno e viene mostrato il numero dei risultati "attesi" sul motore esterno. Viene composto un collegamento che porterà alla pagina dei risultati sul motore EBSCO. EBSCO prevede un servizio ad accesso ristrestto per tutti le richieste provenienti da un determiato range di IP. E' possibile configurare il range di IP e le diverse etichette utilizzate nel box nella pagina di configurazione "Digital Library API Settings". 88

Gli utenti e gli accessi Modulo Digital Library CINECA Basandosi sul sistema degli accessi di Drupal il modulo DL CINECA consente la verifica degli accessi alle risorse. In particolare il client REST che fa accesso ai servizi esposti da SDP è in grado di utilizzare i dati relativi all'utente attualmente loggato nel sistema e di inviarli al servizio remoto che basandosi sulle ACL presenti nel repository, risponderà opportunamente alla richiesta. In questo modo il modulo DL CINECA è in grado di prevenire accessi a risorse non autorizzati. Esistono una serie di metodi e funzionalità che sono stati ritenuti per loro natura "pubblici" e quindi non richiedono l'autenticazione dell'utente. Modulo SOLR for Digital Library CINECA Anche i risultati delle ricerche effettuate tramite SOLR sono filtrati in base ai diritti di accesso che ha l'utente correntemente loggato (o l'utente anonimo per i contenuti pubblici). Per ottenere questo risultato è stato implementato un filtro sulle query per SOLR. Tutti i componenti del modulo non chiamano direttamente l'api REST esposta da SDP, ma un filtro (una sorta di proxy lato Drupal). Il filtro aggiunge a tutte le query una parte di query string (composta in base ai ruoli che ha l'utente e al suo indirizzo IP) che permette a SOLR di filtrare i contenuti non visibili all'utente. Il filtro aggiunge anche una porzione di query string che controlla lo scoring dei risultati. In questo modo è possibile regolare l'importanza dei risultati in base alle politiche di matching più opportune. Gestione degli accessi La gestione degli accessi su collezioni e risorse è demandata al modulo DL Auth descritto più sotto. Il client REST Il client REST è un componente del modulo DL CINECA che implementa la comunicazione via http REST col Service Delivery Platform ed espone una serie di metodi omogenei per il recupero dei dati relativi alle risorse e alle collezioni. La cache Il client REST utilizza le api per la gestione della cache di Drupal. Se il modulo è configurato per utilizzare la cache, verranno messi sul DB i dati di tutte le richieste fatte attravero il client REST. La durata della persistenza dei dati in cache è controllata da un secondo parametro presente nella configurazione del modulo. Modulo DL Auth Questo modulo richiede la presenza dei moduli Drupal Views e Chaos Tools. La sua funzione è quella di implementare una vista sulle risorse del repository tramite la quale impostare le diverse Capabilities con le quali funziona il meccanismo di accesso e autorizzazione. Una volta abilitato il modulo viene resa disponibile la vista http://<indirizzo del portale>/auth che elenca tutte le regole di restrizione agli accessi attualmente presenti. 89

La prima riga in alto permette di filtrare i record della tabella nel caso di molte entry. In particolare è possibile aggregare insiemi di risorse dello stesso tipo o dello stesso ruolo. Cliccando sul link modifica è possibile alterare i flag di ciascuna della quattro capabilities Il link aggiungi nuova regola apre una scheda vuota con cui assegnare le capabilities ad una risorsa, conoscendone il suo PID. 90

Nel caso si asssegnino delle capabilities all interno di una collezione, il filtro per tipo permette di restringere l assegnazione alle sole risorse di quel determinato tipo. Modulo Ingestion Logs Digital Library CINECA Questo modulo serve a monitorare lo stato dei processi di ingestion. Oltre alla normale istallazione è necessario impostare nel file drupal settings.php i parametri del db dei log in cui il processo di ingestion scrive tabelle da monitorare. Il modulo espone dei dati mediante le viste (views) di Drupal. Occorre quindi installare il modulo di terze parti views. Si possono creare perciò una o più viste che utilizzano i dati esposti dal modulo: DL ingestion logs Master Table DL ingestion logs Detail Table DL ingestion logs Scheduler Table Esempi di viste Master Esempio di vista con filtri esposti utilizzando il contenuto "DL ingestion logs Master Table". Si noti il collegamento nella prima colonna che porta alla vista di dettaglio (Dettail). Il colore di ogni riga è regolato da una classe css aggiuntiva per ogni riga e si basa sul valore della colonna "End Code". 91

Detail Esempio di vista utilizzando il contenuto "DL ingestion logs Master Table". La vista accetta un parametro in input che è l'id della sessione di ingestion. Scheduler Esempio di vista con filtri esposti utilizzando il contenuto "DL ingestion logs Scheduler Table". Il colore di ogni riga è regolato da una classe css aggiuntiva per ogni riga e si basa sul valore della colonna "Exit Code". 92

93

UNA REALIZZAZIONE: IL PORTALE SDL DELLA SAPIENZA Introduzione L'integrazione con il CMS Drupal è stata concepita e sviluppata parallelamente alla progettazione e realizzazione del Portale Sapienza Digital Library. Il Portale fa uso dei principali building blocks esposti in Drupal che abbiamo analizzato in dettaglio nei paragrafi precedenti. Le caratteristiche dei moduli, che sono state pensate per essere di utilizzo generale e per avere elevata flessibilità, devono tuttavia molto allo sviluppo del Portale SDL. Oltre al punto di vista tecnologico-informatico, il Portale Sapienza Digital Library ha comportato un approfondito percorso di progettazione partecipata Sapienza-CINECA per definire l'architettura dell'informazione e il layout delle funzionalità DL sulle pagine web del Portale stesso. Il lavoro sul Portale ha rappresentato inoltre un'importante opera di raccordo fra la comunicazione istituzionale d'ateneo e le esigenze di comunicazione specifiche del Portale SDL. La prospettiva di Sapienza di Giovanni Ragone Il Portale SDL (Sapienza Digital Library) è il risultato di un progetto di ricerca e sviluppo condotto dalla Sapienza (DigiLab, in collaborazione con Sistema Bibliotecario della Sapienza e con InfoSapienza), in partnership con il Cineca (2010-2013). La release 1.0 è oggi disponibile per essere trasformata in servizio operativo dell'ateneo. Il portale è l infrastruttura digitale per la comunicazione dei patrimoni culturali, scientifici e ambientali appartenenti alla Sapienza e a enti collegati o a donatori, in un contesto europeo e internazionale. Una infrastruttura che si estenderà o almeno questa è l intenzione a numerose altre università e enti. Si tratta di un salto tecnologico, culturale e organizzativo strategico nel sistema università-ricerca italiano: per la valorizzazione delle attività di ricerca nel campo dei patrimoni culturali e scientifici, per il potenziamento e la valorizzazione delle stesse attività core delle università e dei centri di ricerca; per l integrazione nell infrastruttura europea di Digital Library (Europeana Project), come in quella italiana; per la crescita dell interazione tra la rete di ricerca pubblica e le attività di interesse pubblico ed economico di valorizzazione dei patrimoni culturali, scientifici e ambientali nel territorio; In Sapienza e a ridosso di Sapienza sono presenti o realizzabili numerosi e significativi archivi e collezioni digitali relative al patrimonio culturale, scientifico e ambientale. Esse includono libri, periodici, spartiti musicali, materiale multimediale come film, filmati audio e video, registrazioni audio, fotografie, ricostruzioni 3D di luoghi, edifici e territori, altre immagini e altre fonti di informazione digitalizzate relativi a opere d arte, monumenti e collezioni d archivio, aree di scavo, musei virtuali e contenuti digitali accessibili attraverso siti web. Si tratta di passare da una forte frammentazione e dispersione a una scala più vasta, che garantisca l'accesso on line all'intero 95

patrimonio digitale disponibile, tramite il recupero delle collezioni esistenti e la creazione continua di nuove collezioni e oggetti, supportando Dipartimenti e biblioteche universitarie (che incontrano problemi analoghi a quelli della maggior parte degli enti locali e dei musei). Il sistema deve inoltre garantire la conservazione a lungo termine del patrimonio che include non solo contenuti immediatamente prodotti e/o posseduti dalle istituzioni di Sapienza e relativi al loro lavoro o al lavoro di altri soggetti sull' heritage ma anche, in prospettiva, quelli relativi alle attività di ricerca e formazione (pubblicazioni, tesi, convegni, videoregistrazioni, ecc.) e gli User Generated Content che nel caso di una grande università sono prevalentemente materiali prodotti nell'ambito delle attività di ricerca, o a scopi divulgativi, o come prodotto diretto delle attività degli studenti. Il portale può innescare una vasta gamma di attività di servizio, di ricerca, di formazione e anche attività economiche, perché: rende realmente accessibili i patrimoni favorendone un recupero capace di valorizzare anche i contenuti specialistici permette all'ateneo di affacciarsi sulla filiera specifica della digitalizzazione, metadatazione e gestione delle collezioni digitali dell università e di suoi partner (analisi e catalogazione, digitalizzazione, restauro, meta datazione, conservazione, gestione dei diritti, accesso in streaming), e anche il possibile e-commerce di oggetti di proprietà dell'ateneo offre servizi per il riuso degli oggetti digitali, per il tagging, la donazione, la soluzione di problemi di diritti legali, la produzione di User Generated Content da parte di ricercatori, studenti e prosumer esterni, e per il publishing si presenta come servizio di integrazione in SDL di archivi, collezioni esterne e soggetti nei territori e in altre università si collega a reti di laboratori sia universitari che privati, attivi nella filiera delle collezioni digitali o in campi limitrofi (visualizzazione e animazione o gamification scientifica 2D e 3D, musei virtuali, ecc.) si collega a servizi di formazione si presenta come un laboratorio/community virtuale in rete per la progettazione, lo sviluppo e l implementazione. Il gruppo di ricerca SDL (coordinatore scientifico: Marco Schaerf) ha visto la partecipazione di numerosi ricercatori, tecnici, bibliotecari). Il Centro Digilab oltre a costituire e coordinare il gruppo di ricerca, in stretta collaborazione con SBS e InfoSapienza, ha attivato nel 2012 strutture di servizio importanti per l'implementazione della SDL. Un accordo formale tra SBS, DigiLab e InfoSapienza permetterà una piena e efficace collaborazione tra le strutture per la gestione a regime del servizio, che sarà coordinato da SBS, anche in sinergia con i Dipartimenti e l'amministrazione Centrale. Le attività di ricerca e sviluppo proseguiranno, utilizzando ogni forma di fund raising, in partnership con Cineca, anche nel prossimo anno, durante il quale ci si propone di allargare il confronto e di avviare possibili collaborazioni anche con altri Atenei. 96

UN ESEMPIO: UN PROGETTO DI MUSEO VIRTUALE Il progetto MuVir Il Digital Library Management System CINECA Introduzione Il tema della valorizzazione di patrimoni storici, artistici e culturali italiani attraverso l utilizzo delle tecnologie che la rete, le moderne soluzioni nell ambito della ICT e le tecniche più avanzate di digitalizzazione sono in grado di fornire, è sicuramente un tema caldo da diversi anni per i ministeri competenti, per la Pubblica Amministrazione sia centrale che locale e, più in generale, per gli enti ed associazioni culturali sia pubblici che privati. Tra le varie soluzioni adottate, quelle che sicuramente rivestono un maggior interesse sono i cosiddetti Musei Virtuali. Benchè in quest ambito una definizione univoca non sia stata ancora coniata, si potrebbe citare quella riportata all interno del progetto V-Must, progetto Europeo nato nell ambito delle iniziative che fanno capo al VII Programma Quadro, coordinato dal CNR e del quale CINECA è uno dei partner principali, che si propone di fornire the heritage sector with the tools and support to develop Virtual Museums that are educational, enjoyable, long-lasting and easy to maintain. Secondo il progetto V-Must un museo virtuale è una personalized, immersive, interactive experiences that enhance our understanding of the world around us. The term 'VM' is a general one that covers various types of digital creations including virtual reality and 3D. Although the concept of VMs is not new, they have recently become very popular and widespread: online, in museums and on heritage sites.. Proprio in linea con quanto espresso nel manifesto del progetto V-Must, il CINECA ha avviato, in collaborazione con il centro Digilab dell Università La Sapienza di Roma, un progetto per la progettazione di un infrastruttura dedicata all allestimento di un museo virtuale del patrimonio pittorico, musivo e numismatico appartenente a fondazioni private italiane. Nodo centrale dell infrastruttura che andrà a realizzare questo museo è il Digital Library Management System (DLMS) sviluppato dal CINECA in collaborazione con la Sapienza; in queste note si intendono descrivere gli ambiti del progetto e le sue linee progettuali, con particolare attenzione agli aspetti di integrazione tra il DLMS e l ambiente di virtualizzazione utilizzato per implementare il museo vero e proprio. Caratteristiche generali del progetto Il progetto MuVir si baserà su un impianto tecnologico caratterizzato da una struttura su due livelli: a) la Digital Library delle opere, che rappresenta l ambiente di base e di visualizzazione standard del materiale digitale. Questo livello verrà realizzato partendo dalla piattaforma già disponibile di SDL (Sapienza Digital Library), con il vantaggio di portare direttamente il Museo Virtuale all interno di Europeana (progetto gestito dall Unione Europea), e di renderlo interoperabile con i portali del MIBAC (Ministero dei Beni e delle Attività Culturali); b) il Museo virtuale, livello che dovrà garantire un accesso efficace e d effetto alle riproduzioni digitali delle opere d arte in possesso delle banche oltre a permettere a esperti del settore ed a semplici utenti una facile implementazione di: esposizioni tematiche; esposizioni di singole collezioni; esposizioni collegate ad eventi in luoghi reali. Ricadute in positivo che il progetto dovrebbe garantire sono quello permettere ai singoli utenti finali il pubblico, i prosumer di creare proprie esposizioni, anche attraverso iniziative quali quella, ad esempio, di un concorso per architetti virtuali relativo alla progettazione del museo virtuale e del suo allestimento. 97

Funzionalità del portale Il MuVir del CINECA si baserà su un grande archivio digitale, disponibile per accogliere gradualmente un complesso di circa 300.000 copie digitali di opere d arte, e su una musealizzazione virtuale con effetti di spettacolarizzazione, in grado di esporre le opere delle quali l archivio abbia incamerato almeno una foto digitale ad alta risoluzione, ovvero un modello 3D acquisito tramite specifici scanner tridimensionali. Questo progetto vedrà, per la creazione dell archivio, un completo riuso della piattaforma di digital library sviluppata da DigiLab Sapienza e da Cineca, attraverso il suo riadattamento alle esigenze di funzionalità aggiuntive ed identità visiva richieste dal progetto. Si vuole evidenziare come l intervento sull architettura del progetto SDL avverrà solo per ciò che concerne lo strato di digital library, dal momento che le funzionalità ed i servizi esposti dallo strato di digital library management system rimarranno di fatto inalterati. Altro elemento che contraddistinguerà il progetto sarà legato all utilizzo di software opensource, di good practice acclarate e su un approccio di integrazione di sistemi. In questo senso il MuVir si caratterizzerà per essere una realizzazione avanzata a livello internazionale. L accesso al portale ed ai suoi servizi sarà possibile anche attraverso device mobili (tablet e smartphone). La mobilitazione dei contributi attivi di diversi tipi di soggetti (curatori delle raccolte designati dalle banche, esperti accreditati come creatori o selezionatori di contenuti, prosumer soprattutto studenti che offrono contenuti informativi, tagging e servizi) permetterà al MuVIr di funzionare come una struttura vivente, in continua implementazione e in sinergia con i centri specializzati del mondo dell università e della cultura. Partire da una architettura Sul piano visivo, fin dalla home page il portale del MuVir si presenterà basato su una architettura di museo virtuale. La vitalità del sito potrà essere esaltata da eventuali concorsi nazionali lanciati per la progettazione degli allestimenti di sale e di mostre virtuali di particolare impatto. Possibile struttura della home page del portale Per offrire un idea generale di come il pubblico dovrebbe accedere al MuVir si può immaginare la seguente architettura logica delle sue pagine. In Home Page Testata: Il MuVir / Gli eventi / Le collezioni delle banche 98

Base: Il catalogo / Nuove acquisizioni / Le opere del mese / Il concorso / Login (curatori, esperti, prosumer, utenti) / Blog: progetta il MuVir Al centro: Pianta o modello 3D del museo, con porta di entrata, da cui si accede al piano superiore o al piano inferiore Il piano superiore: le collezioni L accesso alle sezioni espositive ed all archivio Da un ingresso virtuale si accede a sale che vengono generate dal sistema. Una sala può essere generata per contestualizzazione automatica a partire da una singola opera (se il numero delle opere contestuali eccede il limite della sala vengono generate altre sale); oppure può essere generata per contestualizzazione personale gestita dal visitatore. Le scelte del visitatore (scelta dell opera di partenza, del tipo di contestualizzazione automatica, o della procedura di contestualizzazione personale) sono gestite attraverso un tool accessibile nell ingresso, che filtra le opere da selezionare catturandole dall archivio digitale del MuVir. La contestualizzazione può avvenire per autore, per temi, per stili e correnti, per luoghi, per tipologia (quadri in primis, ma in seguito sculture, monete, anfore, ecc.), e per collezione. Singoli visitatori, o comunità virtuali, possono allestire sale che ritengono compiute come percorso espositivo e chiederne l adozione, vincolata al consenso di curatori esperti riconosciuti dal sistema. Le sale adottate rimangono permanentemente visibili. L archivio del MuVir Vi si accede dall ingresso, aprendo il tool di gestione, ed è naturalmente sempre richiamabile, come le altre voci fisse in home page. L archivio costituisce la base per la generazione del museo. Le opere sono catalogate e descritte da metadati in più lingue che rappresentano la collezione dei cui fanno parte e che descrivono il singolo oggetto reale e la sua copia digitale. Un elemento importante per la corretta impostazione del progetto sarà l attività preliminare di costituzione del Deposito digitale del MuVir, ottenuto dalla puntuale ricognizione della tipologia di risorse documentarie (libri, quadri, sculture, reperti archeologici, ecc.) possedute dalle banche consociate in ABI. 99

Tale attività è finalizzata all individuazione dei set di metadati (tra gli standard internazionali e nazionali esistenti) più idonei a descrivere le collezioni e le singole risorse documentarie. I metadati sono infatti il mastice che tiene insieme le informazioni sugli oggetti digitali, garantendone la qualità e l accesso, e, al contempo, rappresentano la struttura logica che consente flussi di informazioni e nuove relazioni tra le risorse digitali, favorendo l identificazione univoca, l individuazione e la localizzazione di una risorsa, l aggregazione e l organizzazione di risorse con caratteristiche comuni. La scelta dei set di metadati è dunque finalizzata alla fruizione, amichevole e disintermediata, da parte degli utenti, a garantire la conservazione a lungo termine delle rappresentazioni digitali delle risorse documentarie e a consentire al MuVir di aggregare dinamicamente la contestualizzazione di opere e collezioni. Pur nel rispetto dei principi enunciati, per ogni collezione e oggetto si applicherà una metadatazione leggera dal punto di vista descrittivo e conservativo (com è quella attualmente operativa nel progetto Sapienza Digital Library), arricchita tuttavia da metadati semantici (soggetti, temi, generi, stili, ecc.), generati utilizzando schemi di classificazione e vocabolari controllati (authority file, ontologie, thesauri), a seconda del dominio disciplinare di appartenenza dei singoli oggetti e delle aggregazioni per collezioni. L architettura del sistema prevede inoltre la possibilità di applicare le tecnologie di social tagging alla descrizione semantica degli oggetti, consentendo agli utenti accreditati di assegnare loro descrittori e, pertanto, di aumentare il potenziale di aggregazione reticolare e associativa tra concetti, temi e oggetti. Ai metadati relativi a un singolo oggetto vanno collegate le immagini (in HD, o a bassa definizione, o in 3D, o in video). Gradualmente, attraverso i servizi attività in collaborazione, le opere vengono corredate di una scheda, che comparirà nella sala, e che a sua volta conterrà link. Il piano inferiore: le mostre Le mostre al piano inferiore possono essere realizzate con allestimenti speciali, e da curatori autorizzati dal sistema. Possono anche funzionare come promozione di esposizioni reali organizzate dalle banche nelle loro sedi. I servizi Comprendono le attività in collaborazione, il bookshop, i servizi stampa e altri servizi. Attività istituzionali in collaborazione: 100 a) Per curatori autorizzati: autorizzazione di singole sale allestite dai visitatori, autorizzazione di promovideo relativi a eventi, a collezioni, a operazioni di divulgazione. b) Per esperti autorizzati: classificazione di singole opere, scrittura delle schede, autorizzazione del carico dell immagine, autorizzazione del carico dei file audio, audio video, in lingua dei segni o testuali di arricchimento dell apparato divulgativo sulle singole opere. c) Per architetti digitali: progettazione di allestimenti Bookshop a) Picture gallery; b) Oggetti e libri prodotti dalle banche Servizi stampa a) cartella stampa in corso; b) archivio delle cartelle stampa; c) newsletter

Altri servizi a) Crowdsourcing per foto digitali, tagging e altre attività; Contatti L impianto tecnologico La soluzione MuVir si baserà sull infrastruttura di Digital Library Management System sviluppata da Digilab e CINECA, per la quale si è partiti dalla definizione, progettazione e realizzazione di una architettura service-oriented organizzata su tre livelli completamente separati, così come rappresentato in figura. Architettura dell infrastruttura Digital Library Analizzando l architettura individuata, il Livello di Integrazione, rappresentato in figura e denominato Digital Library Service Delivery Platform (SDP), 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à in primis il repository - esposte verso utenti o applicazioni esterne (ad esempio aggregatori OAI-PMH). Tale strumento potrà essere di sicuro ausilio per la disseminazione dei contenuti del portale verso aggregatori generalisti, quali quello rappresentato da Europeana. L uso di quest architettura modulare rende semplice l integrazione di applicazioni eterogenee, capaci di sfruttare i servizi web resi disponibili da 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. E proprio questo livello di integrazione che verrà sfruttato per permettere il colloquio tra l area di repository degli oggetti digitali e lo strato di visualizzazione 3D (la cosiddetta Personal Virtual Gallery) ideato per l allestimento del museo virtuale. 101

Macro-funzioni Digital Library L ambiente di Personal Virtual Gallery verrà sviluppato in stretta sinergia con l impianto di DL grazie a specifiche API esposte da quest ultima per l harvesting dei metadati delle opere e delle loro copie digitali. La struttura generale della soluzione che verrà implementata per questo progetto è riassunta nel seguente schema a blocchi, che evidenzia il livello di interazione tra le sezioni dedicate all ingestion ed all archiviazione (repository) degli oggetti digitali e quella di interfaccia verso l utente (realizzata attraverso la personal virtual gallery, PVG). Schema a blocchi logico-funzionali della soluzione proposta Di seguito si passerà ad una descrizione di maggior dettaglio per questi tre elementi. Ingestion Il processo di Ingestion è il meccanismo attraverso il quale le collezioni di opere digitalizzate ed i loro metadati verranno caricati in piattaforma. Nel progetto SDL di è deciso di aderire ad un modello internazionale basato sulla struttura proposta dall Open Archive Information Systems. La figura sottostante descrive le componenti e le interazioni coinvolte durante il processo di Ingestion. 102

Processo di Ingestion La fase di ingestion è strettamente legata all organizzazione (verrà quindi adattato alle esigenze del progetto MuVir), alla definizione di specifiche e standard per la descrizione e la trasmissione dei contenuti e delle loro descrizioni, al deposito e più in generale alla gestione del ciclo di vita dell oggetto digitale. Una fase importante sarà quindi quella dell analisi dei materiali esistenti e dei criteri decisi per la loro metadatazione, individuando dei campioni rappresentativi delle diverse tipologie, a cui poter applicare degli specifici content model. La preparazione dei campioni con la costruzione dei file di metadatazione, la rinomina dei file e il riordino degli oggetti digitali verrà realizzata facendo diverse prove di ingestion fino al raggiungimento della forma più opportuna che permetta al sistema di effettuare il caricamento del campione e di attivarvi i servizi previsti per la sua disseminazione verso l ambiente di Personal Virtual Gallery (PVG). Per ogni campione verranno pertanto stati stabiliti dei vincoli sulla struttura informativa, che permetteranno l attivazione dei servizi adeguati alle caratteristiche peculiari dei campioni, come ad esempio la fruizione del contenuto attraverso specifico visualizzatore utilizzato nell ambiente PVG. La metodologia adottata in SDL prevede l individuazione di un prototipo di workflow per la lavorazione di una collezione completa e per le singole risorse. In parallelo viene sviluppato un software specifico per la creazione di una procedura automatica che crea, raccoglie, integra e codifica i metadati secondo il modello di contenuto informativo, in conformità all infrastruttura definita e in coerenza con i vincoli stabiliti dalla procedura di ingestion. Il workflow si conclude con l impacchettamento automatico di ogni singola risorsa che viene così trasferita nel deposito digitale e con la creazione dei metadati di livello collezione, ovvero con le informazioni di indirizzamento e di sintesi descrittiva delle risorse, appartenenti alla collezione specifica. Questo lavoro si traduce quindi in un servizio, non solamente di tipo informatico, ma di gestione di processo, che è possibile fornire, sia come fase di progetto che come progetto a sé stante, da integrare nell ipotesi di future estensioni del Servizio Digital Library a nuovi contesti ai quali il progetto MuVir dovrà far fronte (ad esempio nel caso in cui si decida di inserire oggetti digitali provenienti da scansioni 3D). Per quanto riguarda la funzionalità di ingestion, quanto già sviluppato nell ambiente della DLMS permetterà di conferire le risorse digitali (già codificate e strutturate) nel Repository del portale MuVir; queste stesse risorse, in base alla complessità del progetto, potranno essere eventualmente oggetto 103

di una serie di attività che possono essere raggruppate in una fase di pre-ingestion, secondo gli standard di metadati e i vincoli definiti in fase di analisi. L ingestion all interno della repository del MuVir verrà inoltre dotata di un backend e di una interfaccia che permetteranno il monitoraggio puntuale di tutti gli step di lavorazione previsti per l ingestion di una risorsa digitale o di una collezione di risorse. La fase di ingestion, sempre sfruttando la Service Delivery Platform, verrà integrata con il motore di transcodifica per permettere il calcolo dei derivati digitali in base alla tipologie di oggetto conferite. Durante questa fase, in conformità con le migliori pratiche derivanti dalla conservazione a lungo termine e dal modello OAIS, verranno seguiti i seguenti step: validazione del pacchetto SIP di ingestion (container, file METS e risorse referenziate, specifiche interne) controlli sul naming del pacchetto e delle risorse controlli di integrità sui file file characterization controlli antivirus sui contenuti controllo dell intero processo di ingestion con possibilità di rollback Il processo sarà inoltre esteso per permettere di utilizzare l ingestion di pacchetti SIP contenenti i soli metadati descrittivi delle risorse in modo da sfruttare il meccanismo per aggiornare i metadati di risorse già presenti nel repository senza doverne ricaricare i contenuti digitali associati. Con l ingestion di un SIP potranno infine essere stabilite, oltre che le relazioni con le collezioni di afferenza, le autorizzazioni di accesso preventivamente stabilite sulle risorse esposte. Repository Per quanto riguarda l archiviazione e la conservazione dei contenuti digitali, il sistema si baserà sull utilizzo di un Digital Repository realizzato attraverso il middleware open source Fedora Commons. La scelta di questo sistema di gestione è indubbiamente strategica e vincolante ai fini della gestione a lungo termine dei materiali. Fedora Commons fornisce un ambiente articolato ed orientato alle integrazioni con web services e tecnologie del web semantico e alla conservazione a lungo termine. Inoltre, permette l applicazione di diversi content model che sono più rispondenti alle esigenze di gestione delle peculiarità dei materiali, che il sistema dovrà gestire. Il repository fornirà anche i servizi di base (ad esempio versioning, audit trailing, fixing) per supportare le fasi di monitoraggio, controllo, migrazione e conservazione sul lungo termine che saranno affrontate nelle prossime evoluzioni del servizio. Le risorse che devono essere conservate a lungo termine al fine di poter garantire la loro autenticità, integrità e possibilità di accesso nel lungo periodo devono essere conferite al sistema opportunamente costruito per garantire la conformità agli standard previsti in questo ambito. Per quanto riguarda la Digital Preservation il modello di riferimento adottato è l OAIS Reference Model9 (ISO:14721:2003) e in conformità verrà adottato lo schema di metadati di conservazione PREMIS. Il sistema di repository attualmente in uso nel progetto SDL è stato ingegnerizzato per acquisire qualsiasi tipo di schema di metadati, ovvero anche schemi XML non previsti dalla struttura core di 9 Open Archival Information System, http://www.iso.org/iso/catalogue_detail.htm?csnumber=24683 104

metadati e considerati dal sistema di deposito come estensioni a suddetta struttura. Il deposito è inoltre integrabile con i più diffusi sistemi di persistent identifier. Il Progetto intende quindi ingegnerizzare le soluzioni prototipali già implementate sul repository in termini di servizi integrati e modelli. La modellazione dei contenuti nel repository si baserà su un approccio completamente atomistico e sull utilizzo di relazioni RDF. Questo approccio, esemplificato dalla figura sottostante, oltre che garantire flessibilità ed estendibilità dei modelli realizzati, permette di definire servizi di dissemination specifici e riutilizzabili e di applicare regole di accesso granulari. I metadati descrittivi, amministrativi e strutturali delle risorse verranno codificati in conformità agli standard più diffusi a livello internazionale e arricchiti dai riferimenti a vocabolari controllati e a specifici thesauri laddove possibile o necessario. Esempio di modellazione atomistica Standard di metadati tecnici specifici per le tipologie di materiale, come anche quelli previsti per la gestione dei diritti e la conservazione a lungo termine, verranno resi disponibili per il progetto MuVir, fermo restando il principio per cui la struttura di contenimento permette in qualsiasi momento di integrare altri standard più adatti alle esigenze future. 105

Infrastruttura di Metadati Il Progetto MuVir inoltre prevede l integrazione di una applicazione Image Server per l elaborazione ed il caching delle immagini presenti nel repository. Questa applicazione sarà basata su software open source e permetterà di fornire i derivati delle immagini al Portale evitando di dover effettuare una interazione diretta con il repository per l erogazione delle immagini agli utenti finali. Per garantire l affidabilità del servizio per il repository si andrà a progettare e realizzare un modello leader follower in cui un nodo del repository agirà da master e un nodo verà mantenuto sincronizzato. Il secondo nodo verrà utilizzato per effettuare l erogazione del servizio mentre il primo sarà dedicato alle operazioni di ingestion. In questo modo otre a garantire replicazione intrinseca dei dati e affidabilità si potranno attuare politiche di load-balancing sui due nodi durante la fase di dissemination. La Personal Virtual Gallery La Personal Virtual Gallery (PVG) rappresenta la modalità di navigazione virtuale delle risorse costituite dalle collezioni nell ambito del progetto MUVIR. E parallela e autonoma rispetto all esplorazione delle opere attraverso una più classica attività di browsing delle stesse da parte dell utente (che utilizza strumenti di selezione e di ricerca per filtrare dinamicamente le opere mediante un interfaccia web semplice e flessibile). La PVG permetterà all utente di gestire visualmente un elevato numero di items digitalizzati - costituiti dalle opere provenienti dalle collezioni per collocarli automaticamente in uno spazio virtuale generato in real-time. Ad ogni opera è associato un contenuto informativo che deriva dai metadati di riferimento. Una volta che l ambiente simulato viene generato l utente è in grado di esplorarlo in realtime e in soggettiva (first-person), cioè attraverso una modalità che simula il punto di vista del visitatore per consentirgli un esperienza il più possibile coinvolgente e spettacolare. In generale lo sviluppo di un applicazione avanzata di grafica virtuale costituita da una piattaforma museale 3d ha l obiettivo non solo di spettacolarizzare la semplice fruizione delle collezioni ma anche di rappresentare un valido strumento utile a diversi profili di utenti nelle varie fasi del processo di valorizzazione del bene culturale. L utilizzo di tale tecnologia può indubbiamente semplificare, dal punto di vista della gestione e del project management di una mostra o di una collezione museale, operazioni e attività specifiche al fine di favorire anche un risparmio sia in termini di tempo che di risorse impiegate. In particolare i profili coinvolti riguardano, oltre all utente assimilabile al visitatore 106

classico di una mostra, le figure del curatore, dell esperto d arte, dello storico e più in generale dello studioso, coinvolti fin dall inizio di un allestimento museale in operazioni di design espositivo e di progettazione dei possibili percorsi tematici e concettuali per una visita. In un ottica collaborativa la piattaforma virtuale che il progetto MUVIR intende sviluppare rappresenterebbe inoltre la possibilità per i detentori delle collezioni di rappresentare contemporaneamente non solo una singola proposta di allestimento ma anche la molteplicità delle sue varianti dando all utente visitatore la possibilità di fruire secondo una modalità fortemente immersiva il percorso museale simulato, anche attraverso le componenti immateriali dei beni culturali esposti (documenti e materiali di diversa natura e formato come testi e documenti audio e video - correlati alle opere esposte). Si tratta sostanzialmente di una nuova strategia espositiva interessante anche nell ottica di attrarre nuovi utenti al fine di rafforzare il target tradizionale in ambito museale. La PVG sarà progettata per essere il più possibile espansibile e modulare, in un ottica che risponde a esigenze pratiche relative alla possibilità nel futuro di inserire nuove risorse e funzionalità. La tecnologia individuata per sviluppare un workflow produttivo utile alla costruzione di un modello di navigazione virtuale assimilabile alla PVG progettata è il tool di Unity3d, un ambiente di sviluppo che consente la costruzione di applicazioni virtuali potenti, versatili e usabili, garantendo inoltre prestazioni elevate in termini di resa grafica. La logica applicativa della PVG che implementa le funzionalità e le interazioni utente sarà sviluppata in Javascript; verranno utilizzate librerie di tipo.net per le funzionalità inerenti alla parte di networking. La PVG infine verrà implementata per un utilizzo multipiattaforma per essere fruito sia su dispositivi mobili sia da postazioni desktop: in entrambi i casi (app mobile e desktop application) si tratta di applicazioni standalone che si installano sui device nativamente. Portale MuVir Il portale MuVir verrà realizzato sfruttando un insieme di moduli Drupal che si andranno a sviluppare durante il Progetto. Questi moduli saranno progettati come componenti configurabili - integrati con il modulo principale già sviluppato nel contesto del progetto SDL - che permetteranno la costruzione modulare di interfacce DL del portale. Il Progetto prevede moduli per la visualizzazione di collezioni, la visualizzazione di aggregazioni, il browsing ed il search, la visualizzazione di singole risorse digitali (primo piano), il faceting, l integrazione con servizi esterni. Search & Browsing Le funzionalità di ricerca e browsing avanzato permetteranno di navigare e ricercare gli oggetti della Digital Library sulla base delle informazioni contenute nei metadati descrittivi. Il Progetto prevede di indicizzare i metadati MODS, le relazioni tra gli oggetti presenti nel repository e i contenuti testuali originali e derivati da trascrizioni automatiche o da analisi semantiche. La funzionalità faceting permetterà il browsing a faccette delle risorse digitali presenti nella Digital Library. La classificazione a faccette permette di catalogare un singolo asset digitale sotto più categorie (le faccette), ciascuna descrittiva di una aspetto (o faccia) particolare dell asset. Il servizio permetterà 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 espresse in RDF. Queste stesse relazioni saranno utilizzate per modellare aggregazioni adhoc e personalizzate di entità. Il Progetto prevede di sfruttare le funzionalità del motore di ricerca per permettere, dati i metadati descrittivi di una risorsa digitale, di individuare le risorse vicine rispetto a un subset definito di metadati (funzionalità MLT). 107

Faceting e full-text search Sfruttando il motore di indicizzazione Lucine/SOLR integrato nella per il browsing avanzato, la funzionalità full-text search permetterà la ricerca full text all interno dei testi, eventualmente associati alle opere esposte (commenti critici; analisi storico artistiche, etc.). La ricerca full-text potrà essere applicata a contenuti testuali o alla trascrizione in testo di immagini derivanti da processi di digitalizzazione (ad esempio libri moderni) quando disponibile. Le due attività principali saranno quella di integrare il motore di ricerca SOLR sia in fase di indexing che di dissemintation. Dovranno infatti essere identificati i metadati oggetto di indicizzazione, definendo per ognuno la modalità di indicizzazione (ad esempio tokening, stemming) e il peso che il motore di ricerca dovrà assegnare rispetto all algoritmo utilizzato per il calcolo della rilevanza. Infine dovranno essere individuati i metadati che saranno utilizzati per il faceting. Visualizzatori Il Progetto prevede l aggiornamento dei viewer già in uso per recepire e sfruttare le nuove funzionalità realizzate durante le fasi precedenti del progetto (ad esempio full-text indexing) e l integrazione di nuovi visualizzatori di seguito descritti. Immagini ad alta risoluzione IIPImage è un player avanzato ad alte prestazioni per la visualizzazione web-based in streaming e lo zoom di immagini ad alta risoluzione. È stato progettato per essere veloce ed efficiente anche in condizioni di banda limitata e di basse prestazioni del client (sia in termini di meoria che di capacità di calcolo). Il sistema può gestire immagini di dimensioni nell ordine di gigapixel così come immagini con caratteristiche avanzate come profondità a 8 e 16 bit, le immagini CIELAB colorimetriche e immagini scientifiche multispettrali. Lo streaming è tile-based, che consente di visualizzare, esplorare e ingrandire in tempo reale porzioni di immagine mantenendo il sistema scalabile indipendentemente dalla dimensione dell'immagine di origine. Le immagini sorgente possono essere in formato TIFF o formato JPEG2000. Nel Progetto si prevede di utilizzare quest ultimo formato, anche se potenziali estensioni verso altri formati, quali il FITS, potranno essere valutate ed eventualmente implementate. Questo viewer verrà utilizzato in alternativa all ambiente PVG o qualora si necessiti di un dettaglio maggiore. Gestione degli utenti e delle autorizzazioni La gestione degli accessi al Portale MuVir si baserà su considerazioni e sull analisi dello stato dell arte dei sistemi di gestione delle identità e di autenticazione attualmente utilizzati in rete. La definizione delle classi di utenza verrà fatta a seguito di un analisi preliminare degli obiettivi che il portale intende raggiungere. Il sistema di gestione delle autorizzazioni si baserà su un approccio misto basato su ruoli e capabilities. Dato un ruolo, a livello di collezione si avrà la possibilità di definire se un utente ha la possibilità di accedere o meno (e quindi di ricercare) a una risorsa. Queste autorizzazioni saranno memorizzate all interno del repository Fedora Commons, espresse secondo lo standard XACML. Un utente che può accedere ad una risorsa potrà infine accedere alle rappresentazioni digitali in base alle capabilities definite sui suoi ruoli e sulla particolare tipologia di risorsa digitale. Queste capabilities saranno memorizzate nel backend del Livello di Integrazione, il quale si occuperà anche della loro risoluzione a run-time. Per permettere l integrazione con il Portale SDL vi sarà una associazione biunivoca tra i ruoli del portale e i ruoli utilizzati nelle regole XACML. Il repository, attraverso una integrazione con il backend del portale Drupal, avrà quindi la possibilità di determinare il ruolo di ogni utente. 108

Conclusioni Il progetto MuVir rappresenta un evidente esempio delle caratteristiche di flessibilità e versatilità offerte dall architettura del DLMS progettato da Digilab-Sapienza e da CINECA. In particolare l aver optato in questo progetto per un architettura aperta e modulare, basata sull utilizzo di standard di comunicazione inter-processo e sull esposizione dei servizi applicativi dall ambiente di repository a quello di visualizzazione (la Personal Virtual Gallery in questo caso), avrà un sicuro impatto sulle tempistiche e sulle economie del progetto MuVir, che di fatto potrà fornire un utile strumento di raffronto delle evolutive che il DLMS potrà garantire in futuro in altri e più svariati contesti. 109

IL CICLO DEI DIRITTI NELLA SAPIENZA DIGITAL LIBRARY. DOCUMENTO DI LAVORO. di Silvia Ortolani Sapienza Digital Library. Gli aspetti legali Sapienza Digital Library è un infrastruttura a supporto della conservazione, gestione e diffusione delle risorse digitali relative al patrimonio bibliografico, archivistico e museale della Sapienza 10, nonché a corpora documentarie provenienti da altre fonti. Si configura come un portale di servizi rivolto innanzitutto alla comunità universitaria, ma aperto anche all utenza esterna con servizi interattivi e l offerta di uno spazio di condivisione e comunicazione delle risorse culturali. SDL nasce come progetto di ricerca da un accordo tra Sapienza e Cineca, che costituiscono quindi i due soggetti di riferimento, nelle loro differenziate funzioni. L architettura logica del sistema e le sue funzioni comportano alcune questioni legali, riconducibili a tre aspetti fondamentali: trattamento dei dati personali degli utenti interni a Sapienza ed esterni; condizioni d uso del portale e dei suoi servizi; diritto d autore. Questi aspetti necessitano di singoli disclaimer legali, accessibili da parte degli utenti e basati su una studiata architettura di identificazione e gestione dei diritti e delle responsabilità. Per quanto riguarda le prime due tematiche, si rimandano all attenzione dell Amministrazione Centrale di Sapienza i documenti già elaborati e in attesa di verifica e approvazione. In questo documento si tratta la problematica relativa al diritto d autore, e si delinea l architettura che consente in Sapienza Digital Library (all interno del quadro dei diritti, Legal Framework) la gestione dei diritti d autore e connessi (da qui in poi anche copyright) e delle relazioni tra le componenti documentali di tale gestione. Il ciclo dei diritti Il ciclo del copyright ha inizio quando qualcuno in qualità di creatore dà origine ad un opera. Si sviluppa qui il soggetto creatore e l azione della creazione. Automaticamente questo dà luogo alla figura del titolare dei diritti esclusivi (morali e di sfruttamento) sulla creazione. Questo soggetto può essere l autore stesso o un altra entità legale legata al soggetto da una relazione contrattuale. A questo punto entrano in scena altri soggetti, altre azioni e relazioni. L opera può essere trasferita, trasformata, distribuita grazie a soggetti che instaurano relazioni contrattuali e legali con il titolare dei diritti ovvero dal titolare stesso, attraverso Content Provider con sistemi di autorizzazioni. Alla fine di questo processo c è l utente (al quale sono o non sono consentite alcune azioni in relazione all opera), legato quindi anch egli da una relazione con i soggetti titolari dei diversi diritti. Si tratta di un ciclo complesso che si vuole semplificare il più possibile, ma non troppo. Si è scelto di farlo attraverso l individuazione di quattro entità : soggetto, oggetto, azione, relazione. 10 A. Di Iorio, M. Schaerf, M. Guercio, S. Ortolani, M. Bertazzo, A digital infrastructure for trustworthiness. The Sapienza Digital Library experience, IRCDL 2013, Rome January 31 february 1 2013. 111

Il ciclo dei diritti in Sapienza Digital Library I livelli di valutazione e controllo dei diritti Il quadro legale (Legal Framework) costituisce la cornice entro la quale il ciclo dei diritti può compiersi. Esso è costituito dalle norme, i regolamenti, gli accordi internazionali che regolano i diritti d autore. All interno di tale quadro - che per Sapienza Digital Library riguarda i diritti relativi alla trasformazione, copia, distribuzione e comunicazione -, si determinano i termini delle licenze e dei contratti (Licensing Terms) e, di conseguenza, i controlli all accesso (Access Control) rivolti agli utenti. 112

Da tale primo livello si raggiunge il secondo livello di specificazione che è definito dai diritti esclusivi individuali detenuti dai titolari dei diritti (Ownership rights) che comprendono i diritti morali e patrimoniali. Nel caso di Sapienza Digital Library essi possono essere in carico di singoli soggetti ovvero in carico ad entità legali non individuali. Da tale livello si arriva poi al livello degli accordi di utilizzo che il titolare dei diritti stabilisce con un altro soggetto attraverso singoli atti. Nel caso di Digital Library tale livello si configura attraverso un sistema diversificato di accordi collettivi e individuali anche attraverso singole strutture che partecipano attivamente al progetto (e.g. DigiLab Centro di ricerca e di servizi), che firmano accordi per SDL con i titolari ovvero con i loro rappresentanti. Infine, vi è il livello delle singole azioni consentite, non consentite o consentite a condizioni particolari (e.g. uno studente appartenente alla classe di e-learning con tracciatura completa sul sito, può avere la possibilità di effettuare una copia ad uso personale del materiale didattico del corso che sta frequentando). Ogni azione compiuta da un diverso soggetto deve rientrare all interno di tutti questi livelli di controllo sovrapposti. Il quadro legale determina e regola i diritti individuali e questi ultimi regolano i permessi concessi dai titolari ad altri; infine, i permessi garantiti dai titolari possono determinare, caso per caso, il consenso al compimento di singole azioni da parte dell utilizzatore (user). Le entità del ciclo dei diritti in SDL I soggetti I soggetti coinvolti nel ciclo dei diritti di SDL sono rappresentati innanzitutto dai soggetti creatori della library, e cioè SBS (il Sistema Bibliotecario Sapienza), DigiLab Centro interdipartimentale di ricerca e servizi e CINECA. Tali soggetti, attraverso convenzioni e contratti hanno costruito, attraverso funzioni diversificate, la Digital Library. Sapienza Digital Library Sapienza, il Centro DigiLab e SBS sono, contemporaneamente anche soggetti titolari di diritti in riferimento alle produzioni che fanno capo all amministrazione pubblica da parte di propri dipendenti. Soggetti creatori e titolari di diritti sono inoltre: le strutture periferiche della Sapienza (e.g. Dipartimenti, Musei, etc.), singoli docenti, studenti, ricercatori. Singoli utenti, inoltre, non appartenenti alla comunità di Sapienza, potranno, attraverso il servizio Dona una risorsa contribuiranno all implementazione delle risorse di SDL, divenendo soggetti attivi del portale. Infine, sono soggetti di SDL tutti quegli enti, organismi legali, Istituzioni, Archivi e singoli ricercatori esterni che desiderano diffondere il loro patrimonio o il loro lavoro attraverso SDL. Tutti i suddetti soggetti fanno parte inoltre del soggetto più esteso degli utenti di SDL. 113

Ricercatori Funzionari/amministrativi Soggetti Comunità Sapienza Amministrazione centrale DigiLab SBS Dipartimenti e altre strutture periferiche Professori Studenti Soggetti esterni singoli utenti/donatori istituzioni Archivi Singoli ricercatori Le azioni Si intende qui per azione qualsiasi processo che comprenda l identificazione, la valutazione e la gestione del copyright. Queste azioni riguardano i diritti di sfruttamento (Exploitation Right) delle opere di creazione ospitate e comunicate in SDL i cui diritti saranno di volta in volta detenuti da uno o più soggetti di quelli definiti sopra. Tali diritti includono: Diritto esclusivo di autorizzare la riproduzione, diretta e indiretta, permanente o temporanea, in ogni modo e forma (ReproductionRight) Diritto esclusivo di autorizzare qualsiasi tipo di comunicazione al pubblico, incluso il diritto di far accedere ogni singolo individuo nel tempo e nel posto scelto individualmente. Ogni tipo di trasmissione dell opera, on demand, broadcast, trasmissione interattiva, ritrasmissione, messa in disponibilità in rete (ComunicationRight) Diritto esclusivo di autorizzare la messa a disposizione del pubblico dell originale o di copie dell opera in vendita o in altro tipo di trasferimento della proprietà. Si tratta di un diritto che riguarda esclusivamente le opere su supporto (dvd, cd, print on demand) o comunque oggetto tangibile, in quanto per tali oggetti si applica l esaurimento del diritto all acquisto della copia (DistributionRight). Diritto esclusivo di autorizzare la manipolazione dell opera in ogni forma e modo (TransformationRight). Tutti questi diritti esclusivi dei titolari si innestano nell architettura dell individuazione, valutazione e gestione dei diritti in SDL, attraverso una serie di accordi (RightAgreements) dove sarà indicata la declinazione delle singole e/o multiple autorizzazioni concesse alla Digital Library dai titolari dei diritti. Di conseguenza, si prevedono le seguenti tipologie di azioni concesse o non concesse alla Digital Library stessa e agli utenti. Le specifiche declinazioni di tali azioni possono essere riassunte dallo schema di seguito: 114

Tutti i diritti riservati Accesso libero Accesso limitato Accesso alla scheda di catalogazione Accesso alle risorse descrittive Visualizzazione Download Streaming Copia Riutilizzo dell opera Modifica e/o rielaborazione successiva dell opera Sì/no Sì/no Sì/no Sì/no Sì/no Sì/no Sì/no Sì/no Sì/no Sì/no Sì/no Le relazioni Per relazione si intende qualsiasi atto che contenga un accordo che riguardi l identificazione, la valutazione e la gestione del copyright. Il primo accordo quadro riguarda i soggetti che stanno collaborando alla creazione di SDL: Sapienza, attraverso il Centro DigiLab, e CINECA. Tale accordo prevede la responsabilità congiunta dei due soggetti nelle fasi di ingestion e dissemination delle risorse ospitate in SDL. A tale accordo si affianca una convenzione tra il Centro DigiLab e la Siae in riferimento alla comunicazione al pubblico di risorse a scopo di ricerca e didattica, nel quale si riconosce il profilo di promozione culturale del sito di DigiLab e si precisa la possibilità, all interno della legislazione vigente in materia di diritto d autore, di utilizzare le eccezioni e limitazioni previste dalla legge all interno della classe e-learning della comunità della facoltà di Scienze Umanistiche della Sapienza, ai fini dell insegnamento in riferimento ad opere sottoposte al diritto d autore. Oltre a tali documenti, sono in essere altre convenzioni tra il Centro DigiLab e soggetti esterni che cedono al Centro e alla Digital Library l autorizzazione a pubblicare sul sito le opere di cui sono titolari di diritto esclusivo. Tale autorizzazione, non esclusiva, si sostanzia in una licenza di comunicazione al pubblico delle opere e non determina la cessione di alcun diritto da parte del/dei titolari che si dichiarano tali assumendosi la responsabilità legale di tale dichiarazione. Un accordo una tantum con accettazione a spunta è previsto per i singoli donatori che fanno uso del servizio Dona una risorsa che permette di donare online oggetti digitali attraverso una procedura in corso di completamento. 115

Il ciclo delle relazioni si può così schematizzare: LEGAL FRAMEWORK L. 633/41 e successive modifiche Gli accordi e le licenze Gli oggetti Gli oggetti digitali presenti in SDL saranno collegati alla fonte di provenienza (accordi, convenzioni, licenza) che ne determinerà le possibilità di accesso e di utilizzo, fatti salvi gli oggetti per cui non sarà possibile l accesso. 116 Esempio del ciclo di accesso ad un singolo documento

INFRASTRUTTURA CINECA 117

119

120

121

122