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., <soggetto1> <predicato1> <oggetto1> . <soggetto2> <predicato2> <oggetto2>).

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.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.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.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].