Risultati
58 risultati
-
AGID
3. Terminologia
Di seguito si riportano gli ACRONIMI che sono utilizzati nelle presenti Linee Guida. API. Application Programming Interface. CAD. Codice dell’Amministrazione Digitale. CC. Creative Commons. CMS. Content Management System. CSV. Comma Separated Value. D. Lgs. Decreto Legislativo. DCAT. Data Catalog Vocabulary. DCAT-AP. Data Catalog Vocabulary - Application Profile. DCAT-AP_IT. Data Catalog Vocabulary - Application Profile ITaliano. DRM. Digital Rights Management. HTTP. HyperText Transfer Protocol. INSPIRE. INfrastructure for SPatial InfoRmation in Europe. ICT. Information and Communication Technology. IPA. Indice della Pubblica Amministrazione. ISA. Interoperability Solutions for public Administration. LOD. Linked Open Data. JSON. JavaScript Object Notation. OD. Open Data. OWL. Ontology Web Language. PA. Pubblica Amministrazione. PSI. Public Sector Information. RDF. Resource Description Framework. RDFS. RDF Schema. RNDT. Repertorio Nazionale Dati Territoriali. SDMX. Statistical Data and Metadata eXchange. SPARQL. Sparql Protocol And Rdf Query Language. URI. Uniform Resource Identifier. XML. eXtensible Markup Language ...
-
AGID
4. Principi generali
L’art. 6 del Decreto stabilisce che pubbliche amministrazioni, organismi di diritto pubblico, imprese pubbliche e private, che rientrano tra i soggetti destinatari di cui al par. Soggetti destinatari, rendano disponibili per il riutilizzo i propri dati, e relativi metadati, nel rispetto delle regole tecniche definite con le presenti Linee Guida. Questo capitolo definisce le modalità e i formati per i dati da rendere disponibili come dati di tipo aperto e, in particolare, per le specifiche categorie di dati individuate da Direttiva e Decreto, ovvero dati dinamici, dati della ricerca e serie di dati di elevato valore (di cui, rispettivamente, agli artt. 6 commi 5 e 6, 9-bis e 12-bis) ...
-
AGID
10. Allegato C - Riepilogo di requisiti e raccomandazioni
Testo raccomandazione. 1. Si raccomanda un percorso graduale verso la produzione nativa di Linked Open Data – LOD (livello cinque stelle). 2. Ove possibile, opportuno o necessario, si raccomanda di rendere disponibili i dati dinamici anche attraverso download in blocco. 3. Ove possibile, i principi FAIR dovrebbero essere seguiti e applicati per tutte le tipologie di dati, non solo per quelli della ricerca. 4. SI RACCOMANDA di demandare al Responsabile per la transizione digitale (RTD) il compito di costituire un gruppo di lavoro dedicato al processo di apertura dei dati e all’implementazione delle presenti Linee Guida all’interno dell’organizzazione dell’Ente. Il RTD deve essere comunque coinvolto in tutto il suddetto processo. 5. SI RACCOMANDA di costituire, all’interno dell’organizzazione dell’Ente, un apposito gruppo di lavoro dedicato al processo di apertura dei dati anche per l’applicazione delle presenti Linee Guida, prevedendo, ove possibile, le strutture e le figure adatte e necessarie a tale scopo. 6. SI RACCOMANDA di definire un percorso di apertura dei dati da inserire nel Piano Triennale ICT della singola Amministrazione, la cui definizione può rientrare nei compiti da assegnare al RTD. Tale percorso potrà essere basato su una scala di priorità nell’apertura tenendo in considerazione gli obblighi derivanti dall’applicazione del Decreto per alcune specifiche tipologie di dati. 7. SI RACCOMANDA di garantire, per tutti i dati in generale e per quelli resi disponibili per il riutilizzo, in particolare, il rispetto almeno delle quattro caratteristiche di qualità dei dati, delle 15 previste dallo Standard ISO/IEC 25012 (ovvero accuratezza, coerenza, completezza e attualità), come da indicazioni della Determinazione Commissariale n. 68/2013 di AgID. Per la misura delle suddette caratteristiche, fare riferimento allo Standard ISO/IEC 25024. 8. SI RACCOMANDA di restringere le condizioni di cui alla licenza apposta ai dati alla sola attribuzione. 9. SI RACCOMANDA di limitare l’uso di licenze con condizioni ulteriori rispetto alla sola attribuzione solo ai casi strettamente necessari. 10. SI RACCOMANDA di limitare l’uso della clausola di “condivisione” (“share-alike” - SA) solo ai casi in cui sia motivatamente necessaria ovvero previa verifica di impossibilità di rilascio con licenza CC BY 4.0, ad esempio, in ragione dell’uso non altrimenti gestibile di una fonte già rilasciata con licenza SA). 11. SI RACCOMANDA di non utilizzare le licenze Creative Commons precedenti alla 4.0, in cui tali diritti sui generis non erano citati/previsti (2.5), o erano richiamati come meramente rinunciati (3.0). 12. SI RACCOMANDA di evitare quelle licenze che – per quanto ben impostate – presentano forti caratteristiche di localizzazione, anch’esse potenzialmente costituenti elementi di ambiguità in caso di riuso e mashup (come la IODL). 13. SI RACCOMANDA ai titolari che hanno già pubblicato set di dati con licenze diverse da quelle sopra richiamate, incluse versioni della CC-BY precedente alla 4.0, di valutare il rinnovo della licenza, adeguandola alle indicazioni suddette, individuando nel caso le ragioni eventualmente impedienti tale aggiornamento. 14. Ove possibile, si raccomanda di utilizzare API conformi al Requisito 27 per rendere disponibili per il riutilizzo tutte le tipologie di dati, non solo quelli dinamici e/o di elevato valore. 15. Si raccomanda di non creare tanti portali diversi per singole iniziative ma, ove possibile, di raccordarle per facilitare il reperimento e il riutilizzo dei dati da parte degli utenti finali ...
-
AGID
1. Ambito di applicazione
I destinatari delle presenti Linee Guida sono quelli individuati dal Decreto e innanzi già citati, ovvero le pubbliche amministrazioni, gli organismi di diritto pubblico e le imprese pubbliche e private. Per l’individuazione delle “pubbliche amministrazioni” si fa riferimento all’art. 1 c. 2 del decreto legislativo 30 marzo 2001, n. 165; sono compresi, quindi:. tutte le amministrazioni dello Stato, ivi compresi gli istituti e scuole di ogni ordine e grado e le istituzioni educative;. le aziende ed amministrazioni dello Stato ad ordinamento autonomo;. le Regioni;. le Province;. i Comuni, le Comunità montane, e loro consorzi e associazioni;. le istituzioni universitarie;. gli Istituti autonomi case popolari;. le Camere di commercio, industria, artigianato e agricoltura e loro associazioni;. tutti gli enti pubblici non economici nazionali, regionali e locali;. le amministrazioni, le aziende e gli enti del Servizio sanitario nazionale;. l’Agenzia per la rappresentanza negoziale delle pubbliche amministrazioni (ARAN);. le Agenzie di cui al decreto legislativo 30 luglio 1999, n. 300. Il Decreto precisa che sono comprese anche le autorità di sistema portuale, le autorità amministrative indipendenti di garanzia, vigilanza e regolazione, nonché i loro consorzi o associazioni a qualsiasi fine istituiti. Per l’individuazione degli “organismi di diritto pubblico” si fa riferimento all’art. 3 c. 1 lettera d) del decreto legislativo 18 aprile 2016, n. 50; sono, quindi, compresi, sulla base dell’allegato IV del predetto decreto legislativo, i seguenti organismi [2]:. Mostra d’oltremare S.p.A.;. Ente nazionale per l’aviazione civile - ENAC;. Società nazionale per l’assistenza al volo S.p.A. - ENAV;. ANAS S.p.A.;. Consip S.p.A. (quando Consip agisce in qualità di centrale di committenza per le autorità sub-centrali). e le seguenti categorie:. Consorzi per le opere idrauliche;. Università statali, gli istituti universitari statali, i consorzi per i lavori interessanti le università;. Istituzioni pubbliche di assistenza e di beneficenza;. Istituti superiori scientifici e culturali, osservatori astronomici, astrofisici, geofisici o vulcanologici;. Enti di ricerca e sperimentazione;. Enti che gestiscono forme obbligatorie di previdenza e di assistenza;. Consorzi di bonifica;. Enti di sviluppo e di irrigazione;. Consorzi per le aree industriali;. Comunità montane;. Enti preposti a servizi di pubblico interesse;. Enti pubblici preposti ad attività di spettacolo, sportive, turistiche e del tempo libero;. Enti culturali e di promozione artistica. Per quanto riguarda le imprese pubbliche, sono da considerare:. quelle attive nei settori di cui agli articoli da 115 a 121 del decreto legislativo 18 aprile 2016, n. 50, che, all’atto di adottare le presenti linee guida, sono i seguenti:. gas ed energia termica;. elettricità;. acqua;. servizi di trasporto;. porti e aeroporti;. servizi postali;. estrazione di gas e prospezione o estrazione di carbone o di altri combustibili solidi;. quelle che agiscono in qualità di «operatore di servizio pubblico», definito dall’art. 2 del Regolamento (CE) n. 1370/2007 come “un’impresa o un gruppo di imprese di diritto pubblico o privato che fornisce servizi di trasporto pubblico di passeggeri o qualsiasi ente pubblico che presta servizi di trasporto pubblico di passeggeri”;. quelle che agiscono in qualità di vettori aerei che assolvono oneri di servizio pubblico ai sensi dell’art. 16 del Regolamento (CE) n. 1008/2008;. quelle che agiscono in qualità di armatori comunitari che assolvono obblighi di servizio pubblico ai sensi dell’art. 4 del Regolamento (CEE) n. 3577/1992. Per quanto riguarda le imprese private, sono da considerare:. le imprese private di trasporto che sono soggette ad obblighi di servizio pubblico ai sensi dell’art. 16 del Regolamento (CE) n. 1008/2008 relativo alla prestazione di servizi aerei nella Comunità Europea;. in generale, i gestori di servizi pubblici in relazione ai servizi di pubblico interesse. Risorse utili. text/html Linee guida in materia di trattamento di dati personali contenuti anche in atti e documenti amministrativi effettuato da soggetti pubblici per finalità di pubblicazione e diffusione sul web, adottate con Deliberazione n. 088 del 2 marzo 2011 del Garante per la Protezione dei Dati Personali. text/html Linee Guida recanti indicazioni operative ai fini della definizione delle esclusioni e dei limiti all’accesso civico di cui all’art. 5 co. 2 del D. Lgs. 33/2013 adottate con Determinazione n. 1309 del 28 dicembre 2016 dell’Autorità Nazionale Anticorruzione. application/pdf Piano nazionale di digitalizzazione del patrimonio culturale – Linee Guida per l’acquisizione, la circolazione e il riuso delle riproduzioni dei beni culturali in ambiente digitale, Ministero della Cultura (in fase di consultazione). [1]. Il Considerando (65) della Direttiva indica alcuni esempi di enti culturali che devono essere esclusi dall’applicazione della Direttiva stessa, ovvero orchestre, teatri lirici, compagnie di ballo e teatri, compresi gli archivi che ne fanno parte, in virtù della loro specificità di «arti dello spettacolo» e del fatto che quasi tutto il loro materiale è soggetto a diritti di proprietà intellettuale di terzi. [2]. Alcuni organismi o categorie possono corrispondere a pubbliche amministrazioni indicate innanzi ...
-
AGID
Introduzione per la consultazione pubblica
Informazioni sulla consultazione. Settore: Open Data. Esiti della consultazione. I risultati della consultazione pubblica on line saranno presi in considerazione dall’Agenzia per l’Italia Digitale per l’aggiornamento delle Linee Guida e le successive integrazioni. Destinatari. Pubbliche amministrazioni, organismi di diritto pubblico, imprese pubbliche e private (destinatari delle Linee Guida che dovranno attuare le indicazioni presenti); ricercatori, stakeholders, utenti generici, cittadini (che saranno i destinatari delle azioni di implementazione delle Linee Guida da parte delle PA e degli altri soggetti). Obiettivo della consultazione. Arricchire il perimetro di indicazioni, suggerimenti e proposte, redatte in modalità collaborativa e aiutare a migliorare il testo delle Linee Guida sia in termini prettamente editoriali, che, soprattutto, tecnici e di contenuto in modo da garantire una loro più efficace implementazione da parte dei destinatari. Come partecipare. Le Linee Guida sono pubblicate su Docs Italia ed è possibile commentarle fino al 17 luglio 2022 su - Forum Italia - ParteciPA - dati.gov.it attraverso il template ISO ...
-
AGID
Gruppo di lavoro
La redazione del documento è stata curata dal Gruppo di lavoro coordinato da AgID e composto dai rappresentanti dei seguenti Enti:. Formez PA;. Istituto Geografico Militare;. Università degli Studi di Roma La Sapienza;. Università degli Studi di Roma Tre;. CSI Piemonte;. Regione Basilicata;. Regione Calabria;. Regione del Veneto;. Regione Emilia-Romagna;. Regione Friuli-Venezia Giulia;. Regione Lazio;. Regione Lombardia;. Regione Marche;. Regione Molise;. Regione Piemonte;. Regione Puglia;. Regione Toscana;. Provincia Autonoma di Trento. Ha collaborato, inoltre, su specifici aspetti, il Ministero della Cultura ...
-
AGID
11. Allegato D - Elenco analitico dei documenti
Di seguito l’elenco dei documenti citati nelle presenti Linee Guida come risorse utili. In corrispondenza di ciascun documento vengono indicate le sezioni del documento (capitoli e paragrafi) dove tali documenti sono indicati come riferimento. Rif. LG. CDLA permissive compatibility. 6.1. CDLA-Permissive-2.0 Compatibility with Other Licenses. 6.1. Circolare del Ministro per la pubblica amministrazione n. 3 del 1° ottobre 2018 - Responsabile per la transizione digitale - art. 17 decreto legislativo 7 marzo 2005, n. 82 “Codice dell’amministrazione digitale”. 5.1.1. Compatibility of Creative Commons Licenses. 6.1. Compatible Licenses, Creative Commons. 6.1. Comunicazione della Commissione Europea 2014/C 240/01 - Orientamenti sulle licenze standard raccomandate, i dataset e la tariffazione del riutilizzo dei documenti. 6.2. Cool URIs for the Semantic Web. 7.1.3. Creative Commons Licenses Compatibility Wizard. 6.1. CSV on the Web. Allegato B. data.europa.eu – Data quality guidelines. 4.1, Allegato B. FAIR principles. 4.4. Generating JSON from Tabular Data on the Web. Allegato B. Generating RDF from Tabular Data on the Web. Allegato B. Gestione licenze – data.europa.eu. 6.1. Guida nazionale per l’implementazione della specifica GeoDCAT-AP. 7.2. Guida operativa per i cataloghi dati. 4.6. Guida operativa per la compilazione dei metadati RNDT. 4.6. Guida per la redazione format del Piano Triennale per le pubbliche amministrazioni. 5.1.2. Guide tecniche INSPIRE per i servizi di rete. 7.1.1. How FAIR are your data? Checklist. 4.4. How to make your data FAIR – Guides for Researchers. 4.4. Italian Open Data License. 6.1. Joinup Licensing Assistant. 6.1. Linee guida in materia di trattamento di dati personali contenuti anche in atti e documenti amministrativi effettuato da soggetti pubblici per finalità di pubblicazione e diffusione sul web. 1, 5.1.2. Linee Guida recanti indicazioni operative ai fini della definizione delle esclusioni e dei limiti all’accesso civico di cui all’art. 5 co. 2 del D. Lgs. 33/2013. 1, 5.1.2. Linee Guida recanti regole tecniche per la definizione e l’aggiornamento del contenuto del Repertorio Nazionale dei Dati Territoriali. 4.6. Linee Guida sull’infrastruttura tecnologica della Piattaforma Digitale Nazionale Dati. per l’interoperabilità dei sistemi informativi e delle basi di dati. 7.1.1. Linee Guida sull’interoperabilità semantica attraverso i Linked Open Data. 5.1.4. Linee Guida sull’interoperabilità tecnica delle Pubbliche Amministrazioni. 7.1.1. Linee Guida sulla formazione, gestione e conservazione dei documenti informatici. 5.1.5. Linee Guida Tecnologie e standard per la sicurezza dell’interoperabilità tramite API dei sistemi informatici. 7.1.1. OGC SensorThings API as an INSPIRE download service. 4.2. Ontopia – rete ontologie e vocabolari controllati. 5.1.4, 5.1.5. Open Data Goldbook for Data Managers and Data Holders - Practical guidebook for organizations wanting to publish Open Data. 4.1. OpenAPI Checker. 7.1.1. Piano nazionale di digitalizzazione del patrimonio culturale – Linee Guida per l’acquisizione, la circolazione e il riuso delle riproduzioni dei beni culturali in ambiente digitale. 1, 6.2, 6.4. Piano nazionale di digitalizzazione del patrimonio culturale 2022-2023 e relative Linee Guida. 6.2, 6.4. Piano Nazionale Infrastrutture di Ricerca (PNIR) 2021 – 2027. 4.4. Programma nazionale per la ricerca (PNR) 2021-2027. 4.4. Regolamento recante i livelli minimi di sicurezza, capacità elaborativa, risparmio energetico e affidabilità delle infrastrutture digitali per la PA e le caratteristiche di qualità, sicurezza, performance e scalabilità, portabilità dei servizi cloud per per la pubblica amministrazione, le modalità di migrazione, nonché le modalità di qualificazione dei servizi cloud per la pubblica amministrazione. 7.1.2. Regolamento sui criteri per la fornitura dei servizi di conservazione dei documenti informatici. 5.1.5. Sistema di Registri INSPIRE Italia. 5.1.4. Strategia Cloud Italia. 7.1.1, 7.1.2. Study on persistent URIs, with identification of best practices and recommendations on the topic for the MSs and the EC. 7.1.3. The FAIR data principles. 4.4. Webinar “Real-time Data”. 4.2. Wiki/cc license compatibility. 6.1 ...
-
AGID
Prefazione
Le presenti linee guida rappresentano l’attuazione dell’art. 12 del D. Lgs. n. 36/2006, come modificato dal D. Lgs. n. 200/2021, recepimento della Direttiva (UE) 2019/1024 (cd. Direttiva Open Data). Esse vengono emesse ai sensi dell’articolo 71 del CAD e della Determinazione AgID n. 160/2018 recante “Regolamento per l’adozione di linee guida per l’attuazione del Codice dell’Amministrazione Digitale” [1]. Ai sensi del citato art. 71, esse divengono efficaci il giorno successivo alla loro pubblicazione sul sito istituzionale di AgID e di essa ne è data notizia nella Gazzetta Ufficiale della Repubblica italiana. Questo documento rappresenta, altresì, l’aggiornamento delle Linee Guida per la valorizzazione del patrimonio informativo pubblico [2]. Le presenti linee guida possono essere aggiornate periodicamente secondo le modalità di cui all’art. 5 del Regolamento innanzi citato. https://trasparenza.agid.gov.it/archivio19_regolamenti_0_5376.html. https://docs.italia.it/italia/daf/lg-patrimonio-pubblico/it/stabile/index.html ...
-
AGID
5. Aspetti organizzativi e qualità dei dati
Il Decreto non contiene specifiche disposizioni sugli aspetti organizzativi e di qualità dei dati. Si ritiene utile, però, riportare opportune indicazioni, alcune delle quali già presenti nelle Linee Guida per la valorizzazione del patrimonio informativo pubblico [1], sebbene organizzate diversamente e ove necessario integrate e/o riviste, come raccomandazioni su tali aspetti che sono cruciali per un processo di apertura e di riutilizzo efficace e sostenibile. I requisiti presenti in questo capitolo sono relativi esclusivamente alle richieste di riutilizzo, esplicitamente previste dal Decreto (cfr. art. 5), nella nuova formulazione introdotta con D-LGS-200-2021. https://docs.italia.it/italia/daf/lg-patrimonio-pubblico/it/stabile/index.html ...
-
AGID
8. Allegato A - Modello per i dati aperti
Per ciascun livello, di seguito vengono indicate le caratteristiche principali in termini di informazione, accesso e servizi. La Figura riportata al par. Requisiti comuni, indica, per ciascun formato, il numero di stelle raggiungibile. 8.1.1. Livello 1 (1 stella). Informazione: Dati disponibili tramite una licenza aperta e inclusi in documenti leggibili e interpretabili solo grazie a un significativo intervento umano (per es., PDF);. Accesso: Prevalentemente umano, necessario anche per dare un senso ai dati inclusi nei documenti;. Servizi: Solo rilevanti interventi umani di estrazione ed elaborazione dei possibili dati consentono di sviluppare servizi con l’informazione disponibile in questo livello;. 8.1.2. Livello 2 (2 stelle). Informazione: Dati disponibili in forma strutturata e con licenza aperta. Tuttavia, i formati sono proprietari (per es., Excel) e un intervento umano è fortemente necessario per un’elaborazione dei dati;. Accesso: I programmi possono elaborare i dati ma non sono in grado di interpretarli; pertanto è necessario un intervento umano al fine di scrivere programmi ad-hoc per il loro utilizzo;. Servizi: Servizi ad-hoc che devono incorporare i dati per consentire un accesso diretto via Web agli stessi;. 8.1.3. Livello 3 (3 stelle). Informazione: Dati con caratteristiche del livello precedente ma in un formato non proprietario (per es., CSV, JSON, geoJSON). I dati sono leggibili da un programma ma l’intervento umano è necessario per una qualche elaborazione degli stessi;. Accesso: I programmi possono elaborare i dati ma non sono in grado di interpretarli; pertanto è necessario un intervento umano al fine di scrivere programmi ad-hoc per il loro utilizzo;. Servizi: Servizi ad-hoc che devono incorporare i dati per consentire un accesso diretto via Web agli stessi;. 8.1.4. Livello 4 (4 stelle). Informazione: Dati con caratteristiche del livello precedente ma esposti usando standard W3C quali RDF e SPARQL I dati sono descritti semanticamente tramite metadati e ontologie;. Accesso: I programmi sono in grado di conoscere l’ontologia di riferimento e pertanto di elaborare i dati quasi senza ulteriori interventi umani;. Servizi: Servizi, anche per dispositivi mobili, che sfruttano accessi diretti a Web per reperire i dati di interesse;. 8.1.5. Livello 5 (5 stelle). Informazione: Dati con caratteristiche del livello precedente ma collegati a quelli esposti da altre fonti (i.e., Linked Open Data). I dati sono descritti semanticamente tramite metadati e ontologie. Essi seguono il paradigma RDF, in cui alle entità è assegnato un URI univoco sul Web. Nel caso dei Linked Open Data l’intervento umano è minimo o nullo;. Accesso: I programmi sono in grado di conoscere l’ontologia di riferimento e pertanto di elaborare i dati quasi senza ulteriori interventi umani;. Servizi: Servizi, anche per dispositivi mobili, che sfruttano sia accessi diretti a Web sia l’informazione ulteriore catturata attraverso i link dei dati di interesse, facilitando il mashup di dati. [1]. Rivisitazione della figura disponibile sul web ...
-
AGID
9. Allegato B - Standard di riferimento e formati aperti
9.2.1. Formati aperti per i dati. 9.2.1.1. CSV (Comma Separated Values). È un formato di file testuale utilizzato per rappresentare informazioni con struttura tabellare. Le righe delle tabelle corrispondono a righe nel file di testo CSV e i valori delle celle sono divisi da un carattere separatore, che, come indica il nome stesso, dovrebbe essere la virgola. Il CSV non è uno standard vero e proprio ma la sua modalità d’uso è descritta nell’RFC 4180. Nel rilascio di dati secondo il formato CSV, per agevolare i riutilizzatori, si raccomanda di dichiarare almeno 1) il separatore di campo utilizzato (e.g, virgola, punto e virgola); 2) se è stato usato un carattere per delimitare i campi di testo. Raccomandazioni sul formato CSV [1]. Utilizza un file per tabella. Ogni file CSV deve contenere solo una tabella. Se la tabella da pubblicare è composta da più fogli, è necessario creare un file CSV per ogni foglio. Evita gli spazi bianchi e informazioni aggiuntive nel file. È importante assicurarsi che il file contenga solo i dati che appartengono alla tabella effettiva, come le intestazioni di colonna e i valori delle voci presenti nella tabella stessa. Nel file CSV, quindi, non devono essere presenti titolo della tabella, righe vuote o eventuali informazioni aggiuntive che aiutino l’utente a capire meglio i dati (queste ultime, che sono utilissime, vanno inserite nei metadati). Il file, inoltre, deve contenere una sola riga di intestazione. Inserisci le intestazioni di colonna. Le intestazioni di colonna devono essere auto-esplicative ed essere incluse nella prima riga del file CSV. Senza le intestazioni, è difficile per gli utenti interpretare il significato dei dati. Assicurati che tutte le righe abbiano lo stesso numero di colonne. Ogni riga deve avere lo stesso numero di colonne e, quindi, di caratteri separatori. Se in una riga manca un valore, questo di solito viene interpretato come “null”. Ciò può comportare un trattamento errato dei dati. Se il CSV contiene righe con un numero diverso di colonne, bisognerebbe controllare se c’è un problema con valori di ‘escape’ non corretti (ad es. un valore che corrisponde al carattere separatore che in quel caso non va interpretato come tale). Indica le unità in una modalità facilmente elaborabile. L’unità di misura di un valore dovrebbe essere indicata nell’intestazione della colonna. Se l’unità cambia da un valore all’altro, allora bisognerebbe considerare una colonna dedicata con un’opportuna intestazione e non inserire l’unità insieme al valore stesso. Per le unità dovrebbero essere utilizzati i codici (URI) derivati da un vocabolario controllato. 9.2.1.2. JSON (JavaScript Object Notation). È un formato aperto per la rappresentazione e lo scambio di dati semi-strutturati, leggibile anche dagli utenti e che mantiene, rispetto a formati simili come l’XML, una sintassi poco prolissa. Questo aspetto ne fa un formato flessibile e compatto. Esso nasce dalla rappresentazione di strutture dati semplici nel linguaggio di programmazione JavaScript, ma mantiene indipendenza rispetto ai linguaggi di programmazione. Raccomandazioni sul formato JSON [2]. Utilizza tipi di dati adeguati. JSON consente l’utilizzo dei seguenti tipi di dati:. Valore nullo (assenza di un valore), rappresentato dalla parola chiave ‘null’;. Valori booleani, vero o falso;. Stringhe, dove la mascheratura dei singoli caratteri funziona allo stesso modo del file CSV;. Numeri e sequenze semplici delle cifre 0–9, eventualmente con un segno e/o punto decimale;. Elenchi, detti anche array, racchiusi tra parentesi quadre, in cui i singoli elementi sono separati da virgole. Gli elenchi possono anche essere vuoti;. Oggetti, racchiusi tra parentesi graffe e contenenti un numero qualsiasi di coppie chiave-valore separate da virgole. Per ulteriori elaborazioni è importante utilizzare tipi di dati adeguati. Utilizza le gerarchie per raggruppare i dati. Invece di allegare tutti i campi all’oggetto radice del JSON, i dati dovrebbero essere raggruppati semanticamente. Ciò migliora la leggibilità da parte degli esseri umani e può migliorare le prestazioni durante l’elaborazione del file. 9.2.1.3. XML (eXtensible Markup Language). È un linguaggio di marcatura standardizzato dal W3C usato per l’annotazione di documenti e per la costruzione di altri linguaggi più specifici per l’annotazione di documenti. XML è basato sull’utilizzo di marcatori (tag) che consentono di strutturare il contenuto informativo da rappresentare. Nell’ambito del Web Semantico è stata definita una specifica serializzazione RDF/XML. Raccomandazioni sul formato XML [3]. Fornire una dichiarazione XML. Ogni file XML dovrebbe avere una dichiarazione XML completa. Questa contiene metadati relativi alla struttura del documento ed è importante affinché le applicazioni elaborino correttamente il file. Fai l’ “escaping” dei caratteri speciali. Quando vengono utilizzati caratteri speciali nei file XML, è necessario eseguire l’ “escape”. Ciò garantisce una struttura del file pulita e impedisce alle applicazioni utilizzate per l’elaborazione del file di interpretare erroneamente i dati. L’ ‘escape’ viene eseguito sostituendoli con le entità XML equivalenti. Utilizza nomi significativi per gli identificatori. Tutti gli identificatori, siano essi tag o attributi, dovrebbero avere nomi significativi e non dovrebbero auspicabilmente essere usati due volte. Utilizza correttamente attributi ed elementi. Sebbene non vi sia una direttiva vincolante obbligatoria in merito alla codifica dei dati in elementi o attributi, la prassi è che le informazioni che fanno parte dei dati effettivi debbano essere rappresentate da elementi. I metadati che contengono informazioni aggiuntive dovrebbero invece essere implementati come attributi. Rimuovi i dati specifici del programma. XML, come qualsiasi formato aperto, dovrebbe essere sempre indipendente da programmi o strumenti specifici utilizzati per l’elaborazione dei file. Questo permette all’utente di scegliere lo strumento che preferisce per il trattamento dei dati senza doverlo prima bonificare. 9.2.1.4. Serializzazioni RDF. N-triples. È una serializzazione di RDF in cui ogni tripla è espressa interamente e indipendentemente dalle altre. La concatenazione delle triple di un dataset RDF secondo N-Triples avviene utilizzando il carattere punto (es.,
. ). Notation3. Notation3 (o N3) è una serializzazione RDF pensata per essere più compatta rispetto a quella ottenuta utilizzando la sintassi XML. Essa risulta più leggibile da parte degli utenti e possiede delle caratteristiche che esulano dall’uso stretto di RDF (per es., rappresentazione di formule logiche). Turtle. È una versione semplificata (un sottoinsieme di funzionalità) di N3. Un dataset in Turtle è una rappresentazione testuale di un grafo RDF e, al contrario di RDF/XML, è di più facile lettura e gestione anche manuale. JSON-LD. È un formato di serializzazione per RDF, standardizzato dal W3C, che fa uso di una sintassi JSON. Viene proposto come formato per Linked Data, mascherando di proposito la sua natura di serializzazione di RDF per ragioni di diffusione del formato. Il gruppo di lavoro che l’ha definito ha posto come obiettivo, oltre quello di mettere a disposizione un’ulteriore funzionalità al framework RDF, anche quello di avvicinare il mondo dello sviluppo Web e degli utilizzatori dei sistemi di gestione dati NoSQL (in particolare dei document store) al Web Semantico. Da un punto di vista pratico è possibile rilasciare dati RDF utilizzando questo «dialetto» JSON nelle situazioni in cui inizialmente non ci si possa dotare di tecnologie ad-hoc come triple store. Allo stesso tempo, con JSON-LD si fornisce uno strumento standard che consente il collegamento di documenti JSON che per loro natura sono unità di informazione indipendenti. Raccomandazioni sul formato RDF/xxx [4]. Utilizza URI http per identificare le risorse. Gli ID di una risorsa dovrebbero essere URI HTTP, poiché questi consentono l’accesso diretto alla risorsa in questione. Rendono inoltre le risorse indicizzabili dai motori di ricerca, il che migliora la loro reperibilità. Utilizza ‘namespace’ (spazi dei nomi) quando possibile. Sebbene gli spazi dei nomi non siano necessari per l’elaborazione di RDF, riducono la verbosità e le dimensioni del file. 9.2.2. Formati aperti più diffusi per i dati geografici. 9.2.2.1. Shapefile. È il formato standard de-facto per la rappresentazione dei dati dei sistemi informativi geografici (GIS). I dati sono di tipo vettoriale. Lo shapefile è stato creato dalla società privata ESRI che rende comunque pubbliche le sue specifiche. L’apertura delle specifiche ha consentito lo sviluppo di diversi strumenti in grado di gestire e creare tale formato. Seppur impropriamente ci si riferisca a uno shapefile, nella pratica si devono considerare almeno tre file: un .shp contenente le forme geometriche, un .dbf contenente il database degli attributi delle forme geometriche e un file .shx come indice delle forme geometriche. A questi tre si deve anche accompagnare un file .prj che contiene le impostazioni del sistema di riferimento. Si raccomanda comunque di specificare nei metadati la proiezione utilizzata. È importante notare che non risulta ancora chiaro se tale formato lo si possa considerare propriamente aperto (e quindi coerente con la definizione introdotta dal CAD) di livello 3 secondo il modello per i dati proposto nel presente documento. Tenuto conto dell’ampio uso di tale formato per la rappresentazione dei dati geografici si ritiene opportuno includerlo comunque in questo elenco. 9.2.2.2. KML. È un formato basato su XML per rappresentare dati geografici. Nato con Google, è diventato poi uno standard OGC. Le specifiche della versione 2.2 presentano una serie di entità XML attraverso cui archiviare le coordinate geografiche che rappresentano punti, linee e poligoni espressi in coordinate WGS84 e altre utili a definire gli stili attraverso cui visualizzare i dati. Eventuali attributi delle geometrie vanno espressi invece attraverso la personalizzazione di alcune entità. Molti strumenti di conversione non si occupano tuttavia di creare questa struttura dati e delegano gli attributi delle geometrie allo stile di visualizzazione. Si consiglia pertanto di distribuire questo dato prestando attenzione o, eventualmente, accompagnando il dataset assieme ad un altro formato aperto per i dati geografici (ad esempio, .shp, .geojson). 9.2.2.3. GeoJSON. È un formato aperto per la rappresentazione e l’interscambio dei dati territoriali in forma vettoriale, basato su JSON. Ogni dato è codificato come oggetto che può rappresentare una geometria, una caratteristica o una collezione di caratteristiche. A ogni oggetto è associato un insieme di coppie nome/valore (membri). I principali nomi di membri che rappresentano le caratteristiche dei dati geografici sono: «type» che serve a indicare il tipo di geometria (punto, linea, poligono o insieme multi-parte di questi tipi); «coordinates» attraverso cui sono indicate le coordinate dell’oggetto in un dato sistema di riferimento; «bbox» attraverso cui sono indicate le coordinate di un riquadro di delimitazione geografica; «crs» (opzionale) per l’indicazione del sistema di riferimento. Inoltre, è possibile associare all’oggetto specifici attributi, attraverso il membro con nome «properties». Si tratta di un formato molto diffuso e supportato da diversi software, ampiamente utilizzato in ambito di sviluppo web. Nel 2016 è stata pubblicata la relativa RFC 7946 “The GeoJSON Format”. La specifica raccomanda di limitare la precisione delle coordinate a 6 decimali, attraverso cui si può specificare qualsiasi posizione sulla terra con una tolleranza di 10 centimetri. La specifica inoltre richiede che i dati siano memorizzati con un sistema di riferimento di coordinate geografiche WGS 84, in latitudine e longitudine, nello stesso stile dei dati GPS. 9.2.2.4. GML (Geography Markup Language). È una grammatica XML che rappresenta un formato di scambio aperto per i dati territoriali. Definita originariamente da OGC, e diventata poi lo Standard ISO 19136:2008, essa fornisce la codifica XML (schemi XSD) delle classi concettuali definite in diversi Standard ISO della serie 19100 e di classi aggiuntive quali: geometrie, oggetti topologici, unità di misura, tipi di base, riferimenti temporali, caratteristiche, sistemi di riferimento, copertura. 9.2.2.5. GeoPackage. È un formato aperto per la rappresentazione di dati geografici e può essere un’alternativa al suddetto formato shapefile. Esso supporta SpatiaLite ovvero un’estensione dello schema del database SQLite. Il principale vantaggio offerto da GeoPackage è quello di rappresentare in un unico file diversi dati geografici, sia di tipo vettoriale che raster, che possono essere gestiti anche tramite apposite interrogazioni SQL. Lo standard è riconosciuto dall’Open Geospatial Consortium. 9.2.3. Formati aperti per i documenti. 9.2.3.1. ODF (Open Document Format). È uno standard dell’OASIS che specifica le caratteristiche di un formato per documenti digitali basato su XML, indipendente dall’applicazione e dalla piattaforma utilizzata. La seguente serie di formati aperti è parte dello standard OASIS ODF:. · ODT (Open Document Text). Standard aperto per documenti testuali. È stato adottato come formato principale per i testi in alcune suite per l’automazione d’ufficio come OpenOffice.org e LibreOffice; è supportato da altre come Microsoft Office, Google Drive e IBM Lotus. · ODS (Open Document Spreadsheet). Standard aperto per fogli di calcolo. Come nel caso precedente, è stato adottato come formato principale per i fogli di calcolo in alcune suite per l’automazione d’ufficio come OpenOffice.org e LibreOffice; è supportato da altre come Microsoft Office, Google Drive e IBM Lotus. · ODP (Open Document Presentation). Standard aperto per documenti di presentazione. È stato adottato come formato principale per i documenti di presentazione in alcune suite per l’automazione d’ufficio come OpenOffice.org e LibreOffice; è supportato da altre come Microsoft Office, Google Drive e IBM Lotus. 9.2.3.2. PDF. È un formato aperto creato da Adobe per la rappresentazione di documenti contenenti testo e immagini che sia indipendente dalla piattaforma di lettura (applicativo, sistema operativo e hardware). È stato standardizzato dall’ISO (ISO/IEC 32000-1:2008) con una serie di formati differenti, ognuno avente una propria prerogativa (per es., PDF/UA per l’accessibilità, PDF/H per documenti sanitari, PDF/A per l’archiviazione, ecc.). Si noti che rilasciare dati secondo tale formato limita fortemente il riutilizzo dei dati stessi in quanto l’intervento umano richiesto per la loro elaborazione è molto elevato (dati rilasciati in formato PDF con una licenza aperta rappresentano solo il primo livello del modello dei dati aperti). 9.2.3.3. Akoma Ntoso. È un linguaggio basato su XML per la rappresentazione di documenti giuridici. Nel 2017 è diventato una specifica OASIS. 9.2.4. Altri formati per i dati di elevato valore. Per le serie di dati di elevato valore, la bozza di Regolamento UE dispone che, in generale, si debba utilizzare un formato aperto e leggibile meccanicamente riconosciuto nell’Unione o a livello internazionale, indicazione che può trovare attuazione seguendo il REQUISITO 2 e quanto riportato innanzi nel presente allegato. Per alcune categorie tematiche, il predetto Regolamento indica la possibilità di utilizzare anche alcuni formati specifici che sono riportati di seguito. 9.2.4.1. Formati per dati meteorologici. Per i dati di osservazione misurati dalle stazioni meteorologiche, oltre al JSON da utilizzare per dati orari, possono essere utilizzati i seguenti formati:. BUFR (Binary Universal Form for the Representation of meteorological data), formato di dati gestito dall’Organizzazione Meteorologica Mondiale (WMO – World Meteorological Organization) [5];. NetCDF (Network Common Data Form), insieme di librerie software e formati di dati indipendenti dalla macchina che supportano la creazione, l’accesso e la condivisione di dati scientifici array-oriented [6];. ASCII (American Standard Code for Information Interchange), codice per la codifica dei caratteri da utilizzare per lo scambio generale di informazioni tra sistemi di elaborazione e comunicazione [7]. Per i dati climatici, possono essere utilizzati i formati NetCDF e JSON. Per gli avvisi meteo possono essere utilizzati i seguenti formati:. CAP (Common Alerting Protocol), formato di dati basato su XML per lo scambio di avvisi pubblici ed emergenze tra tecnologie di allerta [8];. RSS (Really Simple Syndication)/Atom, formati di dati basati su XML per distribuire contenuti come elenchi di informazioni conosciuti come “feed” [9]. Per i dati radar, oltre al JSON, può essere utilizzato il formato HDF5 (Hierarchical Data Format), progettato per archiviare e organizzare grandi quantità di dati [10]. Per i dati del modello NWP (Numerical weather prediction), oltre al JSON e a NetCDF, si può utilizzare il formato GRIB (General Representation of fields In Binary), rappresentazione binaria di dati risultanti da un’osservazione o da una simulazione su modello numerico di una proprietà osservabile in un dominio spaziale e temporale su un sistema di riferimento geospaziale o celeste [11]. 9.2.4.2. Formati per dati statistici. Per i dati statistici il Regolamento indica che, oltre a CSV, JSON e qualsiasi altro formato aperto e leggibile meccanicamente, si può utilizzare anche il formato XML con riferimento a SDMX (Statistical Data and Metadata eXchange), uno standard ISO progettato per descrivere dati statistici e relativi metadati, normalizzare il loro scambio e migliorare la loro condivisione tra organizzazioni statistiche e simili [12]. 9.2.4.3. Formati per i dati relativi alle imprese e alla proprietà delle imprese. Oltre all’indicazione di utilizzare qualsiasi formato che sia aperto e leggibile meccanicamente, per i documenti che rientrano nel campo di applicazione del Regolamento Delegato (UE) 2018/81579 della Commissione il Regolamento indica di utilizzare il formato XHTML (Xtensible HyperText Markup Language), un linguaggio di marcatura per creare pagine web che utilizza la sintassi XML [13]. [1]. Tratte dal documento “data.europa.eu – Data quality guidelines”, indicato nel box “Risorse utili”, a cui si rimanda per ulteriori approfondimenti. [2]. Tratte dal documento “data.europa.eu – Data quality guidelines”, indicato nel box “Risorse utili”, a cui si rimanda per ulteriori approfondimenti. [3]. Tratte dal documento “data.europa.eu – Data quality guidelines”, indicato nel box “Risorse utili”, a cui si rimanda per ulteriori approfondimenti. [4]. Tratte dal documento “data.europa.eu – Data quality guidelines”, indicato nel box “Risorse utili”, a cui si rimanda per ulteriori approfondimenti. [5]. https://community.wmo.int/activity-areas/wmo-codes/manual-codes/bufr-edition-3-and-crex-edition-1. [6]. https://www.unidata.ucar.edu/software/netcdf/. [7]. https://datatracker.ietf.org/doc/html/rfc20. [8]. http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.pdf. [9]. Per RSS v. https://www.rssboard.org/rss-2-0-1, per Atom v. https://datatracker.ietf.org/doc/html/rfc4287. [10]. https://www.hdfgroup.org/solutions/hdf5/. [11]. https://old.wmo.int/extranet/pages/prog/www/WMOCodes/ManualonCodes.html#Codes. [12]. https://sdmx.org/?page_id=5008. [13]. https://www.w3.org/TR/2018/SPSD-xhtml-basic-20180327/ ... -
AGID
2. Normativa di riferimento
[LG-CONS] Linee Guida sulla formazione, gestione e conservazione dei documenti informatici, adottate con la Determinazione AgID n. 407/2020 come modificate con la Determinazione AgID n. 371/2021. [LG-INT] Linee Guida sull’interoperabilità tecnica delle Pubbliche Amministrazioni, adottate con la Determinazione AgID n. 547/2021 del 1° ottobre 2021. [LG-PDND] Linee Guida sull’infrastruttura tecnologica della Piattaforma Digitale Nazionale Dati per l’interoperabilità dei sistemi informativi e delle basi di dati, adottate con la Determinazione AgID n. 627/2021 del 15 dicembre 2021. [LG-RNDT] Linee Guida recanti regole tecniche per la definizione e l’aggiornamento del contenuto del Repertorio Nazionale dei Dati Territoriali, adottate con la Determinazione AgID n. 50/2022 del 28 febbraio 2022. [LG-SIC] Linee Guida Tecnologie e standard per la sicurezza dell’interoperabilità tramite API dei sistemi informatici, adottate con la Determinazione AgID n. 547/2021 del 1° ottobre 2021 ...