�ݺ�ߣ

Koha, RDA, FRBR : alcune riflessioni
Intervento al convegno
METODI SCELTE STRUMENTI : IL NUOVO CATALOGO DELLA RETE URBS
11 giugno 2015
Stefano Bargioni, Pontificia Università della Santa Croce
�ݺ�ߣ 1
Le regole RDA stanno interessandoci sempre di più. Mentre FRBR ci è parso un modello intrigante
da circa dieci anni, non si è riusciti a ottenere qualcosa di veramente concreto. Si iniziò a ragionarci
nel 2005. Tiziana Possemato presentò un proof of concept basato su Amicus al convegno ADLUG
tenuto a Budapest.
Ora invece iniziamo a capire meglio come collegare il mondo MARC con FRBR
(MARC21, perché di RDA e Unimarc non ho ancora sentito parlare con
concretezza...1
). Il collegamento sono le RDA.
�ݺ�ߣ 2
Che cosa sta facendo Koha per introdurre le RDA? Anzitutto, ha già di per sé molte capacità da
sfruttare, e vedremo come. Ma anche un limite, e vedremo come il Koha Gruppo Italiano stia
aiutando la community degli sviluppatori a superarlo.
Va detto subito che Koha accetta qualunque nuovo tag di record di autorità e bibliografici già di per
sé. Chiunque può adattarlo alle proprie esigenze, definendo nuovi tag tramite l'interfaccia web di
configurazione o tramite le tabelle del database.
La versione appena uscita 3.20 include l'Update 19 del MARC21, mentre è in lavorazione l'Update
20 di aprile2
, e una griglia di catalogazione denominata RDA2 riporta tutti i campi necessari per
catalogare in RDA. Ma le RDA non sono una griglia di catalogazione, dato che ogni griglia di Koha
è destinata tipicamente a un tipo di materiale. Con la griglia specifica si hanno a disposizione le
definizioni dei nuovi tag, da riportare nelle griglie in uso presso la propria biblioteca.
I tag introdotti sono immediatamente disponibili per la catalogazione, ma la visualizzazione
nell'OPAC va portata avanti soprattutto dalla community stessa. E il riempimento dei nuovi tag
deve essere agevolato con strumenti specifici.
1 Forse il contributo più significativo è quello di Gordon Dunsire, presentato a IFLA 2009:
http://conference.ifla.org/past-wlic/2009/135-dunsire-en.pdf [5 giugno 2015].
2 http://www.itsmarc.com/crs/mergedprojects/helptop1/helptop1/appendices/appendix_g_format_changes_update_no
._20_april_2015.htm [5 giugno 2015] e
http://www.itsmarc.com/crs/mergedprojects/helpauth/helpauth/appendix_f_format_changes_update_no._20_april_2
015.htm [5 giugno 2015].
1

