Archive for the ‘Uncategorized’ Category

Flusso di lavoro

Wednesday, June 6th, 2012

1.     Preparazione tecnica e fase di test

a)       Firma della lettera di adesione al servizio MD.

NB: Il servizio NBN è attivo solo in associazione al deposito delle tesi di dottorato.

b)      Institutional Repository: installazione plug-in NBN

Il responsabile dell’archivio aderente a Magazzini Digitali riceverà le informazioni necessarie per l’installazione del plug-in NBN e le specifiche di installazione dello stesso sul sistema.

Il plug-in NBN è stato sviluppato allo scopo di ampliare le funzionalità del software di deposito dell’Intitutional Repository (EPrints o DSpace), permettendo la gestione della comunicazione  con il Registro Centrale NBN.

Esso permetterà al responsabile dell’Institutional  Repository di inviare richiesta di NBN per un documento specifico, durante la fase di validazione dei metadati dello stesso.

c)       Intitutional Repository: fase di test del sistema

Il responsabile dell’IR potrà testare il corretto funzionamento dell’installazione di prova del repository software, integrato con il plug-in NBN, utilizzando le credenziali di accesso al Registro Centrale NBN (fornite contestualmente all’installazione del plug-in NBN)

Il database del Registro Centrale prevede uno account di test che sarà periodicamente svuotato.

2. Fine test e passaggio su produzione

La fase di entrata in produzione prevede alcuni passi di comunicazione tra il responsabile dell’archivio e gli amministratori del servizio, durante i quali verranno eseguite procedure di autenticazione e registrazione offline.

a)      Intitutional Repository: invio comunicazione di entrata in produzione del plug-in NBN e dei parametri per l’autenticazione

Invio agli amministratori del servizio NBN della comunicazione di entrata in produzione del plug-in. Oltre a tale comunicazione, il responsabile del IR, dovrà inviare i dati di autenticazione richiesti mediante i quali sarà abilitato ad accedere al servizio NBN definitivo.

I parametri necessari sono username, password, IP della macchina di accesso e baseURL del repository.

Il servizio NBN prevede la possibilità di abilitare, su specifica richiesta del responsabile dell’archivio, più punti di accesso al sistema di generazione con parametri di autenticazione diversi su stesso subnamespace.

b)      Registro Centrale NBN: verifica, registrazione ed abilitazione dei parametri di accesso e assegnazione subnamespace

Mediante procedura offline verranno effettuate verifiche di validità dei dati comunicati ed attivato l’accesso per user, pass ed IP.

Verrà inoltre assegnato un subnamespace univoco, il quale sarà associato a tutti gli identificatori NBN richiesti dalla istituzione relativa.

Entro 48 ore, il responsabile dell’archivio riceverà conferma di avvenuta registrazione e comunicazione del subnamespace ufficiale.

c)       Standard di generazione degli identificativi NBN

Gli identificatori NBN che verranno generati seguiranno la specifica RFC 3188:

URN:NBN:<ISO 3166 country code>:<sub-namespace code>-<assigned NBN string>

Dove <sub-namespace code> corrisponde al codice assegnato all’istituzione e <assigned NBN string> è un numero incrementale UNIVOCO completamente opaco rispetto alla risorsa a cui viene assegnato, alla data del suo deposito o al puntatore alla rappresentazione di tale risorsa sull’IR di origine.

3. Entrata in vigore del servizio

a)      Nuove adesioni a MD: assegnazione identificativo NBN a tutte le risorse già presenti nel repository

Al fine di ottimizzare la fase di allineamento di NBN con MD è necessario seguire la seguente procedura:

1) A seguito di conferma di avvenuta abilitazione all’utilizzo del servizio, il responsabile dell’archivio dovrà assicurarsi di allineare le risorse già presenti nel deposito PRIMA di procedere alla richiesta di NBN per i nuovi depositi.

2) Quando tutti i record presenti nell’archivio avranno un NBN associato, il repository potrà entrare nello scheduler di harvesting di MD.

3) MD harvesterà in modo massivo le risorse che a questo punto avranno già l’NBN tra i metadati, consentendo così al registro NBN di allineare lo stato degli stessi in modo efficace.

