Software iDAIfield

Ciao a tutti,

Vorrei presentarvi un nuovo progetto appena partito al CoDArchLab dell’Università di Colonia, finanziato, gestito e coordinato dal Deutsches Archäologisches Institut.

Stiamo lavorando su un software chiamato iDAIfield 2. Qui trovate una breve descrizione della prima versione in tedesco.

In sintesi, stiamo cercando di sviluppare un programma open source per gestire i dati di scavo in maniera efficiente, centralizzata e consistente, con componenti web-based (come la sincronizzazione tra client diversi). L’obiettivo finale sarebbe ottenere un’unica piattaforma in cui si fondono dati raster e vettoriali, i numerosi database di uno scavo archeologico, matrix e un’interfaccia grafica dinamica.

Abbiamo appena cominciato e il gruppo di lavoro non è molto grande, anzi. Ho chiesto ai programmatori con cui collaboro di aprire un canale di confronto, cercando di ottenere più informazioni e opinioni possibili anche in questa fase iniziale. Molti di voi hanno già affrontato problemi simili e sono sicuro che ci potreste dare ottimi suggerimenti. Vi farebbe piacere aiutarci? Grazie.

Vi propongo un primo quesito, in particolare a @steko che ne ha parlato qui su Twitter qui:

Qual è il data model che considerate migliore per un software che si occupa dei dati di scavo? Abbiamo parlato di Erlangen CRM, ma ci chiedevamo se ne esistessero altri e di qualità migliore.

Penso che Erlangen condivida gli stessi problemi di CIDOC (essendone una trasposizione in formato OWL), ha un approccio molto generico che secondo me è più adatto alla gestione museale che non allo scavo.

Comunque ti segnalo questi vecchi lavori di Andrea D’Andrea:

• http://www.taed.unifi.it/eah-management/main/seminario27_01_06/Andrea_firenze_27012006.ppt
• https://www.academia.edu/1647016/Ontological_modelling_for_archaeological_data

che affrontano questo tipo di problematiche.

È molto raro, anche in contributi specifici sul tema della gestione dei dati di scavo, trovare una definizione esplicita del modello dati.

Ti ringrazio per la risposta, è già meglio di una discussione libera sul tema. Posso dedicare davvero poco tempo a questo progetto ora e sembra che fra un mese non debba proprio più occuparmene. Le priorità decise sono altre per il momento.

Mi piacerebbe avere però un contributo da parte di @pyArchInit se possibile, anche se non ho avuto il piacere di conoscerlo personalmente. Ho visto l’ERD sul sito del software e mi sembra fatto molto bene, ma abbiamo optato per una struttura diversa dato che non siamo legati a QGIS. Per esempio, abbiamo deciso di collegare gli oggetti ad un progetto, piuttosto che ad un sito, che a sua volta sarà collegato al progetto.

Stiamo ancora progettando il resto, ad esempio come suddividere reperti e US. I programmatori propendono per un approccio dinamico, cioè la creazione di oggetti il più possibile unici, che poi vengono presentati in maniera diversa all’utente a seconda del tipo di oggetto che viene scelto. Voi che ne pensate?

Ho ritrovato per caso anche alcuni spunti che possono essere interessanti in questa discussione del 2012, dai toni forse un po’ troppo accesi (faccio mea culpa), ma molto approfondita tra me e @dandrea riguardo alle ontologie e loro problemi (non solo tecnici).

Molto interessante, ti ringrazio. Stavo riflettendo proprio su questi problemi riguardo ad Arachne, che è un’enorme collezione di dati, ma che soffre di problemi interni al database.

Mi rendo conto che arrivo tardi nel dibattito e avrei dovuto seguirlo già qualche anno fa. Non mi soffermo sulla questione software libero sì, software libero no, che è complessa. Condivido molte delle riflessioni che hai espresso e aggiungo solo un pensiero personale.

L’unico ente in grado di imporre una pratica o un tentativo di normalizzazione è a mio parere il MIUR in Italia, che ha il potere e l’autorità per ottenere un risultato del genere. Come del resto è stato per il metodo stratigrafico, che era usato da Nino Lamboglia fin dagli anni ’30-’40, ma che è stato imposto solo negli anni ’70.

Ci vorrebbe però un ulteriore passaggio: l’apertura degli archivi di scavo. Ora il MIUR tutela più il diritto allo studio rispetto al diritto alla fruizione dei dati. Se chi ha il diritto allo studio non ottempera ai propri doveri, tra cui dovrebbe esserci il salvataggio in formato digitale, i dati dovrebbero essere resi accessibili a tutti. A questo punto, come hai detto bene tu, sarebbe importante che si adottassero delle linee guida semplici ed accessibili per poter digitalizzare velocemente i dati raccolti.

