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à. E’ piuttosto condivisa l’idea che il nuovo EAD non debba più supportare la conversione in digitale di inventari cartacei e da questo scaturiscono diverse conseguenze drastiche. Come membro del gruppo di lavoro ho avanzato alcune proposte che, pur essendo particolarmente forti, mi sembrano siano state abbastanza accettate. Ecco dunque una preview del cataclisma che potrebbe avvenire con EAD v. 3 (o, se preferite, con EAD 2012 o 2013 dipende dai tempi):

  • utilizzare <archdesc> (anzi, visto che una richiesta è di rendere tutti i nomi degli elementi espliciti sarà <archivalDescription> immagino) solo come elemento contenitore dei vari<c> (anzi nella nuova ottica <component>)
  • eliminare tutti gli elementi di formattazione testuale: i paragrafi, un elemento span e delle liste è tutto ciò che serve
  • utilizzare il modello delle date di EAC-CPF, molto raffinato ed elegante che permette di esprimere date a differente granularità
  • eliminare il verboso header derivato dalla TEI per approdare a una più agile area di controllo
  • grande uso di schema xml esterni: ad ogni relazione con produttore, conservatore, bibliografia etc) deve essere possibile includere estratti di un altro schema xml (EAC-CPF, EAG, MODS o quant’altro)
  • includere le relazioni con le funzioni, ISDF (di cui avevo parlato nel vecchio blog) è qui fra noi e magari a breve ci sarà anche un EAC-F (Encoded Archival Context – Functions)
  • migliorare il collegamento con gli oggetti digitali: <dao> onestamente è parecchio carente
  • e molto ancora…

Spaventati? In effetti è una bella sfida e bisognerà modificare tutti i nostri software che lavorano, esportano etc in EAD.

Se poi avete altre idee da girare al gruppo di lavoraro, potete anche scriverle direttamente a me

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...