�ݺ�ߣ 3
Anzitutto ci sono i default. Quelli globali, sino al singolo sottocampo. Non mi dispiacerebbe che
fosse possibile dotare il singolo catalogatore di default, decisi dall'interessato stesso, e questo
potrebbe essere una miglioria per Koha.
Ci sono poi i menù a tendina, dai quali si sceglie un valore tra quelli offerti. L'insieme di questi
valori può essere statico, o rinnovato automaticamente ogni tanto, o procedere sul momento da una
fonte esterna che li mantiene (esterna all'ILS o addirittura all'agenzia catalogatrice stessa).
�ݺ�ߣ 4
Tra i menù a tendina, ci sono gli autosuggest, che all'inserimento di pochi caratteri rispondono con
una lista di valori disponibili. Poi vi sono i casi dei campi correlati, frequenti nelle RDA, dove si
vuole conservare la stessa informazione sotto forma di codice e di stringa. Inutile riempire a mano
entrambi i campi, apporterebbe anche errori. Poi ci sono campi che vanno compilati con l'ausilio di
plugin, dove la complessità particolare richiede programmazione specifica. Per esempio i tag 000 e
008 (000 e 100 dell'Unimarc) in Koha sono governati da plugin, e in altri ILS succede qualcosa di
simile, per esempio hanno una schermata apposita.
�ݺ�ߣ 5
Portiamoci in ambito RDA. I valori di default possono essere utili per i sottocampi $2 dei tag 33x,
che avranno valore rdacontent, rdamedia, rdacarrier, in riferimento ai sottocampi $a e
$b.
�ݺ�ߣ 6
Un simpatico esempio di menù a tendina a lista chiusa si potrebbe trovare nella compilazione di un
tag 384, quando si cataloga materiale musicale.
Invece i sottocampi $a e $l del tag 377 per la lingua associata dipendono da una lista che talvolta
varia nel tempo e potrebbe essere la stessa usata per il codice lingua del tag 008 (100). In PUSC
rinnoviamo automaticamente ogni 7 giorni questa lista, scaricando il file dalla LOC e inserendolo in
Koha.
�ݺ�ߣ 7
Un campo con funzionalità di autosuggest potrebbe essere il 340 $a. La fonte dovrà essere quella
più adatta, e ovviamente andrebbe trovata con i valori nella lingua dell'agenzia catalogatrice.
La tecnica a cui si dovrebbe fare ricorso per maggiore comodità è quella di interrogare dal browser
stesso, in REST o SPARQL, la fonte suddetta, estrarre i primi risultati e popolare la tendina. Un
compito non arduo ma per conoscitori di interfacce web dinamiche.
2

�ݺ�ߣ 8
Una fonte di autosuggest può essere interna, o esterna, e anche se autorevole, potrebbe non essere
completa. E in questo caso, la fonte interna è l'insieme dei valori creati dai catalogatori perché
mancanti nella fonte esterna.
Si potrebbe applicare un autosuggest al campo di autorità 374 $a (Occupation) interrogando il
Nuovo Soggettario di Firenze.
�ݺ�ߣ 9
Questa è l'interrogazione che va inviata all'endpoint SPARQL della BNCF, se i primi tre caratteri
sono "att". Notare che la ricerca avviene all'interno della categoria "persone".
�ݺ�ߣ 10
La risposta che si ottiene permette di popolare la tendina con le voci "attacchini" ecc. Notare il
plurale: probabilmente il valore dovrà essere ritoccato a mano. Si può costituire così, volendo, un
insieme di valori interni da riutilizzare anch'essi, mescolandoli alla risposta di BNCF. Se si vuole, si
può sfruttare la potenza dello SPARQL che può interrogare più di un endpoint alla volta e fornire
una sola risposta. Per riuscirci, ovviamente anche la fonte interna deve essere in formato linked
data.
Side 11
Particolarmente interessante sembra essere rdaregistry.info, che offre in formati diversi molta
informazione strutturata relativa alle RDA. L'esempio mostrato permette di scaricare sul momento
nel browser tutti i dati per compilare un menù a tendina per il tag 338. Attualmente le voci sono in 4
lingue, ma possiamo supporre che presto verrà incluso l'italiano, grazie al lavoro di traduzione del
gruppo di Mauro Guerrini.
�ݺ�ߣ 12
Veniamo ai campi correlati, di cui le RDA fanno un uso frequente, per una ragione pratica di
standardizzazione dell'informazione: utilizzare vocabolari controllati validi in ambiti più ampi
possibile permette di farsi capire anche fuori dall'ambito strettamente bibliotecario, e quindi di
partecipare meglio al web semantico. L'ideale sono i codici, ma va salvaguardata la leggibilità del
dato. Ecco allora la coppia code e term, spesso rappresentata dai sottocampi $4 e $e rispettivamente,
unitamente al sottocampo $2 che indica la fonte della coppia suddetta, e che sarà probabilmente,
come già detto, un default della biblioteca.
La coppia deve avere valori coerenti, e va tenuto presente che non si tratta sempre di una
corrispondenza biunivoca. Per esempio, per i 7xx al relator code "wit" (witness) la traduzione
italiana fa corrispondere i relator term "Testimone oculare", "Astante, "Teste", "Osservatore",
"Testimone".
3

�ݺ�ߣ 13
Ecco come apparirebbe in Koha quanto ipotizzo. Presumo che il catalogatore preferirà usare il $e e
gradirà che il $4, meno user friendly, venga riempito automaticamente, per cui non ho previsto il
caso contrario.
In quanto all'importanza del $e specialmente per gli autori secondari, mai utilizzati purtroppo presso
la Pontificia Università della Santa Croce, i miei colleghi giustamente sperano in un intervento di
recupero automatico del pregresso. Credo che potremo affrontarlo utilizzando la stessa logica che ci
portò a migliorare molto la classificazione Dewey3
. L'idea è sfruttare l'ISBN per cercare questa
informazione su fonti interessanti per noi. Lo useremo sia per il pregresso sia per il corrente.
Vedremo in conclusione perché questa informazione risulta utile nell'OPAC.
�ݺ�ߣ 14
I plugin associati a un campo di Koha sono noti soprattutto per i tag 000 e 008 (100), e per
compilare i campi associati a record di autorità. Ma possono essere scritti anche per altri campi.
Siccome si tratta sia di codice Perl sia di codice Javascript, si dà allo sviluppatore una notevole
possibilità di aiutare il lavoro del catalogatore.
Li vedo bene per campi che trattano date, quali il tag 046 (sia bib che auth) e il tag 033. Si sa che le
date sono scomode da scrivere, e quindi gli errori sono dietro l'angolo. In più occorre assicurare
alcune coerenze con altri campi o parti di essi, che tanto vale fare in modo automatico.
�ݺ�ߣ 15
Vediamo adesso un caso molto più complesso, che -lo confesso- non è fatto con la logica stretta dei
plugin di Koha, ma potrebbe. Ha come finalità un arricchimento del catalogo di grande valore. Con
Koha, l'ufficio catalogazione ha deciso di dare un forte impulso ai record di autorità. Al tempo
stesso, ci siamo resi conto dell'importanza dei legami che possono formarsi in ambito linked data se
vengono associati al record alcuni identificatori numerici significativi. Abbiamo ovviamente
individuato il VIAFid e l'ISNI. Per evitare una trascrizione manuale, che richiede soprattutto una
ricerca manuale sui rispettivi siti, abbiamo pensato di aggiungere a Koha una utility che riuscisse a
minimizzare lo sforzo di individuazione del match e la relativa costruzione di due occorrenze del
tag 024 del record di autorità. Il match viene suggerito tramite gli ISBN relativi a un record di
autorità: quelli presenti nel nostro catalogo e quelli derivanti da una ricerca per nome su isni.org,
che restituisce anche gli ISBN associati. Quando vi sono ISBN in comune, la probabilità che si tratti
dello stesso autore è alta, e il catalogatore decide se procedere alla creazione di due occorrenze del
tag 024 del record di autorità con un click su un bottone. Questi valori renderanno poi possibili
alcune funzionalità nell'OPAC e soprattutto permetteranno di costruire triple RDF basate sulla
proprietà owl:sameAs. Proprietà che, come si può capire, fa veramente diventare linked i linked
data, come piace sottolineare a Paola Manoni, perché lega risorse proprie a risorse altrui.
3 http://leo.cineca.it/index.php/jlis/article/view/8766 (consultata il 2015.06.07).
4

�ݺ�ߣ 16
Conclusa la carrellata su come Koha può aiutare la catalogazione a livello campi seguendo le RDA,
vediamo adesso alcune riflessioni personali, come promesso dal sottotitolo di questo intervento.
1. Vi sono diversi casi nel MARC21 attuale che riflettono la necessità di avere un'informazione più
esaustiva rispetto a quella portata da 000 e 008. Abbiamo visto i campi 33x per content, media e
carrier, abbiamo visto date riportate nel tag 046, ecc. Questo mi fa pensare che i controlfield, già
scomodi, stiano soffrendo una crisi di identità. Sono decisamente gli elementi più ancestrali del
MARC.
2. Già da tempo si trovano nel MARC esempi di sottocampi correlati. Adesso, con i casi che
abbiamo visto, specialmente le coppie term e code, direi che diventa evidente un problema. Essendo
ripetibili, ogni $4 a quale $e fa riferimento? Si affida questa informazione alla posizione fisica nel
tag, ma questa vale per l'occhio, non per la macchina. Il programmatore quindi dovrebbe rispettare
la sequenza dei sottocampi ogni volta che interviene sul record. Ma con linguaggi attuali come
XML e JSON con cui si può molto più comodamente rappresentare un record MARC, la posizione
può cambiare casualmente, cioè a piacimento delle librerie di software stesse. Sarebbe necessario
quindi che questa informazione sia presente nel record, ma il MARC non lo prevede.
3. Sempre più spesso le specifiche del MARC21 fanno riferimento a FRBR: contengono frasi del
tipo "When the resource description is for an expression...", oppure citano il concetto di entità,
come riportato sulla slide4
. Ora, studiando le RDA, soprattutto seguendo corsi e libri di Tiziana!, ho
inteso che espressioni e opere sono punti di accesso la cui descrizione associo più ai record di
autorità che a quelli bibliografici. Il MARC introduce le regole RDA, fa appello al modello FRBR,
ma non dà tutti gli strumenti, in particolare non dice come si devono legare tra loro le entità.
Anche RDAToolkit fa capire che opere ed espressioni andrebbero descritte con record di autorità.
Poi aggiunge, negli esempi di record bibliografici: "Related expression recorded using an
unstructured description". Vale a dire che, giustamente, la relazione della manifestazione andrebbe
legata alla sua espressione usando un metodo a piacimento, che alla fine sarà un tag 900, cioè dove
si è liberi di agire. Ma poi come la mettiamo con le migrazioni? Riusciremo a migrare le relazioni?
4. Per quanto detto, quindi, non sorprende il tentativo di rifondazione globale del MARC che sta
andando avanti con BIBFRAME.
�ݺ�ߣ 17
Le relazioni FRBR sono uno a molti, reciproche, ricorsive... Dove vengono adottate, portano
notevole informazione per l'utente: basta vedere il catalogo dell'IDEO, recentemente rifatto
utilizzando espressioni e opere.
�ݺ�ߣ 18
Dieci anni fa Barbara Tillett rappresentava così le relazioni FRBR. Il punto è allora non solo come
4 http://www.loc.gov/marc/bibliographic/bd377.html (consultata il 2015-06-04).
5

descriverle con il MARC (qualche tag 900, si diceva), ma soprattutto come legare questi record tra
loro assicurando le performance per la ricerca e la visualizzazione. Neo4j, Solr, Elasticsearch, ma
anche i database relazionali classici possono risolvere il problema. Non certo l'attuale motore di
ricerca full-text con cui Koha indicizza i record bibliografici e di autorità. Per questo il Koha
Gruppo Italiano ha promosso la sostituzione di Zebra con Elasticsearch, ottenendo un cospicuo
grant da Ebsco a favore della community internazionale degli sviluppatori.
�ݺ�ߣ 19
Come si potrebbero legare le entità FRBR usando Elasticsearch? Questo esempio mostra un legame
tra espressione e manifestazione. Si limita a descrivere la relazione, non i record stessi, per cui gli
elementi essenziali sono gli identificatori numerici dei due record e il tipo di relazione. Si noti che
la proprietà relationships è una lista, cioè è ripetibile. La sintassi è JavaScript Object Notation o
JSON, tipica di Elasticsearch e già pronta per un browser web.
In realtà è previsto molto di più per Elasticsearch in Koha: dovrà anche conservare i record stessi e
indicizzarli, appunto per sostituire il motore di ricerca attuale che con fatica sarebbe in grado di
gestire anche le relazioni.
�ݺ�ߣ 20
Sono già diversi, e significativi, gli impieghi di relazioni FRBR in cataloghi di varia natura. Invito a
visitarli. Direi che tutti vengono accomunati da due caratteristiche abbastanza innovative per gli
OPAC: grafica e dinamicità. Attraenti, navigabili... Ma potrebbero anche nascere problemi di
accessibilità per ipovedenti.
�ݺ�ߣ 21
Un esempio di importanza delle relazioni è il draft che abbiamo realizzato con i dati del nostro
catalogo.
Come si vede, la relazione non è qualificata. Abbiamo già parlato nella slide 13 del progetto per il
sottocampo $e.
Se senza ricorrere a RDA e FRBR si possono già mostrare relazioni significative come quelle tra
autori del proprio catalogo, si capisce che nel lavoro di catalogazione dovremo dare via via
maggiore enfasi alla correlazione, in concreto a quella che non può avvenire tramite algoritmi. È
impegnativo, è lavoro intellettuale, è quello che credo possa dare un forte ritorno al reference, alla
ricerca, allo sfruttamento delle risorse possedute e disponibili in rete.
�ݺ�ߣ 22
Per concludere con un sorriso, riciclo ancora una volta questa striscia nata durante un corso RDA.
Charlie Brown si rivolge al catalogatore Snoopy, che con il suo lap-top sforna schede classiche. Ma
si lamenta.
6

�ݺ�ߣ 23
Da adesso vuole legare i dati: da catalogatore vuole diventare catalegatore, from cataloguing to
catalinking.
--------------
7

�ݺ�ߣ

Koha RDA FRBR: alcune riflessioni (text)

More Related Content

Koha RDA FRBR: alcune riflessioni (text)