Premessa: ho cambiato subject della mail, ma faccio riferimento al thread Articolo open access sull'incontro di Romadel 20giugnohttp://mailman.wikimedia.it/pipermail/bibliotecari/2013-August/001669.html .
*Esporre le informazioni di circolazione in SBN* Secondo me non ha alcun senso. Simpatico. Ma non ha senso. Quando mi interessa sapere se un documento fisico è disponibile? Quando posso prenderlo in mano. Sapere che a Palermo hanno disponibile un libro mentre io abito a Rovigo, che utilità rappresenta? Inoltre non è bene dare per scontato che una cosa "disponibile" per il tuo sistema sistema bibliotecario vattelapesca, sarà disponibile anche per me, non-iscritto allo stesso sistema. Mi interesserebbe sapere la disponibilità solo nel caso di biblioteche vicine alla mia, dove posso andare fisicamente, ma qui starei parlando di una app mobile, non dell'opac sbn dove l'ordine delle localizzazioni è per codice biblioteca.
*ILS-DI Reccomendation* Si tratta di raccomandazioni. Non di una vera e propria specifica. Il paragrafo più interessante è il seguente: "At present, a number of ILS vendors provide proprietary methods for accessing their underlying data stores. These may consist of command-line API tools accessible only for a special fee to trained users, or direct SQL queries against the ILS's database tables. While these methods provide much needed hooks into the ILS, making library resources more widely usable requires a larger, standards-based API. To enable outward integration, organizations will require that ILS's adopt a more standardized method for providing API access to the data store, moving away from traditional library-centric protocols like Z39.50 toward an XML-based web services API model." Il punto era che la crescente diffusione di interfacce da "agganciare" ai gestionali, ha spinto alla definizione di alcune "norme comportamentali" nella definizione di API. Una API è qualcosa di specifico ad una certa applicazione, ma almeno così tutti ci si poteva aspettare di implementare il proprio "discovery layer" aspettandosi di ricevere messaggi formattati in XML a richieste del tipo "dimmi se quella copia è disponibile". Chi ha firmato l'accordohttp://www.libology.com/blog/2008/04/11/berkeley-accord.htmlsono le più grandi aziende del settore e quelle che all'epoca producevano i cosiddetti NextGenOPAC (BiblioCommons, AquaBrowser).
Sono fermamente convinto che le raccomandazioni proposte dal gruppo ILS-DI siano fondamentali per chi intende sviluppare una API per il suo ILS, ma per quanto riguarda l'esposizione di informazioni di circolazione non penso siano il punto di riferimento definitivo per la rappresentazione dei dati. A proposito consiglio di leggere questo post di Jonathan Rochkindhttp://bibwild.wordpress.com/2009/09/10/dlf-ils-di-dlfexpanded-service-for-horizon/ e di dare un'occhiata a questa ontologia in via di definizionehttp://dini-ag-kim.github.io/holding-ontology/holding.html .
*Sviluppare una API per un ILS in Italia* L'ILS di Comperio non implementa le specifiche di ILS-DI, abbiamo una interfaccia SOAP http://en.wikipedia.org/wiki/SOAP che viene usata dal nostro DiscoveryNG. Inoltre usiamo dei campi proprietari UNIMARC (9XX) per informazioni gestionali e di circolazione, visibili nel tracciato XML del record http://bct.comperio.it/data/xml/turbomarc/sbct:catalog:349224 (non usiamo il MARCXML, ma il TURBOMARChttp://www.indexdata.com/blog/2010/05/turbomarc-faster-xml-marc-records). Stiamo lavorando per passare dall'interfaccia SOAP, ad una API REST più aperta e usabile.
Non so come dirlo in maniera pacata, ma non capisco perchè una ditta in Italia dovrebbe mettersi a implementare una API? Quante realtà italiane si trovano ad avere un ILS attaccato ad un OPAC di altra ditta? O ad altri servizi (es. navigazione internet, conteggio accessi, ecc.)? Quante biblioteche italiane sono in grado di implementare servizi su queste ipotetiche API? Attorno ai maggiori prodotti stranieri si è sviluppato un vero e proprio ecosistema di sviluppatori che producono applicazioni, integrazioni, plugin. Mi dite in italia quanti sviluppatori (non sto parlando di "smanettoni") abbiamo in seno ai sistemi bibliotecari? Se penso a tutti i clienti di Comperio, posso dire tremendamente pochi (per la precisione sono 1 e mezzo).
Citando Pierfranco: "Ma quali sono i bibliotecari che capiscono la portata della interoperabilità e la pretendono?" A cui aggiungo: ma se anche i bibliotecari la capissero, chi è che ha scelto fin'ora gli ILS in Italia? E in che modo?
Ciao Giulio
Rispondo tra le righe:
Il giorno 06 agosto 2013 11:33, Giulio Bonanome gbonanome@gmail.com ha scritto:
Premessa: ho cambiato subject della mail, ma faccio riferimento al thread Articolo open access sull'incontro di Romadel 20giugnohttp://mailman.wikimedia.it/pipermail/bibliotecari/2013-August/001669.html .
*Esporre le informazioni di circolazione in SBN* Secondo me non ha alcun senso. Simpatico. Ma non ha senso. Quando mi interessa sapere se un documento fisico è disponibile? Quando posso prenderlo in mano. Sapere che a Palermo hanno disponibile un libro mentre io abito a Rovigo, che utilità rappresenta? Inoltre non è bene dare per scontato che una cosa "disponibile" per il tuo sistema sistema bibliotecario vattelapesca, sarà disponibile anche per me, non-iscritto allo stesso sistema. Mi interesserebbe sapere la disponibilità solo nel caso di biblioteche vicine alla mia, dove posso andare fisicamente, ma qui starei parlando di una app mobile, non dell'opac SBN dove l'ordine delle localizzazioni è per codice biblioteca.
Ti dò 5 motivi per giustificare l'utilità di rappresentare innanzitutto informazioni di accesso (è una biblioteca aperta a tutti o no? e poi di disponibilità (può voler dire anche: è disponibile solo su consultazione; oppure è disponibile anche per il prestito):
1) è utile avere un unico opac che à queste indicazioni su scala nazionale. Non necessariamente perché anche se sono a Rovigo sono disponibile ad andare a Palermo. Ma magari se sono a Rovigo sono a cavallo tra 2 regioni e la politica diffusa in certe regioni di fare opac regionali non ha molto senso. Facciamo un unico opac nazionale con funzionalità avanzate. E i soldi delle Regioni per dei metaopac regionali andrebbero convogliati in quel progetto. Dunque: se sto a Rovigo mi interessa sapere se un libro lo trovo a Bologna o a Padova. L'attuale opac SBN risponde a questa esigenza fornendo una unica interfaccia di interrogazione: ma non mi dà le informazioni di disponibilità. E per sapere se alla biblioteca posso accedere (non è detto) devo fare dei click e andare a vedere l'anagrafe biblioteche
2) è utile per fare richieste di prestito ILL non mediate dal bibliotecario. Il Prestito SBN-ILL è pensato anche per richieste dirette da parte degli utenti. Se sono a Rovigo il prestito ILL lo chiedo a Padova o a Bologna? Se ho le informazioni di disponibilità posso decidere, se non le ho non ho elementi per decidere chi, avendolo disponibile, mi assicura di poterlo avere prima.
3) proprio l'esempio che fai di una APP per dispositivo mobile dimostra l'utilità di queste informazioni. Se sei in giro, in viaggio, può essere utile consultare un solo sistema che dia anche le info di disponibilità.
4) le informazioni di disponibilità sono da intendersi anche come informazioni sull'accesso: per es. il discovery tool australiano Trove per ogni edizione di un libro dice: 1) se esistono e quante e dove copie online e se sono accessibili, oppure se ci sono condizioni particolari di accesso 2) e nel caso delle edizioni cartacee dice: a) se si possono prendere in prestitio e mostra la lista con tanto di collocazione (nell'indice SBN invece non c'è) b) e la dicitura: Open to the public oppure: Not open to the public 3) link al relativo sistema di prestito interbibliotecario. Per es. qui vedi qui un esempio di lista: http://trove.nla.gov.au/work/8098075?q=pillow+book&c=book&borrow=tru...
5) servirebbe anche in prospettiva per la necessità di trattare in maniera uguale risorse cartacee e risorse elettroniche (che al momento non sono in SBN), dando informazioni di disponibilità sull'accesso.
*Sviluppare una API per un ILS in Italia* L'ILS di Comperio non implementa le specifiche di ILS-DI, abbiamo una interfaccia SOAP http://en.wikipedia.org/wiki/SOAP che viene usata dal nostro DiscoveryNG. Inoltre usiamo dei campi proprietari UNIMARC (9XX) per informazioni gestionali e di circolazione, visibili nel tracciato XML del record http://bct.comperio.it/data/xml/turbomarc/sbct:catalog:349224(non usiamo il MARCXML, ma il TURBOMARChttp://www.indexdata.com/blog/2010/05/turbomarc-faster-xml-marc-records). Stiamo lavorando per passare dall'interfaccia SOAP, ad una API REST più aperta e usabile.
Non so come dirlo in maniera pacata, ma non capisco perchè una ditta in Italia dovrebbe mettersi a implementare una API? Quante realtà italiane si trovano ad avere un ILS attaccato ad un OPAC di altra ditta? O ad altri servizi (es. navigazione internet, conteggio accessi, ecc.)? Quante biblioteche italiane sono in grado di implementare servizi su queste ipotetiche API? Attorno ai maggiori prodotti stranieri si è sviluppato un vero e proprio ecosistema di sviluppatori che producono applicazioni, integrazioni, plugin. Mi dite in italia quanti sviluppatori (non sto parlando di "smanettoni") abbiamo in seno ai sistemi bibliotecari? Se penso a tutti i clienti di Comperio, posso dire tremendamente pochi (per la precisione sono 1 e mezzo).
Non capisco l'obiezione: come fa a nascere un ecosistema di ditte (non di smanettoni) se non si inizia a creare le condizioni ambientali favorevoli all'ecosistema? Se l'obiezione è: oggi in Italia previsioni realistiche di richieste da parte del mercato non giustificherebbero l'impiego di tempo da parte di una ditta (tempo = soldi) per fare queste cose, questa può essere una previsione un poco fondata se ci si basa sul pessimismo di fronte all'ingessato ambiente delle biblioteche italiane. Ma se ci si pone in un'ottica un poco più ottimistica come è nello spirito di questa maling list che dà voce a uno spirito critico animato dalla convinzione che tante cose negative all'origine dell'involuzione italiana sono anche frutto di una voluta stasi, allora si può ragionare in maniera diversa. Soprattuto ti faccio notare che probabilmente qualcuno avrebbe preferito rimanere a SBN1 e dal punto di vista economico gli avrebbe fatto molto comodo. Ma non agli altri e non al sistema nel suo complesso. Se SBN2 non fosse mai nato, se non ci fossero stati dei cambiamenti frutto di critiche al precedente sistema di chiusura della rete SBN, allora come sai anche il panorama delle ditte italiane di software sarebbe molto diverso e con molti, molti meno spazi di azione. Conclusione: è compito di istituzioni che pensano al futuro (come in USA la DLF) promuovere dei cambiamenti che in prospettiva producono benefici a cascata. Esattamente come fa la politica nel caso della salvaguardia del principio della libera concorrenza. L'interoperabilità è l'adattamento al campo tecnologico della principio della concorrenza. Comunque lo sottolineo per l'ennesima volta: in USA queste cose non dipendono da leggi, decreti, certificazioni: sono solo accordi. Chi non vuole non li firma. Chi pensa che siano cose inutilmente costose non le fa.
Citando Pierfranco: "Ma quali sono i bibliotecari che capiscono la portata della interoperabilità e la pretendono?" A cui aggiungo: ma se anche i bibliotecari la capissero, chi è che ha scelto fin'ora gli ILS in Italia? E in che modo?
Vedi sopra su atteggiamento pessimista (=stasi: ma siamo sicuri che ci torni utile, di guadagnarci?) o atteggiamento un po' più ottimista (ottimismo della volontà, niente di più).
pierfranco
Ciao Giulio
Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
Ciao,
Esporre le informazioni di circolazione in SBN
leggendo lo scambio di Giulio e Pierfranco mi pare che non parliamo tutti della stessa cosa. A scanso di equivoci, specifico che io parlavo di quello che viene spesso definita Real Time Availability (RTA), cioe' informazioni di disponibilita' in tempo reale: questo documento che ho trovato a catalogo e' disponibile in questo momento a scaffale?
Informazioni sullo stato della circolazione (o come preferite chiamarlo) riguardano invece una condizione con relativa a quell'istante: un libro e' per sola consultazione o anche per il prestito, e' smarrito ecc.
In generale credo che la questione riguardi l'interoperabilita' in generale (e in particolare l'uso di discovery layer potenzialmente separati da ILS) non tanto il fatto di avere un unico catalogo nazionale con l'indicazione di disponibilita'...
Comunque per ora ho scoperto (cosa che non sapevo) che l'ILS di Comperio permette di interrogare un webservice che da informazioni sulla RTA, nel d950-s1, se non sbaglio. Chi adotta quell'ILS ce l'ha a disposizione gratuitamente? Pero' son d'accordo con Giulio sul fatto che in Italia non si senta, diffusamente, il bisogno di avere a disposizione tali possibilita' di apertura. Mi pare importante pero', che un'azienda riesca a dare una risposta positiva, nel caso (strano) qualcuno abbia l'esigenza.
andrea -- Andrea Marchitelli marchitelli@gmail.com - Roma
A me sembra che la questione abbia diversi aspetti che a volte ne vedono prevalere uno e a volte un altro ma l'aspetto unificante è: come fare a far dialogare tra loro sistemi diversi facendo passare le informazioni da un sistema all'altro.
Distinguerei 2 casi:
1) quando una biblioteca ha il gestionale di una ditta e un sistema di ricerca di nuova generazione preso da latra ditta: in questo caso è interessata ad avere le informazioni di disponibilità (=RTA) in tempo reale nella interfaccia di ricerca e quindi ha bisogno che il gestionale implementi un API per rendere questo possibile.
Tra l'altro non è affatto vero che in Italia non ci sia questa richiesta. Scusa, Andrea: ma se eri proprio tu a scriverne l'altro giorno. È una necessità che esiste:
a) nell'ambito delle biblioteche pubbliche: caso di Aquabrowser usato dalla Regione Toscana e del progetto (per ora allo stato di prototipo) della regione Veneto che ha commissionato all'Università di Padova un discovery tool alimentato via OAI-PMH da tutte le biblioteche di diversi enti sparse sulla Regione Veneto
b) sopratutto nell'ambito delle biblioteche universitarie: in particolar modo per le università che hanno Sebina e che hanno adottato un discovery tool rinunciando (la maggior parte) a prendere SebinaYOU perché non serve ad esporre i dati sulle pubblicazioni elettroniche in licenza d'accesso. Queste università hanno bisogno che il gestionale Sebina adotti una API per la RTA al fine di esporre nel discovery tool le informazioni di disponibilità senza oblbigare l'utente a saltare all'opac Sebina (altrimenti per che cosa abbiamo preso a fare il discovery tool?) e si trovano svantaggiate dall'idea che sembra essere tutta italiana, legata anche a una profonda crisi, che in Italia non avrebbe senso fare come gli "ammericani" e aspettarsi di considerare standard quyelle API, per cui l'upgrade va pagato perché considerato una bizzarra richiesta di qualcuno. Le risorse elettroniche, le esigenze degli utenti sono sempre quelle, sia qui che là, come l'esigenza di poter comprare software diversi e farli colloquiare. Comunque siano ormai un certo numero a volerlo. Mi spiace: nelle università non è vero che queste richieste non ci sono.
2) nel caso dell'estensione di questo discorso sulla RTA all'opac SBN, parte da almeno 3 suggestioni nate o sviluppatesi a seguito dell'incontro del 20 giugno: Mauro Guerrini che diceva che l'opac SBN dovrà evolvere verso un discovery tool; Vanni Bertini che faceva notare che l'opac SBN non visualizza servizi; l'articolo di Giulio Blasi che riprende il discorso di Vanni Bertini sotto il profilo delle informazioni sugli e-books. Quindi le considerazioni che ho abbozzato partono da queste premesse per chiedersi: come può evolvere l'opac SBN? Come può diventare il Trove italiano? Oppure no: non siamo d'accordo? deve rimanere così?
Pierfranco
Il giorno 06 agosto 2013 14:07, Andrea Marchitelli marchitelli@gmail.comha scritto:
Ciao,
Esporre le informazioni di circolazione in SBN
leggendo lo scambio di Giulio e Pierfranco mi pare che non parliamo tutti della stessa cosa. A scanso di equivoci, specifico che io parlavo di quello che viene spesso definita Real Time Availability (RTA), cioe' informazioni di disponibilita' in tempo reale: questo documento che ho trovato a catalogo e' disponibile in questo momento a scaffale?
Informazioni sullo stato della circolazione (o come preferite chiamarlo) riguardano invece una condizione con relativa a quell'istante: un libro e' per sola consultazione o anche per il prestito, e' smarrito ecc.
In generale credo che la questione riguardi l'interoperabilita' in generale (e in particolare l'uso di discovery layer potenzialmente separati da ILS) non tanto il fatto di avere un unico catalogo nazionale con l'indicazione di disponibilita'...
Comunque per ora ho scoperto (cosa che non sapevo) che l'ILS di Comperio permette di interrogare un webservice che da informazioni sulla RTA, nel d950-s1, se non sbaglio. Chi adotta quell'ILS ce l'ha a disposizione gratuitamente? Pero' son d'accordo con Giulio sul fatto che in Italia non si senta, diffusamente, il bisogno di avere a disposizione tali possibilita' di apertura. Mi pare importante pero', che un'azienda riesca a dare una risposta positiva, nel caso (strano) qualcuno abbia l'esigenza.
andrea
Andrea Marchitelli marchitelli@gmail.com - Roma _______________________________________________ Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
Scusa, Andrea: ma se eri proprio tu a scriverne l'altro giorno
mi escludevo dal numero dei richiedenti... :))
preciso che son d'accordo con Giulio nel dire che il problema non mi pare sentito, non che va bene che sia cosi'... Se la richiesta fosse generalizzata ne sarei entusiasta!
Penso anche io che la necessita' di una tale apertura ci sia, ma non mi pare che ci siano molte richieste in tal senso. Questo a mio avviso significa che certe politiche di chiusura non sono sufficientemente osteggiate da chi acquista quei prodotti.
Su SBN, in particolare, non riesco a vedere come utile la visualizzazione della RTA, ma il discorso sui dati di disponibilita' e' analogo a quello su tutti gli altri dati: mettiamoli a disposizione, qualcun altro vedra' se riesce a usarli per qualcosa di buono. Quindi se gli ILS avessero questa possibilita', SBN (o qualsiasi altro sistema) potrebbe decidere come avvalersene.
Il problema qui e' a monte: i dati non sono disponibili, i bibliotecari non si impuntano per averli.
Andrea P.S. su trove ci sono i dati delle condizioni di disponibilita' http://trove.nla.gov.au/work/22488054?q=red&c=book&versionId=4491795... (non so se dati di RTA compaiano agli utenti registrati)
-- Andrea Marchitelli marchitelli@gmail.com - Roma
Il giorno 06 agosto 2013 14:54, Andrea Marchitelli marchitelli@gmail.comha scritto:
P.S. su trove ci sono i dati delle condizioni di disponibilita' http://trove.nla.gov.au/work/22488054?q=red&c=book&versionId=4491795... (non so se dati di RTA compaiano agli utenti registrati)
Infatti è quello che ho detto e penso che Trove sia un grande esempio per ripensare l'opac SBN. Ammesso che abbiamo voglia di ripensarlo o non pensiamo piuttosto che debba rimanere così. Tra l'altro non se ci avete fatto caso: ma sembra che l'unico faro di innovazione per SBN sia stato il passaggio a SBN 2. Se ne parlava dal 1996 e mi ricordo che quando nel 2002 tirai fuori la cosa c'era chi mi prendeva in giro dicendo che era un discorso vecchio, una cosa ormai arenata e di cui non si vendeva nulla. Invece poi è andato. Ma ormai, finito quello, non esistono non dico piani, ma neppure idee, discorsi, nulla.
pierfranco
-- Andrea Marchitelli marchitelli@gmail.com - Roma _______________________________________________ Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
Rispondendo alle osservazioni di Pierfranco: 1) purtroppo i soldi per i metaopac regionali sono già stati abbondantemente elargiti a chi doveva implementarli 2) allora prima di tutto bisognerebbe permettere agli utenti dell'OPAC SBN di fare richieste ILL 4) bellissimo Trove :) Giustamente un conto è parlare di RTA, un conto è parlare di informazioni sull'accesso 5) il trattamento della disponibilità in tempo reale per risorse cartacee ed elettroniche è diverso. Per le risorse cartacee viene solitamente interrogato il gestionale, per le risorse elettroniche è possibile andare a interrogare altre sorgenti. Non sono convinto sarebbe un lavoro in prospettiva
Personalmente resto dell'idea che informazioni di disponibilità in tempo reale (RTA) all'interno dell'OPAC SBN, non siano un dato interessante. Al massimo avere informazioni d'accesso non in tempo reale, del tipo se la copia è disponibile al prestito o meno.
Con la terza parte della mia mail volevo rappresentare la mentalità dominante in Italia, in risposta a chi si chiede come mai le ditte italiane non abbiano una API per interfacciarsi ai propri gestionali. Detto questo sapete benissimo che mi auspico il massimo dell'interoperabilità e dell'adesione agli standard. Il mio non vuol essere un atteggiamento pessimistico, parlo di quello che vedo attorno a me. Il fatto che la mia azienda stia investendo in una interfaccia REST per il proprio gestionale, non deriva certo dalle pressioni dei nostri clienti o delle istituzioni :( ma solamente dal desiderio di fare qualcosa di più interoperabile :)
@Andrea Al momento il webservice con interfaccia SOAP viene usato solo da DiscoveryNG. Quello che tu hai visto in XML è una rappresentazione del record, in cui sì, ci sono le informazioni di circolazione in tempo reale :) È gratuito, non abbiamo moduli aggiuntivi o cose particolari per cui facciamo pagare quote aggiuntive. Una cosa sviluppata per un cliente viene (nel bene e nel male) condivisa da tutti gli altri.
Il giorno 06 agosto 2013 14:07, Andrea Marchitelli marchitelli@gmail.comha scritto:
Ciao,
Esporre le informazioni di circolazione in SBN
leggendo lo scambio di Giulio e Pierfranco mi pare che non parliamo tutti della stessa cosa. A scanso di equivoci, specifico che io parlavo di quello che viene spesso definita Real Time Availability (RTA), cioe' informazioni di disponibilita' in tempo reale: questo documento che ho trovato a catalogo e' disponibile in questo momento a scaffale?
Informazioni sullo stato della circolazione (o come preferite chiamarlo) riguardano invece una condizione con relativa a quell'istante: un libro e' per sola consultazione o anche per il prestito, e' smarrito ecc.
In generale credo che la questione riguardi l'interoperabilita' in generale (e in particolare l'uso di discovery layer potenzialmente separati da ILS) non tanto il fatto di avere un unico catalogo nazionale con l'indicazione di disponibilita'...
Comunque per ora ho scoperto (cosa che non sapevo) che l'ILS di Comperio permette di interrogare un webservice che da informazioni sulla RTA, nel d950-s1, se non sbaglio. Chi adotta quell'ILS ce l'ha a disposizione gratuitamente? Pero' son d'accordo con Giulio sul fatto che in Italia non si senta, diffusamente, il bisogno di avere a disposizione tali possibilita' di apertura. Mi pare importante pero', che un'azienda riesca a dare una risposta positiva, nel caso (strano) qualcuno abbia l'esigenza.
andrea
Andrea Marchitelli marchitelli@gmail.com - Roma _______________________________________________ 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 Giulio Bonanome Sent: Tuesday, August 06, 2013 11:34 AM To: Lista di discussione per bibliotecari e wikipediani Subject: [Bibliotecari] Informazioni di circolazione e API di gestionali inItalia Esporre le informazioni di circolazione in SBN Secondo me non ha alcun senso. Simpatico. Ma non ha senso.
Ho l'impressione che questa obiezioni derivi dal fatto che si immagina che l'opac dell'indice debba immediatamente presentare le informazioni di disponibilità per tutti i risultati di una ricerca, risultati che magari ammontano a centinaia di esemplari.
Fatto in questo modo non avrebbe senso, perché normalmente un utente è interessato a conoscere la disponibilità di un piccolo numero di esemplari. Quindi io immaginerei la funzionalità in questo modo: fatta la ricerca ed esaminati i risultati, l'utente sceglie un sottoinsieme di documenti e di relative localizzazioni, e l'opac tutto contento gli presenta l'elenco delle copie con le condizioni di disponibilità (ovviamente l'utente potrebbe anche scegliere di vedere la disponibilità di tutte le copie, ma a quel punto si sa che questo gli interessa).
Per quanto riguarda le informazioni da mostrare, io penso che ci vorrebbero sia le condizioni di disponibilità che la situazione in tempo reale, altrimenti si rischia di vedere che un documento non è disponibile senza poter sapere se è in prestito, se è escluso dal prestito ecc. ecc.
Mi interessa anche il discorso sul disaccoppiamento tra opac e gestionale: non ho mai fatto ricerche per vedere quanti esempi ce ne sono, ma qui in Liguria l'opac regionale (http://www.catalogobibliotecheliguri.it/) esiste dal 1998 ed è sempre stato indipendente dai gestionali. Attualmente ha un proprio database alimentato da Unimarc (polo regionale SBN e Bibliowin) e da importazioni diretta da database Isis, e un metaopac Z39.50 che interroga altri cataloghi esistenti in regione. Non facciamo harvesting tramite OAI-PMH perché non risulta che ci sia qualche catalogo ligure che possa servire da provider. Il db dell'opac fa da target Z ma non da provider OAI-PMH.
Per i dati di disponibilità per ora tutto quello che riusciamo a fare è mettere un link al gestionale, da cui l'utente può vedere la situazione, ma prossimamente avremo anche la visualizzazione in opac dei dati di SbnWeb, che costituiscono la maggior parte del catalogo "nativo". Per i dati recuperati tramite Z ovviamente possiamo al massimo visualizzare un link all'opac originale se questo viene fornito dal target.
Se qualcuno avesse commenti (compresi quelli negativi) o suggerimenti sarei ben contento di sentirli, anche fuori dalla lista se non si ritengono interessanti per tutti.
Beppe
bibliotecari@liste.wikimedia.it
-
Andrea Marchitelli -
Giulio Bonanome -
Pavoletti Giuseppe Carlo -
Pierfranco Minsenti