Archivi categoria: Ricerca

Arenati sullo Step B

Sull’onda di entusiasmo dello Step A siamo partiti con il successivo Step B ovvero l’integrazione delle generazioni dalla 9 alla 12. Non è servito molto tempo ad arenarsi di fronte ai soliti problemi di false omonimie, ambiguità nei nomi, mancate corrispondenze, tutte difficoltà dovute alla mancanza di un identificativo univoco dei soggetti che saranno risolte dal database relazionale. 
Se le competenze e gli strumenti per affrontare questi problemi non mancano, quello che manca è, come al solito, il tempo. Soprattutto da parte mia. 
Le pause pranzo (tempo principe per la ricerca ormai da diversi anni) sono state occupate da un MOOC dell’Université de Bourgogne su un argomento decisamente lontano dalla genealogia (l’enologia) ma, al momento, necessario per affrontare il concreto problema della vinificazione in modo almeno un po’ più consapevole. 
Anche l’attività musicale, ripresa quasi per gioco, ha cominciato ad assumere tratti interessanti e, anche se non assorbe troppo tempo, occupa in modo significativo le risorse mentali ed emotive altrimenti destinate al progetto. Inoltre sembra che anche sul piano della ricerca musicologica si stiano aprendo prospettive interessanti ed a breve sarò chiamato a scrivere (e magari pubblicare) qualche intervento che mi riporti su quel fronte del mondo accademico che mi vede inattivo da oltre dieci anni. 
Sicuramente, però, in questo variegato scenario, Hochadelsdorf mantiene il suo posto di progetto accademico prioritario, sempre più consapevoli che la costruzione di questa base dati ma soprattutto la sua divulgazione possa essere un importante contributo non solo allo studio delle genealogie ma anche a quello dei metodi della fisica applicati alle scienze umane. 

Step A

Si potrebbe pensare che Hochadelsdorf sia scomparso nel nulla e invece ha raggiunto, in questi ultimi mesi, un primo traguardo. Quello che ho denominato Step A, ovvero il popolamento del database relazionale con le prime 9 generazioni, è completato.
Quindi non solo la struttura del database ma anche una parte dei dati pressoché definitivi è stata consolidata e adesso sto lavorando allo Step B ovvero le generazioni dalla 9 alla 12.
Certamente il cammino è ancora lungo anche perché viene percorso con una lentezza estenuante anche se inevitabile.
Nel frattempo (o meglio da un po’ di tempo ma me ne sono accorto solo in questi giorni) è uscito sui Quaderni Storici editi da Il Mulino, un articolo di Paolo Rossi e Roberto Bizzocchi dal titolo “La genealogia come disciplina ausiliaria della genetica”1 che presenta in maniera ampia il mio lavoro di tesi come conferma empirica del modello di Chang2 e come apertura verso ulteriori approfondimenti nell’ambito della genealogia quantitativa e della dinamica delle popolazioni. Uno stimolo in più a completare (in tempi brevi) la base dati.


1. Paolo Rossi, Roberto  Bizzocchi, La genealogia come disciplina ausiliaria della genetica, in “Quaderni storici, Rivista quadrimestrale” 1/2018, pp. 265-278, doi: 10.1408/91127
2. J.T. Chang, Recent common ancestors of all present-day individuals, Advances in Applied Probability 31 (1999) pp. 1002-1026

Mese sabbatico

Questo lungo periodo di silenzio sul blog ha corrisposto ad una fase molto prolifica sul fronte della ricerca. Ho estratto nuovamente tutti i dati dalle tre basi dati online usando nuovi criteri (e automatizzando molti dei processi), li ho allineati per permettere un confronto tra le fonti in modo da individuare (e sanare) eventuali “biforcazioni” nelle genealogie, ho creato la struttura della base dati relazionale ed ho iniziato a popolarla. Tutto sembrava andare a gonfie vele finché è arrivato Dicembre, con il suo carico di impegni, che ha imposto una battuta di arresto, un mese sabbatico appunto. 

