Sogno o incubo? Una nota a proposito di OPAC, #nuovosbn, digital lending, API, dati aperti e antitrust. E disruption
Working notes on open data, libraries, API, antitrust law and how to work on the integration of e-lending metadata into 'traditional' (though 'new generation') OPACs. A few remarks also on #nuovosbn the Twitter hashtag where people is sending ideas on how and what to change in SBN (Servizio Bibliotecario Nazionale) an old national co-operation effort of the italian libraries that needs, today, a serious 'disruption' along more open and updated long term strategies.
Ok, nient'altro? Il titolo è ovviamente uno scherzo per dare il senso degli obiettivi piuttosto ampi di questa brevissima nota. In modo non sistematico (ma spero ordinato), cercherò di riassumere alcune idee relative alle relazioni tra apertura dei dati, biblioteche digitali (in particolare quando contengono materiali coperti da copyright gestiti attraverso sistemi di "digital lending") [1] e funzionamento del mercato dei contenuti nel segmento delle biblioteche. Si tratta di appunti di lavoro e il loro obiettivo è quello di ottenere feedback critico.
Sottolineo - anche se la cosa è piuttosto evidente - che la mia non è una prospettiva "accademica" di discussione ma una prospettiva operativa, poiché queste riflessioni servono a definire la politica da seguire con la piattaforma MLOL (<
http://www.mlol.it>) che oggi (dati di giugno 2013) serve circa 3.000 biblioteche in 14 regioni italiane e 4 paesi stranieri (con numeri in rapida crescita). Questa piattaforma è anche - di fatto - un grande progetto cooperativo dei sistemi bibliotecari pubblici italiani, e dunque si tratta anche di una riflessione sul rapporto tra enti pubblici e soggetti privati nel mercato dei contenuti digitali.Nel recente dibattito su #nuovosbn non mi pare sia stata affrontata la tematica del digitale, cosa piuttosto grave poiché ciò significa rinunciare a riflettere sui servizi potenzialmente costruibili nel contesto SBN in un'area documentale enormemente vasta, che costituisce evidentemente il futuro degli OPAC delle biblioteche italiane. Ripensare SBN non può prescindere da una riflessione su come verranno gestiti i metadati degli oggetti digitali (non importa se nel pubblico dominio, fuori commercio, orfani o in digital lending) che circolano tra gli utenti delle biblioteche italiane di ogni tipologia.
Riconoscere il problema non significa naturalmente che il problema sia semplice o che la soluzione sia sotto mano. Costruire servizi usabili per gli utenti finali nei quali siano presenti sia contenuti analogici che digitali non è affatto semplice, ma ciò non toglie che si tratti di un compito essenziale, considerando che è dal mondo dei documenti digitali che principalmente arriveranno le nuove e più massicce ingestioni di dati nei prossimi anni.
Il problema si pone non solo a livello nazionale ma anche a livello locale. Gli OPAC "tradizionali" (per quanto di "nuova generazione") non sono oggi attrezzati adeguatamente in termini di usabilità nell'accesso ai documenti digitali. Si tende spesso a pensare che il digitale vada "normalizzato" trattandolo al modo dei record bibliografici standard, il che ha una sua ovvia ragionevolezza. Ma ci si dimentica che questa prospettiva contiene un problema di fondo: Internet e il digitale hanno già modificato gli stili di accesso ai contenuti e i problemi da risolvere nello sviluppo di sistemi di ricerca e discovery. L'integrazione del digitale negli OPAC deve essere quindi l'occasione per il ripensamento di molti criteri di usabilità degli OPAC oggi non più attuali (un esempio tra tutti: le cosiddette "faccette" suggerite dagli OPAC suggeriscono in media all'utente temi del tutto irrilevanti per il filtraggio dell'informazione nonostante la pretesa di aggiungere semantica alla ricerca per stringhe. Le faccette sono un'idea buona, evidentemente, la cui applicazione resta però molto spesso ancora lontana da un'usabilità reale per l'utente finale).
In Italia cominciamo appena ad accettare (con una gradazione di impegno che dipende dai settori di applicazione) una visione estesa della necessità di aprire i dati della pubblica amministrazione nel suo complesso [2].
Ma perché aprire i dati? Qual è l'idea che regola una simile prospettiva nel lungo termine? Credo che un buon modello di partenza ci venga offerto dall'esempio del protocollo OAI-PMH [3], che è a fondamento degli sviluppi dell'Open Access ed è l'emblema in un certo senso del tema degli open data in ambito bibliotecario.
L'architettura del protocollo OAI-PMH prevede una distinzione concettuale netta tra fornitori di dati e fornitori di servizi. Un repository (ad esempio, DSpace@MIT gestito appunto dal MIT di Boston) è un Data Provider. OAISTER è invece un Service Provider, nel caso specifico un servizio di ricerca su metadati provenienti da repository OA nel mondo gestito da OCLC (inclusi quelli provenienti dal MIT). Altro esempio: AMS Acta è un archivio aperto dell'Università di Bologna, mentre OpenAIRE è un servizio europeo di accesso a dati OA (tra cui quelli di AMS Acta).
Questa distinzione - ormai molto conosciuta e diffusa tra gli operatori - è oggi a fondamento di una relazione virtuosa tra enti pubblici e potenziali iniziative pubbliche, private o no-profit, il cui obiettivo sia quello di sviluppare servizi a valore aggiunto (eventualmente anche a pagamento) sulla base di tali dati. Il modello degli Open Data ha raggiunto un'infinità di articolazioni ed è ormai un dato di fatto nel settore delle PA in molti paesi del mondo.
Oggi questa distinzione è divenuta centrale nel digital marketing ben oltre la dimensione del mondo bibliotecario e dei soli dati aperti pubblici. I principali operatori digitali nel mondo (Facebook, Amazon, Google, Apple, Twitter, Ebay, Netflix, ecc.) [4] gestiscono API [5] che consentono alle imprese e di fatto a qualunque tipo di operatore di sviluppare servizi basati sui dati e un'infrastruttura on the cloud. In genere, per il pubblico meno esperto, la dinamica di queste aziende come "piattaforme" è poco evidente. Amazon, ad esempio, viene percepita coma "una" azienda, laddove il business di questa azienda è generato in maniera consistente dall'integrazione di decine di milioni di partner affiliati, venditori terze parti, società che acquisiscono servizi basati sull'infrastruttura cloud. Non "una" azienda, quindi, ma un'azienda che genera servizi (decisivi) per milioni di aziende.
A tutto ciò si aggiunge ovviamente - semplificando in modo estremo - la riflessione sui modelli di gratuità (Chris Anderson) e sul ruolo delle piattaforme aperte nei processi di "disruption digitale" sul mercato (James McQuivey) [6].
Se si richiama tutto ciò è perché c'è un'evidente discrepanza, una sorta di lag, nel rapporto tra la realtà appena disegnata e quanto accade - almeno in Italia - nel mercato bibliotecario. In questo ambito vediamo agire ancora un'idea della gestione dei dati bibliotecari come "concessione pubblica" e non come concorrenza tra operatori di ogni genere - in una sorta di processo darwiniano di variazione e selezione - attorno a un bene comune aperto, i dati stessi appunto. Questo lag potrebbe essere anche comprensibile in termini puramente aziendali (le aziende, si sa, non sempre riescono a tenere il passo dei tempi) se non ci fosse in Italia l'aggravante che spesso lo Stato o gli enti locali sono co-proprietari (assieme a soggetti privati di fatto "concessionari" di un bene pubblico) dei software che chiudono tali dati con meccanismi "lock-in" che finanche in realtà ultra-competitive del business digitale sono considerate ormai arretrate e deleterie.
Se poi aggiungiamo ciò che in Italia ha generato lo sviluppo di posizioni aziendali dominanti, si capisce come questo generi automaticamente - a catena - rischi antitrust di ogni tipo. Usare una posizione dominante sul mercato per acquisire in modo improprio dominanza in un segmento diverso pone infatti problemi molto seri in termini di dinamica della concorrenza.
Ma la cultura antitrust italiana è parte della storia recente del nostro paese. Mentre negli Stati Uniti esiste una normativa specifica per la regolamentazione della concorrenza sin dallo Sherman Act (1890), dal Clayton Act (1914) e dal Federal Trade Commission Act (1914) [7], in Italia la prima legge sul tema è del 1990: la Legge 10 ottobre 1990, n. 287 ("Norme per la tutela della concorrenza e del mercato"), con la quale viene anche istituita per la prima volta nel nostro paese un'Autorità Garante della Concorrenza e del Mercato [8]. Non è quindi una sorpresa se in un ambito così specifico come quello del mercato bibliotecario l'attenzione italiana a queste problematiche sia vicina allo zero, e se una cultura amministrativa di rispetto di tali norme non sia ancora un valore condiviso.
Evidentemente non sto ponendo qui un tema "legale". Sto invece ponendo un problema politico molto netto per le pubbliche amministrazioni che si trovino a condividere la proprietà di software e applicazioni che di fatto costituiscono un freno a uno sviluppo libero del mercato delle applicazioni rivolte a questo segmento di mercato. Le posizioni centralistiche - un tempo giustificate in nome di una maggiore efficienza - non sono più credibili e giustificabili oggi. Una logica "federata", in cui i soggetti pubblici si limitano a imporre e validare standard di interoperabilità, è nei fatti l'unico scenario accettabile.
Che le biblioteche digitali debbano avere interfacce applicative che consentano un vasto repertorio di riusi e di innovazioni di servizio è ormai scontato guardando alle realtà più rappresentative nel mondo. Non serve e non è l'obiettivo di questo articolo fare una rassegna delle realtà principali. Mi limiterò a pochi esempi.
Europeana e DPLA (quest'ultima lanciata di recente) sono probabilmente i due più grandi repository di contenuti digitali storici al mondo. Entrambi espongono API in una logica di apertura e riusabilità dei metadati molto radicale (ad esempio, rilascio nel pubblico dominio con licenza CC0 in entrambi i casi) [9].
Il mix di API efficienti aperte e metadati liberi produce risultati istantanei. Per rendersene conto è sufficiente visitare la pagina dedicata alle "apps" di DPLA [10], un insieme di applicazioni sviluppato da terze parti (non importa se pubbliche, private, no profit, singoli sviluppatori, ecc.) per esplorare nuove possibilità di accesso ed elaborazione dell'informazione veicolata dal repository base. Le app finora sviluppate sono poche, ovviamente, ma è la politica di base che conta, una politica sostanzialmente condivisa da Europeana sebbene quest'ultima sia il frutto di un'evoluzione più lenta. Le "appfest" di DPLA e gli "hackathon" di Europeana sono eventi simbolici di un modo potenzialmente davvero nuovo di condividere e gestire collettivamente lo sviluppo di un servizio bibliotecario.
Si tratta in sostanza di un'idea crowdsourcing dei servizi basati sui dati della biblioteca digitale: Europeana e la Digital Public Library of America sono pensate e comunicate come una piattaforma per chiunque voglia contribuire, non come un progetto verticistico che punta al (o finisce per il provocare il) dominio di uno o pochi operatori che diventano concessionari su base statale di metadati (manco i metadati fossero come le autostrade o le frequenze del nostro spettro elettromagnetico...). Il crowdsouring non è una moda o un debito pagato alla moda del web 2.0. Il crowdsourcing è l'unico modo per organizzare un mercato efficiente e garantire innovazione costante a costi sostenibili. Un tempo erano le gare d'appalto a verificare la varietà dell'offerta sul mercato. API e open data allargano lo spettro e stimolano di fatto lo sviluppo di novità e competizione.
Ma come ci si comporta quando gli oggetti contenuti in una biblioteca digitale sono protetti da copyright, sono oggetti di fatto in commercio e gli stessi metadati hanno restrizioni in termini di diffusione? In altri termini, come ci si comporta quando si passa da contenuti aperti (in Europeana e DPLA) al digital lending?
Anche in questo caso si pone un problema di distinzione tra "Data Provider" e "Service Provider". Gli operatori privati che intermediano i contenuti sono in questo caso i data provider. Ciò può essere fatto in molti modi diversi: Overdrive, Springer Link, Ebsco, Torrossa di Casalini Libri, MLOL, ecc. sono esempi di fornitori e intermediatori di contenuti digitali.
Gli OPAC e i sistemi gestionali delle biblioteche sono invece il principale sowftare di servizio usato dalle biblioteche nei confronti dei propri utenti. Un gestionale oggi di base di qualità corrente consente almeno dal punto di vista dell'utente finale:
Molti bibliotecari esprimono comprensibilmente l'esigenza che contenuti digitali e OPAC, ad esempio, siano fortemente integrati. Perché ciò sia possibile sono necessarie però tre condizioni:
Negli USA, ad esempio, Overdrive ha sviluppato API che consentono l'integrazione in OPAC di alcune funzioni essenziali come ricerca, integrazione di metadati, disponibilità del titolo, ecc. Molti sviluppatori di software gestionale per le biblioteche hanno implementato queste API in modo da consentire un'integrazione trasparente all'utente. Ad esempio, il sistema Bibliocommons usato dalla New York Public Library integra le API di Overdrive e consente di usare l'OPAC come sistema di discovery unificato per tutte le tipologie di risorse. [11]
I dettagli di implementazione del sistema mostrano che si tratta di un progetto di interfaccia accurato, in cui ci si è posti in modo sistematico e in un'ottica di usabilità e di design centrato sull'utente il problema di come fare il mashup di dati analogici e digitali.
Ebook nell'OPAC di NYPL
Scheda ebook nell'OPAC Di NYPL
La stessa scheda nel catalogo Overdrive personalizzato per NYPL
Non cito queste cose come introduzione alla tecnologia, ma semplicemente per mostrare come negli USA - l'unico mercato bibliotecario digitale già maturo - questa logica di API aperte e integrazioni tra data provider e service provider è in atto e funzionante a regime (la NYPL, giusto per dare un'idea, ha generato 1,1 milioni di prestiti di ebook nel 2012) [12].
In Italia - con un modello molto simile - le API MLOL appariranno entro la fine del 2013 e consentiranno esattamente il medesimo tipo di integrazione. [13]
In sintesi, il compito di OPAC e sistemi gestionali è quello di accogliere (in una logica di service provider) i contenuti digitali forniti dai diversi operatori sul mercato. Gli OPAC sono gli scaffali delle biblioteche e così come non ha senso vincolare un venditore di mobili a un fornitore di libri, così non ha senso vincolare un fornitore di OPAC a un fornitore di ebook (non sto neanche a dire del paradosso che si genererebbe nel caso le due cose - fornitore di OPAC e fornitore di ebook - poi coincidessero e il software in questione fosse - per accidente - di proprietà di un ente pubblico).
Il tema non riguarda tuttavia solo gli OPAC e i sistemi gestionali delle singole biblioteche e dei singoli sistemi bibliotecari sul territorio. Anche i servizi di carattere nazionale (come SBN) devono confrontarsi con il digitale. Grandi cataloghi internazionali con funzioni simili a quelle di SBN includono oggi informazioni sugli ebook (un esempio per tutti: Worldcat di OCLC che include anche integrazione dei metadati Overdrive e presumibilmente funzioni di localizzazione della risorsa digitale).
Una scheda ebook collegata a overdrive da WORLDCAT
Come accennato in principio il dibattito recente su #nuovosbn ha sostanzialmente ignorato (con la sola eccezione di un intervento di Vanni Bertini) il tema dell'integrazione delle risorse digitali (a tutti i livelli: dal pubblico dominio in su). In Francia, ad esempio, sin dai tempi di Gallica 2 (2008), c'è nei progetti nazionali di biblioteca digitale una integrazione di record relativi a servizi di digital lending assieme al materiale storico nel pubblico dominio. I record degli "e-distributeurs" sono integrati nel repository complessivo, permettono - se previsto - l'accesso gratuito ad anteprime dei documenti e rimandano alla piattaforma di erogazione e agli accordi delle singole biblioteche per ciò che concerne l'accesso dell'utente finale [14].
L'esperienza francese non risolve naturalmente il problema di come segnalare adeguatamente - sul digitale - il posseduto delle biblioteche, che è una delle funzioni principali dello sviluppo di cataloghi nazionali o geograficamente comprensivi come SBN o Worldcat. L'esperienza in ambito accademico con il protocollo OpenURL e applicativi come SFX di ExLibris [15] potrebbero essere una delle soluzioni, assieme ad uno standard di autenticazione federata che normalizzi il modo di verificare a quale collezione ha diritto d'accesso il singolo utente.
La dimenticanza del digitale nel dibattito su #nuovosbn è secondo me una dimenticanza grave. E' stato detto in apertura di questo dibattito - l'invito era di Claudio Leombroni - che dobbiamo "ricominciare a sognare". Sono d'accordo con Leombroni, al 100%. Non dimentichiamoci però di sognare a partire dalla realtà nella quale siamo oggi, una realtà nella quale l'integrazione del digitale è il principale e fondamentale scopo dei nuovi sistemi bibliotecari per i prossimi decenni. Se il sogno non ricomincia da qui, il Servizio Bibliotecario Nazionale rischia di trasformarsi nel peggior incubo da arroccamento nel passato che si possa immaginare e nel giro di qualche anno gli OPAC SBN saranno utilizzati solo dai motori di ricerca e da altri spider automatici.
In Italia ci sono oggi le persone e i mezzi (disseminati sul territorio) per ripensare da capo e a fondo la questione. Facciamolo. Usando come benchmark il meglio - solo il meglio, però - di quello che ci arriva da realtà più avanzate. Se invece di sognare decidiamo di rimanere nel mindset di SBN vecchia maniera, non stupiamoci poi di finire in una condizione - nel giro di pochi anni - nella quale il mondo avrà imparato a fare con pochi mezzi cose eccellenti, mentre qualcuno continuerà a spendere milioni di euro l'anno per ottenere risultati che un ragazzino è in grado di tirar fuori in forma migliore. Gratis. Nel suo tempo libero.
La lettura di James McQuivey è caldamente consigliata a tutti quanti vogliano contribuire al tema del #nuovosbn. Il termine chiave è "disruption". E non è una moda, è il modo di funzionare dell'economia digitale nella quale volenti o nolenti tutti noi agiamo oggi.
Giulio Blasi, MLOL, e-mail: blasi@horizons.it
[1] Come ho spiegato altrove, "digital lending" è per me inteso - in senso generalissimo - come servizio di accesso remoto a contenuti protetti da copyright intermediati dalle biblioteche. Si veda ad esempio Giulio Blasi, Gli e-book (e i contenuti digitali in genere) in biblioteca. Una mappa a partire dall'esperienza di MediaLibraryOnLine, "Digitalia", 2011, <
http://digitalia.sbn.it/article/view/474>; Id., Ebook, DRM e biblioteche: una mappa sintetica sulle prospettive del 'digital lending' per libri e altri media in Italia, "Bibliotime", 13 (2010), 3, <https://www.aib.it/aib/sezioni/emr/bibtime/num-xiii-3/blasi.htm>.[2] Cfr. Antonella De Robbio, Forme e gradi di apertura dei dati. I nuovi alfabeti dell'Open Biblio tra scienza e società, "Biblioteche oggi", 30 (2012), 6, p. 11-24, <
http://www.bibliotecheoggi.it/content/201200601101.pdf>.[3] V. <
http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm>.[4] Vedi ad esempio <http://blog.programmableweb.com/2012/07/19/what-makes-a-great-api-the-five-keys/>.
[5] Che cos'è una API? Ecco una risposta da <
http://www.programmableweb.com/faq>: "An API, or Application Programming Interface, is a set of functions that one computer program makes available to other programs so they can talk to it directly. There are many types of APIs: operating system APIs, application APIs, toolkit APIs and now web site APIs. The classic example is a computer operating system like Microsoft Windows with hundreds of APIs providing services from accessing your hard drive to drawing on the screen. These opeating system APIs then are used by desktop applications like spreadsheets and word processors. Today, APIs can be specified by web sites. Thus amazon.com provides a set of 'retail APIs' that allow developers to create computer programs that make use of Amazon's sophisticated online retail infrastructure. Third party software developers have used this to create specialized storefronts. APIs from eBay facilitate program-to-program auction management, Google's APIs provide search and mapping services, and so on."[6] Vedi Chris Anderson, Free. The Future of a Radical Price, New York, Hyperion 2009, <
http://www.scribd.com/doc/17135767/free-by-chris-anderson>; James McQuivey,Digital Disruption. Unleashing the Next Wave of Innovation, Forrester Research, Las Vegas - NV, Amazon Publishing, 2013.[7] Per una rassegna di massima e una primissima informazione si veda <
http://en.wikipedia.org/wiki/United_States_antitrust_law>.[8] Il testo integrale della legge è reperibile a quest'indirizzo:
<
http://www.agcm.it/normativa/concorrenza/4531-legge-10-ottobre-1990-n-287-norme-per-la-tutela-della-concorrenza-e-del-mercato.html>.[9] Per DPLA v. <
http://dp.la/info/wp-content/uploads/2013/04/DPLAMetadataPolicy.pdf>; per Europeana v. <http://www.europeana.eu/portal/rights/api-terms-of-use.html>.[10] V. <
http://dp.la/apps>.[11] Ecco una query di esempio che include risultati gestiti con le API Overdrive: <
http://nypl.bibliocommons.com/search?t=smart&q=dan%20brown&commit=Search&searchOpt=catalogue>. Per un commento su applicazioni delle API in alcune biblioteche americane v. <http://www.thedigitalshift.com/2013/04/ebooks/overdrives-upcoming-apis-to-allow-ebook-checkouts-from-opac/>.[12] Ecco qualche dato fornito da Overdrive sulle principali biblitoteche americane per numero di download di ebook nel 2012
: <http://www.overdrive.com/news/overdrive-announces-library-ebook-leaders-for-2012/>.[13] Vedi anche Giulio Blasi, Rapporto MLOL 2013 sul prestito digitale. Biblioteche, utenti, contenuti, editori, servizi, "Biblioteche Oggi, 31 (2013), 5, p. 25-32.
[14] Per una lista completa dei distributori di contenuti digitali integrati in Gallica e un link ai relativi dataset v. <
http://gallica.bnf.fr/html/editorial/e-distributeurs>[15] v. <
http://www.niso.org/standards/z39-88-2004> e <http://www.exlibrisgroup.com/category/SFXOverview>.