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:

Diciamo che vogliamo fare una lunga escursione in bicicletta e decidiamo di andare da A a B e vedere anche alcuni luoghi precisi (se vogliamo, fuor di metafora, questa fase può essere vista come la definizione dei requisiti funzionali).

Per fare questo studiamo il percorso (sì, lo so, quando si va in giro in escursione in bici o per un trekking è anche bello perdersi nella natura, ma non divaghiamo), la realtà che affrontiamo e gli elementi di cui abbiamo bisogno (vogliamo chiamarla fase di modellazione?)

Dopo di che sceglieremo la bici idonea, montiamo i cambi opportuni, prepariamo le vivande etc etc. Insomma decidiamo gli strumenti, altrove si direbbe definiamo il nostro profilo applicativo, definiamo la struttura fisica o – se preferite – scegliamo come serializzare il nostro modello di rappresentazione della realtà.

Proporre (più o meno acriticamente) EAD come modello di dati per la descrizione archivistica significa a mio avviso avere una bella bici da pista senza cambi, ma con indubbi vantaggi strutturali (che ne so, anche un bambino può cambiarne una ruota etc), e imporre questa bici, questo strumento, a prescindere dal percorso che vogliamo fare e dal piano di viaggio (che non abbiamo fatto).

Cosa poi accade quando ci troviamo davanti a una salita impervia? Beh o invece di arrivare a B arriviamo a C (tanto nessuno ha fatto un “piano di viaggio” tantomeno il committente di turno) oppure ci arrabattiamo per modificare la nostra bici e affrontare la salita (aka iniziamo a stiracchiare EAD o a integrarlo con altri strumenti).

Alle rimostranze di chi sostiene che quella bici non è idonea possiamo rispondere con tutta una serie di casi in cui questa bici è stata usata su pista o su percorsi pianeggianti… Mmmm…

Ok forse la metafora ha preso il sopravvento ed è necessario tirare le fila del discorso.

EAD nasce per codificare inventari cartacei. In questo fa abbastanza bene il suo mestiere.

Successivamente è stato usato direttamente per descrivere archivi, imponendo, per riprendere le parole di Chiara Veninata un suo “modello di dati” per la descrizione archivistica. E infine è stato usato (uhm, anche qui, forse meglio dire “si è provato ad usarlo”) come formato di scambio.

Dunque la mia opinione è che il primo uso (diciamo così, estensivo) sia un errore, soprattutto se proposto a prescindere. Come la storiella di prima cerca di evidenziare, lo strumento, la codifica, la serializzazione dipende dal modello di dati (che a sua volte dipende dai nostri requisiti che determinano come descrivere la realtà che vogliamo rappresentare). Il viceversa no bueno (almeno a mio avviso).

Ad esempio se volessi (se i miei requisiti funzionali richiedessero di ecc ecc) descrivere in maniera approfondita il soggetto conservatore (magari seguendo il novello ISDIAH) EAD non va bene. E allora che si fa? Si pesca dal fluttuante EAG e, senza grossi meccanismi per gestire questi collegamenti e le relazioni, cerco di affiancarglielo? Oppure si prende EAC e lo si stiracchia (quello vecchio, perché il nuovo EAC-CPF è, a mio modo di vedere per fortuna, più rigido) per fargli fare quello che non era un suo obiettivo (come è stato fatto per altri progetti)? O, semplicemente, si decide che non è poi così importante descriverlo in maniera approfondita (si va verso C invece di andare a B)?

Dal mio punto di vista bisogna prima definire (in qualunque situazione dal creare un nuovo software, al sistema informativo archivistico, alla descrizione del singolo archivio) gli obiettivi e i requisiti funzionali (e non funzionali) del progetto. Solo poi si può scegliere il linguaggio di serializzazione: tu vuoi usare XML? Benissimo! Tu vuoi immagazzinarli direttamente in EAD? Se risponde al tuo modello di dati (e non il viceversa) perché no! Tu, conservatore, vuoi invece usare un database, vero? Tu che sei progressista e un po’ di sinistra ti vedo che vuoi usare RDF o le Topic Maps, ma anche questo va bene.

Poi, aldilà della serializzazione scelta, sarebbe bello e opportuno avere un linguaggio più o meno comune in cui esportare. E in questo EAD potrebbe avere un ruolo importante, come credo lo posso avere EAC-CPF per i produttori o in generale per gli authority. Non l’EAD attuale però, e, a prima vista ma è presto per dirlo, nemmeno quello in fase di revisione poiché non abbandona le incongruità e ambiguità del passato.

Vogliamo definire questo “malcelato preconcetto”? Può essere, Chiara, io lo definirei (post)giudizio critico, ma è questione di definizioni. Certamente ciò non vuol dire che smetterò di confrontarmi (credo che non sia nello stile di chi risponde con entusiasmo – e spesso gratuitamente – a qualunque sollecitazione o richiesta di informazione, come tu sai bene ;-))

Perché all’inizio parlavo della mancanza di un modello concettuale per gli archivi? Beh proviamo a rispondere alla domanda se esiste o meno già un modello di descrizione o un modello di dati per il mondo archivistico. Beh la risposta secondo me è “ni”. Abbiamo un ecosistema di standard descrittivi che in un certo qual modo propongono un modello di descrizione e implicitamente un modello di dati (che peraltro EAD non è in grado di serializzare correttamente per intero). Ma probabilmente non basta. Pensate a che cos’è FRBR per il mondo bibliografico o, ancora meglio per sottolineare le differenze, il rapporto fra FRAD e ISAAR (e qui rimando anche al mio mapping). Mi sembra che proprio di questo si stia iniziando a parlare tra alcuni dei “padri” degli standard descrittivi archivistici e proprio questo potrebbe essere un passaggio interessante e essenziale se si vuole parlare seriamente di ontologie e non proporre solo tentativi che sono ontologie della descrizione archivistica o, meglio, ontologie di una specifico modello di descrizione archivistica.

2 pensieri su “Sull’uso di EAD e sullo sviluppo di un modello concettuale per gli archivi

  1. Pingback: Perché un modello concettuali per gli archivi può essere utile « Frammenti Semantici
  2. Pingback: Perché un modello concettuale per gli archivi può essere utile « Frammenti Semantici

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...