Saluti

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

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)

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

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.

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