b)      IR già aderenti a MD: Allineamento delle risorse per le istituzioni che hanno già aderito alla sperimentazione della procedura di deposito legale delle tesi in formato digitale via harvesting automatico

Le istituzioni che hanno aderito alla sperimentazione della procedura di deposito legale, hanno già messo a disposizione le tesi in formato digitale per l’harvesting automatico di Magazzini Digitali.

Per tali risorse il servizio NBN si interfaccerà con il Deposito Legale e genererà un NBN per ogni risorsa già harvestata.

Le risorse già harvestate durante la sperimentazione avranno così un identificativo NBN associato sia al puntatore alla rappresentazione della risorsa sull’IR che a quello su Magazzini Digitali.

Il responsabile dell’archivio dovrà provvedere all’allineamento delle risorse presenti nel Repository con gli identificativi ad esse assegnati. Per ottenere tale allineamento è sufficiente effetture una richiesta di un nuovo  NBN per ognuno dei record presenti nell’archivio e già harvestati da Magazzini Digitali.

c)       Andamento a regime

Durante la fase di validazione dei metadati sull’IR, il responsabile dell’archivio può effettuare richiesta di identificativo NBN per una risorsa.

L’identificativo viene creato ed associato all’interno del Registro Centrale al puntatore alla rappresentazione della risorsa sull’IR.

A seguito dell’harvest periodico da parte di Magazzini Digitali, verrà inviata una mail al responsabile dell’archivio con allegato un file in formato .xml (e relativo .xsl per la visualizzazione) contenente l’elenco delle URI delle tesi depositate e la relativa impronta digitale.

Il Registro Centrale NBN prevede un riallineamento giornaliero con i record del Deposito Legale. Quindi, entro 24 ore dalla ricezione della mail di avvenuto harvest, agli identificativi NBN verranno associati anche i puntatori alle rappresentazioni delle risorse su MD.

 

 

Documentazione

Wednesday, June 6th, 2012

NBN service API per Intitutional Repository

L’utilizzo della API è aperto a tutti i repository delle istituzioni associate a Magazzini Digitali.

Prima di essere abilitati all’utilizzo della API deve essere inoltrata richiesta di abilitazione di un account di accesso al servizio NBN.

La documentazione di seguito è destinata ad a scopo tecnico e richiede una conoscenza di base di programmazione e del protocollo HTTP.

 

1. Note generali

Sicurezza

Le richieste al servizio possono essere eseguite solo a seguito di autenticazione mediante Authentication Digest.

Endpoint

L’API è implementata in RESTful style e l’end point utilizzato è:

http://nbn.depositolegale.it

Accesso al servizio:

La URI http://nbn.depositolegale.it/api/nbn_generator.pl accetta richiesta con metodo HTTP POST.

La URI http://nbn.depositolegale.it/{nbn}, dove {nbn} è un NBN, restituisce la risorsa.

Content Type

Per il metodo POST è richiesto un header addizionale, il quale specifichi la comunicazione di parametri in formato JSON

Content-Type:application/json; charset:UTF-8

Standard di generazione degli identificativi NBN

Gli identificatori NBN verranno generati, seguendo la specifica RFC 3188, con la seguente sinatssi:

URN:NBN:<ISO 3166 country code>:<sub-namespace code>-<assigned NBN string>

Dove <sub-namespace code> corrisponde al codice assegnato all’istituzione e <assigned NBN string> è un numero incrementale UNIVOCO completamente opaco rispetto alla risorsa a cui viene assegnato, alla data del suo deposito o al puntatore alla rappresentazione di tale risorsa sull’IR di origine.

 

2. Sicurezza

Tutte le richieste a questo sistema richiedono un header con HTTP Digest Authentication.  Username e password di accesso saranno quelli forniti a seguito dell’adesione a Magazzini Digitali e della registrazione al servizio NBN.

L’utilizzo dell’account istituzionale comporta:

-          L’autorizzazione a generare NBN solo con il sub-namespace code specificatamente assegnato

