# Feature request: dataset miliari, certificati, aggiornati, linkati e accessibili via API (lo spunto da IPA e ANPR)

**URL:** <https://forum.italia.it/t/feature-request-dataset-miliari-certificati-aggiornati-linkati-e-accessibili-via-api-lo-spunto-da-ipa-e-anpr/6644>\
**Category:** Dati e open data\
**Created:** [24 Dicembre 2018, 12:19pm UTC](https://forum.italia.it/t/feature-request-dataset-miliari-certificati-aggiornati-linkati-e-accessibili-via-api-lo-spunto-da-ipa-e-anpr/6644 "2018-12-24T12:19:24Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![aborruso](https://forum.italia.it/user_avatar/forum.italia.it/aborruso/32/15_2.png) [@aborruso](https://forum.italia.it/u/aborruso)\
**Post date:** [24 Dicembre 2018, 12:19pm UTC](https://forum.italia.it/t/feature-request-dataset-miliari-certificati-aggiornati-linkati-e-accessibili-via-api-lo-spunto-da-ipa-e-anpr/6644/1 "2018-12-24T12:19:24Z")

</div>

## Feature request: dataset miliari, certificati, aggiornati, linkati e accessibili via API (lo spunto da IPA e ANPR)

Buongiorno,  
uso il termine _dataset miliari_ per definire quelli che qualsiasi utente, che fa analisi e visualizzazione di dati, usa di più e direi propedeuticamente: se lavoro ad esempio con dati con “taglio” comunale, mi capiterà spesso di avere bisogno dei codici ISTAT del Comune, i codici “Belfiore” (i.e. i codici catastali), il Codice Fiscale, ecc…

Ci sono da tempo lavori in corso (come i [vocabolari controllati dell’ex-DAF](https://github.com/italia/daf-ontologie-vocabolari-controllati/tree/master/VocabolariControllati/)), c’è il lavoro su ANPR (che certamente si connetterà al precedente), ci sono i dati territoriali ISTAT, ci sono portali nazionali geografici, c’è il paniere, ecc…  
Non sto facendo pertanto una richiesta nuova o illuminante, ma la faccio per sottolineare come questo (almeno per me) sia un obiettivo primario dall’enorme valore per la società tutta, di cui lo “Stato” può e dovrebbe prendersi presto carico in termini di realizzazione e rilascio.

Se ho bisogno dei dati propedeutici anagrafici dei Comuni, ho due fonti che (credo) devo considerare come le migliori possibili:

- i dati di ISTAT [https://www.istat.it/it/archivio/6789](https://www.istat.it/it/archivio/6789);
- i dati di ANPR [https://www.anpr.interno.it/portale/tabelle-di-riferimento](https://www.anpr.interno.it/portale/tabelle-di-riferimento).

Hanno la gran parte delle info sovrapposte, ma le piccole differenze presenti sono per me di grande utilità. In ANPR ho anche ad esempio la denominazione traslilettarata, utile in quei numerosissimi casi in cui si può fare un JOIN soltanto tramite i nomi dei comuni e ho `CEFALU'` e non `CEFALÙ`.

Mi piacerebbe che nel portale nazionale ci fosse un modo per puntare a tutti i dati di questo valore, in modo da avere una sorta di strada d’orata (cit. Mago di Oz) e non stare in giro a cercare e informarmi. Un sistema che federi questi dataset dalle varie fonti, in modo da poter dire “caro cittadino qui sul catalogo trovi i dati più aggiornati e certificati su …, puoi usare il tag `miliare` per avere l’elenco completo”.

A proposito, ma non si può da subito iniziare a mettere i tag `paniere+nazionale` e `paniere+regionale+CodiceIstatRegione`, per tutti i dataset mappati dei vari panieri?

 ![image](https://forum.italia.it/uploads/default/original/2X/d/d573ae18762bc3c75ab524c3a39155ce2153657a.jpeg)

Penso a una lista alla [_github awesome_](https://github.com/awesomedata/awesome-public-datasets) (lo so, anche questa non un’idea nuova), quindi pensata essenzialmente per le persone, ma anche ad accessi per le macchine e quindi a delle **API** Milestone.

Qualcosa che, semplificando un po’, risponda a chiamate di questo tipo:

```auto
http://api.gov.it/rest/municipality/coordinate/38.139102+13.340759?format=json
http://api.gov.it/rest/municipality/cod_com/082053?format=json
http://api.gov.it/rest/municipality/CF/80016350821?format=json
http://api.gov.it/rest/municipality/name/Palermo?format=json

```

e mi risponda con qualcosa come

```auto
[{
    "name": "Palermo",
    "transliteratedName": "Palermo",
    "region": "Sicilia",
    "cod_region": 19,
    "province": "Palermo",
    "cod_province": 82,
    "COD_COM": "082053",
    "cod_cadastral": "G273",
    "CF": "80016350821",
    "IPA" : "c_g273",
    "CAP": ["90100", "90121-90151"],
    "callingCodes": ["091"],
    "population": 600000,
    "area_Sq_Km": 160,
    "borders": ["Altofonte","Belmonte Mezzagno","Ficarazzi","Isola delle Femmine","Misilmeri","Monreale","Torretta","Villabate"],
    "logo": "https://www.comune.palermo.it/js/server/uploads/220x220/_29042018145943.jpg",
    "website": "https://www.comune.palermo.it"
}]

```

Un po’ come la fantastica Wikidata. E sia via chiamate REST che _query_ SPARQL.

L’hanno scorso per realizzare una bella app per SKY, per il “rischio” (di varia natura) nella città, avevamo bisogno di un servizio in HTTPS che, data una coppia di coordinate, restituisse il codice ISTAT. Non ne trovammo di “statali” ufficiali.   
Penso che cose di queste tipo possano/debbano essere anche a carico dello stato.   
  
In alternativa se lo stato non vuole/può creare servizi di base di questo tipo, potrebbe/dovrebbe creare indici “curati”, manutenuti e predisposti per essere _linked_ (con vocabolari controllati, ontologie, ecc.).

Quello dell’anagrafica comunale è soltanto un esempio tra tanti. A cascata mi viene da pensare (vedi sopra) a _query_ che restituiscano dati aggiornati e certificati sul rischio frane (penso da ISPRA), rischio sismico (penso da ISPRA), i dati delle Zone OMI (le quotazioni immobiliari dell’Agenzia del Catasto).

## L’ispirazione viene dai dati IPA (Indice Pubblica Amministrazione)

È un dataset prezioso per tutte quelle applicazioni e servizi basati su interazioni possibili con la PA. Faccio un esempio per tutti: quello delle richieste FOIA e di un’app, un servizio - come [FOIAPop](http://www.foiapop.it/) - per fare richieste ai Comuni e il punto di partenza potrebbe essere quello di estrarre i codici IPA o i CF di tutti i Comuni italiani e usarli come “chiave” nell’applicazione che si sta costruendo.

Ma c’è qualche problema nell’estrarre rapidamente e senza errori questi dati. I dati sui comuni sono (insieme ad altri) qui [https://www.indicepa.gov.it/public-services/opendata-read-service.php?dstype=FS&filename=amministrazioni.txt](https://www.indicepa.gov.it/public-services/opendata-read-service.php?dstype=FS&filename=amministrazioni.txt) e sono aggiornati di frequente (l’ultimo al momento della scrittura è del 2018-12-24).

Se filtro per “Comuni e loro Consorzi e Associazioni” e “Unioni di Comuni e loro Consorzi e Associazioni” ottengo 8663 record, tra cui anche il “Consorzio per Il Servizio di Vigilanza Boschiva Alta Val di Fassa” o il “C.E.A. Centro di Educazione Ambientale Delle Serre Salentine”, quindi anche altro da “Comuni”.  
  
Potrei usare il codice IPA, filtrando tutti gli enti il cui codice inizia per `c_`, ma mi perderei una trentina di comuni (come Ussassai, Vicari, Girasole, Serrastretta, ecc.) che non rispettano questa regola.  
Potrei usare quelli per cui la descrizione inizia per `Comune di `, ma mi perderei ad esempio come le Unioni dei Comuni.  
  
Una cosa che di base dovrebbe essere semplice - estrarre i codici IPA di tutti i comuni italiani - non sembra si possa fare in un passaggio. Un po’ dipende da alcune complessità formali/amministrative di base, un po’ da una struttura che forse si dovrebbe arricchire/modificare/correggere.

Due note “tecniche” proprio su quest’ultimo punto.

Il campo `des_amm` è quello che contiene il nome del Comune (`Comune`). Il campo Comune infatti contiene il nome del Comune in cui ha sede la PA: tanti comuni in Italia hanno sede amministrativa in un altro comune.  
  
Allora potrei estrarre quei comuni in cui c’è coincidenza tra `des_amm` e `Comune`, perché sono sicuramente un set “certificato” di codici IPA e CF di comuni. 7798 su 7936, circa il 98% del campione, ha un _matching_ pieno. Sono i casi di “Comune di Palermo” e “Palermo”: rimosso "Comune di ", c’è _full match_.

Ma poi ci sono numerosi casi per i quali c’è fare pulizia e normalizzazione, per colpa di uno spazio, di un apice. Sotto alcuni esempi (la colonna `check` è la distanza vettoriale tra le stringhe misurata con [fuzzywuzzy](https://github.com/seatgeek/fuzzywuzzy)).

| cod\_amm | des\_amm | ComuneCFR | Comune | check |
| --- | --- | --- | --- | --- |
| c\_g165 | Comune di Ospedaletto D’ Alpinolo | Ospedaletto D’ Alpinolo | Ospedaletto d’Alpinolo | 98 |
| c\_h798 | Comune di San Cipriano D’ Aversa | San Cipriano D’ Aversa | San Cipriano d’Aversa | 98 |
| c\_i213 | Comune di Sant’ Alessio con Vialone | Sant’ Alessio con Vialone | Sant’Alessio con Vialone | 98 |
| c\_i316 | Comune di Santa Vittoria d’ Alba | Santa Vittoria d’ Alba | Santa Vittoria d’Alba | 98 |
| c\_i318 | Comune di Sant’ Egidio alla Vibrata | Sant’ Egidio alla Vibrata | Sant’Egidio alla Vibrata | 98 |
| c\_i336 | Comune di Sant’ Eusanio Forconese | Sant’ Eusanio Forconese | Sant’Eusanio Forconese | 98 |
| c\_i363 | Comune di Santostefano di Magra | Santostefano di Magra | Santo Stefano di Magra | 98 |
| c\_a266 | Comune di Cortina D’ Ampezzo | Cortina D’ Ampezzo | Cortina d’Ampezzo | 97 |
| c\_a434 | Comune di Arqua Petrarca | Arqua Petrarca | Arqua’ Petrarca | 97 |
| c\_a709 | Comune di Bastia Mondovi | Bastia Mondovi | Bastia Mondovi’ | 97 |
| c\_b996 | Comune di Cassago Brianza | Cassago Brianza | Cassago Brianza | 97 |
| … | … | … | … | … |

Ma partire dalle stringhe è comunque problematico, perché ci sono anche nomi di Comuni in più lingue, nella stessa cella.

Allora provo a partire dal campo `cod_amm`, che contiene il codice “Belfiore”, il codice catastale comunale. Si parte dal filtrare tutti i record che contengono a inizio cella `c_`, dal rimuovere `c_` e dal portarlo in maiuscolo (ad esempio per Palermo da `c_g273` a `G273`).  
  
Così facendo si ha una colonna con cui fare il _matching_ e verifica con una fonte certificata di questi codici come i dati ANPR sui comuni.  
I record di IPA che iniziano per `c_` sono 7778, di questi per circa il 2% non c’è il _matching_, quindi 150 Comuni potrebbero avere dentro IPA il codice catastale errato. Alcuni esempi ([qui](https://gist.github.com/aborruso/94bb4cb4a5367df0a19635487b47f6c8) tutti quelli per cui non è stato possibile fare matching diretto tra IPA e ANPR, rispetto ai Comuni oggi attivi):

- Alcara Li Fusi, in IPA è ZBOH, in ANPR è A177;
- Alà dei Sardi, in IPA è WFS6, in ANPR è A115;
- Breia, , in IPA è B136, in ANPR è B136, ma è un comune che con questo nome non esiste dal 31/12/2017.

@giorgialodi ci ha [descritto](https://forum.italia.it/t/sempre-sui-dati-ipa/1476/9) alcune delle cause di questa mancanza di _matching_.   
  
Quindi anche da questo percorso non si riesce ad estrarre in modo diretto, completo e senza rischi di errori, il dato.

# Per chiudere

Sono stato lungo, ma secondo me valeva la pena fare un approfondimento su un caso di dato che dovrebbe essere _milestone_, inserendo anche delle note di dettaglio (che mi auguro possano in ogni caso essere utili).

L’idea è quella di una sorta di “super paniere nazionale”, certificato, aggiornato, metadatato, controllato, standard e linked (o predisposto per). Con il goal massimo di avere dei servizi pubblici nazionali per esporli.  
  
Molti di questi dati miliari sono già _online_ e di qualità; la mia richiesta è quella di trovar il modo di avere almeno anche un super indice curato, un unico punto d’accesso descritto per persone e macchine. Il massimo sarebbe una sorta di wikidata statale.  
  
L’esposizione di dati di questo tipo e in queste modalità potrebbe essere anche l’occasione di un check sulle licenze, così come [proposto qui](https://forum.italia.it/t/le-licenze-degli-opendata-della-pa-e-quelle-di-wikidata-openstreetmap-e-wikipedia/4975) settimane fa.

E buone feste

---

<div class="post-metadata">

**Author:** ![davide\_taibi](https://forum.italia.it/letter_avatar_proxy/v4/letter/d/f08c70/32.png) [@davide\_taibi](https://forum.italia.it/u/davide_taibi)\
**Post date:** [30 Dicembre 2018, 3:38pm UTC](https://forum.italia.it/t/feature-request-dataset-miliari-certificati-aggiornati-linkati-e-accessibili-via-api-lo-spunto-da-ipa-e-anpr/6644/2 "2018-12-30T15:38:37Z")

</div>

Caro @aborruso  
grazie del post. Anche a me, in diverse occasioni, è capitato di scontrarmi con la difficoltà di trovare fonti di dati affidabili, anche nel caso di dati essenziali come l’elenco dei comuni da te riportato.  
Spesso esistono diverse sorgenti ufficiali, ma per ognuna di esse occorre ricorrere a particolari stratagemmi, molto spesso dettati dall’esperienza, per potere estrarre le informazioni desiderate, correndo anche il rischio che l’approccio usato non sia corretto e che i dati estratti non siano completi.  
La tua proposta è molto interessante, e mi piace perché diretta non solo ai dati ma anche ai servizi. Sarebbe auspicabile avere per questi dati fondamentali (o come hai detto bene tu miliari), che in moltissimi casi costituiscono il mattoncino di base su cui vengono create nuove applicazioni, una sola fonte ufficiale, accessibile, affidabile, riutilizzabile e completa (su ognuna di queste caratteristiche occorrerebbe soffermarsi un po’). Questo consentirebbe anche, ad esempio, di superare la pratica correntemente attuata dai diversi servizi della PA di replicare le informazioni di base usando diversi encoding, diversi caratteri speciali, e così via… cose che si prestano bene per proporre esercizi nei corsi di elaborazione dei dati ma che di sicuro rallentano la creazione di nuovi servizi. Quanto sarebbe bello se ISTAT, ANPR, IPA e chissà quanti altri potessero attingere per i dati miliari a un’unica fonte di informazione completa, ovviamente proveniente da organi ufficiali dello stato.  
Concludo anche io, mi sto dilungando troppo.  
Tutto questo non è semplice da realizzare, ma sarebbe bello se si iniziasse a ragionarci su.  
Siamo in un periodo dell’anno in cui viene bene pianificare le attività per l’anno successivo, chissà se … 🙂  
Buone feste anche a te.

---

<div class="post-metadata">

**Author:** ![gpirrotta](https://forum.italia.it/user_avatar/forum.italia.it/gpirrotta/32/1562_2.png) [@gpirrotta](https://forum.italia.it/u/gpirrotta)\
**Post date:** [1 Gennaio 2019, 1:40pm UTC](https://forum.italia.it/t/feature-request-dataset-miliari-certificati-aggiornati-linkati-e-accessibili-via-api-lo-spunto-da-ipa-e-anpr/6644/3 "2019-01-01T13:40:23Z")

</div>

Caro @aborruso  
sarebbe veramente importante reperire da un’unica fonte centrale dati versionati e validati in modo ufficiale, che siano definiti tramite standard e siano accessibili liberamente tramite API, per cui, ben venga la tua proposta.

Ricordo che durante lo sviluppo di FoiaPop cercavo un servizio API ufficiale per recuperare le anagrafiche delle pubbliche amministrazioni (nome, CF, tel, mail, etc.) ma, purtroppo, il livello di flessibilità fornito dai web-services di IPA (accessibile previa registrazione) non consentiva di definire i criteri di selezione per le interrogazioni che mi servivano.

I dati erano (e sono) disponibili anche in modalità “linked” vale a dire massima flessibilità di interrogazione e supporto nativo all’interoperabilità semantica. Tuttavia ricordo che i dati non erano aggiornatissimi per cui il problema rimaneva.

Alla fine mi sono scaricato il dataset **txt** e a tutt’oggi sono costretto ad aggiornare i dati delle PA in FoiaPop almeno un paio di volte l’anno.

Sai bene che i dati di per sé costituiscono un prodotto di processo e le linee guida AGID lo dicono da anni. Non so se è la risposta che cercavi, Andrea, però io penso che qualche spiraglio si comincia a intravedere con il progetto OntoPia. Penso che questo progetto vada verso la direzione che tu auspichi ma sicuramente passerà del tempo affinché il tutto entri a regime.

Concordo in toto con il buon @davide_taibi, bisognerebbe pensarci un po’ e capire se e cosa si può fare adesso, per superare le criticità che sottolinei nel tuo post.

Ciao e buon anno anche a te

---

<div class="post-metadata">

**Author:** ![dagoneye](https://forum.italia.it/user_avatar/forum.italia.it/dagoneye/32/48_2.png) [@dagoneye](https://forum.italia.it/u/dagoneye)\
**Post date:** [3 Gennaio 2019, 10:22pm UTC](https://forum.italia.it/t/feature-request-dataset-miliari-certificati-aggiornati-linkati-e-accessibili-via-api-lo-spunto-da-ipa-e-anpr/6644/4 "2019-01-03T22:22:43Z")

</div>

Ciao Andrea,  
vedo tre richieste precise nel tuo bel post: grazie per averlo condiviso, specie nei giorni di festa (_al pomeriggio della vigilia di Natale_ 🙂 ).

## API dei dati miliari (e potenziali servizi correlati)

Se l’ambito che hai evidenziato fosse gestito al meglio con quel superindice di cui parli, il risparmio e la facilità del riuso aiuterebbe enormemente tutto l’ecosistema, non solo il bacino di riutilizzatori privati, ma soprattutto l’interoperabilità interna alla PA stessa. Se a livello di strategia nel Piano Triennale tutto torna, i tempi di realizzazione non tornano proprio. Mi sono guardato un po’ in giro e cito il punto cardine:

- [https://teamdigitale.governo.it/it/projects/api.htm](https://teamdigitale.governo.it/it/projects/api.htm) - il catalogo delle API è il progetto in cui si potrebbe inserire quest’idea di superindice. Rispetto agli elenchi delle basi dati chiave, il dato comunale è un livello più infrastrutturale, ma non vedo come si potrebbe evitare di lavorare su quel livello senza raggiungere la qualità di cui parli per abilitare poi il resto dei servizi. Si tratta di un lavoro da fare di certo. Me lo immagino implicito nel percorso che era ipotizzato qui: [https://docs.italia.it/italia/piano-triennale-ict/pianotriennale-ict-doc/it/stabile/doc/12\_indicazioni-per-la-pa.html#indicazioni-sui-dati-della-pubblica-amministrazione-e-sul-daf](https://docs.italia.it/italia/piano-triennale-ict/pianotriennale-ict-doc/it/stabile/doc/12_indicazioni-per-la-pa.html#indicazioni-sui-dati-della-pubblica-amministrazione-e-sul-daf).

Forse non si pensava di rendere un livello simile ben visibile, ma direi che è il caso di farlo. Non vedo modi di poterlo fare ufficiosamente come società civile e/o settore privato: è necessario il ruolo della fonte pubblica, nel suo essere fonte primaria e certificata. Un paio di proposte:

1. quest’idea del superindice mi piacerebbe diventasse un prototipo ‘_agile_’, un suggerimento per aiutare a darsi delle priorità a chi sta sviluppando il progetto API. Potrebbe stimolare il resto del lavoro già previsto dalla strategia originale e fungere da leva o acceleratore. Almeno si è certi che c’è domanda su questo specifico ambito;
2. si potrebbe organizzare una challenge di open innovation tra chi quei dati li strausa all’interno della PA (penso a SOGEI, per dirne uno).

Più in generale, **vorrei capire se e quale mano potrebbe dare la società civile a spingere su una proposta simile da chi conosce gli ostacoli che ha trovato lungo il percorso**. La spiegazione di @giorgialodi sui problemi di match dei dati IPA che citavi è datata 18 dicembre 2017. Cosa è successo nel confronto interno nel frattempo? Cosa si è imparato? Sarebbe fondamentale saperlo.

## Maggior evidenza a questi dati miliari

L’idea dei tag è implementabile fin da subito da dati.gov.it, creando un filtro a parte nella navigazione a faccette. **Mi piacerebbe un feedback ufficiale su questo da parte di chi ci lavora. A chi possiamo segnalarlo che ha il potere decisionale di accettare un’idea di questo tipo? Usiamo le issue su github del repo ufficiale?**. A tendere, sarebbe utile una sorta di onboarding per l’utente avanzato che ha bisogno comunque di utilizzare questi dati (che non è detto sia un programmatore), ovviamente in dati.gov.it. Penso sia un pezzetto di un progetto di comunicazione quasi parallelo, che utilizzi direttamente i metadati estratti dalle API dei dati miliari come fonte primaria per migliorare l’esperienza utente di dati.gov.it. Una co-progettazione con la comunità/società civile interessata?

## Evoluzione del paniere dinamico per renderlo più comprensibile e creare coerenza comunicativa di insieme

Questo punto forse l’ho visto un po’ implicito, ma di sicuro serve ripensare il modo di comunicare il paniere dinamico dei dati. La struttura con cui esporre i dati miliari potrebbe essere usata anche per i dati oggetto di previsione/richiesta diretta di pubblicazione. Avevo già dato suggerimenti sul paniere collegandomi alle iniziative statunitensi correlate [https://groups.google.com/a/teamdigitale.governo.it/d/msg/data/ZwcuDWCi2uw/2LcbLgL-AgAJ](https://groups.google.com/a/teamdigitale.governo.it/d/msg/data/ZwcuDWCi2uw/2LcbLgL-AgAJ) - ma non mi è mai stato chiaro cosa sia stato recepito e cosa no. A questo punto, mi sorge una domanda più ampia: suggerire miglioramenti simili da esterni serve? Si tratta di un’aspettativa di partecipazione errata oppure troppo alta? In ogni caso, il feedback sulle proposte e sui singoli punti è necessario darlo, perché non capiamo se stiamo condividendo astrazioni fuori dal mondo del possibile (fattibile) oppure se qualcosa si riesce a salvare 🙂

Buon anno di cuore a tutti,  
Matteo

---

<div class="post-metadata">

**Author:** ![mfortini](https://forum.italia.it/user_avatar/forum.italia.it/mfortini/32/924_2.png) [@mfortini](https://forum.italia.it/u/mfortini)\
**Post date:** [6 Gennaio 2019, 5:24pm UTC](https://forum.italia.it/t/feature-request-dataset-miliari-certificati-aggiornati-linkati-e-accessibili-via-api-lo-spunto-da-ipa-e-anpr/6644/5 "2019-01-06T17:24:15Z")

</div>

Qualche appunto:

- Sì, ci sono 3-4 dataset che tutte le volte tocca elaborare per arrivare a una base dati con cui fare la join al proprio dataset. Penso alle corrispondenze Nome\_regione, Nome\_provincia, Nome\_comune, Codice\_ISTAT, Geometria, che possono essere l’inizio di una choropleth. Ma allo stesso tempo il dettaglio delle sezioni di censimento e della popolazione residente (vedi qui per il 2018 [http://demo.istat.it/pop2018/index3.html](http://demo.istat.it/pop2018/index3.html) , ma le tabelle sono anche troppo dettagliate, eh lo so, “mi lamento che il brodo è grasso”, ma non si riescono più a gestire con un volgare spreadsheet online)
- Benissimo le API (vanno di moda, e ci sono molti buoni motivi)… ma:
  - facciamo un gist o un fiddle di query di esempio, magari embeddabili. “Quanti abitanti ha il comune di xxxxx?” (questa si potrebbe anche embeddare in Wikipedia, per dirne una, o forse meglio LOD collegati a Wikidata) “Qual è l’indice di vecchiaia e l’età media delle Province italiane?” (è appena uscito il report, siccome la query si farebbe con 2 click, perché non dare la possibilità a tutti di vedere che “non c’è trucco, non c’è inganno”?) “Qual è il tasso di criminalità, di cementificazione, …?”
  - diamo la possibilità di scaricare _sempre_ i dataset raw aggiornati. Perché poi fatte le API salta fuori il problema di “qual è un _free tier limit_ accettabile?” “dopo quante facciamo pagare?” e il povero smanettone a cui scappa la query troppo esosa poi perde la voglia di provarci. Chi non vuole usare le API o vuol farsi le sue, si scarichi i dati
  - usiamo _tutti_ le stesse API. Non devono essere un regalo, devono essere quelle che fanno funzionare anche gli uffici interni
  - definiamo e rispettiamo degli **SLA** rigorosi. Dire “il servizio è down per 2h per manutenzione” non si fa più nel 2019, non è corretto. Gli strumenti ci sono, i servizi si possono rendere disponibili con tanti 9 dopo la virgola. Se ci crediamo, investiamoci e creiamo servizi degni di questo nome, o appoggiamoli su sistemi esistenti che hanno dimostrato la loro robustezza. Altrimenti ce lo sogniamo di avere la startup o la no profit che crea valore dai dati pubblicati usando le nostre API, quando le pagine si caricano con tanti errori perché un servizio non è contattabile.

Grazie ad Andrea per aver sollevato il problema e a tutti i commenti, e buon 2019!

---

<div class="post-metadata">

**Author:** ![giorgialodi](https://forum.italia.it/user_avatar/forum.italia.it/giorgialodi/32/398_2.png) [@giorgialodi](https://forum.italia.it/u/giorgialodi)\
**Post date:** [26 Gennaio 2019, 10:42am UTC](https://forum.italia.it/t/feature-request-dataset-miliari-certificati-aggiornati-linkati-e-accessibili-via-api-lo-spunto-da-ipa-e-anpr/6644/6 "2019-01-26T10:42:17Z")

</div>

Ciao Andrea  
rispondiamo in linea pezzo per pezzo.

> [@aborruso](#):
>
> Buongiorno,  
> uso il termine _dataset miliari_ per definire quelli che qualsiasi utente, che fa analisi e visualizzazione di dati, usa di più e direi propedeuticamente: se lavoro ad esempio con dati con “taglio” comunale, mi capiterà spesso di avere bisogno dei codici ISTAT del Comune, i codici “Belfiore” (i.e. i codici catastali), il Codice Fiscale, ecc…
> 
> Ci sono da tempo lavori in corso (come i [vocabolari controllati dell’ex-DAF](https://github.com/italia/daf-ontologie-vocabolari-controllati/tree/master/VocabolariControllati/)), c’è il lavoro su ANPR (che certamente si connetterà al precedente), ci sono i dati territoriali ISTAT, ci sono portali nazionali geografici, c’è il paniere, ecc…  
> Non sto facendo pertanto una richiesta nuova o illuminante, ma la faccio per sottolineare come questo (almeno per me) sia un obiettivo primario dall’enorme valore per la società tutta, di cui lo “Stato” può e dovrebbe prendersi presto carico in termini di realizzazione e rilascio.
> 
> Se ho bisogno dei dati propedeutici anagrafici dei Comuni, ho due fonti che (credo) devo considerare come le migliori possibili:
> 
> - i dati di ISTAT [https://www.istat.it/it/archivio/6789](https://www.istat.it/it/archivio/6789);
> - i dati di ANPR [https://www.anpr.interno.it/portale/tabelle-di-riferimento](https://www.anpr.interno.it/portale/tabelle-di-riferimento).
> 
> Hanno la gran parte delle info sovrapposte, ma le piccole differenze presenti sono per me di grande utilità. In ANPR ho anche ad esempio la denominazione traslilettarata, utile in quei numerosissimi casi in cui si può fare un JOIN soltanto tramite i nomi dei comuni e ho `CEFALU'` e non `CEFALÙ` .
> 
> Mi piacerebbe che nel portale nazionale ci fosse un modo per puntare a tutti i dati di questo valore, in modo da avere una sorta di strada d’orata (cit. Mago di Oz) e non stare in giro a cercare e informarmi. Un sistema che federi questi dataset dalle varie fonti, in modo da poter dire “caro cittadino qui sul catalogo trovi i dati più aggiornati e certificati su …, puoi usare il tag `miliare` per avere l’elenco completo”.
> 
> A proposito, ma non si può da subito iniziare a mettere i tag `paniere+nazionale` e `paniere+regionale+CodiceIstatRegione` , per tutti i dataset mappati dei vari panieri?
> 
> [![image](https://forum.italia.it/uploads/default/original/2X/d/d573ae18762bc3c75ab524c3a39155ce2153657a.jpeg)  
> image.jpg800×612 210 KB  
> ](https://forum.italia.it/uploads/default/original/2X/d/d573ae18762bc3c75ab524c3a39155ce2153657a.jpeg)
> 
> Penso a una lista alla [_github awesome_](https://github.com/awesomedata/awesome-public-datasets) (lo so, anche questa non un’idea nuova), quindi pensata essenzialmente per le persone, ma anche ad accessi per le macchine e quindi a delle **API** Milestone.

Ti ringraziamo molto per questi spunti. In effetti è da tempo che nel contesto DAF, ma non solo, si sta pensando di far emergere i dataset miliari, come li chiami tu, nella marea di dataset disponibili nel nostro Paese. Tra l’altro, la nuova revisione della direttiva PSI dovrebbe porre l’accento su dataset di “high value”; quello che suggerisci diventa quindi ancora più importante. Possiamo dirti che, nel contesto della PDND (o DAF), stiamo pianificando delle attività per arrivare ad avere questo puntatore diretto alla lista di dataset ad alto valore.

> [@aborruso](#):
>
> Qualcosa che, semplificando un po’, risponda a chiamate di questo tipo:
> 
> ```auto
> http://api.gov.it/rest/municipality/coordinate/38.139102+13.340759?format=json
> http://api.gov.it/rest/municipality/cod_com/082053?format=json
> http://api.gov.it/rest/municipality/CF/80016350821?format=json
> http://api.gov.it/rest/municipality/name/Palermo?format=json
> 
> ```
> 
> e mi risponda con qualcosa come
> 
> ```auto
> [{
> "name": "Palermo",
> "transliteratedName": "Palermo",
> "region": "Sicilia",
> "cod_region": 19,
> "province": "Palermo",
> "cod_province": 82,
> "COD_COM": "082053",
> "cod_cadastral": "G273",
> "CF": "80016350821",
> "IPA" : "c_g273",
> "CAP": ["90100", "90121-90151"],
> "callingCodes": ["091"],
> "population": 600000,
> "area_Sq_Km": 160,
> "borders": ["Altofonte","Belmonte Mezzagno","Ficarazzi","Isola delle Femmine","Misilmeri","Monreale","Torretta","Villabate"],
> "logo": "https://www.comune.palermo.it/js/server/uploads/220x220/_29042018145943.jpg",
> "website": "https://www.comune.palermo.it"
> }]
> 
> ```
> 
> Un po’ come la fantastica Wikidata. E sia via chiamate REST che _query_ SPARQL.

Su questo punto vorremmo fin da ora condividere un lavoro che stiamo revisionando e finalizzando. I dataset che menzioni sono già stati da noi “lavorati” nel contesto del DAF.

In particolare, lo scenario è il seguente:

1. **dataset archivio storico comuni di ANPR** —\> presente nel DAF e disponibile per il download e per l’interrogazione via API [attraverso il data portal](https://dataportal.daf.teamdigitale.it/#/dataset/anpr_comuni_italiani);

2. **dataset ISTAT elenco comuni** —\> presente nel DAF e disponibile per il download e per l’interrogazione via API [attraverso il data portal](https://dataportal.daf.teamdigitale.it/#/dataset/istat_comuni_italiani)

3. questi due dataset sono stati usati e “uniti” per creare un dataset **linked open data dell’archivio storico dei comuni** che si aggiunge ai dataset, sempre linked open data e presentati sotto forma di vocabolari controllati, sulle regioni e province italiane. Mentre i dataset sulle regioni e le province sono già stati pubblicati nel repository che tu prima citavi, il dataset sull’archivio storico dei comuni ha bisogno ancora di lavorazione. In ogni caso, riteniamo possa essere interessante condividere il processo che abbiamo messo in piedi finora. Infatti, per questi dataset, attraverso un processo di triplificazione trasformiamo i dati presenti nella piattaforma big data del DAF in Linked Data utilizzando le ontologie di OntoPiA e li pubblichiamo automaticamente nello SPARQL endpoint del DAF stesso, già disponibile online e contenente già tutte le ontologie e i vocabolari controllati di OntoPiA. Terminati gli ultimi lavori è nostra intenzione pubblicare gli script di conversione nonché esempi di query SPARQL.

Di fatto siamo facendo come la “fantastica Wikidata”, solo che abbiamo di fondo anche modelli ontologici specifici per il contesto italiano e fatti in collaborazione con diverse PA titolari dei dati. Le coordinate potrebbero essere ricavate quindi grazie a possibili linking con dataset esterni (tipo genomes). Stiamo valutando se inserire già il linking nei dataset LOD o se lasciare anche allo sviluppo futuro, di chi voglia contribuire alla wikidata della PA italiana, questo passo. Potrebbe essere una cosa molto interessante dal punto di vista delle comunità e delle loro specifiche esigenze.

> [@aborruso](#):
>
> L’hanno scorso per realizzare una bella app per SKY, per il “rischio” (di varia natura) nella città, avevamo bisogno di un servizio in HTTPS che, data una coppia di coordinate, restituisse il codice ISTAT. Non ne trovammo di “statali” ufficiali.  
> Penso che cose di queste tipo possano/debbano essere anche a carico dello stato.
> 
> In alternativa se lo stato non vuole/può creare servizi di base di questo tipo, potrebbe/dovrebbe creare indici “curati”, manutenuti e predisposti per essere _linked_ (con vocabolari controllati, ontologie, ecc.).
> 
> Quello dell’anagrafica comunale è soltanto un esempio tra tanti. A cascata mi viene da pensare (vedi sopra) a _query_ che restituiscano dati aggiornati e certificati sul rischio frane (penso da ISPRA), rischio sismico (penso da ISPRA), i dati delle Zone OMI (le quotazioni immobiliari dell’Agenzia del Catasto).

Condividiamo il tuo punto di vista 🙂

> [@aborruso](#):
>
> ## L’ispirazione viene dai dati IPA (Indice Pubblica Amministrazione)
> 
> È un dataset prezioso per tutte quelle applicazioni e servizi basati su interazioni possibili con la PA. Faccio un esempio per tutti: quello delle richieste FOIA e di un’app, un servizio - come [FOIAPop](http://www.foiapop.it/) - per fare richieste ai Comuni e il punto di partenza potrebbe essere quello di estrarre i codici IPA o i CF di tutti i Comuni italiani e usarli come “chiave” nell’applicazione che si sta costruendo.
> 
> Ma c’è qualche problema nell’estrarre rapidamente e senza errori questi dati. I dati sui comuni sono (insieme ad altri) qui [https://www.indicepa.gov.it/public-services/opendata-read-service.php?dstype=FS&filename=amministrazioni.txt](https://www.indicepa.gov.it/public-services/opendata-read-service.php?dstype=FS&filename=amministrazioni.txt) e sono aggiornati di frequente (l’ultimo al momento della scrittura è del 2018-12-24).
> 
> Se filtro per “Comuni e loro Consorzi e Associazioni” e “Unioni di Comuni e loro Consorzi e Associazioni” ottengo 8663 record, tra cui anche il “Consorzio per Il Servizio di Vigilanza Boschiva Alta Val di Fassa” o il “C.E.A. Centro di Educazione Ambientale Delle Serre Salentine”, quindi anche altro da “Comuni”.
> 
> Potrei usare il codice IPA, filtrando tutti gli enti il cui codice inizia per `c_` , ma mi perderei una trentina di comuni (come Ussassai, Vicari, Girasole, Serrastretta, ecc.) che non rispettano questa regola.  
> Potrei usare quelli per cui la descrizione inizia per `Comune di` , ma mi perderei ad esempio come le Unioni dei Comuni.
> 
> Una cosa che di base dovrebbe essere semplice - estrarre i codici IPA di tutti i comuni italiani - non sembra si possa fare in un passaggio. Un po’ dipende da alcune complessità formali/amministrative di base, un po’ da una struttura che forse si dovrebbe arricchire/modificare/correggere.
> 
> Due note “tecniche” proprio su quest’ultimo punto.
> 
> Il campo `des_amm` è quello che contiene il nome del Comune ( `Comune` ). Il campo Comune infatti contiene il nome del Comune in cui ha sede la PA: tanti comuni in Italia hanno sede amministrativa in un altro comune.

Sì, questo perché, come già discusso in altri post sul forum, si tende a confondere Comune inteso come entità amministrativa con Comune inteso come entità territoriale. I dataset indicati sopra danno la dimensione territoriale

> [@aborruso](#):
>
> Allora potrei estrarre quei comuni in cui c’è coincidenza tra `des_amm` e `Comune` , perché sono sicuramente un set “certificato” di codici IPA e CF di comuni. 7798 su 7936, circa il 98% del campione, ha un _matching_ pieno. Sono i casi di “Comune di Palermo” e “Palermo”: rimosso "Comune di ", c’è _full match_ .
> 
> Ma poi ci sono numerosi casi per i quali c’è fare pulizia e normalizzazione, per colpa di uno spazio, di un apice. Sotto alcuni esempi (la colonna `check` è la distanza vettoriale tra le stringhe misurata con [fuzzywuzzy](https://github.com/seatgeek/fuzzywuzzy)).
> 
> | cod\_amm | des\_amm | ComuneCFR | Comune | check |
> | --- | --- | --- | --- | --- |
> | c\_g165 | Comune di Ospedaletto D’ Alpinolo | Ospedaletto D’ Alpinolo | Ospedaletto d’Alpinolo | 98 |
> | c\_h798 | Comune di San Cipriano D’ Aversa | San Cipriano D’ Aversa | San Cipriano d’Aversa | 98 |
> | c\_i213 | Comune di Sant’ Alessio con Vialone | Sant’ Alessio con Vialone | Sant’Alessio con Vialone | 98 |
> | c\_i316 | Comune di Santa Vittoria d’ Alba | Santa Vittoria d’ Alba | Santa Vittoria d’Alba | 98 |
> | c\_i318 | Comune di Sant’ Egidio alla Vibrata | Sant’ Egidio alla Vibrata | Sant’Egidio alla Vibrata | 98 |
> | c\_i336 | Comune di Sant’ Eusanio Forconese | Sant’ Eusanio Forconese | Sant’Eusanio Forconese | 98 |
> | c\_i363 | Comune di Santostefano di Magra | Santostefano di Magra | Santo Stefano di Magra | 98 |
> | c\_a266 | Comune di Cortina D’ Ampezzo | Cortina D’ Ampezzo | Cortina d’Ampezzo | 97 |
> | c\_a434 | Comune di Arqua Petrarca | Arqua Petrarca | Arqua’ Petrarca | 97 |
> | c\_a709 | Comune di Bastia Mondovi | Bastia Mondovi | Bastia Mondovi’ | 97 |
> | c\_b996 | Comune di Cassago Brianza | Cassago Brianza | Cassago Brianza | 97 |
> | … | … | … | … | … |
> 
> Ma partire dalle stringhe è comunque problematico, perché ci sono anche nomi di Comuni in più lingue, nella stessa cella.
> 
> Allora provo a partire dal campo `cod_amm` , che contiene il codice “Belfiore”, il codice catastale comunale. Si parte dal filtrare tutti i record che contengono a inizio cella `c_` , dal rimuovere `c_` e dal portarlo in maiuscolo (ad esempio per Palermo da `c_g273` a `G273` ).
> 
> Così facendo si ha una colonna con cui fare il _matching_ e verifica con una fonte certificata di questi codici come i dati ANPR sui comuni.  
> I record di IPA che iniziano per `c_` sono 7778, di questi per circa il 2% non c’è il _matching_ , quindi 150 Comuni potrebbero avere dentro IPA il codice catastale errato. Alcuni esempi ([qui](https://gist.github.com/aborruso/94bb4cb4a5367df0a19635487b47f6c8) tutti quelli per cui non è stato possibile fare matching diretto tra IPA e ANPR, rispetto ai Comuni oggi attivi):
> 
> - Alcara Li Fusi, in IPA è ZBOH, in ANPR è A177;
> - Alà dei Sardi, in IPA è WFS6, in ANPR è A115;
> - Breia, , in IPA è B136, in ANPR è B136, ma è un comune che con questo nome non esiste dal 31/12/2017.
> 
> @giorgialodi ci ha [descritto](https://forum.italia.it/t/sempre-sui-dati-ipa/1476/9) alcune delle cause di questa mancanza di _matching_ . Quindi anche da questo percorso non si riesce ad estrarre in modo diretto, completo e senza rischi di errori, il dato.

Comprendiamo le varie difficoltà perché le abbiamo incontrate anche noi 🙂 e ti ringraziamo di questi dettagli che ci aiutano.

Sempre nell’ambito di lavori nel contesto DAF, abbiamo provato a produrre i linked open data dell’IPA collegandoli al dataset linked menzionato sopra dell’archivio storico dei comuni. L’obiettivo era di creare un primo “zoccolo” di dati di PA, nativamente integrati e di ampio riutilizzo. Anche qui, come nel caso precedente, il dataset LOD dell’IPA necessita di ulteriori lavorazioni che stiamo affrontando: ci siamo scontrati proprio con i problemi che anche tu rilevi sulla qualità.  
Sempre come il caso precedente vogliamo mettere a disposizione script di conversione ed esempi di query SPARQL che possano facilitare le interrogazioni, speranzosamente superando i problemi attuali con i web services. In merito c’è anche il lavoro preliminare di Roberto Polli con Open API (che segue anche le ontologie di OntoPiA) che può essere d’aiuto per superare i problemi sui web services.

In merito a questa discussione, c’è però da tenere sempre in considerazione che AgID è responsabile della base di dati di IPA ma la titolarità del dato è di ciascuna Amministrazione che inserisce materialmente i dati. Purtroppo alcuni problemi di qualità del dato derivano proprio da inserimenti non sempre accurati. Puoi quindi comprendere che intervenire sul dato rispetto a quello inserito all’origine è operazione estremamente delicata per tutti.  
Stiamo in parte affrontando il problema della qualità (e.g., accenti, date) con alcuni strumenti del DAF; ci vorrà ancora un po’ di tempo.

> [@aborruso](#):
>
> # Per chiudere
> 
> Sono stato lungo, ma secondo me valeva la pena fare un approfondimento su un caso di dato che dovrebbe essere _milestone_ , inserendo anche delle note di dettaglio (che mi auguro possano in ogni caso essere utili).
> 
> L’idea è quella di una sorta di “super paniere nazionale”, certificato, aggiornato, metadatato, controllato, standard e linked (o predisposto per). Con il goal massimo di avere dei servizi pubblici nazionali per esporli.
> 
> Molti di questi dati miliari sono già _online_ e di qualità; la mia richiesta è quella di trovar il modo di avere almeno anche un super indice curato, un unico punto d’accesso descritto per persone e macchine. Il massimo sarebbe una sorta di wikidata statale.
> 
> L’esposizione di dati di questo tipo e in queste modalità potrebbe essere anche l’occasione di un check sulle licenze, così come [proposto qui](https://forum.italia.it/t/le-licenze-degli-opendata-della-pa-e-quelle-di-wikidata-openstreetmap-e-wikipedia/4975) settimane fa.
> 
> E buone feste

Per concludere, dei lavori lungo questa linea, come vedi, sono già stati affrontati e altri (es: super-indice) sono parte dei programmi complessivi di sviluppo del DAF. Siamo però anche estremamente consapevoli che bisogna fare un ulteriore passo per offrire un servizio di qualità a tutti. Su questo ci stiamo lavorando e ci piacerebbe uno scambio anche più forte con le comunità, come sta pian piano avvenendo con la rete di ontologie e vocabolario controllati OntoPiA.

Appena abbiamo concluso i collaudi e le revisioni del caso sui dataset sopra menzionati ve ne daremo notizia in questo forum.

Grazie come sempre per gli spunti interessanti  
Il Team del DAF  
(Simone, Alessandro, Giovanni, Maria Claudia, Alberto e Giorgia)

---

<div class="post-metadata">

**Author:** ![giorgialodi](https://forum.italia.it/user_avatar/forum.italia.it/giorgialodi/32/398_2.png) [@giorgialodi](https://forum.italia.it/u/giorgialodi)\
**Post date:** [26 Gennaio 2019, 10:49am UTC](https://forum.italia.it/t/feature-request-dataset-miliari-certificati-aggiornati-linkati-e-accessibili-via-api-lo-spunto-da-ipa-e-anpr/6644/7 "2019-01-26T10:49:42Z")

</div>

Ciao Matteo,

> [@dagoneye](#):
>
> Ciao Andrea,  
> vedo tre richieste precise nel tuo bel post: grazie per averlo condiviso, specie nei giorni di festa ( _al pomeriggio della vigilia di Natale_ 🙂 ).
> 
> ## API dei dati miliari (e potenziali servizi correlati)
> 
> Se l’ambito che hai evidenziato fosse gestito al meglio con quel superindice di cui parli, il risparmio e la facilità del riuso aiuterebbe enormemente tutto l’ecosistema, non solo il bacino di riutilizzatori privati, ma soprattutto l’interoperabilità interna alla PA stessa. Se a livello di strategia nel Piano Triennale tutto torna, i tempi di realizzazione non tornano proprio. Mi sono guardato un po’ in giro e cito il punto cardine:
> 
> - [https://teamdigitale.governo.it/it/projects/api.htm](https://teamdigitale.governo.it/it/projects/api.htm) - il catalogo delle API è il progetto in cui si potrebbe inserire quest’idea di superindice. Rispetto agli elenchi delle basi dati chiave, il dato comunale è un livello più infrastrutturale, ma non vedo come si potrebbe evitare di lavorare su quel livello senza raggiungere la qualità di cui parli per abilitare poi il resto dei servizi. Si tratta di un lavoro da fare di certo. Me lo immagino implicito nel percorso che era ipotizzato qui: [https://docs.italia.it/italia/piano-triennale-ict/pianotriennale-ict-doc/it/stabile/doc/12\_indicazioni-per-la-pa.html#indicazioni-sui-dati-della-pubblica-amministrazione-e-sul-daf](https://docs.italia.it/italia/piano-triennale-ict/pianotriennale-ict-doc/it/stabile/doc/12_indicazioni-per-la-pa.html#indicazioni-sui-dati-della-pubblica-amministrazione-e-sul-daf).
> 
> Forse non si pensava di rendere un livello simile ben visibile, ma direi che è il caso di farlo. Non vedo modi di poterlo fare ufficiosamente come società civile e/o settore privato: è necessario il ruolo della fonte pubblica, nel suo essere fonte primaria e certificata. Un paio di proposte:
> 
> 1. quest’idea del superindice mi piacerebbe diventasse un prototipo ‘ _agile_ ’, un suggerimento per aiutare a darsi delle priorità a chi sta sviluppando il progetto API. Potrebbe stimolare il resto del lavoro già previsto dalla strategia originale e fungere da leva o acceleratore. Almeno si è certi che c’è domanda su questo specifico ambito;
> 2. si potrebbe organizzare una challenge di open innovation tra chi quei dati li strausa all’interno della PA (penso a SOGEI, per dirne uno).
> 
> Più in generale, **vorrei capire se e quale mano potrebbe dare la società civile a spingere su una proposta simile da chi conosce gli ostacoli che ha trovato lungo il percorso**. La spiegazione di @giorgialodi sui problemi di match dei dati IPA che citavi è datata 18 dicembre 2017. Cosa è successo nel confronto interno nel frattempo? Cosa si è imparato? Sarebbe fondamentale saperlo.

La spiegazione complessiva sul match è ancora valida 🙂 e riportata anche nella risposta ad Andrea. Così com’è ancora valido il fatto che la titolarità dei dati è delle PA ed è sempre estremamente delicato intervenire. Nel caso di elementi di errore che erano stati evidenziati in quel thread i colleghi si sono attivati.

> [@dagoneye](#):
>
> ## Maggior evidenza a questi dati miliari
> 
> L’idea dei tag è implementabile fin da subito da dati.gov.it, creando un filtro a parte nella navigazione a faccette. **Mi piacerebbe un feedback ufficiale su questo da parte di chi ci lavora. A chi possiamo segnalarlo che ha il potere decisionale di accettare un’idea di questo tipo? Usiamo le issue su github del repo ufficiale?**. A tendere, sarebbe utile una sorta di onboarding per l’utente avanzato che ha bisogno comunque di utilizzare questi dati (che non è detto sia un programmatore), ovviamente in dati.gov.it. Penso sia un pezzetto di un progetto di comunicazione quasi parallelo, che utilizzi direttamente i metadati estratti dalle API dei dati miliari come fonte primaria per migliorare l’esperienza utente di dati.gov.it. Una co-progettazione con la comunità/società civile interessata?

Per le segnalazioni a [dati.gov.it](http://dati.gov.it/) potete usare due canali:

1. [repo GitHub](https://github.com/italia/dati.gov.it) che è stato aperto anche per questo scopo, soprattutto se le segnalazioni sono relative a sviluppo software e quindi più tecniche

2. il canale di comunicazione che [dati.gov.it](http://dati.gov.it/) mette a disposizione “[Scrivi alla redazione](https://www.dati.gov.it/content/scrivi-redazione)”

> [@dagoneye](#):
>
> ## Evoluzione del paniere dinamico per renderlo più comprensibile e creare coerenza comunicativa di insieme
> 
> Questo punto forse l’ho visto un po’ implicito, ma di sicuro serve ripensare il modo di comunicare il paniere dinamico dei dati. La struttura con cui esporre i dati miliari potrebbe essere usata anche per i dati oggetto di previsione/richiesta diretta di pubblicazione. Avevo già dato suggerimenti sul paniere collegandomi alle iniziative statunitensi correlate [https://groups.google.com/a/teamdigitale.governo.it/d/msg/data/ZwcuDWCi2uw/2LcbLgL-AgAJ](https://groups.google.com/a/teamdigitale.governo.it/d/msg/data/ZwcuDWCi2uw/2LcbLgL-AgAJ) - ma non mi è mai stato chiaro cosa sia stato recepito e cosa no. A questo punto, mi sorge una domanda più ampia: suggerire miglioramenti simili da esterni serve? Si tratta di un’aspettativa di partecipazione errata oppure troppo alta? In ogni caso, il feedback sulle proposte e sui singoli punti è necessario darlo, perché non capiamo se stiamo condividendo astrazioni fuori dal mondo del possibile (fattibile) oppure se qualcosa si riesce a salvare 🙂
> 
> Buon anno di cuore a tutti,  
> Matteo

Ti ringraziamo per questo feedback sul metodo di comunicazione del paniere: ci aiuta a migliorare. Su questo, importanti novità potrebbero arrivare dalla revisione della direttiva PSI. Sarà quindi importante e naturale rivedere tutto complessivamente, cercando di razionalizzare le varie liste (paniere nazionale, regionale, dataset chiave)

Ciao,  
Il team del DAF ,  
(Simone, Alessandro, Giovanni, Maria Claudia, Alberto e Giorgia)

---

<div class="post-metadata">

**Author:** ![Alessio\_Cimarelli](https://forum.italia.it/user_avatar/forum.italia.it/alessio_cimarelli/32/14976_2.png) [@Alessio\_Cimarelli](https://forum.italia.it/u/Alessio_Cimarelli)\
**Post date:** [21 Novembre 2019, 8:31am UTC](https://forum.italia.it/t/feature-request-dataset-miliari-certificati-aggiornati-linkati-e-accessibili-via-api-lo-spunto-da-ipa-e-anpr/6644/8 "2019-11-21T08:31:13Z")

</div>

Un aggiornamento, benché non risolutivo, per quanto riguarda i confini amministrativi ISTAT: [[Call for ideas] Confini amministrativi ISTAT](https://forum.italia.it/t/call-for-ideas-confini-amministrativi-istat/12224)