Sommario
Il webinar di approfondimento relativo a questa parte è disponibile alla pagina Video Tutorial e Webinar.
ATTENZIONE! Se ad uno step di validazione non è associato un permesso di workflow o non è associato alcun utente, allora tale step viene saltato. Ciò significa che IR in fase di invio al workflow NON bloccherà l'item in quello step ma lo farà proseguire allo step successivo. Esempio: Un docente procede all'invio di una pubblicazione. Il sistema cerca se c'è un utente che possiede il permesso "profilo dipartimentale - validatori step one" (normalmente concesso al team step one). Se nessuno è presente fa andare la validazione in step 2. Il sistema quindi cerca se c'è un utente col profilo "step two": se anche qui nessuno è presente, l'item verrà mandato in step 3. Come sopra, se nessuno è presente nello step 3, la pubblicazione passa allo stato definitivo. È quindi importante, per gli atenei che prevedono la validazione, di controllare che i team: abbiano personale abbiano associato il relativo "permesso" (profilo). Se ciò non avviene tale pubblicazione "salterà" quello step. |
Quando l’inserimento di un prodotto nell’Institutional Repository viene completato da un docente, l’item è inviato al workflow di validazione per il controllo di qualità dei dati e idoneità alla pubblicazione sul portale pubblico.
In base alle scelte dell’Istituzione che installa IRIS, si possono presentare scenari differenti.
La validazione può essere INATTIVA o ATTIVA e, se attiva, il relativo workflow deve essere configurato attraverso la User Interface.
La visibilità pubblica è invece configurata attraverso due parametri applicativi su file di configurazione:
La tabella seguente riporta il risultato in termini di visibilità sul portale pubblico in base al valore dei parametri, considerando il caso di validazione INATTIVA.
IR_Valid_Item=notvisible | IR_Valid_Item= disclaimer | IR_Valid_Item=visible | |
IR_Valid_Bitstream=novalidate | Il prodotto non è visibile (né metadati, né fulltext) | Caso DEFAULT: i metadati sono visibili con disclaimer, il fulltext non è visibile | I metadati sono visibili, il fultext no |
IR_Valid_Bitstream=validate | Non applicabile | Metadati e fulltext visibili con disclaime | Metadati e fulltext visibili pubblicamente |
Validazione ATTIVA: configurazione del workflow di validazione attraverso la UI
DSpace consente di attivare fino a tre step di validazione in successione (v. figura sotto):
La norma di IRIS-IR è l'uso del solo step 2.
Procedimento di configurazione mediante interfaccia amministrativa IRIS:
1) aprire la pagina con l'Albero delle tipologie: Menu di sinistra Configurazione -> Prodotti -> Albero delle tipologie
2) accedere alla Home Page di una collezione (ad esempio: “Articolo in rivista”)
3) selezionare Modifica
4) selezionare Crea del passo scelto (ad esempio scegliendo lo step di tipo 2: “Accetta/Rifiuta/Modifica metadati Passo”)
5) premere il tasto Seleziona gruppi: si apre una finestra pop-up che presenta i gruppi disponibili. Qui si deve scegliere il gruppo ROLE_OA_WORKFLOW (v. figura sotto) per delegare la gestione del gruppo di validazione a RM e agli opportuni contesti. Inoltre a questo livello si può fare una eventuale configurazione dei team, tenendo presente che di default i superutenti di contesto e gli amministratori sono i validatori.
| Dalla versione di IRIS 4.3.0.26 l'attivazione di un passo di workflow non porta più alla form per l'inserimento delle persone e dei gruppi, in quanto i validatori sono quelli inseriti nei team e il ROLE_OA_WORKFLOW è inserito automaticamente. |
6) nella stessa schermata, premere su Aggiorna gruppo per salvare le modifiche effettuate.
Questa procedura di configurazione deve essere effettuata per ogni tipologia presente nel Repository, per la quale si definiscono così quali sono gli step attivi (1, 2, 3).
Gli operatori che potranno effettuare l'operazione saranno coloro che dispongono del permesso di esecuzione del workflow step specifico (1, 2, 3) su uno o più dei contesti di riferimento del prodotto. Ricordiamo che i contesti di riferimento di un prodotto sono calcolati nel seguente modo:
- si tiene conto di tutti gli autori interni riconosciuti (tralasciando gli autoriconoscimenti ed escludendo anche il responsabile del dato, a meno che non sia un autore interno)
- per ogni autore si considera l'ultima carriera nota ai fini della ricerca (priorità in caso di rapporti di lavoro multipli)
--> il prodotto appartiene automaticamente a tutti i contesti Dipartimentali, SSD, custom così trovati.
Il contesto "custom" può essere utilizzato per implementare logiche specifiche. Ad oggi, abbiamo due implementazioni "standard" disponibili:
- IDAB: serve per coprire la casistica del contesto IDAB Ugov (su base individuale ogni autore viene assegnato ad un contesto quale la biblioteca di riferimento, etc.)
- Tipologia: il contesto è incentrato sulla tipologia del catalogo, in questo modo si possono abilitare specifici uffici solo per alcune tipologie (es. ufficio dottorati / tesi di dottorato, ufficio brevetti / brevetti) - questa è la soluzione attiva per Statale di Milano e Bicocca
La documentazione DSpace relativa al workflow di validazione è accessibile al seguente link:
https://wiki.duraspace.org/display/DSDOC4x/Functional+Overview#FunctionalOverview-WorkflowSteps
(ma Cineca non supporta "Configurable Workflow", una funzionalità della XMLUI).
La figura seguente schematizza il workflow di validazione implementato in IRIS:
Normalmente in U-GOV finché un prodotto è in stato PROVVISORIO può essere modificato solo dal proprietario del dato, dal superutente di contesto o dall’amministratore.
Se invece il parametro SHARED è attivo, allora anche tutti gli autori riconosciuti di un prodotto sono abilitati alla modifica (non occorre il cambio di proprietario del dato).
Diversamente in IRIS per modificare un prodotto è necessario comunque prenderlo in carico (cambio di proprietario del dato). Inoltre tutti gli autori riconosciuti di un prodotto possono sempre prenderselo in carico (analogamente al comportamento con SHARED abilitato in U-GOV).
In U-GOV se il parametro FREEZE è abilitato (default) si può modificare un prodotto in stato DEFINITIVO solo:
Se invece il parametro FREEZE è disabilitato allora è sempre possibile modificare i prodotti anche se sono in stato DEFINITIVO (proprietario del dato, superutente di contesto e amministratore). |
In IRIS è prevista una funzionalità adhoc per la modifica da parte degli autori interni di prodotti definitivi denominata modifica/integra. Tale funzionalità attiva di default ma disattivabile consente la riapertura dei prodotti in stato DEFINITIVO, l'ateneo può definire in input form quali metadati non debbano essere modificabili con tale funzionalità.
La modifica diretta dei prodotti è configurata sulla base dei permessi di sicurezza ed è di default consentita agli amministratori di sistema e di contesto e agli eventuali validatori. Non è prevista al momento una gestione specifica della casistica "in corso di stampa".
E' inoltre disponibile la funzionalità di riapertura di un prodotto di default disponibile per gli amministratori di sistema e di contesto (ma modificabile tramite gestione permessi) che consente di rinviare il prodotto in stato bozza con possibilità di modifca completa da parte del responsabile del dato.
Il passaggio da PROVVISORIO a DEFINITIVO schedula automaticamente il prodotto per la sincronizzazione con il Sito Docente LoginMIUR.
A differenza di quanto avveniva in U-GOV (elaborazione della coda ogni 10 minuti) in IRIS l’invio al MIUR dei prodotti da aggiornare avviene tipicamente una volta al giorno (h 23.30). La frequenza di esecuzione è modificabile dalla consulenza Cineca tuttavia in IRIS è sempre possibile forzare un aggiornamento puntuale per ogni singolo prodotto che avviene in maniera sincrona.
In U-GOV se FL_VALIDA_PRODOTTI è disattivato, allora il workflow finisce qui.
Se invece FL_VALIDA_PRODOTTI è attivo allora i prodotti in stato DEFINITIVO entrano nel workflow della validazione e passano in stato DA VALIDARE.
A questo punto ogni prodotto viene VALIDATO o RESPINTO da parte dell’amministratore o dal superutente di contesto.
Se un prodotto viene riaperto il workflow ricomincia da capo (anche in IRIS).
In U-GOV se il parametro FL_BLOCCA_RIAPERTURA_VALIDATI è attivo solo l’amministrazione può riaprire un prodotto VALIDATO.
In IRIS il workflow di validazione è definibile a livello di tipologia (Collection) ma non per dipartimento.
In IRIS l’invio al MIUR e la disseminazione (OAI e portale pubblico) avvengono quando un prodotto viene reso DEFINITIVO (e non necessariamente VALIDATO) con la possibilità di aggiungere una nota che esplicita la mancata validazione. Questo comportamento è modificabile posticipando la disseminazione dopo la validazione o prevendendo la pubblicazione automatica senza disclaimer.
La visibilità dei documenti fulltext (allegati) è gestita separatamente dai metadati dei prodotti, ed ogni ateneo può decidere se rendere i fulltext immediatamente visibili nella scheda del prodotto sul portale pubblico secondo le policy di accesso decisa dal submitter o richiedere una approvazione del fulltext e della policy scelta da parte degli operatori del repository. Nel portale interno i fulltext sono tipicamente visibili immediatamente nella scheda del prodotto questo sempre in accordo alla policy di accesso decisa dal submitter (anche questo comportamento può essere configurato agendo sui permessi in riferimento ai contesti di riferimento del prodotto).
Al termine del ciclo di workflow la pubblicazione viene rischedulata per la sincronizzazione con il Sito Docente LoginMIUR ed il tipo di disseminazione può essere impostata puntualmente dagli operatori rendendo il prodotto visibile, non visibile o visibile con un disclaimer sul portale pubblico.
È possibile modificare i prodotti in stato DEFINITIVO senza alterare la data di chiusura.