-          La possibilità di generare giornalmente un numero di identificativi non limitato

 

3. NBN API GET

URI: http://nbn.depositolegale.it/{nbn} dove {nbn} è un NBN specifico.

La richiesta ritorna una URL con i dati riepilogativi relative allo specifico NBN e i link alle rappresentazioni delle risorse sull’IR e, se presenti su MD

Request headers

none

Request body

empty

Response headers

none

Response body

Se il response status è 200, la pagina di risposta conterrà i dati relativi all’NBN,

altrimenti verrà visualizzato un non-200 status con relativa breve spiegazione.

 

4. NBN API POST

URI: http://nbn.depositolegale.it/api/nbn_generator.pl

Il POST genererà un nuovo NBN, se la risorsa URL associate non è già presente all’interno del sistema come già associata ad un identificativo.

 

Request headers

Content-Type:application-json

Request body

-          Parametri obbligatori:

action=nbn_create

url={url}

dove {url} deve essere sostituita con la URL puntatore alla rappresentazione della risorsa presente nel repository.

-          Parametri opzionali:

metadataurl={metadataurl}

dove {metadataurl} deve essere sostituita con la URL puntatore ai metadati descrittivi della risorsa presenti nel repository.

 

Response headers

Content-Type:application-json

Response body

Se la richiesta è andata a buon fine, viene restituita una stringa JSON contenente breve spiegazione dello status code ( es. created, url already exists.. ) ed identificativo NBN (indicato nella tabella di seguito nel campo {nbn} ).

Nel caso in cui la richiesta avvenga per una nuova risorsa il response header status avrà valore “201 Created”.

Response header status Response JSON body parameters
201 Created status = 201, created nbn = {nbn}  

 

Nell’eventualità in cui la URL per la quale è stato richiesto l’identificativo sia già presente all’interno del Registro Centrale, verrà restituito l’NBN già associato.

Il response header status avrà valore “400 Bad Request”.

Tale procedura è ottimizzata per evitare duplicazioni delle risorse nel RC e per gestire eventuali riallineamenti delle informazioni all’interno degli IR.

Response header status Response JSON body parameters
400 Bad Request status = url already exists nbn = {nbn}

 

Gestione dell’errore

Gli errori di risposta ai POST sono comunicati mediante response header statuses del protocollo HTTP.

Le informazioni addizionali riguardo alla tipologia dell’errore sono incluse nel body della return call, formattati in una stinga JSON. Di seguito i possibili errori e le cause associate.

Response header status Response body  Errore
400 Bad Request status = 400 Bad request, wrong action.   Errore nel campo obbigatorio action del request body
400 Bad Request status = 400 Bad Request, not valid url Il contenuto del campo obbligatorio url del request body non rispetta lo standard corretto di sintassi per le URL
401 Unauthorized status = 401 Unauthorized, wrong username   I parametri di autorizzazione non sono validi per l’accesso al sistema
500 Internal Server Error status = 500 Internal Server Error, failed tansaction.   Transazione fallita, ritentare successivamente e, se il problema persiste, contattare l’amministratore.

 

 

 

 

Resolve a NBN

Wednesday, June 6th, 2012

 

La sinatssi degli identificatori NBN, del tipo URN:NBN:<ISO 3166 country code>:<sub-namespace code>-<assigned NBN string> segue la specifica RFC 3188, secondo la quale:
  • <sub-namespace code> corrisponde al codice assegnato all’istituzione
  • <assigned NBN string> è un numero incrementale UNIVOCO completamente opaco rispetto alla risorsa a cui viene assegnato, alla data del suo deposito o al puntatore alla rappresentazione di tale risorsa sull’IR di origine.

 

Flusso di lavoro per la firma della Convenzione e della Licenza

Thursday, May 10th, 2012

1. Preparazione Tecnica

Scambio di mail tra editore e sperimentazioneatdepositolegaledotit con l’obiettivo di definire tecnicamente le modalità di deposito e definire nel dettaglio l’oggetto di deposito.

Responsabilità:

  • Magazzini Digitali (coordinati tra di loro via mail)
  • Editore

2. Firma della convenzione

