In analogia a quanto avviene con XML, `e possibile effettuare una validazione dei documenti IDN rispetto agli IDN Template.
Tale procedura pu`o risultare particolarmente utile nella fase di testing di una IDN Compliant Application, consentendo al programmatore di verificare
7.3 Validazione di un documento IDN 153
se i documenti prodotti e/o elaborati da tale software sono effettivamente conformi a quanto atteso.
In particolare occorre che siano verificate tutte le condizioni indicate di seguito:
1. conformit`a di struttura: il documento IDN deve possedere una struttura conforme a quella dichiarata dall’IDN Template.
In particolare, per ogni nodo del DAG che costituisce il documento IDN occorre validare l’insieme dei link di aggregazione. Questo si- gnifica che ogni nodo X deve aggregare tutti e soli nodi che risultino ciascuno conforme (per le tre regole qui elencate) ad un nodo modello che sia aggregato da quello cui il nodo X in questione dichiara di essere conforme. Inoltre ogni link di aggregazione deve essere presente nel rispetto delle molteplicit`a previste;
2. conformit`a di formato: per ogni nodo del DAG che costituisce il documento IDN, occorre validare il formato, ovvero il MIME Type dei dati di livello applicativo da esso gestiti deve corrispondere a quello indicato dal relativo nodo modello;
3. conformit`a di sintassi: per ogni nodo del DAG che costituisce il documento IDN per cui `e stata indicata la sintassi, occorre che que- st’ultima sia validata, ovvero la sintassi dei dati di livello applicativo da esso gestiti deve essere conforme a quella indicata dal relativo nodo modello.
Il presente lavoro si limita a fornire la suddetta serie di regole guida cui un software validatore dei documenti deve sottostare, demandando tale procedura ad una futura implementazione.
Parte IV
Caso di studio: Open Data
Firenze
Capitolo 8
Riuso degli Open Data di
Firenze
Come illustrato all’interno della parte II, l’intero sistema IDN pu`o essere descritto attraverso l’utilizzo di tre viste:
1. la vista sulle risorse e sull’informazione, IDN Information Model, illu- strata al capitolo 3;
2. la vista sull’architettura dei servizi, IDN Service Architecture, illustra- ta al capitolo 4;
3. la vista sulle applicazioni, le cosiddette IDN Compliant Application. All’interno del presente capitolo saranno dapprima descritte le principali nozioni di una IDN Compliant Application.
Quindi, dopo avere introdotto il concetto di ETL (Extract, Transform and Load), verr`a illustrata una IDN Compliant Application che utilizza tale con- cetto al fine creare una “copia cache” degli Open Data pubblicati dal Comu- ne di Firenze, sotto forma di documenti IDN-IM conformi ad un opportuno IDN Template.
Infine, sar`a descritta Easy Florence, una IDN Compliant Application mobile, che effettua il riuso del precedente IDN Template e dei documenti IDN- IM rappresentanti gli Open Data rilasciati dal Comune di Firenze, ottenuti attraverso la procedura di ETL citata.
8.1
IDN Compliant Applications
Le applicazioni in grado di utilizzare documenti strutturati secondo IDN- IM (dette IDN Compliant Applications), costituiscono la terza vista su InterDataNet, insieme all’IDN Information Model e all’IDN Service Archi- tecture, illustrati rispettivamente ai capitoli 3 e 4.
Mentre IDN-SA offre i dati e le API per la loro gestione, la relativa logica di manipolazione si trova all’interno delle IDN-Compliant Applications, le quali implementano un workflow distribuito, in quanto vengono coinvolte diverse entit`a che collaborano intorno a documenti condivisi.
Nonostante le finalit`a siano essenzialmente diverse risulta possibile, esclusi- vamente a titolo esemplificativo, ipotizzare un parallelo [Cio10] fra il mon- do dei database, che `e ormai consolidato da anni e quindi ben noto, ed InterDataNet.
Da un lato sia IDN-IM sia il modello relazionale dei database catturano esclusivamente i principi astratti dell’informazione, senza introdurre elemen- ti implementativi; dall’altro lato, IDN-SA corrisponde ad una specifica im- plementazione, ad esempio al database PostgreSQL. Tuttavia la differenza sostanziale fra un database ed InterDataNet risiede nel fatto che mentre ad n installazioni di PostgreSQL corrispondono normalmente m > n silos di dati indipendenti (i singoli database) 1, invece l’insieme di sistemi che implementano IDN-SA cooperano per la realizzazione di un’unica ragnatela interconnessa di dati su scala di livello Web2.
Le applicazioni sono le entit`a che utilizzando il modello dell’informazione proposto (i database da un lato e IDN-IM dall’altro), implementano le ne- cessarie logiche di business per affrontare e risolvere specifici problemi di dominio. Nel mondo dei database gli esempi possibili di applicazioni sono in numero pressoch´e infinito, ma se la visione che ha guidato gli sviluppi di InterDataNet in questi anni dovesse concretizzarsi, anche gli esempi di applicazioni IDN saranno in numero elevato. Queste ultime, date le carat- teristiche del sistema, saranno orientate alla collaborazione su larga scala e non solo alla mera manipolazione di dati.
Si considerino i complessi workflow utilizzati per la produzione di un atto amministrativo quale una patente di guida o una carta di identit`a; essi po- trebbero essere gestiti tramite decine di applicazioni IDN diverse ed ogni ente potrebbe realizzare la propria; tuttavia sarebbero in grado di manipo- lare non solo le patenti di guida o le carte di identit`a da loro emesse, ma anche quelle rilasciate da uno qualunque degli altri enti (tramite altre appli- cazioni). Questo `e ci`o che accade da anni nel Web limitatamente al contesto della pubblicazione di documenti, dove ogni ente/organizzazione `e libera di selezionare il proprio stack tecnologico per la realizzazione del proprio sito web, conscio del fatto che gli utenti, con qualsiasi user-agent (entro certi limiti), potranno fruire dei contenuti pubblicati senza difficolt`a.
1
Si assume che ogni installazione di PostgreSQL esponga uno o pi`u database. La fede-
razione non `e stata volutamente presa in considerazione per non complicare eccessivamente
l’esempio.
2
Almeno in via concettuale, niente vieta la possibilit`a di creare una “Intranet”
InterDataNet confinata all’interno di un ben determinato perimetro anche se questo vanificherebbe, almeno in parte, i benefici apportati dal sistema.