Un carico lavorativo straordinario in vista della fine dell’anno mi ha impegnato più del solito trasformando la pausa pranzo in un momento in cui tirare il fiato più che immergersi nell’analisi dei dati. A questo si è aggiunta la decisione di riprendere l’attività musicale in orchestra, dopo oltre 11 anni di inattività. Una scelta di cui sono molto soddisfatto e che spero abbia un seguito, compatibilmente con tutto il resto. 

Nel frattempo, si è laureato il tesista a cui avevo dato alcune dritte sulle genealogie. Ci siamo incontrati per discutere del futuro del progetto Hochadelsdorf e di come avremmo potuto collaborare per unire le due basi dati: quella a cui sto lavorando e quella da lui usata per la tesi. Abbiamo deciso delle linee comuni in modo che, pur lavorando, al momento, separatamente, possiamo poi, con un minimo di sforzo necessario, unire i dati. Hochadelsdorf a questo punto allarga il suo team di lavoro e questo non può che farmi piacere. 

Ancora una volta mi trovo a fare buoni propositi per il nuovo anno. Questa volta sarò molto cauto: l’aspettativa è quella di finire di popolare il database relazionale. Sarebbe già un traguardo! 

Leaving the comfort zone

Due mesi fa, dopo 15 anni, ho lasciato l’azienda per cui lavoravo come sviluppatore software. È capitata una occasione interessante ed ho pensato che fosse arrivato il momento di mettersi alla prova. Sono molto soddisfatto della scelta. Certo non è stato facile ma un amico (e mentore da un punto di vista professionale) mi ha sempre mostrato l’immagine seguente. Ed io ho deciso di lasciare la mia zona di comfort per andare a vedere la magia là dove essa accade. 

Anche dal punto di vista della ricerca ho dovuto lasciare la zona di comfort. Dopo interventi infruttuosi e vicoli ciechi, abbiamo deciso di cambiare completamente approccio. Fino ad adesso abbiamo considerato Genealogics come la fonte dati principale ed utilizzato le altre (Roglo e Geneagraphie) come integrazione. Questo ha portato ad una serie di interventi che, se da una parte correggevano un’incongruenza, da un’altra parte ne inserivano di nuove con nuovi problemi di grafia dei nomi e di legami mancanti. Con oltre tre milioni di record è facile perdere il filo dopo un po’.
Così, dopo una non breve consultazione via Skype (ormai non vado quasi più in dipartimento), abbiamo deciso di ripartire… da capo! Esatto, dai file di testo estratti (a mano) dalle tre basi dati ed elaborati con una versione migliorata degli script in C# che ho usato, ormai oltre tre anni fa, per la tesi.
Da una parte dispiace che tre anni di lavoro siano serviti solo a creare know-how ma dall’altra è un sollievo uscire dalle pastoie di approcci sbagliati e dalla rigidità di una impostazione dei dati che se, all’epoca della tesi, è stata vincente perché ha permesso di individuare alcuni risultati e di intravederne altri, alla lunga ha dimostrato tutti i suoi limiti. Giusto per fare un esempio, all’epoca decisi di usare il nome come identificativo di ciascun soggetto: niente identificativi numerici univoci o cose simili. Avete idea di che significhi fare una ricerca su milioni di righe usando una stringa di trenta o quaranta caratteri come filtro?
In questa revisione della base dati (eviterò di chiamarla Hochadelsdorf 2.0) abbiamo deciso di adoperare da subito un approccio relazionale: più tabelle, una per ciascuna entità o relazione, collegate tra di loro mediante identificativi numerici. Sulla struttura del database tornerò in seguito perché è ancora in fase di definizione. Al momento sto estraendo i dati dai file di testo e popolando delle tabelle provvisorie; da esse dovrò generare un tracciato dati che metta a confronto le tre fonti e su cui determinare i soggetti corretti da importare nel database relazionale (“il relazionale” è ormai il nome comune per questo oggetto che stiamo andando a creare). La roadmap è definita, il tempo, al solito, è poco ma con le idee chiare sul da farsi si lavora meglio. Speriamo di aver imboccato la strada giusta che dalla comfort zone ci porti a incontrare la magia che in questo progetto, sono sicuro, è ancora tutta da scoprire.

