Metadata Jones.

Per esperienza, nella mia vita lavorativa ho sempre lavorato bene o forse meglio con chi era più a digiuno.
I super esperti magari vedono più complicazioni, e tendono per questo a rinunciare.
Anche perché io per primo NON mi considero un esperto, ma solo uno che spesso prova cose in base al solo entusiasmo e voglia di esplorare.
Sono l'Indiana Jones dei metadati :)
Per anni mi sono occupato di metadati e ontologie, e della loro rilevanza che va di pari passo con i dati.
L'amore della vita non si scorda mai, per cui da alcuni anni per passione continuo, nel mio tempo libero, ad occuparmi di metadati e ontologie.
Soprattutto nelle ontologie non mi ritengo e non sono un guru, anzi mi ritengo un principiante.

Qualche anno fa sono stato co-relatore di una tesi di uno studente di informatica in Bicocca (relatore Batini), e con lui abbiamo realizzato tools che, date in input ontologie a scelta (che vuol dire modificabili), cercano eventuali concetti presenti sotto forma di nomi e descrizioni di tavole e campi delle basi dati.
Successivamente, da quando ho avuto a disposizione il catalogo agid, con gli stessi metodi e tools ho provato a lavorare su nomi e descrizioni di basi dati e applicativi di ogni ipa (pubbliche amministrazioni).
Per provare a dare una migliore evidenza al lavoro, ho provato, con l'aiuto di un caro amico di nome Marco Brancolini (presente in lista sod), a mappare le ipa e per ciascuna ipa a far vedere un elenco, per ora testuale, di entità concettuali presenti nelle ipa (soggetti, beni, luoghi, documenti, per citare le entità più astratte possibili).

Un po' di premesse, poi basta, prometto che vado sul pratico.
Le premesse servono solo a far comprendere a tutti che non sono in preda al delirio di onnipotenza da ontologie, ma ripropongo solo cose che ho sperimentato. Anzi non ho manco la pretesa di parlare di ontologie, ma solo di schemi concettuali di riferimento.

Comincio col dire che la mia idea di metadatare dal basso i database non ha la pretesa di essere la soluzione a tutti i mali dovuti a scarso riuso, ma offre un modo, uno strumento, per mettere a fattor comune i concetti presenti, nella fattispecie nelle ipa.
Può servire insomma per mettere le basi, per costruire il campo base attrezzato per, un domani, ottenere le ontologie della p.a. secondo le migliori proposte al mondo, che per me sono ad esempio quelle di Nicola Guarino, che rappresenta per me il monte Everest.
Le gerarchie di entità, e le relazioni, che uso per "cercare la conoscenza", le ho avute in dote da Carlo Batini, ma non per questo hanno da parte mia la pretesa di essere l'unico modo possibile per cercare la conoscenza. Chi desidera ne può proporre altre.
Io ho una versione del campo base ottenuta, per il Piemonte, oltre dieci anni fa, per cui andrebbe di sicuro attualizzata, ma può servire come base per comprendere.

Proposta pratica:

1) bisogna chiedere, possibilmente a personale I.T. delle amministrazioni, di avere i ddl-sql scripts delle basi dati che hanno in casa.
In allegato un esempio di ddl-sql script (merlo.sql: https://www.dropbox.com/s/386l9k4mwit5fkp/merlo.sql?dl=0).

I ddl scripts, opportunamente reversati con tools come erwin (attività che svolgo io), permettono già di mettere in relazione fisica (constraints) i vari oggetti dei database, che poi sono le tavole e i campi.
Scorrendo l'allegato, vedrete che lo script ha delle frasi come "comment on table eccetera eccetera", e "comment on column eccetera eccetera"

Queste frasi sono importanti, direi importantissime, ovvero chi vi fornisce i ddl-sql scripts dovrebbe avere cura di produrveli con tutte le descrizioni (i comment on) che "eventualmente" hanno le tavole e i campi dei db.
"Eventualmente", perché chi è del mestiere lo sa, molto spesso le basi dati sono prive di commenti di tavole e campi.
Ma non ci perdiamo d'animo, perché anche senza commenti, i nomi delle tavole e dei campi a volte sono parlanti, e noi come il sangue dalle rape proveremo a capirne il significato.

2) dopo la fase 1, produrremo per ogni base dati un file (pensatelo in excel) che ha queste colonne:

nome-tavola, descrizione-tavola, nome-campo, descrizione-campo (nome e descrizione tavola ripetuti tante volte quanti sono i campi)

3) usando un tool che ragiona su gerarchie e relazioni fra entità

(vedi allegato f2indent.txt: https://www.dropbox.com/s/eodk7k36m6ehn7y/F2indent.txt?dl=0)

proveremo per ogni base dati ad ottenere by reverse il modello concettuale che esprime, lavorando sugli input delle fasi 1 e 2.
Questo NON vuol dire aver fatto l'ontologia, ma solo aver evidenziato dei concetti tramite search per entità.

Se le strutture delle basi dati, che otteniamo dalle fasi 1 e 2, sono il campo base per l'Everest, vuol dire che la fase 3 NON è l'Everest, ma le corde della via ferrata per arrivarci.
(Le gerarchie e relazioni tra entità da usare, potrebbero essere altre, chi vuole ne proponga).

Due parole sul mapping: il lavoro di mapping fatto con l'amico Marco Brancolini, è stato fatto su un livello meno granulare di metadati, ovvero su quanto ottenuto dal catalogo agid.
Con una analogia un po' audace, per ogni ipa ho lavorato su un tabellone fatto da:

nome-database, descrizione-database, nome-applicazione, descrizione-applicazione
(nome e descrizione database ripetuti tante volte quanti sono gli applicativi).

Le ipa impallinate da almeno una entità
(vedi sempre allegato f2indent.txt: https://www.dropbox.com/s/eodk7k36m6ehn7y/F2indent.txt?dl=0) vengono mappate e quindi disegnate.

Cliccando sul punto geografico mappato, in questa prima release tra i metadati del punto geografico vi sono le entità pescate nell'ipa relativa.
(vedi http://nelfuturo.com/un-amico-risponde#)

Forse un giorno disegneremo le gerarchie e le relazioni, e faremo cadere sui luoghi geografici le linee che collegano entità a punti geografici.
Ovvero unire i puntini tramite i concetti che hanno in comune.

Se vedrete occhi sbarrati e terrore alle vostre richieste di avere dalle ipa i ddl-sql scripts, tenete presente che al limite si può anche fare a meno della fase 1, purche vi diano per ogni base dati un file come quello descritto in fase 2. Faremo a meno dei constraints fisici, non saremo in grado di arricchire la conoscenza a disposizione inferendola dai constraints, ma pazienza, si può arrivare sull'Everest anche senza le bombole.

Battute a parte, sono qua per qualsiasi chiarimento.