CIDOC-CRM nella sua estensione per lo scavo, CRM-archaeo, non risponde al criterio di semplicità. Gli informatici che lavorano al database hanno rinunciato fin da subito ad usarlo, perché senza delle linee guida di applicazione non è possibile implementarlo velocemente. Non credo sia un aspetto da sottovalutare.

Credo che non sia semplice soddisfare le esigenze di tutti e contemporaneamente ogni possibilità di registrazione di oggetti che troviamo nel nostro lavoro. Dovrebbe essere il MIUR a centralizzare la questione e dialogare con tutti, in modo da soddisfare le esigenze di chi lavora nel nostro campo. Tutto a mio modesto parere.

Scusate ragazzi, mi ero perso questa mail.

Do una risposta volante che ho un botto di arretrati di lavoro.

In sostanza noi abbiamo un ERD concettuale ma pyArchInit non ha un DB legato a Qgis e le tabelle non “Sono legate tra di loro”. E’ pensato anche per vivere al di fuori di Qgis con piccole modifiche.

Vuoi legare i reperti al progetto? Benissimo diciamo in 8 ore facciamo la scheda Progetto e tu leghi con in join e le view tutte le tabelle che vuoi. Dal momento che siamo una ditta e lavoriamo con vari ispettori, ognuno ci chiede regole diverse, quindi non creiamo legami trami primary key e foreign. Il Management System è devoluto alle riunioni della ditta con i singoli progetti.

Scusate la fretta, torno al lavoro e spero che possiamo continuare a ragionare…Magari facciao un exporter pyArchInit verso il vostro sistema e viceversa.

Ciao
Luca

Grazie Luca per la risposta. Nel frattempo gli informatici sono andati avanti, ma io non ho potuto seguire il progetto. La prossima settimana mi diranno anche se potrò restare in laboratorio o meno e vi aggiornerò sull’avanzamento.

Vi posso dire però che abbiamo già trattato la questione della conversione da altri tipi di database. Gli informatici hanno deciso di usare un database NoSQL, credo che sia CouchDB, ma non me lo ricordo con precisione. A proposito delle conversioni, mi hanno detto che per essere efficienti si devono adattare alla struttura del database e che quindi lavorerebbero con script personalizzati. Vi aggiornerò al più presto anche su questo.

Io mi sono arrovellato anni su come fosse meglio impostare un database, come tutti del resto. Ricordo un software inglese, di cui mi sfugge il nome. In sostanza non aveva una struttura ad entità definite e senza relazioni, che venivano create dall’utente. Provai a fare un prototipo banalissimo con Filemaker ma mi accorsi che gli utenti a cui lo proponevano alla fine mi segnalavano che perdevano più tempo a capire il concetto di utilizzo, mentre una scheda “secca” di reperti, diciamo anche molto monolitica, era più veloce e immediata.
Qui si apre ovviamente un mondo perchè da un lato hai una normalizzazione del linguaggio e una fruibilità maggiore da parte di più utenti e una indubbia perdita di flessibilità che porta alla perdita di eventuali dati generati deducibili solo dall’incrocio con altri dati, dall’altro hai un prodotto più veloce e semplice da aggiornare ed ampliare tramite riunioni e piccole session di adattamento.

Rimango in casa mia con pyArchInit. Ha un DB banalissimo, dove addirittura per limiti miei ho rinunciato ad una parte relazione rigorosa, dall’altro so per certo che in 10 anni, ci abbiamo schedato qualche centinaio di scavi e nessuno ha mai sentito la necessità di portare variazioni sostanziali. Pensate in 10 anni nessuno ha mai avuto bisogno di fare una ricerca del tipo : US 1 taglia 3 … quindi ho rinunciato a creare una sezione di ricerca per i rapporti stratigrafici.

Io stesso per la tesi persi un annetto o due a cercar di capire cosa fosse “un reperto”, perchè a secondo del taglio che ogni studioso dava alla propria ricerca il medesimo oggetto “scavato” assumeva molteplici identità relazionali; un esempio: un vespaio di laterizi e frammenti di anfora. Nelle US erano matrice di strato, per i ceramologi singoli reperti, per gli archeometristi avevamo le sezioni per le analisi, per il restauratore divenivano oggetti di schedatura della scheda di restauro e così via.

Quindi un DB che ti permette di creare entità singole a seconda della necessità è chiaramente il santo Graal, ma per l’archeologia quotidiana (odio chiamarla di emergenza dato che avviene in regime di preventiva) dove si arriva fino ad un certo livello di schedatura tende ad essere un pachiderma mal gestibile.

