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).
