Sezione 3 – Classifica i dati che caratterizzano l'operatività del GDU
a cura di CNR-IFAC
Valentina Colcelli, Nicola Zoppetti, Alessandra Langella e Moreno Comelli
3.1 Introduzione
Un Gemello Digitale Urbano genera e utilizza un’ampia varietà di dati e informazioni eterogenee; pertanto, la sua realizzazione richiede una gestione accurata di tali elementi sia sotto il profilo legale sia etico. Poiché questi progetti appartengono a un’amministrazione pubblica e possono essere sostenuti da finanziamenti pubblici, è fondamentale svolgere un’attività sistematica di censimento dei dati primari e secondari impiegati, nonché dei software sviluppati, prestando particolare attenzione alle licenze d’uso associate al momento del rilascio. L’obiettivo è garantire, ove possibile, la disponibilità delle risorse digitali in modalità Open Access, in linea con quanto previsto dalla Direttiva (UE) 2019/1024 (Open Data).
Gestire i dati in un GDU significa, in primo luogo, procedere alla mappatura dei dati di natura primaria e secondaria, personali, non personali e misti che eventualmente derivano da rilievi diretti sul campo, sensoristica, acquisti di servizi, convenzioni con terzi etc. Rispetto a questi ultimi occorre capire se i dati sono acquisiti, la modalità di acquisizione (titolo oneroso o gratuito) e soprattutto la modalità di rilascio (licenza) degli stessi all’amministrazione ai fini della sostenibilità anche economica del GDU al termine del progetto.
In secondo luogo, significa organizzare il lavoro di raccolta, conservazione e validazione affinché i dati siano comprensibili e funzionali nel medio e lungo termine.
L’analisi delle tipologie di dati, acquisiti o acquisibili ai fini del progetto, rappresenta un’attività preliminare fondamentale per individuare le azioni necessarie a garantire che la raccolta e l’utilizzo dei dati avvengano in modo conforme alla normativa vigente e secondo principi etici. Tale attività deve essere svolta in collaborazione sia con gli sviluppatori del Gemello Digitale Urbano sia con l’amministrazione comunale.
In particolare, occorre raccogliere le seguenti informazioni:
- Provenienza dei dati
- Diritti sui dati
- Caratteristiche
- Tipologia di utilizzo nel Progetto
- Descrizione della modalità di approvvigionamento
Focus box
I dati personali, in considerazione della loro specificità, saranno trattati in una sezione dedicata del documento (si veda sezione 4 “Gestisci i dati personali nel GDU”).
GLOSSARIO NORMATIVO SINTETICO (PARTE I)
Dati | Qualsiasi rappresentazione digitale di atti, fatti o informazioni e qualsiasi raccolta di tali atti, fatti o informazioni, anche sotto forma di registrazione sonora, visiva o audiovisiva. Fonte: Regolamento (UE) 2023/2854 del Parlamento europeo e del Consiglio, del 13 dicembre 2023, riguardante norme armonizzate sull’accesso equo ai dati e sul loro utilizzo e che modifica il regolamento (UE) 2017/2394 e la direttiva (UE) 2020/1828 (legge sui dati) (GU L 2023/2854 del 22.12.2023). |
Dati dinamici | Documenti in formato digitale, soggetti ad aggiornamenti frequenti o in tempo reale, in particolare a causa della loro volatilità o rapida obsolescenza; i dati generati da sensori sono solitamente considerati dati dinamici. Poiché i dati di mobilità sono tipicamente dati dinamici (traffico, TPL, flussi pedonali), vige l’obbligo di renderli disponibili tramite API immediatamente dopo la raccolta. Eventuali ritardi o restrizioni temporanee devono essere formalmente motivati e non devono pregiudicare indebitamente il potenziale economico e sociale dei dati (Requisito 6 LG AgID). Fonte: Direttiva (UE) 2019/1024 del Parlamento europeo e del Consiglio, del 20 giugno 2019, relativa all'apertura dei dati e al riutilizzo dell'informazione del settore pubblico (rifusione) |
Dati della ricerca | Documenti in formato digitale, diversi dalle pubblicazioni scientifiche, raccolti o prodotti nel corso della ricerca scientifica e utilizzati come elementi di prova nel processo di ricerca, o comunemente accettati nella comunità di ricerca come necessari per convalidare le conclusioni e i risultati della ricerca. Fonti: Direttiva (UE) 2019/1024 del Parlamento europeo e del Consiglio, del 20 giugno 2019, relativa all'apertura dei dati e al riutilizzo dell'informazione del settore pubblico (rifusione) |
Serie di dati di elevato valore | Documenti il cui riutilizzo è associato a importanti benefici per la società, l'ambiente e l'economia, in particolare in considerazione della loro idoneità per la creazione di servizi, applicazioni a valore aggiunto e nuovi posti di lavoro dignitosi e di alta qualità, nonché del numero dei potenziali beneficiari dei servizi e delle applicazioni a valore aggiunto basati su tali serie di dati Fonte: Direttiva (UE) 2019/1024 del Parlamento europeo e del Consiglio, del 20 giugno 2019, relativa all'apertura dei dati e al riutilizzo dell'informazione del settore pubblico (rifusione) |
Riutilizzo |
Direttiva (UE) 2019/1024 del Parlamento europeo e del Consiglio, del 20 giugno 2019, relativa all'apertura dei dati e al riutilizzo dell'informazione del settore pubblico (rifusione) |
Dati personali | Qualsiasi informazione riguardante una persona fisica identificata o identificabile («interessato»); si considera identificabile la persona fisica che può essere identificata, direttamente o indirettamente, con particolare riferimento a un identificativo come il nome, un numero di identificazione, dati relativi all'ubicazione, un identificativo online o a uno o più elementi caratteristici della sua identità fisica, fisiologica, genetica, psichica, economica, culturale o sociale. Fonte: Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016 (GDPR), applicabile dal 25 maggio 2018. |
Dati non personali | Informazioni diverse dai dati personali |
Dati misti | «Un insieme di dati misti è composto sia da dati personali che da dati non personali», come, per esempio, i documenti relativi a un'impresa o ad un ente pubblico che contengono il nome e altre informazioni riguardanti il rappresentante legale. In questi casi, qualora dati personali e non personali all'interno di un insieme di dati siano indissolubilmente legati, per la parte relativa ai dati personali si applicheranno i principi e le regole del GDPR per i dati personali (cfr. art. 2, par. 2, Regolamento (UE) 2018/1807). Fonte: Comunicazione della Commissione, Guidance on the Regulation on a framework for the free flow of non-personal data in the European Union, (29 maggio 2019, COM(2019) 250 final) |
Dati primari | Dati Primari (Grezzi): Sono i dati raccolti alla fonte (es. raw data), non elaborati, mantenendo il massimo dettaglio e precisione. Fonte: Le Linee Guida Open Data adottate da AgID (agosto 2023) |
Dati secondari | i "dati secondari" sono le informazioni risultanti da elaborazioni, analisi o riorganizzazioni dei dati primari (es. titolo, autore, data, URL/nome delle fonti, PID, licenze, ecc). Fonte: Le Linee Guida Open Data adottate da AgID (agosto 2023) |
GLOSSARIO NORMATIVO SINTETICO (PARTE II)
Autore del Dataset | Un’organizzazione (o pubblica amministrazione) che ha materialmente prodotto il dataset. Si raccomanda di evitare l’inserimento di nomi di singole persone. Si vedano gli esempi riportati sull’uso della classe Agent (Soggetto). |
Autore di una banca di dati | Nel diritto d'autore la banca dati può ricevere due protezioni distinte, con due soggetti diversi: 1.Tutela autoriale (Direttiva 96/9/CE, art. 3; L. 633/1941, art. 1, co. 2, e art. 2, n. 9) 2.Diritto sui generis (Direttiva 96/9/CE, art. 7; L. 633/1941, art. 102-bis) |
Catalogo | Un catalogo è definito mediante la classe Catalog identificata univocamente da un URI (Uniform Resource Identifier). |
Database | Si intende una raccolta di opere, dati o altri elementi indipendenti sistematicamente o metodicamente disposti ed individualmente accessibili grazie a mezzi elettronici o in altro modo Fonte: Direttiva 96/9/CE del Parlamento europeo e del Consiglio, dell'11 marzo 1996, relativa alla tutela giuridica delle banche di dati |
Dataset | Raccolta di dati pubblicata o curata da un singolo agente e disponibile per l'accesso o il download in uno o più formati (W3C DCAT (Data Catalog Vocabulary), adottato dalla Commissione europea come base per DCAT-AP) Un dataset è definito mediante la classe Dataset identificata univocamente da un URI (Uniform Resource Identifier). |
Detentore di dati | "La persona fisica o giuridica che ha il diritto o l'obbligo... di utilizzare e mettere a disposizione i dati a cui ha accesso". Non è necessariamente il produttore originale: rileva chi controlla l'accesso. Fonte: Secondo i principi di Economia dei dati — Data Act (Reg. UE 2023/2854, art. 2). |
Editore | Un’organizzazione (o pubblica amministrazione) responsabile di rendere disponibile (pubblicare) il dataset. |
FAIR (principi) | Findable, Accessible, Interoperable, Reusable |
Formati Aperti | Il formato dei dati digitali si definisce "aperto" quando ne viene resa pubblica, mediante esaustiva documentazione, la sintassi, la semantica, il contesto operativo e le modalità di utilizzo. Tali informazioni, unitamente ad una guida all’uso del formato, orientata alla lettura da parte dell’utilizzatore, devono essere presenti in uno o più documenti rilasciati dall’ente proponente lo standard. (Fonte: https://www.agid.gov.it/it/argomenti/formati-aperti) un formato di file indipendente dalla piattaforma e messo a disposizione del pubblico senza restrizioni che impediscano il riutilizzo dei documenti |
Metadati | Informazioni necessarie a interpretare e utilizzare i dati Fonte: Reg. UE 2023/2854 (Data Act) Informazioni strutturate per identificare, autenticare, classificare e reperire documenti informatici Fonte: LG AgID (ex art. 71 CAD) Informazioni che descrivono dataset e servizi territoriali per ricercarli, repertoriarli e usarli Fonte: Dir. INSPIRE 2007/2/CE, art. 3 n. 6 / D. Lgs. 32/2010 |
Thesaurus | Un thesaurus è un vocabolario controllato e strutturato, i cui concetti sono rappresentati da etichette con una struttura gerarchica di termini più ampi e più ristretti. Nel contesto dei vocabolari dell'UE, un thesaurus presenta un equivalente multilingue di questo approccio, con lo stesso concetto in ciascuna delle lingue supportate rappresentato da un'unica etichetta preferita. (Fonti: https://op.europa.eu/en/web/eu-vocabularies/thesauri) |
Vocabolari controllati | I vocabolari controllati forniscono un modo coerente per descrivere i dati. Si tratta di arrangiamenti standardizzati e organizzati di parole e frasi, presentati come elenchi alfabetici di termini o come thesauri e tassonomie con una struttura gerarchica di termini più ampi e più ristretti. (Fonti: https://op.europa.eu/en/web/eu-vocabularies/controlled-vocabularies) |
Titolare | La definizione può cambiare in ragione delle norme di riferimento Secondo la Metadatazione cataloghi — DCAT-AP IT (AgID) Il titolare è l'organizzazione responsabile della gestione complessiva del dataset in virtù delle proprie competenze istituzionali. Si distingue dall'editore (chi lo pubblica) e dal creatore (chi lo ha materialmente prodotto). È il campo dct:rightsHolder nei metadati Fonte: DCAT-AP_IT v1.1 – Profilo italiano di DCAT-AP Secondo la normativa sul Settore pubblico — Open data (D. Lgs. 36/2006, art. 2, co. 1, lett. e), mod. da D. Lgs. 200/2021) Il titolare del dato è "la pubblica amministrazione o l'organismo di diritto pubblico che ha originariamente formato il documento per propri fini istituzionali, ovvero lo ha commissionato ad altro soggetto pubblico o privato". È la PA che ha il dato nel proprio patrimonio informativo e ne è responsabile della disseminazione (CAD, art. 52, co. 1-bis). Secondo il Diritto sui generis (Direttiva 96/9/CE → L. 633/1941, art. 102-bis) Il titolare è il costitutore: la persona fisica o giuridica che ha effettuato un investimento rilevante (finanziario, di tempo o di lavoro) per la raccolta, verifica o presentazione del contenuto. Il diritto sui generis dura 15 anni dalla creazione (rinnovabile se aggiornata sostanzialmente). Non serve creatività: basta l'investimento. Se il lavoro è stato commissionato, il costitutore è il committente (non l'esecutore), salvo diverso accordo contrattuale. |
3.2 Controlla se i tuoi dati sono di elevato valore (High Value Datasets – HVD)
Segui le seguenti indicazioni per la qualificazione di questa importante categoria di dati
3.3 Qualificazione dei dati di elevato valore
I dati di elevato valore (High Value Datasets – HVD) sono definiti all’art. 2 della Direttiva (UE) 2019/1024 come “documenti il cui riutilizzo è associato a importanti benefici per la società, l'ambiente e l'economia, in particolare in considerazione della loro idoneità per la creazione di servizi, applicazioni a valore aggiunto e nuovi posti di lavoro dignitosi e di alta qualità, nonché del numero dei potenziali beneficiari dei servizi e delle applicazioni a valore aggiunto basati su tali serie di dati”.
L'allegato I della Direttiva UE stabilisce i temi di serie di dati di elevato valore elencando sei categorie tematiche di dati:
1)dati geospaziali;
2)dati relativi all'osservazione della terra e all'ambiente;
3)dati meteorologici;
4)dati statistici;
5)dati relativi alle imprese e alla proprietà delle imprese;
6)dati relativi alla mobilità.
mentre i criteri per la loro identificazione, indicati dall'art. 14, par. 2, della Direttiva, si basano sulla valutazione della loro potenzialità nell’apportare importanti benefici socio-economici o ambientali e servizi innovativi; nel beneficiare un numero elevato di utilizzatori, in particolare PMI; nel contribuire a generare proventi; e, infine, nell’essere combinati con altre serie di dati.
3.4 Aspetti normativi per la gestione dei Dati di elevato valore (HVD) nel GDU di riferimento
Dal momento che gli HVD sono informazioni che hanno un particolare potenziale di generazione di benefici socioeconomici, la normativa europea e nazionale impone alcuni obblighi e specifiche raccomandazioni che devono essere considerati da parte del Comune di riferimento che se ne avvale per la realizzazione, la gestione e il funzionamento del GDU.
Difatti, rispetto a questi dati, la normativa europea e nazionale esige in termini generali la pubblicazione aperta e il riutilizzo con restrizioni giuridiche e tecniche minime e a titolo gratuito (cons. 2 Reg. di esecuzione (UE) 2023/138 e cons. 69 Dir. (UE) 2019/1024). Invero, le serie di dati di elevato valore devono essere pubblicate gratuitamente, accessibili in formato aperto, leggibili meccanicamente e fornite mediante API e come download in blocco, se del caso (art. 14, par. 1, Dir. (UE) 2019/1024) oltre che accompagnate da metadati e documentazione.
Con riguardo al regime economico, la regola generale è quella del riutilizzo gratuito, e le uniche deroghe sono quelle tassativamente previste dall'art. 14, parr. 3-5, della Direttiva. Per questa stessa ragione, devono essere utilizzate licenze aperte standard che non limitino il riutilizzo essendo al massimo ammesso un obbligo di attribuzione. I principi di non discriminazione e trasparenza impongono infine che tutti gli utenti devono avere pari accesso ai dati, con il divieto di accordi esclusivi, salvo eccezioni molto limitate.
Sono categorie di dati ad alto valore utilizzati nel GDU di riferimento i dati geospaziali, quelli relativi all'osservazione della terra e all'ambiente e quelli sulla mobilità. Essi rientrano tra le serie di dati di elevato valore ai sensi della Direttiva (UE) 2019/1024 e del Regolamento di esecuzione (UE) 2023/138 e sono strettamente collegati alla Direttiva 2007/2/CE INSPIRE. Invero, hanno natura territoriale, in quanto riferiti a specifiche localizzazioni geografiche, sebbene con caratteristiche diverse: i dati geospaziali costituiscono la base cartografica, i dati sulla mobilità rappresentano fenomeni dinamici legati alle reti di trasporto, mentre i dati ambientali, come quelli sulla qualità dell’aria, descrivono fenomeni territoriali misurati nello spazio. In linea con la definizione presente all’art. 3, punto 2) della Direttiva INSPIRE, i dati territoriali sono definiti dall'art. 2 del D.Lgs. 32/2010 come “i dati che attengono, direttamente o indirettamente, a una località o a un’area geografica specifica”. Il Decreto non include quindi particolari disposizioni su tali dati, se non il rimando alla disciplina specifica definita in applicazione della Direttiva 2007/2/CE conosciuta come Direttiva INSPIRE la quale si applica esclusivamente ai dati territoriali, ossia ai dati georeferenziati relativi al territorio e all’ambiente. Non riguarda, invece, l’insieme dei dati detenuti dalla pubblica amministrazione, ma solo quelli associati a una dimensione spaziale, per i quali stabilisce regole comuni di interoperabilità, condivisione e accesso. Recepita in Italia con il D.lgs. 32/2010, mira a rendere i dati territoriali degli Stati Membri interoperabili, accessibili e condivisibili attraverso infrastrutture di informazione geografica. Invero, la Direttiva istituisce un’infrastruttura per l’informazione territoriale nella comunità europea con l’obiettivo di armonizzare la disponibilità, la qualità, l’accessibilità e la condivisione dei dati geografici tra gli Stati ai fini delle politiche ambientali.
Ciò comporta che i Membri dell’UE debbano organizzare, documentare e pubblicare i propri dati secondo regole proprie volte a garantire la condivisione tra le amministrazioni e l’accessibilità senza barriere tecniche o economiche; i dati devono essere accompagnati da metadati e standard comuni essendo obiettivo principale quello di garantire la possibilità di integrare dati provenienti da fonti diverse, superando la frammentazione tra amministrazioni e settori.
La Direttiva si applica ai dati che:
(a) riguardano zone su cui gli Stati membri hanno diritti giurisdizionali;
(b) sono disponibili in formato elettronico;
(c) sono detenuti da o per conto di un’autorità pubblica e sono stati prodotti o ricevuti da
un’autorità pubblica o sono gestiti o aggiornati dall’autorità in questione e rientrano nell'ambito dei
compiti di servizio pubblico;
(d) riguardano uno o più dei temi elencati negli allegati I, II o III della Direttiva.
Il Comune di riferimento - in quanto autorità pubblica che detiene e gestisce dati HVD, territoriali ed integrabili nel digital twin (al di là del dato che alcuni siano strutturali (mappe), altri dinamici (mobilità) e altri ambientali (aria)) - è soggetto in termini generali agli obblighi previsti dalla Direttiva.
3.5 Direttiva INSPIRE e Gemelli Digitali Urbani
Particolari valutazioni devono essere compiute dal momento che il Comune di riferimento ha realizzato un GDU.
Secondo quanto stabilito dall’Articolo 1 della Direttiva 2007/2, Inspire si fonda sulle infrastrutture per l’informazione territoriale create e gestite dagli Stati membri.
Di fatto, un GDU può agevolare molto l'attuazione delle disposizioni del suddetto documento normativo dal momento che per il suo funzionamento è necessaria la raccolta di dati provenienti da molteplici fonti e tramite questa integrazione si facilita proprio la produzione dei dataset richiesti dalla Direttiva.
Del resto, i gemelli digitali moderni sono spesso costruiti utilizzando standard aperti come quelli promossi da Open Geospatial Consortium e poiché INSPIRE punta all'interoperabilità, molte componenti tecnologiche risultano complementari. Inoltre, INSPIRE è basata sulla condivisione di dati geografici, spesso aggiornati periodicamente e i GDU possono fornire dati migliorando la tempestività delle informazioni territoriali.
L’Amministrazione può quindi utilizzare il GDU come ambiente per raccogliere, verificare e pubblicare i dati che poi confluiscono nei servizi conformi a INSPIRE. In questo senso, il quadro normativo e di interoperabilità per la condivisione dei dati territoriali di INSPIRE trova una evoluzione operativa nei GDU che costituiscono il luogo in cui tali dati vengono integrati, gestiti e analizzati. Il GDU, invero, pur non sostituendo le infrastrutture per l'informazione territoriale previste dalla Direttiva INSPIRE, può in ogni caso costituire un'evoluzione tecnologica delle stesse, favorendo l'integrazione, l'interoperabilità e l'aggiornamento dinamico dei dati territoriali conformi agli standard europei.
3.6 Obblighi e adempimenti del Comune di riferimento
Il Comune di riferimento (come gli altri enti pubblici competenti tra i quali Ministero delle Infrastrutture e dei Trasporti, Regione e altri soggetti coinvolti), in compliance con le norme indicate riguardo alla categoria degli HVD deve assicurare la gestione integrata della filiera dell’informazione curando le attività di produzione, aggiornamento, archiviazione, nonché la messa a disposizione di servizi di accesso e pubblicazione (Guida operativa sulle serie di dati di elevato valore come Documento di orientamento per l’attuazione del Regolamento di esecuzione (UE) 2023/138 e delle Linee Guida per l’apertura dei dati e il riutilizzo dell’informazione del settore pubblico-Dicembre 2023) anche mediante degli obblighi rafforzati rispetto a quanto previsto dalla Direttiva Open Data.
Le disposizioni, i requisiti e le raccomandazioni definiti nei documenti esaminati sono applicabili sia ai dati del Progetto che il Comune utilizzerà nel GDU sia a quelli creati prima della data di applicazione del Regolamento 2023/138.
Sulla base del quadro normativo sopra descritto, il Comune è tenuto a porre in essere alcune attività e adempimenti in relazione ai dati di alto valore gestiti nell’ambito del Gemello Digitale Urbano di riferimento.
3.7 Interoperabilità e standard
In primo luogo, il Comune è tenuto a garantire che i dati territoriali e ad alto valore siano interoperabili secondo gli standard INSPIRE, aperti e riutilizzabili secondo la Direttiva Open Data e resi disponibili con modalità avanzate (API, formati aperti e licenze libere) secondo il Regolamento sui dati di elevato valore.
Con riguardo alla interoperabilità e standard INSPIRE, sono obblighi del Comune applicare i modelli dati INSPIRE per i dati territoriali, implementare i servizi di rete INSPIRE e rispettare il D. Lgs. 32/2010.
3.8 Qualità del dato
Nel caso di dati territoriali, lo standard specifico di riferimento per la qualità è l’ISO 19157 “Geographic
information - Data quality. Per i dati territoriali di cui ai temi INSPIRE, pertanto, il Comune dovrà considerare gli elementi e le misure definite nelle relative specifiche nella sezione “7 - Data quality” per ciascun tema INSPIRE, nonché i sistemi di validazione e controllo nazionali ed europei. Per i dati territoriali che fanno riferimento a specifiche diverse, dovranno essere adottati sistemi di verifiche di qualità a cura di soggetti qualificati diversi da quelli che hanno prodotto il dato.
3.9 Vocabolari e interoperabilità semantica
Il Comune è tenuto ad utilizzare vocabolari controllati e tassonomie standard, nazionali ed europei (in particolare quelli previsti da INSPIRE per i dati territoriali), al fine di garantire l’interoperabilità semantica, ossia la piena comprensione e integrazione dei dati tra sistemi e amministrazioni diverse.
Per i dati relativi alla mobilità, le Linee Guida Open Data stabiliscono che questa serie di dati utilizza vocabolari e tassonomie controllati, pubblicamente documentati e riconosciuti dall’Unione o a livello internazionale, se disponibili (par. 5.1.4). Inoltre, le serie di dati sono descritte in una documentazione online completa e accessibile al pubblico che descrive almeno la struttura e la semantica dei dati (5.1.5).
3.10 Creazione e aggiornamento dei metadati e documentazione (art. 11 INSPIRE; art. 4 D. Lgs. 32/2010; Requisito 16 LG AgID)
Come prescritto dal d. lgs. 36/2006 per rendere i dati reperibili il Comune dovrà documentare i dati con metadati dettagliati; assegnare a dati e metadati un identificatore univoco e persistente (per es. DOI); rendere disponibili online i metadati attraverso una risorsa consultabile, come per esempio un catalogo o un repository (Requisiti 29 e 30 LG AgID); specificare l’identificatore del dato nei metadati.
Tuttavia, come regola specifica il Comune deve creare e mantenere aggiornati i metadati per tutti i dataset di alto valore, con indicazione di conformità dei dataset alle norme tecniche di esecuzione INSPIRE; condizioni di accesso e riutilizzo dei dati, inclusi eventuali canoni; qualità e validità dei dataset; autorità pubblica responsabile della creazione, gestione, manutenzione e distribuzione; eventuali limitazioni dell’accesso pubblico e relative motivazioni.
Per i dati territoriali è richiesto al Comune di documentarli esclusivamente presso il Repertorio Nazionale dei Dati Territoriali (RNDT) che, in maniera automatizzata, si occupa dell’allineamento con il portale nazionale dei dati aperti dati.gov.it. (Art. 9, cc. 1 e 2). Per i dati territoriali, i metadati devono essere conformi alle “Linee Guida recanti regole tecniche per la definizione e l’aggiornamento del contenuto del Repertorio Nazionale dei Dati Territoriali” (Requisito 16 LG AgID). È necessario che siano contenuti almeno gli elementi di metadati definiti nel Regolamento (CE) n. 1205/2008.
3.11 Formati aperti, API e download in blocco (Requisiti 2, 3, 7 LG AgID)
Le serie di dati di elevato valore devono essere rese disponibili in formato aperto e leggibile meccanicamente (almeno 3 stelle nel modello di maturità open data: per es.CSV, JSON, GeoJSON, GML), in un formato riconosciuto dall’Unione o a livello internazionale, e nel caso in cui un dato sia disponibile in più formati, almeno uno di essi deve essere coerente con quanto appena indicato; tramite API conformi agli standard tecnici indicati dalle Linee Guida (Requisito 27); tramite download in blocco; nella versione più aggiornata disponibile, messe a disposizione immediatamente dopo ogni aggiornamento (o con motivato ritardo in caso di vincoli tecnici o finanziari).
Per i dati di elevato valore, la P.A., in quanto titolare dei dati, assume impegni precisi non essendo sufficiente il rispetto del best-effort: devono essere stabiliti e pubblicati i termini di utilizzo delle API e i criteri di qualità dei servizi in relazione a prestazione, capacità e disponibilità.
Le API sviluppate per rendere disponibili i dati per il riutilizzo devono essere conformi alle
“Linee Guida sull’interoperabilità tecnica delle Pubbliche Amministrazioni” e alle “Linee Guida
Tecnologie e standard per la sicurezza dell’interoperabilità tramite API dei sistemi informatici”,
adottate da AgID con la Determinazione n. 547/2021 (Requisito 27 LG AgID).
Tuttavia, per le versioni storiche per la serie di dati ricadenti nella categoria “Dati relativi all’osservazione della Terra e dell’ambiente” si possono rendere disponibili API o download in blocco, per quanto possibile e opportuno.
La P.A., in quanto titolare dei dati, definisce e pubblica le condizioni di utilizzo delle API in forma chiara, completa e accessibile online. L’art. 3, comma 3 del Regolamento stabilisce che la documentazione dell’API debba essere resa disponibile in un formato aperto, leggibile dall'uomo e meccanicamente.
Per i dati territoriali rientranti in INSPIRE, la PA rende disponibili i dati attraverso i servizi di rete previsti dalla Direttiva e garantisce che la relativa documentazione sia fornita direttamente tramite le risposte dei servizi stessi, in formato standard XML. Più nello specifico, la PA è tenuta a implementare i servizi di rete secondo le Linee guida tecniche europee, garantendo in particolare la disponibilità delle operazioni di accesso ai metadati del servizio. Inoltre, deve designare un punto di contatto per le API e renderne disponibili le informazioni all’interno dei metadati pubblicati nei cataloghi nazionali, al fine di assicurare trasparenza e supporto agli utenti.
Per i HVD non rientranti nell’ambito INSPIRE, la PA deve garantire la descrizione formale delle API mediante linguaggi standard di descrizione delle interfacce (IDL), quali OpenAPI per i servizi REST e WSDL per i servizi SOAP, assicurando una documentazione strutturata, completa e leggibile automaticamente, conforme alle Linee guida AgID sull’interoperabilità.
3.12 Licenze e gratuità (Requisiti 8, 20, 21 LG AgID; art. 10 D. Lgs. 32/2010)
Le serie di dati di elevato valore devono essere messe a disposizione gratuitamente, alle condizioni della licenza Creative Commons BY 4.0 o di una licenza aperta equivalente o meno restrittiva. La gratuità è la regola; deroghe sono previste solo in casi tassativi previsti dal Regolamento (UE) 2023/138. È consentito imporre tariffe per i servizi in relazione alle serie di dati di elevato valore nell’esercizio dell'autorità pubblica, in particolare certificando l'autenticità o la veridicità dei documenti.
Sul versante della condivisione inter-istituzionale, l’art. 10 del D. Lgs. 32/2010 prevede che le autorità pubbliche abbiano libero accesso ai dataset territoriali e li condividano senza nuovi o maggiori oneri per la finanza pubblica, senza ostacoli pratici al punto di utilizzo. I dataset forniti ad altre PA o a istituzioni europee per adempimenti ambientali non sono soggetti ad alcuna tariffa.
3.13 Schede operative per categoria di dati di elevato valore
Di seguito si riportano, per ciascuna categoria di dati di elevato valore gestita nell’ambito del GDU di riferimento, una breve descrizione del tema e le azioni a carico della Pubblica Amministrazione, elaborate sulla base del Capitolo 5 della Guida operativa sulle serie di dati di elevato valore (AgID, dicembre 2023) e dell’Allegato al Regolamento di esecuzione (UE) 2023/138. Le azioni sono riferite al Comune di riferimento quale autorità pubblica titolare e gestore dei dati nel GDU; per i temi di competenza nazionale o regionale (es. ISTAT, IGM, ISPRA/SNPA, ARPA e Regione competenti) il Comune opera in coordinamento con gli enti competenti.
3.14 Dati geospaziali
La categoria “Dati geospaziali” comprende le serie di dati Unità amministrative, Nomi geografici, Indirizzi, Edifici, Parcelle catastali, Parcelle di riferimento e Parcelle agricole, riferite al framework di interoperabilità definito dalla Direttiva INSPIRE. Costituiscono la base cartografica del Gemello Digitale Urbano e, in quanto dati territoriali, sono soggette congiuntamente alla disciplina Open Data/HVD e alle regole tecniche INSPIRE (D. Lgs. 32/2010).
Requisito | Azione a carico del Comune di riferimento | Riferimento normativo/tecnico |
|---|---|---|
Modello dati e attributi | Mappare gli attributi degli schemi dati sorgente verso i modelli dati INSPIRE dei temi geospaziali (Unità amministrative, Nomi geografici, Indirizzi, Edifici, Parcelle catastali, di riferimento e agricole), armonizzando o integrando gli attributi mancanti secondo i relativi schemi applicativi. | All. Reg. (UE) 2023/138; Dir. 2007/2/CE (INSPIRE); D. Lgs. 32/2010 |
Licenza | Applicare la licenza CC BY 4.0 o CC0 (o equivalente, meno restrittiva); aggiornare i dataset già pubblicati con licenze più restrittive o privi di licenza. | art. 4 Reg. (UE) 2023/138; Req. 20-21 LG AgID |
Formato aperto | Rendere disponibili i dati in formati aperti e leggibili meccanicamente (almeno 3 stelle: GML, GeoJSON, GeoPackage), privilegiando la distribuzione diretta tramite i servizi di rete INSPIRE. | Req. 2-3 LG AgID |
API e download in blocco | Implementare servizi di rete e Open Features API conformi alle regole tecniche, nonché il download in blocco (es. tramite ATOM Feed). | Req. 7, 27, 28 LG AgID; art. 6 c. 8 D. Lgs. 36/2006 |
Aggiornamento | Definire un piano di aggiornamento e pubblicare la versione più aggiornata immediatamente dopo ogni aggiornamento; motivare formalmente eventuali ritardi. | Req. 5-6 LG AgID |
Metadati | Documentare i dati territoriali esclusivamente nel Repertorio Nazionale dei Dati Territoriali (RNDT), con metadati conformi (almeno gli elementi del Reg. CE 1205/2008) e allineamento automatico a dati.gov.it. | art. 11 Dir. INSPIRE; artt. 4 e 9 D. Lgs. 32/2010; Req. 16 LG AgID |
Vocabolari e semantica | Utilizzare gli asset semantici e i vocabolari controllati INSPIRE federati nel Sistema di Registri INSPIRE, oltre ad altri vocabolari di dominio riconosciuti. | All. Reg. (UE) 2023/138; LG AgID |
3.15 Dati relativi all’osservazione della Terra e all’ambiente
La categoria comprende i dati di osservazione della Terra (dati spaziali o di telerilevamento e dati rilevati a terra o in situ), le serie di dati ambientali e climatici prodotte nel contesto della reportistica ambientale e tutti i dati che ricadono nelle specifiche tecniche INSPIRE (annessi II e III), a tutti i livelli di generalizzazione fino alla scala 1:5.000. Nel GDU di riferimento assumono particolare rilievo le ortoimmagini, gli impianti di monitoraggio ambientale, i dati sulla qualità dell’aria e quelli sulle emissioni, di seguito trattati. L’obbligo di messa a disposizione delle serie di dati di elevato valore vale soltanto per le serie specificate nell’allegato del regolamento di esecuzione (UE) 2023/138, non per l’intera categoria tematica, e soltanto per i documenti ai quali si applica la direttiva (UE) 2019/1024: ne sono esclusi, tra gli altri, quelli su cui terzi detengono diritti di proprietà intellettuale (art. 1, par. 2, lett. c), della direttiva).
3.16 Ortoimmagini
Le ortoimmagini sono riprese aeree o satellitari georiferite e ortorettificate, elemento di base del Gemello Digitale Urbano. A livello nazionale AgEA acquisisce periodicamente ortoimmagini dell’intero territorio (risoluzione 20 cm dal 2015); i dati satellitari (es. COSMO-SkyMed, PRISMA) sono soggetti a vincoli particolari di licenza e diffusione che possono escluderli dal riuso aperto. Per il GDU di riferimento assumono rilievo soprattutto i vincoli contrattuali e di licenza dei dati acquisiti.
Requisito | Azione a carico del Comune di riferimento | Riferimento normativo/tecnico |
|---|---|---|
Fonti e diritti d’uso | Effettuare la ricognizione dei vincoli contrattuali e delle licenze d’uso delle ortoimmagini acquisite (da fornitori, AgEA o fonti satellitari) prima della pubblicazione e del riuso nel GDU. | Cap. 6 Guida operativa; art. 4 Reg. (UE) 2023/138 |
Licenza | Pubblicare con CC BY 4.0/CC0 le ortoimmagini di cui il Comune è titolare; per i dati di terzi con licenze più restrittive (es. COSMO-SkyMed/PRISMA) valutarne l’esclusione dal riuso aperto con motivazione documentata. | art. 4 Reg. (UE) 2023/138; Cap. 6 Guida |
Formato e risoluzione | Rendere disponibili ortoimmagini georiferite e ortorettificate in formati raster aperti, a tutti i livelli di generalizzazione fino alla scala 1:5.000. | sez. 2 All. Reg. (UE) 2023/138; Req. 2 LG AgID |
API e download in blocco | Esporre i dati tramite servizi di visualizzazione (WMS) e di download; per le versioni storiche rendere disponibili API o download in blocco, per quanto possibile e opportuno. | Req. 7, 27 LG AgID |
Metadati | Documentare le ortoimmagini nel RNDT con metadati conformi. | Req. 16 LG AgID; art. 4 D. Lgs. 32/2010 |
3.17 Impianti di monitoraggio ambientale
Il tema riguarda l’ubicazione e il funzionamento delle strutture di monitoraggio ambientale (osservazione e misurazione di emissioni, stato dei mezzi ambientali, biodiversità, ecc.). Il monitoraggio è in capo al Sistema Nazionale per la Protezione dell’Ambiente (SNPA), con ISPRA coordinatore e le ARPA/APPA in rete; possono concorrere anche Comuni, enti di ricerca e privati. Per il GDU di riferimento rilevano in particolare le reti locali (es. qualità dell’aria) gestite con l'ARPA competente.
Requisito | Azione a carico del Comune di riferimento | Riferimento normativo/tecnico |
|---|---|---|
Modello dati e attributi | Identificare per ciascuna rete gli elementi essenziali e mapparli nel modello INSPIRE “Environmental Monitoring Facilities” (Environmental Monitoring Programme/Network/Facility/Activity, Operational Activity Period, Observing Capability). | All. Reg. (UE) 2023/138; Dir. 2007/2/CE (INSPIRE) |
Licenza | Applicare la licenza CC BY 4.0 (i dati delle reti SNPA sono per norma concessi con licenza aperta CC-BY). | art. 4 Reg. (UE) 2023/138; Req. 20-21 LG AgID |
Formato aperto | Rendere disponibili i dati in formati aperti (XML/GML, GeoJSON, GeoPackage, RDF), privilegiando la distribuzione tramite i servizi di rete INSPIRE. | Req. 2-3 LG AgID |
API e download in blocco | Esporre i dati tramite servizi WFS INSPIRE, Open Features API, Linked Open Data e ATOM Feed. | Req. 7, 27, 28 LG AgID |
Aggiornamento | Gestire la natura dinamica/real-time delle misurazioni (registrazioni giornaliere) e gli aggiornamenti annuali di alcuni parametri; rendere i dati dinamici disponibili tempestivamente. | Req. 5-6 LG AgID |
Metadati | Documentare tutti i dataset della rete con metadati di dataset nel RNDT. | art. 11 Dir. INSPIRE; Req. 16 LG AgID |
Vocabolari e semantica | Utilizzare i vocabolari INSPIRE, EEA e di dominio federati nel Sistema di Registri INSPIRE. | All. Reg. (UE) 2023/138 |
3.18 Aria
Il comparto comprende i dati richiesti dalla reportistica europea sull’inquinamento atmosferico, in particolare dalla Direttiva 2008/50/CE (qualità dell’aria ambiente) e dalla Direttiva 2004/107/CE (arsenico, cadmio, mercurio, nichel e IPA) rifuse nella Direttiva (UE) 2024/2881, con effetto dal 12 dicembre 2026: zone e agglomerati, regime e modalità di valutazione, misurazioni (anche near-real-time), piani per la qualità dell’aria e misure. I dati sono raccolti e validati dal MASE per il tramite di ISPRA (sistema InfoAria), anche su trasmissione di Regioni e ARPA, e armonizzati secondo il modello INSPIRE AC esteso (modello AQD dell’EEA).
Requisito | Azione a carico del Comune di riferimento | Riferimento normativo/tecnico |
|---|---|---|
Raccolta e trasmissione | Trasmettere i dataset di qualità dell’aria (zone/agglomerati, valutazione, misurazioni primarie convalidate e near-real-time E1a/E2a, piani e misure) tramite il sistema InfoAria, con invio automatizzato di file XML/GML via API o semi-automatizzato via CSV; valutare l’adozione del software OPAS (Open Air System). | Dir. 2008/50/CE; Dir. 2004/107/CE; All. Reg. (UE) 2023/138 |
Modello dati e attributi | Armonizzare i dati secondo il modello dati INSPIRE AC esteso, identificato con il modello AQD i cui schemi sono pubblicati dall’EEA. | All. Reg. (UE) 2023/138; modello AQD (EEA) |
Licenza | Applicare la licenza CC BY 4.0 (i dataset sono già aperti). | art. 4 Reg. (UE) 2023/138; Req. 20-21 LG AgID |
Formato aperto | Rendere disponibili i dati in formati aperti (CSV, XML/GML) e in download in blocco (GML, GeoPackage). | Req. 2-3 LG AgID |
API e download in blocco | Pubblicare i dati di qualità dell’aria tramite servizi WFS INSPIRE e applicazioni di consultazione. | Req. 7, 27, 28 LG AgID |
Aggiornamento | Garantire l’aggiornamento annuale dei dataset e la frequenza near-real-time (oraria/giornaliera) per i flussi E1a ed E2a. | Req. 5-6 LG AgID |
Metadati | Documentare nel RNDT i dataset geografici e completare la documentazione dei dataset non ancora presenti. | art. 11 Dir. INSPIRE; Req. 16 LG AgID |
3.19 Emissioni
Il comparto fa riferimento alle emissioni in aria, acqua e suolo previste da numerosi atti europei: Direttiva 2010/75/UE (emissioni industriali – IED), Direttiva 2012/18/UE (Seveso), Direttiva 91/676/CEE (nitrati), Direttiva (UE) 2016/2284 (NEC), Regolamento (CE) 166/2006 (registro E-PRTR) e Regolamento (UE) 2017/852 (mercurio). Diversi dataset, essendo geografici, sono mappabili sui temi INSPIRE “Produzione e impianti industriali”, “Impianti di monitoraggio ambientale” e “Zone sottoposte a gestione/limitazioni”; gli altri seguono le regole generali Open Data. I dati confluiscono nel Registro Europeo delle emissioni (EU Registry).
Requisito | Azione a carico del Comune di riferimento | Riferimento normativo/tecnico |
|---|---|---|
Soggetti e flussi | Avviare la verifica dei soggetti coinvolti e dell’interconnessione dei flussi con il Registro Europeo delle emissioni (EU Registry/E-PRTR); per le emissioni degli impianti regionali coordinarsi con la Regione; definire gli schemi dei flussi e degli attributi e verificare il disallineamento rispetto alle codifiche europee. | Dir. 2010/75/UE; 2012/18/UE; 91/676/CEE; (UE) 2016/2284; Reg. (CE) 166/2006; Reg. (UE) 2017/852 |
Modello dati e attributi | Mappare i dataset geografici verso i temi INSPIRE “Produzione e impianti industriali”, “Impianti di monitoraggio ambientale” e “Zone sottoposte a gestione/limitazioni/regolamentazione”. | All. Reg. (UE) 2023/138; Dir. 2007/2/CE (INSPIRE) |
Licenza | Identificare e applicare la licenza CC BY 4.0. | art. 4 Reg. (UE) 2023/138; Req. 20-21 LG AgID |
Formato aperto | Superare la distribuzione in soli formati XML/PDF, rendendo disponibili i dati anche in formati aperti come CSV e JSON. | Req. 2-3 LG AgID |
API e download in blocco | Implementare API coerenti con le indicazioni nazionali ed europee. | Req. 7, 27 LG AgID |
Aggiornamento | Aggiornare i dataset secondo le frequenze previste dai regolamenti europei e dal coordinamento nazionale/locale. | Req. 5-6 LG AgID |
Metadati | Documentare i dati nel portale nazionale dei dati aperti secondo il profilo pertinente (es. DCAT-AP_IT) e, per i dati territoriali, nel RNDT. | Req. 16 LG AgID |
3.20 Dati relativi alla mobilità
I dati relativi alla mobilità (traffico, trasporto pubblico locale, flussi pedonali, reti di trasporto) rappresentano fenomeni dinamici legati alle reti di trasporto e costituiscono una componente centrale del GDU. Fra questi rientrano nelle serie di dati di elevato valore soltanto le reti di trasporto del tema INSPIRE (allegato del regolamento di esecuzione (UE) 2023/138, § 6); gli altri dati di mobilità (flussi di traffico e pedonali, trasporto pubblico locale, parcheggi) si pubblicano come dati aperti ordinari o secondo la disciplina di settore sui sistemi di trasporto intelligenti. La tabella di sintesi che segue riepiloga gli adempimenti applicabili al Comune di riferimento per questa categoria di dati.
3.21 Tabella di sintesi degli adempimenti
La seguente tabella riassume, sulla base delle indicazioni della Tabella 2 delle Linee Guida AgID e del Regolamento (UE) 2023/138, le prescrizioni operative applicabili al Comune di riferimento per i dati di mobilità gestiti nell’ambito del Gemello Digitale Urbano.
Adempimento | Contenuto | Riferimento normativo |
|---|---|---|
Disponibilità gratuita | Le serie di dati di mobilità devono essere messe a disposizione gratuitamente per il riutilizzo commerciale e non commerciale | Reg. (UE) 2023/138; Req. 8 LG AgID |
Licenza aperta | Applicare licenza CC BY 4.0 o equivalente aperta; vietato l’uso di licenze proprietarie o che escludano usi commerciali | Req. 20, 21 LG AgID |
Formato aperto | Dati in formato aperto leggibile meccanicamente (≥ 3 stelle), riconosciuto UE o internazionale | Req. 2, 3 LG AgID |
API e download in blocco | Distribuzione tramite API conformi al Requisito 27 e, se del caso, attraverso download in blocco | Req. 7 LG AgID; art. 6 c. 8 D. Lgs. 36/2006 |
Aggiornamento tempestivo | Dati dinamici di mobilità resi disponibili immediatamente dopo la raccolta; eventuali ritardi formalmente motivati | Req. 5, 6 LG AgID |
Metadati INSPIRE | Metadati conformi alle LG RNDT e contenenti almeno gli elementi del Reg. (CE) 1205/2008 | Art. 11 Dir. INSPIRE; art. 4 D. Lgs. 32/2010; Req. 16 LG AgID |
Regole tecniche INSPIRE | Applicare le regole tecniche del framework INSPIRE/D. Lgs. 32/2010 per i dati territoriali di mobilità | Req. 14 LG AgID; D. Lgs. 32/2010 |
Documentazione online | Documentazione pubblica della struttura e semantica dei dataset di mobilità | Par. 5.1.5 LG AgID |
Vocabolari controllati | Utilizzo di vocabolari e tassonomie controllati riconosciuti UE o internazionali, ove disponibili | Par. 5.1.4 LG AgID; Reg. (UE) 2023/138 |
Condivisione inter-PA | Libero accesso ai dataset tra PA; nessuna tariffa per PA nazionali/UE che adempiono obblighi ambientali; nessun ostacolo pratico alla condivisione | Art. 17 Dir. INSPIRE; art. 10 D. Lgs. 32/2010 |
Procedura di riutilizzo | Definire e applicare una procedura per la gestione delle richieste di riutilizzo dei dati nei termini previsti dalla normativa | Req. 18 LG AgID; art. 5 D. Lgs. 36/2006 |
Nota sul Gemello Digitale | Il Gemello Digitale Urbano può fungere da ambiente unico per la raccolta, la verifica e la pubblicazione dei dati di mobilità conformi agli obblighi INSPIRE e al Regolamento (UE) 2023/138, sfruttando l’integrazione di dati provenienti da molteplici fonti (reti di trasporto, sensori IoT, dati di traffico) e la capacità di esposizione tramite API e standard OGC, complementari all’architettura richiesta dalle Linee Guida AgID. |
3.22 Realizza un piano di ricognizione e gestione dei dati (PdRGD)
La finalità è analizzare e sviluppare il Gemello Digitale Urbano fin dalle fasi iniziali, attraverso la predisposizione di un “Piano di Ricognizione e Gestione dei Dati (PdRGD)” (usa lo Schema n.1_ PdRGD — Dati Non Personali).
In tale piano devono essere chiaramente definiti i dati, includendo la loro provenienza, le modalità di organizzazione e trattamento, nonché le misure previste per l’accesso, la conservazione, la condivisione e l’eventuale cancellazione, sia durante lo svolgimento del progetto sia al suo termine.
È necessario ricordare, per la corretta comprensione di quanto si richiede dal punto di vista giuridico, che il GDU rilasciato dallo sviluppatore debba essere adeguato allo scopo anche oltre la durata del progetto.
Per tale ragione è necessaria la corretta individuazione dei dati, in input ed in output e dei database/dataset da rilasciare al Comune.
In generale, il management dei dati sopra descritto non implica necessariamente apertura dei dati; l’apertura dei dati non costituisce una tappa obbligatoria per ogni tipologia di dati. Certo è che per ampliare la loro potenzialità conoscitiva, garantirne l’integrazione e mantenerne il futuro riutilizzo, l’apertura è, ad oggi, un’azione fortemente opportuna, soprattutto nel caso di attività progettuali, come quelle del progetto UISH, in cui i dati devono essere resi disponibili e fruibili alla/dalla Pubblica Amministrazione.
Gli elementi del dato (caratterizzazione, tipo e caratteristiche) rappresentano il punto di convergenza tra le soluzioni tecniche e logico-architetturali dell’infrastruttura digitale e la percorribilità di certe soluzioni giuridiche/legali dirette all’apertura e riutilizzo. Detto altrimenti, soltanto quei dataset/dati creati o raccolti che presentano specifici attributi funzionali saranno oggetto di licenze e accordi di apertura.
Implementare una corretta strategia di analisi e verifica dell’affidabilità dei dati a supporto delle decisioni della PA, significa affiancare al processo tipico della Data Verification (che è volto a garantire l’accuratezza e la qualità dei dati) un procedimento che potrebbe essere definito “Law Data Verification”, ovvero una valutazione/validazione delle fonti di dati dal punto di vista:
- della legalità ed eticità dell’acquisizione e
- delle caratteristiche FAIR se e quando applicabili, nonché dei criteri per la affidabilità dei dati desumibili dalle regole sulla IA.
Focus box
Apertura dei dati e riutilizzo dell’informazione del settore pubblico
La condivisione dei dati costituisce un elemento essenziale ai fini della gestione e della valorizzazione dei GDU. In tale prospettiva, le licenze aperte rappresentano lo strumento privilegiato per consentire la diffusione e il riutilizzo dei dati, in conformità con la Direttiva (UE) 2019/1024 (Open Data), che ne promuove l’impiego da parte delle Pubbliche Amministrazioni, pur lasciando a queste ultime un margine di discrezionalità nella scelta della specifica soluzione licenziataria.
La produzione e l’acquisizione di dati legano a doppio filo lo sviluppatore del GDU al principio dell’apertura dei dati e al riutilizzo delle informazioni del settore pubblico. Ciò non soltanto in adempimento di principi generali che governano l’azione pubblica (trasparenza, buon andamento, correttezza, efficacia ed efficienza) ma a maggior ragione nel rispetto di quanto stabilito dalla Direttiva (UE) 2019/1024 e del decreto legislativo 8 novembre 2021, n. 200 relativo all’attuazione della direttiva (UE) 2019/1024 relativa all’apertura dei dati e al riutilizzo dell’informazione del settore pubblico.
Questo significa che:
- Lo sviluppatore del GDU deve seguire il principio generale secondo cui i dati pubblici e quelli finanziati con fondi pubblici dovrebbero essere riutilizzabili.
- È promosso l’utilizzo di dati aperti.
- Ciò significa dati presentati in formati aperti utilizzabili liberamente e condivisibili:
- Vanno scelte le forme elettroniche che ne rendano il riutilizzo possibile e opportuno entro un lasso di tempo necessario per la realizzazione e sostenibilità del GDU;
- Devono essere fornite informazioni sui diritti relativi agli output;
- Deve essere facilitata la ricerca e il reperimento online
- Vanno comunque tenute in considerazione le questioni attinenti a diritti di proprietà intellettuale, protezione dei dati personali e riservatezza, sicurezza e legittimi interessi commerciali che implicano che l’azione di rilascio avvenga nel rispetto del principio:
- “IL PIÙ APERTO POSSIBILE, CHIUSO IL TANTO NECESSARIO”
- I dati devono essere messi a disposizione tramite formati aperti, leggibili meccanicamente, accessibili, reperibili e riutilizzabili insieme ai rispettivi metadati e secondo i principi FAIR:
- Findable (i dati devono essere facilmente rintracciabili nel web)
- Accessible (i dati devono essere accessibili)
- Interoperable (i dati devono poter essere utilizzabili da diversi software e piattaforme)
- Reusable (i dati devono essere riutilizzabili per scopi economici e non economici).
- Per raggiungere questo risultato è necessario costruire una tabella FAIR dei dati (Scheda FAIR, par. 3.33.1 del PdRGD).
- Le informazioni che riguardano la FAIR dei dati di output usate nella tabella richiamata derivano dal documento denominato "How FAIR are your data?"
- Autori: Sarah Jones (Digital Curation Centre) & Marjan Grootveld (DANS)
Prodotto per la EUDAT Summer School (finanziamento EU: EUDAT2020, grant 654065)
Licenza: CC BY 4.0, Jones, S. & Grootveld, M. (2021). How FAIR are your data? Zenodo. https://doi.org/10.5281/zenodo.5111307, e che qui in calce sono riportate tradotte.
Findable / Rintracciabili
- È stato assegnato un identificatore persistente (es. DOI, Handle, URN) al dataset?
- Se si, potete riportarlo qui di seguito?
- Il dataset è stato descritto con metadati esaustivi, informativi e accurati?
- Se si, potete fornire qui questi elementi?
- I metadati sono registrati in un catalogo online o in un data repository che sia indicizzato dai motori di ricerca?
- Se si, potete riportarlo qui di seguito?
- Fra i metadati è incluso anche l'identificatore persistente assegnato al dataset?
- Se si, potete riportarlo qui di seguito?
Accessible / Accessibili
- L'identificatore persistente associato al dataset risolve correttamente alla pagina dei metadati del dataset?
- Se si, potete riportarlo qui di seguito?
- Il protocollo di recupero dei dati e dei metadati rispetta un linguaggio standardizzato e riconosciuto come ad esempio quello delle pagine web (HTTP)?
- Se si, potete riportarlo qui di seguito?
- I metadati sono sempre pubblici, visibili e indicizzabili anche se i dati non sono in open access o non lo sono più?
- Se si, potete inserire informazione di dettaglio qui di seguito?
Interoperable / Interoperabili
- I dati sono resi disponibili in formati aperti o almeno in formati documentati e diffusi?
- I metadati seguono schemi standard riconosciuti e condivisi?
- Se si, potete riportarlo qui di seguito?
- Sono stati utilizzati quanto più possibile vocabolari controllati tesauri o ontologie?
- Se si, potete riportarlo qui di seguito?
- Sono resi disponibili link o relazioni con altre risorse rilevanti per la comprensione dei dati come pubblicazioni o rapporti tecnici o applicazioni software?
- Se si, potete riportarlo qui di seguito?
Re-usable/Riutilizzabili
- I dati sono accurati, completi e descritti in modo che siano facilmente comprensibili e riproducibili?
- Al dataset è stata attribuita una licenza che ne specifica le possibilità di riutilizzo?
- Se si, potete riportarlo qui di seguito?
- Al dataset è stata attribuita una licenza diversa dalla precedente?
- Se si, potete riportarlo qui di seguito?
- Sono chiare dai metadati e dalla documentazione allegata le responsabilità scientifiche e finalità dei dati prodotti?
- Quale è il dominio di ricerca di riferimento?
- I dati e i metadati rispettano gli standard e i protocolli di qualità del dominio di ricerca di riferimento?
3.23 Guida alla Compatibilità delle Licenze
La scelta della licenza di rilascio del dataset in output dipende dalle licenze dei dataset di origine (input). Prima di definire la licenza, lo sviluppatore deve mappare le licenze di tutti i dati in input utilizzati e verificarne la compatibilità con quella con cui vorrebbe rilasciare il database/dataset finale.
È possibile che i dati in Input (siano essi primari che secondari) siano già sottoposti ad una licenza d’uso, per esempio anche i dati che derivano da rilevamenti fatti su commissione, ovvero da elaborazioni e prodotti derivati (mappe, indicatori, tabelle) e/o ottenuti da fonti soggette a vincoli i cui contenuti derivano da contratti stipulati anche dalla stessa amministrazione comunale. Ci si deve sempre accertare della licenza che caratterizza i dati d’ingresso, qualunque sia la provenienza. Senza questa consapevolezza non si potrà mai procedere ad assegnare correttamente una licenza d’Output e, sicuramente, non si potranno mai aprire i database/dataset prodotti, così come i software.
Anche i software sviluppati nell’ambito dei GDU necessitano dell’individuazione della licenza di rilascio più adeguata da parte delle Pubbliche Amministrazioni (si veda la sezione 6, «Ora che hai qualificato il tuo software come IA o Deterministico, fai la ricognizione dei software in consegna alla PA»).
Quando per ogni dato di input si conosce la licenza, allora si può procedere alla sua analisi ai fini dell’assegnazione finale di quanto è considerabile output ai fini dell’esistenza del GDU.
Per far questo, emergono rilevanti criticità applicative.
Nel contesto italiano, le Pubbliche Amministrazioni ricorrono principalmente a licenze Creative Commons e alla Italian Open Data Licence (IODL). In ogni caso nel mondo si rintraccia la presenza di oltre quattrocento modelli di licenze open data, spesso tra loro incompatibili, e che determina un significativo grado di frammentazione normativa. Una particolare attenzione, poi, va posta agli effetti delle licenze lungo la catena del valore dell’intelligenza artificiale, situazione ulteriormente aggravata dall’assenza di una definizione condivisa del concetto di “open” in ambito IA e dalla diffusione di pratiche di open-washing da parte degli operatori economici. Assume particolare rilievo l’approfondimento del fenomeno della cosiddetta “viralità” delle licenze open source lungo la catena del valore dell’intelligenza artificiale applicata ai GDU. Più precisamente, si tratta di valutare in che misura licenze di tipo copyleft, quali la GNU General Public License (GPL), possano imporre obblighi di rilascio dell’intero sistema derivato nel caso in cui componenti open source vengano integrate nei modelli o nei dataset utilizzati per l’addestramento dei sistemi di IA. L’obiettivo è quello di prevenire fenomeni di incompatibilità a cascata suscettibili di compromettere le strategie di condivisione e valorizzazione dei GDU.
Principi chiave per la compatibilità delle licenze |
1.Partire dalle condizioni di licenza dei dataset in ingresso. La licenza di uscita non può essere più permissiva di quanto consentito dalle licenze in ingresso. |
2.Attenzione alle clausole 'share alike' (SA): se un dataset in ingresso ha licenza SA (es. ODbL di OSM, CC BY-SA), il database in uscita deve avere la stessa licenza (o compatibile). Questo può limitare la scelta della licenza di uscita. |
3.Distinzione tra: (a) opere derivate — database 'mescolati' soggetti alla SA; (b) collezioni di database — database affiancati non mescolati, di norma NON soggetti alla SA; (c) layer — sovrapposizione di strato autonomo che non genera di per sé una base dati derivata. |
4.Se si utilizzano dati open con licenze compatibili, è possibile mantenere aperto l’intero flusso (dati, processi e output), favorendo interoperabilità e innovazione; tuttavia, la possibilità di rilasciare dataset derivati con licenze open dipende dai vincoli delle licenze originali e da eventuali altre restrizioni. |
5.In caso di incertezza o incompatibilità: verificare indicazioni del titolare; valutare autorizzazione ad hoc; in alternativa, valutare se rinunciare all'uso di quel dataset. |
6.Per nuovi database realizzati con terzi (consulenti, fornitori): garantire la titolarità in capo all'ente senza restrizioni; esplicitare 'by design' il rilascio come open data; escludere esclusive a favore del fornitore. |
FOCUS BOX
Effettua il giudizio di Compatibilità delle licenze
Per fare il test di compatibilità ti consigliamo di usare i seguenti strumenti messi a disposizione dalla CE:


