Finally Archimista (a new opensource archival software) has its own forum.
Actually only who particulate attended to Lombardy Region course (or curse? 😀 well nevermind) can download the program.
I hope that beta test will open as soon as possible to all!
Siamo chiari:
le maschere di interfaccia di catalogazione di descrizione o, usando una brutta parola, di metadatazione sono utili… ormai nessuno si sognerebbe di rilasciare un programma di descrizione e catalogazione senza una comoda interfaccia grafica che permetta di inserire i dati cliccando qua e là…
Eppure a volte queste interfacce sono estremamente lente, soprattutto laddove si debbano modificare diverse istanze in sequenza…
Ed è lì che vorremmo che la nostra comoda, ma ingombrante, maschera di data entry si dissolvesse in un semplice foglio di calcolo… con i campi e le relazioni che si distribuiscono in varie celle pronte a essere editate in sequenza.
Che questa sia un’esigenza sentita è rappresentato anche dalle modalità di modifica “bulk” (letteralmente “in grande quantità”) che si stanno diffondendo su alcuni social network come delicious o anobii.
Sicuramente anche il nuovo software di descrizione e inventariazione archivistica (di cui ho accennato in precedenza e di cui si parla in altri lidi) dovrà avere una modalità “tabella” per la modifica rapida delle schede inserite.
Leggo dalla mailing list di ica-atom la domanda di un utente italiano che chiede:
Hi!
I’m Patrizia, a university student and I’ve recently started to use
ICA AtoM for a project.
For this project I need to add new metadata to extend the Dublin Core
standard. Please can you tell me if I can do this from the web
interface, as I do to add taxonomical terms?
If not, how can I do that?
Thanks a lot.
Sostanzialmente si chiede se con ICA-AtoM sia possibile estendere i campi descrittivi popolando adeguatamente l’interfaccia di data entry.
La risposta ahimè è no.
ICA AtoM è un software in buona parte basato sulla logica degli EAV model, ovvero si basa su accoppiate di chiave/valore. Quindi è, teoricamente, estensibile con l’aggiunta di nuovi campi o anche differenti standard descrittivi. Ma questo modifica richiede un intervento sul codice visto che i campi per l’inserimento sono “hard coded” (codificati direttamente all’interno del codice).
Soluzione? Usare Topincs, o forse l’ho già detto in passato?
A parte gli scherzi (ma neanche tanto) qui abbiamo un caso concreto di archivista italiana che ha bisogno di un software che sia flessibile rispetto alle singole esigenze di descrizioni. Come si potrà/dovrà comportare il sostituto di Sesamo/Guarini, l’Aggeggio, il Coso, il Guaresimo, sì insomma il nuovo software di descrizione archivistica?
Finalmente giungo, seppur incidentalmente, anch’io a parlare del “Coso”, l'”Aggeggio” (con la A maiuscola come si confà ai nomi), il “Guaresimo”, insomma il nuovo software di descrizione archivistica il cui nome è ancora avvolto nelle nebbie (l’ultima mia proposta, Archinauta, è stata accolta tiepidamente) e di cui in altri lidi hanno già scritto in dettaglio.
Discutendo sugli elementi del Soggetto Produttore si è toccato il punto fondamentale delle stringhe di intestazione… stringhe composite, in cui la denominazione (a sua volta composita) è soltanto uno dei vagoncini componenti (seppur uno dei fondamentali).
Una proposta che, a mio avviso, è degna di essere presa in considerazione è quella di prevedere una modalità (superutente? pensando al mondo *nix) che permetta di “disegnarsi” la propria regola di intestazione.
Del resto è senz’altro vero che le indicazioni (più o meno normate) possono divergere (il neonato o, meglio, neo nascente Sistema Archivistico Nazionale, prevede regole di intestazione piuttosto complesse e lunghe, PLAIN – o, come bisognerebbe dire ora, Lombardia Beni Culturali Archivi – ne prevede altre etc.).
A tal riguardo risulta di particolare interesse la possibilità nel nuovo Topincs 4, di cui ho parlato recentemente, di comporre regole di intestazioni.
Ecco un semplice esempio.
Da vecchio appassionato di wrestling in, ormai sempre più rare, occasioni davanti allo spettacolo offerto dai lottatori non potevo esimermi dall’esplodere nel coro “this is awesome”.
Lo stesso pensiero mi è balenato provando il nuovo topincs 4 (ad oggi giunto alla versione 4.2.2) rilasciato da Robert Cerny.
La grossa novità è il supporto a TMCL (Topic Maps Constraint Language – standard ISO 19756).
Che roba è questo TMCL? Detto in parole povere tratte dalla mia tesi di dottorato :
Il TMCL è un linguaggio vincolato per creare schemi di validazione per le Topic Maps (sostanzialmente è possibile paragonare il TMCL a ciò che rappresentano XML Schema e Document Type Definition (DTD) nel caso dei documenti XML). Utilizzando il TMCL è possibile esprimere obbligatorietà e ripetibilità degli elementi e dei costrutti previsti all’interno del TMDM o vincolare (anche tramite regular expression) il valore che questi possono assumere
Dunque Topincs 4 ci dovrebbe permettere, a titolo di esempio, di dichiarare che un soggetto produttore o, meglio, un’istanza di topic appartenente a una sottoclasse di agente, deve avere almeno un nome di tipo “forma autorizzata del nome”, può avere uno o più “altre forme del nome” etc.
Una volta creati tutti questi vincoli, magicamente la nostra interfaccia di inserimento è già creata da Topincs, che richiederà, continuando l’esempio precedente, che un topic di tipo ente (sottoclasse di agente) abbia un nome di tipo “forma autorizzata del nome” etc.
Ma veniamo a un esempio pratico:
Cultural Heritage E-Libraries and Archives 