Koha, RDA, FRBR : alcune riflessioniIntervento al convegno

METODI SCELTE STRUMENTI : IL NUOVO CATALOGO DELLA RETE URBS11 giugno 2015

Stefano Bargioni, Pontificia Università della Santa Croce

Slide 1Le 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.

Slide 2Che 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

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_2015.htm [5 giugno 2015].

1

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.

Slide 3Anzitutto 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).

Slide 4Tra 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.

Slide 5Portiamoci 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.

Slide 6Un 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

2

giorni questa lista, scaricando il file dalla LOC e inserendolo in Koha.

Slide 7Un 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.

Slide 8Una 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.

Slide 9Questa è 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".

Slide 10La 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 11Particolarmente 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

3

lavoro di traduzione del gruppo di Mauro Guerrini.

Slide 12Veniamo 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".

Slide 13Ecco 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.

Slide 14I 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

3 http://leo.cineca.it/index.php/jlis/article/view/8766 (consultata il 2015.06.07).

4

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.

Slide 15Vediamo 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.

Slide 16Conclusa 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

5

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.

Slide 17Le 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.

Slide 18Dieci anni fa Barbara Tillett rappresentava così le relazioni FRBR. Il punto è allora non solo come 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

4 http://www.loc.gov/marc/bibliographic/bd377.html (consultata il 2015-06-04).

6

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.

Slide 19Come 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.

Slide 20Sono 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.

Slide 21Un 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.

Slide 22Per concludere con un sorriso, riciclo ancora una volta questa striscia nata

7

durante un corso RDA. Charlie Brown si rivolge al catalogatore Snoopy, che con il suo lap-top sforna schede classiche. Ma si lamenta.

Slide 23Da adesso vuole legare i dati: da catalogatore vuole diventare catalegatore, from cataloguing to catalinking.

--------------

8