Open access, archivi istituzionali e valutazione della ricerca
L’archivio istituzionale del Politecnico di Torino:
da Ugov a Eprints
Paolo Tealdi
24 ottobre 2011
Agenda
• I sistemi a supporto della Ricerca al Politecnico
•
•
I requisiti dell’Ateneo
Architettura applicativa
• Il catalogo della ricerca e il Repository istituzionale.
•
•
Funzioni di UGOV e di Eprints
Flussi operativi e di dati
• Perché Eprints
•
•
Motivazioni della scelta architetturale
Caratteristiche del software
• Prossimi passi
•
Future feature di Eprints e anagrafe della ricerca
2
I sistemi a supporto della Ricerca al Politecnico
I requisiti dell’Ateneo
Negli ultimi anni l’ateneo ha ritenuto opportuno potenziare il sistema informativo a supporto
della ricerca perseguendo la strategia di una maggiore copertura funzionale e di integrazione
tra i sistemi.
 Capacità di conoscere e rappresentare le attività di Ricerca del Politecnico
 Rafforzare la capacità di attrarre progetti e fondi
 Spinta sulla divulgazione della produzione scientifica, anche a beneficio del
trasferimento tecnologico
 Semplificazione /automazione dei processi di valutazione della ricerca






Possibilità di mappare “chi fa che cosa” nell’ambito della ricerca
Facilità (ed univocità) di classificazione degli ambiti della ricerca
Migliorare la conoscenza delle varie tipologie di accordi (non solo contratti)
Strumenti a supporto della gestione della relazione con i “clienti”
Rafforzamento della presenza Web
Spinta all’Open Access
 Maggiore integrazione tra gli applicativi di Ateneo ed eliminazione progressiva sistemi
locali
3
I sistemi a supporto della Ricerca al Politecnico
Architettura applicativa scelta
Portale della ricerca
Portale Open
Access
Valutazione
Ricerca
POLITO -ePrints
POLITO - MyPoli
Catalogo della
ricerca
Anagrafe
della ricerca
CRM - Analisi dati
contratti progetti
partner
CINECA - POLITO
Gestione
Progetti
contabilità
Operational data store /Datawarehouse
CINECA - Ugov
Gestione operativa
contratti
BPM – Flux + Doqui
Database contratti
Anagrafiche enti*
POLITO - Pauper
4
U-GOV Catalogo della ricerca
Caratteristiche generali
U-GOV Catalogo della Ricerca è stata la naturale evoluzione del software Saperi del
Cineca, che si basava sui dati presenti nel sito docenti del Miur e che ha permesso la
valutazione della ricerca.
Ha permesso di :
 Essere integrato/integrabile con gli altri moduli di UGOV (anagrafiche di
ateneo, contratti, anagrafe della ricerca, etc)
 Dotare l’ateneo di uno deposito UNICO dove i docenti possono inserire le
proprie pubblicazioni e da cui l’ateneo può attingere per le varie attività
istituzionali (valutazione, statistiche, la pubblicazione in accesso aperto, … )
 Acquisire una gestione avanzata e flessibile delle pubblicazioni, evitando le
duplicazioni intrinseche del sito docente del Miur
 Dotare l’ateneo di un applicativo che ha un modulo raffinato per la gestione
della valutazione della ricerca (peer review)
5
EPRINTS Repository istituzionale
Caratteristiche generali
PORTO, il repository istituzionale del Politecnico di Torino è stata la naturale evoluzione
del progetto UGOV - Catalogo della ricerca, contiene una copia esatta delle pubblicazioni
presenti in UGOV ed è strutturato per la loro consultazione da parte degli utenti esterni.
Ha permesso di :
 Presentare i dati di UGOV (citazioni e full-text), che non ha una interfaccia
pubblica accessibile via browser.
 Indicizzare in modo raffinato i contenuti (metadati e file) presenti in UGOV
 Effettuare raggruppamenti per categorie per evidenziare i dati da vari punti di
vista
 Produrre un portale tramite il quale navigare verso altri dati presenti in ateneo
