Ogni tanto sento parlare di metaOPAC. Ne ha parlato Francesco Piras a proposito di quello sardo, poi sul blog del Polo SBN Ligure, oppure perchè c’è un progetto su un Portale delle biblioteche in Veneto oppure un altro progetto simile in Friuli.
Sembra che ogni regione ne abbia oppure cerchi di costruirne uno. Ah, poi c’è il MAI. Ma andiamo con ordine.
Il concetto di meta-motore è legato soprattutto a quello di deep web, ovvero alla enorme mole di informazioni che non è recuperabile dai comuni motori di ricerca. Fino a sei anni fa si stimava che l’insieme dei motori di ricerca avesse indicizzato circa il 20% dei contenuti disponibili sul web. Ora non so a quanto siamo arrivati, ma il concetto resta lo stesso, un motore di ricerca non indicizza tutto (e non sto parlando poi di cosa restituisce, solo di cosa indicizza).
Nel tempo sono nati quindi diversi strumenti (metamotori di ricerca o ricerche federate), per interrogare diverse fonti di informazione contemporaneamente e visualizzare i risultati in maniera omogenea. Il protocollo z39.50 c’era già prima del web, poi sono arrivati altri metodi (es. SRU/SRW). Tuttavia i metamotori spesso hanno alcuni limiti: la possibilità di usare solo un set limitato di parametri di ricerca; si basano su dati strutturati in modo omogeneo; sono vincolati alla disponibilità della risorsa esterna.
Per questo motivo l’ultimo trend, quello dei cosiddetti next generation catalogs o discovery tools, è di spostare la raccolta dati prima della ricerca da parte dell’utente (il cosiddetto harvesting tramite il protocollo OAI-PMH). In sostanza viene catturato l’intero patrimonio di dati presente sulla fonte esterna, quindi viene indicizzato e reso disponibile dal motore di ricerca. La cosa è molto comoda per diversi motivi: si possono aggregare dati eterogenei e quindi “sistemarli” prima dell’indicizzazione; si possono applicare strategie di ricerca più efficienti; in generale è tutto più rapido 😉
A questo punto resta il problema di come sono strutturati i dati che vengono scambiati.
Il formato standard per lo scambio di dati bibliografici è l’ISO 2709, un insieme di codici numerici e valori debitamente separati. Nel tempo le specifiche di questo formato sono state implementate in diversi modi (es. MARC21, UNIMARC) e il metodo più diffuso attualmente consiste nella rappresentazione in linguaggio XML della struttura dei dati. Addirittura, grazie allo sviluppo del web semantico, si sta iniziando a parlare più genericamente di formati per la descrizione di risorse (RDF), per cui magari al posto dei codici numerici avremo costrutti semanticamente significativi.
Dovendo implementare un metamotore di ricerca ci si pone quindi le seguenti domande:
- dove sono i dati
- come sono fatti questi dati
- di chi sono i dati
- a cosa servono
Rispondere alla prima domanda potrebbe aiutare notevolmente la diffusione e il riuso di dati, ovvero la consapevolezza del valore dei dati prodotti dall’istituzione.
La seconda invece ci ricorda dell’utente.
I discovery tool (così come prima i meta-motori) sono utilizzati più che altro in ambito accademico/scientifico, dove il servizio svolto dall’applicazione completa quasi sempre l’attività di discovery to delivery con un accesso immediato alla risorsa recuperata.
Cercando di applicare lo stesso meccanismo alle biblioteche di pubblica lettura, dove il “delivery” si risolve con il ritiro del materiale al bancone della biblioteca, mi chiedo se abbia senso investire in un meta-motore dal quale l’utente dovrà sempre e comunque essere rimbalzato ad un altro sito, magari il catalogo della biblioteca che possiede il titolo. A questo punto l’utente dovrà capire se il titolo è effettivamente disponibile o meno, se può prenotarlo o meno e in che modo ottenere l’eventuale interprestito. Questo moltiplicato per il numero di biblioteche/reti nel bacino sondato dal meta-motore.
Insomma, se volete realizzare un meta-motore per biblioteche di pubblica lettura, chiedetevi sempre per quale motivo lo state facendo, a cosa deve servire e chi dovrebbe usarlo. Se è per gli utenti, vagate nel web alla ricerca di esperienze simili e statistiche d’uso. Poi fatemi sapere cosa trovate.
Magari cercate anche di fare in modo che le biblioteche partecipanti al progetto abbiano una politica comune sull’interprestito e che l’applicazione realizzata alla fine sia chiara nello spiegarne i termini all’utente (non rimbalzatelo su un altro sito lavandovene le mani).
Personalmente, se volete realizzare un meta-motore….. non fatelo. Investite metà della somma a vostra disposizione per corsi tipo questo (qualcuno è andato? com’è stato? dalle slide mi sembra un corso entusiasmante!), il resto stanziatelo per mettere attorno al tavolo i responsabili dei cataloghi che vorreste ricercare, offrendogli le risorse per accordarsi sul servizio da offrire sul loro territorio.
Ah….un’ultima cosa importante….considerate il fatto che al giorno d’oggi nessun OPAC è più costretto a far parte del deep web. Grazie a progetti come la Open Library o Schema.org,ogni titolo del vostro catalogo può tranquillamente essere una pagina web indicizzata da normali motori di ricerca. Sapevatelo.
Sul corso che citi, posso tranquillizzarti: Greenstone è stato parte integrante del mio master, e nonostante il suo autore sia un tipo molto simpatico, il software è rigido, macchinoso, poco interessante. Oltretutto serve per gestire Biblioteche Digitali nell’accezione più povera, ossia collezioni di file e metadati, e non fa praticamente niente di integrato.
Su tutto il resto apprezzo il fatto che hai fatto utili riflessioni sull’evoluzione della metaricerca – in momenti in cui c’è bisogno di chiarezza, visto che l’altra settimana ho sentito un dirigente della Regione Piemonte parlare del futuro usando termini come il “Multi Opac” e altri concetti di vent’anni fa, e mi è venuto da piangere.
Infine, è utile ricordare che un Discovery Tool serve per integrare contenuti diversi per fonte e per formato, e pertanto si presta alle esigenze delle biblioteche universitarie; per le biblioteche civiche che maneggiano libri e materiali comunque catalogati in SBN – per quanto male e per quanto con standard inadatti – la catalogazione partecipata è sufficiente, magari se presentata in maniera moderna grazie alle funzionalità dei Next Generation Catalog. Ma non si tratta di Discovery Tool nel senso di motori di ricerca aggregata.
eh, non era un corso su greenstone, quello era solo l’ultimo post 😛
Il corso si chiamava “Accesso all’informazione e collaborazione virtuale” http://www.aib.it/aib/sezioni/toscana/formaz/co120109.htm e la cosa che mi ha intrigato di più era l’URL del sito del corso “competenze tecnologiche dei bibliotecari” 🙂
Il tuo post offre interessanti spunti di riflessione ed approfondimento.
Ragionando su un metaopac/metamotore (o come altro lo vogliamo chiamare), sono d’accordo nel partire definendo un obiettivo preciso: quale servizio voglio offrire agli utenti?
Questa domanda ovviamente ne presuppone un altra: chi sono gli utenti di questo servizio?
Chiarire e sviscerare bene il risultato che si vuole ottenere, analizzarne i pro e contro e le criticità, è fondamentale rispetto allo strumento tecnologico che si utilizzerà.
Che sia un metamotore o un discovery tool, per me l’importante è il risultato che si ottiene.
Il risultato secondo me deve essere:
1) gli utenti possono sapere che esiste un documento/media, all’interno di uno spazio definito, sia che esso sia un territorio fisico o virtuale (discovery)
2) gli utenti possono entrare in possesso di quel documento, sia che esso sia analogico o digitale (delivery)
Quello che nel mio post cercavo di mettere in luce è che, al di là della tecnologia utilizzata, le biblioteche e le loro risorse devono essere tutte equamente visibili a partire dai siti delle istituzioni, senza disparità di trattamento.
Ti faccio un esempio concreto: se io cittadino parto dal sito di un Ente (Regione, Provincia, Comune) dovrei poter ricercare allo stesso modo le risorse di tutte le biblioteche che fanno capo a quell’Ente. Raggiunto questo primo risultato, che sarebbe già un passo avanti enorme in Italia, possiamo anche pensare al delivery con tecnologie come Single Sign-On federato, tessera comune dell’Ente e prestito interbibliotecario (con i vari standard ILL).
Ben vengano le discussioni su questi temi per portare innovazione 🙂
“le biblioteche e le loro risorse devono essere tutte equamente visibili a partire dai siti delle istituzioni, senza disparità di trattamento.”
sacrosanto… per non parlare del Single Sign-On 🙂
riflessione precisa la tua, che condivido in pieno.
segnalo questa mail da un recente thread da code4lib, che va nella stessa direzione:
http://serials.infomotions.com/code4lib/archive/2012/201202/0732.html