Gruppo di lavoro Open Data¶

Il gruppo che promuove l’uso e la diffusione degli Open Data. Esso riporta all’interno dell’amministrazione le novità inerenti il mondo dell’Open Government, media e valuta le esigenze di pubblicazione dati in base alle normative di riferimento, e ne cura la razionalizzazione rispetto agli altri processi di apertura del dato. Ha la responsabilità di pianificare e coordinare l’evoluzione continua dell’apertura dei dati nell’amministrazione, nonché dell’infrastruttura IT a supporto.

All’interno del gruppo di lavoro è bene prevedere figure che possano fornire il necessario supporto per l’analisi della qualità dei dati, per la definizione delle interfacce d’accesso ai dati, per la promozione di applicazioni sviluppate a partire dai dati pubblicati, fornendo anche nel caso esempi di servizi dimostrativi attraverso cui incentivare il riutilizzo.

Inoltre, il gruppo di lavoro si può occupare della formazione tecnica e concettuale all’interno dell’amministrazione sui temi legati al paradigma Open Data, anche sulla base delle linee guida pubblicate dall’Agenzia per l’Italia Digitale e sullo stato dell’arte degli Open Data dell’amministrazione. Alcuni membri del team (e.g., esperti di tecnologie Web, esperti GIS, esperti di tecnologie e strumenti per i Linked Data) possono occuparsi della gestione del processo di apertura del dato dal punto di vista IT.

Affinché il lavoro del Team Open Data possa essere incisivo all’interno dell’amministrazione, è importante che tale team si confronti con il livello più politico, sia per ottenere da questo le necessarie “spinte”, sia per offrire al decisore politico proposte e stimoli.

Responsabile Open Data (o Data Manager)¶

All’interno del team Open Data è nominato un responsabile. Tale figura permette da un lato di localizzare le competenze necessarie alla gestione delle attività Open Data entro un sistema autonomo di comunicazione e funzionamento, e dall’altro di integrare i processi relativi alle attività di trasparenza in modo parallelo e non seriale. Il responsabile Open Data deve quindi possedere sia le capacità operative di controllo di tale sistema, sia quelle amministrative di coordinamento con i processi già esistenti.

Insieme al team suddetto, conosce i dati dell’amministrazione nel loro insieme, redige linee guida operative per lo scambio dati tra le diverse figure coinvolte (si veda sotto), e pianifica la strategia di apertura dei dati raccolti e analizzati e le attività di diffusione dei dati. Infine, collabora e si coordina con il Responsabile della Trasparenza (quest’ultimo istituito ai sensi del D.lgs. n. 33/2013 e s.m.i) al fine di rafforzare vicendevolmente gli obiettivi da un lato di massimo riutilizzo dei dati pubblici di tipo aperto e dall’altro di trasparenza.

Responsabile della banca dati¶

All’interno dell’amministrazione è responsabile del procedimento amministrativo che popola la specifica fonte del dato, che ne cura la qualità e il relativo aggiornamento. Tipicamente un Dirigente o un Quadro, coordina un gruppo di persone che svolgono il loro lavoro quotidiano attorno alla fonte del dato. Ha anche il potere di decidere se modificare un certo dato sulla base di indicazioni pervenute ad esempio da cittadini che, vedendo il dataset, ne richiedono una versione evoluta.

Referente tecnico della banca dati¶

Si tratta tipicamente di un componente del gruppo coordinato dal responsabile della banca dati; esso deve avere conoscenze informatiche e svolge un ruolo operativo sul sistema gestionale afferente al dato. Inoltre, fornisce indicazioni circa il reperimento concreto dei dati dalla base dati, e cura il monitoraggio dei vari “connettori” che a partire dalla base dati espongono il dato come Open Data. Tipicamente riceve materialmente le segnalazioni dei cittadini sul dataset di propria competenza, e le smista eventualmente al Referente tematico per valutarne il contenuto, prima di chiedere al Responsabile della Banca Dati l’approvazione per eventuali azioni correttive strutturali sul dataset.

