Ciao Francesco,
grazie per la tua valutazione.
Per quanto riguarda il discorso sui limiti dell'opac dell'Indice SBN (problema sollevato a Roma da Vanni Bertini) e la risposta di Caffo: è stato un argomento che come molti altri è stato toccato molto rapidamente mentre sicuramente merita molti approfondimenti.
Comunque hai ragione a sollevare qualche dubbio se la questione della visualizzazione delle informazioni di disponibilità nell'opac dell'Indice debba sovrapporsi alla quesitone della certificazione.
Vale a dire: non si può pensare a degli accordi di livello un po' più informali, per così dire, cioè non del tipo assolutamente vincolante come è il processo della certificazione? Lo dico per rilanciare la mia proposta di qualche e-mail fa: adottare anche in Italia l'accordo americano del 2008 per un API standard dedicata all'esposizione aperta dei dati di disponibilità da parte dei gestionali: accordo sponsorizzato dalla Digital Library Federation che ha creato il gruppo di lavoro ILS Discovery Interface Task Group (ILS-DI) da cui è uscito il documento di raccomandazioni tecniche: "An API for effective interoperation between integrated library systems and external discovery applications": http://www.diglib.org/architectures/ilsdi/DLF_ILS_Discovery_1.1.pdf Il documento riporta in appendice The Berkeley Accord, Spring 2008 e i firmatari.
In Italia ne aveva parlato Valdo Pasqui nell'articolo: *Evoluzione dei sistemi di gestione bibliotecaria tra vecchi e nuovi paradigmi,* in «Bollettino AIB», vol. 49 n. 3 (settembre 2009), pp. 289-306. http://bollettino.aib.it/article/view/5455/5220 Ma sembra che nessuno ci abbia fatto caso e abbia implementato quelle soluzioni. Ora questo ritardo è dovuto al fatto che nessuno aveva un discovery tool o un next generation opac, per cui non c'era bisogno di far dialogare sistemi diversi. Ma adesso il panorama è cambiato: ci sono almeno 2 next generation opac del tutto indipendenti dal gestionale (Aqua browser nel caso della Regione Toscana; VuFind nel caso della biblioteca Braidense e del Polo SBN di Biella). Poi ci sono le università che hanno adottato un discovery tool prodotto da una ditta completamente diversa dal gestionale: sono ormai un certo numero e avrebbero bisogno di visualizzare nel discovery tool le informazioni di disponibilità, magari adottando l'API definita negli Strati Uniti, perché no?
E la stessa evoluzione potrebbe fare l'opac SBN. Anche lì con le stesse modalità potrebbero essere visualizzate le informazioni di disponibilità.
Anzi: facciamo come dice Giulio Blasi e riprendiamo a sognare: ipotizziamo un next generation opac che funzioni come l'applicazione WorldCat Local: ma basato su SBN. Chi lo implementa avrà i risultati di posseduto della sua biblioteca che saranno visualizzati secondo un ordine di rilevanza mettendo ai primi posti il posseduto locale e poi tutti i dati dell'Indice SBN (WorldCat Local funziona così). Quello escogitato da WorldCat Local è un compromesso che mi pare sensato tra 2 esigenze altrimenti opposte: fare vedere tutto l'Indice e allo stesso tempo rispondere al bisogno degli utenti di individuare innanzitutto il posseduto a portata di mano della propria biblioteca.
Ora: siamo sicuri che per fare tutto questo ci sia bisogno di "certificazione"? Non basta raccogliere le ditte attorno a un tavolo e dire: vorremmo migliorare l'opac SBN in questo modo e abbiamo bisogno della vostra collaborazione, cioè che implementiate tutti la stessa API per l'esposizione delle informazioni di disponibilità?
In America lo chiamano trovare un accordo: che significa che non c'è nulla di obbligatorio, chi vuole partecipa, chi non vuole sta fuori. Il punto è che il mercato americano è un vero mercato: cioè saranno i clienti a decidere se il fatto che un software non implementa una certa funzione è un punto a sfavore nella scelta. Ma il mercato funziona positivamente solo se possiede clienti liberi di scegliere e capaci di farlo: capaci di pubblicare richieste di fornitura con allegati documenti tecnici (Request for proposal) a cui le ditte rispondono e poi i bibliotecari valutano. In Italia la chiamiamo gara d'appalto e quando chiedo in giro è rarissimo che si faccia una gara in biblioteca per la fornitura di un software: che sia il gestionale o un next generation opac. Solo grossi sistemi che per l'entità della cifra non possono ovviare alla gara d'appalto, la fanno. Se possono, le biblioteche non fanno quasi mai gare d'appalto anche per non incorrere nelle trafile burocratiche. Ma così non imparano a fare documenti tecnici di richieste, a informarsi in prima persona, a parlare con le ditte in maniera informata stando sullo stesso piano e non accettare tutto a scatola chiusa. È per questo motivo che gli standard hanno vita tanto difficile in Italia: perché le biblioteche hanno più interesse di una ditta a adottarli per l'ovvia ragione che così si spianano la strada sia a cambiamenti di software sia all'interoperabilità tramite applicativi diversi. Ma le biblioteche spesso NON chiedono l'adozione di standard tecnici perché spesso non li conoscono. Conoscono solo standard di contenuto: le ISBD.
Ecco: qui ci sono una serie di proposte che si potrebbero inserire nella proposta AIB per l'evoluzione di SBN.
pierfranco
Il giorno 01 agosto 2013 16:13, Francesco Piras fra.piras@gmail.com ha scritto:
Anche io trovo che si tratti di un ottimo articolo, completo e dettagliato.
C'è una cosa che mi ha colpito in particolare, ovvero questa frase: "Sull’assenza di informazioni di disponibilità e accesso, Caffo ricorda che la procedura di certificazione da parte dell’ICCU dei software riguarda solo il colloquio con l’Indice per l’invio di notizie catalografiche e localizzazioni, ma non i servizi."
Non ero presente alla giornata del 20 giugno, ma il senso di queste parole così come riportate sembra essere che non ci sono in SBN informazioni sulla disponibilità al prestito perchè questa caratteristica non è presente nella procedura di certificazione degli applicativi. Sembra quasi suggerire che il problema sarebbe dover ricertificare gli applicativi.
Credo che citare la certificazione sia un pò come partire dalla fine, perchè prima dovrebbe essere implementata la nuova funzione, e poi si dovrebbe stabilire come certificarne il dialogo. Il problema vero sono semmai i tempi della attuale procedura di certificazione, che prevedono una durata di *150 giorni* (come descritto quihttp://www.iccu.sbn.it/opencms/opencms/it/main/sbn/certif_conf_protoc_sbnmarc/#ancora3) che fra contatti preliminari e verifica informale delle date spesso si concretizzano in *10 mesi di tempo* (si avete capito bene, quasi un anno).
Quindi credo che, se i tempi della procedura fossero ridotti drasticamente ed allineati ad una maggiore efficienza, ed una eventuale certificazione "aggiuntiva" fosse fatta solo su questo aspetto senza richiedere oneri economici alle aziende, tutti i produttori sarebbero ben lieti e disponibili a certificarsi, anche perchè tutti gli applicativi gestiscono già questi aspetti quindi il lavoro sarebbe minimo.
Ciao Francesco
Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari