Un dato destinato alla pubblicazione è frutto di una catena di processi e una serie di attività di analisi ed elaborazione finalizzati al miglioramento della qualità e dell’accesso al dato stesso
Nella Figura 3 che segue è rappresentato un possibile percorso di preparazione dei dati per garantirne la produzione e la pubblicazione di qualità, necessariamente elastico per l’applicazione alle diverse realtà amministrative.
Continua a leggere su Docs Italia.
Un dato per l’Open data deve essere di qualità. La qualità va ricercata durante il Ciclo di vita del dato riportato dall’ISO/IEC 25024:2015 (norma UNI CEI ISO/IEC 25024: 2016 “Misurazione della qualità del dato”) composto dalle fasi di: progettazione, acquisizione, integrazione con altri dati, elaborazione, memorizzazione, uso, cancellazione
Oltre agli aspetti affrontati (5.1.3. Analisi, 5.1.4. Arricchimento, 5.1.5. Documentazione, 5.1.6. Validazione, 5.1.7. Pubblicazione ed altri per 6.1 Licenze e 7.1 Pubblicazione) potrebbe essere fornire indicazioni specifiche anche per: Identificazione (come poter identificazione potenziali nuovi dataset all’interno dell’Amministrazione, ad es.: attraverso l’uso di schede informative e interviste.), Monitoraggio (come raccogliere feedback, la collaborazione con i cittadini e monitoraggio della performance dei dataset pubblicati) e Aggiornamento/Dismissione (come fare e cosa valutare nel processo decisionale). Vedi anche il commento per la proposta di utilizzo del modello aperto Open Data Management Cycle (ODMC) in [LG_Open-Data] Allegato B - Standard di riferimento e formati aperti - n°2 da giovanisp
Ove si cita che l’applicazione del processo deve avvenire in maniera costante sarebbe forse utile suggerire una disposizione ciclica delle attività del percorso, eventualmente organizzate in più iterazioni, un po’ come avviene nel concetto di miglioramento continuo e nel ciclo ODMC (già citato da @giovanisp)?
5.1
Uno degli aspetti spesso più sottovalutati nella pubblicazione del dato è la sua struttura, intesa come modellazione di colonne e righe (data arrangement).
Infatti, semplicemente scegliendo diversi insiemi di colonne e manipolando di conseguenza il dato grezzo è possibile esprimere la stessa quantità di informazione in forme diverse.
Sarebbe utile aggiungerei qui un’indicazione a preferire una struttura tidy, in cui ogni variabile forma una colonna e ogni osservazione forma una riga?
Nella mia esperienza è molto più semplice filtrare, elaborare e aggregare i dati in questa forma, e potrebbe facilitarne il riuso
5.1.4
Posto, e sono d’accordo, che l’arricchimento semantico dei dati sia la strada da intraprendere, mi chiedo se l’unica implementazione attuabile sia il modello RDF. Non contesto tanto il framework, quanto il lavoro aggiuntivo che richiede il serializzare e pubblicare ogni dato in forma di triple.
Reputo il RDF non facilmente applicabile sia a scale molto piccole, ad esempio la singola PA che pubblica qualche csv, sia a scale molto grandi, come quando in un contesto big data andrebbero trasformati diversi GB di dati.
Inoltre i dati così espressi, se da un lato ampliano notevolmente l’interoperabilità machine-machine, restano poco human-readable.
Non sono a conoscenza di progetti in tal senso, ma anche solo prevedere modalità alternative di indicatori (es. uri in formato plain string) potrebbe a mio parere semplificare ed ampliare l’adozione dei dati semantici.
5.1.5
In che modo sarà possibile, nei metadati, esprimere che i valori di una certa colonna o attributo appartengono ad un modello dati del dominio o a un vocabolario? Esiste uno standard? Mi sembra che attualmente sia possibile definire una URI solo a livello di singolo record ma non di dataset (se non utilizzando SHACL in contesti RDF).
Sarebbe invece molto utile sapere preventivamente che i valori corrisponderanno ad un concetto e ad una conseguente lista: aiuterebbe sia in fase di documentazione che di validazione.
5.1.5
Quando si cita che i set di dati devono essere descritti in una documentazione online completa e pubblicamente disponibile che contenga almeno la definizione della struttura e della semantica dei dati, esiste uno standard e/o un modello per la definizione strutturale (schema) dei dati?
Spesso non esistono metadati a supporto dei dati, oppure sono insufficienti e/o troppo generici.
Sarebbe sensato suggerire (o rendere obbligatoria) la presenza degli schema (JSON schema, XSD, CSV schema etc.) relativi ad ogni dataset pubblicato, così come suggerito sulle Data Quality Guidelines della EU?
In questo modo sarebbe molto semplice per il cittadino (o anche il catalogo stesso) valutare la validare dei dati pubblicati.
5.1.6
Per esperienza, gran parte del lavoro di validazione è definito dalle cosiddette regole di business (citate anche nelle ISO 25000), ovvero quelle regole di validazione molto specifiche che non interpretano un dataset solo dal punto di vista sintattico o semantico ma che garantiscano il corretto utilizzo del dato nelle procedure (es. a varie categorie di patente corrispondono diverse età minime)
Avrebbe senso citarle nel paragrafo?
5.1.6
Poiché si cita il documento Methodology for data validation, e tenendo ben presente la distinzione tra data validation e data quality, potrebbe avrebbe senso richiamare i concetti di Validation Levels (da 0 a 5), di modo che costituiscano una guida analoga al modello 5 stars per gli open data? Potrebbe anche essere aggiunto un allegato ad hoc.
Spesso, su formati poco strutturati, capita che si violi anche il solo livello 0, ad esempio quando quote e separatori mal gestiti corrompono sintatticamente i csv.