Q UALCHE PROPOSTA OPERATIVA

Che gli OPAC italiani (e non solo) siano destinati a cambiare e a evolversi può sembrare un'affermazione scontata, se non altro in considerazione della loro natura di applicazio- ni web per gli utenti, ossia di strumenti nati in un settore in costante mutamento. Le tempistiche del cambiamento, tuttavia, sono già più incerte: come sottolineato nel capi- tolo precedente, occorre che le novità proposte in ambito internazionale vengano riela- borate e integrate organicamente nelle tradizioni catalografiche nazionali, prima di po- ter riscontrare cambiamenti concreti nei nostri futuri cataloghi.

La natura stessa di questi cambiamenti, poi, può essere oggetto di ulteriori riflessio- ni, tutt'altro che definitive. Se da un lato cominciano a diffondersi anche in Italia le aziende in grado di fornire alle biblioteche soluzioni basate sui linked data (spesso pre- sentati come servizio aggiuntivo rispetto alla strutturazione tradizionale dei dati biblio- grafici)79_{, dall'altro questo tipo di soluzioni non è ancora pienamente disponibile per le} biblioteche pubbliche e la stessa biblioteconomia italiana sembra aver bisogno di più tempo per stabilire le regole con cui appropriarsi di questa tecnologia.

I cambiamenti degli OPAC italiani proposti in questa ricerca, in realtà, non sono strettamente collegati allo sviluppo tecnologico e, a mio modesto parere, potrebbero

79 È il caso, per esempio, del nuovo software di gestione implementato da DM Cultura, SebinaNEXT: oltre a salvare i dati bibliografici nel formato UNIMARC, il programma dà la possibilità di visualizzarli anche in formato BibFrame. La funzione per ora non sembra avere altro scopo che quello di conservare i dati in un formato alternativo e renderli dunque disponibili per eventuali trasferimenti; appare ancora lontano, perciò, il momento in cui la struttura dei linked data giungerà a influenzare direttamente le interfacce OPAC.

contribuire a migliorare l'esperienza che gli utenti vivono con i cataloghi delle bibliote- che pubbliche. Per attuare queste modifiche, dunque, non sembra necessario attendere la fine del periodo di transizione, quando le biblioteche avranno elaborato una strategia per accorpare le novità proposte da IFLA-LRM, RDA, BibFrame. Si tratta di aggiustamen- ti che, ovviamente, richiederebbero comunque uno sforzo non trascurabile da parte dell'azienda che volesse metterli in pratica; avrebbero, però, il vantaggio di essere indi- pendenti dagli standard internazionali e quindi gestibili con una certa libertà.

3.1 C

G

.

A corredo dell'indagine compiuta in questa ricerca, perciò, è stato implementato un prototipo di applicazione OPAC, chiamato CataloGo., che prova a considerare tutti i mi- glioramenti suggeriti.

L'applicazione web è stata sviluppata principalmente in PHP e dialoga con un data- base SQL. Il database è stato implementato manualmente e, nell'ottica di realizzare un'interfaccia ispirata ai concetti di IFLA-LRM, i dati sono stati strutturati in tabelle che rispecchiano le entità usate nel modello, specialmente per quanto riguarda le entità che in FRBR appartenevano al Gruppo 1: esistono quindi le tabelle works, expressions, manife- stations e items, oltre a numerose altre tabelle utili a rappresentare gli autori (creators), le relazioni fra opere (work_relations), eccetera. I dati, perciò, non sono stati salvati nel formato UNIMARC e non c'è stato bisogno di creare una mappatura fra UNIMARC e FRBR/LRM, passaggio che invece risulterebbe indispensabile se si volesse convertire ai concetti LRM l'interfaccia di uno degli OPAC 'reali' analizzati in questa ricerca.

Il database contiene più di 30 diverse Opere e, man mano che i livelli si fanno più ap- profonditi, si espande fino a contare circa 80 Items; rispecchiando la tripartizione dei li- velli suggerita da BibFrame e accolta già da altre esperienze italiane, le due tabelle ex- pressions e manifestations sono state accorpate in un'unica vista80_{, chiamata manifpres-}

80 In un database, una vista è una sorta di tabella virtuale che, senza aggiungere nuovi dati, permette di rappresentare in modo alternativo i dati che già sono presenti. Nel caso di CataloGo., la vista manifpres-

sions, che costituisce quindi l'unico livello intermedio fra Opere e Items. L'inserimento manuale dei dati è stata una scelta dettata sia all'oggettiva difficoltà di elaborare in soli- taria una mappatura verso LRM che gestisse tutta la complessità del formato UNIMARC, sia dalla possibilità di inserire velocemente nel sistema quelle risorse bibliografiche utili a eseguire, in CataloGo., le stesse ricerche svolte sugli altri OPAC durante l'indagine. Il database contiene quindi diverse opere di Jo Nesbø, oltre a risorse riguardanti l'adde- stramento dei cani e la storia dell'informatica; dal punto di vista del collegamento fra opere, la tabella work_relations garantisce la creazione di questa connessione e permette poi di gestirla nell'interfaccia.

