Questo sito web utilizza cookie tecnici e, previo Suo consenso, cookie di profilazione, nostri e di terze parti. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsente all'uso dei cookie. Leggi la nostra Cookie Policy per esteso.OK

la proposta

Metadata mining, migliorare così i database delle PA

Le vicissitudini di un metadata miner, ossia colui che da semplici porzioni di testo riesce a ricostruire informazioni, a dare quindi valore ai dati e ai metadati stessi, alle prese con la mission di ottenere, un domani, le ontologie della PA

11 Dic 2018

Riccardo Grosso

metadata architect


Il minatore è colui che, scavando nella dura terra, riesce a portare in superficie le pietre migliori, che in successive lavorazioni possono diventare preziose. La stessa cosa può fare il minatore informatico, più comunemente detto “miner”. 

Data e metadata miner

Il concetto è applicabile sia ai dati che ai metadati (questi ultimi sono dati che descrivono i dati). Il metadata miner può essere colui che da semplici porzioni di testo riesce a ricostruire informazioni, a dare quindi valore ai dati e ai metadati stessi.

Il mestiere del minatore è un mestiere umile. 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, anzi, un semplice minatore.

Metadati e ontologie

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 Carlo Batini) e con lui abbiamo realizzato tool 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 tool ho provato a lavorare su nomi e descrizioni di basi dati e applicativi di ogni IPA (da qui in poi chiameremo ipa le pubbliche amministrazioni).

Per provare a dare una migliore evidenza al lavoro, ho provato, con l’aiuto di un caro amico di nome Marco Brancolini, 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.

Mettere a fattor comune i concetti presenti nelle PA

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 neanche 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 PA 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.

Una proposta pratica

  • Bisogna chiedere, possibilmente a personale IT delle amministrazioni, di avere i ddl-sql scripts delle basi dati che hanno in casa (un esempio di ddl-sql script). I ddl scripts, opportunamente reversati con tool 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…”, e “comment on column…”. 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.

  • 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).
  • Usando un tool che ragiona su gerarchie e relazioni fra entità 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 svolto 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à 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.

<< Un mio caro e vecchio amico, ed ex collega, ha risposto ad una mia richiesta proponendomi una soluzione. Tale soluzione costituisce la beta release, la release zero, da perfezionare e migliorare, tuttavia e’ un buon punto di partenza.

L’amico risponde: ho scritto (in linguaggio R) un primo programmino che:

Unzippa in una cartella il file allegato ONT.zip e poi esegui ont.html che vi è contenuto: vengono visualizzate in mappa tutte le ipa, il colore del pin point è determinato dal grado di precisione della geolocalizzazione:

– verde = a livello di numero civico

– giallo = a livello di strada

– arancione = nelle vicinanze

– rosso = a livello di città

– nero = a livello di provincia

Tra l’altro in ipaEntitiesGeo.csv ci sono anche due campi (geocodeQualityCode, geocodeQuality che indicano il grado di precisione della geolocalizzazione. Cliccando su un pinpoint vengono visualizzati il suo indirizzo e le sue entità. Ora si tratterebbe di sofisticare ont.html per avere la possibilità di filtrare/ricercare tra tutte le ipa quelle di interesse (ma io sono un principiante di javascript….). Un esempio a caso di mappa interattiva che utilizza la stessa libreria (leaflet) usata da me: >>

Forse un giorno disegneremo le gerarchie e le relazioni, e faremo cadere sui luoghi geografici le linee che collegano entità a punti geografici.

Unire i puntini

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.

La summa di tutti i miei lavori si trova qui, seguendo la presentazione e tutti i link correlati.

@RIPRODUZIONE RISERVATA

Articolo 1 di 3