La cosa bella, a mio modestissimo parere sarebbe far convivere i due modelli: schede monolitiche che ti guidano nella prima schedatura e un ambiente superiore per l’analisi scientifica dove puoi andare a scomporre il dato in più entità dandoti 2 possibilità: - creare un potente motore di ricerca, -creare infinite modalità di analisi quantitative e statistiche.

Non mi sono mai avvicinato ai DB NoSQL, per un piccolo motivo, che io ritengo basilare: continuo a incontrare nelle PA database SQL (vuoi Oracle o PostgreSQL) e tantissimi privati che fanno uso di SQL. Questo mi permette di avere tantissimi utenti a livello mondiale che hanno già risolto il 99.9% dei problemi che mi si presentano.

Mi sfugge il concetto della tua permanenza in laboratorio; vuoi dire che nn farai più parte del gruppo di Sviluppo?

Ciao
Luca

Io lavoro al CoDArchLab di Colonia in questo momento e partecipo a più progetti: il principale è iDAIvocab, il secondo, su mia richiesta, è iDAIfield. Non si capisce bene se ad aprile il mio contratto verrà rinnovato per via di questioni finanziarie a Berlino e avrò di conseguenza meno tempo per dedicarmi allo sviluppo del software. Per ora sto assistendo gli informatici come archeologo.

Hai ragione, non è semplice. Abbiamo affrontato le questioni di cui parli. La scelta è ricaduta su un database NoSQL ad oggetti proprio per evitare di dover aggiungere tabelle su tabelle e relazioni rigide, fino a renderlo una matassa inestricabile, dato che si dovrà adattare a vari tipi di attività (l’esperienza di Arachne ha insegnato loro molto). I ragazzi hanno deciso quindi di impostare un’interfaccia dinamica su degli oggetti predefiniti, su cui poi impostano le relazioni.

Stiamo anche sviluppando le relazioni tra gli oggetti, comprese le relazioni stratigrafiche (evitando in questa fase la semplificazione anglosassone below/above e impostandole sulla scheda dell’ICCD). La soluzione al dilemma del reperto o strato che abbiamo trovato è inserire due oggetti separati e poi equipararli e collegarli. Insomma, puntiamo al Santo Graal, vedremo se ci arriveremo.

È vero che diventa meno gestibile in questa maniera, ma siamo in una fase molto precoce di sviluppo e può essere tutto rivoluzionato in corso d’opera.

Per onestà aggiungo che io non ho scritto una sola riga di codice, la gran parte del lavoro è tutta del gruppo degli informatici.

Esattamente… per poter creare un reperto nel DB sarebbe necessario schedare singolarmente ogni frammento separatamente e infine collegarli tra loro… Ma questo ha un difetto: aumenta esponenzialmente l’errore umano di “errato” collegamento o “errata digitalizzazione” … pensa nella mia tesi ho riscontrato che 25.000 rapporti stratigrafici circa il 60% degli errori era dovuto banalmente ad errata digitalizzazione: che ne so : 21 al posto di 12.

Che bello che puoi partecipare ad un progetto simile… io ho mestamente portato un progetto di Geodatabase collegato ai google glass per avere in realtà aumentata le info dei palinsesti storici e collegare i professionisti di vari settori tra di loro … ma mi hanno detto che non ne capivano l’utilità … ora l’ordine degli ingegneri stanno realizzando la cosa … ora mi deprimo … anzi … mi sparo un bel Luca = None

Spero tantissimo che ti rinnovino il contratto e tu possa lavorare al progetto.

So anche che Vittorio Fronza di Siena e Luca Altilia stanno sviluppando un WEBgis per l’archeologia con un DB NOSQL . Magari se li contattate, se non lo avete già fatto, potete incrociare le informazioni.

Ciao
Luca

Intanto, grazie mille per le informazioni e il supporto Spero anch’io che mi rinnovino il contratto, il progetto mi piace parecchio, ma la decisione purtroppo non spetta a me. Da parte mia, continuerò a lavorarci anche se non pagato, proprio perché lo trovo interessante e formativo.

Esattamente… per poter creare un reperto nel DB sarebbe necessario schedare singolarmente ogni frammento separatamente e infine collegarli tra loro… Ma questo ha un difetto: aumenta esponenzialmente l’errore umano di “errato” collegamento o “errata digitalizzazione” … pensa nella mia tesi ho riscontrato che 25.000 rapporti stratigrafici circa il 60% degli errori era dovuto banalmente ad errata digitalizzazione: che ne so : 21 al posto di 12.

