Certo, come tu stesso ricordi, dei monoliti difficilmente ci si può liberare se pensiamo alle funzioni di catalogazione o circolazione dei documenti, che richiedono sw molto articolati e strutturati (giusto, SERE). E però anche qui bisogna distinguere tra monoliti o insomma piattaforme di spessore ma aperte, scalabili e interoperabili e piattaforme di spessore ma chiuse, proprietarie che non colloquiano con nessuno se non con altri moduli dello stesso fornitore…

E così arriviamo al discorso del layer da piazzare sopra i database, che, come giustamente rivendichi tu, può e deve essere configurabile dalle biblioteche, quanto a layout, struttura, contenuto e logica di navigazione. Sembra banale e scontato se pensiamo a quello che accade con altre applicazioni web, e diventa utopia nel nostro ambito…

Io, che vedo nel futuro le biblioteche acquistare direttamente i record XML dagli editori, riversarli nel catalogo magari con qualche piccolo aggiustamento da apportare in batch, indicizzarli come con il motore che meglio si presta, interrogarli con l’interfaccia che si desidera (magari anche un’interfaccia esterna, chessò, una piattaforma di elearning), credo che la stagione dei pachidermi stia finendo, così come credo stia finendo la stagione, anzi, l’era, delle applicazioni verticali.

Il futuro è dell’orizzontalità: ricombinare, aggregare, prendere pezzi diversi e mischiarli in maniera originale. E poi far esplodere tutto ciò in mille badge di informazioni che gli utenti possono scaricarsi sul blog o gli studenti aggiungere nella piattaforma di elearning.

Il caso di “Urbanistica” è davvero interessante e mi piacerebbe approfondire. In ogni caso, se ho capito bene, vi ritrovate una base di dati da utilizzare e ricombinare e interrogare come vi pare e questo mi sembra fondamentale. I dati dovrebbero sempre poter essere interrogati secondo varie angolature e, perché no, anche direttamente dal web. Questa è un’altra vexata quaestio: come rendere il patrimonio di informazioni strutturate disponibile per i motori di ricerca?

Se cerco la rivista in Google, al quarto posto trovo appunto il record di Worldcat. Con una base di record in XML e la libertà al livello intermedio (=interfaccia di interrogazione) è possibile anche esporre i dati al crawling dei motori di ricerca… In questo caso ci sono credo problemi di proprietà e accesso alle informazioni, però la fattibilità tecnica non mi sembra in discussione.

@SERE: la vedova di Dobis è troppo forte! :D
Ho già accennato nella risposta a Pierre che sw strutturati sono essenziali e ci vuole sostanza dietro l’immagine frizzante delle interfacce 2.0 Però credo che il punto sia come sono costruiti questi programmi: spesso infatti sono chiusi (cioè aperti solo ad applicazioni della stessa società) e credo tutti noi abbiamo sperimentato le difficoltà anche solo di avere un’uscita in XML dei dati contenuti nei cataloghi oppure API (interfacce di programmazione) pubbliche e stabili, da non dover ricostruire con qualche reverse engineering rattoppato alla bell’e meglio…

Il 2.0, nel senso migliore, dovrebbe servire proprio a stimolare, provocare se vuoi, una maggiore apertura delle piattaforme e dunque maggiori possibilità di riusare i dati, di mapparli senza costruire crosswalk da mal di testa, indcizzarli e interrogarli, come già si diceva, liberamente.

Devo infine inchinarmi alla sapiente esperienza di te&Pierre che quando scendete in campo ci offrite sempre spunti di riflessione e racconti di grande interesse…

L’esempio e’ la rivista Urbanistica.
Per quanto riguarda il quadro complessivo ricordo i punti principali
- le immagini sono state a suo tempo realizzate dalla BNCF in basae ad una convenzione fra BNCF, INU e CNBA
- gli spogli sono stati realizzati a suo tempo dall’Università di Firenze (p.ssa Ragghianti) e ceduti al CNBA
- il prof. Gosen dello Iuav ha elaborato i dati per incrociare immagini e spogli e realizzare dei file CSV poi elaborati da me in Excel per ottenere i file guida (fascicoli e spogli)
- tutti i file guida sono stati caricati su MetaMAG, recuperando la descrizione via Z39.50 dal database degli spogli
- i relativi file XML sono stati indicizzati da un motore di ricerca semantico e strutturato (Swish-e)
- in fase di indicizzazione EasyWeb verifica da una apposita lista se esiste una corrispondenza BID e file XML e ne segnala la presenza in un apposito campo che permettera’ quindi al PFT (print format) di generare il link
- sono state realizzate due “query” via PHP su Swish-e, lanciate dal link di EasyWeb, la prima per ottenere dall’analitico (struttura per pagine di spoglio) il nome del file del BID madre, la seconda per recuperare dal BID madre (struttura per fascicoli) i nomi di file immagini.
- con le informazioni relative alla struttura e ai nomi dei file PHP richiama i file immagini dei singoli articoli e crea “al volo” un file PDF mandato in visualizzazione.