“L’utilizzo di licenze standard favorisce, infine, l’immediata comprensibilità delle stesse e l’uniformità nel loro riutilizzo”36.
È stato realizzato un tool che riassume le indicazioni dell’Agid sulle licenze da adottare in tema di dati aperti. Pur rinviando alla lettura completa del testo, per una consultazione orientativa si può utilizzare il seguente sistema:

ANNOTAZIONE |
Questa parte del testo è funzionale a completare la parte della Tabella presente nel PdRGD denominata “Scheda FAIR” (par. 3.33.1), la cui parte a cui si fa riferimento si riporta per memoria qui in calce |
LICENZE DI RILASCIO E CONDIZIONI D'USO | |
Licenza in ingresso (dati secondari) | [Da compilare — licenza del/dei dataset di origine] Verificare compatibilità prima di scegliere la licenza di uscita. |
Licenza di rilascio (output) | [Da compilare — es. CC BY 4.0 / IODL 2.0 / CC0] Raccomandazione: non scegliere la licenza senza prima averne verificato la compatibilità. |
Condizioni d'uso | [Da compilare — dipende dalla licenza scelta sopra] |
3.24 Guida Compatibilità delle Licenze dei dati Geospaziali e HVD
Come sopra ricordato, le serie di dati di elevato valore devono essere rese disponibili al pubblico secondo il principio generale della gratuità, che costituisce la regola fondamentale stabilita dal quadro normativo europeo. Tali dati devono essere accessibili senza costi e distribuiti attraverso una licenza aperta, in particolare la licenza Creative Commons BY 4.0 oppure un’altra licenza equivalente o ancora meno restrittiva, in modo da garantire la massima possibilità di riutilizzo da parte di chiunque.
Eventuali deroghe a questo principio di gratuità sono ammesse solo in casi eccezionali e tassativamente individuati dal Regolamento (UE) 2023/138, che delimita in modo rigoroso le situazioni in cui può essere consentita l’applicazione di tariffe. Anche in tali circostanze, tuttavia, il pagamento non riguarda l’accesso ai dati in quanto tali, bensì eventuali servizi aggiuntivi connessi al loro utilizzo. In particolare, le pubbliche amministrazioni possono richiedere un corrispettivo nell’esercizio di pubblici poteri, ad esempio quando forniscono servizi di certificazione dell’autenticità oppure di attestazione della veridicità dei documenti.
Per quanto riguarda la condivisione tra amministrazioni pubbliche, l’articolo 10 del decreto legislativo n. 32 del 2010 stabilisce un principio di piena cooperazione istituzionale. Le autorità pubbliche devono poter accedere liberamente ai dataset territoriali detenuti da altre amministrazioni e sono tenute a condividerli senza imporre nuovi o maggiori oneri a carico della finanza pubblica. Inoltre, tale scambio deve avvenire senza ostacoli pratici che possano compromettere o rallentare l’effettivo utilizzo dei dati.
Infine, quando i dataset vengono forniti ad altre pubbliche amministrazioni o a istituzioni dell’Unione europea per adempiere a obblighi in materia ambientale, essi non possono in alcun caso essere assoggettati a tariffe. In tali situazioni, infatti, prevale l’esigenza di garantire la circolazione libera e gratuita delle informazioni, al fine di assicurare il corretto adempimento degli obblighi normativi e la tutela dell’interesse pubblico.
Licenza in ingresso | Licenza di uscita possibile | Vincolo principale |
CC0 (Public Domain) | Qualsiasi licenza (incluso CC0, CC BY, IODL, proprietaria) | Nessun vincolo |
CC BY 4.0 | CC BY 4.0, IODL 2.0, CC BY-SA 4.0 | Solo attribuzione |
IODL 2.0 | CC BY 4.0, IODL 2.0, equivalenti aperti | Solo attribuzione |
CC BY-SA 4.0 | Solo CC BY-SA 4.0 o licenze compatibili SA | Share-alike obbligatorio |
ODbL (OpenStreetMap) | ODbL per il database; CC BY o altra per i contenuti prodotti | Share-alike per il database |
Proprietaria / licenza d'uso limitata | Uso interno; nessun rilascio open senza autorizzazione del titolare | Verifica contratto necessaria |
Dati senza licenza o autore non identificabile | Non utilizzabile (escludere a priori) | Rischio IPR non gestibile |
3.25 Suggerimenti operativi su licenze e condizioni di riutilizzo
Coerentemente con il Considerando 12 del Regolamento (UE) 2023/138, l’obiettivo della Direttiva (UE) 2019/1024 è promuovere l’uso di licenze pubbliche standard disponibili online. L’art. 4 del Regolamento indica come licenze standard per il riutilizzo la Creative Commons Public Domain Dedication (CC0) o, in alternativa, la Creative Commons BY 4.0, ovvero qualsiasi licenza aperta equivalente o meno restrittiva, senza restrizioni ulteriori rispetto all’eventuale sola attribuzione. Sono ammesse licenze “equivalenti” anche con disposizioni aggiuntive, purché non limitino le possibilità di riutilizzo rispetto al livello minimo di apertura predefinito.
Per alcune categorie di HVD — in particolare i dati geospaziali — alle previsioni Open Data si sommano quelle della Direttiva 2007/2/CE (INSPIRE), riferimento primario per metadati, dati e servizi geografici. La natura del dato geografico rende le relative basi di dati tutelabili tendenzialmente solo secondo il c.d. “diritto sui generis”: ciò suggerisce l’adozione della licenza più aperta possibile, anche perché il riutilizzo di una base dati geografica si configura spesso come estrazione “sostanziale” (se non totale) del database, coinvolgendo proprio le esclusive del diritto sui generis.
In caso di riutilizzo di basi di dati di terzi, l’analisi preventiva deve: partire dalle condizioni di licenza delle basi dati che si intende utilizzare; in caso di creazione di database con la collaborazione di terzi, definire contrattualmente, con chiarezza, titolarità e disponibilità del database; approfondire l’interpretazione del titolare di clausole e licenze (anche tramite FAQ ufficiali); confrontare tale interpretazione con le modalità di (ri)utilizzo necessarie.
Nella valutazione di compatibilità tra database rilevano nozioni quali opera derivata, “collezioni di database” (database affiancati e non “mescolati”, di norma non soggetti alla clausola share alike), “layer” (sovrapposizione di uno strato informativo autonomo, che non genera di per sé una base dati derivata) ed estrazione “sostanziale”. In caso di dubbio si consiglia una posizione prudenziale, applicando la licenza di origine o quelle compatibili secondo le matrici delle Linee Guida Open Data.
A titolo esemplificativo, la base dati di OpenStreetMap (OSMF) è rilasciata con licenza ODbL, che contiene la clausola “share alike”: se una PA acquisisse dati in misura “sostanziale” da OSM per costituire una propria base dati geografica, dovrebbe rilasciare il proprio database sotto ODbL, potendo rilasciare con propria licenza (sola attribuzione) esclusivamente la mappa derivata — con pesanti vincoli al successivo riutilizzo, in contrasto con il quadro strategico su open data e HVD. Si raccomanda pertanto di sostituire le clausole SA con le licenze indicate, anche per i database preesistenti.
In sintesi, si raccomanda di:
- adottare licenze che permettano una circolazione fluida e multilivello del dato geografico, prive di dubbi interpretativi;
- in caso di riutilizzo di database di terzi: mapparne preventivamente le licenze; escludere a priori le basi dati prive di licenza o di autore identificabile; individuare le condizioni di potenziale conflitto (clausole ND, NC, SA) e analizzarne rilasciabilità e compatibilità con CC BY 4.0;
- in caso di incertezza o potenziale incompatibilità: verificare FAQ e indicazioni formali del titolare; valutare l’acquisizione di un’autorizzazione ad hoc; in alternativa, valutare la possibilità/necessità di non utilizzare quel database;
- in caso di nuovi database realizzati con terzi (consulenti, fornitori): garantire la titolarità in capo all’ente senza restrizioni; esplicitare “by design” il rilascio come open data e le licenze da adottare; escludere esclusive d’uso a favore del fornitore (salvo eccezioni normate); assicurare formati e qualità compatibili e la tracciabilità delle licenze dei database terzi utilizzati;
- adottare modalità di “attribution” semplici e omogenee per prevenire lo “stack of attribution” (es. attribuzione soddisfatta richiamando il nome dell’Ente nei crediti), valutando un modello di “attribution standard” condiviso tra più PA.
Raccomandazione finale sulle licenze HVD |
Per tutti i dati HVD del GDU: adottare CC BY 4.0 o IODL 2.0 come licenza standard di rilascio. |
Adottare modalità di attribuzione semplici e omogenee per evitare lo 'stack of attribution': |
→ attribuzione soddisfatta richiamando il nome dell'Ente nei crediti |
→ valutare un modello di 'attribution standard' condiviso tra i partner del progetto. |
3.26 Schema n. 1 – PdRGD — Dati Non Personali
Piano di Ricognizione e Gestione dei Dati
PdRGD — Dati Non Personali
──────────────────────────────────────
[NOME PROGETTO / COMUNE]
[Versione X.X] — [Data]
Campo | Dettaglio |
Titolo | Piano di Ricognizione e Gestione dei Dati — Dati Non Personali (PdRGD-DNP) |
Progetto GDU | [Nome del progetto] |
Ente committente / Comune | [Nome del Comune / PA] |
Sviluppatore GDU | [Nome soggetto sviluppatore] |
Data Steward | [Nome, ruolo, contatto] |
Versione | 1.0 |
Data di emissione | [GG/MM/AAAA] |
Stato | Bozza / In revisione / Approvato |
Indice PdRGD
- 3.27 Introduzione e principi
- 3.28 Ricognizione dei dataset/database da consegnare al Comune
- 3.29 Schede di qualificazione
- 3.30 Dati di Elevato Valore (HVD) nel GDU — Obblighi e adempimenti
- 3.31 Audit di conformità HVD e INSPIRE
- 3.32 Law Data Verification
- 3.33 Schede FAIR
- 3.34 Trasferimento dei dataset al Comune
- 3.35 Checklist operativa
- 3.36 Registro versioni e approvazione
3.27 Introduzione e principi
Il Piano di Ricognizione e Gestione dei Dati (PdRGD) definisce l'iter metodologico e operativo per la gestione dei dati non personali prodotti, acquisiti o utilizzati nell'ambito del progetto di Gemello Digitale Urbano (GDU). Il documento si articola in cinque fasi progressive obbligatorie, applicabili a ogni dataset/database/catalogo che sarà consegnato al Comune.
Le cinque fasi del PdRGD-DNP |
1.RICOGNIZIONE — Identificare e registrare tutti i dataset/database da consegnare al Comune. |
2.SCHEDA DI QUALIFICAZIONE — Per ogni dataset: caratteristiche, provenienza e licenze. |
3.LAW DATA VERIFICATION — Verificare la legalità, l'eticità e l'affidabilità di ogni dataset. |
4.OPENABILITY CHECK — Decidere se il dataset può essere aperto (open data) o deve restare chiuso. |
5.SCHEDA FAIR — Per ogni dataset apribile: compilare la scheda FAIR completa (Findable, Accessible, Interoperable, Reusable). |
Il principio guida |
"PIÙ APERTO POSSIBILE, CHIUSO IL TANTO NECESSARIO" |
Restrizioni all'apertura sono giustificate solo da: vincoli contrattuali insuperabili con fornitori terzi; esigenze di sicurezza; diritti di proprietà intellettuale di terzi non risolvibili con licenza compatibile. |
Normativa: Dir. (UE) 2019/1024 | D. Lgs. 200/2021 | Reg. (UE) 2023/2854 (Data Act) | Reg. (UE) 2023/138 (HVD) | Linee Guida Open Data AgID (2023) |
3.28 Ricognizione dei dataset/database da consegnare al Comune
Questa sezione contiene il Registro completo di tutti i dataset, database e cataloghi che lo sviluppatore del GDU è tenuto a consegnare al Comune al termine del progetto. Per ogni elemento del registro deve essere compilata la Scheda di Qualificazione (par. 3.29), eseguita la Law Data Verification (par. 3.32) e, se apribile, la Scheda FAIR (par. 3.33).
3.28.1 Registro dei dataset da consegnare
ID | Denominazione | Categoria | Tipo (primario / secondario / misto) | Formato consegna | Fase compilata |
D001 | [Da compilare] | [Da compilare] | [Da compilare] | [Da compilare] | ☐ Sched. ☐ LDV ☐ FAIR |
D002 | [Da compilare] | [Da compilare] | [Da compilare] | [Da compilare] | ☐ Sched. ☐ LDV ☐ FAIR |
D003 | [Da compilare] | [Da compilare] | [Da compilare] | [Da compilare] | ☐ Sched. ☐ LDV ☐ FAIR |
D004 | [Da compilare] | [Da compilare] | [Da compilare] | [Da compilare] | ☐ Sched. ☐ LDV ☐ FAIR |
D005 | [Da compilare] | [Da compilare] | [Da compilare] | [Da compilare] | ☐ Sched. ☐ LDV ☐ FAIR |
... | Aggiungere righe secondo necessità |
3.28.2 Flusso di lavoro per dataset
Fase | Strumento (paragrafo) | Esito atteso | Obbligatorio per |
Scheda di Qualificazione | 3.29 | Caratteristiche, provenienza e licenza documentate | Tutti i dataset |
Law Data Verification | 3.32 | Verifica legalità, eticità, affidabilità, openability | Tutti i dataset |
Scheda FAIR | 3.33 | Certificazione FAIR e apertura dati | Solo dataset apribili (esito D. positivo in LDV) |
Input Dataset Sub-Scheda | 3.33.1 (dati secondari input) | Documentazione dei dataset secondari in ingresso | Solo per dataset con dati secondari |
3.29 Schede di qualificazione
Compilare una scheda per ogni dataset/database/catalogo del Registro (par. 3.28.1). Le schede costituiscono il riferimento documentale per la Law Data Verification e per la decisione di apertura.
3.29.1 Scheda di qualificazione — D001
SCHEDA DI QUALIFICAZIONE — D001: [Denominazione dataset] | |
1. IDENTIFICAZIONE | |
ID Dataset | D001 |
Denominazione | [Denominazione dataset] |
Categoria (es. geospaziale, IoT, mobilità...) | [Da compilare] |
Descrizione sintetica del contenuto | [Da compilare] |
Da consegnare al Comune? | ☐ Sì ☐ No ☐ Parzialmente |
Formato di consegna | [Da compilare — es. SHP, GeoJSON, CSV, CityGML, LAS...] |
2. PROVENIENZA | |
Origine | ☐ Solo dati primari ☐ Solo dati secondari ☐ Dati misti |
Autore / produttore originale | [Da compilare] |
Titolare del dato | [Da compilare — es. Comune / CNR-IMATI / DIITET / fornitore terzo] |
Modalità di acquisizione | ☐ Produzione diretta ☐ Open data ☐ Convenzione PA ☐ Acquisto ☐ Affidamento ☐ API |
Titolo contrattuale / riferimento atto | [Da compilare — es. Affidamento DIITET a START4.0 del GG/MM/AAAA] |
Finanziamento (progetto / fondi pubblici?) | [Da compilare — es. Progetto UISH, fondi [tipo]] |
3. LICENZE E DIRITTI | |
Licenza in ingresso (se secondari) | [Da compilare — es. CC BY 4.0 / ODbL / proprietaria / nessuna (primari)] |
Restrizioni della licenza in ingresso | [Da compilare — es. share-alike / no commerciale / solo uso interno] |
IPR di terzi? | ☐ Sì — specificare:___________ ☐ No |
Clausole contrattuali che limitano il rilascio? | ☐ Sì — specificare:___________ ☐ No |
Licenza di rilascio prevista (output) | [Da compilare dopo Law Data Verification] |
4. CARATTERISTICHE TECNICHE | |
Formato / standard tecnico | [Da compilare] |
Sistema di riferimento / proiezione | [Da compilare — es. WGS84 / ETRS89 / UTM32N] |
Periodo temporale coperto | [Da compilare — es. 2022–2024 / snapshot del GG/MM/AAAA] |
Copertura geografica | [Da compilare — es. Centro storico di ___, area C...] |
Dimensione stimata | ☐ < 100 MB ☐ ~100 MB ☐ > 100 MB ☐ Altro:_______ |
Software di gestione | [Da compilare] |
5. QUALITÀ | |
Il dataset è validato? | ☐ Sì (da chi / come:___________) ☐ No ☐ In corso |
Limitazioni note o lacune | [Da compilare] |
Aggiornamento previsto? | ☐ Sì (frequenza:___________) ☐ No ☐ Solo per il progetto |
[Duplicare la sezione per ogni dataset aggiuntivo nel Registro]
3.30 Dati di Elevato Valore (HVD) nel GDU — Obblighi e adempimenti
I dati di elevato valore (High Value Datasets – HVD) sono quei dataset il cui riutilizzo è associato a importanti benefici per la società, l'ambiente e l'economia. Nei GDU, questa categoria riguarda principalmente tre tipologie presenti in quasi ogni progetto: dati geospaziali, dati di osservazione della terra e dell'ambiente, dati relativi alla mobilità.
Obblighi fondamentali per i dati HVD (Reg. UE 2023/138 + Dir. 2019/1024) |
1.Rilascio GRATUITO — nessun costo per il riutilizzo, commerciale o non commerciale. |
2.LICENZA APERTA — CC BY 4.0, CC0 o licenza equivalente/meno restrittiva. Vietate licenze proprietarie. |
3.FORMATO APERTO — leggibile meccanicamente, almeno 3 stelle (criterio delle Linee guida AgID) (es. CSV, JSON, GeoJSON, GML, GeoPackage). |
4.API — distribuzione tramite API conformi alle Linee Guida AgID (Req. 27); documentazione in formato aperto (OpenAPI/WSDL). |
5.DOWNLOAD IN BLOCCO — da garantire sempre; per dati dinamici: aggiornamento immediato dopo ogni raccolta. |
6.METADATI — documentazione obbligatoria nel RNDT (dati territoriali) o su dati.gov.it (altri HVD), conformi a ISO 19115 / DCAT-AP IT. |
7.SEMANTICA — vocabolari controllati e tassonomie standard (INSPIRE, EEA, GEMET). |
3.30.1 Dati HVD presenti nel GDU: categorie e classificazione
Categoria HVD | Esempi tipici nel GDU | INSPIRE? | Licenza obbligatoria | Formato minimo |
Dati geospaziali | Unità amministrative, nomi geografici, indirizzi, edifici, parcelle catastali, reti stradali | Sì — Annessi I e II | CC BY 4.0 o CC0 | GML, GeoJSON, GeoPackage (≥3★) |
Osservazione terra e ambiente — Ortoimmagini | Ortofoto aeree/satellitari georif., nuvole di punti LiDAR, modelli altimetrici | Sì — Ann. II | CC BY 4.0 o CC0 (verificare diritti terzi) | GeoTIFF, JPEG2000 |
Osservazione terra e ambiente — Monitoraggio | Ubicazione e dati delle stazioni di monitoraggio ambientale (aria, acqua, suolo) | Sì — Ann. III | CC BY 4.0 | XML/GML, GeoJSON, RDF |
Osservazione terra e ambiente — Aria | Zone/agglomerati, misurazioni qualità aria, modelli di dispersione | Sì — modello AQD (EEA) | CC BY 4.0 | CSV, XML/GML, GeoPackage |
Osservazione terra e ambiente — Emissioni | Emissioni industriali, registro E-PRTR, impianti IED/Seveso | Sì — Ann. III | CC BY 4.0 | CSV, JSON (superare PDF/XML proprietario) |
Dati relativi alla mobilità | Reti di trasporto (tema INSPIRE; allegato del Reg. 2023/138, § 6). Flussi veicolari e pedonali, TPL (GTFS) e dati sui parcheggi non sono HVD: si pubblicano come dati aperti ordinari o secondo la disciplina di settore sui sistemi di trasporto intelligenti | Sì (reti) | CC BY 4.0 | GTFS, GeoJSON, CSV, formati aperti ≥3★ |
3.31 Audit di conformità HVD e INSPIRE
La seguente checklist costituisce uno strumento di audit interno per verificare la conformità del GDU al quadro INSPIRE + Open Data + HVD. Va compilata congiuntamente da sviluppatore e Comune prima della consegna finale.
AUDIT INTERNO — Dati territoriali e dati di elevato valore (HVD) |
1. IDENTIFICAZIONE DEI DATI 1.1 – Inventario ☐ Il Comune ha identificato tutti i dataset disponibili? ☐ I dati sono classificati per tipologia (geospaziali, mobilità, ambiente)? 1.2 – Classificazione normativa ☐ È stato verificato se i dati rientrano in: dati territoriali INSPIRE? ☐ È stato verificato se i dati rientrano in: dati di elevato valore HVD? ☐ È noto se i dati rientrano in una categoria del Regolamento UE 2023/138? |
2. GOVERNANCE E TITOLARITÀ ☐ È chiaro chi è il titolare dei dati? ☐ È definito il responsabile della pubblicazione? ☐ Esiste coordinamento con: Regione? ☐ Esiste coordinamento con: Ministeri? ☐ Esiste coordinamento con: altri enti? |
3. STANDARD INSPIRE (per dati territoriali) ☐ I dataset territoriali sono conformi ai modelli INSPIRE? ☐ È stata effettuata la mappatura degli attributi? ☐ Sono utilizzati schemi dati armonizzati? |
4. METADATI (OBBLIGO CRITICO) ☐ Tutti i dati territoriali sono documentati nel RNDT? ☐ I metadati sono completi? ☐ I metadati sono aggiornati? ☐ I metadati sono conformi alle linee guida? ☐ I dataset sono visibili su geodati.gov.it? ☐ I dataset sono visibili su dati.gov.it? ⚠ ALERT: Se un dataset territoriale NON è nel RNDT → NON è conforme. |
5. FORMATO DEI DATI ☐ I dati sono in formato aperto? ☐ I dati sono leggibili meccanicamente? ☐ È rispettato il livello minimo di 3 stelle? ⚠ Esempi accettabili: CSV, JSON, GeoJSON, GML, GeoPackage. |
6. ACCESSO AI DATI API ☐ I dati sono disponibili tramite API? ☐ Le API sono conformi alle Linee Guida AgID? ☐ Le API hanno documentazione tecnica (OpenAPI/WSDL)? ☐ Le API hanno termini di utilizzo pubblicati? ☐ Le API hanno livelli di servizio (SLA) definiti? Download ☐ È disponibile il download in blocco? |
7. DATI TERRITORIALI – SERVIZI INSPIRE ☐ Sono implementati servizi WMS (visualizzazione)? ☐ Sono implementati servizi WFS (download dati)? ☐ I servizi sono interoperabili? |
8. LICENZE ☐ I dati sono rilasciati con CC BY 4.0? ☐ I dati sono rilasciati con CC0? ☐ Se licenza diversa: è motivata formalmente? |
9. RIUTILIZZO ☐ I dati HVD sono gratuiti? ☐ I dati HVD sono senza restrizioni al riutilizzo commerciale? ☐ È evitata ogni forma di accesso discriminatorio? |
10. DOCUMENTAZIONE Dati NON INSPIRE ☐ Esiste documentazione completa della struttura del dataset? ☐ Esiste documentazione della semantica? ☐ Esiste documentazione dei campi/attributi? Dati INSPIRE ☐ (verifica solo) Sono già conformi agli standard INSPIRE — non serve documentazione extra. |
11. SEMANTICA (OBBLIGO) ☐ Sono utilizzati vocabolari controllati? ☐ Sono adottati standard nazionali? ☐ Sono adottati standard INSPIRE? ☐ Sono adottati standard europei/internazionali? |
12. AGGIORNAMENTO E QUALITÀ ☐ È definita la frequenza di aggiornamento per ogni dataset? ☐ I dati sono aggiornati regolarmente? ☐ È garantita qualità e coerenza interna? |
13. TRASPARENZA ☐ Il Comune pubblica annualmente l'elenco dei dataset disponibili? |
14. CONFORMITÀ HVD (CHECK FINALE) Per ciascun dataset HVD verificare che siano soddisfatti TUTTI i requisiti seguenti: ☐ Formato aperto (≥3 stelle) ☐ API disponibile e documentata ☐ Download in blocco disponibile ☐ Licenza aperta (CC BY 4.0 o CC0) ☐ Rilascio gratuito ☐ Metadati completi (RNDT o dati.gov.it) |
LIVELLO DI CONFORMITÀ (AUTOVALUTAZIONE) ■ Non conforme — mancano requisiti fondamentali (RNDT, API, licenza) ■ Parzialmente conforme — dati pubblicati ma non standardizzati ■ Conforme — pieno rispetto INSPIRE + HVD |
3.32 Law Data Verification
La Law Data Verification (LDV) è la valutazione/validazione sistematica di ciascun dataset dal punto di vista della legalità ed eticità dell'acquisizione, dell'affidabilità dei dati (in particolare ove applicabili i criteri dell'AI Act), e della possibilità di apertura. Deve essere eseguita per ogni dataset del Registro prima di procedere alla Scheda FAIR.
Cosa valuta la Law Data Verification |
A — LEGALITÀ: il dato è stato acquisito lecitamente? Il titolo giuridico è documentato? Le licenze in ingresso consentono il riutilizzo previsto? I diritti di proprietà intellettuale sono rispettati? |
B — ETICITÀ: il dato è stato raccolto in modo trasparente e proporzionato? Sono stati evitati bias sistematici? Il dataset è validato? |
C — AFFIDABILITÀ (qualità e governance dei dati, art. 10 AI Act, ove applicabile): i dati sono rappresentativi, tracciabili, aggiornati? Le limitazioni sono documentate? |
D — OPENABILITY CHECK: il dato è non personale? Non vi sono vincoli contrattuali, di sicurezza o IPR che ostino all'apertura? È un dato di elevato valore (HVD)? |
Esito finale → APERTO / APERTO CONDIZIONATO / CHIUSO |
3.32.1 Scheda Law Data Verification — D001
LAW DATA VERIFICATION — D001: [Denominazione dataset] | ||
Criterio di verifica | Esito (Sì / No / Parziale / N.A.) | Note / Azione richiesta |
A — LEGALITÀ DELL'ACQUISIZIONE | ||
A1 Il dato è stato acquisito lecitamente (contratto, affidamento, open data, convenzione)? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
A2 Il titolo giuridico di acquisizione è documentato (contratto, licenza, atto pubblico)? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
A3 Le condizioni della licenza di ingresso consentono il riutilizzo per le finalità del GDU? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
A4 In caso di dati da affidamento/appalto: il contratto assegna i diritti di proprietà al committente? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
A5 In caso di dati secondari a pagamento: è stato verificato che la licenza consenta la sublicenza verso il Comune? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
A6 In caso di dati da terzi (open data): la licenza è compatibile con la licenza di rilascio prevista per l'output? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
A7 I diritti di proprietà intellettuale (IPR) di terzi sono stati identificati e rispettati? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
B — ETICITÀ DELL'ACQUISIZIONE | ||
B1 Il dato è stato raccolto in modo trasparente, senza inganni o coercizioni? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
B2 Il dato è stato raccolto nel rispetto dei principi di proporzionalità e minimizzazione? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
B3 Sono stati evitati bias sistematici nella raccolta che potrebbero compromettere la qualità o l'equità del dataset? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
B4 Il dataset è stato validato (accuratezza, completezza, coerenza interna)? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
C — AFFIDABILITÀ DEL DATO (qualità e governance dei dati, art. 10 AI Act, ove applicabile) | ||
C1 I dati sono sufficientemente rappresentativi dell'area/fenomeno che descrivono? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
C2 La provenienza (provenance) è documentata e tracciabile? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
C3 Il dato è aggiornato rispetto alle finalità di utilizzo nel GDU? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
C4 Sono documentate le eventuali limitazioni o lacune del dataset? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
D — VERIFICA DI APERTURA (OPENABILITY CHECK) | ||
D1 Il dato è non personale (o è stato anonimizzato in modo adeguato)? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
D2 Non vi sono clausole contrattuali che vietano la pubblicazione? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
D3 Non vi sono vincoli di sicurezza o riservatezza che ostano all'apertura? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
D4 Non vi sono IPR di terzi non risolvibili con una licenza compatibile? | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
D5 Il dato appartiene a una delle serie specificate nell’allegato del Reg. di esecuzione (UE) 2023/138 e la direttiva (UE) 2019/1024 vi si applica (nessun diritto di proprietà intellettuale di terzi, art. 1, par. 2, lett. c))? (Se Sì: apertura obbligatoria) | ☐ Sì ☐ No ☐ Parziale ☐ N.A. | [Da compilare] |
DECISIONE: ☐ APERTO ☐ APERTO CONDIZIONATO ☐ CHIUSO Motivazione: _______________________________________________________________ | ||
[Duplicare la sezione per ogni dataset aggiuntivo nel Registro]
3.33 Schede FAIR
Questa sezione contiene le Schede FAIR complete per i dataset che la Law Data Verification (par. 3.32) ha classificato come APERTI o APERTI CONDIZIONATI. La struttura della scheda segue i principi FAIR — Findable, Accessible, Interoperable, Reusable — con le informazioni di provenienza, licenza e i dataset di input.
Istruzione per la compilazione |
|
|
|
|
|
3.33.1 Scheda FAIR — D001: [Denominazione]
INFORMAZIONI GENERALI | |
Denominazione | {DATA(BASE)-NAME} [Denominazione completa del dataset] |
Autore | [Da compilare] |
Editore | [Da compilare — es. pubblicazione prevista tramite Geoportale del Comune] |
Titolare | [Da compilare — es. Comune / ente committente] |
Ambito | [Da compilare — es. GDU Comune di ___, raccolta dati non personali] |
Descrizione | [Da compilare] |
LICENZE DI RILASCIO E CONDIZIONI D'USO | |
Licenza in ingresso (dati secondari) | [Da compilare — licenza del/dei dataset di origine] Verificare compatibilità prima di scegliere la licenza di uscita. |
Licenza di rilascio (output) | [Da compilare — es. CC BY 4.0 / IODL 2.0 / CC0] Raccomandazione: non mescolare dati CC BY 4.0 in ingresso con database in uscita sotto ODbL senza verifica di compatibilità. |
Condizioni d'uso | [Da compilare — dipende dalla licenza scelta sopra] |
⚠ Le righe in giallo indicano campi da completare o decisioni in sospeso. | |
IDENTIFICATORE PERSISTENTE | |
Identificatore persistente (PID) | [Da compilare — es. UUID secondo ISO 19115 / DOI / Handle / URI permanente] |
FAIR — FINDABLE (Trovabile) | |
Catalogo o data‑repository | [Da compilare — es. Geoportale Comune, dati.gov.it, Zenodo, EUDAT...] ⚠ Registrarsi in un catalogo indicizzato dai motori di ricerca. |
PID integrato nei metadati | [Da compilare — es. UUID integrato nel file metadati (ISO 19115)] |
PID risolve alla pagina dei metadati | [Da compilare — es. Sì, gestione a cura del Comune (identificatore web persistente)] ⚠ Completare prima del rilascio. |
FAIR — ACCESSIBLE (Accessibile) | |
Protocollo di recupero dati/metadati | [Da compilare — es. Protocollo HTTP conforme a standard web pubblici] ⚠ Completare. |
Metadati pubblici e indicizzabili | [Da compilare — es. Metadati QGIS/ISO 19115 rimangono pubblici; indicizzazione gestita dal Comune] |
Modalità di accesso | [Da compilare — es. Download e visualizzazione via Geoportale – Servizi WFS, API, Web Service] |
Formato dei dati | [Da compilare — es. File vettoriale ESRI Shapefile (DBF, SHP, SHX, QMD, PRJ)] |
Formati aperti e/o documentati | [Da compilare — es. Shapefile interoperabile, supportato da QGIS (open source) e ArcGIS] |
Schemi standard per metadati | [Da compilare — es. Schema ISO 19115 compatibile FAIR e QGIS metadata template] |
Vocabolari controllati o tesauri | [Da compilare — es. GEMET (https://www.eionet.europa.eu/gemet) / INSPIRE Codelist / SKOS] |
Collegamenti con altre risorse | [Da compilare — es. link a report tecnici, pubblicazioni del progetto, dataset correlati] ⚠ Completare. |
FAIR — INTEROPERABLE (Interoperabile) | |
Il formato usa standard comuni nella comunità di riferimento? | [Da compilare — Sì / No + specificare] |
Ontologie o vocabolari formali usati nella struttura del dato | [Da compilare — es. INSPIRE Feature Concept Dictionary / OWL / CityGML ontology] |
Possibilità di lettura con software non specifici | [Da compilare — es. Sì: QGIS, Excel, LibreOffice, script Python/R] |
Licenza del software di lettura | [Da compilare — es. Open source (QGIS GPL / Apache) e proprietario (ArcGIS)] |
FAIR — REUSABLE (Riutilizzabile) | |
Accuratezza, completezza, riproducibilità | [Da compilare — es. Conformità ISO 19157; metodologie documentate] |
Responsabilità e finalità dei dati | [Da compilare — es. File metadati – sezione Riassunto; contatto scientifico] |
Standard di qualità del dominio | [Da compilare — es. Conformità ISO 19157; processi derivati da metodologie scientifiche] |
Responsabilità della validazione | [Da compilare — es. Ricercatori, secondo criteri ISO 19157 (Coerenza, Accuratezza, Completezza)] |
Citazione raccomandata | [Da compilare — citazione bibliografica del dataset con DOI/PID] |
ORIGINE DEI DATI | |
Dati Secondari – DB/DS Input | [Da compilare — elencare i dataset di origine con nome e URL] |
Dati Primari – DB/DS Input | [Da compilare — oppure: NA se il dataset è interamente derivato] |
DATI SECONDARI INPUT — Dataset 1: [Nome dataset di origine 1] | |
Denominazione Dataset | [Da compilare] |
Descrizione | [Da compilare] |
Tipo di dati | [Da compilare — es. Quantitativi geospaziali vettoriali / Qualitativi / Raster] |
Dimensione prevista | [Da compilare — es. < 100 MB / ~100 MB / > 100 MB] |
Modalità di riutilizzo | [Da compilare — come viene scaricato, elaborato, integrato] |
Provenienza dei dati | [Da compilare — organizzazione/URL di origine] |
Software per la gestione | [Da compilare — es. GIS software (QGIS, ArcGIS) / Python / R] |
Accordo/contratto formalizzato | [Da compilare — es. Nessuno (open) / Convenzione / Contratto commerciale] |
Licenza | [Da compilare — es. CC BY 4.0 / ODbL / IODL 2.0 / proprietaria] |
Condizioni di ridistribuzione | [Da compilare — es. attribuzione obbligatoria / share-alike / uso non commerciale] |
Restrizioni alla circolazione | [Da compilare — eventuali URL ToS / condizioni d'uso] |
Dati soggetti a IPR o accordi commerciali | [Da compilare — Sì / No / specificare] |
DATI SECONDARI INPUT — Dataset 2: [Nome dataset di origine 2 — se presente] | |
Denominazione Dataset | [Da compilare] |
Descrizione | [Da compilare] |
Tipo di dati | [Da compilare — es. Quantitativi geospaziali vettoriali / Qualitativi / Raster] |
Dimensione prevista | [Da compilare — es. < 100 MB / ~100 MB / > 100 MB] |
Modalità di riutilizzo | [Da compilare — come viene scaricato, elaborato, integrato] |
Provenienza dei dati | [Da compilare — organizzazione/URL di origine] |
Software per la gestione | [Da compilare — es. GIS software (QGIS, ArcGIS) / Python / R] |
Accordo/contratto formalizzato | [Da compilare — es. Nessuno (open) / Convenzione / Contratto commerciale] |
Licenza | [Da compilare — es. CC BY 4.0 / ODbL / IODL 2.0 / proprietaria] |
Condizioni di ridistribuzione | [Da compilare — es. attribuzione obbligatoria / share-alike / uso non commerciale] |
Restrizioni alla circolazione | [Da compilare — eventuali URL ToS / condizioni d'uso] |
Dati soggetti a IPR o accordi commerciali | [Da compilare — Sì / No / specificare] |
[Duplicare la sezione per ogni dataset apribile aggiuntivo]
3.34 Trasferimento dei dataset al Comune
Obbligo di sostenibilità post-progetto |
Il GDU rilasciato dallo sviluppatore deve essere adeguato allo scopo anche oltre la durata del progetto. |
Tutti i dataset in input e in output devono essere rilasciati al Comune in forma che ne consenta la gestione autonoma continuativa. |
I contratti con fornitori di dati terzi devono prevedere clausole che consentano al Comune di subentrare allo sviluppatore. |
3.34.1 Piano di consegna
ID | Denominazione | Formato consegna | Licenza di rilascio | Scheda FAIR compilata? | Data consegna prevista | Consegnato? |
D001 | [Da compilare] | [Da compilare] | [Da compilare] | ☐ Sì ☐ No | [Da compilare] | ☐ Sì ☐ No |
D002 | [Da compilare] | [Da compilare] | [Da compilare] | ☐ Sì ☐ No | [Da compilare] | ☐ Sì ☐ No |
D003 | [Da compilare] | [Da compilare] | [Da compilare] | ☐ Sì ☐ No | [Da compilare] | ☐ Sì ☐ No |
3.34.2 Elementi da consegnare al Comune
- 1.Tutti i dataset primari in formato aperto, leggibile meccanicamente, con metadati ISO 19115 / DCAT-AP IT.
- 2.I dataset secondari elaborati (output), con indicazione delle licenze in ingresso e in uscita.
- 3.Il catalogo metadati completo e aggiornato, conforme a DCAT-AP IT.
- 4.Le Schede FAIR (par. 3.33) per tutti i dataset aperti.
- 5.La documentazione delle pipeline di acquisizione e aggiornamento dati.
- 6.Le credenziali e le chiavi API per l'accesso ai flussi di dati continuativi.
- 7.L'elenco completo delle licenze di tutti i dataset di terzi integrati nel GDU, con indicazione delle condizioni di subentro del Comune.
- 8.Il presente PdRGD-DNP aggiornato allo stato finale del progetto.
3.35 Checklist operativa
3.35.1 Avvio progetto
☐ Da completare all'avvio del progetto |
☐ PdRGD-DNP redatto e condiviso con il Comune |
☐ Registro dei dataset (par. 3.28.1) inizializzato con tutti i dataset noti |
☐ Data Steward nominato |
☐ Schede di Qualificazione (par. 3.29) avviate per tutti i dataset |
☐ Licenze dei dataset di terzi verificate prima dell'acquisizione |
☐ Clausole di sublicenza verso il Comune verificate nei contratti con fornitori |
☐ Catalogo metadati inizializzato (DCAT-AP IT) |
3.35.2 Durante il progetto
☐ Da completare durante il progetto |
☐ Registro e Schede aggiornate ad ogni nuovo dataset |
☐ Law Data Verification eseguita per ogni dataset prima del rilascio |
☐ Scheda FAIR compilata per ogni dataset con esito APERTO |
☐ Revisione semestrale del PdRGD-DNP completata |
☐ Compatibilità licenze verificata prima di ogni elaborazione di dati secondari |
☐ Identificatori persistenti (DOI/URI/UUID) assegnati ai dataset significativi |
3.35.3 Fine progetto
☐ Da completare prima della chiusura |
☐ Tutte le Schede di Qualificazione completate |
☐ Law Data Verification completata per tutti i dataset |
☐ Tutte le Schede FAIR compilate per i dataset aperti |
☐ Campi gialli (⚠) risolti in tutte le Schede FAIR |
☐ Dataset HVD rilasciati con licenza aperta (CC BY / IODL 2.0) via API / download |
☐ Catalogo metadati finale consegnato e pubblicato |
☐ PdRGD-DNP aggiornato allo stato finale e archiviato |
☐ Piano di manutenzione GDU post-progetto concordato con il Comune |
3.36 Registro versioni e approvazione
Versione | Data | Autore | Modifiche | Approvato da |
0.1 | [Da compilare] | [Da compilare] | Prima bozza | — |
1.0 | [Da compilare] | [Da compilare] | Versione definitiva | [Da compilare] |
[X.X] |
Firme
Ruolo | Nome e Cognome | Organizzazione | Firma | Data |
Data Steward / Responsabile GDU | [Da compilare] | [Da compilare] | [Da compilare] | |
Referente del Comune / PA | [Da compilare] | [Da compilare] | [Da compilare] | |
Responsabile scientifico (se ente ricerca) | [Da compilare] | [Da compilare] | [Da compilare] |
Il presente documento è soggetto a revisione periodica. La versione aggiornata sostituisce integralmente le versioni precedenti.