Come ti dicevo, le cose cambiano in fretta dall’ultima volta che ho discusso con i programmatori. Il database implementato nel software è Elasticsearch, un database a documenti con funzioni avanzate di ricerca. In riferimento al problema dei duplicati di cui mi hai parlato, stanno cercando di implementarlo in modo da evitare la duplicazione dei singoli oggetti, ma di lavorare direttamente sull’oggetto aggiungendo ogni volta i dati necessari. Ogni oggetto quindi non apparterrà ad una singola classe (come avviene per forza in un database SQL), ma ci saranno oggetti predefiniti a cui si possono aggiungere successivamente le caratteristiche necessarie per usarlo in altre funzioni. Quindi uno strato potrebbe diventare un reperto, anche se l’oggetto predefinito a cui faceva riferimento non lo prevedeva. Si sposta il problema sulle funzioni di ricerca, ma rende molto più semplice la progettazione.

So anche che Vittorio Fronza di Siena e Luca Altilia stanno sviluppando un WEBgis per l’archeologia con un DB NOSQL . Magari se li contattate, se non lo avete già fatto, potete incrociare le informazioni.

https://github.com/scarpazi/oa2

Ho appena mandato un’email al prof. Fronza, ogni volta che ci ho parlato è sempre stato molto gentile. Mi aveva parlato del webGIS nel 2012, ma me n’ero dimenticato. Il GIS è una parte che per ora i programmatori non vogliono sviluppare e mi sembra che ci siano tutti i presupposti per condividere gli obiettivi.

Che bello che puoi partecipare ad un progetto simile… io ho mestamente portato un progetto di Geodatabase collegato ai google glass per avere in realtà aumentata le info dei palinsesti storici e collegare i professionisti di vari settori tra di loro … ma mi hanno detto che non ne capivano l’utilità … ora l’ordine degli ingegneri stanno realizzando la cosa … ora mi deprimo … anzi … mi sparo un bel Luca = None

Mi dispiace per il tuo progetto, che mi sembra una proposta valida (come si è dimostrato poi). Io ho riflettutto su qualcosa di simile, ma senza realtà aumentata: un geodatabase topografico che permetta di fare ricerche sulle strutture e i loro metadati (esempio: cerca tutte le strutture in legno di 5 m² di forma rettangolare), ma esteso a numerosi siti italiani e non. Insomma, a cosa ci servono tutti questi dati se poi non riusciamo a fare confronti se non con lunghe ricerche in biblioteca? Peraltro, in Arachne c’è già qualcosa di simile, ma solo per le immagini e non per i dati vettoriali. Hai pensato di proporlo al Google Cultural Institute? Sto sognando ad occhi aperti, ma sarebbe davvero bello e con un team di persone interessate potrebbe essere possibile.

Doerr, quando ha creato CIDOC ha voluto risolvere due problemi specifici: rendere “traducibile” una banca dati in un’altra (grazie alle triplette) e fare uno strumento “per gli oggetti tangibili inclusi in una collezione museale”. Gli utilizzi successivi sono stati adattamenti: hanno creato un effetto “palla di neve” che ha aggiunto relazioni e classi rendendo il sistema tento completo quanto inutilizzabile. E’ oltre tutto davvero difficile confrontarsi con chi usa CIDOC per creare banche dati perché nella maggioranza dei casi si tratta di ricercatori che non usano lo strumento sul campo, si occupano solo di implementarlo. Ad ogni modo, nel frattempo, sono state proposte altre ontologie più “ampie” nello scopo e che coprono, fra le altre cose, aspetti archeologici. Sul piano teorico, un esempio interessante è CHARM, il quale offre anche un modello dati per lo scavo stratigrafico. Sul lato pratico, molto interessanti sono i database NOSQL (ad esempio Neo4j - che ha una community edition subito utilizzabile) che ben si sposano con l’ontologia CHARM. Purtroppo è dura anche solo contraddire l’utilizzo di CIDOC…

Ad un livello completamente astratto e accademico, questo è in parte vero, ma ti garantisco che nell’insieme ristretto degli addetti ai lavori che sanno cosa sia CIDOC, ben pochi lo ritengono utile o addirittura lo usano. Anche perché dopo tanti anni è ancora una soluzione in cerca di un problema. Nel frattempo tutti avremmo beneficiato dell’esistenza di vocabolari condivisi, che sono stati creati in modo organico dalle iniziative più disparate e negli ultimi tempi stanno in parte lentamente convergendo.

Non parliamo nemmeno delle migliaia di archeologi che ogni giorno producono dati sul campo e in laboratorio, che giustamente non sanno nemmeno cosa sia CIDOC né saprebbero cosa farsene.

sono pienamente d’accordo !