A caccia di muoni

Sono sempre stato affascinato dai progetti di grid computing e di citizen science. Non ho mai sperimentato SETI@home perché la ricerca di forme di vita extraterrestri non rientra nei miei interessi ma, in una fase piuttosto nerd della mia vita, avevo configurato un server per Folding@home, il progetto sullo studio delle proteine dell’Università di Stanford.
Qualche giorno fa ho ricevuto il mio primo numero di Asimmetrie, la rivista dell’Istituto Nazionale di Fisica Nucleare, numero interamente dedicato ai muoni. La rivista, splendidamente realizzata, viene recapitata gratuitamente a tutti coloro che ne fanno richiesta e, pur affrontando tematiche legate alla fisica delle particelle, risulta sufficientemente divulgativa da garantire una piacevole lettura.
Nell’ultima pagina ho trovato il riferimento ad un progetto veramente interessante promosso dal Wisconsin IceCube Particle Astrophysics Center della Wisconsin University denominato DECO (Distributed Electronic Cosmic-ray Observatory).

DECO
In breve si tratta di sfruttare il sensore della fotocamera di un dispositivo mobile per rilevare i muoni derivanti dai raggi cosmici.
Al di là di un interesse amatoriale per la fisica delle particelle, l’entusiasmo è scattato perché i raggi cosmici seguono un processo di branching e quindi rientrano nel mio ambito di studio.
È bastato requisire un vecchio cellulare Android di mia moglie ormai in disuso e istallare l’app del progetto per trasformare la mia soffitta il mio studio1 in un rilevatore di muoni.
Se qualcuno fosse interessato a vedere come me la sto cavando, il link al tracciato CSV è questo: https://deco-web.wipac.wisc.edu/?sensor_id=DECO-ffffffff-fc4b-30b0-4480-0c3100000000&output=csv.

EDIT 10/01/2018: Visti gli scarsi risultati ho pensato di destinare il dispositivo ad altro uso ovvero il testing di applicazioni sviluppate con Thunkable… maggiori dettagli in seguito.


  1. Sembra che, sebbene la soffita sia ad un solo piano di distanza, non sia raggiunta dal wi-fi di casa pertanto l’app non è in grado di trasmettere i dati al server. In attesa di portare la connessione tramite una power line, ho spostato il rilevatore nella libreria dello studio.

A che punto siamo?

E’ passato molto tempo dall’ultima volta che ho scritto su questo blog ma non sono stato inoperoso. Certo il progetto procede un po’ a rilento ma durante l’estate sono state fatte molte correzioni alla base dati e, ad oggi, dovrei essere in grado di integrare i dati con quelli provenienti da un’altra base dati online, operazione che dovrebbe colmare alcune lacune nelle genealogie studiate. Proprio in questi giorni sto valutando l’impatto di questa operazione di integrazione.

Qualche mese fa, il professore mi ha chiesto di dare una mano ad un suo tesista in fisica statistica che sta lavorando sulla cladistica tra famiglie. L’idea era quella di integrare gli alberi genealogici dei capostipiti dell’alta nobiltà con rami sterili e su questi dati condurre varie analisi di tipo statistico. La base dati del progetto Hochadelsdorf poteva quindi costituire un ottimo punto di partenza ma necessitava di alcune elaborazioni. Ho fatto quindi quello che forse avrei dovuto fare fin dall’inizio: trasformare la base dati in una base dati relazionale. Attualmente infatti il database di Hochadelsdorf è una enorme tabella in cui molti dati sono ridondanti. Ho quindi estratto la tabella dei soggetti univoci assegnando ad essi un codice numerico ed ho sostituito, nella tabella delle occorrenze, i nomi con i codici. Poi a ciascun soggetto ho assegnato il codice del padre e quello della madre. In questo modo ho facilitato il lavoro del tesista fornendogli i dati in un formato sicuramente più maneggevole. Magari in un prossimo post entrerò nel dettaglio delle istruzioni SQL adoperate per la trasformazione.

