metadati

Vista l'architettura di progetto i metadati non sono un optional utile per interpretare i dati, ma qualcosa di più.
Costituiscono l' intelligenza del sistema perchè è attraverso di essi che verranno attivate tutte le azioni previste.
Quindi non possiamo utilizzare il solito file descrittore (magari seguendo paradigmi standard tipo dublin core) ma ci serve un vero e proprio database che dovrà contenere:

• indirizzo di origine del dato
• credenziali e protocolli per l'accesso al dato
• descrizione (vedi sopra)
• criteri di validazione
• criteri di transcodifica
• criteri di offuscamento
• regole per la ripubblicazione del dato

Forse è utile mettere in questa componente anche i log di sistema (riguardanti le transazioni con le banche dati provider e con i servizi client) e una cache dati da dimensionare inoltre potrebbe ospitare interi pezzi di codice da attivare su trigger.
Ci vuole quindi un dbms robusto e io penso a postgres anche se altrettanto validi sono mysql o mariadb che è la versione più open di mysql ormai sotto l' egida dell' Oracle corporation. Meno bene sqlite, ma soltanto perchè ha meno tools.
Il dibattito è aperto.

Nella nostra offerta tecnica abbiamo proposto l'uso della piattaforma EDI del CNR raccomandata dal RNDT (Repertorio Nazionale Dati Territoriali) dell'AGID.
E' possibile vederla in azione qui: http://edidemo.get-it.it
Penso non sia complesso customizzarla per Forma Romae. Va analizzata la necessità di avere un Database dedicato.

Come descrittore va benissimo, ma secondo me abbiamo bisogno di molto di più che un descrittore, ci serve anche registrare protocolli di interoperabilità, criteri di validazione ecc... vedi l'elenco che ho postato che forse non è neanche completo.
Insomma la piattaforma può essere un ottimo strumento di raccolta informazioni in modo standardizzato, ma poi perchè quelle informazioni (e non solo quelle) fungano da regole, trigger ecc. per il funzionamento della AI c'è bisogno di un DB.
Ad ogni descrizione di classe dati va associata una tabella di azioni possibili che a loro volta azionano uno o più trigger che lancia sql e altro...
Insomma una specie di programmazione ad oggetti che deve risiedere da qualche parte. Il dato così diventa esso stesso un oggetto e interagisce col sistema, non so se mi sono spiegato....
Ho riguardato la piattaforma e mi pare che soddisfa benissimo il punto 3 del mio elenco, ma ci sono gli altri punti.......
Usando come riferimento l' ETL la piattaforma può benissimo funzionare per l' Extract, già funziona meno per il Translate perchè dice come è scritto il dato ma non come vogliamo trasformarlo e non ci è di nessuno aiuto per il Load cioè per l' utilizzo del dato.