Di questo servizio abbiamo già parlato ma mi fa piacere riprenderlo attraverso il capitolo 11 di Library Mashups (come sapete, nell’esplorazione dei vari capitoli, non procederemo con ordine :-), intitolato Mashing Up Open Data with biblios.net Web Sevices e scritto da Joshua Ferraro di LibLime.
All’inizio del 2009 la società che vende servizi per software open source, LibLime, ha rilasciato un servizio di catalogazione gratuito, web based e che poggia su una base di milioni di record bibliografici liberamente adoperabili (openly licensed): biblios.net. In particolare, il capitolo si focalizza sui servizi web (web services) offerti da LibLime insieme al software di catalogazione e alla base dati di record.
I biblios.net Web Services (BWS) poggiano su una conquista fondamentale: gli Open (Bibliographic and not) Data, che a loro volta consentono la libertà e gratuità di intervenire sui record bibliografici, sui metadati prodotti dalle biblioteche e rilasciati/messi a disposizione di tutti attraverso licenze dedicate. Questo dei dati è sempre stato un grosso ostacolo nel mondo bibliotecario – e chi frequenta questo blog da un po’ lo sa bene. Spesso i molti e ricchi e riccamente strutturati metadati che i bibliotecari con grande fatica e sudore di fronte creano quando catalogano i libri, rimangono poi confinati entro ILS (software di automazione e catalogazione) proprietari o comunque chiusi alla possibilità del rilascio libero e del riutilizzo (al netto delle esperienze di catalogazione cooperativa, che però sono un’altra cosa).
Joshua Ferraro, invece, mette subito in rilievo lo slancio che la nascita di licenze come la PDDL (Open Data Commons Public Domain and Dedication Lincese) e di iniziative di apertura dei forzieri dei propri metadati prese da biblioteche come la Library of Congress o la Open Library di Brewster Kahle, ha dato all’impresa di LibLime, di rilasciare nel pubblico dominio così grandi quantità di record bibliografici a disposizione di tutti (di nuovo, se n’era parlato qualche tempo fa). Recod bibliografici che sono stati poi utilizzati dalla stessa LibLime per i suoi servizi e in particolare per la creazione di un livello di accesso e di interrogazione (le famose API, Application Programming Interface) concreto e usabile da tutti gli utenti.
I BWS sono infatti proprio un set di API create per consentire ai programmatori o geek librarian che dir si voglia, di scrivere applicazioni che interagiscano con il database di biblios.net e creare quindi mashup con i dati e i servizi ritornati da questo provider. I web services disponibili sono attualmente:
-
Searching for bibliographic and authority records (OpenSearch, SRU/W and Z39.50)
-
Retrieving single records (UnAPI)
Verranno invece presto attivati i seguenti:
-
Download the ‡biblios.net Dataset (BitTorrent) (coming soon)
-
Programming Guide (coming soon)
- API Reference (coming soon)
Uno degli interessanti esempi mostrati nel capitolo, è il mashup creato grazie al SRU target service, che restituisce i dati delle liste di autorità contenute nella base dati di biblios: il catalogatore che stia inserendo nella scheda catalografica di un volume una cosiddetta voce controllata (potrebbe essere quella del nome dell’autore oppure del soggetto/topic con cui si classifica il volume), può attingere on the fly alle voci controllate conservate e messe a disposizione da biblios, attraverso un semplice ed efficace menu ad auto-complete – in questo modo non solo potendo attingere a dati uniformi, controllati e di qualità, ma anche evitando di perdere tempo nell’andare a interrogare separatamente un altro database.
L’altro esempio che Ferraro propone è quello relativo agli strumenti per facilitare la catalogazione cooperativa delle biblioteche, sempre usufruendo dei web services messi a disposizione da biblios. In questo caso si sfrutta la potenza del protocollo OAI-PMH, dei feed RSS e del buon vecchio Z39.50, per costruire un mashup di notifica e aggiornamento delle modifiche avvenute su un record: le biblioteche in una rete cooperativa possono così venire a conoscenza dei cambiamenti intervenuti su una scheda che è stata già acquisita dal catalogo e, se del caso, anche decidere di accogliere quei cambiamenti, sovrapponendo la scheda catalografica modificata con quella del proprio OPAC, in maniera del tutto rapida e automatizzata.
Forse questo capitolo è il più interessante di tutti almeno sotto un profilo: mostra come il catalogo e la catalogazione non solo non sono esclusi, in quanto ambiti di attività tradizionali, dalla creazione di servizi innovativi e mashup, ma possono con la loro ineludibile centralità venire impattati pesantemente dalla creazione di servizi agili, in grado di eliminare le parti più ripetitive e meccaniche di certe attività e aprire la strada alla creatività nell’utilizzo delle informazioni e dei dati contenuti negli OPAC, frutto di anni e anni di lavoro delle migliori menti bibliotecarie…
Etichette: API, library mashups, open data, SRU, web of data, web services, z39.50
30 novembre 2009 alle 4:39 pm
[...] alcune applicazioni in rete hanno portato nella cloud la catalogazione (Biblios.net su cui si veda qui e SkyRiver) Anche il maggior consorzio bibliotecario mondiale OCLC mira a fornire un servizio a [...]
9 dicembre 2009 alle 10:13 am
A proposito del paragrafo finale, mi vengono in mente due riflessioni, anche a seguito di quanto si è discusso al seminario ITALE:
1) parlare di cooperazione, interoperabilità e riusabilità dei metadati è ormai imprescindibile, e lo sappiamo. Ma nel mondo dei documenti digitali è più che imprescindibile: è davvero l’unica strada. Non solo per questioni di economia (si risparmia) e di agilità (si fa prima), ma soprattutto per omogeneità: perché fare diecimila volte lo stesso lavoro, rischiando di farlo in maniera differente, quando alla fine il documento che viene catalogato è lo stesso?
2) in questo contesto, nel quale i documenti nascono già digitali, il metadato *deve* essere fornito insieme al documento. Quanto a lungo potremo ancora pensare all’attività di catalogazione tradizionale? Quanto ancora prevarrà la necessità di assegnare a posteriori a un documento una “descrizione” esterna ad esso, soprattutto quando la vastità del “docuverso” digitale comporta il trattamento di migliaia di record alla volta? Si è ancora lontani sicuramente dal giorno in cui gli editori forniranno dei metadati standard, omogenei, coerenti e usabili direttamente, ma allo stato attuale credo che il ruolo del bibliotecario-catalogatore sia ormai vicinissimo a una trasfigurazione. Finirà il mondo dei catalogatori, e inizierà l’epoca dei gestori di metadati.
13 dicembre 2009 alle 3:25 pm
Caro Enrico, grazie di nuovo per le cose interessanti che riporti. Sono completamente d’accordo con te: intanto, con l’esigenza di interoperabilità per i contenuti digitali. Come scrivevo qualche commento fa, i contenuti nei nostri database dovrebbero essere unici, descritti in formati codificati e contenuti in database accessibili con interfacce standard, in modo che si possano riutilizzare a piacimento, senza che ogni volta si debbano ricreare. Può bastare un’API o una mappatura coerente per rendere interoperabile il dato digitale e ormai non possiamo più pensare di essere al riparo al chiuso dei nostri chiusi sistemi (ILS e simili). Siamo ormai in un universo – talvolta caotico, comunque in continua espansione – che chiede il rispetto di certe regole, per poter aspirare a sistemi economici e agili.
Poi, l’acquisizione dei metadati: su questo c’è dibattito in corso – sulla qualità e la tipologia dei record descrittivi, intendo. Mi pare comunque che i principali editori – in particolare quelli che pubblicano digitale – si siano orientati tutti sulla vendita di dato e metadato. Ne parlavo qualche sera fa con Angiolini, del Mulino, a proposito della loro nuova piattaforma di e-book, Darwin Books, e della utilità di offrire alle biblioteche sia il contenuto che il record MARC associato. Per non dire, poi, che sperabilmente con l’evoluzione delle tecniche di intelligenza artificiale, linguistica computazionale e web semantico, il record MARC o perfino quello Dublin Core potrebbero diventare un lontano ricordo :-)
15 gennaio 2010 alle 2:57 pm
E’ la prima volta che sento dire quello che sostengo da tempo: il MARC è vecchio. Tutta la logica associata al MARC (compresa la monoliticità degli ILS) sta per cadere, sotto i colpi dell’interoperabilità, del web semantico, ecc. Ci vorrà tempo, ma la catalogazione dovrà orientarsi a collegare informazione, non a scriverla e riscriverla sempre uguale, derivata o meno che sia.
15 gennaio 2010 alle 3:50 pm
@Stefano,
se è la prima volta che lo senti dire si vede che non conosci Tennant…
non riesco a immaginare niente di più esplicito di “MARC must die”, datato 2002 ;-)
15 gennaio 2010 alle 4:00 pm
Ho sentito spesso parlare della “morte del MARC” ma non ho mai capito bene le argomentazioni “concrete” (anche se posso immaginarle e, preventivamente, persino condividerle). Stavo per chiedere a Stefano di argomentare, poi Shaitan ha citato Tennant, ho fatto una rapida ricerca e ho trovato quello che cercavo. Condivido il link all’articolo di Tennant (Library Journal 10/15/2002):
http://www.libraryjournal.com/article/CA250046.html
17 gennaio 2010 alle 1:57 pm
Ciao, grazie dei commenti e dei riferimenti sitografici :-)
La mia domanda a questo punto è: con cosa sostituiremo il MARC? Già qualche post fa io e Shaitan avevamo avuto una discussione in merito al Dublin Core e alla necessità di integrarlo. La mia perplessità era (ed è) che a forza di integrare il DC (cosa peraltro necessaria), si potrebbe arrivare a re-inventare la ruota del MARC ;-)
18 gennaio 2010 alle 11:26 am
Generalmente chi sostiene un abbandono del MARC lo fa verso soluzioni più agili come MODS (se non, rilanciando la ricerca di Martha Yee, direttamente in RDF [1])…
queste risultano più agili sia per l’uomo (beh title subtitle e nonsort sono un po’ più leggibili e memorizzabili di 245 $a $b e secondo indicatore…)
ma soprattutto per la macchina, basti pensare a un’espressione xpath per creare indici per titoli su records mods e sui i corrispettivi records marcxml…
voglio dire /mods/titleInfo/title è un po’ più semplice e leggibile di qualcosa tipo (l’ho scritta al volo quindi sarà sbagliata) substring(/record/datafield[@tag='245']/subfield[@code='a'], /record/datafield[@tag='245']/@ind2)
Ma il solito Alexander Johannensen forse lo esemplifica meglio [2]
Giustamente il problema è che la maggior semplicità coincide con una minore granularità semantica (il caso estremo è appunto il set base di dublin core dove i campi quelli sono e, volenti o nolenti, un soggetto produttore ti diventa creator o, peggio, un soggetto conservatore publisher con conseguente mal di pancia pe noi archivisti :-D )
Il problema, tornando ai record bibliografici, è appunto cosa può esprimere mods (che ha sicuramente dei limiti, soprattutto per determinate tipologie documentarie, e su questo si sta ragionando per un’ipotetica versione 4 dello schema) [3] e se la complessità del marc è davvero vantaggiosa in termini di ricchezza di informazioni [4] e quanto i vari campi siano usati nella pratica [5]
Certamente bisognerà trovare un punto di equilibrio.
Ritengo però estremamente interessanti i tentativi di Yee (anche perché la mia tesi propone alcune cose simili per i dati archivistici, quindi sto tirando acqua al mio mulino)
Metto i riferimenti in un altro post perché sicuro verrà bloccato da askimet vista la quantità di link.
18 gennaio 2010 alle 11:26 am
[1] Martha M. Yee, Can Bibliographic Data Be Put Directly Onto the Semantic Web? http://www.escholarship.org/uc/item/91b1830k
[2] Alexander Johannesen MARCXML: Beast of burden http://shelter.nu/blog/2008/09/marcxml-beast-of-burden.html
18 gennaio 2010 alle 11:27 am
[3] Goldsmith – Knudson Repository Librarian and the Next Crusade: The Search for a Common Standard for Digital Repository Metadata http://www.dlib.org/dlib/september06/goldsmith/09goldsmith.html
[4] Roy Tennant The Unused Complexity of MARC http://www.libraryjournal.com/blog/1090000309/post/1730049773.html?nid=3565
[5] MARC Content Designation Utilization – Results of Frequency Counts Analysis http://www.mcdu.unt.edu/?p=43
23 marzo 2010 alle 4:14 pm
[...] anche le discussioni fatte su The Geek Librarian, mi viene in mente come la prassi quotidiana della catalogazione sia qualcosa che fra non molto [...]
28 aprile 2012 alle 2:07 pm
Ciao, mi chiamo Marco e vivo in Sierra Leone. Nella Universita` in cui insegno (University of Makeny http://www.unimak.edu.sl) abbiamo bisogno di un programma semplice per la biblioteca, fai conto che non abbiamo fino a questo momento una connessione internet in biblioteca.
Quello che ci servirebbe sarebbe un programma che tenesse d’occhio i prestiti, qui nessuno riporta libri, e tutto dalla lista dei libri al prestito e` segnato su grandi quadernoni che poi nessuno va piu` a consultare.
Sto usando Ubuntu 12.04 pensi che open biblio vada bene per il mio caso o e` meglio usare un altro programma? Nel caso potresti indicarmene uno adatto al nostro caso?
Grazie dell’aiuto.
Marco