Un esempio di interfaccia di nuova generazione, separata dal gestionale, che riesce a visualizzare i dati di disponibilità interrogando in tempo reale:
Il Next Generation Opac VuFind della Braidense: http://opac.braidense.it/vufind/
Quando un utente fa una ricerca e il sistema crea la lista risultati, per ogni record bibliografico viene anche mostrata la disponibilità:a seconda dei casi la risposta può essere l'indisponibilità (scritta in rosso: Non disponibile) o la disponibilità (scritta in verde: Disponibile). È una cosa che siamo straabituati a vedere quando l'opac è parte integrante del gestionale e comunica in tempo reale con il modulo prestiti. Ma non siamo affatto abituati a vedere la stessa cosa quando l'opac è una interfaccia di nuova generazione del tutto indipendente dal gestionale.
L'interrogazione dei dati del modulo prestiti avviene in tempo reale (altrimenti i dati non sarebbero aggiornati con i dati sui prestiti effettivi e le restituzioni). Quindi *non è* una informazione che deve importare in precedenza (sarebbe vecchia) come avviene nel caso dei dati che viaggiano con SBN-MARC. Il tutto è possibile solo se: 1) il sistema del gestionale adotta una API per esporre i dati sui prestiti in tempo reale + 2) il next generation opac è dotato di un apposito plugin per interrrogare la API del gestionale in concomitanza con la creazione di una lista di risultati a seguito di una ricerca da parte di un utente
L'accordo di Berkeley serve a dire come deve essere fatta questa API in modo che i produttori la adottano a prescindere da eventuali richieste dei clienti, che quindi se la trovano integrata nel prodotto, magari tramite una nuova release, senza dover chiedere e pagare ognuno per averla come potrebbe invece succedere in Italia. Lo standard ha questo di bello: che il produttore è tenuto a darlo gratuitamente se vuole stare sul mercato in maniera competitiva. Altro vantaggio: un produttore solo di un next generation opac sa in anticipo con che tipo di API si troverà a lavorare per poter comunicare con i gestionali prodotti da altre ditte.
È questo il bello degli accordi: fanno comodo a tutti perché l'interoperabilità è un valore per tutti, ammesso che la competizione si voglia vincere con le idee e non con i software chiusi. È per questo che gli accordi sottoscritti all'estero per gli standard ci ci interessano eccome
pierfranco
________________________________
From: bibliotecari-bounces@wikimedia.it [mailto:bibliotecari-bounces@wikimedia.it] On Behalf Of Pierfranco Minsenti Sent: Monday, August 05, 2013 11:10 PM To: Lista di discussione per bibliotecari e wikipediani Subject: Re: [Bibliotecari] Articolo open access sull'incontro di Romadel20giugno Lo standard ha questo di bello: che il produttore è tenuto a darlo gratuitamente se vuole stare sul mercato in maniera competitiva.
Concordo su quello che dici anche in altri post sui vantaggi dell'interoperabilità, così come sul fatto che questo aspetto sia stato gravemente trascurato soprattutto in SBN1 (che per diversi anni ha avuto problemi già solo a stare in piedi per conto suo).
Su questo punto in particolare osserverei che di standard ce ne sono tanti (infatti si dice che il bello è che ognuno trova quello che gli piace, così può usarne uno diverso dagli altri ...), ma non tutti hanno tanto successo da diventare un "obbligo" di fatto: uno può dichiarare di supportare un certo standard ma non trovare nessuno a cui interessi.
Ad esempio, i protocolli di rete ISO-OSI sono standard con tutti i crismi, ma c'è qualche produttore che si sente obbligato ad implementarli?
Se oggi per la visualizzazione di informazioni di disponibilità le uniche scelte sono le API di Berkeley (accordo il cui ruolo non avevo capito bene) o soluzioni proprietarie è chiaro che bisogna cercare di sostenere la prima soluzione (non entro nel merito perché è un argomento che conosco poco), però avevo l'impressione che in alcuni messaggi dei giorni scorsi si sopravvalutasse l'aspetto procedurale (accordo, certificazione ecc.) rispetto quello tecnico (scelta dello standard e sua implementazione dove manca, ad esempio nell'opac del indice).
Poi mi sembra chiaro che se si vuole che l'opac dell'indice abbia funzionalità di questo genere, l'unica soluzione sensata sia individuare uno standard che debba essere adottato sia dall'indice che dai software di polo, altrimenti l'opac indice dovrebbe prevedere un supporto per tutte le soluzioni proprietarie. Anche con lo standard ci vuole comunque un investimento per l'evoluzione del software: forse voi che conoscete bene l'argomento potete valutare se sarebbe una cosa molto complessa.
Questo però non garantisce il successo dell'operazione: i produttori dei sw di polo potrebbero ritenere la cosa di scarso interesse o limitarsi ad aspettare che qualche cliente gli commissioni lo sviluppo.
Beppe
bibliotecari@liste.wikimedia.it
-
Pavoletti Giuseppe Carlo -
Pierfranco Minsenti