Arrampicandosi sull’albero genealogico

La fine del 2016 è stata un momento decisamente intenso: l’arrivo della piccola prima e il trasloco nella nuova abitazione poi, hanno messo me e mia moglie a dura (ma piacevole) prova. Il trasloco in particolare è stato frenetico e gli scatoloni continuano a dominare il panorama domestico. Nel riordinare alcuni oggetti fragili, diligentemente imballati, a (vana) difesa dalla maldestrìa dei traslocatori, in carta di giornale, mi è capitato tra le mani un articolo del quotidiano locale, a data 18 luglio 2016, dall’occhieggiante titolo “Così ci arrampichiamo sull’albero genealogico”. Sin dalle prime righe appariva evidente il tenore da articolo estivo, tipico di quando i giornali hanno meno contenuti e incaricano qualcuno dei cronisti (in questo caso la giornalista Ileana Reali) di scrivere un pezzo su un argomento di costume, ma sono comunque arrivato in fondo alla lettura. L’articolo spiegava in breve come tentare di ricostruire il proprio albero genealogico con i consueti mezzi: i parenti, internet, gli archivi.
In sostanza un onesto articolo sulla genealogia familiare. Quello che mi ha invece interessato e fatto riflettere è stata la figura a corredo dell’articolo, un disegno realizzato da una maestra, Roberta Bancale, che raffigura sulla sinistra un albero spoglio a cui una bambina appende tre cartellini, “babbo”, “mamma”, “io” e, sulla destra, lo stesso albero con foglie e fiori. Mi ha ricordato il modo di procedere nella realizzazione della base dati di Hochadelsdorf: i rami ci sono tutti e sono i codici Sosa presenti nella base dati (dovrò decidermi prima o poi a scrivere qualcosa sul sistema Sosa-Stradonitz); quello che, in parte, manca sono le foglie e i fiori ovvero i soggetti giusti al posto giusto. L’opera (apparentemente infinita) di completamento che sto portando avanti assomiglia alla bambina che appende i cartellini in attesa che l’albero fiorisca. In questo momento anche la mia ricerca sta affrontando un lungo e freddo inverno ma confido in una rigogliosa primavera, che porti finalmente qualche fiore al progetto, e in una estate ricca dei tanto attesi frutti.
Concludo con una citazione della storica francese Christiane Klapisch Zuber, riportata in testa al citato articolo.

“L’albero durante i secoli ha rappresentato quel grande corpo che è un lignaggio, una discendenza. Come l’albero, una famiglia nasce, si sviluppa, si ramifica, si secca. Le rappresentazioni della parentela hanno utilizzato fin da tempi molto antichi questa metafora che si è poi fissata in una immagine: l’albero genealogico”.

Un mese con Azure

Come già anticipato nel post precedente, ho spostato (o meglio copiato) la base dati del progetto su Azure ed ho cominciato ad usare i servizi cloud di Microsoft. Al termine del primo mese di utilizzo posso fare un primo bilancio di costi, qualità e usabilità della piattaforma.

Sono sempre stato un po’ scettico su Azure sia a causa di una prima non positiva esperienza quando il servizio era ancora agli esordi e quindi non esattamente intuitivo nell’utilizzo, sia per la paura di una tariffazione oscura ed incontrollabile.

A distanza di qualche anno da questa prima esperienza, Azure ha raggiunto una completezza e chiarezza di servizio, supportata da una interfaccia utente intuitiva e potente, tale che l’utilizzo risulta agevole fin dai primi approcci.

Le diffidenze verso la tariffazione sono state vinte grazie alla sottoscrizione DreamSpark ottenuta tramite l’email (da studente) dell’Università che consente l’utilizzo gratuito di diversi servizi. In realtà, con la sottoscrizione DreamSpark si fa ben poco, soprattutto a livello di database, ma è servita come chiave di ingresso nel mondo di Azure. Appena mi sono reso conto che il servizio poteva essermi utile, ho cercato di espandere le possibilità di utilizzo e mi sono ricordato che come sviluppatore Microsoft, tramite il programma Dev Essentials, potevo avere diritto, per un anno, ad un credito mensile pari a 25 euro. Restava da verificare cosa fosse possibile fare con 25 euro/mese.

azure_novembre

Il grafico, estratto dalla dashboard del mio account Azure, mostra il consumo di credito nel primo mese ed appare evidente che non ho esaurito il credito malgrado l’uso intensivo e gli errori di configurazione dati dall’inesperienza.

Come prima cosa ho creato un database SQLServer analogo a quello locale del progetto. Ho scelto una configurazione con un numero di DTU (che sono le unità di elaborazione dei database Azure) non troppo basso perché dovevo trasferire qualche milione di righe solo per creare la base dati e la sottoscrizione DreamSpark, con solo 5 DTU, era andata immediatamente in saturazione. Ho scelto la soluzione da 10 DTU che si è rivelata sufficiente alle operazioni necessarie al trasferimento dei dati ma anche all’elaborazione delle interrogazioni. Azure inoltre, in base all’utilizzo del database, suggerisce ed applica ottimizzazioni alle tabelle e alle query.

Ho usato il database per alcuni giorni notando che il consumo di credito era abbastanza irrisorio e che l’utile proiezione del grafico preannunciava che avrei terminato il mese con oltre metà del credito disponibile.

Ho deciso di creare quindi anche una macchina virtuale da usare collegato in Remote Desktop per accedere al database da dispositivi privi di software specifico. Le macchine virtuali generiche Windows 10 sono riservate ai sottoscrittori MSDN ma è sempre possibile creare una macchina con Visual Studio. Il sistema operativo, in questi casi, è una versione server di Windows, in particolare Windows Server 2012 R2. Qui ho commesso un errore: nel creare la macchina virtuale, il sistema suggerisce due configurazioni abbastanza carrozzate in termini di RAM e processore ma con tariffe alte. Confidando in un utilizzo saltuario, ho scelto una di queste senza notare il link “mostra tutte”. Nel grafico, questa scelta corrisponde alla drastica e rapida riduzione del credito. Dopo aver notato che, malgrado un uso veramente minimo, il credito calava vertiginosamente, ho distrutto e ricreato la macchina virtuale usando un diverso piano tariffario, riducendo la RAM a 1.75GB e usando un processore mono core. Il grafico del consumo, a quel punto, ha ripreso un andamento più rassicurante. La cosa positiva da notare è che molte delle operazioni di creazione di servizi (siano essi database o macchine virtuali) è intuitiva e veloce.

Una sola accortezza è necessaria nell’uso delle macchine virtuali di Azure: non basta spegnerle per ridurre quasi a zero il consumo, vanno deallocate. In pratica, oltre a spegnere la macchina occorre spegnerla anche dalla piattaforma e poi deallocarla premendo nuovamente sul pulsante arresta della propria area di gestione. In alternativa è possibile configurarsi uno script PowerShell da lanciare dalla propria dashboard. Come stima grossolana, un’ora di utilizzo di una macchina virtuale di queste dimensioni costa circa 0.20 euro.

Dal punto di vista della qualità del servizio c’è poco da dire, Azure funziona alla grande e fornisce quasi out of the box moltissimi servizi. Per il progetto che sto portando avanti, ho configurato un database replica di quello ufficiale e una macchina per lo sviluppo e l’interrogazione della base dati in pochissimo tempo e con una spesa abbordabile. Inoltre non devo preoccuparmi di configurazioni del sistema, di hardware (e relativi guasti) e, soprattutto, di backup.

