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

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), 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:

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?

Penso a una lista alla github awesome (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:

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

[{
    "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 - 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 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).

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 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 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 settimane fa.

E buone feste

20 Mi Piace

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 … :slight_smile:
Buone feste anche a te.

6 Mi Piace

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

4 Mi Piace

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 :slight_smile: ).

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:

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 - 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 :slight_smile:

Buon anno di cuore a tutti,
Matteo

5 Mi Piace

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 , 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!

4 Mi Piace

Ciao Andrea
rispondiamo in linea pezzo per pezzo.

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.

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;

  2. dataset ISTAT elenco comuni—> presente nel DAF e disponibile per il download e per l’interrogazione via API attraverso il data portal

  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.

Condividiamo il tuo punto di vista :slight_smile:

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

Comprendiamo le varie difficoltà perché le abbiamo incontrate anche noi :slight_smile: 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.

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)

1 Mi Piace

Ciao Matteo,

La spiegazione complessiva sul match è ancora valida :slight_smile: 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.

Per le segnalazioni a dati.gov.it potete usare due canali:

  1. repo GitHub 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 mette a disposizione “Scrivi alla redazione

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)

2 Mi Piace

Un aggiornamento, benché non risolutivo, per quanto riguarda i confini amministrativi ISTAT: [Call for ideas] Confini amministrativi ISTAT

2 Mi Piace