Perché un modello concettuale per gli archivi può essere utile

Questo blog post nasce in realtà da un commento che stavo scrivendo a un post sul blog archimacerata. Ma la risposta stava diventando troppo lunga e con troppi riferimenti per un commento e inoltre non ho capito come registrarmi per commentare a seguito della nuova policy del blog 🙂

Dunque si parlava di un modello concettuale per gli archivi e della sua utilità, in particolare sulla sua utilità per riuscire a scambiarci i dati fra i mille(mila) sistemi, software italiani dove ognuno (pur nel rispetto degli standard) fa quel cavolo che gli pare. Scrive infatti Pierluigi Feliciati:

E poi, siamo sinceri, credi davvero che la disponibilità di una base concettuale più solida (e chi deciderà quando sarà arrivato il momento?) olierebbe la strada per una effettiva collaborazione tra gli stakeholders, se il quadro dovesse essere sempre quello attuale? Continua a leggere

Sull’uso di EAD e sullo sviluppo di un modello concettuale per gli archivi

WARNING: Post molto lungo (e essendo uno stream of consciousness non esente da errori)

Sulla mailing list Archivi23 si è scatenato un’interessante dibattito (con annesse polemiche forse meno interessanti) sull’uso e il senso di EAD.

Chiara Veninata (dell’Archivio centrale dello stato) a un certo punto dice:

Rispetto ai vantaggi però
di utilizzare uno standard internazionale così diffuso come formato
interno dei dati  – il fatto che gli strumenti di corredo siano stati
“creati” o siano stati trasformati successivamente davvero poco
importa se si sta parlando tout court  delle capacità descrittive di
un modello dati –  mi sembra che ci sia poco da discutere

Mi spiace estrapolare una frase dalla sua lunga mail, ma spero di non travisarne il concetto e partire da qui per una riflessione sul senso di EAD e sulla mancanza di un modello concettuale per gli archivi (cosa di cui mi sembra si stia iniziando a discutere nell’hinterland dell’ICA e su cui tutti, io in primis, dovremmo riflettere).

Dunque si parlava del fatto che EAD rappresentasse dal punto di vista di Chiara un “modello di dati” valido per rappresentare la descrizione archivistica e questa sua validità fosse attestata dall’uso in diversi progetti [che io definirei minoritari rispetto al totale delle descrizioni archivistiche, ma sembra che “minoritari” sia letta come offesa] e che molti di questi progetti fossero recupero di strumenti di corredo cartacei non importasse nella valutazione del modello di dati proposto.

Ciò a me fa scattare alcuni campanelli d’allarme. Probabilmente ciò è dettato dal mio imprinting da topic mappers, ma per me il modello dei dati è (uhm forse meglio dire dovrebbe essere) indipendente dal linguaggio di serializzazione scelto. Nelle Topic Maps abbiamo un modello di dati (TMDM) e poi lo si può serializzare come lo si vuole, tu vuoi esprimerlo in XML? eccoti XTM, ma anch TMXML! Tu preferisci un formato testuale compatto? Eccoti LTM o CTM. Tu vuoi serializzarlo in un comune database? Fai pure. Tu vuoi esprimerlo con un database nosql? Perché no… A chi non padroneggi il mondo delle Topic Maps questo potrebbe sembrare confuso, cercherò, senza pretese di aver necessariamente ragione o di possedere la scienza infusa, di spiegarmi con un esempio: Continua a leggere

Cosa non va in EAD e come vogliamo cambiarlo

EAD (Encoded Archival Description) è in fase di revisione (qui una pagina sul nuovo portale della Society of American Archivists sulla revisione in corso).

Il perché è presto detto: EAD è nato per convertire in digitale inventari cartacei. A prescindere da se e quanto questa pratica abbia senso e porti buoni frutti (e non porti invece a forzature con divisioni, di una descrizione pre-ISAAR e quindi unitaria, in diverse entità), non si può negare che nel tempo EAD sia stato usato per altri scopi, in particolare come formato di interscambio dati e per inventari digitali nativi.

Tuttavia spesso la sua originaria natura emerge creando forzature o difficoltà laddove lo si voglia utilizzare come formato di scambio dei dati.

Ad esempio l’elemento <archdesc> è estremamente problematico: cosa ci va qui? La descrizione del primo livello? E perché questa non può andare in un comune <c>?

La verità è che l’elemento <archdesc> rispecchia in buona sostanza l’introduzione degli inventari cartacei, con le varie note metodologiche, il riepilogo delle serie la storia del soggetto produttore (in un mondo pre ISAAR, dove il soggetto produttore non era visto come separato dalla descrizione del fondo), etc.

Un elemento del genere ha poco senso per inventari digitali nativi o, ancor di più, per lo scambio dei dati.

All’interno del Technical Subcommittee on Encoded Archival Description (TS-EAD) stanno  circolando diverse idee su come risolvere queste difficoltà. Continua a leggere

Abilità informatiche dell’archivista

Su Archiviando (il forum di ANAI lombardia) ho aperto una discussione su quale siano le abilità tecnologiche in archivistica.

La mia idea era quello di proporre come risultato un post simile a quello di Eric Lease Morgan sulle abilità tecnologiche per un bibliotecario.

Complice Roberto Grassi, la piega sta diventando più pratica (e utile) di quello che ipotizzavo/speravo 😉

Se vi capita buttateci un occhio.