Identificazione del progetto¶

Nome del progetto ⓘ: nome del progetto ed eventuale acronimo.

Codice progetto ⓓ: al progetto può essere assegnato un identificatore univoco, in modo da riconoscere con precisione l’identità del progetto ed evitare possibili ambiguità.

Obiettivi del progetto ⓘ: descrizione sintetica degli obiettivi che il progetto intende raggiungere, evidenziando la coerenza con quanto previsto dal PND.

Ruoli e responsabilità ⓘ¶

Responsabilità del progetto ⓘ: indicazione dei nominativi delle persone che rivestono i vari ruoli definiti (responsabile del progetto, responsabile della banca dati, responsabile tecnico della banca dati, responsabile tematico della banca dati, responsabile open data, digital data curator).

Ulteriori ruoli di gestione dei dati ⓘ: indicazione dei nominativi degli ulteriori ruoli e responsabilità previsti nella gestione dei dati e metadati del progetto. In relazione alle varie fasi in cui si articola il progetto, può inoltre essere utile descrivere le responsabilità dei vari ruoli in maniera sintetica tramite una matrice cosiddetta “RACI”, come segue:

• Responsible (R): coloro che lavorano per eseguire un determinato compito. Esiste almeno un ruolo di responsabile.
• Accountable (A): il solo che può approvare il corretto completamento di un compito e che delega il lavoro ai responsabili. Può esistere un solo ruolo accountable per uno specifico compito.
• Consulted (C): coloro che possono essere consultati in quanto esperti di dominio e con i quali instaurare una comunicazione bidirezionale.
• Informed (I): coloro che devono essere tenuti aggiornati sui progressi del processo, spesso al termine dello stesso.

La Tabella 1 riporta un esempio di possibile matrice RACI. In generale, le responsabilità assegnate varieranno a seconda delle specificità del progetto.

Tab. 1 – Esempio di matrice dei ruoli e responsabilità (RACI)

Produzione e raccolta dei dati ⓘ¶

In questa sezione è opportuno descrivere le modalità di produzione e raccolta dei dati in relazione agli obiettivi del progetto. In particolare, occorre descrivere dettagliatamente in che modo i dati vengono raccolti/prodotti all’origine, chi è responsabile della raccolta o della produzione, se la raccolta/produzione avviene in maniera automatica o manuale.

In caso di produzione automatica dei dati, sarebbe rilevante esplicitare quali strumenti software vengono utilizzati per questa attività e se e in che modo i dati vengono trasformati dopo la raccolta. Nel caso vengano trasformati, quali strumenti software vengono adottati. Per ulteriori informazioni, fare riferimento al capitolo «Il progetto di digitalizzazione, Come» delle Linee guida per la digitalizzazione del patrimonio culturale e alle Linee guida per l’acquisizione, la circolazione e il riuso delle riproduzioni dei beni culturali in ambiente digitale .

Tipologie e formati di dati ⓘ¶

È opportuno che il DMP descriva tutte le tipologie di dati prodotti/raccolti nel progetto, e per ogni tipologia il formato in cui sono raccolti i dati, facendo riferimento al capitolo Formati delle Linee guida per la digitalizzazione del patrimonio culturale e alle linee guida AgID sui formati aperti per i dati e i documenti [7]. L’uso dei formati consigliati dalle linee guida garantisce la migliore esecuzione del processo di digitalizzazione e della valorizzazione del bene. Inoltre, buona pratica per la conservazione a lungo termine di progetti di digitalizzazione, è la generazione di file master (lossless e non compresso) e di uno o più file derivati.

Origine dei dati ⓘ¶

Un aspetto che va sicuramente monitorato e tracciato è l’origine dei dati che ci si trova a trattare. Affinché possano essere documentate la conoscenza delle origini e gli eventuali spostamenti dei dati, è importante indicare chi ha originariamente prodotto i dati e in che modo, quando e dove sono stati prodotti i dati, e se si tratta di dati nuovi o già esistenti. Inoltre, se si tratta di dati esistenti, è opportuno indicarne la provenienza e descriverne le modalità di migrazione (sezione 7.2.5).

Tipologia di beni ⓘ¶

Per ciò che riguarda un progetto di digitalizzazione, la precisazione della tipologia dei beni a cui si riferiscono gli oggetti digitali può essere di supporto alla documentazione e a una successiva verifica. In particolare, è utile descrivere nel dettaglio tutte le tipologie di beni a cui si riferiscono i dati e per ogni tipologia indicare la quantità di beni oggetto di digitalizzazione, l’intervallo temporale e il luogo geografico di origine dei beni. Queste informazioni potranno essere utili anche a fini statistici e di ricerca.

Migrazione di dati esistenti ⓘ¶

