Libraries 2.0 and RSS

Editor's Notes

• #4: Creazione: si passa dalle pagine web create dai webmaster all'UCC (user-created content), dal sito web al blog e al wiki, dall'inserimento manuale di informazioni all'aggregazione di informazioni da altre fonti.
• #5: Fruizione: si passa dalla semplice visualizzazione dei contenuti sulla pagina web all'offerta di modi personalizzati di ri-utilizzare quei contenuti: email alerts, feeds da caricare nel proprio news reader o da ri-pubblicare sul proprio sito, fino a web services che permettono di effettuare in maniera remota operazioni avanzate sui contenuti e di ri-aggregarli in altri contesti.
• #7: E' cambiata la concezione dei sistemi informativi avanzati: il passaggio da sistemi informativi chiusi e altamente coordinati a sistemi informativi aperti basati su architetture distribuite (con fonti facilmente accessibili, addirittura “hackable”) in cui la necessità di coordinazione è minima grazie all'utilizzo di tecnologie, protocolli e formati standard.
• #8: Le tecnologie Web 2.0 offrono gli strumenti per rendere i contenuti accessibili da qualsiasi servizio “consumer” senza necessità di coordinazione: in questo modo qualsiasi produttore di contenuti è una potenziale fonte per altri servizi: i servizi che producono e che consumano informazioni diventano minimamente interdipendenti, “loosely coupled”: il passaggio da sistemi “tightly coupled” a sistemi “loosely coupled” è una delle trasformazioni chiave del Web 2.0 individuate da Tim O'Reilly nelle sue famose pagine che definiscono il Web 2.0.
• #9: Il flusso delle informazioni: da un flusso che era (o almeno era percepito come) un flusso diretto dalla fonte all'utente finale, che visualizzava l'informazione in una schermata, ad un flusso incontrollato multi-direzionale in cui i produttori sono spesso anche consumer e i consumer sono spesso servizi avanzati che rielaborano, aggregano e disgregano i contenuti e li rendono disponibili ad altri servizi consumer, in un ciclo potenzialmente infinito.
• #10: In questo nuovo contesto, l'informazione estratta da un database e visualizzata dall'utente finale in una schermata, senza l'offerta di ulteriori modi di ri-utilizzo e possibilmente di estrazione dinamica delle informazioni da quel sistema, ha un ciclo di vita breve e possibilità quasi nulle di disseminazione
• #11: In base a quanto detto sopra, per le biblioteche, adottare un approccio Web 2.0 significa andare oltre l'offerta di un'interfaccia web per navigare e fare ricerche nei propri cataloghi e iniziare ad usare tecnologie Web 2.0 per rendere le proprie informazioni bibliografiche accessibili ad altri servizi consumer e per, a propria volta, “consumare” e ri-utilizzare informazioni rese disponibili attraverso le stesse tecnologie da altre biblioteche o da altri servizi bibliografici. 
• #12: In base a quanto detto sopra, per le biblioteche, adottare un approccio Web 2.0 significa andare oltre l'offerta di un'interfaccia web per navigare e fare ricerche nei propri cataloghi e iniziare ad usare tecnologie Web 2.0 per rendere le proprie informazioni bibliografiche accessibili ad altri servizi consumer e per, a propria volta, “consumare” e ri-utilizzare informazioni rese disponibili attraverso le stesse tecnologie da altre biblioteche o da altri servizi bibliografici. 
• #13: A questo fine, sia l'architettura OAI1 che il meccanismo RSS sono esempi del tipico approccio Web 2.0: entrambi si basano su un'architettura distribuita, entrambi realizzano l'accessibilità in modo semplice tramite web services di tipo RESTful (il classico meccanismo richiesta / risposta http "stateless") ed entrambi si appoggiano su standard largamente adottati cosicché non sono necessari ulteriori accordi tra servizio produttore dei contenuti (fonte) e servizi che vogliano ri-utilizzare quei contenuti. Nota: Normalmente, il protocollo OAI-PMH non viene incluso tra le tipiche tecnologie Web 2.0, perché si parlava di OAI anche prima di iniziare a parlare di Web 2.0, ma è una tecnologia e un tipo di approccio Web 2.0 a pieno titolo, soprattutto se si considerano le potenzialità del self-archiving da parte degli autori.
• #14: Di solito, la soluzione proposta alle biblioteche per rendere accessibili i loro cataloghi è quella di diventare Open Archive providers, rendendo così i loro record bibliografici disponibili per l'harvesting da parte di altri servizi. L'architettura OAI, pur basandosi su un protocollo semplicissimo e su standard largamente adottati come il Dublin Core, è piuttosto complessa, e l'implementazione delle risposte ai “verb” richiede l'intervento di un programmatore esperto. Fortunatamente, diversi software di gestione delle biblioteche adesso forniscono un'interfaccia OAI-PMH che richiede solo una configurazione iniziale.
• #15: Un ostacolo alla condivisione dei cataloghi tra biblioteche o alla disseminazione delle informazioni bibliografiche può essere la difficoltà per alcune di queste a creare un'interfaccia OAI-PMH e soprattutto la difficoltà sia per le biblioteche che per eventuali altri servizi “consumer” a incorporare un OAI harvester nel proprio sito per poter accedere alle informazioni bibliografiche degli altri provider. Inoltre, di solito gli OAI harvester si limitano a raccogliere i record dai vari archivi e ad offrire un semplice motore di ricerca. Difficilmente si può configurare un OAI harvester per filtrare le ultime accessioni di n biblioteche su un certo soggetto... Esistono anche protocolli standard per la ricerca e l'estrazione di informazioni da servizi remoti (come SRU) ma per adesso il numero di servizi che li utilizza è ancora bassissimo.
• #16: Considerato che i potenziali servizi “consumer” delle informazioni prodotte da una biblioteca sono molti e di diverso tipo (dai siti delle facoltà universitarie ai siti dei Comuni fino ai servizi inter-bibliotecari), la possibilità di renderne il ri-utilizzo il più semplice possibile è importante.
• #28: Facilità di implementazione per i consumer: Con l'utilizzo di un CMS in grado di aggregare feed (la maggior parte): nessuna difficoltà Senza l'utilizzo di un CMS: esistono widget (poche righe di codice javascript) per incorporare feed in qualsiasi pagina web ed esistono servizi di aggregazione di feed che producono a loro volta feed aggregate che possono essere incorporate nelle pagine web Inoltre, molti CMS avanzati permettono di salvare i record aggregati e permettono il browsing e la ricerca dei record
• #30: Vantaggio rispetto a OAI-PMH: alta ri-usabilità: esistono i tool per leggere le feed e per incorporarle nei siti; la maggior parte dei tool per creare siti web o blog offre funzionalità sia per incorporare RSS feed sia per aggregarne gli item in modo avanzato (es. Drupal). I servizi “consumer” possono molto più facilmente incorporare un RSS reader o usare un plugin per un RSS aggregator che non leggere i record bibliografici tramite OAI-PMH
• #32: Si possono produrre feed di qualità usando tutti gli elementi previsti: la maggior parte dei lettori RSS è in grado di trattare quasi tutti gli elementi Il campo <category>, ad es., usando una classificazione o un soggettario comune, permette di gestire la semantica si può mappare la maggior parte dei campi fondamentali del Dublin Core agli elementi RSS
• #33: RSS è estendibile con altri namespaces: di solito si usa Dublin Core (che in RSS 1.0, che è RDF, è incluso di default), ma si può usare qualsiasi altro namespace. Naturalmente, i lettori RSS standard ignoreranno gli elementi aggiuntivi (anche se DC è spesso accettato), ma con alcuni tool, in maniera più o meno facile (??), si possono configurare i campi da leggere. Vista la caratteristica di estendibilità di RSS, si spera che i lettori e gli aggregatori RSS evolvano verso la consapevolezza dei namespace aggiuntivi o almeno verso la configurabilità degli elementi da leggere.