spingitori di spingitori di metamotori di ricerca

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

Esistono però anche altre due domande a cui sarebbe bello rispondere quando si cerca di implementare un meta-motore di ricerca:

• 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.

Don’t search our catalogues, search your browser!

Oggi è stata una giornata ricca di tweet interessanti 😛 Uno che mi è passato sott’occhio conteneva la frase: “Don’t search our catalogues, search your browser!“.

Mi è subito tornato in mente il Mycroft Project (e l’open search) e il fatto che probabilmente la nuova versione dell’OPAC SBN invalidava il plugin per Firefox. Così sono andato a correggerlo e ora funziona di nuovo 🙂
Lo trovate con questa ricerca e aprendo il link con Firefox vi chiederà automaticamente di aggiungerlo all’elenco dei motori di ricerca.

Probabilmente ne abuso un po’, tuttavia mi sembra una funzione estremamente comoda che permette di risparmiare inutili tempi di caricamento per dover comunque compilare un form di ricerca. Tra l’altro, se il sito lo prevede, durante la navigazione vi verrà proposto di aggiungerlo tra i motori. Attualmente ci sono 884 plugin per cataloghi di biblioteche (8 per l’Italia).

Allo stesso modo ho imparato come aggiungere un motore di ricerca a Chrome. E’ spiegato bene sulla guida di Chrome, ad ogni modo, per aggiungere rapidamente la possibilità di ricercare su SBN, basta cliccare la chiave inglese in alto a destra e quindi andare in Opzioni (o Preferenze). Dalla scheda Impostazioni di base vi basta cliccare sul pulsante Gestisci motori di ricerca… per aprire un riepilogo dei motori che potete usare. In fondo troverete la possibilità di aggiungere una nuova riga, simile alla seguente:

dove l’URL bordato di rosso dovrebbe contenere:

http://opac.sbn.it/opacsbn/opaclib?db=solr_iccu&select_db=
solr_iccu&from=1&searchForm=opac%2Ficcu%2Ffree.jsp&result
Forward=opac%2Ficcu%2Fbrief.jsp&do_cmd=search_show_cmd&struct
%3A1016=ricerca.parole_tutte%3A4%3D6&item%3A1016%3AAny=%s

Se come me avete impostato “sbn” come parola chiave per usare quel motore, vi basterà digitarla nella barra degli indirizzi, seguita da spazio (o tab), quindi dalla stringa di ricerca, per ottenere immediatamente i risultati.

P.S. mentre scrivevo l’articolo mi son detto “… e perchè non fare un plugin anche per il MAI – MetaOPAC Azalai?” Così ho fatto anche quello (per titolo, su tutti i cataloghi e tipi di documento), che però non può funzionare allo stesso modo per Chrome visto che il passaggio di parametri ad Azalai è un pelo più complesso. Ad ogni modo ricordo l’indicazione riportata sul sito del metaopac: “Questo metaOPAC è indicato per la ricerca di documenti poco comuni non trovati in altri cataloghi italiani. Usarlo come strumento di ricerca primario è sconsigliabile, perché produce risultati sovrabbondanti e rallenta il funzionamento.”

letture stimolanti e parenti di investigatori famosi

Un libro altamente consigliato ai lettori di questo blog è Library Mashups: Exploring New Ways to Deliver Library Data.

E’ in inglese ma potete trovare alcuni interessanti riferimenti in italiano sul blog di Bonaria Biancu, The geek librarian, che ha scritto il secondo capitolo.

L’aspetto più interessante del libro è che si rivolge soprattutto ai bibliotecari, introducendoli ad un linguaggio un po’ più “informatico” e alle potenzialità degli strumenti che hanno già a disposizione. In questo senso ci sono sia “buone pratiche” utilizzando software open source, che spunti interessanti per combinare diversi dati in modo nuovo ed efficace.

Sono stato molto stimolato dal capitolo sui microformati (magari qualcuno che mi segue su twitter avrà notato un po’ di entusiasmo per banali implementazioni di COinS). Più in generale credo sia entusiasmante vedere quanto si può fare anche in condizioni non ottimali, semplicemente lavorando su feed rss o applicando un minimo di conoscenze di html e css (suggerimento: dopo esservi letti qualche minimo tutorial sul tema, installatevi Firebug e iniziate a “fare le pulci” ai siti che vi piacciono per vedere, almeno in parte, cosa c’è dietro…)

Il tutto mi ha ricordato del Mycroft Project, ovvero di quanto semplice sia implementare la ricerca in un qualsiasi sito nella finestrella di ricerche rapide integrata in Firefox (ma in verità grazie a OpenSearch la cosa funziona anche su altri browser). Personalmente ne faccio ampio uso e, se così fosse anche per voi, magari vi viene voglia di creare un plugin per il vostro OPAC. Ad esempio come è stato fatto dal buon Bilal per SBN.

Ma lo sapevate che Mycroft era il nome del fratello di Sherlock Holmes? 🙂