relazione tecnica

Relazione al Comitato tecnico scientifico sulle
evolutive dell’Indice SBN
1. Materiale audiovisivo
Alle evolutive già sottoposte si ritiene opportuno aggiungere il trattamento dei campi specifici del
materiale audiovisivo, che nell’ambito del progetto di Evoluzione dell’Indice non era stato realizzato
perché si era data priorità alla musica, per poter integrare la relativa base dati, alla grafica e alla cartografia
ritenuti materiali più largamente diffusi nelle biblioteche che aderivano a SBN. Oggi il problema della
gestione del materiale audiovisivo si ripropone in una nuova prospettiva: l’Istituto Centrale per i Beni
Sonori e Audiovisivi (ICBSA) ha deciso di aderire a SBN portando tutto il proprio patrimonio di registrazioni
sonore (musicali e non musicali) e video. La sempre maggiore diffusione nelle biblioteche e l’inclusione di
tale materiale nel deposito legale sono due fattori che rendono ancora più rilevante l’ingresso in SBN
dell’ICBSA. Si ritiene infatti che l’ICBSA possa da un lato svolgere un ruolo autorevole nella catalogazione
del materiale audiovisivo, anche per la normativa, dall’altro contribuire in modo significativo alla
cooperazione mettendo a disposizione della rete il proprio catalogo.
Il personale dell’ICCU sta collaborando con i colleghi dell’ICBSA alla messa a punto del progetto, per
individuare le soluzioni più opportune per la migrazione del catalogo della Discoteca su un Polo SbnWeb e
in Indice. Il catalogo consta di 230.000 documenti, 320.000 autori e ca. un milione di spogli.
Pur nella consapevolezza che è possibile far evolvere il solo applicativo di Polo, senza coinvolgere l’Indice
SBN ed evitando così di modificare il protocollo di colloquio, si ritiene più opportuno intervenire facendo
evolvere parallelamente sia l’Indice che il Polo per le seguenti ragioni:



la soluzione è più completa ed ha caratteristiche di definitività, che risparmiano gestioni
‘differenziate’ per la gestione del materiale audiovisivo rispetto a tutti gli altri materiali ed
eventualmente tra un Polo e tutti gli altri poli utenti dell’applicativo SbnWeb. Infatti per evitare
l’utilizzo di versioni diverse del software, la modifica alla struttura della base dati dovrebbe essere
attuata su tutte le basi dati periferiche, comprese quelle dei Poli che non gestiscono il materiale
audiovisivo con un intervento che risulterebbe poi inutile e forse da ripetere nel momento in cui
l’Indice fosse adeguato a recepire i dati specifici degli audiovisivi. L’onerosità sarebbe tale da far
quasi prendere in considerazione la coesistenza di versioni diverse, situazione assolutamente da
sconsigliare;
la soluzione si ritiene percorribile in tempi compatibili con l’esigenza di un ingresso rapido in SBN
dell’Istituto centrale per i beni sonori e audiovisivi, in quanto l’affidamento delle due applicazioni –
di Indice e di Polo – ad un unico aggiudicatario rende possibili delle economie di lavoro (tempi e
risorse) nello sviluppo contemporaneo sui due ambienti;
l’adeguamento dell’Indice SBN alla gestione del materiale audiovisivo non avrebbe alcun impatto
sui Poli utenti degli altri applicativi, che potranno adeguarsi nei tempi che riterranno opportuni, in
quanto i dati degli audiovisivi sarebbero trattati in condivisione con l’Indice SBN come una ulteriore
specificità che deve essere esplicitamente abilitata. In assenza di tale abilitazione, i Poli tratteranno
questo tipo di materiale come privo delle specificità degli audiovisivi.
1
1.1. Dati, controlli e protocollo di colloquio
Data questa premessa, l’Istituto ha ritenuto opportuno procedere con l’analisi dei contenuti informativi da
gestire definendo di conseguenza:
 I dati da includere e i necessari adeguamenti della base dati;
 i controlli da inserire;
 il trattamento nell’ambito del protocollo per ottenere la compatibilità tra i Poli (e i software) che
