Buona sera a Tutti, non vorrei fare un discorso del tipo "volemose
bene" o "peace and love", ma non voglio tenere per me il fatto che
patisco nel vedere contrapposizioni anche qui, in questa mailing list.
Peraltro ne faccio parte, anzi ringrazio di farne parte, quindi mi va
bene di patire :)
Tuttavia le contrapposizioni ideologiche non fanno bene, non portano
da nessuna parte.
Non sono ne' un esperto di open data, ne' di spc, per cui non metto in
campo la presunzione di fare guerre di religione se sia meglio una
cosa o l'altra: sono necessarie entrambi, credo, per quanto ho letto e
per quanto la mia esperienza mi suggerisce.
Cosi' come forse e' utile cio' che evidenzia il signor open fuffa (il grigio).
Cosi' come credo possa essere utile cio' di cui propongo fino alla
nausea, cioe' l'uso di ontologie applicate al mondo degli open data.
Quando tanti anni fa lavoravo in Iveco e mi occupavo di repository dei
metadati, non sfuggiva un campo che fosse uno se non era stato
modellato e depositato nel repository, e di conseguenza il concetto di
master data management era implicito: esisteva IL DATO, fonte unica, e
per ciascun dato si sapeva esattamente chi lo scriveva, lo leggeva
eccetera (le famose proprieta' CRUD, Create, Read, Update, Delete).
Altri tempi.
Poi arrivarono i sistemi decentrati, client server, poi web, e
allegria ! Ognuno si costruiva le strutture dati a piacere, se
conveniva si accedeva alla fonte dati master, altrimenti si duplicava,
e addio allineamenti.
Altri tempi, che portarono al bisogno di recuperare l'entropia con
fatiche immani di reverse engineering di strutture dati (fare il
maiale partendo dal salame), di riconciliazione formati, di
individuazione e scelta di fonti master per ridurre le ridondanze e le
duplicazioni. Il mio primo lavoro in CSI, ed anche il piu' importante
per il quale venni assunto, consisteva nel catalogare i metadati delle
basi dati della pubblica amministrazione locale piemontese. Le basi
dati sono oggetti informatici ricchi di informazioni, di semantica,
esse racchiudono concettualmente, oltre ai dati, anche i processi che
descrivono i contesti applicativi, nella fattispecie quelli della
pubblica amministrazione. Quando con un semplice metalinguaggio
concettuale
preso a presto dalla grammatica italiana, dico che "il cittadino paga
i tributi", esprimo sia il fatto che ci sono i dati dei cittadini, i
dati dei tributi, e la relazione tra i dati dei cittadini e i dati dei
tributi. Ma esprimo anche un processo dato dalla relazione, o verbo,
"paga". La modellazione concettuale esprime con la grammatica le
relazioni che vi sono tra gli oggetti informatici, che
fondamentalmente sono dati, o entita', e le relazioni, o processi. Il
modello concettuale si chiama anche modello entita' relazioni.
Potremmo anche chiamarlo modello dati processi, ma preferisco entita'
relazioni, perche' piu' affine alla grammatica alla quale si rifa',
ovvero: soggetto, predicato-verbale, complemento-oggetto. Venivo da
un'esperienza di eccellenza, in IVECO, dove l'implementazione
informatica di dati e processi avveniva top-down, partendo da un
perfetto modello concettuale, che veniva depositato in un repository
(opportunamente conciliato con modelli gia' esistenti che di
conseguenza evolvevano) e implementato informaticamente, ovvero
diventava una struttura di un database, e un archetipo
dell'applicazione informatica realizzata. Tutto questo era
meraviglioso, poiche' si arrivava a produrre il salame partendo dal
maiale, cioe' seguendo un ciclo naturale che partiva dalla
formulazione nero su bianco dei requisiti con gli utenti, ed arrivava
sino alla minutazione delle specifiche tecniche nel linguaggio
informatico implementativo. Arrivai in CSI e tutto questo non
esisteva, o meglio esisteva tanto salame ma non si sapeva da che
maiale arrivasse. Bisognava in qualche modo sforzarsi di riottenere il
maiale partendo dal salame, con operazioni di reverse engineering,
cioe' di risalire ai modelli concettuali che avevano generato gli
oggetti informatici fisicamente realizzati. In particolare ci
concentreremo sulle basi dati, ovvero su tabelle costituite da righe e
colonne, e tra loro relazionate da attributi chiave. Per semplicita'
immagina un data base access, con tabelle tra loro correlate. Io avevo
una vasta esperienza di reverse engineering di strutture di basi dati,
con tools come erwin della Computer Associates. Tali tools permettono
di dare una forma grafica ad una base dati, partendo dalla sua
struttura fisica, e trasformandola in un grafo con le tabelle e i
campi racchiusi in tanti quadrati, e le relazioni tra le tavole
espresse come linee di collegamento tra tabelle, linee che legano i
campi chiave tra una tabella e l'altra. Un primo grosso lavoro fu
quello di reversare tutte le strutture dei database fisici, per dargli
una forma grafica. Era gia' qualcosa, partendo dal salame, ma non era
ancora il maiale. Diciamo che usando il salame come fosse pongo, col
pongo avevamo costruito un maiale ma esso era inanimato come una
statua di pongo appunto. Bisognava dargli vita. Tutti questi maiali
reversati e inanimati, avevano bisogno almeno dei burattinai che li
animassero artificialmente. Cercai intanto nel web chi fosse il
massimo esperto di modellazione concettuale nella pubblica
amministrazione, e l'occhio cadde rapidamente sul professor Carlo
Batini. Batini negli anni '90 in AIPA raccolse e catalogo'
i modelli concettuali della pubblica amministrazione centrale, con un
paziente lavoro di ricostruzione fatto principalmente da interviste
presso gli enti governativi, e svolto da tesisti e borsisti. L'idea
che misi in campo, e che Batini valorizzo' con tutta la sua esperienza
e competenza sia della P.A. che della modellazione concettuale, fu
quella di usare i modelli concettuali PAC (P.A.centrale) di Batini
come burattinai dei concetti presenti nelle basi dati della PAL
(P.A.locale, quella piemontese). o meglio ancora di usare entita',
gerarchie, relazioni e attributi della PAC come esche da pesca per
"pescare" i concetti nella PAL. Mettemmo a punto una metodologia,
Batini ed io, che chiamammo anche "pesca miracolosa", dove si
pescavano i concetti per somiglianza. Nel mare magnum delle strutture
delle basi dati PAL piemontesi, si cercavano per somiglianza i
concetti presenti. In poche parole, ogni oggetto concettuale PAC
(entita'/gerarchie, attributi, relazioni) veniva cercato per
somiglianza nei nomi e nei metadati descrittivi di tavole e campi
delle basi dati. Qualcuno ha definito un po'
"cheap" l'uso di queste euristiche e soluzioni empiriche, ma tale
lavoro ci ha permesso di ridurre di un ordine di grandezza i tempi
necessari a riconcettualizzare tutta la PAL piemontese. Venne
realizzato, con un tesista della Bicocca, da me un tool che partendo
dagli schemi concettuali della PAC otteneva gli schemi concettuali
della PAL. Ci basavamo sull'ipotesi che gran parte dei concetti PAC
fossero validi anche per la PAL, e li andavamo a cercare e mappare.
Inoltre la metodologia consentiva, oltre all'inferenza semantica di
somiglianza like, anche l'inferenza relazionale, ovvero le relazioni
fisiche tra gli oggetti della PAL "pescati" potevano rivelare nuovi
concetti ed arricchire il repository ottenuto. Era ed e' quindi una
metodologia apprenditiva: venivano usati dei concetti come criterio di
ricerca, e i concetti trovati potevano essere piu' ricchi di quelli di
partenza. Il tool realizzato con Garasi per la sua tesi applicava la
metodologia sulle basi
dati, ma eravamo convinti che tale metodologia poteva andare bene piu'
in generale anche per gli oggetti del web, ovvero per andare a scovare
relazioni nel mare magnum del web, idea alla quale ci sta arrivano
google, anzi pare ci sia gia' arrivata in stati uniti. Presentammo,
Bicocca ed io, questi esperimenti all'iasummit a Trento nel 2007, li'
conoscemmo Nicola Guarino del CNR, esperto mondiale di ontologie. Lui
volle approfondire e propose a CSI (nella mia persona) e a Bicocca
(Batini) di partecipare alla stesura di una proposta che chiamammo
ontopa: definire un
ente, e l'attivita' dell'ente stesso, che avesse il compito per la
nazione italiana di gestire il repository delle ontologie della
pubblica amministrazione. Partendo dall'esistente, utilizzando vari
metodi tra cui il metodo Batini-Grosso, arrivare a gestire un vero e
proprio registro di repositories ontologici a vari livelli, dalla PA
centrale alle singole PA dei comuni, riutilizzando anche i metodi e i
tools sperimentati per la PA della regione piemonte. Guarino si
occupo' di presentar in CNIPA la proposta: era il 2008.
Tutta questa sbrodolata stile quark di Piero Angela, fondamentalmente
per dire che un approccio ontologico "in reverse" prima o poi sara'
necessario applicarlo anche nella gigantesca nuvola degli open data.
E tutta sta sbrodolata anche solo per evidenziare che su ogni tema,
ogni attore porta la sua esperienza, e con la sua esperienza puo'
arricchire anche per il futuro cio' di cui ci stiamo occupando nel
presente. Piu' volte nei thread di sod sui temi da me proposti mi sono
definito autoironicamente vintage, ma riferito ai tools sperimentali
realizzati, non tanto alle idee che magari vintage non sono poi cosi'
tanto, perche' si sa che la storia dell'informatica e' piena di
ricorsi storici, di problemi ricorrenti e di soluzioni ricorrenti.
Un saluto. Riccardo Grosso.
Il 10 novembre 2012 21:24, Francesco Minazzi
<
dott.france...@gmail.com> ha scritto:
--
http://about.me/riccardo.maria.grosso