In conclusione, grazie alla sottoscrizione Dev Essentials, godrò per un anno di un ambiente di lavoro potente, raggiungibile da ovunque e sicuro. Al termine della sottoscrizione, molto probabilmente, deciderò di stanziare un fondo per l’uso della piattaforma, magari limando ancora un poco le risorse per contenere ulteriormente le spese anche se sono convinto che la comodità di un sistema come quello che ho configurato su Azure non abbia prezzo.

Nella nuvola

L’arrivo di mia figlia ha rivoluzionato in positivo, tra le tante cose, anche i tempi e gli spazi della mia ricerca. L’ora quotidiana dedicata al progetto, in genere dalle 6 alle 7 dei giorni feriali, è adesso dedicata alla preparazione dei biberon, al cambio dei pannolini o, se va bene, al recupero di qualche momento prezioso di sonno.

Ho deciso quindi di cambiare l’approccio e questo mi ha permesso di sperimentare strumenti interessanti distribuiti sul cloud. L’esigenza è stata quella di avere i dati sempre disponibili in modo da poter lavorare in qualunque momento e da qualunque postazione. E’ stata quindi l’occasione per sperimentare i servizi di Microsoft Azure che da tempo mi incuriosivano ma verso i quali nutrivo sempre una certa diffidenza. L’account DreamSpark ottenuto tramite la email dell’Università non mi consentiva di fare molto a causa delle sue limitazioni. Per fortuna, il programma Dev Essentials fornisce agli sviluppatori un credito mensile di 25 euro, sufficiente a creare un database abbastanza grande da ospitare i dati del progetto. Ho così creato una copia della base dati su Azure in modo da averla sempre disponibile. Per il momento, storage e uso non intensivo di un database di circa 500MB mi costano circa 0.35 euro al giorno, abbondantemente dentro i limiti del credito concessomi.

L’interrogazione della base dati avviene attraverso i medesimi strumenti usati per la versione locale (ovvero SQLServer Management Studio) ma adesso ho il vantaggio di poter lavorare in mobilità che significa durante la pausa pranzo o nei tempi morti di altre attività. Per questo ho istallato anche una app sullo smartphone (SQL Server Metro) anche se l’utilizzo è limitato a qualche interrogazione di controllo dati.

In realtà lo strumento che avrei voluto usare in mobilità sarebbe dovuto essere il netbook convertibile Asus VivoTab ma mi sono scontrato con le grosse limitazioni del sistema operativo Windows RT. L’unica app (a pagamento!) disponibile per questo sistema che possa interfacciarsi con SQL Server non funziona con l’ultima versione di Azure SQL Server e l’ho scoperto a mie spese. Con questa versione di SQL Server non è possibile neanche utilizzare il management online, funzionante fino alla precedente versione. Proverò il servizio Azure RemoteApp sperando di rimanere nei limiti del credito, ammesso che funzioni. E’ un vero peccato perché con queste giornate di caldo, su una panchina durante la pausa pranzo, avrei lavorato veramente bene!

Comunque sia, aver decentralizzato i dati copiandoli nel cloud mi sta dando una maggiore libertà di gestione in termini di luogo e tempo di lavoro oltre a fornirmi una copia sicura di backup (oltre a quella su dispositivo rimovibile). Come spesso accade, soprattutto a me, una apparente (e in questo caso piacevole) limitazione è motivo per apprendere cose nuove, sperimentare, tentare con tenacia di superare i limiti del mezzo tecnologico. Una sfida nella sfida che rende tutto molto più avvincente.

Edit (09/11/2016):
Azure RemoteApp non è più supportato, l’unica alternativa valida è stata creare una macchina virtuale su Azure con istallato SQL Server Management Studio ed accedere a quella in Desktop Remoto.

Leo van de Pas (1942 – 2016)

Mercoledi 17 Agosto 2016 è morto Leo van de Pas, ideatore e curatore del sito genealogics.org una delle più vaste e attendibili banche dati di genealogie disponibile in rete. Un lavoro titanico, come ho avuto modo di sottolineare più volte, messo a disposizione degli studiosi, condotto con rigore scientifico ed in costante aggiornamento. Con la morte di van de Pas il sito rimane attivo anche se in “modalità manutenzione” ovvero non sarà soggetto ad aggiornamenti ma solo alla correzione di eventuali errori.

