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