CataloGo. è stato implementato tenendo inconsiderazione prevalentemente la ma- schera di ricerca libera, quella solitamente privilegiata dagli utenti delle biblioteche pubbliche81_{: nella homepage dell'applicazione è stato previsto un link per condurre a una} scarna maschera di ricerca avanzata, che si è scelto di non sviluppare. Nell'ottica di ri- specchiare maggiormente la realtà contemporanea degli OPAC italiani, CataloGo. è stato progettato come un OPAC di più biblioteche (sono state inserite in modo piuttosto ca- suale le biblioteche dei comuni vicini a Pordenone82_{, oltre che la stessa biblioteca civica} del capoluogo); alle biblioteche, inoltre, sono stati affiancati altri contenitori di risorse, quelli digitali. Il database contiene infatti manifestazioni digitali e libere da copyright di alcune delle opere considerate: ebook, audiolibri, interviste conservate online su Project Gutenberg, Liber Liber, LibriVox, YouTube, SoundCloud. Questi siti sono stati trattati alla stregua di singole biblioteche e accomunati a esse nella tabella containers (conteni- tori di risorse). La descrizione di una risorsa contenuta in questi siti presenta, al posto di una segnatura di collocazione, direttamente il link esterno alla risorsa online.

Le pagine realizzate per l'applicazione sono le seguenti:

sion permette di raggruppare in un unico luogo i dati delle due tabelle expressions e manifestations: l'unio-

ne delle due tabelle (che è solo virtuale) avviene grazie al numero identificativo delle Espressioni.

81 Nella sua indagine di usabilità sull'OPAC della biblioteca di Musicologia dell'Università di Pavia, Carlo Bianchini sottolinea che la ricerca 'Google like' è effettivamente la più usata, senza che ciò risulti partico- larmente sorprendente, forse anche perché è il tipo di ricerca che viene presentato per primo in evidenza all'utente [Bianchini 2017a, p. 32].

• home.php (Figura 5), da dove è possibile lanciare una ricerca libera specificando, se si desidera, la biblioteca o il contenitore in cui cercare; la pagina contiene inol- tre i link ai paragrafi Aiuto e Che cos'è CataloGo.;

• search.php, cui si arriva dopo aver lanciato una ricerca e che carica di volta in volta il contenuto selezionato dalle interazioni dell'utente. La pagina ha una struttura a F con due fasce perpendicolari, in alto e a sinistra: la prima contiene le maschere di ricerca, per poter effettuare una nuova interrogazione senza do- ver tornare alla home; la seconda presenta i link atti ad approfondire il contenuto della pagina vera e propria: nel caso dei risultati di una ricerca, vengono presen- tate le faccette attraverso cui scremare le risorse ottenute;

• results.php è la pagina che carica effettivamente i risultati della ricerca immessa e viene incastonata nel centro di search.php. Come si vedrà più avanti, i risultati sono differenziati in due tab separate a seconda che siano opere (e quindi risorse bibliografiche) oppure creatori;

• bookvisual.php è la pagina dedicata a una singola opera e viene a sua volta cari- cata dentro a search.php. Presenta in alto la trama e le collocazioni di tutte le espressioni/manifestazioni; poco più sotto, è possibile selezionare una singola manifpression, in base al proprio interesse, e visualizzare le collocazioni relative solo a quella risorsa. Nella fascia laterale compaiono, se esistono, le opere colle- gate a vario titolo a quella che si sta visualizzando;

• creatorvisual.php è la pagina dedicata a un'entità creatrice di contenuti, senza particolare distinzione fra Persona e Agente Collettivo; anch'essa si carica all'interno di search.php. Oltre a una breve descrizione biografica, vengono elen- cate separatamente quali opere, fra quelle presenti in CataloGo., sono state create dall'agente oppure sono state realizzate su di esso in quanto soggetto.

Quasi tutte le pagine si avvalgono di istruzioni JavaScript per gestire la visualizzazione delle informazioni e l'interazione con l'utente. Per interrogare il database, le entità de-

scritte nelle varie tabelle SQL sono state fatte confluire in altrettante classi PHP. Il file functions.php contiene tutte le istruzioni necessarie al funzionamento dell'applicazio- ne, prima fra tutte la funzione di ricerca: questa verifica anzitutto se l'input immesso dall'utente in fase di ricerca è costituito da una o più parole e, a seconda della situazio- ne, procede con operazioni differenti.

Dopo aver brevemente descritto le principali caratteristiche di CataloGo., procedia- mo ora con l'analisi delle possibilità offerte, elaborate in base alle osservazioni degli OPAC delle biblioteche pubbliche italiane.