Skip to end of metadata
Go to start of metadata

Sommario


Il file Excel input-forms.xls

Il file Excel input-forms.xls viene utilizzato per produrre file di configurazione XML per il software IRIS tramite strumenti automatici.

La descrizione del set di pagine mediante le quali i ricercatori inseriscono i metadati relativi al prodotto della ricerca è chiamata “form” (benché di fatto sia un insieme di form, nel significato HTML del termine). Un form è identificato da un unico nome simbolico (ad esempio, nel nostro caso, Articolo in rivista, Contributo in volume, e così via), ma nella struttura XML esso si divide in una serie di “pagine”, ciascuna della quali rappresenta una precisa pagina web per la raccolta dei metadati. A sua volta, l’elemento pagina contiene una sequenza di elementi “campo”, ciascuno dei quali definisce una finestra dialogo interattivo (un’area di testo, una data, una tendina di valori fissi, eccetera) con cui il ricercatore inserisce ogni metadato di tipo Dublin Core.

Per customizzare le pagine di inserimento dati, l’istituzione che installa IRIS deve esplicitare tutte le proprie scelte mediante un file avente struttura predeterminata, appunto il file input-forms.xls.

IRIS può contenere più di una versione di input-form e ogni versione può essere attiva o inattiva. Lo stato della singola input form è gestibile dalla funzionalità di Attivazione input form che si può trovare seguendo questo percorso nei menu:

Configurazione > Prodotti > Attivazione input-form