Si intende per avvenuta a seguito:

  1. Dell’invio via mail da parte dell’editore della Convenzione e del contratto di Licenza compilato all’indirizzo sperimentazioneatdepositolegaledotit
  2. Della pubblicazione sul sito http://www.depositolegale.it da parte di Magazzini Digitali del nome dell’editore aderente accompagnato dalle impronte SHA-1 dei due documenti inviati e della contestuale comunicazione via mail da parte di Magazzini Digitali all’editore dell’avvenuta pubblicazione sul sito

Note:

  • In conformità a quanto previsto dal CAD (Codice Amministrazione Digitale) si è ritenuto di non prevedere passaggi cartacei
  • L’impronta digitale SHA-1 pubblicata e inviata via mail all’editore garantisce che i documenti inviati (Convenzione e Licenza) non hanno subito nel tempo modifiche
  • L’Allegato 1 di cui parla la Convenzione è da intendersi Allegato A (così come è intestata la Licenza)
  • Convenzione e Licenza in formato digitale saranno archiviati e conservati nel tempo da Magazzini digitali
  • Tutto lo scambio di mail di sperimentazioneatdepositolegaledotit sarà archiviato da Magazzini Digitali e disponibile alle istituzioni coinvolte (compresa la DGBID)

Responsabilità:

  • Editore
  • Magazzini Digitali (coordinati tra di loro via mail)

Prime indicazioni tecniche per la sperimentazione del deposito legale delle pubblicazioni digitali in rete

Wednesday, December 21st, 2011

Per partire con la sperimentazione sono offerte inizialmente due modalità:

  • 1. raccolta automatica (o harvesting) delle pubblicazioni da parte di MD a partire da un repository che espone i metadati attraverso il protocollo OAI-PMH;
  • 2. invio telematico delle risorse a MD effettuato direttamente dal depositant

1. Raccolta automatica

Per la raccolta automatica verrà messa a disposizione una procedura analoga a quella prevista per le tesi di dottorato

2. Invio telematico

Per rendere la sperimentazione applicabile in tempi brevi Magazzini Digitali ha deciso di adottare il formato di aggregazione BagIt
In pratica i file da inviare a Magazzini Digitali dovranno essere aggregati in un unico file (zip o tar) rispettando alcune semplici regole previste dal formato BagIt. Per facilitare il trattamento da parte di Magazzini Digitali è richiesto inoltre che i file che veicolano la pubblicazione da depositare siano accompagnati anche dai relativi metadati descritttivi. L’abbinamento tra dati e metadati avviene con una semplice convenzione di denominazione dei nomi di file: il nome del file che contiene i metadati avrà lo stesso nome del file contenente i dati con l’aggiunta finale dell’estensione .metadata Anche se i metadati sono in molti casi inclusi nel file di dati (ad esempio perché previsto dal formato) si ritiene importante che i metadati descrittivi di base siano sempre evidenziati in un file autonomo. La sintassi dei metadati dovrà essere in formato XML. Sono accettati i formati più diffusi come per esempio DC,ONYX, MAG, DIDL, MARC21XML (scrivere a Magazzini Digitali per il supporto di altri formati) L’invio del BagIt avviene al momento esclusivamente tramite posta elettronica all’indirizzo bagitatdepositolegaledotit. Effettuati i controlli di validità Magazzini digitali invierà una “ricevuta di ritorno” contenente il manifest del BagIt. La pagina che segue presenta un esempio di BagIt

Un_Bagit_pronto_per_essere_inviato 
|
| manifest-md5.txt
| (49afbd86a1ca9f34b677a3f09655eae9 data/Via_con_il_vento.pdf ) 
| (408ad21d50cef31da4df6d9ed81b01a7 data/Via_con_il_vento.pdf.metadata)
| …. altri file inviati (md5 data/ …)
|
| bagit.txt
| (BagIt-version: 0.96 )
| (Tag-File-Character-Encoding: UTF-8 )
|
--- data/
|
| Via_con_il_vento.pdf [1]
| (... byte del contenuto .. 
|
| Via_con_il_vento.pdf.metadata [2]
| (... byte del contenuto …. ) 
| 
| altre sequenze di file_a.estensione_b, file_a.estensione_b.metadata [3]

[1] Sono accettati formati standard e non protetti da DRM (per esempio PDF/A, EPUB). I formati saranno validati da validatori quali Jhove Droid ecc . E’ richiesto almeno un file per considerare valido il file Bagit ai fini del deposito

[2] Medatati in formato XML (per esempio DC,ONYX, MAG, DIDL, MARC21XML) Anche se i metadati possono essere inclusi nel file di dati [1] si ritiene importante che i metadati descrittivi di base siano sempre evidenziati in un file autonomo. I metadati verranno messi in relazione con i dati tramite la convenzionale aggiunta del .metadata al nome di file contenenti i dati: file_a.estensione_b (contiene i dati) file_a.estensione_b.metadata (contiene i metadati del file_a.estensione_b)

E’ richiesto almeno un file di metadati che rispetti la nomenclatura convenzionale (aggiunta di .metadata al nome del file che contiene i dati) per considerare valido il Bagit ai fini del deposito

[3] Nota: BagIt non prevede limiti di grandezza del file. Visto tuttavia che – almeno nelle prime fasi della sperimentazione – l’invio verrà effettuato tramite posta elettronica non vanno superati i limiti di 25 Megabyte per invio (limite del nostro sistema di posta elettronica)

Si segnala qui una raccolta di tools open source per la produzione di un file BagIt

Ricevuta di avvenuto deposito

Wednesday, October 26th, 2011

Come notifica della corretta cattura dei dati viene inviata una mail al contatto riportato nell’identificazione del repository OAI-PMH.

La corretta esposizione di tale indirizzo mail si può controllare con un browser visitando la url del proprio repository

http://repository/cgi/oai2?verb=Identify

Per richiedere l’invio in copia ad ulteriori destinari si prega di inviare una mail ad oaiatdepositolegaledotit

La mail inviata conterrà in attachment un file xml e un file di stile xsl. Salvando entrambi i file nella stessa directory sarà possibile aprire il file xml con un comune browser e visualizzarne l’output in forma tabellare per una lettura più comoda e veloce.

La struttura del file xml e’ la seguente:

<?xml version="1.0" ?>
<?xml-stylesheet type="text/xsl" href="style.xsl" ?>
<harvest data="DATA-DELLA-CATTURA">
  <item id="ITEM-IDENTIFIER">
    <component>
      <url> URL </url>
      <sha1> CHECKSUM SHA1 BASE32 </sha1>
      <http_code> RISPOSTA HTTP (200=OK 302=REDIRECT 404=NOT FOUND) </http_code>
      <mimetype> MIMETYPE </mimetype>
    </component>
  </item>
</harvest>

Esempio di ricevuta di una tesi (Item) composta da due oggetti (Components): la pagina html di presentazione (jump off page) e la risorsa pdf

<?xml version="1.0" ?>
<?xml-stylesheet type="text/xsl" href="style.xsl" ?>
<harvest data="28092010">
  <item id="oai:amsdottorato.cib.unibo.it:1618">
    <component>
      <url>http://amsdottorato.cib.unibo.it/1618/</url>
      <sha1>U6NTYF7ISBVHMNN3O7ALOQ6Z7YS4QCUH</sha1>
      <http_code>0</http_code>
      <mimetype>text/html</mimetype>
    </component>
    <component>
      <url>http://amsdottorato.cib.unibo.it/1618/1/Lovece_Stefania_tesi.pdf</url>
      <sha1>GQ7GCFTWYAIFCA6KNSBEOPWL6T6XQYUH</sha1>
      <http_code>200</http_code>
      <mimetype>application/pdf</mimetype>
    </component>
</harvest>

CHECKSUM SHA1 BASE32

Si e’ scelto l’utilizzo di tale algoritmo per una maggiore robustezza rispetto al piu’ utilizzato MD5.

Per generare e controllare la validita’ del checksum SHA1 BASE32 si possono usare i seguenti programmi

WINDOWS: FSUMFE

http://fsumfe.sourceforge.net/

Utilizzare il programma come spiegato nella screenshot di seguito

Linux / OSX

Un semplice script per generare il checksum SHA1 in BASE32 per ambienti Linux/OSX e’ il seguente. Richiede un interprete Ruby 1.8 e la gem ‘base32′

$ gem install base32

editare sha1-base32.rb

#!/usr/bin/env ruby
require 'rubygems'
require 'base32'
require 'sha1'
d = SHA1.new
d << File.read(ARGV[0])
puts Base32.encode(d.digest)

eseguire ./sha1-base.rb NOMEFILE

$  ./sha1-base32.rb NOMEFILE.pdf

Tesi di dottorato in embargo

Monday, September 5th, 2011

Tesi embargate

Nel caso di tesi sottoposte ad embargo i metadati vengono normalmente pubblicati via oai-pmh, mentre l’accesso al fulltext (file pdf) e’ possibile solo previa autenticazione con user e password da una pagina web del repository.


Abilitazione all’accesso degli harvester

L’harvester, il software che si occupa della cattura degli oggetti web, non e’ configurabile per effettuare in automatico l’autenticazione, motivo per cui bisogna abilitare all’accesso completo senza password soltanto i server delle Biblioteche Nazionali Centrali da cui viene eseguito il processo di cattura.

Gli indirizzi IP da abilitare alla cattura sono i seguenti:

193.206.206.150 – 193.206.206.151BNCF
193.206.215.11BNCR

Di seguito le istruzioni per l’abilitazione di repository funzionanti con Dspace o Eprints:

Dspace

Si faccia riferimento al capitolo Step per la creazione delle policy di accesso nel manuale redatto dal CILEA

Documentazione Harvesting BNCF

Eprints

Modificare il file ARCHIVE/cfg/cfg.d/security.pl col seguente codice di esempio:

    my ($oncampus, @depositolegale, $power_ip);
    $oncampus = 0;
    @depositolegale = ('193.206.206.150','193.206.206.151', '193.206.215.11');
    foreach $power_ip (@depositolegale) {
      if ($ip eq $power_ip) {
        $oncampus = 1;
      }
    }
    return ( "ALLOW" ) if ( $status eq "archive" &amp;&amp; $oncampus );

Metadati

I diritti di accesso esposti in dc:rights dovranno essere conformi alle voci del vocabolario controllato info:eu-repo

Fare riferimento alle linee guida dei progetti DRIVER e OPENAIRE:

Esempi:

dc:rights

info:eu-repo/semantics/openAccess

info:eu-repo/semantics/closedAccess

info:eu-repo/semantics/embargoedAccess

info:eu-repo/semantics/restrictedAccess

dc:date

info:eu-repo/date/embargoEnd/2011-05-12

Tesi di dottorato

Wednesday, October 27th, 2010

Deposito legale digitale delle tesi di dottorato di ricerca

Le Biblioteche Nazionali Centrali di Firenze e di Roma, nell’ambito del progetto Magazzini Digitali della Fondazione Rinascimento Digitale e in collaborazione con il gruppo di lavoro Open Access della CRUI, hanno realizzato e testato un servizio di raccolta automatica (harvesting) dei dati e dei metadati delle tesi di dottorato di ricerca ai fini del deposito legale, così come previsto dalla Circolare MiUR n. 1746 del 20 luglio 2007.

Il servizio di raccolta automatica (harvesting) consente a tutte le Università italiane che raccolgono le tesi di dottorato in formato digitale in un archivio aperto, secondo le raccomandazioni contenute nelle Linee guida per il deposito delle tesi di dottorato negli archivi aperti approvate dalla CRUI, di ottemperare agli obblighi di legge (senza ricorrere all’invio di documentazione cartacea).

La raccolta automatica dei dati e dei metadati delle tesi di dottorato da parte delle Biblioteche Nazionali consente un miglioramento dei servizi documentali e bibliografici riducendo i tempi di catalogazione e aumentando la visibilità delle tesi rendendo i record disponibili attraverso il Servizio Bibliotecario Nazionale.

Le tesi oggetto di embargo, per ottemperare agli obblighi di legge, verranno comunque raccolte. Secondo la normativa vigente in materia di dottorato, esse saranno consultabili nei locali delle Biblioteche Nazionali su PC privi di periferiche dopo il trattamento biblioteconomico in SBN.



Standard

Formato dei file

Il formato raccomandato per il file delle tesi di dottorato è preferibilmente il PDF/A. Sono in ogni caso accettati formati aperti .

Protocollo di scambio di metadati

Le università che intendono usufruire del servizio di deposito legale via harvesting automatico devono esporre i dati e i metadati relativi alle tesi di dottorato attraverso il protocollo OAI-PMH implementato dai principali applicativi software per la gestione di open archives, molti dei quali sono open source.

Formato dei metadati

Il formato dei metadati, obbligatorio, supportato dalle procedure di harvesting di depositolegale.it e’ MPEG21-DIDL.

La scelta di tale formato e’ dettata dalla necessita’ di poter identificare risorse digitali (tesi) composte da più file.

MPEG21 DIDL permette di identificare con precisione i componenti (didl:Component) della risorsa (didl:Item) e la cosiddetta JOP (jump off page), url della pagina web che riporta informazioni sulla risorsa utili alla consultazione mediante un browser.

L’uso del solo Dublin Core (oai_dc) permette di identificare, attraverso dc:identifier, solo la jump off page, senza ulteriori informazioni sui componenti.

In casi di eccezione, quali l’utilizzo di software autoprodotti o non supportanti DIDL, l’harvesting puo’ essere effettuato usando oai_dc esclusivamente se le tesi sono composte da un solo file riportato in dc:identifier .

Qui di seguito vengono date alcune indicazioni per l’esposizione dei metadati strutturale in formato MPEG21DIDL per gli applicativi EPrints e DSpace

Configurazione di EPrints 3

GNU EPrints 3 offre un sistema di plugin per la gestione dell’esposizione dei record via OAI. In particolare sono presenti una serie di moduli che implementano l’esportazione dei dati e la mappatura dal dataset interno al’applicativo verso i formati standard.

NOTA: le istruzioni che seguono sono pensate per un’installazione standard di GNU EPrints su un server con sistema operativo UNIX-like (Linux, Solaris, etc.). Qualsiasi riferimento alle cartelle di installazione è relativo alla cartella di installazione del software.

I plugin di esportazione in GNU EPrints si trovano nella cartella perl_lib/EPrints/Plugin/Export In particolare l’esposizione in DIDL viene implementata di default dal modulo perl DIDL.pm A sua volta il modulo DIDL.pm richiama il modulo DC.pm, dedicato alla mappatura dei metadati descrittivi in Dublin Core

Eprints abilita di default DIDL, verificare nel file archives/NOMEARCHIVIO/cfg/cfg.d/oai.pl

$oai->{v2}->{output_plugins} = { 
 "didl" => "DIDL", 
};

A causa di un errore presente nei sorgenti di Eprints (versioni 3.0 e 3.1), è necessario modificare manualmente nei file perl_lib/EPrints/Plugin/Export/DIDL.pm il nome errato del tag “Descriptior” col corretto “Descriptor”

  54: my $d1 = $plugin->{session}->make_element( "didl:Descriptior" );
  68: my $d2 = $plugin->{session}->make_element( "didl:Descriptior" );
  82: my $d3 = $plugin->{session}->make_element( "didl:Descriptior" );

Configurazione di DSPACE 1.5

Il DIDL Crosswalk può essere attivato come di seguito:

  • Decommentare oai.didl.maxresponse in config/dspace.cfg
  • Decommentare la riga DIDL Crosswalk (Crosswalks.didl=org.dspace.app.oai.DIDLCrosswalk ) nel file config/templates/oaicat.properties
  • Eseguire bin/install-configs
  • Riavviare Tomcat
  • Verificare l’attivazione del crosswalk all’ URL http://mydspace/dspace-oai/request?verb=ListRecords&metadataPrefix=didl

Per una guida completa alla configurazione di Dspace si faccia riferimento al seguente manuale redatto dal CILEA: Documentazione Harvesting BNCF

Uso di oai_dc

Per rendere possibile l’interoperabilità sintattica e semantica è necessario utilizzare il seguente schema di metadati relativi alle tesi di dottorato definito secondo lo schema base del Dublin Core (DC):

DatasetDublin CoreNote
titleDC:titleTitolo della tesi
creatorDC:creatorAutore dell’opera (nel formato cognome, nome); non obbligatorio, ma raccomandato è l’indicazione dell’anno di nascita dell’Autore inserito con la seguente sintassi cognome, nome <anno>
descriptionDC:descriptionabstract (meglio se in inglese)
languageDc:languagelingua (nel formato ISO639-1)
identifierDC:identifierURL a cui raggiungere il full-text della tesi o a una pagina intermedia
typeDC:typeTipologia di materiale, da impostare di default come Doctoral Thesis è importante per il recupero dei dati usare la forma inglese
contributorDC:contributornome del tutor (nella forma cognome, nome)
dateDC:dateData di discussione della tesi (min. Anno)
publisherDC:publishernome dell’università (è importante perché l’università di provenienza rende esplicito il valore della tesi)
formatDC:formatopzionale (mime type, size)
subjectsDC:subjectSettore Scientifico Disciplinare MIUR
rightsDC:rightsVa espresso secondo il vocabolario info:eu-repo. Maggiori dettagli alla pagina sulle tesi in embargo

OAI identifier univoco

I record esposti via oai-pmh devono avere un identifier univoco, comunemente legato alla base URL del repository.

Eprints nella configurazione standard espone i record oai con l’identifier “generic.eprints.org”. Per configurarlo, editare il file archives/NOMEARCHIVIO/cfg/cfg.d/oai.pl e modificare il seguente valore:

46: $oai->{v2}->{archive_id} = "generic.eprints.org"

Dspace automaticamente genera l’OAI identifier ricavandolo dalla base url di installazione.


La Procedura

Si invitano le Università che intendono usufruire del servizio di deposito legale mediante raccolta automatica a confermare la loro disponibilità con una comunicazione scritta al Direttore della Biblioteca Nazionale Centrale di Firenze e al Direttore della Biblioteca Nazionale Centrale di Roma. In allegato un modello di lettera alle Biblioteche.

Frequenza della procedura di raccolta automatica

La raccolta automatica (harvesting) dei dati e dei metadati delle tesi di dottorato avviene una volta al mese in modo incrementale.

Come fare per attivare la procedura di raccolta automatica

Per attivare la procedura è sufficiente utilizzare l’applicazione sul sito http://register-oai.depositolegale.it o in alternativa inviare una mail a oai@depositolegale.it.

Vi verranno inviate ulteriori istruzioni per consentire la raccolta delle tesi soggette ad embargo, che verranno ammesse alla sola consultazione attraverso PC privi di periferiche presso le Biblioteche Nazionali Centrali.

Evidenza dell’avvenuto deposito

Come evidenza dell’avvenuto deposito le Biblioteche Nazionali Centrali invieranno una mail al responsabile dell’archivio con allegato un file in formato .xml (e relativo .xsl per la visualizzazione) contenente l’elenco delle URI delle tesi depositate e la relativa impronta digitale in formato SHA-1 base32.

Istruzioni per la lettura della ricevuta xml.


La Sperimentazione

Alla sperimentazione della procedura di deposito legale delle tesi in formato digitale via harvesting automatico hanno partecipato l’Alma Mater Studiorum – Università di Bologna, l’Università Federico II di Napoli e l’Università di Trieste. Hanno contribuito alla definizione delle specifiche tecniche l’Alma Mater Studiorum – Università di Bologna per il software EPrints e l’Università di Trieste per il software DSpace.
Hanno successivamente aderito alla sperimentazione la LUISS, l’Università di Parma, l’Università Cattolica di Milano, l’Università degli Studi di Milano-Bicocca.

Alla redazione di questo documento hanno contribuito le Università coinvolte nella sperimentazione. Si prega di inviare osservazioni e commenti a redazione@depositolegale.it.

Versione 1 del 12 ottobre 2010