Come illustrato all’interno del paragrafo 2.4, il Comune di Firenze risulta a dicembre 2012 la terza amministrazione in Italia per numero di dataset rilasciati (circa 350, come illustrato all’interno della tabella 2.1); tali dati sono disponibili in formati liberamente riutilizzabili (quali CSV, KML e Shapefile, illustrati all’interno del paragrafo 2.3) senza alcuna restrizione. Una analisi accurata di essi consente comunque di evidenziare alcune carat- teristiche che potrebbero essere aggiunte al fine di renderli ancora pi`u usabili di quanto siano gi`a adesso. Innanzitutto, i dati sono talvolta presentati in maniera generica; ad esempio i file KML relativi alle attivit`a commerciali non consentono di conoscere con precisione la tipologia di ognuna di esse (es. forni, macellerie, ecc. . . ).
Inoltre sarebbe interessante riuscire ad individuare facilmente un singolo dato senza dovere leggere l’intero dataset; ad esempio, volendo conoscere il sito web del Museo Nazionale del Bargello, occorre dapprima aprire il file relativo ai musei, quindi individuare al suo interno la sezione relativa a tale museo, ed infine trovare l’informazione desiderata. Sarebbe invece preferibile poter indirizzare direttamente tale dato, in modo da accedervi con semplicit`a. Le informazioni dotate di tali caratteristica sarebbero facilmente riutilizzabili ed integrabili in applicazioni realizzate da terze parti.
A tal fine e nell’ottica di presentare alcuni casi d’uso della tecnica di mo- dellazione mediante IDN Template, `e stata realizzata una opportuna IDN Compliant Application in grado di trasformare tali dati in documenti IDN- IM.
Come gi`a illustrato all’interno del paragrafo 2.4, il Comune di Firenze ha suddiviso i propri Open Data in varie categorie, ad ognuna delle quali appar- tiene un certo numero di dataset. Per quanto riguarda i file georeferenziati in formato KML4, ogni dataset si compone di una serie di luoghi di interes- se identificati mediante il tag <Placemark>. Per ognuno di essi il Comune di Firenze ha definito varie informazioni, tra le quali risultano essere pi`u rilevanti:
• un identificativo univoco, rappresentato dall’attributo id all’interno del tag <Placemark>;
• le coordinate geografiche; in particolare per quanto riguarda i luoghi di interesse con geometria puntiforme, esse sono definite mediante il
4Una procedura analoga, che non sar`a descritta all’interno del presente lavoro, `e stata
8.3 ETL per gli Open Data di Firenze 161
tag <Point>, mentre per quelli con geometria lineare o areale viene utilizzato il tag <MultiGeometry>;
• una descrizione, definita attraverso il tag <Description>. In partico- lare essa `e costituita da un CDATA, al cui interno `e stata inserita una lista di elementi5, ognuno dei quali si compone di due sezioni HTML <span>, l’una appartenente alla classe atr-name e l’altra a atr-value. Tali dati costituiscono quindi una serie di coppie nome-valore 6, do- ve il nome `e definito dall’elemento racchiuso all’interno dello <span> di classe atr-name, mentre il valore `e dato dall’elemento racchiuso all’interno dello <span> di classe atr-value.
Tutti gli altri elementi presenti all’interno del file KML, non sono stati invece considerati, poich´e sono essenzialmente utili ai fini della visualizzazione del luogo di interesse su una mappa.
L’organizzazione del file sin qui descritta ha portato alla definizione di un IDN Template, avente come radice un nodo generico, indicato con il nome opendata, il cui LRI pu`o essere considerato come indirizzo base dal quale comporre gli altri LRI di ogni risorsa descritta nel seguito (in base alle regole indicate nel paragrafo 3.6). All’interno della presente trattazione esso `e indicato come:
http://server/baseLRI .
Per ognuna delle categorie definite dal Comune di Firenze, esso aggrega un nodo che `e possibile indicare con il nome generico di {categoria}; pertanto il nodo opendata ha come figli i nodi ambiente, istruzione, turismo, ecc. . . In base alle regole per la definizione degli LRI canonici, ognuno di tali nodi `e identificato da un LRI del tipo:
http://server/baseLRI/{categoria} .
Ciascuno di essi aggrega un nodo per ognuno dei dataset che il Comune di Firenze ha inserito nella relativa categoria, che `e possibile indicare con il nome generico di {dataset}; ad esempio, il nodo turismo aggrega i no- di musei, consolati, bagnipubblici, ecc. . . , ognuno dei quali rappresenta il corrispondente file KML.
Ognuno di tali nodi `e identificato da un LRI del tipo: http://server/baseLRI/{categoria}/{dataset} .
5
Il Comune di Firenze ha scelto presumibilmente un artificio grafico per la visualizzazio- ne di una serie di informazioni nel fumetto che viene presentato quando l’utente seleziona il luogo di interesse, inserendo all’interno di una lista (identificata dal tag HTML <ul>) una serie di elementi (ognuno identificato dal tag HTML <li>).
6Occorre osservare che tutti i luoghi all’interno di uno specifico dataset presentano lo
Ciascun nodo {dataset} aggrega un nodo per ognuno dei luoghi di interes- se definiti dal tag <Placemark> all’interno del file KML, che `e possibile indicare come {luogo}.
Ognuno di tali nodi `e identificato da un LRI del tipo:
http://server/baseLRI/{categoria}/{dataset}/{luogo} .
Tenendo conto delle informazioni significative presenti nel file KML, descrit- te precedentemente, ogni {luogo} aggrega:
• un nodo id; i dati di livello applicativo da esso gestiti contengono l’identificativo specificato dall’attributo id sopra illustrato;
• un nodo coordinate; i dati di livello applicativo da esso gestiti con- tengono la codifica delle coordinate geografiche in formato GeoJSON (illustrato all’interno del paragrafo 2.3.3);
• un nodo descrizione, il quale aggrega a sua volta un numero di nodi pari a quello delle coppie nome-valore presenti nel tag <Description> sopra illustrate. In pratica, per ogni coppia nome-valore esiste un nodo il cui LRI `e stabilito dal nome ed i cui dati di livello applicativo sono impostati al valore.
La figura 8.1 illustra la struttura di un ipotetico e generico IDN Template relativo alla rappresentazione sotto forma di documento IDN-IM degli Open Data pubblicati dal Comune di Firenze. Tuttavia occorre rilevare che i vari dataset sono diversificati tra loro dall’insieme di nodi aggregati da descri- zione, poich´e le coppie chiave-valore sono diverse per ogni dataset. Inoltre la stessa natura molteplice dei dataset fa s`ı che essi siano diversi tra loro anche per quanto riguarda la semantica.
Pertanto, la struttura del modello presentata in figura 8.1 pu`o essere conside- rata come un meta-modello da declinare opportunamente in base al dataset considerato; ad esempio la figura 8.2 illustra la sezione dell’IDN Template relativa ai musei, mentre la figura 8.3 illustra quella relativa ai bagni pub- blici. In particolare, per quanto riguarda il primo esempio, `e stata anche definita una apposita ontologia, illustrata al paragrafo 7.2.
`
E stata quindi realizzata una IDN Compliant Application che effettua un processo di ETL per gli Open Data del Comune di Firenze, al fine di ottenere dei documenti IDN-IM conformi ai relativi IDN Template sopra definiti, i quali gestiscono come dati di livello applicativo le informazioni ricavate da tali Open Data.
Tale applicazione7 esegue i tre passi seguenti:
7Nella implementazione tale ETL `e stato realizzato come procedura batch in linguaggio
8.3 ETL per gli Open Data di Firenze 163 {luogo} coordinate descrizione id {dataset} 1…* 1…* {categoria} 1…* opendata
Figura 8.1: IDN Template generico per gli Open Data geografici pubblicati dal Comune di Firenze; per la natura generica dei dati, non sono specificati gli aggregati del nodo modello descrizione.
164 Riuso degli Open Data di Firenze
{museo}
coordinate descrizione id
nome indirizzo telefono sitoWeb
musei 1…*
Figura 8.2: IDN Template per gli Open Data relativi ai musei pubblicati dal Comune di Firenze.
• i dati contenuti nel file KML desiderato 8 vengono estratti e caricati
in memoria in una struttura analoga alla sorgente9;
• nel processo di trasformazione, viene creata in memoria una apposita struttura equivalente a quella del documento IDN-IM desiderato; per ogni nodo, i dati di livello applicativo gestiti sono ottenuti sulla base di quelli caricati al passo precedente10;
• infine il documento IDN-IM corrispondente alla struttura illustrata11
viene memorizzato da un apposito Virtual Resource.
Si pu`o quindi affermare che `e stata creata in tal modo una “copia cache”, sotto forma di documenti IDN-IM, degli Open Data rilasciati dal Comune di Firenze; essa pu`o essere successivamente impiegata da IDN Compliant
8Il file KML in questione era stato precedentemente scaricato dal sito del Comune di
Firenze relativo agli Open Data [Com12b] e memorizzato in una apposita directory.
9Tale operazione viene effettuata attraverso l’unmarshalling dei dati.
10
Nella implementazione si ricorre ad un apposita libreria Java per la gestione di documenti IDN.
11Nella implementazione si ricorre alla medesima libreria Java per la gestione di