Il progetto Hochadelsdorf deve moltissimo a questa base dati che costituisce la fonte principale (anche se non l’unica) dei dati che stiamo elaborando. Per questo motivo, ritengo giusto rendere onore a questo studioso e al lavoro che ha fatto. Grazie Leo!

Delusioni

Quando sembrava che il lavoro di disambiguazione della base dati fosse concluso, un nuovo processo di analisi basato questa volta non sulle coppie ma sugli “orfani” (soggetti con genitori sconosciuti) ha messo in luce una serie consistente di buchi nelle genealogie. In pratica alcuni soggetti, e non pochi, hanno i genitori noti nella maggior parte delle occorrenze nel database ma non in tutte. Queste occorrenze nelle quali il soggetto risulta figlio di ignoti (anche se i genitori sono conosciuti) crea dunque una serie di interruzioni negli alberi e soprattutto una mancata corrispondenza tra soggetti. La causa sembrerebbe essere l’integrazione di alcuni alberi con dati provenienti da altre fonti ma quello che conta, adesso, è trovare un algoritmo in grado di rimettere a posto i genitori.

Progressi

Il lungo silenzio su queste pagine è dovuto all’enorme lavoro di disambiguazione effettuato sulla base dati di Hochadelsdorf. Per disambiguazione intendo l’individuazione di soggetti che, pur essendo la stessa persona, compaiono con nomi diversi nella base dati. Il fenomeno è dovuto alla provenienza dei soggetti da fonti diverse o più semplicemente a grafie diverse dello stesso nome. Risolutiva, in questa poderosa caccia all’intruso, è stata l’ideazione di un processo di analisi che si basa non sui singoli individui ma sulle coppie. Associando ciascun soggetto al suo o ai suoi coniuge/i è stato più agevole scovare i falsi doppi e ricondurli ad una grafia unica. Il lavoro manuale è stato considerevole ma l’estrazione automatica di questo tracciato di controllo ha fatto sì che potessimo procedere per approssimazioni successive fino alla completa (o almeno ragionevolmente tale) bonifica della base dati. L’intera operazione ha richiesto oltre un anno di lavoro anche se c’è da dire che, per me, non è certo un lavoro a tempo pieno e non è stato facile individuare di tempi adeguati per essere portato a termine. L’esito positivo dell’ultimo controllo effettuato mi ha fatto tirare un sospiro di sollievo anche se sono consapevole che ci sono ancora molte fasi da affrontare prima che la base dati sia veramente adatta allo scopo della ricerca che ci siamo posti.

Sul blogging accademico

Qualche settimana fa sono stato contattato dalla giornalista Alessia Smaniotto, responsabile della comunicazione per il progetto OpenEdition Italia (l’infrastruttura che sviluppa Hypotheses.org e che ospita questo blog), con lo scopo di raccogliere materiale per un breve articolo di presentazione dei blog italiani attualmente attivi su Hypotheses.org. Genealogy Cruncher è stato uno dei blog prescelti ed ho avuto occasione di riflettere sulla genesi, sulle finalità e sul ruolo, in un panorama più ampio, di quanto ho scritto fino ad ora e scriverò in seguito in questo pubblico spazio.

Il contatto è stato fortunoso perché i filtri antispam, per un eccesso di zelo, avevano pensato bene di mettere la mail della Smaniotto nella posta indesiderata e solo il caso ha voluto che io andassi a curiosare nel bidone della spazzatura, cosa che faccio di rado ma che può riservare, a volte, delle sorprese.

Così, dopo un breve scambio di email, ho risposto alle domande e le risposte non solo hanno contribuito alla stesura dell’articolo principale ma sono state pubblicate interamente in un altro articolo esclusivamente dedicato a questo blog.

I links a cui è possibile leggere i due articoli sono:

Cinque storie di blogger italiani su Hypotheses.org

Il blogging al servizio della ricerca sulle genealogie della nobiltà europea

Se comunico solo adesso in questa sede l’uscita dei due articoli è solamente perché, nell’ultimo periodo, il progetto Hochadelsdorf ha assorbito tutte le mie energie. La normalizzazione della base dati tesa ad uniformare i soggetti univoci presenti con due diversi nomi è stata una operazione lunga e complessa ma assolutamente necessaria. Prosegue al momento il lavoro sulla identificazione dei MRCAs (Most Recent Common Ancestors) che dovrebbe costituire una parte importante di un futuro articolo sull’argomento.

Close the semantic gap

According to Wikipedia, “Scientists include theoreticians who mainly develop new models to explain existing data and experimentalists who mainly test models by making measurements – though in practice the division between these activities is not clear-cut, and many scientists perform both.” The domain-specific language that many scientists use to define their models is mathematics, and since the early days of computing science, the holy grail has been to close the semantic gap between scientific models and executable code as much as possible. It is becoming increasingly clear that all scientists are practicing applied mathematics, and some scientists, such as theoretical physicists, are behaviorally indistinguishable from pure mathematicians. The more we can make programming look like mathematics, the more helpful we make it to scientists and engineers.

Erik Meijer, prefazione a D. Syme, A. Granicz, A. Cisternino “Expert F#”, Apress 2007

Calcolo dell’età

Può capitare, lavorando con le genealogie ma anche studiando fenomeni come le dinamiche di reclutamento, di dover calcolare l’età di un soggetto, di cui si conosca la data di nascita, sia rispetto alla data odierna, sia rispetto ad un’altra data di riferimento.

Qualche tempo fa, in un mio lavoro sull’età di inizio professione da parte di alcuni soggetti operanti nel mondo giudiziario, disponendo di un database MySQL, avevo applicato con successo la seguente interrogazione:

SELECT YEAR(DATE_FORMAT([dataInizio], '%Y­%m%d')) ­- YEAR(DATE_FORMAT([dataNascita], '%Y­%m%d')) ­- (DATE_FORMAT([dataInizio], '%m%d') <  DATE_FORMAT([dataNascita], '%m%d')) AS eta  FROM [tabella]

In pratica, per calcolare l’età di inizio professione, si è proceduto facendo la sottrazione tra l’anno di inizio professione e l’anno di nascita e si è sottratto 1 qualora giorno e mese di nascita fossero successive, rispetto all’anno solare, a giorno e mese di inizio professione. Questa formula può essere scritta

anno(data inizio) – anno(data nascita) – (giorno e mese inizio < giorno e mese nascita)

in considerazione del fatto che, in MySQL, il confronto produrrà un esito booleano che sarà interpretato come 0 (falso) o 1 (vero) andando a togliere tale valore dal risultato della sottrazione iniziale.

Sicuramente non è l’unico metodo e forse neanche il più immediato tuttavia non manca di eleganza.

Ho tentato di convertire le istruzioni nella sintassi di SQLServer, database che sto usando attualmente per il progetto Hochadelsdorf.

Al posto dell’istruzione DATE_FORMAT, ma solo a partire dalla versione 2012 di SQLServer, quella usata dal progetto, è possibile fare uso dell’istruzione FORMAT che accetta in ingresso un valore, un pattern di formattazione e una indicazione di cultura.

E’ possibile quindi riscrivere l’interrogazione con la seguente sintassi:

SELECT DATEPART(YEAR, [data_inizio]) - DATEPART(YEAR, [data_nascita]) - CASE WHEN FORMAT([data_inizio],'MMdd','it-IT') < FORMAT([data_nascita],'MMdd','it-IT') THEN 1 ELSE 0 END AS eta FROM [tabella]

ottenendo lo stesso risultato.

Al momento non so se questa interrogazione sarà necessaria nella mia ricerca ma ritengo utile condividerla, anche solo come promemoria per uso futuro.