Nel caso di migrazione o conversione di dati esistenti, è opportuno indicare nel DMP le tipologie di migrazione e conversione e i metodi utilizzati, verificando se ci siano incongruenze tra il vecchio e il nuovo formato, e controllando che non siano più utilizzati formati obsoleti. A corredo di queste informazioni va inoltre affiancata una descrizione dei vari passaggi della migrazione e della conversione, con particolare riferimento alla pulizia dei dati, alla preparazione e rimozione di informazioni duplicate per garantire l’integrità dei dati, alla qualità e alla sicurezza dei dati. In questo modo, sarà possibile tenere traccia delle procedure seguite ed eventualmente ripeterle in caso di necessità. Inoltre, nel DMP è opportuno indicare quali strumenti software vengono utilizzati per compiere queste operazioni e descrivere l’archivio dei file sorgenti.

Quantità di dati prevista ⓘ¶

È importante stimare fin dall’inizio del progetto la quantità di dati che si prevede di raccogliere, o almeno il loro ordine di grandezza. In base alla quantità di dati indicata, potranno essere previsti diversi profili di configurazione, con riferimento anche al conferimento alla costituenda infrastruttura nazionale dei dati del patrimonio culturale (cfr. par. Infrastruttura nazionale dei dati del patrimonio culturale del PND).

Livello di metadatazione ⓘ¶

Le linee guida AgID prevedono quattro possibili livelli di metadatazione [8], come descritto nella Fig. 1. Si consiglia di adottare il livello più alto che è tecnicamente possibile implementare. Il primo livello non include metadati, ed è quindi fortemente sconsigliato. Il secondo e il terzo livello hanno esclusivamente metadati associati al dataset, mentre il quarto livello prevede metadati associati internamente al dato stesso.

Figura 1 – Livelli di metadatazione

(fonte:https://docs.italia.it/italia/daf/lg-patrimonio-pubblico/it/stabile/_images/Metadati.png)

Metodologie per la metadatazione ⓘ¶

Nel DMP sono descritte le metodologie di metadatazione, specificando in che modo vengono prodotti i metadati e chi ne è responsabile. Per ulteriori informazioni si rimanda a quanto contenuto nelle Linee guida per la digitalizzazione del patrimonio culturale e ai regolamenti o prassi in vigore nella comunità scientifica di riferimento.

Standard di metadatazione ⓘ ⓒ¶

Il risultato delle precedenti tappe del modello operativo si traduce nella produzione di metadati che certificano le caratteristiche del dato. Come detto precedentemente, la metadatazione, sia dei singoli dati che degli interi dataset, è cruciale: una delle problematiche più diffuse relative ai dati del MiC è la molteplicità di copie disponibili di una stessa informazione, senza che sussista la necessaria certezza sulle caratteristiche e sulla validazione di ciascun rilascio.

Nel DMP è opportuno descrivere tutti gli standard di riferimento che sono stati adottati per la metadatazione. Inoltre, un altro elemento significativo potrebbe essere la descrizione dei formati di codifica che sono stati utilizzati, facendo riferimento al capitolo 3 delle Linee guida per la digitalizzazione del patrimonio culturale. In particolare, per i metadati è opportuno seguire lo standard XML/METS (Metadata Encoding and Transmission Standard), che codifica i metadati descrittivi, amministrativi, tecnici e strutturali riguardanti le risorse digitali.

Analisi della qualità dei dati ⓘ ⓓ¶

Secondo la norma ISO 9000:2015, la qualità è la totalità degli elementi e delle caratteristiche di un prodotto o servizio che concorrono alla capacità dello stesso di soddisfare esigenze espresse o implicite. Le misure per quantificare la qualità dei dati sono individuate dallo standard ISO/IEC 25012:2008, divenuto norma italiana UNI ISO/IEC 25012:2014, che definisce un insieme di 15 caratteristiche specifiche per la caratterizzazione della qualità dei dati: accuratezza, attualità, coerenza, completezza, credibilità, accessibilità, comprensibilità, conformità, efficienza, precisione, riservatezza, tracciabilità, disponibilità, portabilità e ripristinabilità. L’ISO/IEC 25024 estende l’ISO/IEC 25012 definendo 63 misure di qualità applicabili alle caratteristiche di qualità dei dati.

Le caratteristiche più rilevanti ai fini della redazione del DMP sono quattro: accuratezza, coerenza, completezza e attualità. La Determinazione Commissariale dell’Agenzia per l’Italia Digitale n. 68/2013 riporta una tabella con un insieme esemplificativo di misure, con riferimento allo standard ISO, a supporto delle attività di valutazione della qualità dei dati delle amministrazioni [9]. Nel DMP è opportuno descrivere le modalità di analisi della qualità dei dati adottate nel progetto, e, in particolare, quale standard è stato adottato per valutare la qualità dei dati; quali misure di qualità dei dati sono in uso e per ogni misura, in che modo viene eseguita la misurazione. In caso di tipologie di dati multiple, queste informazioni devono essere riportate per ogni specifica tipologia.

Bonifica dei dati ⓘ¶

Generalmente l’analisi della qualità del dato può richiedere una fase di bonifica: i dati all’interno dei sistemi informativi o degli archivi di un’amministrazione possono talvolta essere “sporchi” e non rispondenti ai requisiti di qualità previsti dagli standard adottati nel progetto. La bonifica può essere basata sui dati oppure basata sui processi. Nel primo caso, il dataset viene corretto tramite un confronto con il mondo reale (anche con attività economicamente onerose come contattare direttamente i soggetti preposti alla gestione della base dati) e/o tramite un confronto incrociato (matching) con altri dataset.

La bonifica basata sui processi invece analizza le cause che hanno portato alla scarsa qualità del dato e rivede i processi di produzione del dato per garantirne la qualità nel tempo. Per esempio, se si riscontra che la scarsa accuratezza di una base di dati deriva da un processo di inserimento dati manuale, si può intervenire sulla fase di acquisizione introducendo metodi per minimizzare la possibilità di errori. La bonifica basata sui processi ha dunque il consistente vantaggio di essere una strategia risolutiva. Nel DMP è opportuno descrivere le attività di bonifica dei dati previste nel progetto, e in particolare:

• quali sono le attività oggetto di bonifica (es. inserimento dati)
• se la bonifica è basata sui dati oppure sui processi
• in caso di bonifica basata sui dati, quali sono le modalità di bonifica e quali sono i dataset di riferimento per la bonifica
• in caso di bonifica basata sui processi, quali interventi sono previsti per minimizzare gli errori
• quali software sono utilizzati per la bonifica

In caso di tipologie di dati multiple, queste informazioni devono essere riportate per ogni specifica tipologia.

Nomenclatura degli oggetti digitali ⓘ ⓒ¶

Le convenzioni per nominare i file sono importanti per descrivere ciò che contengono e come si relazionano ad altri file. Lo sviluppo di una struttura è fatto attraverso l’identificazione degli elementi chiave del progetto, le differenze importanti e i punti in comune tra i file che l’istituto produce o gestisce. Questi elementi potrebbero includere aspetti come la data di creazione, il nome dell’autore, il nome del progetto, il nome di una sezione o una sottosezione del progetto, la versione del file, ecc. Un vantaggio nell’usare nomi di file unici e standardizzati è la capacità di seguire i nomi dei percorsi e collegarsi ad altri sistemi che richiedono nomi di file unici. Le indicazioni per la nomenclatura degli oggetti digitali sono riportate nel Capitolo Nomenclatura degli oggetti digitali delle Linee guida per la digitalizzazione del patrimonio culturale.

Nel DMP è opportuno descrivere la metodologia utilizzata per assegnare i nomi dei file, spiegando in che modo è implementata e quali software sono utilizzati per assegnare i nomi dei file. Inoltre, è importante indicare la modalità di costruzione del codice oggetto (che costituisce la parte variabile del nome) e la provenienza degli identificativi presenti nel codice oggetto (es. SBN). In caso di metodologie di nomenclatura multiple, sarà opportuno riportare queste informazioni per ogni specifica metodologia adottata.

Livello open data ⓘ¶

Le Linee guida AgID, che riprendono la definizione di Open Data del W3C [11], prevedono cinque possibili livelli di open data, come mostrato nella voce corrispondete delle FAQ.

Il MiC pubblicherà i dati in formato aperto almeno di livello 3* mirando, nel tempo, a pubblicare solo dati di livello a 4* e 5* (Linked Open Data). Si consiglia in ogni caso di adottare il livello più alto che è tecnicamente possibile implementare.

Nel DMP deve essere indicato se i dati saranno pubblicati in formato aperto e a che livello.

Identificatori ⓘ ⓓ¶

In caso di Open Data di livello 4* o 5*, è opportuno indicare nel DMP le metodologie adottate per la costruzione di URI (Uniform Resource Identifier) o IRI (Internationalized Resource Identifier) univoci e persistenti, facendo riferimento alle linee guida del W3C [12].

Nel DMP è importante descrivere in che modo vengono assegnati questi identificatori, come vengono costruiti e qual è il nome di dominio di riferimento.

Nel caso che il sistema locale adotti un modello “integrato” con l’infrastruttura dati nazionale (cfr. par. Pubblicazione dei dati ⓘ ⓓ del presente documento e par. Infrastruttura nazionale dei dati del patrimonio culturale del PND) gli URI verranno definiti nell’infrastruttura stessa; nel caso dell’adozione di un modello “federato” gli URI dovranno essere indicati dal singolo istituto.

Standard per gli open data ⓘ ⓒ¶

Un altro aspetto importante che va descritto nel DMP riguarda gli standard adottati per la produzione degli open data; va quindi registrato nel DMP quale versione è stata adottata di quale standard e per quale tipologia di dati viene utilizzato.

Ontologie e vocabolari di riferimento ⓘ ⓒ¶

Allo stesso modo, è opportuno documentare nel DMP le ontologie e vocabolari di riferimento adottati nel progetto, descrivendo le finalità per cui verranno utilizzati. Si raccomanda di modellare i dati sulla base dei vocabolari e delle ontologie di OntoPiA (cfr. voce specifica nelle FAQ allegate) in larga parte allineati a standard aperti del Web e disponibili in formati aperti standard sulla piattaforma https://github.com/italia/. Gli uffici del MiC, per il tramite degli Istituti centrali, sono incoraggiati ad avviare un processo di standardizzazione sia per la rappresentazione di dati ricorrenti, indipendenti dallo specifico dominio applicativo, come per esempio i dati sulle persone, sulle organizzazioni pubbliche e private, sui luoghi e gli indirizzi usando le ontologie di OntoPiA. In particolare, nel DMP andranno elencati le specifiche ontologie e vocabolari adottati, quale versione di ciascuno è stata utilizzata e per quale finalità. Nel caso si scegliesse di adottare ontologie o vocabolari non standard in alternativa a standard di dominio, è utile descrivere il perché di questa scelta. Inoltre, se nel corso del progetto vengono prodotti delle ontologie o dei vocabolari, è opportuno descriverli nel DMP, in modo da facilitarne il più possibile il riuso.

Framework e protocolli per l’interoperabilità delle risorse digitali: IIIF (International Image Interoperability Framework) ⓘ ⓒ¶

Per la gestione e la metadatazione delle immagini digitali, lo sviluppo di framework applicativi come il IIIF ha giocato un ruolo cruciale per l’adozione delle tecnologie proprie del Web e dei Linked Open Data per migliorare l’interoperabilità e il riuso delle immagini. Il IIIF consiste in un insieme di documenti che compongono il framework. La definizione di questo ambiente si concentra al momento su sei documenti di specifica per la creazione di API [13] destinate alla descrizione, manipolazione e presentazione delle immagini, al controllo degli accessi, e a meccanismi per la ricerca e diffusione delle stesse. Tutti i documenti di specifica riusano e/o adattano data model esistenti per rendere interoperabili i metadati descrittivi delle immagini seguendo il paradigma degli Linked Open Data, che includono il Web Annotation Data Model (http://w3.org/TR/annotation-model/) e Shared Canvas (https://iiif.io/api/model/shared-canvas/1.0/). Inoltre, esistono fornitori (https://iiif.io/get-started/vendors/) e software per la visualizzazione (https://iiif.io/get-started/iiif-viewers/), il salvataggio e l’esposizione (https://iiif.io/get-started/image-servers/) delle immagini secondo gli standard del IIIF.

Il progetto dovrebbe mettere almeno a disposizione delle API conformi alle specifiche Image API e Presentation API di IIIF. Tuttavia, l’implementazione di API conformi anche agli altri documenti di specifica è altamente consigliata per garantire la massima interoperabilità e riuso delle immagini, anche tra diversi progetti e istituti culturali.

Ci sono, inoltre, due possibili modalità di adozione del IIIF, che non si escludono a vicenda. La prima riguarda un ente che espone il proprio patrimonio di riproduzioni facsimilari usando IIIF. La seconda, invece, di progetti che riutilizzano i dati esposti da altri Istituti mediante gli standard di IIIF.

Importante è fornire indicazioni dell’identificatore persistente della risorsa e indicare il tracciato descrittivo dei beni digitali, delle proprietà utilizzate e valorizzate all’interno del file JsonLD, chiamato, nel framework, “manifest”. In questo contesto può essere esplicitata la provenienza, la proprietà dell’immagine e la relativa licenza d’uso (vedi Linee guida per l’acquisizione, la circolazione e il riuso delle riproduzioni dei beni culturali in ambiente digitale)

Licenze open data ⓘ ⓓ¶

La scelta di una licenza è indispensabile per determinare come poter riutilizzare il dataset. È quindi opportuno indicare nel DMP il nome e la versione delle licenze aperte adottate nel progetto, specificando a quali dati si applicano e fornendo anche un riferimento al testo completo della licenza (cfr. voce specifica nelle FAQ allegate).

Integrazione con altri dataset ⓘ¶

Uno dei principali vantaggi dell’adozione degli open data e dell’uso degli standard del Semantic Web è la facilità di integrazione o linking del dataset che viene prodotto con altri dataset già esistenti e che seguono i medesimi standard. Ciò costituisce un valore aggiunto per il progetto stesso, che potrà riutilizzare e integrare i dati prodotti in precedenza, e al tempo stesso facilita l’interoperabilità e il futuro riuso dei nuovi dati che vengono prodotti. Esistono oggi molteplici basi di conoscenza che sono facilmente integrabili con un nuovo dataset. Ciò può essere fatto riutilizzando direttamente gli URI esterni, oppure importando i dati (nel rispetto delle rispettive licenze), o ancora eseguendo un linking tramite il linguaggio OWL (proprietà owl:sameAs). Infine, può essere anche prevista la ripubblicazione diretta dei dati prodotti nel progetto in una base di conoscenza esistente, andando ad arricchirla. Sarebbe opportuno ai fini anche dell’interoperabilità se è prevista l’integrazione con dataset esistenti, e per ognuno di questi dataset, qual è la tipologia di integrazione (es. riuso, linking, pubblicazione nella base dati esistente). In caso di linking o riuso diretto di URI, è utile indicare quali sono le modalità con cui avviene il linking o riuso, e se si tratta di un riuso diretto, quali sono le modalità di importazione dei dati e in che modo è stata valutata la compatibilità delle licenze. Infine, in caso di pubblicazione dei dati prodotti nel progetto in una base di conoscenza esistente, è opportuno descrivere in che modo è prevista la pubblicazione e in che modo è stata valutata la compatibilità delle licenze.

Dati personali e consenso informato ⓘ¶

Il diritto alla protezione dei dati è sancito dalla Carta dei diritti fondamentali dell’UE e dal Trattato sul funzionamento dell’Unione europea, che rendono effettivo il diritto alla privacy delle persone fornendo loro il controllo sul modo in cui le informazioni che li riguardano vengono raccolte e utilizzate.

Le categorie di dati personali che meritano speciale protezione sotto il profilo della riservatezza sono definite dal Regolamento UE 2016/679 relativo alla protezione dei dati personali (GDPR). In particolare, i dataset pubblicati non devono contenere “dati personali che rivelino l’origine razziale o etnica, le opinioni politiche, le convinzioni religiose o filosofiche, o l’appartenenza sindacale, nonché trattare dati genetici, dati biometrici intesi a identificare in modo univoco una persona fisica, dati relativi alla salute o alla vita sessuale o all’orientamento sessuale della persona” (art. 9 del GDPR) e i “dati personali relativi alle condanne penali e ai reati o a connesse misure di sicurezza” (art. 10 del GDPR).

In questo paragrafo occorre dunque indicare:

• Se nel progetto verranno trattati dati personali, e se sì quali
• Chi è responsabile del trattamento dei dati personali
• Quali soggetti sono proprietari dei dati personali
• Se sono previste modalità di raccolta consenso informato, e se sì quali sono.

Diritto d’autore ⓘ¶

Il diritto d’autore in Italia è protetto dalla legge 22 aprile 1941 n. 633 (Protezione del diritto d’autore e di altri diritti connessi al suo esercizio), che descrive i diritti riconosciuti agli autori di un’opera, e quali sono le modalità di fruizione di tali diritti. La legge distingue il diritto morale, che è inalienabile e indipendente dall’utilizzazione economica dell’opera, dai diritti patrimoniali (pubblicazione, riproduzione, trascrizione, esecuzione e rappresentazione, comunicazione, distribuzione, modificazione, traduzione, noleggio e prestito), che sono invece rinunciabili e soggetti a un limite temporale. In Italia, la durata prevista per i diritti patrimoniali è, nella maggior parte dei casi, di 70 anni.

I diritti relativi alle banche dati, e i doveri a cui sono soggetti gli utenti delle stesse, son normati dagli articoli 102-bis e 102-ter della legge sul diritto d’autore, che prevedono una serie di vincoli e un diritto esclusivo sulla banca dati da parte del costitutore, che ha una durata di 15 anni.

In un progetto di digitalizzazione, è fondamentale tenere in considerazione tutti gli aspetti del diritto d’autore (o copyright) e assicurarsi di rispettare la legge, in particolare nel momento in cui viene adottata una specifica licenza, che deve pertanto essere compatibile con i diritti che l’istituto detiene.

In questo campo vanno descritti gli aspetti relativi al diritto d’autore che vanno affrontati nel progetto, e in particolare:

• Indicare se i beni oggetto di digitalizzazione sono attualmente protetti dal diritto d’autore o da altri diritti di natura patrimoniale
• Se sì, indicare le tipologie di beni e la durata dei relativi diritti
• Se sì, indicare come si prevede di garantire il rispetto di tali diritti
• Indicare se i dati prodotti o raccolti nel progetto sono protetti dal diritto d’autore o da altri diritti di natura patrimoniale
• Se sì, indicare come si prevede di garantire il rispetto di tali diritti
• Indicare se gli eventuali dataset riutilizzati nel progetto (di cui al paragrafo 7.5.6) sono protetti dal diritto d’autore o da altri diritti di natura patrimoniale
• Se sì, indicare come si prevede di garantire il rispetto di tali diritti.

Possibili fonti di bias ⓘ¶

Nella produzione, modellazione ed elaborazione dei dati è possibile che vengano introdotti bias, ovvero distorsioni che rendono i dati non rappresentativi della realtà, in particolare per quanto riguarda la rappresentazione delle minoranze e delle comunità marginalizzate. È opportuno che nella gestione di un progetto siano individuate tutte le possibili fonti di bias, e che si prevedano meccanismi per correggerli (oppure, ove non fosse possibile, contestualizzarli).

La pubblicazione di dataset contenenti bias corre infatti il rischio di perpetuare le diseguaglianze sociali, ad esempio quelle di genere [14], etnia, lingua, religione, orientamento sessuale. Nella rappresentazione di dati storici, è inoltre particolarmente frequente che esistano bias “per omissione”, ovvero che nel dataset siano state privilegiate talune categorie sociali rispetto ad altre al punto di rendere queste ultime invisibili [15].

Qualora i dati fossero stati elaborati tramite metodi di intelligenza artificiale (es. apprendimento automatico di conoscenza da testi o immagini), occorre considerare i limiti degli attuali sistemi di machine learning e valutare attentamente i possibili bias che ne derivano [16].

In questo paragrafo vanno descritti:

• I possibili bias derivanti dalla produzione e raccolta dei dati
• I possibili bias derivanti dal riuso di dati esistenti
• I possibili bias derivanti dai modelli utilizzati per rappresentare i dati
• I possibili bias derivanti dall’uso di sistemi di intelligenza artificiale
• Eventuali ulteriori tipologie di bias individuabili nel progetto
• Per ogni tipologia di cui sopra, le modalità con cui si prevede di farvi fronte

Archiviazione dei dati ⓘ¶

Nel DMP sono descritte le modalità con cui sono archiviati i dati del progetto. È sempre consigliabile archiviare i dati in repository istituzionali. Il MiC dispone di un Centro Elaborazione Dati (CED) che si occupa dei servizi di housing e hosting della maggior parte dei sistemi informativi, dei siti e dei portali del MiC. In coerenza con la Strategia per la crescita digitale del Paese e il Piano Triennale per l’informatica nella PA [17], AGID ha delineato una strategia Cloud [18] che prevede un percorso di qualificazione per i soggetti pubblici e privati che intendono fornire servizi cloud alla Pubblica amministrazione, affinché queste ultime possano adottare servizi e infrastrutture di cloud computing omogenei, che rispettino elevati standard di sicurezza, efficienza e affidabilità. Inoltre, più recentemente, il Dipartimento per la trasformazione digitale con l’Agenzia per la cybersicurezza nazionale ha elaborato la Strategia Cloud Italia [19] contenente gli indirizzi strategici per il percorso di migrazione verso il cloud di dati e servizi digitali della Pubblica Amministrazione.

Coerentemente con questi orientamenti, per garantire l’archiviazione e la preservazione nel tempo dei dati del patrimonio culturale, il Ministero nell’ambito dell’investimento M1C3 1.1 “Digital Strategy and Platforms for Cultural Heritage” del Piano Nazionale di Ripresa e Resilienza (PNRR) ha previsto di sviluppare un’infrastruttura (hardware e software) per la gestione delle risorse digitali e per l’orchestrazione di servizi e procedure, finalizzata alla raccolta, conservazione, organizzazione e distribuzione delle risorse digitali della cultura, in linea con le strategie europee e con le indicazioni del piano triennale dell’informatica nella PA. L’infrastruttura software (cfr. par. Infrastruttura nazionale dei dati del patrimonio culturale del PND) costituirà il nucleo centrale di una rete di sistemi, anche esterni, la cui interconnessione aggiunge valore ai diversi sistemi singolarmente considerati. Allo stesso modo l’infrastruttura consentirà l’interconnessione trasversale dei contenuti delle diverse collezioni digitali, superando la logica “a silos” o “ad aggregazione di silos”, che ha caratterizzato ad oggi la digitalizzazione delle collezioni digitali e la loro interconnessione. A questo scopo verranno integrate nell’infrastruttura le logiche più evolute del Web Semantico e del Web 2.0, ma anche le più promettenti tecnologie di intelligenza artificiale applicate alla multimedialità.

Si tratterà di un’infrastruttura aperta, congruente con le Linee guida per la digitalizzazione, adottando quanto verrà man mano stabilito nel PND. L’infrastruttura metterà a disposizione diversi strumenti di alimentazione del repository: le collezioni digitali che saranno contenute nel repository saranno esposte nella Digital Library della cultura, che ne costituirà il principale portale di accesso, ma anche di altri sistemi di accesso che intendano utilizzarne i servizi; si tratterà quindi di un repository aperto anche nella distribuzione delle collezioni digitali conservate, fatti salvi i vincoli sulla proprietà intellettuale.

È opportuno pertanto che gli Istituti, nella gestione dell’archiviazione dei dati del progetto tengano conto di quanto sopra descritto e si allineino alle indicazioni che verranno fornite dall’ICDP e dallo stesso MiC.

In relazione alle specifiche informazioni sull’archiviazione dei dati del progetto, è opportuno comunque definire:

• la localizzazione (fisica o virtuale) dei dataset
• le modalità di conferimento dei dataset
• le modalità di conservazione dei dataset
• il responsabile della gestione dei dataset.

Pubblicazione dei dati ⓘ ⓓ¶

Se l’istituto ha - o prevede di realizzare - un’interfaccia utente di fruizione delle informazioni (portale o sito web), in questa sezione è importante indicare dove e come verranno pubblicati i dati e descrivere in che modo è garantito il rispetto delle raccomandazioni AgID per la pubblicazione dei dati [20]; nella pubblicazione occorrerà in particolare prestare attenzione ai seguenti aspetti:

• assegnare ai dataset nomi auto-esplicativi e fornire descrizioni testuali degli stessi;
• mettere in evidenza la licenza in uso;
• fornire strumenti di ricerca e navigazione dei dati;
• fornire statistiche di uso, accesso e produzione, notifiche di aggiornamento dei dataset e del sito web;
• fornire strumenti per semplificare le interrogazioni.

Pertanto, in questa sezione del DMP occorre indicare:

• quale interfaccia utente/portale/sito web verrà utilizzata per la pubblicazione dei dati
• chi avrà in carico la gestione dell’interfaccia utente
• qual è la localizzazione dell’interfaccia utente (URL o indirizzo IP)
• se l’interfaccia utente rispetta o meno i requisiti di accessibilità previsti dalla legge 9 gennaio 2004, n. 4 (Disposizioni per favorire l’accesso dei soggetti disabili agli strumenti informatici)
• se l’interfaccia utente rispetta o meno i requisiti di usabilità previsti nel Piano quinquennale per l’informatica nella Pubblica Amministrazione [21]
• se è prevista o meno la pubblicazione nel portale nazionale https://dati.cultura.gov.it (cfr. par. Open data), di quali dati e con quali modalità e temporalità (conferimenti manuali o harvesting).

Inoltre, poiché ogni interfaccia utente ha generalmente un suo backend di gestione, nel DMP va inoltre indicato:

• quale struttura di backend verrà utilizzata per la pubblicazione dei dati e in che modo è integrata all’interfaccia utente (portale/sito web)
• chi avrà in carico la gestione del portale/sito web
• qual è la localizzazione fisica del portale/sito web (dove si trovano fisicamente i server che conservano i dati)
• qual è la localizzazione virtuale del portale/sito web (URL o indirizzo IP)
• in che modo il portale/sito web si relaziona con l’infrastruttura software del patrimonio culturale (cfr. par. Archiviazione dei dati ⓘ)
• in caso di utilizzo dell’infrastruttura software del patrimonio culturale gestita dall’ICDP, qual è il modello di interazione adottato (modello integrato/modello federato [22]).

Preservazione dei dati ⓘ¶

Nella gestione di un dataset, è fondamentale garantire la conservazione a lungo termine del dataset stesso. Il termine “digital preservation” indica le strategie e i metodi adottati per garantire la conservazione del dato nel corso del tempo [23].

Sia i formati utilizzati per i dati e i metadati, sia i supporti sui quali il dataset risiede, sono soggetti a obsolescenza, pertanto è molto importante analizzare sin dall’inizio del progetto di digitalizzazione i rischi in cui è possibile incorrere e le tecniche che possono essere adottate per garantire la digital preservation.

In questa sezione sono descritti i possibili rischi per la preservazione a lungo termine dei dati, e in particolare:

• se e quando è prevista una futura obsolescenza delle tecnologie utilizzate (ad esempio, un determinato software non più aggiornato)
• se e quando è prevista una futura obsolescenza dei formati utilizzati per rappresentare i dati (ad esempio in seguito a sostituzione con nuovi formati)
• se sono previsti i rischi legati alla conservazione fisica del dato (ad esempio perdita di dati in seguito a incidente)
• quali altri rischi relativi alla preservazione dei dati sono previsti
• con quali modalità si prevede di far fronte ai rischi di cui sopra.

Procedure di backup ⓘ ⓓ¶

Oltre alla gestione dei rischi legati alla conservazione, è necessario individuare e implementare specifiche procedure di duplicazione (backup) per evitare possibili perdite di dati in caso di incidente. Tali procedure dipendono da come sono strutturati i sistemi di gestione dei dati utilizzati (sistemi on-premise, sistemi in hosting o in housing, sistemi in cloud).

In questo paragrafo vanno descritte le procedure di backup dei dati e dei metadati e le modalità di recupero previste in caso di incidente. In particolare, occorre indicare:

• quali sono le procedure di backup dei dati e metadati
• dove sono conservati i backup
• con quale frequenza vengono eseguiti i backup
• quali modalità di recupero dei dati sono previste in caso di incidente
• chi ha la responsabilità di eseguire i backup.

Certificazione per la conservazione a lungo termine ⓘ¶

Le eventuali attività di certificazione previste per la conservazione a lungo termine possono essere documentate e, in particolare, possono essere segnalate:

• quali attività di certificazione sono previste
• qual è l’ente responsabile della certificazione
• che tipo di controlli sono previsti
• chi ha la responsabilità di gestire la certificazione.

Disposizioni per la sicurezza dei dati ⓘ¶

Nella sezione sono descritte le misure che verranno messe in atto per il rispetto delle misure minime di sicurezza ICT per le pubbliche amministrazioni, in base al livello AgID che l’istituto ha deciso di adottare.

Si consiglia inoltre di compilare la checklist per la verifica degli AgID Basic Security Controls – ABSC (si veda il par. 7.8.2) al fine di verificare il rispetto dei requisiti minimi di sicurezza. Gli aspetti che sono da considerare in questa sezione:

• se sono rispettati o meno i requisiti di sicurezza minimi ABSC
• se sono rispettati o meno requisiti di sicurezza di livello superiore
• quali sono le modalità di verifica periodica dei requisiti
• con che frequenza verranno eseguite queste verifiche
• chi ha la responsabilità di eseguire queste verifiche.

Standard per la sicurezza dei dati ⓘ¶

Per garantire la sicurezza dei dati, è opportuno adottare criteri standard di valutazione della sicurezza. Il MiC consiglia di adottare lo standard ABSC (AgID Basic Security Controls) definito dall’Agenzia per l’Italia digitale [27], che è compatibile con il framework FNSC (Framework Nazionale di Sicurezza Cibernetica [28]) e con lo standard internazionale CCSC (CIS Critical Security Controls [29]). Lo standard ABSC prevede la creazione di un inventario dei dispositivi autorizzati e non autorizzati, l’adozione di standard per la protezione dei dispositivi, una valutazione continua delle vulnerabilità per far fronte a nuovi possibili rischi, un uso appropriato dei privilegi di accesso e la protezione da malware. Sono inoltre previste altre due attività molto importanti, ovvero l’esecuzione di copie di backup (cfr. par. Procedure di backup ⓘ ⓓ) e la protezione dei dati soggetti a vincoli di riservatezza (si cfr. par. Sicurezza dei dati personali ⓘ).

In questa sezione del DMP è opportuno riportare:

• se è stato adottato o meno lo standard ABSC
• se no, per quale motivo
• quali altri standard di sicurezza sono stati adottati
• in che modo è stato verificato il rispetto di tali standard.

Rischi per la sicurezza dei dati ⓘ¶

Questa sezione delinea sinteticamente i possibili rischi previsti per la sicurezza dei dati, facendo riferimento alla specifica tipologia di dati raccolti nel progetto. In particolare, occorre indicare, se si prevedono:

• rischi di furto dei dati
• rischi di riuso improprio o illegale dei dati
• violazioni delle licenze adottate
• violazioni delle policy di accesso
• attacchi informatici all’infrastruttura
• attacchi informatici all’interfaccia utente
• qualunque altro rischio per la sicurezza dei dati non elencato sopra.

Sicurezza dei dati personali ⓘ¶

Nel caso di pubblicazione di dati soggetti al Regolamento sulla protezione dei dati personali, occorre prevedere una regolamentazione degli accessi che potrà fare capo a un sistema di registrazione online dell’utenza mediante SPID, in modo da riconoscere con certezza l’identità del richiedente e informarlo adeguatamente in merito alle regole deontologiche per il trattamento dei dati personali e alle responsabilità derivanti da un utilizzo illegittimo degli stessi. In alcuni casi può essere opportuno prevedere forme di anonimizzazione o pseudonimizzazione dei dati.

In questa sezione del DMP occorre quindi indicare:

• quali misure vengono adottate nel progetto per garantire la sicurezza dei dati personali
• quali forme di controllo degli accessi sono previste
• quali livelli di accesso sono previsti
• quali modalità di autenticazione sono previste
• se è stata adottata l’autenticazione tramite SPID
• se non è stata adottata, indicare per quale motivo
• se sono previste forme di registrazione online degli utenti
• se sì, quali modalità di registrazione sono previste e con quali modalità verranno conservati i dati
• se è stata eseguita una anonimizzazione o pseudonimizzazione dei dati, e se sì di quali dati e con quali modalità.