Referente tematico della banca dati¶

Si tratta di un esperto di dominio che conosce in modo approfondito l’ufficio e la storia dei dati su cui l’ufficio opera. Spesso propone nuovi dataset da esporre a partire dal sistema gestionale corrispondente e cura eventuali valutazioni di dominio o relative al significato dei dati. Ha anche la possibilità di compiere bonifiche e semplici adeguamenti sulla banca dati, su segnalazione di cittadini o su valutazioni proprie. Riferisce invece al Responsabile della Banca dati la necessità di eventuali variazioni strutturali al sistema gestionale che insiste sui dati.

Ufficio Statistica¶

Un anello importante dell’intera catena, sia nel promuovere nuove tipologie di dataset da esporre, sia nel validare dal punto di vista metodologico e statistico i dati pubblicati e le loro visualizzazioni.

Ufficio giuridico-amministrativo¶

Può assumere le più svariate forme in base all’organizzazione interna dell’amministrazione. In generale esso rappresenta una singola figura che fornisce consulenza sia su aspetti non tecnici legati agli Open Data, come la definizione delle licenze e delle note legali associate ai dati, la loro rimodulazione sulla base di esigenze specifiche (si pensi per esempio alla necessità di aprire dati prodotti da terze parti o addirittura da cittadini), sia su tutte quelle problematiche di tipo giuridico o amministrativo, comprese quelle di privacy, di finalità del dataset e di trattamento del dato personale ove presente.

Gruppo comunicazione¶

Può assumere varie forme in base all’organizzazione interna dell’amministrazione, ma in ogni caso si indicano quelle figure con competenze di comunicazione istituzionale e non solo, in grado di curare la comunicazione e il dialogo con i cittadini.

Il Modello RACI¶

Rispetto alle linee di azione del modello operativo mostrato in Figura 5, e descritte di seguito, si individua la matrice dei Ruoli e delle Responsabilità (RACI) [3] tra le diverse figure identificate.

Dove OD = Open Data, BD = Base Dati e

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

Bibliografia

Linea 1: Dati Nativi¶

La linea 1 dei dati nativi tratta tutta la filiera di gestione ed esposizione dei dati esistenti generati dalle amministrazioni. Questi dati sono principalmente prodotti dai vari uffici durante l’adempimento delle proprie funzioni istituzionali. La maggior parte di questi dati possono essere pubblicati come dati aperti, portando un’ineludibile fonte potenziale di sviluppo per il territorio e per l’intero sistema Paese.

Censimento. All’interno dei singoli uffici o dei vari settori dell’amministrazione vanno quindi ricercate quelle che si possono chiamare “basi di dati primarie” oggetto del censimento. Si tratta di individuare quegli uffici che generano, mantengono e sono responsabili delle specifiche tipologie di dati che si vogliono rendere aperti (e.g., lo sportello unico per le attività produttive (SUAP) del comune è lo strumento che va a semplificare gli adempimenti connessi alla creazione, l’avvio, la modifica e la cessazione delle imprese per la produzione di beni e servizi. L’ufficio SUAP gestisce e mantiene quindi l’archivio con i dati di tutte le imprese del territorio).

In quelle realtà in cui il processo di apertura dei dati ha raggiunto una fase matura, il concetto di dato nativo può evolvere, includendo non solo i dati raccolti perché legati all’attività amministrativa, ma anche tutte quelle informazioni che, una volta aperte, possano abilitare nuove forme di riutilizzo dell’informazione. Per esempio, se finora per un ufficio non era prioritario raccogliere in maniera strutturata un certo tipo di dato (e.g., gli esercizi che vendono prodotti a km zero o i locali che hanno prodotti per celiaci), perché non strettamente correlato a qualche norma o regolamento amministrativo, il solo fatto che un dato “nativo” poi viene aperto e reso fruibile in forme strutturate al cittadino, lo rende un dato utile all’attività istituzionale nel concetto “esteso” della pubblica amministrazione, inteso non solo come soggetto erogatore di servizi pubblici, ma anche come espositore di patrimonio informativo che abilita nuove forme di business sul mercato. I dati aperti, quindi, modificano il concetto stesso di utilità del dato inserendo nella categoria dei dati “nativi” della PA informazioni che prima non erano ritenute tali dalla PA stessa, ma che risultano invece utili all’esterno.

