12 Risposte to “Cataloghi eXtensibili, interfacce e metadati”

  1. Enrico Francese Says:

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

  2. bonaria Says:

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

  3. Il portale oss4lib « Mind Matters Says:

    […] 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 […]

  4. Pierre Says:

    “…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

  5. bonaria Says:

    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.

  6. shaitan Says:

    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

  7. bonaria Says:

    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)

  8. shaitan Says:

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

  9. shaitan Says:

    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.

  10. bonaria Says:

    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?

  11. Lorenzo De Santis Says:

    Interessante BibliOntology. Un pò scarno ma funziona bene..

    Saluti

  12. Mind Matters » Blacklight Says:

    […] 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 […]

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...


%d blogger cliccano Mi Piace per questo: