OpenData Palermo: riunione del 18/06/2013 (opendatapalermo@googlegroups.com)

20 views
Skip to first unread message

davide taibi (Google Drive)

unread,
Jun 18, 2013, 11:36:49 AM6/18/13
to opendat...@googlegroups.com
I've shared an item with you.
Ho sintetizzato gli argomenti principali che abbiamo affrontato nella riunione di oggi. Se potete, integrate il documento con i vostri appunti!
Document OpenData Palermo: riunione del 18/06/2013
Google Drive: create, share, and keep all your stuff in one place. Logo for Google Drive

Giulio Di Chiara

unread,
Jun 19, 2013, 6:13:23 AM6/19/13
to opendat...@googlegroups.com
24 ore dopo riesco a realizzare meglio le vicende e volevo riprendere il discorso affrontato ieri in fase di riunione, perchè c'è una cosa poco chiara che non mi convince.

Ok, abbiamo definito l'obiettivo, ovvero la centralizzazione di tutto il servizio, con web service e upload indipendente su server centrale. Ma su questo, al momento non abbiamo alcuna garanzia di realizzazione e di tempi. 

L'anello mancante a mio avviso è "nel frattempo". Non so se ho avuto una sensazione distorta delle cose dette ieri, ma mi sembra ci sia un grado di superficialità ALTA su quello che andrà fatto all'interno degli uffici in tutto il periodo che intercorre tra adesso e l'eventuale servizio finale.

L'anagrafica delle banche dati ci restituirà un quadro più chiaro di cosa c'è e di cosa potrà essere pubblicato. Ma nel frattempo gli uffici cosa faranno? Continueranno a produrre word e scansioni nei loro hard disk? Tema non affrontato. 

Alla luce dei suggerimenti di Andrea, Davide e Francesco, qualche dato verrà ripreso, riaggiustato e riproposto in nuovo formato, e salvo qualche dataset sporadico (vedi quello del turismo) non vi sarà una procedura che garantirà uno standard minimo di quantità e qualità per la produzione dei dati da parte degli uffici comunali, che sono la vera fonte dei dati su cui lavorare e destinare il nostro sforzo in queste linee guida. Questo tema, per me fondamentale, è stato bypassato dal Dott.Meli che prospettava problemi di sindacati, mansioni e budget vari. Abbiamo traguardato oltre. 

L'esplosione delle banche dati di Sispi possono essere l'inizio di un percorso, ma va garantita la produzione dagli uffici, l'aggiornamento del dato. E per fare questo, non si può prescindere a mio avviso, dall'individuare figure e procedure semplici che in qualche modo costringano la macchina comunale a gettare le basi per una strutturazione interna, seppur minima.

Il rischio concreto che tra sei mesi rimanga tutto indefinito nell'attesa della centralizzazione dei servizi è alto, viste le esperienze precedenti a vari livelli. E sinceramente non vorrei aver speso parte del mio tempo per tornare allo status attuale, senza aver apportato un plus migliorativo.
Non mi sto tirando indietro nè sto facendo il disfattista. Provo a cogliere tutte le sfaccettature di questa vicenda, alla luce di mettere mano nuovamente alle linee guida.

Per me andrà comunque prevista una procedura interna, checchè ne dica il Dott. Meli.
Volevo capire le vostre sensazioni in merito. Le ho già condivise con Ciro poco fa, il quale manifestava i miei stessi dubbi. 

Attendo un rapido giro di pareri ;)
A presto.




andy

unread,
Jun 19, 2013, 6:57:36 AM6/19/13
to Giulio Di Chiara, opendat...@googlegroups.com
Ciao Giulio,

2013/6/19 Giulio Di Chiara <giuliod...@gmail.com>

L'anello mancante a mio avviso è "nel frattempo". Non so se ho avuto una sensazione distorta delle cose dette ieri, ma mi sembra ci sia un grado di superficialità ALTA su quello che andrà fatto all'interno degli uffici in tutto il periodo che intercorre tra adesso e l'eventuale servizio finale.

è un po' quello che volevo sottolineare io quando richiedevo di fare in modo che il sito possa avere una doppia faccia: pronto per erogare dati e servizi da un repository centralizzato, e continuare a dare la possibilità di fare - come adesso -il semplice download di file.
Per questa ragione, nel mio intervento, ho introdotto alcuni semplici elementi per fare passare il sito attuale almeno a tre stelle.

Nelle linee guida inserirei questo punto: passare entro fino settembre (è una data di esempio) a tre stelle. Con tutto ciò che ne consegue, anche con la rimozione di alcuni file.

Per questo punto, ancora una volta, ci vuole una figura che si occupi di verificare le stelle. 
 
L'anagrafica delle banche dati ci restituirà un quadro più chiaro di cosa c'è e di cosa potrà essere pubblicato. Ma nel frattempo gli uffici cosa faranno? Continueranno a produrre word e scansioni nei loro hard disk? Tema non affrontato.

Potremmo inserire nelle linee guida, alla luce del paletto delle tre stelle questi due classici vincoli:
  1. Il dato deve essere pubblicato in un formato strutturato che può essere interpretato da un software (per esempio un foglio di calcolo e non la scansione di una tabella)
  2. Il dato deve essere pubblicato anche in formato non proprietario (nell'esempio di prima, CSV è un formato migliore di Microsoft Excel in quanto non soggetto a licenza)
In questo modo saltano scansioni, PDF, e anche fogli xls impaginati per la stampa.

Sulla qualità del dato il tema è grande. Bisognerebbe infatti valutarlo in termini di struttura (cosa facile e neutra), mentre cosa diversa sono i contenuti. Non ho una risposta pronta per questo, e se ce l'avessi probabilmente rendere il "nel frattempo" qualcosa di lungo.
 
Alla luce dei suggerimenti di Andrea, Davide e Francesco, qualche dato verrà ripreso, riaggiustato e riproposto in nuovo formato, e salvo qualche dataset sporadico (vedi quello del turismo) non vi sarà una procedura che garantirà uno standard minimo di quantità e qualità per la produzione dei dati da parte degli uffici comunali, che sono la vera fonte dei dati su cui lavorare e destinare il nostro sforzo in queste linee guida. Questo tema, per me fondamentale, è stato bypassato dal Dott.Meli che prospettava problemi di sindacati, mansioni e budget vari. Abbiamo traguardato oltre.

L'istituenda commissione che valuterà, fatta l'anagrafica, quali dati pubblicare con priorità a partire da un db centralizzato, potrebbe monitorare che la sezione OpenData non rimanga ferma per più di 30 giorni. Non sarà ferma se pubblicherà un nuovo dato, se lo arricchirà di metainformazioni, se moltiplicherà il numero di formati di download, se ne pulirà qualcuno, se ne rimuoverà qualcuno di inutile.
C'è ancora una volta da assegnare un ruolo dal lato del Comune, qualcuno a cui suonare la campanella nel caso di stop.
 
Il rischio concreto che tra sei mesi rimanga tutto indefinito nell'attesa della centralizzazione dei servizi è alto, viste le esperienze precedenti a vari livelli. E sinceramente non vorrei aver speso parte del mio tempo per tornare allo status attuale, senza aver apportato un plus migliorativo.
Non mi sto tirando indietro nè sto facendo il disfattista. Provo a cogliere tutte le sfaccettature di questa vicenda, alla luce di mettere mano nuovamente alle linee guida.

Anche io temo che si possa arrivare a un nulla di fatto. Ma grazie al lavoro che stiamo facendo insieme, ho capito che stiamo affrontando una "cosa" grossa, per cui vale la pena di spendersi per ancora un altro po'. Però il Comune deve prendersi le sue responsabilità ed il suo ruolo, mettersi davanti dei paletti in termini di scadenze e qualità, e soprattutto crederci ed avere una visione d'insieme.
 
Per me andrà comunque prevista una procedura interna, checchè ne dica il Dott. Meli.

L'anagrafica serve proprio per le procedure. Anche se non si dovesse centralizzare tutto, sarebbe necessaria. Per quello lavora con EXCEL, quello con OpenOffice, quello fa solo scansioni, quello uso un applicativo dedicato, quello usa la carta, quell'altro il campo Via lo chiama "NomeVia", e quell'altro "CodiceVia". Senza conoscere i tipi di dati, e come vengono prodotti e archiviati e difficile trovare una procedura buona per tutto.

"Nel frattempo" potremmo chiedere di rispettare almeno i due punti di sopra, per i quali scrivere un manualetto di procedure mi sembra cosa semplice.


Da subita un'idea di verso dove bisognerebbe andare da subito (e ci vuole strategia, visione, personale e procedure) e di quanto tutto questo sia politica nel senso alto e buono del termine. Se i nostri amministratori lo capiranno, "nel frattempo e dopo" sarà tutto più semplice.

Buon pranzo,

a


--
Andrea Borruso
website: http://blog.spaziogis.it
GEO+ geomatica in Italia http://bit.ly/GEOplus 
38° 7' 48" N, 13° 21' 9" E, EPSG:4326
--

"cercare e saper riconoscere chi e cosa,
 in mezzo all’inferno, non è inferno, 
e farlo durare, e dargli spazio"

Italo Calvino

Giulio Di Chiara

unread,
Jun 19, 2013, 8:27:00 AM6/19/13
to andy, opendat...@googlegroups.com
Andy,

Nelle linee guida inserirei questo punto: passare entro fino settembre (è una data di esempio) a tre stelle. Con tutto ciò che ne consegue, anche con la rimozione di alcuni file.

Andrebbero esplicitate tutte le condizioni tecniche del "3 stelle" così cominciamo a fargli alzare l'asticella della qualità.
 
Per questo punto, ancora una volta, ci vuole una figura che si occupi di verificare le stelle. 

Qui ricadiamo nella solita beffarda routine che per le istituzioni sono quasi mai previste delle sanzioni. Quindi l'unica possibilità è prevedere l'individuazione di un responsabile da incensare o lapidare all'occorrenza, anche se alla fine saremo noi (più che altro voi tecnici) a valutare la qualità delle pubblicazioni.

Verosimilmente potremmo inserire nelle linee guida che i dati pubblicati saranno verificati dalla comunità degli sviluppatori che muoverà le proprie critiche positive e negative, e che il Comune è obbligato a recepirle e farsene carico per il miglioramento del dato pubblico, dando risposta entro un determinato arco temporale.

L'istituenda commissione che valuterà, fatta l'anagrafica, quali dati pubblicare con priorità a partire da un db centralizzato, potrebbe monitorare che la sezione OpenData non rimanga ferma per più di 30 giorni.

Questa commissione da chi sarà composta? Altro tema non discusso. Con molta probabilità saranno da escludere i dirigenti d'area per mille motivi. Rimane il gruppo opendata da noi rappresentato e eventuali referenti individuati dai dirigenti nelle singole aree comunali. Non vedo altre possibilità.

Sul "non rimanga ferma per più di 30 giorni" sono d'accordo in parte. Ok che dobbiamo costringerli ad aggiornare con cadenze più o meno regolari, ma non vorrei che diventi abitudine l'aggiornamento del dato esistente senza produrne nuovi.

 L'anagrafica serve proprio per le procedure. Anche se non si dovesse centralizzare tutto, sarebbe necessaria. Per quello lavora con EXCEL, quello con OpenOffice, quello fa solo scansioni, quello uso un applicativo dedicato, quello usa la carta, quell'altro il campo Via lo chiama "NomeVia", e quell'altro "CodiceVia". Senza conoscere i tipi di dati, e come vengono prodotti e archiviati e difficile trovare una procedura buona per tutto.

Tu stai guardando più le caratteristiche del dato. Io pensavo all'organizzazione delle risorse umane. 
Fermo restando i dettami tecnici che giustamente evidenzi, rimangono da sviluppare le procedure che portano alla produzione dei dati all'interno degli uffici.
A tal proposito la proposta era la seguente: 

ogni area comunale avrà un dirigente (che già esiste) il quale individuerà tramite circolare un "referente opendata", ovvero un personaggio attitudinalmente più predisposto alla tematica che verrà infarinato (tramite corso o tramite affiancamento di volontari) sulle caratteristiche base del dato da produrre e inviare al webmaster.

Il dirigente sarà sempre responsabile della pubblicazione, ma verrà affiancato da qualcuno che potrà dedicarsi maggiormente all'attività e divenire punto di riferimento per gli impiegati del settore.
Inoltre, come scrivevo prima, il referente farebbe parte della commissione che in questo modo potrà riunirsi più facilmente, non facendo capo agli infiniti impegni dei dirigenti.

A dopo.



twitter: giuliodichiara 
Reply all
Reply to author
Forward
0 new messages