A tal riguardo si evidenzia che il titolare del dato, ai sensi dell’articolo 5 comma 2 del D.lgs 36/2006 come modificato dal D.lgs 18 maggio 2015, n. 102 e s.m.i., stabilisce le modalità di acquisizione delle richieste con proprio provvedimento, instaurando così una collaborazione con le suddette categorie che possono sfruttare tali modalità per avanzare le proprie proposte.

Analisi giuridica delle fonti. Alla fase di censimento fa seguito l’analisi giuridica delle fonti del dato. Essa è fondamentale per garantire sostenibilità nel tempo del processo di produzione e pubblicazione dei dati e creare un servizio equilibrato nel rispetto della funzione pubblica e dei diritti dei singoli individui. L’analisi giuridica delle fonti mira quindi a valutare questi delicati equilibri, evidenziando limitazioni d’uso, finalità di competenza, determinazione dei diritti e dei termini di licenza.

Analisi della qualità dei dati. All’analisi giuridica delle fonti segue l’analisi della qualità dei dati. Per la definizione del concetto generale di qualità si può ricorrere alla norma ISO 9000:2015, secondo cui la qualità è la totalità degli elementi e delle caratteristiche di un prodotto o servizio che concorrono alla capacità dello stesso di soddisfare esigenze espresse o implicite. Nella sezione dedicata alla “qualità dei dati” di seguito riportata si identificano alcune misure e un metodo di valutazione, considerando gli standard ISO di riferimento ISO/IEC 25012 e lo standard ISO/IEC 25024.

Bonifica. Generalmente l’analisi della qualità del dato può richiedere una fase di bonifica. Infatti, i dati all’interno dei sistemi informativi o degli archivi di un’amministrazione sono spesso “sporchi” e non rispondenti ai requisiti di qualità (e.g., accuratezza, completezza, ecc.). L’apertura dei dati può essere uno stimolo importante per la conduzione di attività mirate di bonifica. Si distinguono processi di bonifica basati sui dati e basati sui processi. I processi di bonifica basati sui dati prevedono che il dataset sia corretto in uno dei due seguenti modi: (i) confronto con il mondo reale (anche con attività economicamente onerose come contattare direttamente i soggetti preposti alla gestione della base dati che presenta errori per correggerli insieme loro) e (ii) confronto incrociato (matching) con altri dataset. Tali processi hanno il vantaggio di poter pervenire in termini relativamente brevi al risultato, ma lo svantaggio di non risolvere il problema alla radice. Infatti, in un arco temporale medio-lungo, i dataset potrebbero nuovamente presentare i problemi di qualità. I processi di bonifica basati sui processi hanno invece la caratteristica di analizzare le cause che hanno portato alla scarsa qualità del dato e di rivedere i processi di produzione del dato per garantirne la qualità nel tempo. Per esempio, se si riscontra che la scarsa accuratezza di una base di dati deriva da un processo di “data entry” manuale, si può intervenire prevedendo una fase di acquisizione automatica dei dati che minimizzi la possibilità di errore di acquisizione. L’adozione di processi di bonifica “basati sui processi” ha dunque il consistente vantaggio di essere una strategia risolutiva.

Politiche di accesso e licenza. Altro aspetto importante da considerare sono eventuali forme di aggregazione dei dati e restrizioni di accesso, che hanno anche un impatto sulla scelta della licenza, tappa quest’ultima prevista dal modello operativo e trattata ampiamente in “Aspetti legali e di costo” a cui si rimanda.

