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
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
Ti ringrazio Pierfranco per la chiarezza nell'esposizione e per lo sviluppo delle ideee
Carla
------------------------------------------------------- Carla Colombati 12/A, V.le dello Splendore I-64021 Giulianova Mob.: +39 392 7848408 E-mail: c.colombati@gmail.com
Il giorno 02 agosto 2013 10:33, Pierfranco Minsenti < pierfranco.minsenti@gmail.com> ha scritto:
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
Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
Grazie Carla.
Ma speriamo che su SBN non si continui solo a fare parole. E devo ammettere che anche il mio "speriamo" appare abbastanza fatalistico. Il punto è: quali sono le condizioni di possibilità per l'innovazione? Che cosa fa il Comitato tecnico-scientifico? Le competenze dei componenti (vedi qui la lista componenti: http://www.iccu.sbn.it/opencms/export/sites/iccu/documenti/Decreto_Cts.pdf) sono estremamente diseguali e non sempre riflettono quelle che si possono definire realmente competenze "tecniche". Comunque il difetto maggiore è che è presieduto dallo stesso direttore dell'ICCU. Ma così non è un comitato autonomo, non può emettere valutazioni super partes. È solo un organo di ausilio, di consulenza. Non è così che si fa innovazione. L'innovazione richiede valutazione sullo stato presente e la valutazione richiede autonomia rispetto al valutato. Un organo autonomo deve poter anche dire cose spiacevoli sul passato/presente e indicare che cosa deve cambiare. Nell'attuale situazione non ci sono le condizioni. Giusto quindi il rilievo del Direttore generale per le biblioteche del MiBAC che gli organi di SBN devono essere cambiati perché sono pletorici e non lavorano perché non sono abbastanza snelli. Ma il problema è anche l'assenza di autonomia di quegli organi. Chissà se anche su questo non sia opportuno fare delle proposte per sollevare il problema. ciao
pierfranco
Il giorno 02 agosto 2013 11:39, Carla Colombati c.colombati@gmail.com ha scritto:
Ti ringrazio Pierfranco per la chiarezza nell'esposizione e per lo sviluppo delle ideee
Carla
Carla Colombati 12/A, V.le dello Splendore I-64021 Giulianova Mob.: +39 392 7848408 E-mail: c.colombati@gmail.com
Il giorno 02 agosto 2013 10:33, Pierfranco Minsenti < pierfranco.minsenti@gmail.com> ha scritto:
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
Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
________________________________
From: bibliotecari-bounces@wikimedia.it [mailto:bibliotecari-bounces@wikimedia.it] On Behalf Of Francesco Piras Sent: Thursday, August 01, 2013 4:13 PM Subject: [Bibliotecari] Articolo open access sull'incontro di Roma del 20giugno 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." [...] 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.
La certificazione riguarda l'implementazione del protocollo SBN-MARC, e quindi del colloquio con l'indice, e non tutte le funzionalità che un applicativo può avere in proprio, così come non riguarda aspetti come la qualità dell'interfaccia, la stabilità del programma ecc.
Ovviamente la gestione dei servizi avviene in polo e quindi non utilizza SBN-MARC (dico "ovviamente" in una struttura come quella attuale di SBN, se fosse una rete totalmente centralizzata, senza i poli, allora sarebbe centralizzata anche la gestione dei servizi) quindi è al di fuori della certificazione).
Se le informazioni sulla disponibilità non sono previste da SBN-MARC, la loro trasmissione all'indice (e relativa gestione da parte di quest'ultimo) richiederebbe, prima di una ricertificazione degli applicativi, una evoluzione del protocollo e una corrispondente evoluzione del software dell'indice.
Con riferimento al discorso sull'utilità della certificazione fatto in un messaggio successivo, mi pare che il discorso si riferisse a casi di API per l'esposizione di dati, e quindi ad un accesso in sola lettura, ma siccome SBN-MARC prevede anche operazioni di scrittura a mio parere è corretto verificare in anticipo i programmi per evitare che un programma mal realizzato, oltre a non servire a chi lo usa, crei anche dati scorretti in indice.
Beppe Pavoletti
giuseppe.pavoletti@regione.liguria.it
Beppe,
non ci siamo capiti. Il discorso che ho proposto si basa su una netta distinzione tra quello che è e le funzioni che svolge SBN-MARC, da una parte, e dall'altra quelle che sono le API per comunicare le informazioni di disponibilità: sono discorsi da tenere assolutamente tenuti separati perché non c'entrano niente. Sono due cose diversissime sotto tutti i punti di vista.
SBN-MARC = scambio di informazioni catalografiche (biblio + aut) e di localizzazione. Sono informazioni tutto sommato "stabili" nel senso che se anche le notizie si correggono, le pubblicazioni si perdono o vengono scaricate, non sono informazioni che cambiano in continuazione. Inoltre SBN-MARC è fatto per prevedere controlli sull'inserimento di nuove notizie e per gli allineamenti. Infine sono tutte informazioni destinate in primo luogo ai gestionali usati dai catalogatori e da qui passeranno negli opac.
API per le informazioni di disponibilità = web services per esporre informazioni sui prestiti: non sono informazioni che devono finire nei gestionali di tutte le biblioteche cooperanti in SBN e non sono neppure informazioni da "importare" stabilmente da qualche parte: sono solo informazioni che devono essere visualizzate tramite un plugin basato su AJAX, solo temporaneamente e solo nella interfaccia dell'opac di Indice e di eventuali piattaforme di nuova generazione separate dal gestionale e che potrebbero essere usate da un Polo o anche solo da una certa biblioteca di un Polo.
Si tratta di flussi di dati completamente diversi e con diversissima funzione. Non sovrapponiamo i due discorsi e soprattutto stiamo attenti a non far credere che per caso il capitolo certificazioni debba essere riaperto. Si tratta non di un nuovo (ennesimo?) passaggio burocratico da far durare mesi per ogni ditta, ma di raggiungere un accordo usando un testo già sottoscritto negli Stati Uniti . È solo questione di applicare una soluzione già utilizzata. Nei paesi civili succede: senza giri burocratici e certificazioni. Smettiamola di burocratizzare SBN anche quando non ce n'è affatto bisogno: lo è già abbastanza così.
pierfranco
Il giorno 05 agosto 2013 10:04, Pavoletti Giuseppe Carlo < GiuseppeCarlo.Pavoletti@regione.liguria.it> ha scritto:
From: bibliotecari-bounces@wikimedia.it [mailto:bibliotecari-bounces@wikimedia.it] On Behalf Of Francesco Piras Sent: Thursday, August 01, 2013 4:13 PM Subject: [Bibliotecari] Articolo open access sull'incontro di Roma del 20giugno
C'è una cosa che mi ha colpito in particolare, ovvero questa frase: "Sull'assenza di informazioni di disponibilità e accesso, Cafforicorda 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." [...] 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.
La certificazione riguarda l'implementazione del protocollo SBN-MARC, e quindi del colloquio con l'indice, e non tutte le funzionalità che un applicativo può avere in proprio, così come non riguarda aspetti come la qualità dell'interfaccia, la stabilità del programma ecc.
Ovviamente la gestione dei servizi avviene in polo e quindi non utilizza SBN-MARC (dico "ovviamente" in una struttura come quella attuale di SBN, se fosse una rete totalmente centralizzata, senza i poli, allora sarebbe centralizzata anche la gestione dei servizi) quindi è al di fuori della certificazione).
Se le informazioni sulla disponibilità non sono previste da SBN-MARC, la loro trasmissione all'indice (e relativa gestione da parte di quest'ultimo) richiederebbe, prima di una ricertificazione degli applicativi, una evoluzione del protocollo e una corrispondente evoluzione del software dell'indice.
Con riferimento al discorso sull'utilità della certificazione fatto in un messaggio successivo, mi pare che il discorso si riferisse a casi di API per l'esposizione di dati, e quindi ad un accesso in sola lettura, ma siccome SBN-MARC prevede anche operazioni di scrittura a mio parere è corretto verificare in anticipo i programmi per evitare che un programma mal realizzato, oltre a non servire a chi lo usa, crei anche dati scorretti in indice.
Beppe Pavoletti
giuseppe.pavoletti@regione.liguria.it
Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
________________________________
From: bibliotecari-bounces@wikimedia.it [mailto:bibliotecari-bounces@wikimedia.it] On Behalf Of Pierfranco Minsenti Sent: Monday, August 05, 2013 3:39 PM To: Lista di discussione per bibliotecari e wikipediani Subject: Re: [Bibliotecari] Articolo open access sull'incontro di Roma del20giugno
API per le informazioni di disponibilità = web services per esporre informazioni sui prestiti: non sono informazioni che devono finire nei gestionali di tutte le biblioteche cooperanti in SBN e non sono neppure informazioni da "importare" stabilmente da qualche parte: sono solo informazioni che devono essere visualizzate tramite un plugin basato su AJAX, solo temporaneamente e solo nella interfaccia dell'opac di Indice
L'opac indice per visualizzare queste informazioni deve averle, e non le può avere dall'indice gestionale, quindi da dove le prende?
L'idea sarebbe quindi quella di prevedere una API che permetta all'opac dell'indice di interrogare il polo per acquisire l'informazione aggiornata?
E' così o non ho capito bene qualcosa?
Prima di aspetti burocratici (detto per inciso, non capisco perché l'accordo di Berkeley debba interessarci tanto) ce ne sono di tecnici: bisogna individuare l'API da utilizzare e implementarla sia in indice che negli applicativi di polo.
La funzionalità sarebbe certamente utilissima, ma non spunterà nell'indice solo perché si sottoscrive un accordo.
Beppe
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/
In questa screenshot qui sotto i vede che in un caso la riposta è stata l'indisponibilità (scritta in rosso) e in altri casi la disponibilità (scritta in verde):
[image: Immagine in linea 1]
L'interrogazione avviene in tempo reale (altrimenti non sarebbe aggiornata 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
Il giorno 05 agosto 2013 16:42, Pavoletti Giuseppe Carlo < GiuseppeCarlo.Pavoletti@regione.liguria.it> ha scritto:
From: bibliotecari-bounces@wikimedia.it [mailto:bibliotecari-bounces@wikimedia.it] On Behalf Of Pierfranco Minsenti Sent: Monday, August 05, 2013 3:39 PM To: Lista di discussione per bibliotecari e wikipediani Subject: Re: [Bibliotecari] Articolo open access sull'incontro di Roma del20giugno
API per le informazioni di disponibilità = web services peresporre informazioni sui prestiti: non sono informazioni che devono finire nei gestionali di tutte le biblioteche cooperanti in SBN e non sono neppure informazioni da "importare" stabilmente da qualche parte: sono solo informazioni che devono essere visualizzate tramite un plugin basato su AJAX, solo temporaneamente e solo nella interfaccia dell'opac di Indice
L'opac indice per visualizzare queste informazioni deve averle, e non le può avere dall'indice gestionale, quindi da dove le prende?
L'idea sarebbe quindi quella di prevedere una API che permetta all'opac dell'indice di interrogare il polo per acquisire l'informazione aggiornata?
E' così o non ho capito bene qualcosa?
Prima di aspetti burocratici (detto per inciso, non capisco perché l'accordo di Berkeley debba interessarci tanto) ce ne sono di tecnici: bisogna individuare l'API da utilizzare e implementarla sia in indice che negli applicativi di polo.
La funzionalità sarebbe certamente utilissima, ma non spunterà nell'indice solo perché si sottoscrive un accordo.
Beppe
Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
API per comunicare le informazioni di disponibilità
Sarebbe interessante sapere quanti e quali degli ILS attualmente in commercio in Italia mettano a disposizione questo servizio. A me non risulta che siano moltissimi... E sarebbe interessante anche sapere quali costi abbia, per coloro che hanno acquisito certe soluzioni ILS, avere la disponibilita' di tali webservice....
Andrea -- Andrea Marchitelli marchitelli@gmail.com - Roma
Il 05 agosto 2013 15:39, Pierfranco Minsenti pierfranco.minsenti@gmail.com ha scritto:
Beppe,
non ci siamo capiti. Il discorso che ho proposto si basa su una netta distinzione tra quello che è e le funzioni che svolge SBN-MARC, da una parte, e dall'altra quelle che sono le API per comunicare le informazioni di disponibilità: sono discorsi da tenere assolutamente tenuti separati perché non c'entrano niente. Sono due cose diversissime sotto tutti i punti di vista.
SBN-MARC = scambio di informazioni catalografiche (biblio + aut) e di localizzazione. Sono informazioni tutto sommato "stabili" nel senso che se anche le notizie si correggono, le pubblicazioni si perdono o vengono scaricate, non sono informazioni che cambiano in continuazione. Inoltre SBN-MARC è fatto per prevedere controlli sull'inserimento di nuove notizie e per gli allineamenti. Infine sono tutte informazioni destinate in primo luogo ai gestionali usati dai catalogatori e da qui passeranno negli opac.
API per le informazioni di disponibilità = web services per esporre informazioni sui prestiti: non sono informazioni che devono finire nei gestionali di tutte le biblioteche cooperanti in SBN e non sono neppure informazioni da "importare" stabilmente da qualche parte: sono solo informazioni che devono essere visualizzate tramite un plugin basato su AJAX, solo temporaneamente e solo nella interfaccia dell'opac di Indice e di eventuali piattaforme di nuova generazione separate dal gestionale e che potrebbero essere usate da un Polo o anche solo da una certa biblioteca di un Polo.
Si tratta di flussi di dati completamente diversi e con diversissima funzione. Non sovrapponiamo i due discorsi e soprattutto stiamo attenti a non far credere che per caso il capitolo certificazioni debba essere riaperto. Si tratta non di un nuovo (ennesimo?) passaggio burocratico da far durare mesi per ogni ditta, ma di raggiungere un accordo usando un testo già sottoscritto negli Stati Uniti . È solo questione di applicare una soluzione già utilizzata. Nei paesi civili succede: senza giri burocratici e certificazioni. Smettiamola di burocratizzare SBN anche quando non ce n'è affatto bisogno: lo è già abbastanza così.
pierfranco
Il giorno 05 agosto 2013 10:04, Pavoletti Giuseppe Carlo GiuseppeCarlo.Pavoletti@regione.liguria.it ha scritto:
From: bibliotecari-bounces@wikimedia.it[mailto:bibliotecari-bounces@wikimedia.it] On Behalf Of Francesco Piras Sent: Thursday, August 01, 2013 4:13 PM Subject: [Bibliotecari] Articolo open access sull'incontro di Roma del 20giugno
C'è una cosa che mi ha colpito in particolare, ovvero questafrase: "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." [...] 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.
La certificazione riguarda l'implementazione del protocollo SBN-MARC, e quindi del colloquio con l'indice, e non tutte le funzionalità che un applicativo può avere in proprio, così come non riguarda aspetti come la qualità dell'interfaccia, la stabilità del programma ecc.
Ovviamente la gestione dei servizi avviene in polo e quindi non utilizza SBN-MARC (dico "ovviamente" in una struttura come quella attuale di SBN, se fosse una rete totalmente centralizzata, senza i poli, allora sarebbe centralizzata anche la gestione dei servizi) quindi è al di fuori della certificazione).
Se le informazioni sulla disponibilità non sono previste da SBN-MARC, la loro trasmissione all'indice (e relativa gestione da parte di quest'ultimo) richiederebbe, prima di una ricertificazione degli applicativi, una evoluzione del protocollo e una corrispondente evoluzione del software dell'indice.
Con riferimento al discorso sull'utilità della certificazione fatto in un messaggio successivo, mi pare che il discorso si riferisse a casi di API per l'esposizione di dati, e quindi ad un accesso in sola lettura, ma siccome SBN-MARC prevede anche operazioni di scrittura a mio parere è corretto verificare in anticipo i programmi per evitare che un programma mal realizzato, oltre a non servire a chi lo usa, crei anche dati scorretti in indice.
Beppe Pavoletti
giuseppe.pavoletti@regione.liguria.it
Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
Ciao Andrea,
Sarebbe interessante sapere quanti e quali degli ILS attualmente in commercio in Italia mettano a disposizione questo servizio. A me non risulta che siano moltissimi...
visto che sono on-line ti rispondo: -- Exlibris -- (forse) Millennium -- Koha -- (forse) Comperio
Di sicuro non Sebina (se non era piu' facile fare il vufind cumulativo della Toscana).
Ciao Zeno
-----Original Message----- From: bibliotecari-bounces@wikimedia.it [mailto:bibliotecari-bounces@wikimedia.it] On Behalf Of Zeno Tajoli Sent: Monday, August 05, 2013 6:12 PM To: Lista di discussione per bibliotecari e wikipediani Subject: Re: [Bibliotecari] Articolo open access sull'incontro di Romadel 20giugno
Sarebbe interessante sapere quanti e quali degli ILS attualmente in commercio in Italia mettano a disposizione questo servizio.
visto che sono on-line ti rispondo:
Ma usano delle API standard o ognuno ha la sua soluzione?
Beppe
Non mi pare che ci siano API "standard". Pero' avere API non standard ma documentate sarebbe gia' un enorme passo avanti (rispetto al nulla...)
Andrea -- Andrea Marchitelli marchitelli@gmail.com - Roma
Il 06 agosto 2013 09:23, Pavoletti Giuseppe Carlo GiuseppeCarlo.Pavoletti@regione.liguria.it ha scritto:
-----Original Message----- From: bibliotecari-bounces@wikimedia.it [mailto:bibliotecari-bounces@wikimedia.it] On Behalf Of Zeno Tajoli Sent: Monday, August 05, 2013 6:12 PM To: Lista di discussione per bibliotecari e wikipediani Subject: Re: [Bibliotecari] Articolo open access sull'incontro di Romadel 20giugno
Sarebbe interessante sapere quanti e quali degli ILS attualmente in commercio in Italia mettano a disposizione questo servizio.
visto che sono on-line ti rispondo:
Ma usano delle API standard o ognuno ha la sua soluzione?
Beppe _______________________________________________ Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
Potrebbe essere così: ognuno ha la sua API e la conosce solo chi si mette d'accordo con quel fornitore e gli capita di lavorarci.
O potrebbe essere come negli Stati Uniti: l'accordo della Digital library Federation del 2008 è questo: adottare tutti la stessa API che è pubblicata nel testo del report Provo a ricitarlo: "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
È un documento che esamina a 360 gradi l'interoperabilità tra sistemi diversi e l'harvesting.
Per il discorso fatto qui interessa l'interoperabilità al livello delle informazioni di disponibilità: quindi il paragrafo 6.3.1 GetAvailability (Level 1): pagina 26-28
Le altre pagine che interessano sono: pagina 57: 9. Summary of Basic Discovery Interfaces compliance:
GetAvailability must be supported for all bibliographic records and items available for discovery, via a REST URL request and an XML response that conforms to the DLF XML schema, using the dlf:simple availability element, as defined in this document.
pagina 71: Appendix 4: GetAvailability Responses with DLF:simpleavailability
contiene un esempio di risposta in XML
pagina 77: Appendix 7: The Berkeley Accord, Spring 2008
contiene il testo dell'accordo tra la Digital Library Federation e le ditte firmatarie:
On March 6, representatives of the Digital Library Federation (DLF), academic libraries, and major library application vendors met in Berkeley.
*At the meeting, participants agreed to support a set of essential functions through * *open protocols and technologies by deploying specific recommended standards.*
These functions are: 1. Harvesting. Functions to harvest data records for library collections, both in full, and incrementally based on recent changes. Harvesting options could include either the core bibliographic records, or those records combined with supplementary information (such as holdings or summary circulation data). Both full and differential harvesting options are expected to be supported through an OAI-PMH interface. 2. Availability. Real-time querying of the availability of a bibliographic (or circulating) item. This functionality will be implemented through a simple REST interface to be specified by the ILS-DI task group. 3. Linking. Linking in a stable manner to any item in an OPAC in a way that allows services to be invoked on it; for example, by a stable link to a page displaying the item's catalog record and providing links for requests for that item. This functionality will be implemented through a URL template defined for the OPAC as specified by the ILS-DI task group.
Sottolineo la portata innovativa della cosa che emerge sta affermazione:
*At the meeting, participants agreed to support a set of essential functions through * *open protocols and technologies by deploying specific recommended standards.*
I participants erano ditte. Ve lo immaginate in Italia 4 o 5 ditte che ovviamente sono in concorrenza tra loro ma che per migliorare i servizi delle biblioteche si riuniscono attorno a un tavolo e firmano un accordo per usare uno schema comune per l'interoperabilità?
È una cosa veramente difficile da immaginare qui eppure è proprio per questo che bisognerebbe volerla. Perché rendiamoci conto di una cosa: come ho scritto, solo Valdo Pasqui nel 2009 aveva parlato della cosa 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
Qui l'apertura e l'innovazione si fa sulle riviste scientifiche e rimane spesso teoria inapplicata: né alle ditte né alle biblioteche sembra interessare pretendere quelle innovazioni che negli USA sono cose pratiche: contenute in report tecnici e documentate in accordi, non in articoli teorici. Qui invece c'è uno scollamento pauroso tra conoscenze nuove, che rimangono patrimonio di pochissimi e non si diffondono nelle biblioteche, non diventano patrimonio comune per cui non influiscono sul mercato. È un circolo vizioso, ovviamente. Ci si limita a scriverne. Il resto del mondo bibliotecario continua a proseguire nel grigiore di pratiche superate e dettate dal loro fornitore di riferimento rispetto al quale non hanno la possibilità di elaborare strumenti critici anche perché non si sono mai posti il problema di crearseli.
pierfranco
Il giorno 06 agosto 2013 09:28, Andrea Marchitelli marchitelli@gmail.comha scritto:
Non mi pare che ci siano API "standard". Pero' avere API non standard ma documentate sarebbe gia' un enorme passo avanti (rispetto al nulla...)
Andrea
Andrea Marchitelli marchitelli@gmail.com - Roma
Il 06 agosto 2013 09:23, Pavoletti Giuseppe Carlo GiuseppeCarlo.Pavoletti@regione.liguria.it ha scritto:
-----Original Message----- From: bibliotecari-bounces@wikimedia.it [mailto:bibliotecari-bounces@wikimedia.it] On Behalf Of Zeno Tajoli Sent: Monday, August 05, 2013 6:12 PM To: Lista di discussione per bibliotecari e wikipediani Subject: Re: [Bibliotecari] Articolo open access sull'incontro di Romadel 20giugno
Sarebbe interessante sapere quanti e quali degli ILS attualmente in commercio in Italia mettano a disposizione questo servizio.
visto che sono on-line ti rispondo:
Ma usano delle API standard o ognuno ha la sua soluzione?
Beppe _______________________________________________ Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
Ciao a tutti,
Ma usano delle API standard o ognuno ha la sua soluzione?
C'e' un po di tutto.
Exlibris: API del Berkeley Accord citato da Pierfranco + altri standard + API proprietarie Millennium: altri standard e API proprietarie, http://www.eiug.org/c2011/MillenniumAPIs.pptx Koha: API del Berkeley Accord citato da Pierfranco + altri standard + API proprietarie Comperio: qui e' meglio che risponda Giulio Buonanome.
Tendenzialmente il Berkeley Accord è una base minima su cui poi si inseriscono altre componenti.
Ciao Zeno Tajoli
Il giorno 06 agosto 2013 10:09, Zeno Tajoli z.tajoli@cineca.it ha scritto:
Ciao a tutti,
Ma usano delle API standard o ognuno ha la sua soluzione?
C'e' un po di tutto.
Exlibris: API del Berkeley Accord citato da Pierfranco + altri standard + API proprietarie Millennium: altri standard e API proprietarie, http://www.eiug.org/c2011/MillenniumAPIs.pptx Koha: API del Berkeley Accord citato da Pierfranco + altri standard + API proprietarie Comperio: qui e' meglio che risponda Giulio Buonanome.
Tendenzialmente il Berkeley Accord è una base minima su cui poi si inseriscono altre componenti.
Ecco: questo è l'aspetto interessante di questo approccio condiviso del Berkeley Accord del 2008: impegnarsi per realizzare una base minima comune, che non esclude però altre specificazioni. Il punto è: impegnarsi sui dati aperti, tutti (o, per lo meno, un po' di fornitori) e creare così le condizioni per un mercato dove l'interoperabilità non è un optional ma uno standard.
Prendiamo il caso di una ditta che ha firmato l'accordo: Ex Libris. Produce vari prodotti ma prendiamone 2 in particolare: Aleph e Primo. Primo è solo interfaccia di discovery e può interfacciarsi con un gestionale di altri produttori purché questo sia interoperabile. Nel mondo dell'interoperabilità puoi vendere il prodotto grosso e costoso, il gestionale, oppure puoi vendere solo una interfaccia di discovery: puoi cioè diversificare le tue linee di prodotto e avere clienti che comprano solo l'una o l'altra. Ma questo richiede l'interoperabilità. In un mercato dominato dall'interoperabilità si aprono più opportunità per tutti: anche per le ditte perché creano nuovi prodotti e conquistano nuovi clienti che magari acquistano solo una specifica applicazione e la combinano con un altra. I vantaggi ci sono sia per le ditte che per i clienti: ma tutto diventa più competitivo. Bisogna saper rinunciare ai prodotti chiusi per arrivare a vedere queste opportunità. Si capisce che c'è chi come per es. l'ex CILEA (scusate ma è più chiaro se uso questa espressione) avrebbe più spazio di azione e di proposta in un mercato realmente aperto e che fa della interoperabilità il proprio standard. Si creerebbero maggiori opportunità per tutti. È come liberare la concorrenza. Ma quali sono i bibliotecari che capiscono la portata della interoperabilità e la pretendono? O forse il problema è che molti, troppi bibliotecari a causa di SBN non si mai occupati di queste cose perché tutte le decisioni venivano prese dalle istituzioni locali che controllavano le ditte a partecipazione statale che sviluppavano i software per SBN1? Quante responsabilità ha avuto SBN nel creare assenza di competenze e responsabilizzazione nei bibliotecari, istruiti solo per inserire records nel sistema e nient'altro che quello?
pierfranco
Ciao Zeno Tajoli _______________________________________________ Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
bibliotecari@liste.wikimedia.it
-
Andrea Marchitelli -
Carla Colombati -
Francesco Piras -
Pavoletti Giuseppe Carlo -
Pierfranco Minsenti -
Zeno Tajoli