(la rubrica, in futuro il portale dell’anagrafe della ricerca)
 Effettuare statistiche sui download dei PDF
 Dotare l’ateneo di un applicativo per il controllo del copyright di ogni singolo
allegato che gli autori hanno reso ad accesso aperto.
6
Da UGOV a EPRINTS
Flusso applicativo
Il flusso applicativo di una pubblicazione è
 Uno degli autori inserisce, eventualmente coadiuvato da un referente
dipartimentale, in UGOV la pubblicazione, associandola a TUTTI gli autori
interni, ed eventualmente allegando il full-text (privato/pubblico).
 Quando viene salvata in modo definitivo, è trasferita automaticamente al
cineca per popolare il sito docente (si evita al docente di doverla inserire due
volte)
 In modalità batch una volta al giorno viene trasferita su PORTO e indicizzata
nel catalogo.
 Ciascun allegato definito dall’autore ad accesso aperto viene controllato dal
gruppo «copyright» e, se effettivamente rientra nei limiti definiti dagli editori,
viene messo ad accesso aperto. In alternativa il gruppo interagisce con l’autore
per la pubblicazione di un allegato corretto.
7
Da UGOV a EPRINTS
Flusso dei dati
Il flusso dei dati consiste in
 I dati vengono esportati da UGOV tramite un opportuno applicativo sviluppato
dal Politecnico di Torino che, partendo dal tracciato ORACLE, trasforma i campi
bibliografici di descrizione della pubblicazione in un file XML.
 Successivamente , attraverso dei webservices, il file XML processato da un
programma che carica via batch i record in EPRINTS.
 Gli allegati associati a ciascun record, sempre tramite webservices, vengono
importati direttamente dal programma batch, trasferendo i relativi metadati di
accesso e di descrizione.
 Ogni esportazione prevede l’inserimento di tutti i record nuovi e la sostituzione
dei record modificati. Essa viene eseguita a scadenza giornaliera o in base alle
necessità in modalità manuale.
 Ad ogni esportazione è necessario preservare i dati relativi alla gestione del
copyright, la cui gestione non è (ancora) in UGOV.
8
Perché U-GOV e EPRINTS
Scelte dell’architettura
Tra le possibili scelte architetturali abbiamo scelto di dividere il gestionale (UGOV) dal
motore pubblico perché
 Il gestionale UGOV è all’interno di una suite di altri applicativi che stiamo già
utilizzando e con i quali il modulo dialoga e permette interazioni di dati (ad
esempio il modulo progetti )
 Il gestionale non è, forse volutamente, provvisto di un’interfaccia pubblica che
doveva essere implementata autonomamente, avendo solo una interfaccia
OAI-PMH disponibile.
 La suddivisione tra gestionale e Repository istituzionale ci sembrava
permettesse di ottimizzare gli sforzi di sviluppo e di manutenzione dei due
applicativi.
 Avere un repository istituzionale garantisce una maggiore visibilità da parte
della comunità accademica e da quella locale, e funziona come agente
virtuoso nei confronti degli autori che vengono spinti a inserire le loro
pubblicazioni nel deposito
9
Perché Eprints
Scelte dell’architettura
E’ stata effettuata una valutazione tra i possibili software di sviluppo di un Deposito
Istituzionale. I motivi della scelta di EPRINTS sono stati :
 Si riteneva necessario un applicativo di pubblico dominio, anche per la filosofia
relativa agli «archivi aperti» che sottende l’intero sistema
 All’interno del Politecnico esisteva una esperienza pregressa in Eprints (2.0) e
in perl, il linguaggio di programmazione in cui è sviluppato l’applicativo : tutto
il codice prodotto per la gestione della biblioteca è stato sviluppato in perl.
 Si aveva scarsa dimestichezza con il linguaggio di programmazione di D-SPACE
 Fedora, probabilmente il più completo (e complesso) tra gli applicativi non era
dotato di una interfaccia web e quindi lo sforzo per svilupparne una da zero è
stato ritenuto troppo oneroso
 Ritenevamo che il gruppo di sviluppo di Eprints desse un supporto sufficiente
