Zombie in biblioteca

Tempo fa parlavo di fumetti, e di quanto poco questo medium straordinario sia stato sfruttato a fini educativi: mi chiedevo soprattutto se ci fosse qualche interessante esperienza dell’impiego del fumetto all’interno delle biblioteche, o della scienza dell’informazione in generale.

Ecco che giusto ieri scopro tramite Linkedin una vera perla: una guida ai servizi della Miller Library del McPherson College (Kansas).

A fumetti.

Con gli zombie!

Il divertentissimo fumetto di 15 pagine (scaricabile da questo link) riprende i temi dello zombie splatter ma anziché ambientarli nel classico ospedale li trasporta nella biblioteca del campus, nella quale due impauriti studenti si rifugiano per essere eruditi da un magro e barbuto bibliotecario (lo so, se fosse stato anche pelato la mia eccitazione sarebbe stata un tantino più incontenibile).

Il bibliotecario della Miller Library (immaginatelo pelato)

Con l’ironia tipica del genere vengono illustrati l’ordinamento delle raccolte secondo la classificazione Dewey, il ruolo degli addetti al reference, la collezione musicale (con una divertente citazione da Shaun of the Dead). Avrei gradito un po’ più di riferimenti alle collezioni digitali, ma riconosco che è più facile decapitare uno zombie con un 33 giri in vinile che con una ricerca su Metalib (sempre a proposito di morti viventi).

Al termine del fumetto sono riepilogate, in maniera appena più discorsiva ma non priva dello stesso tono divertito, informazioni più dettagliate sui servizi: il funzionamento delle collocazioni, come effettuare ricerche efficaci nel catalogo, come cercare i periodici elettronici nelle banche dati online. Notevole anche la lista di piccoli accorgimenti per valutare la qualità di una risorsa online: quel tipo di informazioni bibliografiche pratiche che secondo me sono l’essenza di ciò che deve fornire una biblioteca, così come il flowchart finale per una corretta ricerca bibliografica.

Ammirevole.

P.S.: Ringrazio Rexford Quick per questa chicca.

Zombie in biblioteca

Who de-sucks the de-suckers?

Ulteriori riflessioni sui sistemi di ricerca federata e gli opac arricchiti (ossia gli opac 2.0, i de-suckers: AquaBrowser, Primo, VuFind, Endeca, ecc. ecc.)

A parte il fatto che ognuno si vende un po’ come vuole, definendosi in maniera ottimistica e promettendo cose che poi sono tutte da vedere, quello che ci deve far riflettere è: qual’è il rapporto fra sostanza e superficie?

Va bene arricchire l’opac (de-schifizzarlo, come dicono i blog anglosassoni che parlano continuamente di unsucking the opac) con funzionalità bibliografiche ormai imprescindibili (clustering, cronologia delle ricerche…) o con gli ormai consueti servizi 2.0 (rss, commenti, ecc.).

Questo va bene per quanto riguarda l’interfaccia e la presentazione dei dati. Ma quanto ai dati stessi?

La chimera odierna è quella di avere un unico strumento per gestire e presentare tutte le tipologie documentarie della biblioteca ibrida. Libri, periodici, e-journals, archivi istituzionali, siti web, metadati bibliografici esterni, accesso ai full-text, e-books. Ma da dove raccogliere questi dati?

Gli opac arricchiti non sono in grado di indicizzare la quantità totale dei metadati utili. Sono in grado di raccogliere tramite harvesting i metadati locali (il proprio catalogo, il proprio deposito istituzionale) ma per l’accesso alle fonti esterne (in primis le banche dati commerciali per i metadati bibliografici) devono necessariamente passare attraverso un motore di ricerca federata o metaricerca (WebFit, Metalib, ecc.) che vada a raccogliere questi dati. Ma a questo punto i metadati così raccolti giungono nella base dati del nostro opac con tutti i limiti della metaricerca (ossia tracciati ridotti all’osso, quando va bene).

Alla fine ci troviamo con un opac arricchito, funzionale, perfettamente in linea con i servizi web 2.0, ma che avrà, nella ricerca bibliografica, gli stessi limiti degli strumenti precedenti.

… continua

Who de-sucks the de-suckers?

Avere gli agganci giusti

Mi viene confermato quel che sospettavo. I grandi software di metaricerca e ricerca federata (Metalib, Primo, ecc.) vengono venduti insieme a un pacchetto di configurazioni molto ricco, ed è quest’ultimo a far levitare il prezzo.

Oltre al software, quindi alle funzioni di base, il valore aggiunto di alcune case su altre è l’insieme di configurazioni già predisposte che vengono fornite insieme al sw, ossia tutti gli “agganci” (hook) con un numero esteso di risorse che consentono al motore di funzionare.

Il costo dei sw quindi si deve più che allo strumento in sé al lavoro di configurazione che viene fornito (e tenuto aggiornato!) dalla ditta.

Questo è un elemento decisivo da considerare al momento della scelta di un sw – specialmente di un sw open-source. Oltre alla qualità dello strumento occorre valutare la quantità di “agganci” già pronti: non averli può costare all’istituzione proprietaria un lavoro di configurazione arduo, lungo, e forse più dispendioso.

E’ vero però anche un aspetto inverso: occorre valutare che gli agganci forniti dal sw siano effettivamente utili. Pagare a caro prezzo una knowledge base di n risorse delle quali a me ne servono soltanto poche decine può non valere la pena- specialmente quando le risorse a me utili non sono comprese! Un caso esemplare è quello di Metalib, che ci fornisce l’hook a n opac di tutto il mondo, ma non agli opac Sebina che in Italia sono numerosi.

Allo stesso modo può convenire indirizzare i propri sforzi sulla configurazione di poche risorse utili, e condividere la configurazione degli hook con altre istituzioni. Insomma, partire da una knowledge base vergine o minimale, e alimentarla col contributo di una comunità.

Avere gli agganci giusti