La catalogazione etnomusicologica informatizzata: CDS-ISIS, Francesco e altre storie

in Bibliografie, biblioteche e gestione dell'informazione: un omaggio a Francesco Dell'Orso

In queste pagine cercherò di ripercorrere la più che trentennale amicizia con Francesco Dell'Orso, raccontando però non gli aspetti personali ma come ogni svolta tecnologica abbia costituito occasione di un dialogo tecnico-scientifico, per risolvere i problemi di un'applicazione produttiva dell'informatica ai nostri campi di interesse.

All'inizio degli anni '80 subito dopo la mia tesi di laurea etnomusicologica si prospettava la possibilità dell'apertura a Perugia del MERU (Museo Etnografico Regionale dell'Umbria). L'Istituto di Etnologia e antropologia culturale dell'Università degli Studi di Perugia, sotto la direzione dei Tullio Seppilli, ne aveva elaborato il progetto scientifico, anche la sede era stata già individuata nel complesso di S. Matteo degli Armeni e il progetto preliminare della struttura era già stato elaborato. Tutta l'operazione era frutto della collaborazione fra il Comune di Perugia, la Provincia di Perugia, l'Azienda autonoma del turismo di Perugia e la Regione dell'Umbria. C'era quindi bisogno di predisporre un sistema catalografico per i documenti sonori, esito delle ricerche etnomusicologiche dell'Istituto. Questo lavoro ha impegnato me, insieme a Tullio Seppilli per quasi due anni, fin dal 1982: ne è nata la scheda ETM - Scheda di rilevazione/catalogazione etnomusicologica[i].

Partendo dalle varie schede già esistenti e, in primis, dalla FKM dell'ICCU, elaborata da D. Carpitella e S. Biagiola e constatata la loro inadeguatezza, oltre che una loro non coerente impostazione strutturale, reimpostammo completamente il tracciato della scheda aggiungendo anche parecchi campi, ma soprattutto disarticolando le informazioni composte in insiemi di informazioni più semplici. Il risultato fu la scheda ETM che prevede, in una struttura modulare, il massimo di informazioni possibili sul documento.

La struttura è organizzata secondo un percorso, dal generale al particolare, in tre grossi blocchi: il primo di informazioni rilevanti per una analisi antropologica (campagna, rilevazione, informatori, localizzazione e occasione/funzione); il secondo di informazioni rilevanti per una analisi musicologica(documento, modo di esecuzione musicale, strumenti musicali, incipit musicale, strutture formali, struttura metrica verbale, testo verbale); il terzo di informazioni rilevanti per la catalogazione museale (caratteristiche e modalità tecniche della registrazione originale e sua ubicazione e collocazione, caratteristiche e modalità tecniche delle registrazioni in copia e loro ubicazioni e collocazioni, altri materiali di documentazione contestuale, esiti editoriali del documento, altri materiali riferiti non specificamente al documento). La scheda è materialmente confezionata con una cartelletta rigida nel recto della quale c'è il quadro delle principali informazioni contenute nella scheda stessa e nel verso l'indicazione dei capitoli compilati, compilatore e data, revisioni o integrazioni successive. Nella cartelletta sono contenuti gli intercalari mobili (capitoli), dei quali solo quelli necessari vengono utilizzati, snellendo così una scheda che a prima vista può apparire, non a torto, troppo corposa[ii].

Ne risultava comunque un numero di intercalari, 31 per la precisione, che facevano diventare la scheda ETM più che una scheda, un vero studio approfondito sul documento oggetto di catalogazione.

Proprio in quegli anni nasceva l'informatica diffusa: il PC IBM era stato presentato nel 1981 e aveva stimolato lo sviluppo di cloni che subito sull'onda del successo di questi primi elaboratori erano stati messi in commercio. Nel 1986 comprai il mio primo PC. Era un PC AT compatibile con processore Intel 80286 memoria di 640K, dotato di Floppy disk da 5 pollici e ¼ ad alta densità (1,2 Mb), Hard Disk da ben 20 Mb e monitor monocromatico a fosfori ambra. Ero convinto che per utilizzare la tecnica (informatica o altro) in campi disciplinari specifici, bisognava avere una conoscenza non superficiale di questa. Con questo spirito, oltre al sistema operativo (era l'MS-DOS 3.20 in versione Olivetti) cominciai a studiare soprattutto i sistemi di database allora in voga. Insieme ai fogli elettronici, (Lotus 123 era quello più diffuso) il DBMS comunemente utilizzato era il dBase III plus della Ashton-Tate.

Dopo una serie di prove per implementare la struttura della scheda ETM su questo DBMS, il progetto fu abbandonato poiché in una sola tabella l'occupazione di spazio disco era eccessivo, in quanto, in questi gestori di database a matrice, i caratteri che erano stati fissati per ogni campo in fase di creazione della struttura del database, occupavano sulle memorie di massa sempre lo stesso spazio, sia che fossero interamente riempiti di dati o del tutto vuoti. Altro problema erano i campi MEMO che in dBase III erano utilizzati per occupazioni di testo: all'interno di essi non era possibile la ricerca. D'altra parte una struttura modulare del database con varie tabelle collegate, che potevano essere gestite da un eseguibile compilato, per esempio in Clipper, non era realizzabile con le mie competenze di allora.

Proprio in quel periodo conobbi Francesco Dell'Orso, che aveva predisposto, con CDS-ISIS un sistema di catalogazione delle tesi di laurea all'Istituto di etnologia e antropologia culturale dell'Università di Perugia, dove tenevo i seminari etnomusicologici per gli studenti. Francesco era già un utilizzatore esperto di CDS-ISIS e stava in contatto con Gianpaolo Del Bigio, che aveva coordinato il gruppo di sviluppo dell'UNESCO del Computerised Documentation Service fin dalla metà degli anni '70 su computer mainframe dell'IBM. Il Computerised Documentation Service / Integrated Set of Information Systems (CDS-ISIS) fu introdotto a Perugia proprio da Francesco e fui uno dei primi con cui intavolò un confronto che portò poi da parte sua, nel 1999, alla compilazione del manuale, dato che tutta la documentazione esistente fino ad allora su ISIS era ampiamente insufficiente per l'utente comune[iii].

Francesco mi consigliò di utilizzare CDS-ISIS per la catalogazione etnomusicologica, date le sue caratteristiche di gestione eminentemente testuale e la sua capacità e flessibilità in fase di ricerca delle informazioni. ISIS gestiva i campi a dimensione variabile e implementava un indice, inverted file, che poteva anche essere consultato. Era poi utilizzabile un linguaggio di ricerca tratto dall'algebra booleana, con troncamenti che permetteva di ricercare sia sull'indice che su tutto il database considerato come un'unica stringa. Era insomma una soluzione adeguata per le mie esigenze di catalogazione. Strutturai allora la Field definition table (FDT) nel modo seguente:

Tag	Nome	Lung.	Rip.	Delimitatori sottocampo
2	Istituzione	55	R
4	Numero scheda	10
6	Numero campagna	6
8	Numero documento	6
100	Campagna denominazione	150
105	Campagna def. istituzionale	300	R
110	Campagna periodo/area	150	R	pan
200	Numero progr. rilevaz.	6
210	Data e ora	20		o
220	Luogo	135	R	lcpr
230	Ambiente	55
240	Condizioni generali (B)	55		abc
245	Condizioni generali (D)	300		11cpr345n
250	Informatori (B)	300	R	cr
255	Scheda informatori (C)	300	R	1234567cpr89vloietyz
260	Rilevatori	300	R	tcnr12345
270	Annotazioni Rilevazione	300
400	Rifer. tipol. funzione (E)	135		c
410	Rifer. tipol. musicali	135		c
420	Rifer. tipol. letterari	135		c
430	Definiz. tipologica locale	135
440	Denominazione locale	135
450	Primo capoverso	135
460	Durata effettiva	6
470	Repertorio (area/fascia)	300		efc
480	Annotazioni documento	300
500	Modo esecuzione musica	300		12345
580	Tipologia strumenti	300	R	dne
590	Numero informatori	300		abcd
595	Annotazione esecuzione	300
600	Strumenti	300	R	123u456789abn
610	Incipit	300		1234
620	Trasporto a sol3/do3	300		12
630	Strutture formali	300	R	123456789n
700	Struttura metrica	300		123456
800	Testo verbale	1650	R	1234567n
810	Registrazione	300	R	r2m1345d6ta789
860	Posizione e durata	300		12345n
880	Ubicazione originale	135		a1b23
910	Riversamento	300	R	r123abcd
920	Registrazione su nastro	300	R	12d3ta456
922	Registrazione su disco	300		123456n
924	Posiz. e durata copia	100		12345n
926	Copie	135	R	1abc
928	Altri materiali	300	R	123456
930	Esiti editoriali	300	R	123
932	Riferim. altre ETM	135	R
934	Riferimenti vari	300	R	123456
936	Riferim. pubblicazioni	300	R	12345
938	Note	300
940	Cod. comp. scheda ISIS	153		ndcrxy

I capitoli della scheda cartacea diventarono i campi della FDT e gli item i sottocampi. Si arriva quindi a 51 campi, dei quali 20 ripetibili, con 197 sottocampi totali. Come primo componente essenziale del database elaborai la maschera di immissione dati (worksheet) (Palombini 1994: 468-470). Tra i vantaggi di una catalogazione informatizzata c'è quello che è possibile anche un'implementazione parziale di dati sul DB in modo da avere intanto a disposizione alcuni dati che possono in seguito essere completati. Per la visualizzazione dei dati inseriti in ISIS è disponibile un linguaggio specifico, formatting language che viene utilizzato sia per scrivere i display format per la visualizzazione che le field select table (FST) per la selezione dei campi in fase di ricerca. Non esiste editor visuale ma i formati devono venire scritti carattere per carattere, con le istruzioni separate da virgole e tutto di seguito (Palombini 1994: 471). Parecchie volte ci siamo confrontati con Francesco sui modi più efficienti per elaborare questi formati di visualizzazione: lui era un vero esperto di questo argomento (Dell'Orso 1999: 113-146) come lo era per l'esportazione dei dati con le varie FST di riformattazione (Dell'Orso 1999: 148-177).

Cominciai quindi a popolare il DB e completai una trentina di schede. Nel 1988 su invito di Diego Carpitella presentai per la prima volta il sistema di catalogazione ai seminari di etnomusicologia organizzati a Siena dall'Accademia Chigiana.

Uno dei problemi che subito mi si pose fu come conservare la notazione musicale all'interno del DB, che accettava esclusivamente dati alfanumerici. Studiai allora tutti i sistemi alfanumerici di descrizione della partitura musicale. Scartato a priori il Plaine & Easie Code, uno dei primi sistemi per la codifica musicale alfanumerica, utilizzato dal RISM (Rèpertoire International des Sources Musicales), in quanto non permetteva l'inserimento di segni diacritici, mi orientai verso DARMS (Digital Alternate Representation of Musical Score). Nato all'inizio degli anni 60 si era affermato soprattutto quale strumento per l'analisi. Il DARMS permette di descrivere con la massima accuratezza partiture musicali anche complesse e con segni diacritici aggiunti, segni che in una trascrizione etnomusicologica sono comunemente utilizzati. Ma il DARMS già allora aveva parecchi dialetti: a fronte del canonical esistevano il COMUS, l'A-R e il Note-Processor DARMS. Proprio su quest'ultimo, che aveva il vantaggio di essere utilizzato come formato nativo di file dall'omonimo applicativo si orientò la scelta. Ma essa comunque si rivelò un percorso con eccessive limitazioni: era legata, prima di tutto, alla disponibilità di un applicativo commerciale, il Note-Processor. Anche la procedura per implementare il codice DARMS, esportarlo e copiarla nel campo Incipit della scheda ETM era alquanto macchinosa. Per visualizzare in notazione il codice all'interno del Note-Processor bisognava poi fare il percorso inverso.

Abbandonai allora il DARMS e mi rivolsi al command language che il programma Score, uno standard allora per la scrittura della musica, utilizzava per immettere i dati. Questa codifica però aveva dei ritorni a capo in linee separate che non era possibile conservare all'interno di un campo di ISIS. Fu elaborato da un mio studente, esperto informatico un piccolo applicativo in Clipper che faceva la transcodifica…

La limitazione degli applicativi di data base del tempo fu superata quando all'interno dei campi fu possibile inserire o collegare altri tipi di oggetti che non il solo testo, con la tecnologia OLE (object link and embedding): file immagine, audio o multimediali. Nacquero vari database che avevano questa funzionalità ma, conoscendone già la filosofia, mi rivolsi a WinISIS, una implementazione di CDS-ISIS in ambiente Windows, che beneficiava delle potenzialità proprie del sistema operativo a finestre di Microsoft e di cui proprio in quegli anni, stavamo nel 1998, veniva rilasciata la versione 1.0.

La struttura, le maschere di immissione dati e gli stessi dati furono agevolmente trasferiti in questo nuovo ambiente, ma fu necessario riscrivere completamente i formati di display che presentavano rispetto a quelli DOS una sintassi molto variata ma anche maggiori potenzialità grafiche. Anche in questa fase i consigli di Francesco e lo scambio di idee fra di noi portò a un approfondimento dei problemi che questo software presentava. Francesco era in diretto contatto con Davide Storti che a Parigi aveva affiancato e poi sostituito Gianpaolo Del Bigio nello sviluppo di WinISIS e l'implementazione di un database così complesso come ETM-Isis costituiva un buon banco di prova e di test del programma. Francesco difatti si occupava allora a tempo pieno di questo argomento e nel 1999 pubblicò il Manuale di Isis (Dell'Orso 1999) che nel secondo volume trattava la versione Windows.

Ma i cambiamenti dell'informatica erano veloci e si stava diffondendo allora in maniera sempre più pervasiva la tecnologia Java, un linguaggio indipendente dalla piattaforma su cui è eseguito. Le applet o i veri e propri applicativi Java cominciarono a invadere il campo del digitale. Non esiste oggi dispositivo che non utilizzi questa tecnologia, che il proprietario, Sun Microsystem ha rilasciato sotto licenza GPL gratuita. Anche i gestori di ISIS si rivolsero a questo tipo di soluzione che permetteva di utilizzare data base in rete anche geografica.

Nasceva quindi nello stesso anno 1998 il client JavaISIS progettato da Renato Enea e il server scritto in C++ da Alessandro Enea. L'istallazione del sistema prevedeva quindi un server in rete, nel quale risiedevano i dati e vari client che a questo si collegavano e potevano compiere operazioni di lettura e scrittura in remoto. Questa versione era promossa dall'UNESCO e distribuita dalla DBA di Firenze.

Nel 2001 fu rilasciata la versione 3.5b1 di JavaISIS e ne implementai un'istallazione sul server della Regione Umbria[iv]. Nel sito del CEDRAV venivano date queste indicazioni:

La catalogazione dei documenti etnomusicologici umbri è in corso di trasferimento dalla scheda ETM cartacea, realizzata da Tullio Seppilli e Giancarlo Palombini e utilizzata dalla Regione dell'Umbria, al supporto informatizzato che utilizza il data base CDS-Isis dell'Unesco. E' possibile consultare la banca dati ETM con una interfaccia utente realizzata con il software JAVAISIS di proprietàdell' UNESCO. Il client JAVAISIS funziona su Windows 95, 98, NT e 2000, Macintosh e tutti i sistemi Unix su cui è disponibile l'interprete Java come Linux, IBM AIX, Sun Solaris, Digital Alpha. Per maggiori informazioni e per scaricare il client di Javaisis si può visitare il mirror o il sito ftp dell'Unesco. Al file SERVER.INF nella directory del client si deve aggiungere questa riga: 194.143.141.100:6556:ETM - Regione dell'Umbria / CEDRAV.

Ma questa tecnologia non durò molto: lo sviluppo della tecnologia Java portò ad utilizzare altri componenti, per esempio la piattaforma NetBeans, come database Berkley DB della Oracle e Apache Lucene come motore per il retrival. Nacque così J-ISIS che assomma in sé un client e insieme un server. Difatti un'istallazione di J-ISIS può collegarsi al locahost o a qualsiasi altra istallazione in rete geografica conoscendone soltanto l'indirizzo IP. A tutt'oggi vengono periodicamente rilasciati sempre nuovi aggiornamenti della Suite J-ISIS. La suite fino a poco tempo fa veniva distribuita come file compresso che, scompattato in una directory senza bisogno di installazione aveva in sé tutti i componenti per funzionare compresi gli eseguibili. Le nuove release comportavano l'eliminazione totale di quelle vecchie, ma gli archivi ai quali si stava lavorando dovevano in toto essere spostati e il file di configurazione Dbhome.conf aggiornato. La gestione di questo nuovo applicativo era più complessa dei precedenti e in questa fase era Francesco che chiedeva a me notizie sui cambiamenti e sulle nuove funzionalità man mano aggiunte al pacchetto ai quali era impegnativo stare dietro. Provai a trasferire l'ETM e ad adattare ad essa il nuovo ambiente software. L'operazione riuscì ma i continui rilasci di aggiornamento mi scoraggiarono dal proseguire.

Nel frattempo cominciai a lavorare nel gruppo di lavoro dell'ICCD (Istituto Centrale per il Catalogo e la Documentazione) che, aggiornando finalmente i suoi strumenti catalografici, voleva elaborare una scheda per la catalogazione dei beni demo-etno-antropologici immateriali. Dopo qualche anno di lavoro fu così licenziata nel 2006 la scheda BDI v. 3.01. È una scheda molto complessa che fa tesoro delle precedenti schede di catalogazione ed anche dell'ETM. La scheda si è evoluta recentemente alla versione 4.

Nel frattempo proseguendo nel parallelo lavoro di trattamento delle registrazioni audio mi sono reso conto che sempre di più si trattano file digitali, sia quelli esito di digitalizzazione conservativa, sia quelli nativamente digitali. I supporti analogici, centrali per le schede di catalogazione suddette, ETM e BDI, hanno perso questa loro centralità. La rivoluzione copernicana che ne è seguita consiste nel trattare e documentare file digitali: non è più necessario catalogare un documento, è urgente documentare un file digitale e questa operazione si fa implementandone i metadati. Ho trattato tutto questo processo operativo in un articolo che ho scritto nel 2011 [v] e individuando nei metadati amministrativi gestionali (MAG) promossi dall'ICCU (Istituto Centrale per il Catalogo Unico) la soluzione più adeguata per la catalogazione etnomusicologica.

Però:

Mentre dettagliata e esauriente è nel MAG la parte gestionale, non altrettanto se ne può dire di quella descrittiva, demandata ai quindici elementi del Dublin Core che, per la loro stessa genericità, non sono sufficienti per descrivere le caratteristiche di contenuto di un documento etnomusicologico. L'elaborazione di una sezione specifica etnomusicologica, sotto forma di un namespace <etm> esterno da importare in <bib>, che vada ad integrare il Dublin Core, mi sembra la soluzione più efficace per poter adattare il MAG, che per sua stessa definizione è uno standard aperto, e poterlo così utilizzare per la gestione di un archivio etnomusicologico digitale. (Palombini 2011).

Il cerchio si chiude: eravamo partiti con la catalogazione e ETM, ci ritroviamo senza catalogazione ma la specificità di ETM viene incorporata nel MAG.