Analisi di processo, (re)ingegnerizzazione dei processi organizzativi e produzione dei dati. Ogni dato ha un proprio ciclo di vita, caratterizzato da uno specifico tasso di aggiornamento o manutenzione.

Vanno quindi individuati non solo i dati nativi “grezzi” di partenza ma anche gli attori che concorrono alla prima produzione del dato, distinguendo chi è responsabile e titolare dello stesso e chi invece aggiunge altri elementi informativi nel processo produttivo. Quello che accade sovente nelle amministrazioni è che i dati sono gestiti da singoli funzionari, nell’ambito di processi “verticali” chiusi a livello di dipartimento e molto spesso ancorati alle conoscenze di una persona specifica. Accade così che elementi conoscitivi importanti siano delocalizzati tra i servizi di competenza, senza che tuttavia sussista una gestione federata e complessiva della risorsa dati. Questo fatto, tra i molteplici effetti negativi, ha spesso quello della duplicazione dei dati: uffici tematicamente contigui tendono a replicare informazioni funzionali alla propria attività, con un incremento del rumore di fondo attorno al patrimonio informativo dell’amministrazione. L’utilizzo di codici condivisi a livello nazionale, di classificazioni comuni per tipologie di dato non dipendenti da specifici domini e ll passaggio verso la creazione di una risorsa federata (fase data hub interno) consentono di superare progressivamente le suddette criticità. L’impegno politico e il relativo sostegno da parte dei livelli manageriali più alti costituiscono comunque il prerequisito fondamentale senza il quale ogni sforzo può essere vano.

Metadatazione. Il risultato delle precedenti tappe del modello operativo si traduce nella produzione di metadati che, in buona sostanza, certificano le caratteristiche del dato. Come detto precedentemente la metadatazione è cruciale: una delle peggiori malattie che affliggono i dati della PA è la molteplicità di copie disponibili di una stessa informazione, senza che sussista la necessaria certezza sulle caratteristiche e sulla validazione di ciascun rilascio. Si ricorda a tal riguardo di seguire il modello per i metadati descritto in “Modello per i metadati” e in particolare il profilo DCAT-AP_IT che consente di specificare i più importanti metadati descrittivi per i dataset (e.g., soggetti e relativi ruoli, contestualizzazione geografica e temporale, licenza, frequenza di aggiornamento, aspetti di distribuzione, punto di contatto, ecc.).

Data hub interno, produzione di livello 3, e pubblicazione. Nel modello operativo proposto, la risorsa federata è rappresentata dal cosiddetto data hub interno. Essa è una piattaforma dove far confluire tutti i dati prodotti dai diversi dipartimenti dell’amministrazione nella loro versione rilasciata ufficialmente. Questa infrastruttura, una volta attivata e messa a regime, viene a contenere lo stato dell’arte del patrimonio informativo e costituisce un potente punto di riferimento, accessibile da parte delle autorità di accesso, secondo diverse modalità (a “tag” o “query”). Essa, inoltre, costituisce lo snodo fondamentale, non solo per la linea dei dati nativi che può proseguire verso la produzione e la pubblicazione di dataset di livello 3, ma per tutte le altre direttrici indicate. In generale, il data hub interno, presumibilmente creato anche attraverso basi di dati consolidate e mantenute costantemente aggiornate attraverso l’inserimento di dati da parte dei funzionari dell’amministrazione, può essere agevolmente utilizzato per la gestione di un processo dinamico e sostenibile nel tempo di produzione di dati aperti, periodicamente aggiornati a ogni nuova revisione del data hub stesso. Infine, è bene notare che l’uso degli standard previsti per i livelli 4 e 5 del modello per i dati aperti (i.e., standard del Web semantico, come per esempio RDF e OWL descritti in “Architettura dell’informazione del settore pubblico”) può facilitare la definizione e la gestione del data hub interno, consentendo una più agevole integrazione tra i dati del patrimonio informativo.

