Ciao,
faccio un’altra segnalazione sulla risorsa Amministrazioni pubblicato nell’indice delle Pubbliche Amministrazioni. È una di quelle “importanti”, quindi ci metto spesso le mani dentro.
Ci sono dei comuni che hanno la descrizione, che non corrisponde a quello che si legge nel campo Comune.
Sotto i casi che mi sono saltati all’occhio. Un esempio per tutti: il record in cui il campo des_amm è uguale a Comune di Caines, ha nel campo Comune la stringa Rifiano e non Caines.
Se è un errore, sarebbe da correggere presto.
Grazie
cod_amm
tipologia_istat
des_amm
Comune
c_b364
Comuni e loro Consorzi e Associazioni
Comune di Caines
Rifiano
c_d086
Comuni e loro Consorzi e Associazioni
Comune di Cosenza
Cosenza
c_f011
Comuni e loro Consorzi e Associazioni
Comune di Masera’ di Padova
Padova
c_g224
Comuni e loro Consorzi e Associazioni
Comune di Padova
Padova
c_h284
Comuni e loro Consorzi e Associazioni
Comune di Rifiano
Rifiano
c_d0869
Comuni e loro Consorzi e Associazioni
Comune di Serra D’Aiello
Cosenza
P.S. @giorgialodi se non devo farle qui queste segnalazioni, mi puoi indicare un indirizzo pubblico a cui rivolgermi? Grazie
Un’osservazione aggiuntiva: per i comuni il cod_amm dovrebbe essere c_ seguito dal codice catastale del Comune.
Peccato che il codice catastale debba essere una lettera seguita da 3 numeri e non da quattro e che il codice catastale d869 sia quello del Comune di Gallarate…
Ciao Andrea, ciao Marco,
intanto grazie per queste operazioni di controllo che aiutano tutti a migliorare una banca dati definita come una banca dati equiparabile a una di interesse nazionale.
Da questa analisi dobbiamo tuttavia fare delle precisazioni: da un lato semantiche e dall’altro lato di processo di gestione del dato.
Precisazioni semantiche. Il campo “comune” presente nel data set “amministrazioni” indica il comune presso il quale è collocata la sede primaria dell’ente. Bisogna qui prestare attenzione al concetto di comune inteso come entità amministrativa (organizzazione) dal concetto comune (città) inteso come entità territoriale. Non a caso facciamo ontologie per le organizzazioni da un lato e per i luoghi/indirizzi (e componenti dell’indirizzo) dall’altro, che ti invito a visionare nel repository daf-ontologie-vocabolari-controllati
Precisazione relativa al processo. Queste informazioni, come tutte le altre, sono dichiarazioni fatte in fase di accreditamento dal responsabile dell’ente che in caso di variazioni deve comunque garantire, per legge, il corretto aggiornamento. E’ bene specificare che la titolarità delle informazioni presenti in IPA è inequivocabilmente del singolo ente, pertanto AgID può solo segnalare le incongruenze sollecitando gli aggiornamenti necessari. Quindi va bene segnalarlo ad AgID ma nello stesso modo bisognerebbe segnalare le incongruenze anche ai titolari del dato stesso.
Vediamo punto per punto:
la sede dichiarata è : Via Passo Giovo, 48 - 39010 Rifiano (BZ) - informazione confermata nel sito del comune http://www.comune.caines.bz.it/
la sede dichiarata è : Via Passo Giovo, 48 - 39010 Rifiano (BZ) - informazione confermata nel sito del comunehttp://www.comune.rifiano.bz.it/
la sede dichiarata è: Piazza Dei Bruzi - 87100 Cosenza (CS)
la sede dichiarata è: Piazza Municipio, 41 - 35100 Padova (PD)
la sede dichiarata è: Via Municipio 6 - 35122 Padova (PD)
la sede dichiarata è: Via Papa Giovanni XXIII - 87100 Cosenza (CS)
e 2) il comune di Caines e quello di Rifiano dichiarano lo stesso indirizzo in località Rifiano;
le informazioni sono congruenti
la località corretta della sede del comune è Masera’ di Padova; questo è un verosimile refuso
le informazioni sono congruenti;
la località corretta della sede del comune è Serra D’aiello (CS); questo è un verosimile refuso.
Per quanto riguarda quanto segnalato sul codice, la costruzione del codice IPA è in effetti fortemente raccomandata come descritta da @emmedi.
Tuttavia esistono situazioni passate per cui si sono verificate eccezioni.
Per il caso specifico, è l’amministrazione che ha dichiarato come Comune “Cosenza”; pertanto per non alterare la dichiarazione originale dell’amministrazione, l’unica titolare del dato, il codice attribuito ha seguito questo processo: c_codicebelfiorediCosenza (ovvero c_d086). Siccome esiste già nella banca dati, è stato aggiunto un progressivo finale facendo diventare il codice dopo “c_" di 4 numeri + la lettera. Cambiare il codice IPA, utilizzato in diverse altre banche dati, è operazione estremamente delicata.
Attenzione comunque che il codice belfiore di Gallarate è d869 che non è d0869 assegnato in questo caso.
In ogni caso, per i casi 4 e 6, AgID prende in carico le segnalazioni.
Ciao,
Giorgia (collaboratrice AgID)
Quella del campo comune è un mio errore, non avevo letto il file con in metadati.
Quindi l’unico modo per mettere in relazione questa risorsa di grande interesse (ci sono già diverse importanti applicazioni basate anche sull’iPA), con una delle decine di risorse in cui è presente un nome di comune (penso ai tanti dati ISTAT), è rimuovere la stringa Comune di dal campo des_amm e fare il JOIN con il campo nome comune suddetto (avendo cura di risolvere prima il problema degli accentati traslitterati, delle maiuscole, ecc.)?
Se sì, rinnovo l’invito a inserire in iPA anche un codice come il PRO_COM di ISTAT o di pubblicare un tabella chiave che metta in relazione i codici cod_amm con i codici ISTAT.
A me pare che si dovrebbe rendere più stringente la regola di composizione del codice IPA (almeno quello dei Comuni). La corrispondenza tra codice Belfiore e codice ISTAT è, con tutte le problematiche del caso, risolta.
Da un sommario controllo eseguito sugli opendata pubblicati su IPA e sul sito dell’Agenzia delle Entrate risulta che:
in IPA ci sono 169 Comuni con codiceIPA malformato (Codice Belfiore non presente del DB dell’Agenzia)
nel DB dell’Agenzia ci sono 177 Comuni che non si trovano in IPA
La differenza non è quindi dovuta ai soli errori di codifica.
@giorgialodi: mi pare che i danni causati da una cattiva codifica superino di gran lunga la delicatezza di introdurre (o chiedere di introdurre) le opportune correzioni in IPA.
Sono stato sollecitato a rileggermi e obiettivamente faccio confusione
Perché in iPA ci sono entità amministrative, mentre i codici ISTAT riguardano entità territoriali (faccio riferimento a questi dati). Quindi in iPA non ha senso inserire il codice ISTAT ad esempio dei comuni.
Però per diversi progetti di cui mi occupo è molto spesso per me necessario associare a entitià territoriali comunali, il codice iPA (e vari dati correlati).
Allo stato attuale faccio ad esempio così:
filtro da iPA soltanto i record dei comuni (quelli il cui codice inizia per c_);
rimuovo da iPA nella colonna des_amm la stringa Comune di;
faccio il JOIN tra la colonna COMUNE Istat (quella che si trova nelle basi territoriali) e la colonna des_amm .
Ma in iPA gli accenti sono traslitterati - à diventa a' - e Cefalù quindi non si “sposa” con Cefalu'.
Quindi devo prima gestire questa cosa. Non è complesso, ma è da fare con attenzione.
Il carattere ' non è soltanto usato per gli accenti: ci sono nome di comune come Cappella de' Picenardi, dove il carattere ' è bene che stia lì.
Inoltre proprio in iPA, il nome di questo comune è scritto Cappella De' Picenardi (in modo scorretto, perché il de' dovrebbe essere minuscolo) e non Cappella de' Picenardi. Quindi anche qui il JOIN ISTAT > iPA “salterebbe”. Salvo (cosa semplice anche questa) fare un JOIN che non tenga conto del case.
Se in iPA esistesse una colonna con la label corretta dell’entità a cui fa riferimento - quindi nel caso di c_b680 sarebbe Cappella de' Picenardi - o se esistesse anche per le sole entità amministrative comunali una tabella “certificata” di correlazione tra entità territoriali e entità amministrative, o se esistesse un motore linked (alla wikidata) che consentisse di arrivare via “ponti” da una definizione amministrativa a una territoriale (e viceversa), sarebbe una gran cosa.
A me pare che questa umile attività di corretta codifica e di riordino delle nomenclature delle PA possa entrare a pieno titolo tra le attività di plumbing di cui parla sovente Diego Piacentini. Perché ottiene così poco interesse?
grazie per quanto ci stai scrivendo che ci fa capire il riutilizzo possibile di questa tipologia di dati. Parto dalla chiusura del tuo messaggio dove dici "o se esistesse un motore linked (alla wikidata) che consentisse di arrivare via “ponti” da una definizione amministrativa a una territoriale (e viceversa), sarebbe una gran cosa”. Nell’ambito di alcune attività del DAF legate alla semantica stiamo proprio lavorando sui dati dell’archivio storico dei comuni e sulla classificazione territoriale dell’ISTAT e sui dati aperti dell’IPA per trasformarli in Linked Open Data pubblicandoli poi in uno sparql endpoint (le ontologie per entrambe le tipologie di dati ci sono e possono essere utilizzate per la materializzazione dei linked open data). Riferirò nel gruppo di questa richiesta che immagino per il tuo lavoro sia molto utile e che va nella direzione sulla quale stiamo operando. Nell’ambito del DAF ci sono lavori volti a garantire anche un minimo di pulizia del dato; pertanto è molto utile ciò che hai scritto e lo terremo in considerazione. Chiederò comunque ai colleghi AgID che si occupano direttamente del dato di IPA di verificare questa cosa degli accenti e delle maiuscole, minuscole, almeno nel caso di esportazione in open data di livello 3. Sugli accenti come inclusi nella banca dati, come ricorderai, avevo indicato la motivazione della scelta. Vediamo se e come possiamo agire anche in questo caso.
quando scrivi: “in IPA ci sono 169 Comuni con codiceIPA malformato (Codice Belfiore non presente del DB dell’Agenzia)” non ci è ben chiaro perché è malformato. Come precedentemente ricordato esiste una procedura definita e adottata di assegnazione del codiceIPA (ID univoco all’interno della base dati IPA che rispecchia le informazioni fornite dalle PA stesse uniche titolari del dato). Non è malformato, è la procedura che prevede di assegnarlo in quel modo. Si può discutere se quel modo è opportuno o meno ma è una convenzione che si applica in maniera uniforme a tutta la banca dati. Quell’indice è poi usato, come detto, in diverse altre basi di dati per identificare univocamente l’amministrazione, intesa come entità amministrativa.
Le due banche dati potrebbero non essere allineate anche in base a diversi fattori di popolamento del dato, popolamento che deriva, come ricordato, dalle amministrazioni stesse e dai loro tempi di inserimento del dato.
In ogni caso, come risposto anche ad Andrea Borruso, cercheremo di migliorare la qualità del dato presente nella banca dati, anche sollecitando le Amministrazioni stesse ove si ravvedano problemi (e.g., i casi di maiuscolo e minuscolo) in modo da facilitare il riutilizzo anche in funzione della correlazione con altri tipi di dati. Anche il DAF, dove stanno confluendo questi dati, potrebbe aiutare in termini di qualità del dato
Ciao Giorgia,
Possiamo definirlo malformato o scarsamente interpretabile. Resta il fatto che essere costretti alle capriole descritte da @aborruso per correlare i Comuni presenti in IPA con l’elenco dei Comuni italiani mi sembra davvero poco funzionale.
Anche l’impossibilità di inserire caratteri Unicode nella banca dati mi pare davvero antistorica.
Ciao @giorgialodi ,
grazie per il riscontro. Mi piacerebbe molto vedere realizzato quello che descrivi.
Io insisto però anche nel provare a trovare una soluzione transitoria, che consenta a breve di rendere semplice la correlazione di banche dati importanti come queste. Perché oltre a essere importanti, sono molto usate.
Non vedo alternative al momento a quella di creare una tabella che faccia da stele di rosetta, almeno quella per le entità geografiche comunali. Non è elegante, ma dato che penso non si possa intervinere alla radice (parlo sia iPA, che di ISTAT), non vedo grandi alternative.
Credo che questo possa essere un lavoro a carico di di chi come AgID e Team fa da ponte.
La mia richiesta è quella di dedicare delle risorse a quei 10-15 dataset hot, sui quali vale la pena di trovare una soluzione transitoria di emergenza. Perché avviene troppo spesso, che progetti enormi come openCUP, pubblichino dati senza dichiarare encoding e separatori e senza API.
Quindi in attesa di qualcosa di importante come il DAF, secondo me c’è da centralizzare un po’ anche del lavoro “bruto”.