gestiscono e quelli che non gestiscono le specificità del materiale audiovisivo.
In merito al primo aspetto, i dati, saranno introdotti tutti i campi relativi alle etichette UNIMARC 115
(video), 126 e 127 (registrazioni sonore) con poche obbligatorietà (cfr. documento allegato).
I controlli saranno sviluppati dipendentemente dal tipo di materiale audiovisivo (video o audio) e in alcuni
casi dal valore inserito per alcuni campi (ad es. il tipo di video ammette o no la valorizzazione di alcuni
campi). Anche per questo si fa riferimento al documento allegato (documento sui controlli).
Per quanto riguarda il terzo punto, la soluzione è affidata, come in passato, al campo tipo_materiale, che si
è deciso di chiamare più correttamente ‘specificità’, con l’introduzione di un nuovo codice H,
corrispondente a ‘specificità del materiale audiovisivo’. Si è però considerato che il materiale audiovisivo
può includere anche campi specifici della Musica. Non a caso già oggi, le registrazioni sonore musicali e i
video musicali ammettono le specificità di Musica (es. organico sintetico, analitico, etc.). Si è pertanto
stabilito che chi gestirà il materiale audiovisivo dovrà anche essere in grado di gestire i campi della Musica.
In altri termini le registrazioni sonore musicali e i video musicali (corrispondenti ai tipo_record …) potranno
avere sia dati specifici della Musica che dati specifici degli audiovisivi. I Poli o gli applicativi che non
gestiscono né le specificità della Musica né quelle degli audiovisivi potranno trattare il record senza fornire
alcun campo specifico e l’Indice sarà in grado di inviare loro il record al netto delle specificità. I Poli o gli
applicativi che gestiscono le specificità della Musica ma non quelle degli audiovisivi potranno fornire le sole
specificità ‘musicali’ e l’Indice sarà in grado di inviare il record al netto delle specificità degli audiovisivi,
preservando così i dati non gestiti dal Polo. I Poli e gli applicativi che gestiscono sia le specificità della
Musica che quelle degli audiovisivi, riceveranno e restituiranno la totalità dei campi.
La soluzione appena descritta risponde all’obiettivo, già condiviso con il Comitato rispetto alla gestione dei
campi specifici di musica, grafica e cartografia per il libro antico, di evitare la combinazione di più ‘tipi di
materiale’ su uno stesso documento. Pertanto l’unico valore H, potrà includere le specificità non solo degli
audiovisivi, ma anche della musica, e il sistema in base al tipo record ammetterà i dati di musica per le
registrazioni sonore musicali e video, ma le escluderà per le registrazioni sonore non musicali. Le
registrazioni sonore musicali potranno essere descritte senza i campi specifici degli audiovisivi, ma l’Indice
impedirà che un Polo, ricevendo le specificità dell’audiovisivo, le elimini mantenendo le sole specificità
della Musica, come oggi impedisce che qualsiasi Polo elimini le specificità di Musica, Grafica e Cartografia
abbassando il livello del contenuto informativo ai soli dati comuni.
1.2. Legami: interpreti
Altri interventi evolutivi riguardano il trattamento degli interpreti. Oggi l’interprete si lega al personaggio e,
tramite questo, al timbro vocale che lo contraddistingue. Si richiede invece di poter legare l’interprete ad
uno strumento anche in assenza di legame al personaggio. Pertanto lo strumento sarà gestito come una
sorta di specificazione del relator code ‘interprete’ o ‘strumentista’. Il legame interprete personaggio, oggi
riservato alla Musica (per libretti d’opera, etc.) potrà essere esteso al materiale audiovisivo.
2
1.3. I numeri standard
Infine la catalogazione del materiale audiovisivo estende notevolmente la quantità e tipologia di numeri
standard da gestire per la presenza di numeri di registrazione, matrice, etc. (v. all.). In merito a questo
aspetto, che già era stato considerato tra le modifiche evolutive (‘ampliamento dei numeri standard’) si
ritiene indispensabile sottolineare che ci si aspetta un totale adeguamento da parte degli applicativi di Polo,
per le seguenti ragioni:
a. i numeri standard non sono mai stati sottoposti a vincoli sul tipo_materiale; in altri termini, non
sono mai stati considerati come campi specifici della Musica, piuttosto che del Libro Moderno. Il
controllo eventualmente viene effettuato sulla natura (es. l’ISSN è ammesso per periodici e
collezioni, ma non per monografie) o sul tipo record;
b. la scelta a suo tempo fatta di non considerare i numeri standard come campi specifici di una certa
tipologia di materiale si giustifica ed è ancora valida in quanto costituiscono chiavi di accesso
primarie e in quanto tali richiedono un comportamento uniforme;
c. non essendovi nuove etichette da gestire nel protocollo, oltre a quelle già trattate, per gli
applicativi di Polo si tratterà soltanto di aggiungere in tabella i codici che indicano le nuove
tipologie di numeri standard.
2. Date di pubblicazione
Per quanto riguarda gli altri interventi evolutivi sull’Indice ritenuti più urgenti, essendo stata approvata dal
Comitato l’ipotesi di ammettere le specificità della Musica, della grafica e della cartografia sul materiale
antico, con la sola indicazione della specificità (tipo_materiale) Musica, Grafica o Cartografia, si è reso
necessario un controllo di obbligatorietà sul campo data1. In altri termini, il sistema riconosce come ‘antica’
la pubblicazione descritta non per la presenza della E al 4. carattere del BID, né per il tipo_materiale = E, ma
in base alla data < 1831, mentre abiliterà l’inserimento dei dati specifici della musica, della grafica o della
cartografia in base al tipo_materiale = U, C, G. Tuttavia, anche per continuità “storica” con la gestione
precedente, si continuerà ad associare il valore ‘E’ nel tipo_materiale alle pubblicazioni antecedenti il
1831 prive di specificità (semplici testi a stampa o manoscritti), soprattutto per facilitare, o continuare ad
utilizzare, alcuni tipi di statistiche basate proprio sulla distribuzione dei tipi materiali nelle basi dati
centrale o periferiche.
L’obbligatorietà del campo data1, insieme al tentativo di adeguarsi sempre più allo standard UNIMARC, sta
portando ad un ripensamento sia delle regole di catalogazione, sia dei controlli.
La principale differenza tra UNIMARC e la catalogazione in SBN, consiste nel fatto che mentre UNIMARC
ammette un valore incerto nei due campi data1 e data2 (es. 197#) e riserva il codice tipo data F alle
monografie pubblicate in un solo anno con data incerta, in SBN la data F si applica a tutti i documenti
(monografie pubblicate in un anno solo o in più anni, periodici, collezioni) di cui sia incerta la data unica o
iniziale. Parallelamente, la catalogazione in SBN richiede la valorizzazione di campi numerici di 4 e quindi,
nel caso di data incerta – per qualsiasi tipo di documento – richiede o l’inserimento in data1 di un anno
presunto, o in data1 e in data2 gli estremi cronologici entro i quali si ritiene che si situi la data unica o
iniziale della pubblicazione.
Lo stato dei controlli in Indice, al momento attuale, è il seguente: data F è ammessa per tutti i tipi di
documento, data1 è diventata obbligatoria per le sole monografie (M, W). Come ulteriore intervento
evolutivo si vorrebbe:
3
a. accettare per qualsiasi tipo data, ad eccezione del tipo data ‘d’, la valorizzazione dei campi data1 e
data2 con numeri seguiti da # come carattere jolly: es. 197# , 19##.
b. riservare la data F alle sole monografie pubblicate in un anno solo (indicazione catalografica);
c. ammettere per tutti i tipi data diversi da F la valorizzazione di data1 e data2 non come estremi
cronologici della data unica o iniziale, ma i valori certi o incerti relativi alla data di inizio e di fine
della pubblicazione; es.: Tipo data B, data1 197# , data2 1992 esprime periodico iniziato negli anni
Settanta e chiuso nel 1992; Tipo data G, data1 197# data2 198# esprime monografia in più volumi
conclusa di cui sono incerte sia la data iniziale che la data finale; Tipo data G, data1 197# data2
assente esprime monografia in più volumi non ancora conclusa di cui è incerta la data iniziale; Tipo
data G, data1 157# data2 157# esprime monografia in più volumi conclusa di cui sono incerte sia la
data iniziale che la data finale, nell’ambito dello stesso decennio.
d. ne conseguirebbe un progressivo adeguamento agli standard, perché i tipi data potrebbero
successivamente essere sottoposti al controllo di coerenza con la natura del documento e
l’obbligatorietà di data 1 sulle monografie (M, W) impone fin da oggi la necessità di intervenire e
l’opportunità di correggere le monografie, che costituiscono la massima parte dell’archivio.
Per quanto riguarda il recupero del pregresso, si dovrebbe intervenire manualmente soltanto sui record
che presentano tipo data = F e data 2 valorizzata, in quanto richiedono un diverso contenuto informativo
nei due campi. Tutti gli altri documenti con tipo data = F e la sola data1 valorizzata resterebbero invariati
nel contenuto di data1. (In allegato il report sulle date F presenti nella base dati di Indice)
3. Area 0
Altro intervento di interesse generale è quello per la gestione dell’area 0. L’implementazione delle
etichette 181 e 182, per il trattamento dei dati in forma codificata è sicuramente preferibile a quello
dell’etichetta 203, che fornisce le stesse informazioni, in forma non codificata, nella descrizione
bibliografica e avrebbe sicuramente un maggiore impatto sulle basi dati di Polo, che non seguono uno
stesso modello di organizzazione dei dati (registrazioni suddivise per area/etichetta, per sottocampi, in un
unico campo con riconoscimento delle aree/etichette, etc.).
Dall’esame effettuato si potrebbero attribuire di default, con un margine di errore forse accettabile, i
seguenti valori:
Per i documenti cartacei di tipo testuale (tipo record a, b), ad esclusione dei testi in braille che peraltro non
sono individuabili in alcun modo:
Etichetta, sottocampo
Contenuto
Tipo record Valore
181$a0
181$b0
181$b1
181$b2
181$b3
182$b0
Forma del contenuto
Specificazione del tipo di
contenuto
Specificazione
del
movimento
Specificazione
della
dimensionalità
Specificazione sensoriale
Tipo di supporto
a, b
a, b
i=testo
#=non applicabile
a, b
#=non applicabile
a, b
#=non applicabile
a, b
a, b
e=visivo
y = senza mediazione
Per la musica a stampa e manoscritta, cartacea:
4
Etichetta, sottocampo
Contenuto
Tipo record
Valore
181$a0
181$b0
Forma del contenuto
Specificazione del tipo di
contenuto
Specificazione
del
movimento
Specificazione
della
dimensionalità
Specificazione sensoriale
Tipo di supporto
c, d
c, d
d=musica
a=notato
c, d
#=non applicabile
c, d
#=non applicabile
c, d
c, d
e=visivo
y = senza mediazione
Per il materiale cartografico:
Etichetta, sottocampo
Contenuto
Tipo record
Valore
181$a0
181$b0
Forma del contenuto
Specificazione del tipo di
contenuto
Specificazione
del
movimento
Specificazione
della
dimensionalità
e, f
e, f
b=immagine
c = cartografico
e, f
b = fissa
e, f
Specificazione sensoriale
Tipo di supporto
e, f
e, f
2=bidimensionale
(ad eccezione dei mappamondi (o
forse delle carte a rilievo?): 3 =
tridimensionale)
e=visivo
y = senza mediazione
Per le audioregistrazioni musicali:
Etichetta, sottocampo
Contenuto
Tipo record
Valore
181$a0
181$b0
j
j
d=musica
b=eseguito
j
#=non applicabile
j
#=non applicabile
j
j
a=uditivo
a=audio
Per le audioregistrazioni non musicali:
Etichetta, sottocampo
Contenuto
Tipo record
Valore
181$a0
Forma del contenuto
i
181$b0
Specificazione del tipo di i
contenuto
Specificazione
del i
movimento
Specificazione
della i
dimensionalità
h = parlato (ma g = suoni, per il
sonoro diverso da parlato e musica)
#=non applicabile
181$b1
181$b2
181$b3
182$b0
181$b1
181$b2
181$b3
182$b0
181$b1
181$b2
181$b3
182$b0
181$b1
181$b2
Forma del contenuto
Specificazione del tipo di
contenuto
Specificazione
del
movimento
Specificazione
della
dimensionalità
Specificazione sensoriale
Tipo di supporto
#=non applicabile
#=non applicabile
5
181$b3
182$b0
Specificazione sensoriale
Tipo di supporto
i
i
a=uditivo
a=audio
Per il materiale grafico:
Etichetta, sottocampo
Contenuto
Tipo record
Valore
Forma del contenuto
Specificazione del tipo di
contenuto
Specificazione
del
movimento
Specificazione
della
dimensionalità
Specificazione sensoriale
Tipo di supporto
k
k
b=immagine
#=non applicabile
k
b = fissa
k
2=bidimensionale
k
k
e=visivo
y = senza mediazione
181$a0
181$b0
181$b1
181$b2
181$b3
182$b0
Sul materiale video è più difficile trovare dei default:
Etichetta, sottocampo
Contenuto
Tipo record
Valore
181$a0
181$b0
g
g
b=immagine
# = non applicabile
g
a = in movimento
b = fissa
2=bidimensionale
3 =tridimensionale
e=visivo
e = proiettabile
181$b1
181$b2
181$b3
182$b0
Forma del contenuto
Specificazione del tipo di
contenuto
Specificazione
del
movimento
Specificazione
della
dimensionalità
Specificazione sensoriale
Tipo di supporto
g
g
g
Una volta che si saranno individuati i valori di default per il pregresso, da un lato sarà possibile applicare lo
stesso default in caso di assenza delle informazioni sui nuovi record che verranno inseriti, dall’altro sarà
necessario che tali valori siano resi correggibili da chi li gestisce, senza che altri li eliminino per impossibilità
di gestirli. Su questo aspetto è necessario prendere una decisione, valutando le due possibili soluzioni: o
proteggere le informazioni codificate dell’area 0 come avviene per i dati specifici, che sono tutelati dalla
gestione differenziata, o chiedere che, sia pure con un lasso di tempo abbastanza lungo (es. un anno), gli
applicativi si adeguino all’evoluzione dello standard, includendo i dati codificati.
4. Libretti d’opera
Tra i trattamenti da adeguare con la dismissione del vecchio protocollo c’è anche quello dell’informazione
relativa i libretti d’opera. Unimarc gestisce l’informazione nell’etichetta 105 e nel sottocampo $a11, tipo
testo letterario, facendo riferimento ad un’apposita tabella di codici (a = fiction; b = drama; c = essays; d =
humour, satire; e = letters; f = short stories; g = poetry; h = poetry; i = libretto; y = not a literary text; z =
multiple or other literary forms). Nella realizzazione dell’Indice, l’informazione che pubblicazioni a stampa
o manoscritte consistessero in libretti d’opera è stata gestita nei seguenti modi:

nel protocollo SBN con due valori, appositamente creati, nella tabella Genere della pubblicazione:
‘2’ per i libretti a stampa e ‘3’ per i libretti manoscritti; (si ricorda che nel protocollo SBN, il campo
genere della pubblicazione era stato utilizzato negli anni per indicare i cosiddetti ‘materiali speciali’:
6

cartografia a stampa e manoscritta,m musica a stampa e manoscritta, etc. e che in fase di
realizzazione del protocollo SBNMARC era stata individuata una stretta corrispondenza tra tali
valori già ospitati nella tabella Genere della pubblicazione e i valori previsti da UNIMARC nella
tabella del tipo record).
nel protocollo SBNMARC con il corretto tipo record a (materiale testuale non manoscritto) o b
(materiale testuale manoscritto) erroneamente accompagnati dal valore ‘b’ = drama nel tag 125
(corrispondente a 125$b Indicatore di testo letterario). In altri termini, per un errore di analisi, il
tipo testo letterario è stato così incluso nel protocollo SBNMARC come dato specifico della Musica.
Ne consegue che chi gestiva i dati di Musica poteva fornire l’informazione, mentre chi non li gestiva
o non la dava affatto oppure utilizzava i due valori ‘2’ e ‘3’ come codici del Genere della
pubblicazione.
Evidentemente il problema che si pone oggi non è quello, fin troppo semplice, di convertire il valore ‘b’ in
‘i’, ma quello di poter dismettere l’uso di questi valori ‘2’ e ‘3’ fuori standard inseriti in una tabella, Genere
della Pubblicazione, per un utilizzo improprio e di trovare una soluzione che consenta a tutti i Poli e a tutti
gli applicativi, indipendentemente dall’abilitazione a gestire le specificità della Musica, di ricevere e fornire
l’informazione che il testo a stampa o manoscritto contiene un libretto. Le soluzioni possibili sono due:


modificare il protocollo SBNMARC in modo che l’informazione che il documento consiste in un
libretto d’opera sia correttamente riportato nel campo codice di tipo testo letterario (in UNIMARC
105$a11 con valore ‘i’, per i libretti pubblicati dopo il 1830 oppure nel campo 140$a17-18 con
valore ‘da’, per i libretti pubblicati entro il 1830). L’aggiunta di tale dato, fino ad oggi non gestito,
estende la facoltà di utilizzare, per qualsiasi tipologia di testo, anche gli altri valori inclusi nella
tabella dei codici di tipo di testo letterario; il campo rientrerebbe pertanto nella quota parte dei
dati comuni. In questa ipotesi tutti gli applicativi di Polo dovrebbero adeguarsi a gestire
l’informazione tra i dati comuni: sia quelli, già certificati per la gestione delle specificità di Musica,
che attualmente gestiscono l’informazione nella 125$b, sia quelli che non gestiscono le specificità
di Musica e che attualmente forniscono l’informazione con i ‘codici di genere’ ‘2’ e ‘3’.
Ricorrere a qualche ‘escamotage’ per gestire con un diverso valore di tipo record i libretti (es.
utilizzare due valori non ancora utilizzati, oppure esprimere l’informazione attraverso un
particolare formalismo, come potrebbe essere tipo record ‘A’ o ‘B’ (invece di ‘a’ o ‘b’ che indicano
testi a stampa o manoscritti). Questa soluzione avrebbe un impatto sicuramente inferiore sugli
applicativi, non comprometterebbe l’uscita UNIMARC che sarebbe comunque corretta (tipo record
‘a’ o ‘b’ con ‘i’ in 105$a11), ma si limiterebbe ad individuare i libretti a stampa e manoscritto e non
consentirebbe la gestione dell’informazione ‘tipo testo letterario’ ad altri tipi di documenti.
7

Download Report