Credo sia ormai evidente la mia insana passione per le Topic Maps.
Cercherò, brevemente di esemplificare perché mi sono tanto care.
Prima di tutto una precisazione: Topic Maps non significa necessariamente XML (cfr GARSHOL L.M., XTM is not Topic Maps)… Spesso, alla mia proposta di utilizzare le Topic Maps, mi sento rispondere che si preferiscono i database a XML…
Questo equivale a rispondere che si preferisce la frutta a chi chiede se vuoi uscire a cena fuori…
XTM, LTM etc sono solo serializzazioni delle Topic Maps e, in tal senso, ci sono differenti database conformi al 100% (o al 99%) con il modello delle Topic Maps.
Nel caso in esame ipotizziamo di utilizzare un TMDBMS un database basato sulle Topic Maps (per le sue caratteristiche si veda Topic Map DataBase Management System axioms).
E’ notizia di pochi giorni fa il rilascio del nuovo standard nel mondo archivistico: International Standard for Describing Functions [scarica il PDF].
Ipotizziamo dunque di voler aggiornare il nostro vecchio sistema, ISAAR(CPF) compliant, al nuovo standard, che prevede numerose regole (opzionali o meno) da seguire nella descrizione delle funzioni (che diventano entità a sé stanti).
Cosa succede in un RDBMS?
Nel caso migliore, ovvero laddove le funzioni (ISAAR 5.2.5) siano state trattate come relazioni si tratta di ampliare la tabella “function” con diversi campi e metterla in relazioni con diverse altre entità (si pensi alle relazioni fra le funzioni e l’ente, previste da ISDF e descritte nell’Appendix A).
Nel caso peggiore, ovvero laddove le funzioni fossero state inserite come un campo dell’agente descritto, si tratta di ripensare il database estrapolando le funzioni in una nuova tabella etc. etc.
Cosa succede in un TMDBMS?
Nulla. O meglio, dal punto di vista della struttura del database nulla.
Nel caso migliore (ovvero nel caso in cui le funzioni siano già gestite come association) si aggiungeranno occurrence e association secondo quanto previsto dal nuovo standard.
Nel caso peggiore (ovvero dove le funzioni siano state inserite come occurrence dell’agente), basterà far diventare l’occurrence type un’association type, inserire le funzioni come topic associati e da lì procedere… Ma ciò può avvenire senza un intervento strutturale sul database (non c’è alcuna modifica che riguardi la creazione di una nuova tabella o di un nuovo campo), ad esempio utilizzando un editor eccezionale come topincs, dove le modifiche, se l’editor è settato correttamente, possono essere fatte direttamente in stile wiki in pochi passi e in poco tempo.
Senza impelagarsi in lunghe pratiche burocratiche con il vostro centro di calcolo per sentirsi rispondere, alla fine, “non modifichiamo per una singola esigenza”…
Senza dare il là all’ennesimo rifacimento del rifacimento del rifacimento del portale (ovviamente pagato con i soldi pubblici)…
Senza dover pagare un tecnico esterno 60 (sessanta) € (euro) / h (all’ora).
E, mi sento di dire, that’s cool.
[...] Mi riferisco a ISDF (International Standard for Describing Functions), lo standard internazionale per la descrizione di funzioni, di cui avevo parlato tempo addietro. [...]
[...] descrizione basata su Dublin Core Simple, a una basata su DCTERMS a una basata su EAD (cfr. anche TMDBMS vs RDBMS ovvero, nuovo standard? No problema e il mio intervento “Standard Descrittivi E Standard Di Metadati”alla Conferenza [...]