Le nuove submission utilizzano sempre la versione attiva più recente di una submission (NB: se una submission viene interrotta e ripresa successivamente, potrebbe accadere che nel tempo intercorso sia stata caricata una nuova versione dell'input form).

Se la versione dell' input form con cui è stato creato il prodotto è ancora attiva, si continuerà a far riferimento a quella versione per la descrizione del prodotto, ma se invece quella versione è stata disattivata allora il sistema aggiornerà il prodotto alla nuova versione segnalando gli eventuali metadati non più utilizzabili e dando la possibilità di cambiare tipologia di prodotto prima della conversione (utile nei casi in cui una nuova versione di input form sia stata introdotta dopo aver "spezzato" una input form preesistente in più sotto-tipologie).

Le tre opzioni presenti al caricamento (dal menu a sinistra: Configurazione > Prodotti > Caricamento input form):

  1. attiva la nuova versione caricata e disattiva le precedenti
  2. non attivare la nuova versione

consentono quindi di gestire i possibili scenari complessivamente per tutte le input form che si caricano via Excel senza dover poi utilizzare singolarmente la funzionalità di attivazione/disattivazione.

L'opzione 3 di non attivare la input form è prevista principalmente per futuri sviluppi: si vuole infatti rendere possibile in una futura versione il test delle nuove input form agli amministratori prima della loro attivazione. Al momento potrebbe essere utilizzata per caricare nel sistema una nuova input form e condividerla con i colleghi tramite la piattaforma, oppure valutare tramite le funzionalità di check (Prodotti > Tools di manutenzione > Check ...) l'impatto che avrebbe sul pregresso.

Guida alla compilazione del file Excel

Al fine della corretta generazione dei file di configurazione, e per ridurre i tempi di messa in servizio di richieste di modifiche a queste configurazioni, devono essere seguite le seguenti indicazioni:

  • Il foglio Excel si compone di fogli distinti, i cui nomi NON devono essere alterati

  • NON deve essere utilizzata bordatura, l’unica evidenziazione eventualmente ammessa è con colori di sfondo ed esclusivamente su righe in uso (non inserire righe vuote)

  • NON devono essere valorizzate celle nei fogli ad eccezione di quelle esplicitamente citate in questa guida; eventuali commenti ed informazioni aggiuntive vanno inserite in nuovi fogli (in posizione successiva a quelli predefiniti) e segnalate esplicitamente ai tecnici CINECA

Il form-definition descrive i template di submission/validazione disponibili per il sistema. Ciascun template definisce i metadati per una specifica tipologia di documento (es. articolo su rivista, intervento a convegno, contributo in libro, monografia, ecc.).

Le uniche celle da utilizzare rientrano nelle colonne A:K.

Tutte le informazioni devono essere inserite sequenzialmente nell’ordine corretto, NON devono essere presenti righe vuote. Ogni template va configurato interamente prima di passare alla definizione di un nuovo template. I metadati vanno inseriti nell’ordine in cui si desidera che siano presentati all’utente nelle pagine di inserimento/validazione, rispettando l’ordine di paginazione.

La colonna A (form_name) contiene il nome del template. Deve essere mantenuto costante per tutta la definizione del template. Le richieste di utilizzo di un determinato template per una specifica collezione devono far riferimento a tale nome.

La colonna B (page) contiene il numero di pagina in cui il metadato sarà richiesto. I numeri di pagina devono essere inseriti sequenzialmente senza salti a partire dal valore 1.

La colonna C (element) contiene l’element Dublin Core del metadato. Si richiede l’utilizzo di metadati in accordo a quanto definito dallo standard: http://dublincore.org. Una guida in lingua italiana è disponibile all'indirizzo: http://www.aepic.it/dublincore.php. NON è possibile utilizzare i caratteri _ (underscore) e . (punto).

La colonna D (qualifier) contiene il qualifier Dublin Core del metadato, se necessario. Oltre a qualifier "standard" possono essere definiti qualifier "custom" (personalizzati). Si consiglia di mantenere il più possibile quelli proposti per non incorrere in costi di personalizzazione delle procedure che vi fanno riferimento (ad es. la generazione automatica di citazioni). NON è possibile utilizzare i caratteri _ (underscore) e . (punto).

La colonna E (input-type) definisce la modalità di immissione per il metadato. I valori ammessi sono:

  • ance: per inserire la rivista o serie mediante collegamento con il database ANCE

  • onebox: un singolo box per l’immissione di testo libero

  • twobox: utilizzabile solo per metadati ripetibili, consente la definizione di due valori in una sola riga html

  • textarea: box multilinea per l’immissione di testo libero

  • name: box multipla per l’inserimento di nomi di persone che saranno poi memorizzate nel db nella forma “Cognome, Nome”

  • year: per inserire il solo anno tramite menù a tendina con autocomplete e gestione della casisitica "in corso di stampa". Il range di anni proposti, iniziale e finale in funzione dell'anno corrente (+0, +1, +2. etc.) possono essere configurati dalla consulenza mediante parametri applicativi

  • year_noinprint: analoga alla modalità "year", con la sola differenza che non prevede la scelta dell'opzione "in corso di stampa". Questa modalità può essere utile laddove sia richiesto il censimento dei soli prodotti pubblicati, o per tipologie per i quali il caso "in corso di stampa" non ha senso, come ad esempio i brevetti.  

  • date: box multipla per la selezione di una data. Nel caso il metadato sia definito obbligatorio è sufficiente l’indicazione del solo anno

  • fulldate: granularità giornaliera inserimento via calendario javascript

  • dropdown: menù a discesa con valori predefiniti, per la cui definizione si veda la colonna F

  • list: checkbox o radio (in base alla definizione di ripetibilità) con una lista di opzioni predefinita per la cui definizione si veda colonna F

  • qualdrop_value: combinazione di un dropdown per la definizione del qualifier specifico del metadato e di una box a testo libero per l’immissione del valore. La Colonna CD deve essere lasciata vuota. Per la definizione della lista di qualifier utilizzabili si veda la colonna F

  • qualdrop_text: combinazione di un dropdown per la definizione del qualifier specifico del metadato e di una text area a testo libero per l’immissione del valore.  La D deve essere lasciata vuota. Per la definizione della lista di qualifier utilizzabili si veda la colonna F

  • sharepriority: utilizzabile solo per metadati ripetibili, box multilinea per l’inserimento facilitato di persone multiple. Il tool permette di identificare i singoli nominativi suddividendoli in campi controlled_name e ricoscendone l’eventuale afferenza all’istituzione. È possibile richiedere alla consulenza l'attivazione per tale modalità di inserimento di una percentuale di attribuzione di responsabilità per i singoli nomi e/o la valorizzazione esplicita della rilevanza (Corresponding author, primo autore, ultimo autore, etc). Il sistema esegue dei controlli per verificare che la percentuale abbia un totale di 100% e che l’ordinamento sia coerente con i valori inseriti nella box (ripetizioni, mancanze, ecc.).

  • default_value: (solo per gli archivi che abbiano richiesto specifici sviluppi) valore automatico non modificabile generato secondo logica specifica concordata con il cliente. Attualmente il default value valorizza il metadato dc.type.miur con il codice della tipologia Miur su cui è mappato la tipologia di pubblicazione in ugov (esempio: articolo in rivista deve prevedere un default value per dc.type.miur con valore 262). Questo differisce dalla precedente versione di Ugov che per questa operazione prevedeva una interfaccia specifica.


La colonna F (list name) deve essere valorizzata solo se come modalità di immissione (colonna E) si è scelta una delle seguenti: dropdown, list, qualdrop_value o qualdrop_text, nei quali casi occorre inserire il nome assegnato al set di valori ammessi nel foglio form-value-pairs.

La colonna G (repeatable) contiene un valore True/False ad indicare la ripetibilità o meno del metadato.

La colonna H (scope) contiene l’ambito di utilizzo del metadato. I possibili valori sono:

  • cella vuota: campo utilizzabile in lettura/scrittura sia durante la submission che durante il workflow di verifica;

  • sub hidden: il campo non è presente durante la fase di submission. Utilizzabile per semplificare il processo di self-archiving riservando la compilazione di alcuni metadati agli operatori  durante la fase di verifica;

  • sub readonly: il campo è presente durante la fase di submission in sola lettura;

  • work hidden: il campo non è presente durante la fase di verifica dei metadati. Utilizzabile per esempio per rendere anonima la submission in fase di verifica;

  • work readonly: il campo è presente durante la fase di verifica dei metadati in sola lettura;

  • readonly: il campo è presente in sola lettura sia durante la submission che durante la verifica dei metadati. Utile in presenza di campi pre-valorizzati da procedure automatiche;

  • hidden: il campo non è utilizzato nelle form di submission. Utilizzabile per definire la visibilità del campo nella scheda breve dell’item;

  • no update: N.B. Per fare in modo che i campi non siano poi più modificabili dagli utenti quando portano il prodotto in stato DEFINITIVO, il valore dare allo "scope" è "no update".

La colonna I (label) contiene la label mostrata all’utente nei form di submission/validazione dei metadati. Se il metadato è definito obbligatorio il sistema inserirà automaticamente un * prima della label specificata. Se il metadato è definito in colonna E come default_value, il contenuto di questa colonna verrà utilizzato per la valorizzazione del metadato. Inserendo il testo fra due segnaposto @@ si potrà indicare la generazione tramite uno degli algoritmi disponibili (ad esempio, per il metadato dc.identifier.citation, si deve compilare la label come ‘@@citation@@’).

Il valore di questo campo non viene utilizzato come label nella scheda breve di presentazione dell’item. Per la definizione di tale label occorre agire sulle configurazioni e utilizzare la funzionalità di gestione dell’i18n.

La colonna J (required) contiene il messaggio di errore da mostrare in caso di mancata valorizzazione del metadato. La cella vuota implica la non obbligatorietà del campo.

La colonna K (hint) contiene una mini guida per la compilazione del metadato che sarà mostrata all’utente subito sopra la box di immissione del metadato stesso. Può contenere tag HTML.

 

Attenzione nel caso l'ambito di utilizzo venga limitato non è possibile definire il campo come obbligatorio

 


Il foglio Form-value-pairs

Nel foglio Form-value-pairs vengono descritti i set di valori disponibili per i metadati con modalità di immissione dropdown, list, qualdrop_value o controlled_name (si veda Colonna E). Le colonne devono essere valorizzate da sinistra verso destra senza lasciare colonne vuote.

Ogni set di valori occupa due colonne adiacenti: nella prima cella della prima colonna (ad esempio A:1) viene definito il nome del set di dati (si veda Colonna F), nella prima cella della seconda colonna (ad esempio B:1) andrebbe  riportato il qualifier del primo metadato che utilizza tale set.

A partire dalla seconda riga vengono quindi inseriti i valori ammissibili inserendo nella prima colonna (ad esempio A:2) il valore visualizzato dall’utente e nella seconda colonna (ad esempio B:2) il valore che sarà effettivamente salvato nel database  in caso di selezione di tale opzione.

L’assenza di valore in una data riga per entrambe le colonne che definiscono il set determinano la fine dei valori ammissibili per quel dato set. Non vanno quindi lasciate “righe vuote” all’interno della definizione di un set.

Tutti i valori utilizzati per il salvataggio sul database (seconda colonna) devono essere univoci nella relativa lista. Inserire voci duplicate anche se in posizioni differenti nella stessa colonna NON è consentito.


Definizione delle tipologie di file

Nel foglio value-pairs è anche possibile definire la la lista delle tipologie di file accettabili (dataset, preprint, versione editore, etc.) a tal fine è necessario definire una lista denominata

type_file (applicata come default a tutti i template)

con la possibilità di specificare una lista differente per un dato template definendo una lista denominata

type_file_<alias template> (ad esempio type_file_Articolo su rivista / type_file_thesis).

In caso di assenza di una configurazione specifica per il template in uso e della configurazione relativa alla lista di default il metadato "type" relativo al singolo file non sarà richiesto in fase di upload.

Altre configurazioni: scheda breve e scheda completa

Per la definizione di quali metadati mostrare nella scheda breve e scheda completa dell’item occorre accedere alla UI di configurazione tramite il menu di sinistra:

Configurazione > Prodotti > Layout schede

e definire, per ogni tipologia di scheda prodotto, gli attributi della scheda breve (o completa).

N.B.: è possibile modificare l’ordinamento dei campi scelti (quelli per cui è stata selezionata la checkbox “Mostra”) tramite drag&drop, come nella figura qui sotto.



Le etichette mostrate in visualizzazione della scheda dell'item sono modificabili utilizzando la funzionalità di gestione dell'internazionalizzazione/etichette . In particolare le chiavi avranno la forma

metadata.<schema>,<element>[.<qualifier>]

ad esempio quindi metadata.dc.title per il Titolo.

È anche possibile personalizzare una label quando relativa ad una specifica input form utilizzando la chiave

metadata.<style>.<schema>,<element>[.<qualifier>]

dove style segue la seguente sintassi simple|full.<ID della tipologia di inputform>.

Funzionamento "edit batch" dei metadati DSpace (operazioni massive)

È possibile utilizzare la funzionalità "operazioni massive" (Menu Prodotti -> Tool di manutenzione -> Operazioni massive) per effettuare l'aggiornamento di uno o più metadati.
Per costruire il file che deve essere caricato nel sistema, le operazioni da eseguire sono le seguenti:

  1. Entrare nell’Albero delle tipologie (Menu Configurazione -> Prodotti -> Albero delle tipologie) e cliccare su Export Metadata, che si trova nel box degli Strumenti di amministrazione (si veda l'esempio della figura seguente, dove sono stati cerchiati in rosso i tasti a cui ci si riferisce)



  2. Il file csv che si scarica contiene un item per ogni riga, mentre i metadati sono le colonne

  3. eliminare tutte le righe di item che non devono essere modificati

  4. eliminare TUTTE le colonne dei metadati che non devono essere modificate, TRANNE "id" e "collection"

N.B. Attualmente le operazioni massive non sono associate a un evento, non generano una snapshot nella history e se vengono modificati i metadati associati agli autori si perde la rilevanza (ossia l'ordinamento degli autori per una pubblicazione).


Possono essere aggiunti venti elementi per volta. Quindi, ad esempio, se si deve intervenire su settanta pubblicazioni sarà necessario creare tre file con 20 items e un file con gli ultimi 10.
È necessario che il file sia in formato CSV e la struttura dati sia composta da id/collection/metadata secondo questo schema:
colonna id: id dell'item
colonna collection: id della collezione
colonna dc.language.iso[it]: valore "eng", "ita" o qualsiasi altra lingua

FileEsempioOperazioniMassive.csv

 

N.B. Sconsigliamo di provare a effettuare un export dei metadata di collezioni con molti item (ad esempio Articolo su periodico) perché l'operazione potrebbe essere pesante per la quantità di oggetti contenuti.
La cancellazione fisica e logica prevista dalla funzionalità DSpace non sono attualmente supportate in IRIS e potrebbero generare errori applicativi, poiché in IRIS la cancellazione è gestita in una maniera più articolata. Il supporto per la cancellazione sarà ripristinato nella versione 4.4.0.0

I dettagli di questa funzionalità sono descritti al seguente link: https://wiki.duraspace.org/display/DSDOC4x/Batch+Metadata+Editing

 

 

  • No labels