E’ L.2.0 utilizzare dati provenienti da fonti diverse e farli interagire fra di loro.
Oggi ho EW, ho gli strumenti per modificare sia l’indicizzazione sia la visualizzione ed elaborare i link.
Ma quale Opac mi permette di fare cio’ (neanche ovviamente la nuova release di EW….).

Altro caso.
Ho una piattaforma di streaming video, in cui sto caricando una selezione di video in vari formati (a partire da http://opac.iuav.it/sbda/main.php?section=208 ).
Se come sopra ho potuto collegare EW ai video, tuttavia, per gestire i diritti di accesso ai video, soggetti a molteplici variabili, dipendo da un software ad hoc, MediaTOO, che ovviamente non si integra in modo trasparente perche’ vuole mantenere la sua immagine…
Ma comunque, potro’ in futuro continuare a mantenere questi collegamenti? Attenzione, non mi si parli di inserire il link in un campo del database in fase catalografica. Di 2.0 parliamo.

Sono esempi. Forse locali, ma credo pertineti. L’Opac non ha speranze se vuole essere omnicomprensivo, monolitico a autorefernziale. Aspetto datbase aperti ad integrazioni e postelaborazioni Web 2.0.

Pierre

Appunto.
Monolitiche….

Il mio punto di vista, assolutamente personale (specificato e ribadito), e’: BUTTIAMO VIA GLI OPAC.
Io vedo un futuro ove i dati bibliografici siano accessibili similmente all’Open Archive.
O anche semplicemente come (per gli oggetti digitali) i MAG dell’ICCU (semplici file XML).
Saranno poi i motori delle singole istituzioni che indicizzeranno localmente con il motore che preferiranno i diversi cataloghi di proprio interesse.
Alle ditte che costruiscono i monoliti, lasciamo il compito di realizzare i database, legati agli strumenti di backoffice e prestito. Ma che forniscano delle chiavi di accesso ai database o ai file dei singoli record, in modo che possiamo gestirci localmente i cataloghi che vogliamo, propri o pubblici che siano, in modo che possiamo fornire l’interfaccia con l’ergonomia che preferiamo e il look che ci rappresenta (noi, non le ditte), in modo che possiamo integrare agilmente i cataloghi con le infinite possibili che ci offre il Web 2.0.

Non credo che nuove release rilasciata dalla ditta tale o tal’altra permettano di realizzare un unovo Opac 2.0. La loro intrinseca necessia’ di affermazione sulla concorrenza le sping sempre piu’ a rafforzare la propria immagine, la necessità di ridurre i costi di gestione a fornire prodotti sempre piu’ standardizzati.

Insomma, non sara’ Web 2.0 l’Opac che sara’ uguale per una rete di biblioteche civiche o una rete di biblioteche di supporto alla ricerca fisica avanzata.

Mi si obiettera’ che difficilemtne le istituzione possono permettersi di realizzare in proprio gli strumenti sopra indicati. Vero, ma perche’ mai dovrebbero realizzarli loro? Si rivolgeranno ad altr ditte che lavorano nel mondo 2.0, non necessariamente con le biblioteche, ma che saranno in grado di fornire strumenti finali per l’utente probabilmente molto piu’ efficaci.

Ma questo e’ un punto di vista mooolto personale.

Pierre Piccotti

Costi altissimi (sia in sé sia considerando i tagli ai finanziamenti che si abbattono ogni anno sui bilanci pubblici) e piattaforme non proprio oliate e flessibili. Oltre al fatto che, essendo chiuse, tutti i problemi e le difficoltà ricadono sull’ultimo anello della catena, cioè appunto sulle biblioteche utilizzatrici. Sarà che più lavoro in biblioteca e più ne vedo ma veramente alcuni software paiono uno spot vivente all’open source ;)

Io una proposta ragionevole e sensata – leggi: economica ma non troppo sperimentale – (anzi, un paio) per il Sistema Trentino ce l’avrei ma ti fai tu (collaboratore-)intermediario? Let me know… :)

Secondo me di fronte ad una proposta ragionevole e sensata, sarebbero disposti a finanziare un progetto per passare ad un’altra piattaforma.
Ti va di pensarci? Con la tua esperienza non dovrebbe essere difficili individuare cosa proporre (in pieno spirito KISS (keep it simple stupid)!).
Che ne dici?
[Forte fare queste proposte nel pubblico di un commento sul blog e non nel privato di una email ...]