Conservazione e storicizzazione. I dataset rilasciati costituiscono non solo una risorsa per la collettività, ma un prezioso patrimonio anche per le pubbliche amministrazioni che possono in questo modo archiviare in modo alternativo i loro dati in modalità indipendente dagli applicativi software originali che li hanno prodotti. Per questo motivo è importante premunirsi di un sistema di archiviazione/conservazione che mantenga le diverse versioni dei dati nel lungo periodo. A tal fine si raccomanda di assicurare che le versioni stesse siano accessibili a un URL stabile, che sia anche documentato unitamente alla pubblicazione del dato.

Linea 2: Dati Mashup¶

Oltre alla pubblicazione dei dati nativi, attività istituzionali multidisciplinari, che coinvolgono più di una pubblica amministrazione, potrebbero rendersi necessarie. Inoltre è cruciale la sensibilità dell’amministrazione rispetto agli stimoli e alle proposte provenienti dalla società civile. A tal riguardo, ogni nuovo dato in questa linea nasce da uno specifico “concept”. ovvero la proposta necessaria a definire gli elementi fondamentali di un progetto. All’interno di un “concept” si identifica l’idea generale e le linee guida del progetto che ne accompagnano la declinazione nel corso della fase esecutiva. Al “concept” fa seguito la raccolta delle informazioni dalle diverse fonti interne ed esterne che concorrono alla formazione del dato. Questa operazione di “mashup” (da cui il nome della linea) non implica soltanto la raccolta del dato da fonti diverse e la relativa definizione degli algoritmi di integrazione. La parte più importante è la definizione delle modalità di accesso a partire dalle politiche dei singoli produttori dei dati e le relative modalità di rilascio e aggiornamento dei dati. Questo tipo di dati, nati a seguito di particolari esigenze o di determinati disegni strategici, sono creati in funzione dell’esposizione al pubblico e del conseguente coinvolgimento. Per questo, essi si prestano a forme di coinvolgimento e visualizzazione (“data visualization”) particolarmente innovative che spesso sono definite già a livello di “concept”. Il risultato ultimo di questa linea è la produzione di API e/o la pubblicazione di altri dataset. In generale, si raccomanda di utilizzare un approccio di pubblicazione dataset/API, pubblicando come API sicuramente i dataset che necessitano di un aggiornamento dinamico e variabile, alleviando dall’onere dell’aggiornamento manuale.

Si noti infine che i risultati attesi da questa linea possono essere anche ottenuti con l’applicazione dei principi e metodologie previste per la linea 3 dei Linked Open Data, di seguito descritta, grazie ai collegamenti possibili tra i dati.

Linea 3: Linked Open Data¶

Nel modello operativo proposto in Figura 5, la linea Linked Open Data è raffigurata come una filiera di lavorazione autonoma in quanto considerata ancora per molte amministrazioni, soprattutto medio piccole, un percorso complesso da intraprendere, dove sono richieste competenze tecniche specifiche.

Nel modello operativo, vi è una chiara interconnessione tra la linea dei dati nativi e quella dei Linked Open Data. La connessione tra queste due linee (seppur non illustrata graficamente in Figura 5) è anche rafforzata dal fatto che alcune delle fasi attraversate dalla linea dei dati nativi sono necessarie per avviare, analogamente, il percorso sulla linea dei Linked Open Data. E” altresì importante notare che nella pratica si ritiene a volte necessario passare da modelli di rappresentazione tradizionali come quello relazionale per la modellazione dei dati operando opportune trasformazioni poi per renderli disponibili secondo i principi dei Linked Open Data. Tuttavia tale pratica non è necessariamente quella più appropriata: esistono situazioni per cui può essere più conveniente partire da un’ontologia del dominio e che si intende modellare e dall’uso di standard del Web semantico per poter governare i processi di gestione dei dati. Sebbene le linee guida della Commissione di Coordinamento SPC1 sull’interoperabilità semantica attraverso i Linked Open Data siano risalenti al 2012, la metodologia ivi proposta risulta essere ancora valida e solida per una produzione ottimale di Linked Open Data. Infatti, analizzando alcune fasi appartenenti alla linea dei dati nativi (i.e., censimento, analisi della qualità, bonifica e metadatazione) e alla linea dei Linked Open Data (i.e., modellazione, ontologia, inferenza, interlinking, validazione e pubblicazione) si nota come queste richiamino integralmente le sette fasi dell’approccio metodologico delle suddette linee guida. Si incoraggiano quindi le amministrazioni a riferirsi ancora a quel lavoro per affrontare il processo di produzione di Linked Open Data.

