Nuova sezione: analisi dei siti della PA

Nuova sezione del menu di Siamo geek con l’analisi statistica dei siti della Pubblica Amministrazione italiana.

Il progetto è nato come estensione dell’analisi della presenza in IPv6 della PA a cui sono state aggiunte alcune funzioni.

Inutile dire che il lavoro maggiore è stato (ed è tutt’ora) quello di gestire un database aggiornato dei siti delle PA, con particolare riferimento ai Comuni.

Negli anni ’90 era in vigore una consuetudine (non so se regolamentata al livello legislativo o di direttive) che il sito di un comune non capoluogo fosse www.comune.{nome_comune}.{provincia}.it mentre quello di un comune capoluogo fosse www.comune.{nome_comune}.it

Già qui sono iniziati i distinguo: alcuni hanno indicato la provincia con la sigla, altri per intero; alcuni Comuni capoluogo hanno usato la sigla, altri il nome intero. Come se non bastasse, già allora qualche comune si è registrato un dominio .it, .com, .net, .org e chi più ne ha più ne metta.

Il Ministero per la Pubblica Amministrazione e Innovazione con la direttiva n. 8/2009 del 26 novembre 2009 impone alle PA una riorganizzazione dei loro siti web istituzionali facendole passare sotto il terzo livello .gov.it e pubblica delle linee guida per nulla precise. Viene scritto infatti che  i nomi di dominio di 3° livello da utilizzare nell’ambito del dominio .gov.it dovranno essere il più possibile autoesplicativi e brevi; a tal fine è opportuno non inserire nel nome il suffisso “ministero, ente, dipartimento. Avevamo una regola, seppur imprecisa e adesso non abbiamo più nemmeno quella. Risultati: {nome_comune}.gov.it, comune{nome_comune}.gov.it, comune.{nome_comune}.gov.it, {nome_comune}.{sigla_provincia}.gov.it, comune.{nome_comune}.{sigla_provincia}.gov.it, {sigla_provincia}.gov.it, eccetera. Evidentemente scrivere una regola da seguire sarebbero stati uno sforzo intellettuale e un’assunzione di responsabilità eccessivi per il Ministero.

Ovviamente non tutti i Comuni si sono uniformati alla direttiva, anzi sono per ora un’esigua minoranza. Con il risultato che non si capisce più un razzo.

I vari balletti di cambi, creazione e aggregazione di provincie ci hanno messo il loro contributo, con URL che dall’oggi al domani cambiavano senza che su quello vecchio venisse mantenuto un redirect.

Su questo punto c’è una nota dolente: ben poche Amministrazioni hanno una consapevolezza delle regole presenza sul web. Non sto parlando di SEO o altra roba da presunti stregoni del web, ma di semplici regole, una delle quali è non cambiare nome a dominio ogni volta che rifai il sito o cambi fornitore. Se per un’azienda sembra una regola ovvia, per la PA non è così intuitivo. È infatti normale vedere che gli URL publicati (ad esempio) sul sito dell’ANCI non solo sono obsoleti ma restituiscono o un HTTP 404 oppure un errore di dominio inesistente (quando non puntano a pagine di pubblicità perché qualcun altro si è preso il nome a dominio).

Con l’aiuto della Wikipedia italiana, integrando la tabella ISTAT usando come chiave univoca il codice del Comune e con alcune procedure di analisi autocostruite ho messo assieme un database abbastanza aggiornato, che è tutt’ora in manutenzione ed è scaricabile in formato CSV. Per ricambiare del servizio reso, ho aggiornato tutte le pagine della Wikipedia che contenevano dati obsoleti o incompleti.

Alla fine resta lo stupore nel constatare che dopo oltre 15 anni di presenza mainstream di Internet in Italia non ci sia una regola univoca e deterministica per raggiungere, se presente, il sito di un Comune.

Autore: Luigi Rosa

Consulente IT, sviluppatore, SysAdmin, cazzaro, e, ovviamente, geek.

21 pensieri riguardo “Nuova sezione: analisi dei siti della PA”

  1. Non c’è una regola univoca ma c’è un indice ufficiale: http://www.indicepa.gov.it

    L’iPA, nelle intenzioni del legislatore, è l’indice unico di tutte gli enti/aziende della pubblica amministrazione e _deve_ contenere tutti i riferimenti ufficiali delle stesse (siti, indirizzi PEC, numeri di fax, riferimenti dei responsabili delle AOO, etc). Hanno _persino_ un ldap pubblico con tutto l’indirizzario.

    Diciamo che se lo pubblicizzassero meglio forse gli enti PA si sentirebbero più motivati a tenerlo aggiornato. Per adesso è solo un sito da “addetti ai lavori”.

    LLaP, Andrea

    1. Appena ho tempo vedo se e’ scaricabile l’elenco dei Comuni dal loro sito, grazie. Ovviamente hanno il LORO codice univoco (che mi sembra una derivazione del codice Belfiore/Catasto).
      Ovviamente/2 non usano le lettere accentate (UTF8? Unicode? cosa sono?!) ma gli apostrofi ASCII.
      Zeus strafulmini tutti gli Enti che si inventano un loro codice univoco.

      Se solo ci fermassimo a pensare quanto costa in termini monetari vivi e di inefficienza l’assenza di una strategia univoca nell’informatizzazione della PA… Sono gli stessi problemi che affronto nelle aziende, ma almeno li’ qualcuno li vuole risolvere.

      1. A norma del decreto , il loro (di iPA) codice è quello definitivo scolpito nella pietra, etc etc. Hanno addirittura la gestione dello storico dei codici, per consentire di scoprire quali enti si sono fusi, gemmati, spezzati o fagocitati tra loro.

        L’unico problema è che ho visto troppi tentativi di inventarsi un codice univoco definitivo per credere che questa sia la volta buona ma … la speranza è l’ultima a morire 😉

        1. Anche l’ISTAT ha la stessa auctoritas e la stessa storia di codici (e’ una cosa normale nella codifica informatica) ed esiste prima di iPA.

          E se andiamo a vedere ci saranno altri enti altrettanto titolati ad avere una codifica.

          Finche’ citiamo leggi e decreti non ne usciamo vivi (e infatti non ne stiamo uscendo).

    2. Ho fato una po’ di test con qualche confronto. Il database scaricabile da http://spcdata.digitpa.gov.it/dataIPA.html nel campo del sito istituzionale contiene un sacco di fuffa (esempio: per il Comune di Acquarica del Capo il sito istituzionale e’ ‘password5’, verificabile anche nell’interfaccia web http://www.indicepa.gov.it/ricerca/dettaglioamministrazione.php?cod_amm=c_a042) e dati non validati (ci sono spazi, virgole al posto di punti, email e altro), senza contare che per la maggior parte sono hostname e ogni tanto c’e’ un URL.

  2. Il codice Istat pero` non e` granche`… un comune cambia codice quando si sposta da una provincia all’altra.

    Il codice catastale alla fin fine mi sembra meno peggio.

    1. La tabella ISTAT dei Comuni scaricabile in formato XLS e CSV ha sia i vari codici ISTAT sia il codice Belfiore di raccordo. iPA CREDO che per i comuni abbia semplicemente prepsoto “c_” passando in lowercase il codice Belfiore. Pavia per iPA e’ c_g388, mentre per il codice catastale/Belfiore e’ G388.

      Cerco della documentazione sul sito iPA per vedere se ci sono delle tabelle di raccordo o qualcosa di scaricabile in formato tabellare che non sia un sito web o in LDAP (bleah!)

      Lo spostamento dei comuni tra Province e’ frutto del delirio della politica degli utlimi anni, quando ISTAT si e’ inventata la codifica non poteva pensare che facessero e disfacessero provincie per il gusto di farlo e per il gusto di buttar via quattrini, ma sto divagando.

      1. Il codice iPA dei Comuni sembra essere effettivamente CONCAT(‘c_’,LOWER(belfiore)). Ho aggiunto il Belfiore alla mia tabella, ho calcolato il codice iPA e adesso dovrei riuscire a fare una JOIN sul codice iPA con i dati scaricati da http://spcdata.digitpa.gov.it/dataIPA.html per fare un po’ di confronti.
        Anche se i dati iPA sul sito istituzionale non sono normalizzati perche’ in gran parte contengono un hostname e ogni tanto un URL, vabbe’.
        In ogni modo anche i dati iPA non sono aggiornatissimi. Primo esempio: Abbadia Lariana, iPA riporta http://www.abbadialariana.com/ mentre il sito e’ http://www.comune.abbadia-lariana.lc.it/
        Conclusione: vanno comunque scremati

        Grazie ancora ad Andrea per la segnalazione dell’iPA

      2. Quando l’ISTAT ha inventato la codifica sapeva comunque benissimo che sarebbero nate nuove province, infatti il codice provincia e` sempre stato previsto su tre cifre. Infatti sono nate nuove province sia negli anni ’70, sia negli anni ’90, sia negli anni ’00.

        Ovviamente, se l’ISTAT si aspettava la nascita di nuove province, mi riesce difficile immaginare che si aspettasse che noi invadessimo la Svizzera e costituissimo le nuove province con comuni non ancora censiti all’ISTAT. Ovviamente, anche loro si aspettavano che le nuove province sarebbero state composte da comuni tolti da quelle esistenti. Comuni che si sarebbero trovati a cambiare codice.

        Dunque non c’entra nulla il fatto che alcuni comuni abbiano cambiato provincia. Il fatto che un comune cambi codice ISTAT e` dovuto a cattiva progettazione del codice suddetto. O forse a buona progettazione del codice suddetto (nato per uso dell’ISTAT nelle sue statistiche, e per la comunicazione da parte di terzi di dati statistici all’ISTAT) ma a sua poca adattabilita` a contesti diversi.

        Un codice catastale (che secondo alcune fonti e` errato chiamare “Belfiore”) nasce invece con una prospettiva di vita plurisecolare, non mi stupisce che funzioni meglio.

        Vale sempre la regola d’oro: mai usare come chiave di una tabella un valore che non assegni tu; rimane il problema di raccordare la chiave interna con codifiche esterne che variano.

        1. Scusa, ma nessuna codifica gestisce bene il fatto che i Comuni cambiano territorio (nel senso che intere aree passano da uno all’altro), vengono sciolti o addrittura costituiti ex-novo. Il codice Istat serve a gestire quello che ruota intorno alle Anagrafi dei Comuni e in questo senso funziona molto meglio del codice cosiddetto “Belfiore” che cambia addirittura quando cambia il *solo* nome del Comune….

          1. Intanto, chiariamoci sui nomi. La codifica “Belfiore” in senso stretto e` l’antico codice catastale, non piu` usato dal secolo scorso. Ha vari problemi, credo, fra cui quello che dici tu. E` un codice del tipo “M1AD” (Albano Laziale)

            Il codice usato nei codici fiscali e` l’attuale codice catastale, e per Albano Laziale vale “A132”. Nota che quando Albano ha cambiato nome in Albano Laziale ha mantenuto lo stesso codice catastale.

            Qualunque codifica, anche la piu` scarsa, gestisce facilmente la costituzione ex novo di un comune; gli assegna un codice nuovo.

            Lo spostamento, poi, da una provincia all’altra non deve creare necessariamente problemi. Il codice catastale di Prato e` sempre stato G999, sia quand’era in provincia di Firenze, sia quando e` diventato capoluogo della provincia di Prato.

            1. Ah, ma il problema non e’ il nuovo Comune, quanto il fatto che i territori coinvilti esistevano anche prima e cambiano codice…. supponiamo si presenti in anagrafe una persona che ti dice (e ha anche sui documenti) sono nato a “Mirabello” in provincia di Pavia, Comune che non esiste da molti anni. Se i codici venissero riutilizzati avresti un grosso problema, invece cosi’ il codice resta valido anche se corrisponde a uun Comune soppresso e tu sei sicuro che non indicava Comuni diversi in momenti diversi. Per quanto riguarda Albano Laziale non saprei, ma mi ricordo di due casi in cui era cambiato: Ciano d’Enza . Canossa e Telese Telese Terme.

              Per una interessante lettura sulle variazioni territoriali:

              http://www3.istat.it/dati/catalogo/schedavolume.php?ID=401

          2. Ciano: codice C669
            Ciano d’Enza: codice C669
            Canossa: codice C669
            Come vedi e` rimasto lo stesso.

            Analogamente per Telese/Telese terme.

            Mirabello (in provincia di Pavia) era F237, ha cambiato nome in “Mirabello ed Uniti di Pavia” rimanendo F237, fino alla soppressione. Dov’e` il problema?

          3. Vero, sono andato a memoria e ho sbagliato esempio. Peccato pero’ che (cosa assai piu’ grave) i Comuni amministrativi non coincidano con quelli catastali: esiste una nutrita lista di eccezioni sul sito dell’Agenzia delle Entrate.

            http://goo.gl/5IEJFT

            Se questo non e’ un problema, non so proprio cosa dire…

          4. Piu` correttamente, ci sono degli immobili che si trovano nel territorio di un comune ma che il catasto classifica nel territorio di un altro comune. E` un problema, ma di altro genere.

            Comunque tutti i comuni italiani esistenti oppure esistiti dall’unita` d’Italia ad oggi hanno un codice catastale unico, mai variato nel tempo, e tutti i codici catastali corrispondono ad un comune amministrativo. E questo e` meglio di quanto non accada con altri codici (codice Istat, CAB, CAP, etc. etc.). Persino il codice ISO 3166-2 (che peraltro si ferma alle province e non arriva ai comuni, lo cito soltanto pour parler) non manterrebbe un codice univoco se una provincia cambiasse regione!

  3. La tua regola d’oro è una regola di tolla perché impedisce di raccordare tabelle di varie fonti. Una chiave univoca condivisa (es: codice fiscale i partita iva) è la pietra angolare per correlare i dati di varie fonti, se ognuno si crea la propria chiave univoca allora torniamo indietro di 30 anni quando ogni computer era un mondo a sé stante e la gente riscriveva ogni volta i dati senza correlare le tabelle.

    ISTAT ha fatto il meglio dei due mondi: ha creato una propria codifica e ha messo nella medesima tabella la chiave di raccordo per il codice chiamato colloquialmente ‘Belfiore’.

    1. Luigi, evidentemente non ti e` chiara la differenza fra la chiave di una tabella e le codifiche esterne che usi per comunicare con terzi.

      E` ovvio che per comunicare con terzi devi usare una codifica condivisa, ma trattarla come chiave e` da polli. Se tu credi che i codici fiscali siano univoci, ad esempio, avrei una bella fontana in zona centrale di Roma da venderti a prezzo straciatissimo.

      La procedura di interscambio dei dati dovra` tenere conto che prima o poi qualunque codifica esterna condivisa ma decisa da terzi ti dara` problemi, e gestire correttamente il fallimento che accadra` in quel caso.

      Nota che questo problema c’e` potenzialmente con qualunque codifica esterna perche’ prima o poi gli utilizzatori della codifica avranno esigenze diverse da quelle dell’ente gestore della codifica in questione. E` successo anche con l’ISO: la codifica ISO-3166 dei codici delle nazioni non e` pensata per applicazioni storicizzate, ed infatti dopo qualche anno loro volevano riutilizzare codici dismessi come ad esempio “CS” (Cecoslovacchia). Questo stava per creare un sacco di casini a vari utilizzatori, infatti hanno cambiato idea e sono tornati indietro.

      Passando invece al problema delle chiavi: nelle TUE tabelle e` sbagliatissimo usare come chiave un valore generato da altri, fosse anche un ufficio diverso dello stesso ente. Questo perche’ prima o poi le esigenze altrui divergeranno dalle tue, e ti troverai a piedi. L’ho visto accadere un botto di volte.

  4. Per me l’ID INTEGER UNSIGNED AUTOINCREMENT PRIMARY KEY c’e’ di default nelle tabelle, ma in questa discussione mi interessa meno di epsilon e non e’ l’oggetto della discussione, che e’ il codice di raccordo. Meglio: l’assenza del medesimo. Manco mi ero posto il problema di andare offtopic parlando di un intero autoincrementale quando si parla di raccordi tra tabelle da fonti diverse.

    Anche perche’ la tabella che uso non contiene solamente Comuni, ma sono affari miei.

    Il succo, tornando in topic, e’ che non esiste una chiave di raccordo univoca per codificare i Comuni, ma che ci vogliono tabelle di conversione.

      1. La tua regola d’oro e’ quella di usare una primary key unsigned int autoincremental?

        Scrivila un un PowerPoint assieme all’altra regola “non duplicare i dati dove non necessario” e sei un perfetto consulente di Andersen (nome usato di proposito, non fare il pignolo).

        1. L’ho scritta piu` sopra, ed e` chiarissima: “mai usare come chiave di una tabella un valore che non assegni tu”

          Le prime due volte non so cos’hai letto, ed hai criticato una regola diversa da quella che ho scritto io.

          Io non ti dico COME devi generare la tua chiave. Dipende dalla tua tecnologia. Puoi farti una bella sequence, puoi usare un campo autoincrementante, dipende tutto da cosa supporta il tuo sistema di database.

          E purtroppo e` una regola che non e` cosi` scontata. L’ho vista violare troppo spesso.

Spazio per un commento