alla comunità e che, d’altro canto, fosse un progetto vivo, con una comunità
molto vivace.
 E’ possibile, dietro contratto, accedere al supporto da parte degli sviluppatori
di Eprints. Al momento non è stato necessario.
10
Perché Eprints
Caratteristiche dell’applicativo
Le principali caratteristiche dell’applicativo, che hanno contribuito alla sua scelta, sono :

Applicativo di pubblico dominio, con possibilità di accedere e modificare i sorgenti, per
adattarli alle proprie necessità

Grande comunità di utilizzatori e sviluppatori, che nel tempo hanno sviluppato un gran
numero di plugin che aggiungono funzionalità a quelle presenti nel pacchetto base e
possibilità di loro ulteriore personalizzazione

Possibilità di import/export dei dati in un nutrito numero di formati adatti al riuso.

Presenza dell’interfaccia di accesso OAI-PMH

Gestione sofisticata degli allegati e dei loro metadati

Possibilità spinta di personalizzazione dei dati (aggiunta di campi semplici e/o strutturati)
e della loro presentazione.

Possibilità di personalizzazione nella presentazione (look and feel del sito) e nell’utilizzo
delle viste: raggruppamenti dei dati in base a criteri assegnati

Possibilità di avere più istanze attive di EPRINT in un solo sito ed elevata
personalizzazione tra istanze (dati e sito)

Supporto per la gestione del multilingua (nativo)

Supporto per i database mysql, postgres ed oracle
11
Perché Eprints
Multi istanza
digit.biblio.polito.it
webthesis.biblio.polito.it
Porto.polito.it
12
Implementazione di Eprints
L’home page
Multilingua
Struttura
organizzata in viste
Canale di News
Ultimi titoli inseriti
Ultima pubblicazione con allegati ad accesso aperto
13
Implementazione di Eprints
Home page - 2
Ricerche
Statistiche
RSS feed
Top periodici
14
Implementazione di Eprints
Viste
Vista per autori
Vista per anno di pubblicazione
Vista per titolo del periodico
Vista per aree
disciplinari
Vista per dipartimenti
Vista per allegati
15
L’implementazione di Eprints
Altre funzioni
Altre funzioni interessanti :

Link al link resolver : esiste un meccanismo software che permette, ogni volta che si crea
una pagina relativa ad un documento, di associargli dinamicamente altri dati,
ristrutturando opportunamente i campi presenti, oppure importando dinamicamente dati
da altri database

Request for document : Funzione che permette di mandare a tutti gli autori di uno
specifico prodotto una richiesta per il documento stesso, nel caso non sia presente o non
sia accessibile.

Statistiche sui download degli allegati: esiste un plugin denominato irstats che permette di
eseguire statistiche sui download generali, per dipartimento, per autore e addirittura sul
singolo prodotto.

Sviluppo di tool per la gestione, ad esempio per monitorare le Request for document o per
tenere traccia su database delle nuove importazioni e degli aggiornamenti

Link da e verso la rubrica e i sistemi dipartimentali per la presentazione degli elenchi delle
pubblicazioni
16
Il futuro
Future implementazioni di eprints
Nel breve/medio periodo saranno presenti le seguenti nuove funzionalità :

Implementazione di una FAQ per coprire le domande più frequenti

Migrazione alla versione 3.3.6, che prevede dei miglioramenti sensibili relativi
all’indicizzazione e alle ricerche

Valutazione dell’handler verso il database oracle

Messa in produzione delle statistiche sui download generali e, in un secondo momento,
quelle relative ai singoli autori, dipartimenti e documenti, annegate nelle relative pagine

Popolamento dei dati relativi all’indice delle citazioni di web of science, implementando
una top citation list e una vista per indice di citazione

Import delle tesi di dottorato degli ultimi 10 anni e inserimento di UGOV (con conseguente
pubblicazione su porto) nel flusso di consegna delle nuove tesi

Arricchimento della pagina di statistiche sui prodotti

Collegamento con il futuro «portale della ricerca», che presenterà i dati relativi agli
operatori, ai gruppi della ricerca, ai progetti e ai collaboratori esterni
17