Linea 4: Coinvolgimento (Engagement)¶

Il percorso di coinvolgimento si relaziona facilmente anche con il noto modello internazionale a cinque stelle dell’engagement, proposto dal ricercatore inglese Tim Davies per attivare una strategia di rilascio di dataset aperti che sia il più possibile inclusiva. Il modello si compone dei seguenti livelli:

Essere guidati dalla domanda – pubblicare dati che soddisfino una domanda specifica di stakeholder esterni implica cominciare a ridurre le continue richieste di dati a un ufficio.

Inserire dati nel contesto – accompagnare i dati con una ricca documentazione ne permette un facile riutilizzo. Porli nel corretto contesto amplifica tale possibilità. Due ottimi esempi di implementazione di strategia di engagement di livello 2 vengono dal progetto recente Open Cantieri del Ministero delle Infrastrutture e dei Trasporti e dal progetto «OpenCoesione» del Dipartimento per lo Sviluppo e la Coesione Sociale. Il portale OpenCoesione presenta una grafica, corredata da una mappa e diagrammi, che permettono di prendere visione, in maniera efficace, della distribuzione dei fondi sociali europei sul territorio italiano. L’applicazione permette inoltre di scaricare i dati sia nella loro totalità, sia nello specifico caso dei progetti presentati o nelle loro aggregazioni per categoria o amministrazione comunale/provinciale/regionale.

Supportare conversazioni intorno ai dati – Molti cataloghi Open Data ospitano una sezione FAQ e offrono diversi canali di interazione quali email o social network attraverso cui dialogare con l’ente pubblico che distribuisce i dati. Nuovamente, il caso di OpenCoesione può essere visto come una buona iniziativa di coinvolgimento di questo livello in quanto offre la possibilità di usufruire di tali canali per innescare una conversazione online.

Creare capacità, competenze e reti – in questo livello rientra la fase “scenari d’uso” nel presentare i dati attraverso infografiche interattive si fornisce la possibilità di capire al meglio i dati. Rimane importante però stimolare il riutilizzo organizzando, ove possibile, incontri formativi volti a spiegare i dati e/o a mostrare strumenti di pulizia, analisi, e visualizzazione. Tra gli esempi virtuosi di tali pratiche rientrano “School of Data” dell’Open Knowledge Foundation, i datalab promossi da ISTAT e “A scuola di OpenCoesione” del Dipartimento per lo Sviluppo e la Coesione Sociale e del Ministero dell’Istruzione.

Collaborare su dati come una risorsa comune – il rilascio dei dati prevede cicli di feedback con una comunità di riferimento (spesso quella da cui si è partiti per aprire i dati) da cui trarne delle considerazioni e produrre nuovi dati e strumenti. Nuovamente, l’esempio di OpenCoesione fornisce iniziative virtuose di coinvolgimento a cinque stelle quali hackaton organizzati con la comunità e il progetto monithon.it dove, attraverso segnalazioni partendo dai progetti presentati nel sito di OpenCoesione, chiunque può riportare informazioni aggiuntive per stimolare evoluzioni dei progetti finanziati).