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.
In the mood for library 