Un progetto nato in Estonia dimostra come rendere fruibili
al grande pubblico i dati disponibili in database ambientali interconnessi,
per documentazione e interrogazioni
Valerio Alessandroni(1); Peeter Ennet(2); Jaan Aigro(3); Hannes Kinks(3);
Robert Kullamaa(3); Ott Madis Ozolit(3); Ain Salula(3)
Nello scenario europeo, l’Estonia si sta sviluppando come
una e-Country, con una forte informatizzazione di tutti i servizi piubblici.
Affinché questo obiettivo abbia successo, tuttavia, è molto importante che il
pubblico generico cominci ad accettarne l’idea e sia messo in grado di
utilizzare agevolmente tutti i servizi disponibili; in caso contrario,
l’insuccesso è assicurato.
Attualmente, in Estonia è disponibile un blocco di servizi
e-Country accessibili a tutti I cittadini previa autorizzazione, che avviene
tramite inserimento dei propri dati personali. Tale blocco si appoggia al
sistema estone X-tee (‘via-X’, nella lingua locale). Tuttavia, non tutte le
persone sono disponibili a pubblicare i loro dati personali come richiesto.
Per
abituare alla filosofia dell’e-Country, è quindi necessario offrire servizi che
non costringano a rendere pubblici le proprie informazioni personali e tali
servizi devono avere tutti lo stesso tipo di struttura. Ciò non esclude l’uso
dell’X-tee, ma al contrario ne può semplificare ed estendere l’utilizzo in
futuro.
Gestione delle acque
Qui sotto viene descritto brevemente un nuovo servizio
e-Country, che offre alle persone informazioni senza costringerle a pubblicare
i loro dati personali. Il progetto sta ricvevendo una forte attenzione da parte
di organizzazioni ambientali nazionali estoni e norvegesi, ma riteniamo che
anche qualche partner italiano potrebbe essere interessato, date le sue
caratteristiche di innovazione, nell’ottica di un’amministrazione pubblica più
efficiente e più vicina agli utenti.
La Direttiva sull’Infrastruttura delle Acque o WFD
(Commissione Europea, 2000) è un elemento centrale nella legislazione sulle
acque dell’Unione Europea. La WFD impegna gli stati membri a raggiungere entro
il 2015 un buono stato qualitativo e quantitativo di tutti gli enti preposti
alla gestione delle acque. Per raggiungere tale obiettivo, uno dei compiti più
impegnativi è la selezione di misure economicamente convenienti per risolvere
vari problemi degli enti idrici.
In particolare, l’Estonian Environmental Information Centre
(EEIC) raccoglie, elabora, analizza e distribuisce informazioni sulla natura
estone, sullo stato dell’ambiente e sui fattori che hanno impatto sull’ambiente stesso. Inoltre,
le informazioni sull’ambiente vengono messe a disposizione del pubblico
generico, come previsto dalla Convenzione di Aarhus (Aarhus, 1998).
L’EEIC ha creato un gruppo di lavoro con alcuni studenti
della Tallinn University of Technology (TUT) allo scopo di creare una serie di
applicazioni, soprattutto modelli computazionali, per la creazione di un
Estonian Water Information System (EWIS). Esso utilizzerà molti database
differenti, a loro volta creati per la memorizzazione dei dati ambientali in
Estonia. L’EWIS dovrà ottenere i dati necessari al suo funzionamento
principalmente da tre database EEIC: l’Environmental Register, l’Information
System of Environmental Permits e l’Information System of Estonian Nature.
Poiché
tali database non sono intrinsecamente interconnessi, è stato necessario
pensare a un servizio add-on con
caratteristiche di bridge per assicurare la corretta comunicazione fra i
database e i modelli, soprattutto perché i modelli possono essere interdipendenti
fra loro. Le informazioni ambientali in possesso dell’EEIC saranno rese
disponibili al pubblico tramite un servizio cartografico interattivo –
utilizzabile da chiunque: scienziati, studenti, amministrazioni e semplici
cittadini – che fornirà anche le applicazioni citate in precedenza.
Un
risultato ottenuto dagli sforzi del gruppo di lavoro è un metodo, descritto
nella fig. 1, che verrà utilizzato per connettere i dati ambientali e i modelli
computazionali. L’uso di tale metodo è dettagliato nel seguito dell’ articolo.
Figura 1. Metodo di connessione dei database
L’interfaccia di sistema è stata realizzata usando la
tecnologia Geographic Information System (GIS). Tale tecnica permette, ad
esempio, di testare vari scenari e tenere conto, nello stesso tempo,
dell’influenza di misure diverse sull’intero bacino idrografico, fornendo un
servizio cartografico interattivo a disposizione della base utenti per eseguire
applicazioni e fare interrogazioni.
L’Estonia è molto adatta per progetti di questo tipo, grazie
alle sue dimensioni contenute e alla notevole quantità di dati ambientali
disponibili. In particolare, il numero di enti idrici in Estonia è facilmente
gestibile ed è anche opportunamente monitorizzato. Molti dei corsi d’acqua
estoni hanno stazioni di misura per la raccolta automatica dei dati, pertanto
mantenere un flusso costante di nuove informazioni non presenta particolari
difficiltà.
Nonostante esista già un tool sviluppato dal governo estone,
l’X-tee, per consentire la comunicazione regolare fra i database amministrati
dal governo stesso, il gruppo di lavoro non si è fatto limitare dai suoi
vincoli. Tutti i database di cui il gruppo aveva bisogno sono amministrati
in-house e, in futuro, l’X-road sarà incluso nel nuovo servizio, denominato
Rooma (la città di Roma in estone, fig. 2).
L’acronimo deriva da Relational,
Object-Oriented, Models, Databases (‘Andmebaasid’ in estone). Il servizio
bridge opererà da mediatore e traduttore fra i vari database che utilizzeremo,
con il metodo di connessione (fig. 1) come base di riferimento. Poiché ogni
databas è costruito in modo differente, i dati in esso contenuti sono
intrinsecamente comprensibili solo per le applicazioni che sono state
esplicitamente progettate per tale database. Questo problema verrà risolto con
‘Roma’, che stabilirà uno specifico formato per i dati ambientali.
Per esempio,
i database possono utilizzare modi differenti per stoccare i dati geospaziali.
Alcuni usano oggetti geospaziali completi, mentre altri si limitano ad avere
solo un ‘campo commenti’ incluso in una riga dati, che memorizza la posizione
geografica in modo testuale. Se vi sarà la necessità di interrogare questi dati
formattati in modo irregolare, Rooma li convertirà in un formato standard con il
quale le nostre applicazioni avranno familiarità.
Figura 2. Le funzioni primarie di Rooma
Questo ci porta a un’altra decisione progettuale riguardante
le nostre applicazioni – poiché dovevamo utilizzare un certo numero di
database, abbiamo costruito semplicemente le nostre applicazioni in modo che
ciascuna abbia la propria logica di interrogazione e la parte di comunicazione
sia gestita da Rooma.
Effettivamente, quindi, le nostre applicazioni sono
costruite basandosi su Rooma anziché sui nostri database. Ciò significa che se
dovremo connettere altri database in EWIS durante lo sviluppo, potremo farlo
senza dovere editare la logica di interrogazione di tutte le applicazioni
esistenti.
Il ciclo di comunicazione è molto semplice. Inizialmente, un
utente dell’EWIS avvia un’applicazione perché desidera calcolare qualche
risultato. L’utente richiede quindi il calcolo..A questo punto, l’applicazione
trasmette a Rooma la sua richiesta e Rooma sceglie i database da interrogare per
ottenere le informazioni necessarie.
Dopo l’interrogazione dei database, Rooma elabora quindi i dati secondo un formato stabilito e li inoltra
all’applicazione. Questo ciclo si ripete per ogni database. Infine,
l’applicazione inizia a lavorare e restituisce il risultato del calcolo in
funzione dei dati ricevuti dai database.
In più, i modelli sono interconnessi: il risultato di un
modello può diventare l’ingresso di un altro modello. I modelli sono inoltre
connessi ai database EEIC per l’installazione e l’inizializzazione automatiche.
Anche le applicazioni possono essere interconnesse e lo devono essere, se è
richiesta una modellazione complessa. E’ qui che Rome diventa ancora una volta
utile, assicurando che tutti i dati siano convertiti in un formato specifico,
leggibile automaticamente, che ogni componente può comprendere (fig. 3).
Se
un’applicazione richiede un input da un’altra applicazione, Rooma la esegue e
restituisce i dati richiesti.
Figura 3. Flusso di lavoro per l’esecuzione di un modello
Rooma non è solo un tool vitale nelle intercomunicazioni fra
i componenti dell’EWIS, ma è anche un tentativo di standardizzazione dei dati
ambientali..L’idea di avere un formato dati non ambiguo è interessante non solo
per gli sviluppatori dell’EWIS, ma anche per ogni idrologo perché, come
affermato sopra, i dati ambientali a volte sono stoccati in modo caotico, in
quanto lo stoccaggio dei dati non è centralizzato in un singolo database, ma in
molti database più piccoli.
Recentemente, Il W3C e l’ISO/IEC JTC 1 hanno
iniziato una collaborazione, nata dal desiderio del W3C di utilizzare come standard
internazionale le sue specifiche aperte. Anche qualsiasi tipo di
standardizzazione dei web service ha un effetto sullo sviluppo dell’EWIS,
perché l’EWIS stesso è un servizio fornito su web. L’omogeneizzazione del
terreno dei web service dovrebbe dare l’esempio e, nello sviluppo dell’EWIS,
intendiamo seguire tale esempio, cercando di standardizzare anche i dati che
abbiamo utilizzato, benché in un ambito limitato.
E’ auspicabile che gli sforzi finora dedicati all’EWIS diano
dei frutti, perché il sistema avrà un’ampia base utenti da soddisfare e
semplificherà la vita di tutti coloro che hanno a che fare con le politiche
idriche o l’idrologia in generale. Lo scopo è creare qualcosa che rappresenti
un esempio da seguire, perché i principi usati nell’EWIS possono essere
applicati anche altrove, dovunque sia richiesta una comunicazione senza
ostacoli fra database e applicazioni, soprattutto nel campo dei dati nazionali
pubblici, come l’argomento del nostro sistema informativo – i dati ambientali.
1 Guest professor
2 Estonian Environment Information Centre, Data analyst
3 Tallinn University of Technology, Student
No comments:
Post a Comment