Il gruppo di lavoro di XC, Extensible Catalog, ha partorito, dopo alcuni studi condivisi con la comunità bibliotecaria internazionale, i primi applicativi: tool open source sviluppati per arricchire le funzionalità degli OPAC e soprattutto per lavorare a una emersione dei loro contenuti (se n’era già parlato qualche tempo fa).
Il progetto mi interessa moltissimo – sempre a proposito di metadati ed esigenze di riconvertire/trasformare(/appiattire?) i nostri schemi di rappresentazione delle informazioni verso interfacce universali basate su lingue franche. Paul Weston ha dedicato al tema un interessantissimo e originale intervento alle Stelline.
Peraltro qui si lavora anche ai moduli di circolazione – che mi sembrano in assoluto quelli più negletti quando si parla di costruire interfacce ai cataloghi (in genere si privilegia l’interrogazione di risorse; questa è un nota eccezione). Inoltre l’obiettivo è non solo una rappresentazione più completa e ricca delle risorse descritte in catalogo ma l’interoperabilità con (informazioni provenienti da) altri sistemi (tipicamente i learning management systems) e l’integrazione con altri tipi di contenuti – anche quelli forniti dagli utenti.
Recentemente uno dei gruppi di lavoro che ho la fortuna di coordinare, ha rilasciato MetaBib, il meta-motore di interrogazione delle risorse digitali della mia biblioteca basato sul software Metalib. E’ stata un’esperienza interessante e formativa sotto vari aspetti, tra cui proprio quello della creazione from scratch e non, di modalità di interrogazione delle diverse banche dati, motori, archivi aperti, piattaforme di e-journals.
Prendiamo il nostro archivio aperto, per esempio. Tra le altre, dispone – ovviamente – di un’uscita OAI-PMH, lo standard verso cui XC è – giustamente – focalizzato, per favorire l’interrogabilità e la reperibilità sul Web delle risorse digitali, delle informazioni contenute nei cataloghi.
Configurando il nostro archivio per renderlo interrogabile in MetaBib, è emerso un problema con il campo data. In BOA vi sono tre date, di cui due interne e una terza che rappresenta la data di pubblicazione del documento (poniamo: un articolo) che il record descrive. Queste date, come tutti gli altri metadati, sono espresse con Dublin Core qualified, che rendono conto delle diversità dei campi.
Il protocollo OAI-PMH si basa però sui Dublin Core simple, cioè lo schema base schiacciato sui quindici metadati primari. E in essi vi è un solo campo data. Ergo: in MetaBib, BOA non può essere interrogato, sfruttando il protocollo OAI-PMH, per la sola data di pubblicazione: ogni qual volta si lancia una ricerca per data, vengono interrogati anche i campi delle date di creazione/validazione dei record – che sono ovviamente campi interni, il cui contenuto poco interessa all’utente.
Vi sono potenzialmente altre modalità di uscire dalla situazione: ad esempio creando delle interfacce standard di programmazione, sfruttando la rappresentabilità dei record nei vari dialetti XML. Ma il problema dei Dublin Core simple – formato diventato grande (in tutti i sensi) proprio grazie alla sua universalità e applicabilità – resta. Resta la difficoltà di esprimere la ricchezza dei dati attraverso pochi campi, e così generici, da un lato, da consentire la semplicità di adozione, e, dall’altro, da impedire che la ricchezza delle informazioni emerga intatta nel Web. Come pure resta la difficoltà di confrontarsi con dei qualificatori che richiedono comunque ulteriori personalizzazioni, che vengono talvolta codificate in application profile – ma che rimangono spesso e inevitabilmente locali all’applicazione che le implementa (e parliamo solo di descrizione delle informazioni!).
Concludo segnalando l’uscita del sito di RDA e quella, scoperta grazie al Friendfeed di Massimo Menichinelli, di un social network – peer-to-peer, di nicchia e in erba, ma che pone l’accento su questioni di vitale importanza, come la privacy, l’accessibilità e la portabilità dei dati. Last but not least, segnalo l’uscita (di scena) di Encarta (cui va il mio de profundis inquieto).
8 Aprile 2009 alle 11:16 am
Dalle prime righe di presentazione che ho subito letto su XC sembra che ne vedremo delle belle! Cito: “XC does not use metasearch technology. XC uses a series of services to collect metadata, normalize it into a common format, enhance existing relationships, refine it into FRBR levels, and then construct a single efficient interface that provides precise and comprehensive searches.”: niente male! Sembra la Shangri-La dei sistemi di ricerca :-)
8 Aprile 2009 alle 8:20 pm
Ciao Enrico, sì, davvero sembra un ottimo progetto. Ricordo che, mentre nell’ultimo anno almeno il team raccoglieva spunti per definire il modello concettuale, si erano levate anche delle critiche – un po’ per l’approccio (che sembrava) eccessivamente teoretico, un po’ perché veniva letto forse come l’ennesimo progetto di meta-qualcosa che rischiava di sgonfiarsi come una bolla da new economy :-)
E invece con il rilascio di questi tool, i primi passi cominciano a farli – e mi sembra nella giusta direzione. L’approccio alla creazione di un workflow di integrazione tra metadati mi sembra interessante – anche se, proprio sulla scorta dell’esperienza fatta con Metalib, devo dire che sono sempre più scettica sulle possibilità di mettere insieme (a un livello significativo, non basico) configurazioni di metadati differenti.
Certo, FRBR può aiutare – e per inciso evidenzia ancora una volta la necessità di aderire a uno schema terzo – ma bisogna vedere cosa emerge al termine dell’operazione di normalizzazione. Comunque, senz’altro l’argomento è di grande momento e, per questioni non solo di generica partecipazione culturale, ma di egoistico interesse professionale terra-terra, non vedo l’ora che se ne continui a parlare, che si sperimenti, si provi, si migliori. Ciao, a presto e Buona Pasqua a te e a tutti i lettori di Geek Lib :-)
9 Aprile 2009 alle 4:09 pm
[...] si va ad aggiungere all’altra interessante scoperta di questa settimana (grazie a Bonaria): eXtensible Catalog, che ha finalmente pubblicato i tool su cui lavora da un po’ di [...]
15 Aprile 2009 alle 1:14 pm
“…ogni qual volta si lancia una ricerca per data, vengono interrogati anche i campi delle date di creazione/validazione dei record – che sono ovviamente campi interni, il cui contenuto poco interessa all’utente….”
Proprio in questi giorni pure qui stiamo mappando i nostri DB con D.C: per OAI-PMH.
Relativamente alla data, noi abbiamo scelto di considerare *solo* la data di pubblicazione, scartando le altre.
Problemi comunque ce ne sono, proprio per le ragioni da te indicate.
Per esempio il link alla risorsa originale (il D-B. originante) va in DC Identifier? In generale si, ma ci sono esempi discordanti.
Dove va il luogo di pubblicazione? E’ escluso che vada in DC Coverage che indica la copertura geografica e/o temporale.
Ma neanche in DC Publisher, non ho trovato casistiche in questo senso.
Mi sembra che l’editore sia sempre riportato senza luogo.
E altro ancora.
Volendo possiamo scambiarci le tabelle prodotte.
Ciao, Pierre
15 Aprile 2009 alle 4:17 pm
Ciao Pierre, mi sa che in questo periodo lavoriamo su cose molto simili :-)
Anche a noi la mappatura dei DC ci ha fatto penare parecchio (e per la verità è un processo ancora in fieri: ogni tanto emerge qualche perplessità) – e considera che avevamo un’ottima base fornita dal Cilea come architettura di DSpace.
Dico mappatura perché di fatto quello su cui ci siamo trovati a lavorare è stata una riedizione creativa dei DC qualificati – ritagliata sulle esigenze del nostro archivio. I dubbi che nutri sui campi li condivido appieno – e temo siano irrisolvibili (almeno allo stato delle cose).
Passando alla mia interpretazione dei DC qualified, il link lo metterei senz’altro nell’identifier; per il luogo dell’editore, in BOA ci siamo orientati su una specificazione del metadato publisher (publisher.place – v. per esempio questo record di BOA. Quanto alle date, noi in totale ne abbiamo quattro, di cui una sola obbligatoria (data di pubblicazione) e due interne (la quarta è quella di creazione del documento, ma è opzionale).
Uno squarcio di luce, per quanto mi riguarda, l’hanno aperto non solo altre applicazioni, quanto i profili applicativi cui ho attinto a piene mani (in particolare lo SWAP). Un altro aiuto può venire dal fatto che in uscita comunque in DC si possono ulteriormente mappare, alla ricerca di un’infinita compatibilità (che però, come obiettivo ultimo, sfugge sempre ;-)
E tutto ciò, come giustamente ricordato da Paul Weston alle Stelline, riguarda solamente la descrizione formale, non ancora i valori interni ai campi, per la qual cosa i problemi aumentano e si moltiplicano… Soprattutto se si ha bisogno di descrivere risorse bibliografiche, sarebbe forse più corretto attingere a formati specifici, come l’ONIX, integrando namespace e schema XML, piuttosto che forzare a dismisura il DC: è una cosa su cui sto riflettendo per il nostro archivio. Ancora una volta, però, il problema di ricondurre poi il tutto, in uscita, a DC interoperabili, non sarebbe per questo eluso…
Insomma, dall’alto della mia pluriennale sprezzatura verso questo arcaico e ridondante e didascalico formato, quasi quasi comincio a rivalutare l’UNIMARC e tutti i suoi campi e sotto-campi ;-) Scambiamoci senz’altro le tabelle: mi piacerebbe avviare un confronto anche con altri colleghi e arrivare a qualche determinazione comune. A presto, e grazie.
15 Aprile 2009 alle 8:03 pm
Più che ONIX io guarderei a MODS, visto che ONIX non permette di fornire descrizioni (neanche di alto livello) per specifiche tipologie documentarie, come riportato in un articolo di Goldsmith e Knudson su d-lib http://www.dlib.org/dlib/september06/goldsmith/09goldsmith.html
A tal proposito Rebecca Guenther ha assicurato che le discussioni su una versione 4 di MODS dovrebbero portare qualche cambiamento anche nelle aree dove mods permette solo descrizioni sommarie
16 Aprile 2009 alle 2:27 pm
Ciao Salva, l’idea dell’ONIX nasce dall’esigenza di rappresentare, secondo regole precise e in vista dell’interoperabilità anche con database esterni, singoli segmenti di informazioni bibliografiche con i formati più adatti – dunque di intessere l’XML dell’OAI-PMH con vari schemi, alla bisogna.
ONIX ha dei vantaggi quanto a rappresentazione bibliografica di alcune tipologie di documenti – invece MODS per ora lo usiamo solo per l’esportazione di record verso altri contenitori, e non sarebbe risolutivo un suo utilizzo massivo perché resterebbero sempre delle tipologie scoperte.
In ogni caso, come detto, entrambe le ipotesi non sono risolutive rispetto allo standard OAI-PMH, la cui evoluzione verso un ampliamento del set di metadati base, sarebbe credo l’unica vera leva per consentire piena interoperabilità tra gli archivi… (almeno quelli che aderiscono a OAI-PMH)
16 Aprile 2009 alle 3:27 pm
No, ma questo mi è chiaro… del resto la nascita e lo sviluppo di OAI-ORE prende corpo anche dalla consapevolezza dei limiti di OAI-PMH (anche se non voglio dire sia nato solo per questo).
Quello che volevo dire è che non sono convinto, e l’articolo citato sembra supportare questa ipotesi ( http://www.dlib.org/dlib/september06/goldsmith/09goldsmith.html#fig1 ), che ci siano tipologie documentarie esprimibili (nel dettaglio) in ONIX che non siano esprimibili con uguale granularità in MODS. Al contrario ci sono alcune aree in cui ONIX non è in grado di fornire informazioni di livello alto (come fa dublin core).
16 Aprile 2009 alle 3:32 pm
edit: aggiungo per completezza che non ho guardato se il nuovo schema di ONIX (la versione 3, rilasciata una settimana fa) cambia qualcosa rispetto a questa analisi… ma visto che è solo relativo allo schema per i libri sarei propenso per il no.
25 Aprile 2009 alle 7:53 pm
Ciao Salva, la differenza tra ONIX e MODS ripropone in qualche modo il dilemma tra la scelta di un formato di metadati specifico per un tipo di documento, che presenta un’elevata granularità ed è ad alto tasso di significatività (se ben codificato, ovviamente) e metadati universalmente granulari ma per questo non completamente specifici di nessuna tipologia di documento e però contenenti comunque un certo grado di complessità. Oggi mi sono dilettata nell’andare a riguardare un formato bibliografico semantico che mi aveva suggerito Federico Bo ormai quasi un anno fa: BibliOntology. Che ne pensi?
10 Maggio 2009 alle 4:13 am
Interessante BibliOntology. Un pò scarno ma funziona bene..
Saluti